Générateur d’UUID

La version 4 est un UUID fait de bits aléatoires — 122 d’entre eux, les six restants étant fixés pour déclarer la version et la variante. Il ne porte aucune information sur le moment ni sur le lieu de sa fabrication, ce qui est justement pourquoi c’est la version par défaut : rien de lui ne fuite, et deux identifiants générés indépendamment n’importe où dans le monde ne se rencontreront pas.

Les autres répondent à d’autres questions. Les versions 1 et 6 embarquent un horodatage et un identifiant de machine, donc elles se trient par date de création et divulguent quelque chose sur la machine. Les versions 3 et 5 sont déterministes — un hash d’un nom dans un espace de noms, donc le même nom donne toujours le même UUID. La version 7 est la nouvelle version ordonnée dans le temps, conçue pour les clés de base où une insertion aléatoire coûte cher à l’index.

Un UUID produit par `Math.random` a la même forme, les mêmes tirets et le même chiffre de version qu’un UUID issu d’une source cryptographique. Rien en lui n’a l’air faible. Mais `Math.random` est un générateur pseudo-aléatoire rapide à petit état interne, et une poignée de sorties peut suffire à prédire les suivantes — ce qui transforme un identifiant « aléatoire » en identifiant devinable.

Cette page emploie `crypto.randomUUID`, qui puise dans l’entropie du système d’exploitation et fixe correctement les bits de version et de variante. Là où il n’est pas disponible, la page s’arrête et le dit au lieu de se rabattre : un repli silencieux est la façon dont des identifiants prévisibles arrivent en production, puisqu’il n’y a aucun symptôme à remarquer.

Il est indevinable, ce qui n’est pas la même chose que secret. Les UUID finissent dans des URL, dans des journaux, dans des en-têtes de référent, dans des outils de mesure d’audience, dans des tickets de support et dans des captures d’écran. Tout ce qui est accessible en connaissant un UUID est accessible à quiconque a vu cette URL une fois.

Cela en fait une poignée indevinable acceptable pour quelque chose de peu sensible — un lien de partage vers un document, un envoi ponctuel — et un mauvais choix comme seule chose séparant Internet des données de quelqu’un. Si connaître l’identifiant donne l’accès, vous avez construit une authentification à partir d’une valeur qui fuit par conception.

Il existe 2^122 UUID de version 4 possibles. Pour atteindre une chance sur un milliard d’observer une seule collision, il faudrait en générer environ 10^15 — un milliard par seconde pendant à peu près un mois. Pour tout système réel, la réponse est que cela n’arrivera pas.

La réserve est que cela ne tient que si l’aléatoire est réel. Chaque collision d’UUID rapportée dans la nature remonte à un générateur faible ou mal initialisé : des conteneurs démarrés depuis une image identique et amorcés sur l’horloge, un équipement embarqué sans entropie au démarrage, une bibliothèque retombée sur `Math.random`. Le risque n’est pas dans les mathématiques, il est dans la source.

Un UUID aléatoire en clé primaire répartit les insertions uniformément dans l’index, ce qui est l’inverse de ce qu’un arbre B veut — chaque insertion touche une page différente, le cache cesse d’aider, et l’index se fragmente. Sur une grande table, c’est un coût mesurable et bien documenté.

Les réponses habituelles sont un UUID ordonné dans le temps comme la version 7, ou une clé séquentielle séparée avec l’UUID conservé comme identifiant externe. Il vaut mieux décider délibérément que découvrir le problème à l’échelle, car changer le type d’une clé primaire plus tard fait partie des migrations les plus coûteuses qui soient.

La forme canonique compte trente-deux chiffres hexadécimaux en cinq groupes séparés par des tirets, en minuscules. L’outillage Windows entoure souvent l’ensemble d’accolades, et beaucoup de bases stockent la valeur sans tirets pour gagner quatre octets par ligne.

Ces variantes désignent le même identifiant, et pourtant elles ne se comparent pas comme des chaînes. Une jointure entre une table qui stocke les tirets et une autre qui ne les stocke pas ne remonte rien, sans aucune erreur : c’est un mode de panne courant et long à diagnostiquer, parce que les deux colonnes contiennent visiblement la même valeur.

Le plafond est là pour que la sortie reste lisible et copiable d’un geste, pas parce que le calcul coûterait quelque chose : générer mille UUID prendrait quelques millisecondes. Cent lignes tiennent dans un presse-papiers et se relisent ; dix mille ne se relisent pas.

Au-delà, l’outil approprié n’est plus une page web mais une commande dans le langage que vous employez : une boucle autour de `crypto.randomUUID` en JavaScript, `uuidgen` en ligne de commande, `gen_random_uuid()` dans PostgreSQL. Ce sont d’ailleurs les mêmes sources d’entropie, et le résultat a exactement la même qualité.

La version 7 place un horodatage en millisecondes dans ses premiers bits, ce qui la rend croissante dans le temps et donc bien meilleure comme clé primaire. Elle a été normalisée en 2024 et les bibliothèques la proposent de plus en plus largement.

Elle n’est pas générée ici parce que `crypto.randomUUID` produit exclusivement de la version 4, et qu’écrire une version 7 à la main demanderait de remplacer la primitive de la plateforme par notre propre assemblage de bits — exactement ce que la section sur l’aléatoire déconseille. Quand la plateforme la proposera, cette page la proposera.

Un UUID de version 1 contient l’adresse MAC de la machine qui l’a produit et l’instant, à cent nanosecondes près, où il a été produit. Publier de tels identifiants revient donc à publier un inventaire partiel de son infrastructure et une chronologie exacte de ses créations d’enregistrements.

Ce n’est pas théorique : c’est ainsi qu’un document a autrefois été relié à la machine de son auteur. Si vous héritez d’un système qui expose des UUID de version 1 vers l’extérieur, la page de validation d’à côté vous dira lesquels, et le remplacement par de la version 4 est en général un changement d’une ligne.