T
uuid ulid nanoid database distributed-systems backend

Guide de sélection des identifiants uniques (ID) modernes : Au-delà de l'UUID v4

Une analyse complète des UUID v1-v8, ULID, NanoID, CUID2 et Snowflake ID. Apprenez à choisir le bon identifiant unique pour votre base de datos, vos systèmes distribués et la sécurité des URL.

2026-04-11 Utiliser cet outil

Choisir le bon identifiant unique (ID) est l'une des décisions les plus critiques en architecture logicielle. Un ID mal choisi peut entraîner des goulots d'étranglement de performance, des vulnérabilités de sécurité ou des problèmes de synchronisation dans les systèmes distribués. Pendant longtemps, l'UUID v4 a été le choix par défaut. Cependant, avec l'évolution des systèmes distribués et des bases de données à grande échelle, les limites de l'UUID v4 (comme l'absence de triabilité et la fragmentation des index B-Tree) sont devenues flagrantes.

Dans ce guide, nous plongerons dans l'évolution des UUID, explorerons des alternatives modernes comme l'ULID et le NanoID, et fournirons un cadre pour sélectionner le meilleur ID selon votre cas d'utilisation.

1. L'évolution de l'UUID (du RFC 4122 au RFC 9562)

L'identifiant unique universel (UUID) est le standard de l'industrie depuis des décennies. Récemment, l'IETF a mis à jour le standard avec le RFC 9562, introduisant de nouvelles versions conçues pour les besoins des bases de données modernes.

UUID v1 : Basé sur le temps

L'UUID v1 combine l'horodatage actuel, une séquence d'horloge et l'adresse MAC du générateur.

  • Avantages : Unicité garantie dans l'espace et le temps.
  • Inconvénients : Problèmes de confidentialité (expose l'adresse MAC) et non-monotonie si généré sur différentes machines, ce qui nuit aux performances des index B-Tree.

UUID v3 & v5 : Basés sur le nom (MD5/SHA-1)

Ils sont déterministes. Un même nom dans un même namespace donnera toujours le même UUID.

  • UUID v3 : Utilise MD5.
  • UUID v5 : Utilise SHA-1 (préférable au v3).
  • Cas d'usage : Besoin d'IDs reproductibles basés sur des entrées uniques (ex: générer un ID à partir d'une URL).

UUID v4 : Aléatoire

La version la plus courante, composée de 122 bits aléatoires.

  • Avantages : Probabilité de collision extrêmement faible, aucune information sensible exposée.
  • Inconvénients : Totalement non triable. Utilisé comme clé primaire dans un index B-Tree (comme InnoDB de MySQL), il provoque une fragmentation massive de l'index, dégradant sévèrement les performances à mesure que la table grandit.

La nouvelle génération : UUID v6, v7 et v8

Le RFC 9562 a introduit ces versions pour résoudre le problème de tri de la v4 tout en gardant le format UUID.

UUID v7 : Le nouveau standard

L'UUID v7 est ordonné dans le temps. Il utilise un horodatage Unix de 48 bits (précision à la milliseconde) suivi de bits aléatoires.

  • Pourquoi c'est génial : Il est triable lexicographiquement. En tant que clé primaire, les nouveaux enregistrements sont ajoutés à la fin du B-Tree, minimisant les scissions de pages.
  • Recommandation : Pour presque tous les nouveaux projets, l'UUID v7 devrait remplacer l'UUID v4.

UUID v6

Essentiellement un UUID v1 réordonné pour être triable. À n'utiliser que si vous avez une dépendance héritée à la structure v1.

UUID v8

Permet une implémentation personnalisée tout en conservant la structure UUID. Utile pour les systèmes propriétaires nécessitant d'intégrer des métadonnées spécifiques.

2. Zoom sur les alternatives modernes

Bien que les UUID soient des standards, plusieurs alternatives ont gagné en popularité pour leurs avantages en lecture, longueur ou génération distribuée.

ULID (Universally Unique Lexicographically Sortable Identifier)

L'ULID est un concurrent sérieux de l'UUID v7.

  • Structure : Horodatage 48 bits + 80 bits d'aléatoire.
  • Encodage : Utilise le Base32 de Crockford (26 caractères au lieu de 36 pour un UUID).
  • Avantages : URL-safe, insensible à la casse, triable et visuellement plus court.
  • Inconvénients : Pas un format UUID standard (certaines bases de données anciennes ne le gèrent pas nativement).

NanoID : L'alternative petite et rapide

Souvent utilisé en front-end et applications web.

  • Avantages : Plus petit que l'UUID, alphabet personnalisable, plus rapide que l'UUID v4.
  • Sécurité : Utilise des générateurs aléatoires cryptographiquement forts.
  • Cas d'usage : Raccourcisseurs d'URL, IDs publics nécessitant des chaînes courtes et non devinables.

CUID2 : La nouvelle génération d'IDs sécurisés

Conçu pour la sécurité et le passage à l'échelle horizontale.

  • Caractéristiques : Haute résistance aux collisions, non séquentiel (évite les attaques par énumération).
  • Cas d'usage : Quand la sécurité et l'évolutivité importent plus que le tri temporel strict.

Snowflake ID : Le poids lourd distribué

Développé par Twitter, ce sont des entiers de 64 bits.

  • Structure : Horodatage + ID de worker + Séquence.
  • Avantages : Très rapide à générer, tient dans un BIGINT (64 bits), ordonné dans le temps.
  • Inconvénients : Nécessite une coordination de "Worker ID" pour éviter les collisions en cluster.

3. Table de comparaison

Fonction UUID v4 UUID v7 ULID NanoID Snowflake CUID2
Longueur 128 bits 128 bits 128 bits Variable 64 bits Variable
Triable Non Oui (Temps) Oui (Temps) Non Oui (Temps) Non
Format Hex Hex Base32 Alphanum Entier Alphanum
Collision Négligeable Négligeable Très faible Configurable Zéro (si coordonné) Très faible
Lisibilité Faible Faible Bonne Excellente Bonne Bonne
Type natif DB Oui Oui Non Non Oui (BIGINT) Non

4. Bonnes pratiques pour choisir un ID

Pour les clés primaires de base de données

  • Utilisez l'UUID v7 si votre base supporte les UUID 128 bits (PostgreSQL, MySQL moderne). C'est le meilleur compromis unicité/performance.
  • Utilisez le Snowflake ID pour les systèmes distribués massifs pour économiser de l'espace avec des entiers 64 bits.
  • Évitez l'UUID v4 pour les grandes tables ; l'insertion aléatoire détruira vos performances d'écriture.

Pour les URLs publiques

  • Utilisez NanoID ou SQID. Courts, sûrs pour les URLs et esthétiques.
  • Short UUIDs (UUIDs encodés en Base58/Base62) sont aussi une excellente option.

Pour les systèmes distribués (Microservices)

  • ULID ou KSUID sont excellents car ils ne nécessitent pas de coordinateur central (contrairement à Snowflake) tout en étant triables par le temps.

5. Exemples de code

Générer un UUID v7 en Node.js

const { v7: uuidv7 } = require('uuid');
console.log(uuidv7()); // ex: '018c3b7a-6b5d-7e8c-9a1b-2c3d4e5f6g7h'

Générer un ULID en Python

from ulid import ULID
ulid = ULID()
print(ulid) # ex: '01H6P7XG6WJ9S5H8K4M6N7B2P1'

6. FAQ : Pièges courants

Q : Puis-je convertir mes UUID v4 existants en UUID v7 ? R : Non, la structure des bits est différente. Vous pouvez cependant commencer à utiliser l'UUID v7 pour vos nouveaux enregistrements.

Q : Le NanoID est-il aussi sûr que l'UUID ? R : Oui, si la longueur et l'alphabet sont bien choisis. Un NanoID de 21 caractères a une probabilité de collision similaire à un UUID v4.

Q : Pourquoi ne pas simplement utiliser des entiers auto-incrémentés ? R : C'est parfait pour les petites bases. Mais cela expose votre volume de données (ex: user/5000 révèle que vous avez 5000 utilisateurs) et c'est difficile à gérer en distribué.

7. Conclusion

En 2026, il n'y a plus vraiment de raison d'utiliser l'UUID v4 pour des clés primaires. L'émergence de l'UUID v7 offre une solution standardisée et triable qui résout les problèmes de performance. Pour des besoins spécifiques, l'ULID offre une meilleure lisibilité et le Snowflake ID une efficacité maximale à grande échelle.

Retour au blog Générateur d'UUID →