Générateur d’UUID

Qu’est-ce qu’un UUID ?

Un UUID (Universally Unique Identifier, ou identifiant unique universel), aussi appelé GUID, est une valeur de 128 bits écrite sous la forme de 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets — 8-4-4-4-12, par exemple f47ac10b-58cc-4372-a567-0e02b2c3d479. Le but est de créer un identifiant unique sans autorité centrale, afin que des systèmes indépendants puissent chacun produire des identifiants qui n’entreront jamais en collision. Le 13e chiffre code la version et le 17e code la variante.

Les versions d’UUID en un coup d’œil

Cet outil génère les versions v4, v7, v1 et v5. Les versions 2 (sécurité DCE), 6 (une v1 réordonnée) et 8 (personnalisée) sont rarement utiles dans le code applicatif. Nous omettons volontairement la v3 basée sur MD5 — MD5 est cassé et indisponible dans l’API crypto du navigateur — et proposons la v5 basée sur SHA-1, que la spécification privilégie.

Quelle version choisir ?

• Besoin d’un simple identifiant unique ? Utilisez v4 (aléatoire) — c’est le choix par défaut le plus sûr.
• Clé primaire de base de données ? Utilisez v7 — son horodatage en tête garde les insertions dans l’ordre et évite la fragmentation d’index que provoquent les clés v4 aléatoires.
• La même entrée doit toujours donner le même identifiant ? Utilisez v5 avec un espace de noms et un nom.
• Interopérabilité avec un système plus ancien ? Utilisez v1.

Inspecter un UUID

Collez n’importe quel UUID pour vérifier qu’il est valide et lire sa version, sa variante et (pour v1/v7) l’horodatage intégré.

Les UUID sont-ils vraiment uniques ?

Pour la v4 aléatoire, le risque de collision est astronomiquement faible : avec 122 bits aléatoires, vous pourriez générer un milliard d’UUID par seconde pendant environ 86 ans et n’avoir encore qu’environ 50 % de chances d’obtenir un seul doublon. En pratique, vous pouvez les considérer comme uniques. Un UUID est toutefois un identifiant, pas un secret — ne l’utilisez jamais comme mot de passe ou jeton de sécurité.

De la RFC 4122 à la RFC 9562

Les UUID ont d’abord été normalisés par l’IETF dans la RFC 4122 (juillet 2005), qui définissait les versions 1 à 5 et enregistrait l’espace de noms urn:uuid:. Près de deux décennies d’usage réel — en particulier l’essor fulgurant des bases de données distribuées — ont révélé une lacune : les formats temporels d’origine n’étaient pas conçus pour se trier dans l’ordre de création, ce dont les bases de données ont cruellement besoin. La RFC 9562, publiée en mai 2024, rend la RFC 4122 obsolète et répond à cette demande.

Elle conserve les anciennes versions telles quelles et en ajoute trois nouvelles — v6 (une v1 réordonnée), v7 (temps Unix en millisecondes plus aléa) et v8 (une disposition libre, définie par le fournisseur) — ainsi que la nouvelle valeur sentinelle UUID Max. Elle a aussi déclaré l’ancienne variante Microsoft COM hors du champ de la norme, si bien que les versions modernes ne s’appliquent qu’à la disposition courante « variante 1 ». En résumé : rien de ce que vous utilisez déjà n’a été cassé, et les identifiants triables par date sont enfin devenus une norme plutôt qu’un patchwork de solutions maison incompatibles.

L’anatomie d’un UUID, bit par bit

Les 128 bits ont tous un rôle. Sur les 16 octets, deux petits champs sont réservés et le reste porte la charge utile — des bits aléatoires, un horodatage ou un hachage, selon la version. La version occupe les quatre bits de poids fort du septième octet (le premier chiffre hexadécimal du troisième groupe) ; elle se lit donc toujours comme l’un des chiffres 1–8.

La variante occupe les bits de poids fort du neuvième octet (le premier chiffre hexadécimal du quatrième groupe), et pour tout UUID standard ces bits valent 10 en binaire — c’est pourquoi ce chiffre est toujours 8, 9, a ou b. Deux valeurs réservées échappent entièrement au schéma des versions : l’UUID Nil, composé uniquement de zéros (00000000-0000-0000-0000-000000000000), qui signifie « aucune valeur », et l’UUID Max, composé uniquement de uns (ffffffff-ffff-ffff-ffff-ffffffffffff), ajouté par la RFC 9562 pour marquer la fin d’une plage.

Les UUID basés sur un nom et les quatre espaces de noms standard

Les versions 3 et 5 sont déterministes : elles hachent un UUID d’espace de noms avec une chaîne de nom, si bien que la même paire donne toujours le même identifiant, sur n’importe quelle machine, pour toujours. Elles sont donc idéales pour des identifiants stables dérivés de clés existantes — une URL, un nom de fichier, un domaine — sans requête en base de données ni coordination. La seule différence entre les deux est le hachage : v3 utilise MD5, v5 utilise SHA-1, et la spécification recommande v5. La RFC 4122 définit quatre UUID d’espace de noms prêts à l’emploi pour que des systèmes indépendants s’accordent sur les mêmes entrées :

Par exemple, hacher l’espace de noms DNS avec le nom example.com en v5 produit toujours le même UUID sur toute implémentation correcte — c’est précisément pour cela que les UUID basés sur un nom sont reproductibles d’un service à l’autre sans aucun état partagé.

Pourquoi la version 7 s’impose pour les clés primaires de base de données

Les UUID v4 aléatoires font de mauvaises clés primaires pour un index cluster. Comme chaque valeur est imprévisible, les insertions successives se dispersent dans tout l’index ; un arbre B doit scinder des pages partout dans la structure, l’ensemble de travail ne tient plus proprement en cache et le débit d’écriture se dégrade à mesure que la table grossit.

Un UUID v7 corrige cela en plaçant un horodatage Unix de 48 bits, en millisecondes, dans les bits de poids fort, suivi de bits aléatoires qui assurent l’unicité au sein d’une même milliseconde. Les valeurs augmentent donc avec le temps et se trient lexicographiquement dans l’ordre de création, de sorte que les nouvelles lignes s’ajoutent au « bord droit » de l’index — la même localité qu’avec un entier auto-incrémenté, tout en conservant la nature décentralisée, impossible à deviner et facile à fusionner d’un UUID.

C’est aussi pour cela que de nombreuses équipes se sont tournées vers ULID avant l’arrivée de v7. Un ULID est un identifiant de 128 bits triable par date — un horodatage de 48 bits en millisecondes plus 80 bits aléatoires — représenté par 26 caractères en base 32 de Crockford au lieu de l’hexadécimal. Il résout le même problème de localité, mais ce n’est pas une norme de l’IETF et sa forme textuelle n’est pas un UUID valide. Maintenant que la RFC 9562 a normalisé v7 avec, pour l’essentiel, la même conception, les nouveaux projets peuvent obtenir des identifiants ordonnés dans le temps tout en restant pleinement compatibles UUID, ce qui fait progresser v7 au détriment des clés v4 aléatoires comme de ULID.

Les chiffres derrière « unique », et les notes sur la confidentialité

Les probabilités de collision de la v4 sont plus faciles à saisir avec des chiffres exacts. Six des 128 bits sont fixés pour la version et la variante, ce qui laisse 122 bits aléatoires — environ 5,3 × 10³⁶ (5,3 sextillions) valeurs distinctes. D’après le paradoxe des anniversaires, il faudrait environ 2,71 trillions d’UUID avant qu’une seule collision devienne plus probable que l’inverse, et même après en avoir généré 103 billions, le risque d’un doublon reste d’environ un sur un milliard — bien plus d’identifiants que la plupart des organisations n’en créeront jamais dans toutes leurs bases de données. La seule réserve : cela ne vaut qu’avec une bonne source d’aléa. Une v4 produite par un générateur pseudo-aléatoire faible ou mal initialisé peut entrer en collision — et cela arrive.

Deux mises en garde méritent d’être répétées. D’abord, un UUID est un identifiant, pas un secret — ne l’utilisez jamais comme mot de passe, clé d’API ou jeton de session, là où il vous faut une valeur à la fois unique et impossible à deviner, issue d’une source cryptographique dédiée. Ensuite, les versions temporelles peuvent divulguer des informations : un UUID v1 classique intègre à la fois l’horodatage de création et l’adresse MAC réseau de la machine qui l’a généré, ce qui a notoirement aidé les enquêteurs à remonter jusqu’à l’auteur du virus Melissa en 1999.

C’est exactement pour cela que ce générateur construit les v1 avec un nœud aléatoire plutôt qu’avec une vraie adresse MAC, et que v4 ou v7 sont les choix par défaut les plus sûrs dès qu’un identifiant risque d’être exposé publiquement. Enfin, « GUID » — le terme employé par Microsoft — n’est qu’un autre nom pour un UUID ; la seule subtilité est que certains anciens GUID Microsoft sérialisent des parties de la valeur dans un ordre d’octets différent : comparez-les donc toujours sous la forme de la chaîne de texte canonique 8-4-4-4-12 plutôt que sous forme d’octets bruts.

Stocker et formater les UUID en pratique

Un UUID fait conceptuellement 16 octets, mais il s’écrit généralement sous la forme de la chaîne de 36 caractères 8-4-4-4-12. La façon de le stocker compte. Le conserver sous forme de 16 octets bruts — le type natif uuid de PostgreSQL, ou BINARY(16) dans MySQL — occupe moins de la moitié de l’espace d’une colonne texte de 36 caractères et s’indexe plus vite ; le stocker en VARCHAR(36) est pratique mais coûteux à grande échelle.

La forme textuelle canonique est en minuscules, bien que la spécification exige que les analyseurs acceptent aussi les majuscules : traitez donc les comparaisons sans tenir compte de la casse et normalisez les valeurs dès leur entrée. Les tirets ne sont qu’un regroupement cosmétique — certains systèmes les suppriment pour économiser quatre caractères — mais la forme canonique et interopérable les conserve.

Une mise en garde de conception : comme v1, v6 et v7 intègrent un horodatage, et que v4 est impossible à deviner, on suppose parfois que n’importe quel UUID peut être exposé sans risque dans une URL. C’est vrai — pour l’unicité — mais un UUID reste un identifiant, pas une autorisation. Si le contrôle d’accès repose sur le fait que la valeur reste secrète (« toute personne disposant du lien peut voir »), préférez v4 ou un jeton aléatoire dédié aux versions temporelles, car un v1 ou un v7 divulgué révèle approximativement la date de création de l’enregistrement et, pour v1, potentiellement la machine qui l’a créé.

Quand un UUID n’est pas le bon outil

Les UUID ne sont pas gratuits. Avec 128 bits, ils font quatre fois la taille d’un entier de 32 bits et deux fois celle d’un entier de 64 bits, ce qui s’accumule sur des milliards de lignes et dans chaque clé étrangère qui y fait référence. Ils sont aussi peu pratiques pour les humains — personne ne lit à voix haute un numéro de ticket de support du type « f47ac10b-58cc… ».

Si vos identifiants restent dans une seule base de données qui fournit déjà une séquence auto-incrémentée fiable, et que vous n’avez pas besoin de générer des identifiants hors ligne, sur plusieurs nœuds ou avant l’insertion de la ligne, un simple entier séquentiel est plus petit, plus rapide et plus lisible. Optez pour un UUID précisément lorsque vous avez besoin d’une génération décentralisée — des identifiants créés par des clients, par plusieurs serveurs, ou fusionnés depuis des systèmes distincts sans coordination — car c’est là que sa garantie « sans autorité centrale » prend toute sa valeur. Dans ce cas, préférez v7 afin de conserver cette garantie sans sacrifier la localité d’index dont dépend une base de données.

Questions fréquentes

Les UUID sont-ils garantis uniques ?

Pas mathématiquement, mais en pratique, oui. Un UUID de version 4 contient 122 bits aléatoires — il faudrait en générer des milliards par seconde pendant de nombreuses années avant qu’une collision devienne un tant soit peu probable. La version 5 est déterministe : le même espace de noms et le même nom produisent toujours le même UUID, par conception.

Quelle version d’UUID choisir ?

Utilisez la version 4 (aléatoire) pour des identifiants uniques courants. Utilisez la version 7 si vous voulez des identifiants triés par date de création — idéal pour les clés primaires de base de données, car elle évite la fragmentation d’index que provoquent les clés v4 aléatoires. Utilisez la version 5 lorsque vous avez besoin d’un identifiant reproductible dérivé d’un nom. La version 1 sert surtout à la compatibilité avec les systèmes existants.

Un UUID est-il sûr ou difficile à deviner ?

Un UUID de version 4 est suffisamment imprévisible pour être difficile à deviner, mais un UUID est un identifiant, pas un secret. Ne l’utilisez pas comme mot de passe, jeton de session ou clé de sécurité — générez pour cela un secret cryptographique dédié.

Quelle est la différence entre v4 et v7 ?

Les deux sont uniques, mais v7 intègre un horodatage en millisecondes au début, de sorte qu’une liste d’UUID v7 se trie dans l’ordre de création. v4 est entièrement aléatoire et n’a aucun ordre. Utilisez v7 pour les clés de base de données (meilleure localité d’index) et v4 lorsque l’ordre n’a pas d’importance.

Pourquoi n’y a-t-il pas de version 3 ici ?

La version 3 est basée sur un nom mais utilise MD5, qui est cassé sur le plan cryptographique, et l’API Web Crypto du navigateur ne fournit pas MD5. Nous proposons la version 5, l’équivalent fondé sur SHA-1 que la spécification recommande à la place.

Les UUID sont-ils générés en toute confidentialité ?

Oui. Tout est généré localement dans votre navigateur grâce à l’API Web Crypto intégrée — rien n’est envoyé à un serveur, et l’outil fonctionne hors ligne une fois la page chargée. La version 1 utilise un nœud aléatoire, de sorte que l’adresse matérielle de votre carte réseau n’est jamais exposée.

Outils associés

• Générateur de hachage SHA
• Convertisseur de timestamp Unix
• Encodeur / décodeur Base64
• Formateur et validateur JSON

Voir toutes les conversions pour développeurs et données →