Générateur d'UUID

À propos de cet outil

Ce générateur crée des identifiants universels uniques (UUID) conformes à la norme RFC 9562 : la version 4, totalement aléatoire, et la version 7, qui commence par l'horodatage de création et se trie donc dans l'ordre chronologique. Choisissez le format (standard, majuscules, sans tirets, avec accolades ou URN), générez-en jusqu'à cent d'un coup et copiez la liste.

Comment utiliser cet outil

1. Choisissez la version : v4 (aléatoire) ou v7 (triable par date).
2. Sélectionnez le format de sortie et le nombre d'UUID à générer.
3. Cliquez sur « Générer » (ou appuyez sur Espace).
4. Copiez la liste complète en un clic ; pour la v7, l'outil affiche la date encodée dans le premier identifiant.

Anatomie d'un UUID

Un UUID (Universally Unique IDentifier, ou GUID chez Microsoft) est un nombre de 128 bits conçu pour identifier une ressource sans qu'un organisme central ait besoin de distribuer les numéros. On l'écrit en 32 chiffres hexadécimaux répartis en cinq groupes, séparés par des tirets :

• Le chiffre M (premier chiffre du troisième groupe) indique la version : 4 pour un UUID aléatoire, 7 pour un UUID horodaté.
• Le chiffre N (premier chiffre du quatrième groupe) code la variante. Pour les UUID standard, il vaut 8, 9, a ou b.

Ce format est défini par la norme RFC 9562 (mai 2024), qui remplace la RFC 4122 de 2005 et ajoute les versions 6, 7 et 8. Pour la lecture, la norme considère les majuscules et les minuscules comme équivalentes ; la convention est d'écrire en minuscules.

Quelle version choisir ?

Cet outil génère les deux versions les plus utiles aujourd'hui. Un UUID v4 contient 122 bits aléatoires (6 bits sont réservés à la version et à la variante). Un UUID v7 place l'horodatage en tête, suivi de 12 bits qui servent ici de compteur pour garantir que les identifiants d'une même série restent dans l'ordre croissant, puis de 62 bits aléatoires.

UUID v4 ou v7 pour une base de données ?

La plupart des bases de données stockent leurs index sous forme d'arbres triés (des arbres B). Lorsqu'on insère des clés totalement aléatoires (v4), chaque nouvelle ligne tombe à un endroit imprévisible de l'index : les pages mémoire sont sollicitées au hasard, l'index se fragmente et les performances d'écriture se dégradent à mesure que la table grossit. La norme RFC 9562 relève précisément cette « mauvaise localité » des UUID v4 dans les index, et présente la version 7 comme une réponse : comme les valeurs consécutives sont proches, les insertions se regroupent à la fin de l'index, comme avec un compteur auto-incrémenté.

Un UUID v7 conserve les avantages de l'UUID : il peut être créé par n'importe quel serveur, navigateur ou application mobile sans coordination, y compris hors ligne, puis fusionné plus tard sans conflit. Deux conseils pratiques :

• Stockez-le sous forme binaire. Un UUID occupe 16 octets en binaire (type uuid sous PostgreSQL, BINARY(16) sous MySQL) contre 36 caractères en texte. Sur de grosses tables, la différence de taille se répercute sur tous les index.
• Gardez le v4 quand la date de création est sensible. Un UUID v7 expose l'heure de création à quiconque le connaît. Pour l'identifiant public d'un compte ou d'un document que vous préférez ne pas dater, le v4 reste préférable.

Collisions : faut-il s'en inquiéter ?

Avec 122 bits aléatoires, il existe environ 5,3 × 10³⁶ UUID v4 possibles. Selon le paradoxe des anniversaires, il faudrait en générer environ 2,7 milliards de milliards (2,7 × 10¹⁸) pour atteindre une chance sur deux d'obtenir un doublon. À raison d'un milliard d'UUID par seconde, cela demanderait environ 86 ans de génération ininterrompue. Pour tout usage réel, le risque de collision est négligeable.

Les collisions observées en pratique ont une autre origine : un mauvais générateur aléatoire. Un générateur peu entropique ou initialisé de la même façon sur plusieurs machines produit des séquences identiques. C'est pourquoi cet outil utilise crypto.getRandomValues(), le générateur cryptographique du navigateur, et non la fonction Math.random(), qui n'est pas conçue pour cela. Les navigateurs récents proposent aussi crypto.randomUUID(), réservée aux pages servies en HTTPS.

Ce qu'un UUID n'est pas : un secret

Un UUID sert à identifier, pas à authentifier. La norme RFC 9562 demande de ne pas supposer qu'un UUID est difficile à deviner et de ne jamais l'utiliser comme « capacité de sécurité », c'est-à-dire comme identifiant dont la simple possession donne accès à une ressource. Quelques cas à ne pas confondre :

• Un lien « secret » (partage de document, réinitialisation de mot de passe) doit reposer sur un jeton aléatoire cryptographique dédié, de durée limitée, et non sur l'identifiant d'une ligne.
• Un UUID v1 ou v7 contient une date ; un UUID v1 peut aussi révéler la machine émettrice. N'exposez ces versions que si cette information est sans conséquence.
• Les autorisations doivent être vérifiées à chaque requête côté serveur. Qu'un identifiant soit impossible à deviner ne dispense pas de contrôler qui a le droit de l'utiliser.

Pour fabriquer des mots de passe ou des clés d'accès, utilisez plutôt le générateur de mots de passe, qui indique l'entropie réelle du résultat.

Enfin, les cinq formats de sortie de l'outil correspondent à des usages courants : le format standard en minuscules, les majuscules (fréquentes dans l'écosystème Microsoft), le format sans tirets (32 caractères, pratique dans un nom de fichier), les accolades (registre et COM de Windows) et la forme URN urn:uuid:…, définie par la norme pour les contextes où l'identifiant doit se présenter comme un URI.

Questions fréquentes