Versions de GUID expliquées : v1–v7 et laquelle choisir

2026-07-09

Tags: Windows · GUID · Tutoriel · QuickGUID

---

Ouvrez n'importe quelle bibliothèque UUID et vous verrez uuid1(), uuid3(), uuid4(), uuid5(), et de plus en plus uuid7(). La spécification définit huit versions. Laquelle utiliser réellement ?

La réponse courte : v4 pour presque tout, v7 pour les clés primaires de base de données, v5 quand vous voulez que la même entrée produise toujours le même GUID. Le reste de cet article explique pourquoi — avec les dispositions d'octets, les vraies raisons de chaque version, et un aide-mémoire de code par langage.

Si vous débutez complètement avec les GUID, commencez par Qu'est-ce qu'un GUID ? pour les bases de la structure et de l'unicité. Cet article est le compagnon technique — il va plus loin sur chaque version.

Le panorama des versions de GUID/UUID

Chaque version est une recette différente pour remplir les mêmes 128 bits. Le nibble de version (premier chiffre hex du troisième segment) indique quelle recette a été utilisée.

Version	Source de génération	Triable	Utilisation typique
v1	Temps + MAC	Oui	Systèmes hérités (risque de confidentialité)
v2	DCE Security	Oui	Rare, spécialisé
v3	Hash de namespace MD5	Non	Obsolète (utilisez v5)
v4	Aléatoire	Non	Valeur par défaut générale
v5	Hash de namespace SHA-1	Non	IDs déterministes
v6	Temps v1 réordonné	Oui	Remplacement direct de v1
v7	Horodatage en millisecondes	Oui	Clés primaires de base de données
v8	Défini par le vendeur	Personnalisé	Spécialisé

Les versions v1, v4, v5 et v7 couvrent 99 % de l'usage réel. Passons-les en revue.

v1 : Temps et adresse MAC

v1 est la recette originale de la RFC 4122. Elle regroupe trois choses dans 128 bits :

| time_low (32) | time_mid (16) | ver+time_hi (16) | var+clk_seq (16) | node/MAC (48) |

• Horodatage 60 bits — intervalles de 100 nanosecondes depuis le 15/10/1582 (date d'adoption du calendrier grégorien). L'horodatage est réparti sur time_low, time_mid et time_hi.
• Séquence d'horloge 14 bits — un compteur qui distingue deux GUID générés dans le même tick d'horloge, ou quand l'horloge système a été reculée.
• Nœud 48 bits — l'adresse MAC de la carte réseau.

Le problème de l'adresse MAC

Le champ nœud est une empreinte matérielle. Tout GUID v1 que vous publiez transporte l'adresse MAC de votre machine — et contrairement à une adresse IP, une adresse MAC est conçue pour être globalement unique et persistante. C'est une véritable fuite de confidentialité.

Ce n'est pas théorique. Des chercheurs ont montré qu'on peut retracer des documents jusqu'à la machine qui les a créés en lisant les GUID v1 intégrés aux métadonnées de fichiers. Microsoft lui-même a retiré la génération v1 de la télémétrie Office après que cela fut démontré. Les systèmes d'exploitation modernes randomisent aussi l'adresse MAC présentée aux réseaux Wi-Fi pour la même raison.

Verdict : évitez v1 dans le nouveau code. Il survit dans les systèmes hérités, les interfaces COM et certains outils proches du matériel — mais il n'y a aucune raison de le générer vous-même aujourd'hui.

v2 : DCE Security

v2 est la version que vous ne rencontrerez essentiellement jamais. Elle reprend la disposition v1 (horodatage + MAC) et y superpose un UID/GID POSIX — les identifiants locaux d'utilisateur et de groupe du modèle de sécurité DCE (Distributed Computing Environment) — pour que l'UUID puisse transporter des informations de contrôle d'accès en plus de son unicité.

v2 existe pour l'authentification DCE/RPC et les ACL dans les systèmes d'entreprise hérités. À moins de maintenir un logiciel qui parle explicitement DCE Security, vous ne générerez ni ne consommerez jamais de v2. Il apparaît ici uniquement pour que la liste des versions soit complète et que vous ne vous demandiez pas ce que signifie un « 2 » dans ce nibble si jamais vous en rencontrez un.

v3 : Pourquoi il a été déprécié

v3 est identique à v5 sauf qu'il utilise MD5 au lieu de SHA-1. MD5 a des attaques par collision pratiques — deux entrées différentes peuvent être conçues pour produire le même hash. Cela casse la garantie de déterminisme de v3 dans des contextes adversariaux.

La RFC 4122 a conservé v3 pour la rétrocompatibilité mais v5 l'a remplacé. Il n'y a aucune raison de générer v3 aujourd'hui. Si vous rencontrez un v3 dans la nature, traitez-le comme hérité.

v4 : La valeur aléatoire par défaut

v4 est ce que vous obtenez de pratiquement chaque appel « générer un GUID » : [guid]::NewGuid(), Guid.NewGuid(), crypto.randomUUID(), uuid.uuid4(), NEWID(). Il remplit 122 des 128 bits avec un aléa cryptographiquement fort (les 6 autres bits sont les marqueurs de version et de variante).

Pas d'horodatage, pas de MAC, pas d'état machine — du pur aléa. Cela rend v4 sûr à exposer, trivialement parallélisable et suffisamment résistant aux collisions pour toute charge réaliste. Pour la mathématique complète des collisions (et pourquoi la affirmation virale « un milliard d'années » se trompe sur le paradoxe des anniversaires), voir l'article principal.

Verdict : c'est votre valeur par défaut. Choisissez v4 sauf si vous avez une raison spécifique de choisir autre chose.

v5 : Les IDs de namespace déterministes

C'est la version dont la plupart des développeurs ont entendu parler sans jamais l'utiliser réellement — et elle résout un problème véritablement utile.

v5 vous permet de dériver le même GUID de la même entrée, à chaque fois. Donnez-lui un UUID de namespace et une chaîne de nom, et il renvoie un identifiant déterministe :

import uuid

# Même entrée → même GUID, à chaque exécution, sur chaque machine
dns_guid = uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
url_guid = uuid.uuid5(uuid.NAMESPACE_URL, 'https://prunelab.net/blog/guid-explained')

print(dns_guid)  # toujours  cf14e0a3-... (même valeur)
print(dns_guid == uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # True

Comment ça marche

En interne, v5 concatène les octets de l'UUID de namespace avec les octets UTF-8 du nom, passe le résultat au SHA-1, prend les 16 premiers octets, puis applique les bits de version (5) et de variante. Le namespace lui-même est un UUID — NAMESPACE_DNS, NAMESPACE_URL, NAMESPACE_OID et NAMESPACE_X500 sont prédéfinis, mais vous pouvez utiliser n'importe quel UUID comme namespace.

Quand v5 est le bon outil

• Fixtures de test reproductibles — générez des IDs pour des données de test qui restent stables entre les exécutions, pour qu'un test échouant pointe toujours vers la même entité.
• Identifiants dérivés d'URL — transformez une URL en GUID sans recherche en base. Deux systèmes qui calculent indépendamment uuid5(NAMESPACE_URL, url) pour la même URL tombent toujours d'accord.
• Déduplication idempotente — importez deux fois le même enregistrement et le GUID entre en collision avec lui-même, vous pouvez donc détecter le doublon par la clé seule.

Le contraste clé avec v4 : v4 renvoie une valeur unique par appel (même pour des entrées identiques) ; v5 renvoie une valeur stable pour des entrées identiques. Ils ne sont pas interchangeables.

Verdict : recourez à v5 chaque fois que vous avez besoin d'un GUID qui se dérive de manière reproductible à partir d'une chaîne d'entrée.

v6 : Le correctif v1 dont vous n'avez probablement pas besoin

v6 contient exactement les mêmes données que v1 — le même horodatage, la même séquence d'horloge et MAC — mais réorganise les bits d'horodatage pour que la valeur se trie naturellement par ordre chronologique. En v1 l'horodatage est maladroitement divisé (low, mid, high) ; en v6 il est stocké high-first, donc le tri lexicographique des chaînes égale le tri par temps.

v6 a été standardisé en 2024 dans la RFC 9562 aux côtés de v7. Il existe principalement comme chemin de migration direct pour les systèmes déjà liés au modèle horloge-et-MAC de v1 : vous gardez votre logique d'horodatage existante et réécrivez simplement la disposition des bits.

Pour les nouveaux systèmes, v7 est presque toujours le meilleur choix. v7 utilise un horodatage en millisecondes (plus simple que le comptage grégorien à 100 ns de v1/v6), n'embarque pas d'adresse MAC et a un remplissage aléatoire plus propre. v6 répond à « comment moderniser v1 sans changer mon modèle de génération » ; v7 répond à « que devrais-je utiliser à l'avenir ».

v7 : Ordonné dans le temps pour les bases de données

v7 est le ajout le plus important depuis v4. Il résout un problème que v4 crée dans les bases de données.

Le problème v4 en base de données

Quand une base de données utilise des GUID comme clés primaires, ces clés soutiennent un index en arbre B+. Les arbres B+ restent efficaces quand les insertions sont à peu près ordonnées — les nouvelles valeurs atterrissent au bord droit et remplissent les pages existantes. Les GUID v4 aléatoires se dispersent à travers tout l'espace de clés, donc chaque insertion frappe une page aléatoire. Sur les grandes tables cela provoque des fractionnements de page constants, de la fragmentation d'index, du cache thrash et de l'amplification d'écriture. Le correctif dans SQL Server (NEWSEQUENTIALID()) est un hack propriétaire et non portable qui fuite le séquencement.

La disposition de v7

| unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) |

• Horodatage Unix 48 bits en millisecondes — champ de tête, donc les valeurs augmentent avec le temps.
• Version 4 bits — mise à 7.
• rand_a 12 bits — aléatoire, ou optionnellement un compteur monotone pour ordonner au sein de la même milliseconde.
• Variante 2 bits — le marqueur RFC 9562 standard.
• rand_b 62 bits — aléatoire.

Parce que l'horodatage est en tête, les GUID v7 générés en séquence sont naturellement ordonnés : les insertions d'index se regroupent au bord droit, les pages se remplissent proprement, et l'arbre B+ se comporte comme avec un entier auto-incrémenté — tout en restant globalement unique sans coordinateur central.

Quand v7 n'en vaut PAS la peine

• Stores en mémoire (Redis, memcached) — pas d'arbre B+, pas de coût de fragmentation. v4 suffit.
• Petites tables — la différence entre v4 et v7 est invisible en dessous de millions de lignes.
• Colonnes hors clé — si le GUID est juste un attribut stocké et pas une clé d'index, l'ordre est sans importance.
• GUIDs qui doivent être opaques — v7 fuite la milliseconde de génération, ce qui peut être indésirable dans des contextes sensibles à la sécurité.

Verdict : si un GUID est une clé primaire clusterisée sur une vraie base de données, utilisez v7. Sinon v4.

v8 : Défini par le vendeur

v8 est la porte de sortie : la RFC 9562 laisse le vendeur définir sa propre disposition de bits, tant que le nibble de version vaut 8 et que les bits de variante sont corrects. Tout le reste — largeur de l'horodatage, source d'aléa, encodage — est à la discrétion de l'implémenteur.

Vous ne verrez v8 que dans des systèmes qui ont conçu un schéma UUID personnalisé pour une raison spécifique (par exemple, intégrer un shard ID ou un node ID dans l'UUID pour le routage). Si vous ne construisez pas un tel système, v8 est hors de propos ; et si vous en construisez un, les règles sont celles de votre propre schéma, pas quoi que ce soit dans cet article.

Quelle version devriez-vous vraiment utiliser ?

Un guide de décision :

• « Générer des IDs pour un usage général ? » → v4. C'est la réponse dans 90 % des cas.
• « Clé primaire de base de données, ou besoin d'ordre temporel ? » → v7. Surtout pour les index clusterisés sur de grandes tables.
• « Besoin du même GUID pour la même entrée à chaque fois ? » → v5. Mapping déterministe depuis une chaîne.
• « Vous travaillez avec un système hérité qui attend du v1 ? » → v1 (gardez la compatibilité), mais planifiez une migration vers v7.
• « Quelqu'un m'a dit d'utiliser v3 ? » → Non. Utilisez v5 à la place (MD5 dans v3 est cassé).
• « Je veux la chose la plus récente. » → Ce n'est pas une raison. v7 est récent et résout un vrai problème (ordre en base) ; v6 est récent et surtout une aide de migration v1. Choisissez par cas d'usage, pas par nouveauté.

Si vous hésitez encore, utilisez v4. La valeur par défaut existe pour une raison.

Générer des GUID par version et langage

Langage / outil	v4 (défaut)	v5 (déterministe)	v7 (ordonné)
PowerShell	[guid]::NewGuid()	—	—
C# / .NET	Guid.NewGuid()	—	Guid.CreateVersion7() (.NET 9+)
Python	uuid.uuid4()	uuid.uuid5(uuid.NAMESPACE_URL, 'name')	uuid.uuid7() (3.14 beta) / lib
JavaScript	crypto.randomUUID()	—	(npm uuid v11+)
Node.js (lib uuid)	uuid.v4()	uuid.v5('name', NAMESPACE)	uuid.v7()
SQL Server	NEWID()	—	—
PostgreSQL	gen_random_uuid()	—	(extension)

Quelques notes : le support natif de v7 est encore en cours d'intégration dans les bibliothèques standard en 2026. Le paquet uuid de Node.js (v11+) et .NET 9 le livrent nativement ; Python ajoute uuid.uuid7() en 3.14 ; les runtimes plus anciens nécessitent une bibliothèque. Le support de v5 est quasi universel car c'est de la pure mathématique SHA-1 sans source d'entropie requise.

FAQ

v7 remplacera-t-il v4 comme valeur par défaut ?

Non. v4 reste le défaut général. v7 ne gagne que quand le GUID est une clé primaire ordonnée — pour la plupart des autres usages (jetons de session, IDs de requête, hashes de contenu, tout ce qui n'est pas en base) l'aléa de v4 n'est pas un inconvénient, et l'horodatage de tête de v7 ne ferait que fuiter de l'information de timing sans bénéfice.

v1 est-il encore sûr à utiliser ?

Non. v1 embarque l'adresse MAC de votre carte réseau, qui est une empreinte matérielle persistante. Microsoft lui-même a retiré v1 de la télémétrie Office après que des chercheurs eurent tracé des machines à travers des documents via des GUID intégrés. Pour le nouveau code, évitez v1 entièrement ; pour le v1 hérité, planifiez une migration vers v7.

Quelle est la différence entre v3 et v5 ?

Les deux sont des hashes de namespace déterministes (même entrée → même GUID). v3 utilise MD5, v5 utilise SHA-1. MD5 a des attaques par collision pratiques, donc v3 est considéré cassé pour des fins d'intégrité et a été déprécié au profit de v5. Il n'y a aucune raison de générer v3 aujourd'hui.

Puis-je convertir un GUID v4 en v7 ?

Non. La version n'est pas une étiquette qu'on peut permuter — chaque version utilise une logique de génération complètement différente. v4 n'a pas d'horodatage à extraire, donc la seule façon « d'obtenir un v7 » est d'en générer un nouveau. Si vous devez migrer une colonne de clé primaire v4 vers v7, vous ajoutez en réalité une nouvelle colonne et la réécrivez.

.NET supporte-t-il v7 nativement ?

Oui. Guid.CreateVersion7() a été ajouté dans .NET 9 (publié en novembre 2024). Si vous êtes sur .NET 8 ou antérieur, utilisez les paquets NuGet GenVault ou UUIDv7, ou mettez à niveau.

QuickGUID : générer v4 et v7, convertir tout format

Pour le travail GUID au quotidien, QuickGUID est une boîte à outils native Windows qui couvre tout le flux de travail :

• Génération par lots de v4 ou v7, jusqu'à 1 000 à la fois
• Conversion 10+ formats : standard, sans tirets, accolades, Base64, tableau d'octets C, macro DEFINE_GUID — tout avec aperçu en direct
• Extraction intelligente : collez des logs ou du code source, trouvez et convertissez automatiquement chaque GUID
• Décorateurs en direct : guillemets, préfixes/suffixes, casse — bascule globale et copie directe

Entièrement gratuit, 100% hors ligne.

Pour conclure

Le système de versions existe parce que différents travaux nécessitent différentes garanties : v4 vous donne de l'aléa intraçable, v5 vous donne de la reproductibilité, v7 vous donne de l'ordre. Par défaut v4, recourez à v7 sur les clés de base de données, et utilisez v5 quand des entrées identiques doivent produire des GUID identiques.

Nouveau avec les GUID ? Commencez par Qu'est-ce qu'un GUID ? pour les bases de la structure, du format à tirets, et pourquoi 128 bits suffisent à rendre les collisions négligeables en pratique.