Versions d’UUID

Un UUID est un identifiant de 128 bits, écrit comme 32 chiffres hexadécimaux en groupes 8-4-4-4-12, normalisé par la RFC 9562. Le quartet de version vous dit comment il a été fabriqué : v1 et v6 à partir d’une horloge, v3 et v5 à partir du hachage d’un nom, v4 à partir d’aléa, v7 à partir d’un horodatage Unix plus de l’aléa — chacun avec des arbitrages différents d’ordre et de confidentialité.

100 % local

Deux systèmes qui ne se sont jamais rencontrés doivent nommer une ligne, une requête ou un fichier sans demander la permission à personne. Tel est le problème que résolvent les UUID : générer un identifiant à partir d’informations locales — une horloge, des bits aléatoires, un nom — et la probabilité que quelqu’un d’autre produise la même valeur est assez faible pour qu’on puisse bâtir dessus. Aucun service de coordination, aucun compteur partagé à se disputer, aucun registre central à consulter.

La norme actuelle est la RFC 9562, publiée en mai 2024 pour succéder à la RFC 4122, et son changement phare est le statut officiel accordé à deux versions plus récentes : v6 et v7. La version réside dans le quartet de poids fort du troisième groupe — le premier chiffre hexadécimal après le second tiret — et les bits de variante ouvrent le quatrième groupe. Lire ces deux chiffres vous donne d’un coup d’œil la provenance d’un UUID.

Ce guide explique l’agencement en bits de chaque version, ce qu’elle fait de mieux, et là où son honnêteté s’arrête — y compris le coût de confidentialité de l’adresse MAC embarquée de v1 et les mathématiques de collision derrière v4. Le générateur lié ci-dessous produit plusieurs versions en local, pour que vous puissiez examiner le schéma sur votre propre machine.

Chaque agencement ci-dessous se lit plus facilement sur un vrai spécimen — le générateur d’UUID produit des identifiants v4 et v7 dans votre navigateur, et rien de ce qu’il génère n’est journalisé ni envoyé nulle part.

Les identifiants voyagent aussi dans les tokens ; le guide de la structure JWT montre où une revendication jti transporte un UUID et pourquoi le token qui l’entoure est signé mais pas secret.

Anatomie : 128 bits en 36 caractères

Un UUID tient en 128 bits, canoniquement écrits comme 32 chiffres hexadécimaux minuscules en cinq groupes séparés par des tirets, selon 8-4-4-4-12 — 36 caractères avec les tirets, 32 sans. L’agencement n’est pas décoratif : des plages de bits précises portent du sens. Le champ de version, sur quatre bits, occupe le quartet de poids fort du troisième groupe, et la variante, sur deux bits — qui distingue les UUID à la RFC des mises en page plus anciennes de Microsoft et des héritages — occupe les bits de poids fort du quatrième groupe, lisant toujours 8, 9, a ou b en hexadécimal.

Groupe	Chiffres d’exemple	Contenu (montré pour un v1)
1	614e4000	time_low — les bits d’horodatage de poids faible
2	26bc	time_mid — les bits d’horodatage centraux
3	11ef	12 bits d’horodatage, puis la version sur 4 bits — le 1 signifie v1
4	b17d	variante sur 2 bits (binaire 10), puis 14 bits de séquence d’horloge
5	0242ac120002	48 bits de nœud — en v1, l’adresse MAC de la machine génératrice

Quatre versions, un coup d'œil

v1  614e4000-26bc-11ef-b17d-0242ac120002
v4  f7b17bde-5a0c-4174-8c95-407558615543
v6  1ec9414c-232a-6b00-b3c8-9e6bdeced846
v7  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a

Où regarder

3rd group, 1st hex digit = version (1, 4, 6, 7 here)
4th group, 1st hex digit = variant (b, 8, b, 8 here)

v1 et v6 : une horloge et une adresse MAC

v1 construit l’identifiant à partir d’un horodatage de 60 bits comptant des intervalles de 100 nanosecondes depuis le 15 octobre 1582 — le début du calendrier grégorien — plus un compteur de séquence d’horloge et l’adresse MAC sur 48 bits de la machine. L’horodatage est découpé de façon peu intuitive en time_low, time_mid, time_high, un ordre de champs dicté par une commodité de compactage de bits des années 1990, et regretté depuis. L’adresse MAC est le piège à retardement de la confidentialité : chaque UUID v1 révèle quel matériel l’a produit, et c’est pourquoi la RFC 4122 permettait déjà de substituer un nœud multicast aléatoire.

v6, c’est v1 avec l’ordre des champs corrigé : les bits d’horodatage de poids fort passent devant, si bien que les UUID v6 se trient chronologiquement quand on les trie comme chaînes. Même horloge, même champ de nœud, mêmes réserves de confidentialité — mais un comportement en base de données bien meilleur, et c’est là tout l’objet du réordonnancement.

Le même horodatage, deux ordres de champs

v1:  614e4000-26bc-11ef-b17d-0242ac120002
v6:  1ec9414c-232a-6b00-b3c8-9e6bdeced846

Ce qui se range correctement dans un index de chaînes

v6 — son champ timeHigh vient en tête : l’ordre
lexicographique est donc l’ordre chronologique. v1 commence
par les bits de poids faible et s’éparpille.

v3 et v5 : une identité tirée d’un nom

v3 et v5 dérivent l’identifiant d’un UUID d’espace de noms et d’un nom, hachés avec MD5 (v3) ou SHA-1 (v5). Même espace de noms, même nom, même UUID — sur chaque machine, pour toujours. Ce déterminisme est la fonctionnalité : dériver des identifiants stables d’URL, de noms d’utilisateur ou de noms de domaine, sans stocker de table de correspondance, et les régénérer à tout moment sur n’importe quel système.

Le coût, c’est l’envers du déterminisme : l’identifiant fuit de l’information sur le nom. Un v5 d’un nom à faible entropie peut être confirmé par simple devinette, et des noms identiques produisent délibérément des identifiants identiques. v5 remplace v3 — SHA-1 plutôt que MD5 — et bien que la RFC 9562 ne nomme aucune nouvelle version fondée sur un nom, les conceptions neuves qui veulent à la fois déterminisme et ordre temporel passent généralement à v7, avec le nom stocké à côté.

Déterministe : même entrée, même sortie

namespace: DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8
name:      python.org

v3  6fa459ea-ee8a-3ca4-894e-db77e160355e
v5  886313e1-3b8a-5372-9b90-0c9aee199e5d

Pourquoi il se reproduit partout

hash(namespace bytes || "python.org") avec la version
(3 ou 5) et la variante (binaire 10) écrites à des
positions de bits fixes — le même calcul, bit pour bit.

v4 : 122 bits aléatoires et ce que cela achète

v4 fixe 122 bits à partir d’un générateur aléatoire cryptographiquement sûr ; seuls les quartets de version et de variante sont figés. Les probabilités de collision suivent la borne de l’anniversaire : après avoir généré n valeurs, la chance d’un doublon quelconque vaut à peu près n²/2¹²³. Il faudrait environ 2^61 UUID — près de 2,3 trillions — pour avoir une chance sur deux d’une seule collision. Quand des doublons surgissent en pratique, la cause est presque toujours un aléa défaillant — une graine faible, un état de PRNG réutilisé, un défaut matériel — jamais les probabilités elles-mêmes.

L’aléa est aussi la faiblesse de v4 comme clé de base de données : des valeurs complètement désordonnées atterrissent sur des pages B-tree aléatoires, fragmentant les index et épuisant les caches d’écriture à grande échelle. Ce reproche est précisément ce que v6 et v7 ont été normalisés pour corriger, et la raison pour laquelle beaucoup d’ORM et de bases de données distribuées orientent désormais les nouvelles tables vers v7.

v7 : millisecondes Unix plus aléa

v7 est le candidat par défaut moderne : 48 bits d’horodatage Unix en millisecondes, puis 12 plus 62 bits de charge utile aléatoire. L’horodatage en tête rend les UUID v7 triables comme chaînes — un atout pour les index dans précisément les bases de données qui les stockent — tandis que les 74 bits aléatoires maintiennent les probabilités de collision pratiquement au niveau de v4. Il n’exige ni adresse MAC, ni epoch de 1582, ni conversion de calendrier.

Au sein d’une même milliseconde, la RFC 9562 décrit un compteur monotone dans le champ rand_a, pour que des identifiants créés en rafale continuent de croître — une propriété que les clés primaires recherchent encore plus que l’unicité brute. L’horodatage est aussi lisible : il se lit comme 2026, non comme un compte de tops de 100 nanosecondes depuis 1582, ce qui rend v7 agréable à parcourir dans les logs et les résultats de requêtes.

Ordonné dans le temps par construction

2026-01-01T00:00:00Z  019b76da-a800-7c3e-8f2a-5b6c7d8e9f0a
2026-01-01T00:00:01Z  019b76da-abe8-9d41-8c2f-4a5b6c7d8e9f

Trié comme chaîne, trié dans le temps

019b76da-a800-… < 019b76da-abe8-…

l’ordre lexicographique suit la chronologie,
et les 48 bits de poids fort sont un horodatage Unix en ms.

Choisir une version, honnêtement

Pour du neuf : v7 quand les identifiants doivent se ranger par ordre de temps ou vivre dans un index de base de données ; v4 sinon — les deux se passent de coordination et ne fuient rien sur leur origine. v5 se justifie quand l’identifiant doit être reproductible à partir d’un nom. v1 et v6 restent pris en charge, mais fuient l’identité du matériel tant que le générateur ne rend pas aléatoire le champ de nœud, et v3 est l’héritage MD5 maintenu pour compatibilité. Aucune version n’est secrète, et aucune n’anonymise les données : un UUID est un nom, pas une information d’authentification.

Version	Source des bits	Triable comme chaîne	Points de vigilance
v1	Horodatage grégorien + séquence d’horloge + nœud MAC	Non	Fuite de l’adresse MAC
v3	MD5 de l’espace de noms + du nom	Non	Héritage MD5 ; noms devinables
v4	122 bits aléatoires	Non	L’ordre d’insertion aléatoire fragmente les index
v5	SHA-1 de l’espace de noms + du nom	Non	Déterministe — noms confirmables par devinette
v6	v1 réordonné pour la triabilité	Oui	Même réserve MAC que v1
v7	Horodatage Unix en ms + 74 bits aléatoires	Oui	Ex æquo à la même milliseconde sans compteur monotone

Questions fréquentes

Les UUID générés sur ce site sont-ils enregistrés quelque part ?

Non. Le générateur crée les identifiants avec l’API d’aléa de votre propre navigateur, à l’intérieur de l’onglet — il n’y a ni étape d’envoi ni journal côté serveur, car le code n’envoie jamais de requête. Vous pouvez constater que le panneau Network reste silencieux pendant qu’il travaille, et la Content-Security-Policy du site bloque les connexions sortantes pendant toute la durée de vie de la page.

Deux UUID peuvent-ils entrer en collision en pratique ?

Pour v4, la borne de l’anniversaire place la chance sur deux d’un doublon à environ 2^61 valeurs générées — près de 2,3 trillions. Les collisions réelles signalent presque toujours un aléa défaillant plutôt que la malchance : une graine faible, un état de PRNG réutilisé, ou un défaut du RNG matériel. v3 et v5 « entrent en collision » délibérément — le même nom dans le même espace de noms donne le même UUID, par construction.

Pourquoi certains UUID se comportent-ils mal comme clés primaires de base de données ?

Les versions aléatoires (v4) dispersent les nouvelles lignes dans un index B-tree, écrivant sur des pages imprévisibles et martyrisant le cache à mesure que la table grossit. Les versions ordonnées dans le temps (v6, v7) ajoutent au contraire leurs lignes près du bord droit de l’index. Si vous êtes attaché aux clés v4, les remèdes classiques sont une colonne de clustering séparée, ordonnée dans le temps, ou le passage des nouvelles lignes à v7.

Un UUID est-il secret ou anonyme ?

Ni l’un ni l’autre. Un UUID est un identifiant, pas une information d’authentification : il n’apporte aucune preuve de qui le détient, et un v1 diffuse même l’adresse MAC de la machine génératrice tant que le champ de nœud n’a pas été rendu aléatoire. Traitez les UUID comme des noms — sans risque à journaliser, utiles à recouper — et confiez l’authentification et l’autorisation à des mécanismes capables de vérifier réellement quelque chose.

Quelle est la différence entre un GUID et un UUID ?

Ils nomment la même famille d’identifiants de 128 bits ; GUID est le terme de Microsoft. La différence technique réside dans les bits de variante au début du quatrième groupe, qui distinguent les UUID à la RFC (binaire 10 — premier chiffre hexadécimal 8, 9, a ou b) des mises en page plus anciennes de Microsoft et des héritages. Les GUID modernes sont générés comme variantes RFC, et c’est pourquoi les deux termes s’emploient indifféremment dans la plupart des documentations.

Pourquoi l’horodatage v1 commence-t-il en 1582 ?

Le compteur de 60 bits avance par intervalles de 100 nanosecondes depuis la réforme du calendrier grégorien du 15 octobre 1582 — un point de départ assez lointain pour que le compteur ne déborde pas avant des millénaires. Le prix, c’est la lisibilité : un horodatage v1 ne veut rien dire sans convertisseur. Les millisecondes Unix de v7 ont été choisies en partie parce qu’elles se lisent directement comme des dates.

Où puis-je lire les normes citées ici ?

RFC 9562 — Identifiants uniques universels (UUID)
RFC 4122 — Espace de noms URN des identifiants uniques universels (UUID) (remplacée par la RFC 9562)

Équipe ToolsByUs · Comment nous vérifions nos outils

Versions d’UUID en clair