Qu’est-ce qu’un UUID ? Le guide complet : format, versions et cas d’utilisation

Chaque fois que vous vous inscrivez à un service, un identifiant unique est créé pour votre compte. Chaque requête API porte un ID de traçage. Chaque ligne d’une base de données distribuée a besoin d’une clé primaire qui ne collisionnera pas avec les clés générées sur d’autres machines. La solution derrière tout cela ? UUID — Universally Unique Identifier (Identifiant Universellement Unique).

Ce guide explique ce que sont les UUID, comment ils sont structurés, ce que fait chaque version en coulisses, et quand les utiliser (ou les éviter).

UUID en un coup d’œil

Un UUID est un identifiant de 128 bits (16 octets) conçu pour être globalement unique sans nécessiter d’autorité centrale. Il s’écrit en 32 chiffres hexadécimaux au format canonique 8-4-4-4-12 :

550e8400-e29b-41d4-a716-446655440000
|------| |--| |--| |--| |----------|
 8 hex   4    4    4      12 hex

Soit 32 caractères hexadécimaux + 4 tirets = 36 caractères au total. Les tirets sont purement esthétiques — ils ne portent aucune donnée.

Faits clés :

128 bits = 2¹²⁸ ≈ 3,4 × 10³⁸ valeurs possibles
Standardisé par RFC 9562 (mai 2024, remplace RFC 4122)
Également appelé GUID (Globally Unique Identifier) dans l’écosystème Microsoft — même format, nom différent
Supporté nativement par PostgreSQL (type uuid), MySQL (BINARY(16) ou CHAR(36)) et pratiquement tous les langages de programmation

Anatomie d’un UUID

Chaque UUID encode deux champs de métadonnées à des positions de bits fixes, quelle que soit la version :

550e8400-e29b-41d4-a716-446655440000
                  ^  ^
                  |  |
         Version -┘  └- Variante

Champ de version (Bits 48–51)

Le 13e chiffre hexadécimal (premier chiffre du troisième groupe) identifie la version de l’UUID :

Chiffre hex	Version	Méthode
`1`	v1	Horodatage + adresse MAC
`3`	v3	Hachage MD5 de namespace + nom
`4`	v4	Aléatoire cryptographique
`5`	v5	Hachage SHA-1 de namespace + nom
`6`	v6	Horodatage réordonné (RFC 9562)
`7`	v7	Horodatage Unix + aléatoire (RFC 9562)
`8`	v8	Personnalisé / spécifique à l’implémentation

Champ de variante (Bits 64–65)

Le 17e chiffre hexadécimal (premier chiffre du quatrième groupe) identifie la variante. Pour les UUID RFC 4122/9562, les premiers bits sont 10, ce qui signifie que ce chiffre est toujours 8, 9, a ou b.

Exemple d’analyse

550e8400-e29b-41d4-a716-446655440000
              ↑         ↑
              4 → v4    a → variante RFC 4122

Ceci est un UUID v4 (aléatoire), variante RFC 4122/9562.

Les versions UUID expliquées

Version 1 : Horodatage + adresse MAC

UUID v1 était le design original. Il encode :

Horodatage de 60 bits — intervalles de 100 nanosecondes depuis le 15 octobre 1582 (la réforme du calendrier grégorien)
Séquence d’horloge de 14 bits — compteur de monotonie pour éviter les doublons en cas de retour d’horloge
Nœud de 48 bits — typiquement l’adresse MAC de la machine

|        Horodatage         | Ver |  Horl  |Var|    Nœud (MAC)     |
| 60 bits                   | 4b  | 14b    |2b | 48 bits           |

Problèmes :

Expose l’heure de génération et l’identité matérielle (risque de confidentialité)
Les adresses MAC peuvent être usurpées, compromettant l’unicité
L’époque de 1582 est déroutante et nécessite une conversion

Verdict : Déprécié par RFC 9562. Utilisez v7 à la place pour les UUID basés sur le temps.

Version 3 : Basée sur un nom MD5 (Déterministe)

UUID v3 hache un UUID de namespace et une chaîne de nom en utilisant MD5. Les mêmes entrées produisent toujours le même UUID.

import uuid
# namespace = DNS, nom = "example.com"
print(uuid.uuid3(uuid.NAMESPACE_DNS, "example.com"))
# → "9073926b-929f-31c2-abc9-fad77ae3e8eb"  (toujours cette valeur)

Quatre namespaces standard sont définis :

DNS : 6ba7b810-9dad-11d1-80b4-00c04fd430c8
URL : 6ba7b811-9dad-11d1-80b4-00c04fd430c8
OID : 6ba7b812-9dad-11d1-80b4-00c04fd430c8
X.500 : 6ba7b814-9dad-11d1-80b4-00c04fd430c8

Verdict : Fonctionnel mais préférez v5 — SHA-1 est plus robuste que MD5.

Version 4 : Aléatoire — La plus populaire

UUID v4 remplit 122 bits avec des données aléatoires cryptographiquement sécurisées (les 6 bits restants sont réservés aux champs de version et de variante).

|           Aléatoire       | Ver |    Aléatoire  |Var|    Aléatoire    |
| 48 bits                   | 4b  | 12 bits       |2b | 62 bits         |

Avec 2¹²² ≈ 5,3 × 10³⁶ valeurs possibles, la probabilité de collision est astronomiquement faible. Pour atteindre une chance de 50 % d’au moins une collision, il faudrait environ 2,71 × 10¹⁸ UUID — soit 2,71 trillions.

// Tous les navigateurs modernes et Node.js supportent ceci
const id = crypto.randomUUID();
console.log(id); // → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

Forces : simple, privé, universellement supporté, aucune coordination nécessaire.

Faiblesse : la distribution aléatoire cause la fragmentation des index B-tree quand utilisé comme clé primaire de base de données. Pour les cas intensifs en base de données, considérez v7.

Version 5 : Basée sur un nom SHA-1 (Déterministe)

Identique à v3 mais utilise SHA-1 au lieu de MD5. Les mêmes entrées produisent toujours le même UUID.

import uuid
print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com"))
# → "cfbff0d1-9375-5685-968c-48ce8b15ae17"  (toujours cette valeur)

Cas d’utilisation :

Générer des identifiants stables à partir d’URL ou de noms DNS
Clés de stockage adressable par contenu
Données de test reproductibles

Important : v3 et v5 ne sont PAS conçus pour la sécurité. Ils sont déterministes — quiconque connaît le namespace et le nom peut reproduire l’UUID.

Version 7 : Horodatage Unix + aléatoire (Recommandée pour les nouveaux projets)

UUID v7 est la version la plus récente, introduite dans RFC 9562 (mai 2024). Il encode :

Horodatage Unix de 48 bits en millisecondes — monotonement croissant
74 bits d’aléatoire cryptographique

|   Horodatage Unix (ms)    | Ver |  rand_a  |Var|     rand_b       |
| 48 bits                   | 4b  | 12 bits  |2b | 62 bits          |

Cela signifie que les UUID v7 sont naturellement triés par date de création — les UUID plus récents sont toujours lexicographiquement supérieurs aux plus anciens. Cette propriété les rend idéaux comme clés primaires de base de données, où les index B-tree restent séquentiels au lieu de se fragmenter aléatoirement.

import { v7 as uuidv7 } from "uuid";

const id1 = uuidv7(); // généré à T₁
const id2 = uuidv7(); // généré à T₂ (T₂ > T₁)
console.log(id1 < id2); // → true (comparaison lexicographique)

Pourquoi c’est important pour les bases de données : la propriété séquentielle de v7 réduit les divisions de pages d’index jusqu’à 90 % par rapport à v4, résultant en des insertions plus rapides, des index plus petits et de meilleures performances de cache.

UUID vs GUID — Quelle différence ?

Il n’y a aucune différence fonctionnelle. GUID (Globally Unique Identifier) est le nom que Microsoft donne aux UUID, utilisé dans Windows, .NET, COM et SQL Server. Le format est identique : 128 bits, 8-4-4-4-12 en hexadécimal.

La seule différence cosmétique : les outils Microsoft affichent parfois les GUID en majuscules avec des accolades :

UUID : 550e8400-e29b-41d4-a716-446655440000
GUID : {550E8400-E29B-41D4-A716-446655440000}

Si quelqu’un demande la « différence entre UUID et GUID », la réponse est : le nom commercial.

Valeurs UUID spéciales

RFC 9562 définit deux UUID spéciaux :

Nom	Valeur	Usage
UUID nil	`00000000-0000-0000-0000-000000000000`	Représente l’absence de valeur (comme `null`)
UUID max	`ffffffff-ffff-ffff-ffff-ffffffffffff`	Marqueur de limite ou valeur sentinelle

Ne les utilisez jamais comme identifiants réels — ils ne sont pas uniques par définition.

Probabilité de collision : Le problème des anniversaires

Le « problème des anniversaires » calcule combien d’UUID sont nécessaires avant qu’une collision devienne probable. Pour UUID v4 (122 bits aléatoires) :

UUID générés	Probabilité de collision
1 million	~10⁻²² (virtuellement impossible)
1 milliard	~10⁻¹⁶ (toujours négligeable)
2,71 × 10¹⁸	50 % (la « borne des anniversaires »)

Pour mettre en contexte : si vous génériez 1 milliard d’UUID par seconde, il faudrait 86 ans pour atteindre une probabilité de 50 % d’une seule collision. En pratique, les pannes matérielles, les bugs logiciels et les rayons cosmiques ont tous plus de chances de causer un doublon que les mathématiques de UUID v4.

La formule : p(n) ≈ n² / (2 × 2¹²²)

Comment valider un UUID

Un UUID valide correspond à ce motif regex (insensible à la casse) :

^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Cela vérifie :

Le format hexadécimal 8-4-4-4-12
Le chiffre de version est 1–7 (position 15)
Le quartet de variante commence par 8, 9, a ou b (position 20)

function isValidUUID(str) {
  return /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(str);
}

isValidUUID("550e8400-e29b-41d4-a716-446655440000"); // → true
isValidUUID("not-a-uuid"); // → false

Générer des UUID dans chaque langage

JavaScript / TypeScript

// Navigateur et Node.js — v4 intégré
crypto.randomUUID();

// Package npm uuid — supporte v1, v3, v4, v5, v7
import { v4, v7 } from "uuid";
v4(); // aléatoire
v7(); // ordonné par le temps

Python

import uuid

uuid.uuid4()                                    # aléatoire
uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")   # déterministe
# uuid.uuid7() prévu pour Python 3.14+

Go

import "github.com/google/uuid"

uuid.New()              // v4 aléatoire
uuid.Must(uuid.NewV7()) // v7 ordonné par le temps

Java

import java.util.UUID;

UUID.randomUUID();        // v4 aléatoire
// UUID v7 : utilisez com.fasterxml.uuid ou java.util.UUID dans JDK 21+

SQL (PostgreSQL)

-- v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- v7 (PostgreSQL 18+)
SELECT uuidv7();

Cas d’utilisation courants

Clés primaires de base de données

Les UUID permettent de générer des identifiants n’importe où — dans l’application, côté client, en périphérie — sans aller-retour vers la base de données. Cela permet les architectures offline-first et simplifie les systèmes distribués. Utilisez v7 pour les meilleures performances d’index, ou v4 si l’ordre n’a pas d’importance.

Traçage de requêtes API

Assignez un UUID à chaque requête API au point d’entrée (passerelle, répartiteur de charge). Transmettez-le à tous les services en aval via un en-tête comme X-Request-ID. Cela rend la corrélation des logs entre microservices triviale.

Clés d’idempotence

Les API utilisent les UUID comme clés d’idempotence pour garantir que les requêtes rejouées ne créent pas de ressources dupliquées. Le client génère un UUID avant la première tentative et envoie le même UUID lors des réessais.

Identifiants de session

Les UUID fournissent une unicité suffisante pour prévenir les collisions de sessions sur de grandes bases d’utilisateurs. Contrairement aux entiers auto-incrémentés, ils ne peuvent pas être énumérés — un attaquant ne peut pas deviner les identifiants de session valides en incrémentant un nombre.

Stockage adressable par contenu

UUID v5 génère des identifiants déterministes à partir du contenu. Pour une même entrée, vous obtenez toujours le même UUID — utile pour la déduplication, la mise en cache et les builds reproductibles.

Considérations de sécurité

Les UUID ne sont PAS des jetons de sécurité

Les UUID sont conçus pour l’unicité, pas pour le secret. Problèmes clés :

UUID v1 expose l’horodatage de génération et l’adresse MAC
UUID v4 a 122 bits d’aléatoire mais une structure prévisible (les bits de version/variante sont fixes)
UUID v3/v5 sont déterministes — quiconque connaît le namespace et le nom peut reproduire l’UUID

Pour les jetons de sécurité, clés API ou secrets de session, utilisez un CSPRNG dédié avec 128+ bits d’aléatoire pur :

// Pour les jetons de sécurité — PAS un UUID, mais entièrement aléatoire
const token = Array.from(crypto.getRandomValues(new Uint8Array(32)))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

UUID v7 expose l’heure de création

Les 48 premiers bits d’un UUID v7 encodent l’horodatage de création en millisecondes. Quiconque reçoit un UUID v7 peut extraire quand il a été créé :

const hex = "01906b5e-4a3e-7234-8f56-b8c12d4e5678".replace(/-/g, "").slice(0, 12);
new Date(parseInt(hex, 16));
// → 2024-07-01T12:34:56.000Z

Si l’heure de création est une information sensible, utilisez v4 à la place.

N’utilisez pas les UUID pour empêcher l’énumération

Bien que les UUID soient plus difficiles à deviner que les entiers séquentiels, ils ne devraient pas être votre seul mécanisme de contrôle d’accès. Appliquez toujours des vérifications d’autorisation — ne vous fiez pas à l’obscurité des URL.

Questions fréquentes

Pourquoi y a-t-il des tirets dans les UUID ?

Les tirets dans le format 8-4-4-4-12 sont purement pour la lisibilité humaine. Ils ne portent aucune donnée et sont ignorés lors de l’analyse. Certains systèmes stockent les UUID sans tirets (32 caractères hexadécimaux), ce qui est tout aussi valide.

Deux UUID peuvent-ils être identiques ?

Théoriquement oui, pratiquement non. Pour UUID v4 avec 122 bits aléatoires, la probabilité de générer deux UUID identiques est d’environ 1 sur 5,3 × 10³⁶ pour toute paire donnée. Aux taux de génération réels, vous avez plus de chances d’être frappé par la foudre en gagnant au loto que de rencontrer une collision d’UUID.

Les UUID sont-ils séquentiels ?

Seulement certaines versions. UUID v1, v6 et v7 contiennent des horodatages et se trient chronologiquement. UUID v4 est entièrement aléatoire sans ordre. UUID v3 et v5 sont déterministes mais non ordonnés.

Combien de stockage utilise un UUID ?

Binaire : 16 octets (128 bits) — le stockage le plus efficace
Chaîne (avec tirets) : 36 octets (ASCII)
Chaîne (sans tirets) : 32 octets (ASCII)

La plupart des bases de données stockent les UUID en format binaire en interne. Le type natif uuid de PostgreSQL utilise exactement 16 octets.

Faut-il utiliser UUID ou auto-incrément pour les clés primaires ?

L’auto-incrément est plus simple pour les applications à base de données unique (plus petit, plus rapide, séquentiel). UUID est meilleur pour les systèmes distribués (génération partout, pas de coordination, fusion sans conflit). Si vous utilisez UUID, préférez v7 pour les meilleures performances en base de données.

Qu’est-ce que RFC 9562 ?

RFC 9562, publié en mai 2024, est le dernier standard UUID. Il remplace RFC 4122 et introduit formellement les versions UUID 6, 7 et 8. Il déprécie v1 en faveur de v6/v7 et définit les valeurs UUID nil et max. Si vous implémentez la génération ou la validation d’UUID, RFC 9562 est la référence faisant autorité.

Peut-on utiliser les UUID entre différents langages de programmation ?

Oui. Le format UUID (128 bits, 8-4-4-4-12 en hexadécimal) est indépendant du langage. Un UUID généré en JavaScript sera correctement analysé en Python, Go, Java ou tout autre langage supportant les UUID. Cette interopérabilité est l’un des plus grands atouts des UUID.

Générez, décodez et validez des UUID instantanément avec notre Générateur UUID — supporte v1, v4, v5 et v7 avec génération par lots, 100 % dans votre navigateur.