Un UUID, ce sont 128 bits écrits en 32 chiffres hexadécimaux selon la forme familière 8-4-4-4-12. La promesse : vous pouvez en frapper un sur n'importe quelle machine, à tout moment, sans demander à personne, et ne jamais entrer en collision avec un UUID frappé ailleurs. Cet outil génère la version 4 — celle qui est aléatoire.
La version 4, ce sont 122 bits aléatoires, pas 128
Six des 128 bits sont déjà pris. Quatre encodent la version, ce qui explique que tout UUID v4 porte un « 4 » littéral au début du troisième groupe. Deux autres encodent la variante, ce qui explique que le quatrième groupe commence toujours par 8, 9, a ou b. Tout le reste — 122 bits — est aléatoire.
Cela laisse la place à environ 5,3 × 10³⁶ valeurs. Le nombre qui intéresse vraiment, c'est la probabilité de collision : la borne des anniversaires place 50 % de chances d'obtenir un doublon quelconque autour de 2,7 × 10¹⁸ UUID. Pour l'atteindre, il faudrait en générer un milliard par seconde pendant environ quatre-vingt-cinq ans. En pratique, si vous entrez en collision, c'est votre source aléatoire qui est cassée — pas vos probabilités.
L'origine de l'aléa compte plus que la version
Ce générateur utilise crypto.getRandomValues(), la source aléatoire cryptographiquement sûre du navigateur. Ce choix n'est pas cosmétique. L'alternative évidente, Math.random(), n'est pas un CSPRNG : V8 l'implémente avec xorshift128+, un algorithme conçu pour la vitesse et la qualité statistique, pas pour l'imprévisibilité. Observez assez de ses sorties et vous pourrez reconstituer son état interne et prédire chaque valeur suivante.
Pour un UUID qui doit seulement être unique, cette différence est sans importance. Elle devient capitale dès qu'on attend aussi d'un UUID qu'il soit indevinable — un lien de réinitialisation de mot de passe, une URL d'invitation, le partage « secret » d'un document. Ce sont précisément les endroits où les UUID v4 servent de jetons, et un générateur fondé sur Math.random en fait une vulnérabilité qu'aucun test ne détectera. Si vous ne retenez qu'une chose de cette page : vérifiez ce qu'utilise votre bibliothèque d'UUID avant de traiter sa sortie comme un secret.
La question de la clé primaire
Les UUID aléatoires font d'excellents identifiants et de médiocres clés primaires groupées ; mieux vaut savoir pourquoi avant de figer un schéma. Les bases de données conservent les index B-tree triés. Les entiers auto-incrémentés s'ajoutent toujours à la page la plus à droite, ce qui coûte peu. Les UUID v4 aléatoires atterrissent n'importe où : les insertions se dispersent sur tout l'index, forçant des éclatements de pages et salissant des pages dans tout le buffer pool.
C'est le plus douloureux sur MySQL avec InnoDB, où la clé primaire est l'index groupé : la table elle-même est physiquement ordonnée par elle, et chaque index secondaire embarque une copie de la clé primaire. Une clé aléatoire de 16 octets y coûte doublement. C'est exactement le problème que la version 7 des UUID a été normalisée pour résoudre : elle place un horodatage en millisecondes dans les bits de poids fort, si bien que les valeurs se trient grosso modo par date de création et que les insertions restent près du bord droit, tout en gardant assez d'aléa pour rester indevinables. Si vous voulez des UUID en clés primaires à grande échelle, v7 ou ULID est la réponse moderne. Cet outil génère du v4, le bon choix pour des identifiants qui ne sont pas aussi l'ordre physique de votre table.
Les formats sont cosmétiques, pour l'essentiel
Avec tirets, sans tirets, en majuscules, entre accolades — les quatre représentent les mêmes 128 bits et tout analyseur sensé les accepte tous. Le style à accolades vient des conventions GUID de Microsoft ; c'est ce que vous verrez dans le registre Windows et dans les interfaces COM. La forme compacte de 32 caractères est pratique là où la longueur compte, comme un segment d'URL.
Une mise en garde : la RFC 9562 impose les minuscules en sortie, tandis que les analyseurs doivent accepter les deux casses en entrée. Si vous stockez les UUID sous forme de chaînes plutôt qu'en type natif de 16 octets, une casse incohérente peut produire deux lignes qui sont le même UUID sans être égales à la comparaison. C'est un bug qu'on s'inflige soi-même ; normaliser en minuscules à l'entrée l'évite.
Questions fréquentes
Les UUID sont-ils générés sur un serveur ?
Non. Cet outil porte la mention « client » : chaque valeur est produite dans votre onglet par sa propre source aléatoire, et rien n'est transmis. C'est aussi la réponse honnête à la question de savoir s'ils n'appartiennent qu'à vous — personne ici n'en garde trace, nous compris.
Deux UUID v4 peuvent-ils être identiques ?
Mathématiquement oui, pratiquement non — avec un gros astérisque. Les probabilités ne sont négligeables que si l'aléa sous-jacent est sain. Les incidents réels d'UUID en double remontent presque tous à une source cassée : un PRNG à graine fixe, une machine virtuelle clonée avec son réservoir d'entropie, ou un appareil embarqué qui génère des clés avant d'avoir collecté la moindre entropie. Le risque n'est pas la mathématique, c'est la source aléatoire.
Un UUID v4 est-il sûr comme jeton secret ?
S'il provient d'une source cryptographiquement sûre, 122 bits aléatoires suffisent largement — confortablement plus qu'un jeton de session typique de 128 bits. Mais la condition est toute la réponse. Vérifiez que votre générateur utilise crypto.getRandomValues ou l'équivalent de la plateforme plutôt que Math.random, et ne présumez jamais qu'une bibliothèque a bien fait les choses au seul motif que sa sortie a l'air aléatoire.
Faut-il un UUID ou un entier auto-incrémenté ?
Les entiers sont plus petits, plus rapides à indexer et se trient naturellement. Les UUID permettent de générer des identifiants sans aller-retour vers la base, de fusionner des jeux de données de systèmes différents sans renumérotation, et d'éviter de révéler combien d'enregistrements vous avez — un identifiant séquentiel dans une URL raconte à tout le monde votre nombre de commandes. Beaucoup de schémas finissent avec les deux : une clé entière interne pour la base, et un UUID pour le monde extérieur.
Pourquoi le troisième groupe commence-t-il toujours par 4 ?
Ce quartet est le champ de version, et 4 signifie « généré à partir de nombres aléatoires ». Il n'est pas lui-même aléatoire : c'est une étiquette. C'est ainsi qu'un analyseur sait qu'il doit interpréter le reste comme du v4 et non comme un horodatage v1 ou un hachage v5. Si vous en générez 2000 ici, les 2000 la porteront.