UUID generator : tout comprendre sur les identifiants universels uniques
Qu'est-ce qu'un UUID et pourquoi l'utiliser ?
Un UUID (Universally Unique Identifier) est un identifiant de 128 bits standardisé par l'IETF. Son objectif est de fournir un identifiant unique sans nécessiter de coordination centrale entre les systèmes qui le génèrent. Contrairement aux identifiants auto-incrémentés classiques (1, 2, 3...), un UUID peut être créé indépendamment sur n'importe quel serveur, appareil ou navigateur, avec une probabilité de collision quasi nulle.
Les UUIDs sont omniprésents dans le développement logiciel moderne : clés primaires en base de données, identifiants de ressources dans les APIs REST, tokens de session, noms de fichiers temporaires, ou encore identifiants de corrélation dans les architectures microservices. Leur adoption massive s'explique par leur capacité à fonctionner dans des systèmes distribués sans point de synchronisation unique.
Les différentes versions d'UUID : v1, v4 et v7
La RFC 4122 (2005) définit cinq versions d'UUID, et la RFC 9562 (2024) en ajoute trois nouvelles. En pratique, trois versions dominent les usages courants.
Comparaison des versions UUID courantes
Source : RFC 4122 (IETF, 2005) et RFC 9562 (IETF, 2024)
UUID v1 combine un timestamp de 60 bits avec l'adresse MAC de la machine. Il garantit l'unicité mais expose des informations sur le matériel et l'heure de création. UUID v4 est entièrement aléatoire (122 bits d'entropie via un générateur cryptographique) et reste le plus utilisé aujourd'hui. UUID v7, introduit par la RFC 9562, intègre un timestamp Unix dans les 48 premiers bits : l'UUID est donc triable chronologiquement, ce qui le rend idéal comme clé primaire dans les bases de données relationnelles où l'ordre d'insertion importe pour les performances d'indexation.
UUID v4
122 bits
Aléatoire pur, non triable
UUID v7
48+74 bits
Triable par date, indexation optimale
Anatomie d'un UUID v4 : format et structure
Un UUID s'écrit sous la forme canonique xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, soit 36 caractères (32 chiffres hexadécimaux + 4 tirets). Le chiffre 4 en cinquième position du troisième groupe identifie la version. Le caractère y (8, 9, a ou b) encode la variante (RFC 4122).
Format : 8-4-4-4-12 caractères hexadécimaux = 128 bits = 16 octets
Exemple illustré : générer un UUID pour une base de données
Prenons le cas d'une application e-commerce qui utilise PostgreSQL et crée des commandes dans un système distribué.
crypto.randomUUID() ou gen_random_uuid() en SQL
550e8400-e29b-41d4-a716-446655440000 Type UUID natif PostgreSQL (16 octets, indexable)
INSERT INTO orders (id) VALUES ($1) L'UUID sert d'identifiant public dans l'URL REST
/api/orders/550e8400-e29b... 5,3 × 10³⁶
Nombre de combinaisons possibles pour un UUID v4 (122 bits d'entropie)
Probabilité de collision : peut-on avoir deux UUID identiques ?
La probabilité de collision suit le paradoxe des anniversaires. Pour un UUID v4 avec 122 bits d'entropie, la probabilité d'obtenir au moins une collision après avoir généré n UUIDs est approximativement :
P(collision) ≈ 1 - e^(-n² / 2 × 2¹²²)
En termes concrets : si vous générez 1 milliard d'UUIDs par seconde pendant 85 ans, la probabilité d'une seule collision serait d'environ 50 %. Pour une application générant 1 000 UUIDs par jour, le risque est si infime qu'il n'a aucune pertinence pratique. La fiabilité du matériel informatique (erreurs mémoire, pannes disque) représente un risque incomparablement plus élevé.
UUID comme clé primaire : avantages et inconvénients
Utiliser un UUID comme clé primaire en base de données présente des avantages majeurs dans les architectures distribuées : aucune coordination nécessaire entre les serveurs, possibilité de générer l'identifiant côté client avant même l'insertion, et absence de fuite d'information sur le volume de données (contrairement à un ID auto-incrémenté qui révèle le nombre total d'enregistrements).
En revanche, les UUIDs v4 aléatoires posent un problème de performance avec les index B-tree : les insertions dispersées provoquent des page splits fréquents. C'est précisément pourquoi UUID v7 a été conçu : en intégrant un timestamp, les valeurs sont naturellement ordonnées et les insertions deviennent séquentielles, préservant les performances d'indexation. Pour générer des hashs de vérification associés à vos identifiants, consultez notre générateur de hash SHA.
Bonne pratique
uuidv7() (extension pg_uuidv7) pour vos clés primaires. Vous obtenez l'unicité d'un UUID avec les performances d'insertion d'un identifiant séquentiel.Erreurs fréquentes à éviter
- Utiliser Math.random() pour générer un UUID. Cette fonction n'est pas cryptographiquement sûre et produit des valeurs prévisibles. Utilisez toujours
crypto.randomUUID()(Web Crypto API) ou un équivalent sécurisé côté serveur. - Stocker un UUID en VARCHAR(36) au lieu du type UUID natif. Le type natif occupe 16 octets contre 36 en texte, et bénéficie d'index optimisés. PostgreSQL, MySQL 8+ et SQL Server supportent le type UUID natif.
- Supposer que UUID v4 est triable. Les UUIDs v4 sont aléatoires et n'ont aucun ordre chronologique. Si vous avez besoin d'un tri par date de création, migrez vers UUID v7 ou ajoutez une colonne
created_at. - Utiliser un UUID comme token de sécurité. Bien qu'aléatoire, un UUID v4 n'a que 122 bits d'entropie. Pour un token de session ou un secret d'API, préférez 256 bits d'aléa via
crypto.getRandomValues(). Vérifiez l'intégrité de vos tokens avec notre générateur de hash. - Confondre UUID et ULID/KSUID. Ces formats alternatifs offrent des propriétés similaires à UUID v7 (triabilité, unicité) mais ne sont pas standardisés par l'IETF. Si la conformité RFC est requise, restez sur UUID v7.
Sources et références
- RFC 4122 (IETF, 2005) : A Universally Unique IDentifier (UUID) URN Namespace.
- RFC 9562 (IETF, 2024) : Universally Unique IDentifiers (UUIDs), incluant UUID v7.
- MDN Web Docs, crypto.randomUUID() : documentation de l'API Web Crypto.
- PostgreSQL Documentation, UUID Functions : fonctions UUID natives.