Les UUIDs sont le premier outil auquel la plupart des développeurs backend pensent pour un identifiant unique indépendant d'une séquence de base. Ils sont intégrés à quasi tous les langages, sont présentables dans une URL, et fonctionnent sans coordination entre services. Mais la spécification UUID définit plusieurs versions avec des compromis différents, et choisir la bonne compte pour les gros systèmes.

Ce qu'est un UUID

Un UUID (Universally Unique Identifier, aussi appelé GUID sur Windows) est une valeur 128 bits, écrite typiquement en 32 chiffres hex groupés 8-4-4-4-12. Les quatre caractères hex des positions 13–16 encodent la version (1 à 7) ; le premier caractère du groupe 17–20 encode la variante. Le reste est de la donnée dont le sens dépend de la version.

Version 1 : temps et MAC

v1 encode l'horodatage courant (intervalles de 100 ns depuis le 15 octobre 1582) plus l'adresse MAC de la machine plus une séquence d'horloge. Unique garanti sans coordination — mais fuit quand et où l'ID a été généré, généralement indésirable. Beaucoup de bases d'entreprise en produisent encore par habitude.

Version 4 : purement aléatoire

v4 remplit 122 des 128 bits avec des données d'un RNG cryptographique. Les 6 autres bits sont fixes pour l'identifier comme v4. C'est le défaut des systèmes modernes car il ne révèle rien, est simple à générer (une ligne si crypto.randomUUID est disponible) et a une probabilité de collision si faible qu'elle n'a aucune importance pratique.

Version 7 : ordonnée par le temps

v7 est plus récente (RFC 9562, publiée en 2024). Commence par un horodatage à la milliseconde et remplit le reste d'aléa. Le résultat est monotone triable — utile en clé primaire de base car v4 fragmente les index de façon catastrophique, tandis que v7 garde les insertions groupées. Si votre librairie le supporte, préférez v7 à v4 pour les clés primaires ; v4 uniquement quand vous voulez masquer la date de création.

Probabilité de collision

Pour v4, l'espace est 2^122 — environ 5 × 10^36. Générer un milliard d'UUIDs par seconde pendant 85 ans donne encore une probabilité négligeable de collision. En pratique, les collisions v4 viennent de mauvais RNGs, pas de l'épuisement de l'espace. Utilisez toujours crypto.randomUUID ou crypto.getRandomValues, jamais Math.random.

UUID vs auto-increment

Les IDs auto-incrémentés sont plus petits (8 octets contre 16), naturellement triés, rapides à indexer — mais fuient des données métier (« combien de commandes cette entreprise traite-t-elle par jour »), demandent une coordination en systèmes distribués et rendent les merges entre bases pénibles. Les UUIDs sont l'inverse : opaques, sans coordination, volumineux. Utilisez auto-increment pour les tables internes où aucun ID ne sort de la base. Utilisez UUIDs pour tout ce qui est visible par l'utilisateur ou échangé entre services.

Notes de stockage

Stockez toujours les UUIDs en type binaire natif si la base le supporte (UUID en Postgres, BINARY(16) en MySQL). Les stocker en VARCHAR(36) double l'espace et ralentit chaque lookup d'index de 2 à 3 fois. La forme hex avec tirets est uniquement pour l'affichage.