Les UUID expliqués : v4, v7 et comment choisir la bonne version

Mis à jour : 28 septembre 2026

Un UUID est un identifiant de 128 bits que n’importe quel ordinateur peut créer seul, sans compteur central, avec la quasi-certitude que personne d’autre n’a produit le même. C’est pourquoi on les retrouve comme clés de base de données, noms de fichiers, identifiants de requête et numéros de commande. La plupart des UUID que vous croisez sont en version 4, purement aléatoire ; la version 7, normalisée en 2024, y ajoute l’instant de création et s’impose rapidement comme le meilleur choix pour les bases de données. Ce guide explique comment en lire un, en quoi les versions diffèrent, quel est le risque réel de collision, et laquelle choisir.

À quoi ressemble un UUID

Un UUID fait 128 bits, écrits sous la forme de 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets — 8, 4, 4, 4 et 12 chiffres, soit 36 caractères au total :

3f2a9c1e-5b7d-4e8a-9c21-7d4e5f6a8b90Un UUID de version 4.
01a0d86f-ca00-7b3e-9f21-6c4d8a0e5b17Un UUID de version 7.

La norme actuelle est la RFC 9562, publiée en mai 2024, qui a remplacé la RFC 4122 de 2005. Les lettres peuvent s’écrire en majuscules, en minuscules ou en mélangeant les deux ; les trois formes désignent la même valeur.

Les bases de données dotées d’un type UUID natif, comme PostgreSQL, stockent la valeur sur 16 octets plutôt que sous forme de 36 caractères de texte.

Lire la version

Deux chiffres indiquent à quel type d’UUID vous avez affaire. Le premier chiffre du troisième groupe est la version. Le premier chiffre du quatrième groupe est la variante : pour tout UUID conforme à la norme, il vaut 8, 9, a ou b.

UUID	Version	Nature
`3f2a9c1e-5b7d-4e8a-9c21-7d4e5f6a8b90`	4	Aléatoire
`01a0d86f-ca00-7b3e-9f21-6c4d8a0e5b17`	7	Ordonné dans le temps, créé le 25 septembre 2026 à 12:00:00 UTC
`00000000-0000-0000-0000-000000000000`	—	Le Nil UUID : tous les bits à 0, pour signifier « aucune valeur »
`ffffffff-ffff-ffff-ffff-ffffffffffff`	—	Le Max UUID : tous les bits à 1, utilisé comme borne supérieure

Les versions

Version	Mode de génération	Usage aujourd’hui
1	Horodatage et adresse réseau (MAC) de l’ordinateur	Ancienne ; elle révèle quelle machine a créé l’UUID
3	Empreinte MD5 d’un espace de noms et d’un nom	Uniquement pour reproduire des identifiants existants ; préférez la version 5
4	122 bits aléatoires	Le choix par défaut presque partout
5	Empreinte SHA-1 d’un espace de noms et d’un nom	Le même nom donne toujours le même UUID
6	La version 1 réordonnée pour se trier dans le temps	Uniquement là où la version 1 est déjà utilisée
7	Horodatage Unix en millisecondes, suivi de bits aléatoires	Les nouvelles bases de données et tout ce qui gagne à suivre l’ordre chronologique
8	Structure définie par l’application	Formats expérimentaux ou propres à un éditeur

La version 2 existe pour un ancien système de sécurité et sort du cadre de la norme. La RFC 9562 indique que les implémentations devraient utiliser la version 7 plutôt que les versions 1 et 6 lorsque c’est possible.

Version 4 : aléatoire

Un UUID de version 4 fixe 6 de ses 128 bits pour indiquer la version et la variante, et remplit les 122 autres de données aléatoires. La norme demande un générateur de nombres aléatoires cryptographiquement sûr, ce que les navigateurs fournissent avec crypto.randomUUID() — la fonction qu’utilise le générateur nTools.

Avec 122 bits aléatoires, les collisions ne posent pas de problème en pratique. La probabilité que deux UUID quelconques coïncident n’atteint 50 % qu’après environ 2,7 × 10¹⁸ UUID — à un milliard par seconde, il faudrait environ 86 ans pour y arriver. Après mille milliards d’UUID, la probabilité que deux d’entre eux soient identiques est d’environ 1 sur 10 000 milliards. Le risque réaliste, c’est un générateur de nombres aléatoires défaillant, pas les mathématiques.

Générateur UUID

Version 7 : triée dans le temps

Un UUID de version 7 place le temps Unix en millisecondes dans ses 48 premiers bits, puis la version et la variante, puis 74 bits aléatoires ou issus d’un compteur. Comme le temps vient en premier, les UUID créés plus tard se classent après les plus anciens, aussi bien sous forme de texte que d’octets.

Dans l’exemple ci-dessus, les 12 premiers chiffres hexadécimaux, 01a0d86fca00, correspondent à 1 790 337 600 000 millisecondes après le 1er janvier 1970 : le 25 septembre 2026 à 12:00:00 UTC. L’horodatage de 48 bits suffit jusqu’en l’an 10889. Au sein d’une même milliseconde, les générateurs utilisent soit des bits aléatoires, soit un compteur ajouté pour que les UUID d’un même processus sortent tout de même dans l’ordre.

La prise en charge arrive dans les outils du quotidien : PostgreSQL 18, sorti en septembre 2025, a ajouté une fonction intégrée uuidv7() aux côtés de uuidv4().

Laquelle utiliser comme clé de base de données

La plupart des bases de données conservent les clés primaires dans un index B-tree (arbre B), qui reste efficace lorsque les nouvelles clés arrivent dans l’ordre.

Les clés en version 4 atterrissent à des endroits aléatoires de l’index. Sur de petites tables, cela n’a pas d’importance ; sur de grandes, chaque insertion touche une partie différente de l’index, ce qui entraîne davantage de divisions de pages, davantage de défauts de cache et des index plus volumineux.
Les clés en version 7 arrivent dans l’ordre chronologique : les nouvelles lignes s’ajoutent donc près de la fin de l’index, un peu comme avec un numéro auto-incrémenté — tout en pouvant être créées n’importe où, sans demander la valeur suivante à la base de données.
Les entiers auto-incrémentés sont plus compacts et les plus rapides, mais ils nécessitent un compteur central unique et révèlent combien d’enregistrements existent et dans quel ordre ils ont été créés.

Pour une nouvelle table qui a besoin d’UUID, la version 7 est généralement le meilleur choix. La version 4 reste la bonne option lorsque l’instant de création ne doit pas pouvoir se déduire de l’identifiant.

Ce qu’un UUID n’est pas

Pas un secret. Un UUID de version 7 révèle à quiconque le lit quand il a été créé, à la milliseconde près. Un UUID de version 4 est difficile à deviner, mais les identifiants finissent dans des journaux, sont partagés dans des URL et s’affichent dans des interfaces. Les liens de réinitialisation de mot de passe ou d’accès à des fichiers privés devraient utiliser un jeton aléatoire dédié, et non l’identifiant de l’enregistrement.
Pas une source d’information. La norme recommande de traiter les UUID comme des valeurs opaques : stockez-les et comparez-les, mais ne bâtissez pas de logique qui repose sur la lecture de leurs différentes parties.
Pas toujours en version 4. Un code qui attend de l’aléatoire ne devrait pas le supposer ; vérifiez le chiffre de version lorsque cela compte.

Questions fréquentes

Deux UUID aléatoires peuvent-ils être identiques ?

En théorie, oui ; en pratique, non. Il faudrait environ 2,7 × 10¹⁸ UUID de version 4 pour avoir 50 % de chances d’obtenir une seule coïncidence, à condition qu’ils proviennent d’un véritable générateur de nombres aléatoires.

Un GUID est-il la même chose qu’un UUID ?

Oui. GUID est le nom que Microsoft donne au même identifiant de 128 bits. Les outils Windows l’affichent souvent en majuscules ou entre accolades, comme {3F2A9C1E-5B7D-4E8A-9C21-7D4E5F6A8B90}, mais la valeur est la même.

Les UUID sont-ils sensibles à la casse ?

Non. 3F2A9C1E-… et 3f2a9c1e-… sont le même UUID. Comparez-les sans tenir compte de la casse, ou stockez-les dans une colonne de type UUID natif, ce qui règle la question.

Quelle version le générateur nTools crée-t-il ?

La version 4, grâce à la fonction crypto.randomUUID() du navigateur. Il en crée jusqu’à 100 à la fois, entièrement sur votre appareil.