Guide des UUID : v4 ou v7, et les UUID comme clés primaires
Des chaînes comme 550e8400-e29b-41d4-a716-446655440000 identifient partout des commandes, des fichiers et des requêtes d'API. Découvrez comment les UUID sont générés et quelle version choisir.
Qu'est-ce qu'un UUID ?
Un UUID (Universally Unique Identifier) est un identifiant de 128 bits qui permet à chacun de créer des identifiants sans risque de conflit, sans interroger un serveur central. Microsoft l'appelle GUID. La norme actuelle est la RFC 9562, publiée en 2024.
Il s'écrit sous la forme de 32 chiffres hexadécimaux séparés par des tirets en groupes 8-4-4-4-12, soit 36 caractères au total. Le premier chiffre du troisième groupe indique la version : xxxxxxxx-xxxx-4xxx-... est une v4 et 7xxx une v7.
Les versions en un coup d'œil
Aujourd'hui, on choisit généralement la v4 pour un usage courant et la v7 lorsque l'ordre et les performances d'insertion comptent, comme pour les clés primaires de base de données.
- v1 : combine un horodatage et l'adresse MAC de la machine. Triée dans le temps, mais peut divulguer des informations matérielles.
- v3 et v5 : hachent un espace de noms et un nom, si bien qu'une même entrée donne toujours le même UUID (v3 utilise MD5, v5 SHA-1).
- v4 : 122 bits aléatoires. La plus répandue et la plus simple à implémenter.
- v7 : un horodatage Unix de 48 bits en millisecondes suivi de bits aléatoires. Se trie dans l'ordre de création.
Les UUID peuvent-ils vraiment ne jamais entrer en collision ?
La partie aléatoire d'un UUID v4 fait 122 bits, soit environ 5,3 × 10^36 valeurs possibles. D'après le paradoxe des anniversaires, il faudrait environ 2,7 × 10^18 UUID pour avoir 50 % de chances d'obtenir un seul doublon — environ un milliard par seconde pendant 85 ans. En pratique, les collisions n'arrivent pas.
Cela ne vaut que si les nombres aléatoires sont vraiment aléatoires. Des doublons ont été signalés après le clonage de machines virtuelles avec un état de générateur aléatoire identique, ou avec des implémentations maison utilisant des fonctions aléatoires prévisibles. Utilisez la fonction UUID standard de votre plateforme.
Les UUID comme clés primaires
Les clés UUID peuvent être générées sur plusieurs serveurs à la fois et ne révèlent pas le nombre d'enregistrements. Avec des entiers auto-incrémentés, une URL comme /orders/1052 permet à un concurrent d'estimer votre volume de commandes.
Les contreparties sont la taille et l'ordre. Un UUID occupe 16 octets, deux fois un entier de 8 octets, et davantage s'il est stocké sous forme de chaîne de 36 caractères. Comme la v4 est entièrement aléatoire, les nouvelles lignes atterrissent n'importe où dans un index B-tree, ce qui provoque de fréquentes divisions de pages et ralentit les écritures. La v7, croissante dans le temps, évite largement ce problème.
- PostgreSQL : utilisez le type natif uuid (16 octets).
- MySQL : stockez en BINARY(16) ; les versions 8.0 et ultérieures proposent UUID_TO_BIN.
- SQL Server : utilisez le type uniqueidentifier.
Quand ne pas utiliser un UUID comme secret
Un UUID est conçu pour être un nom unique, pas un secret impossible à deviner. Les v1 et v7 contiennent un horodatage, donc certains bits sont prévisibles. Les valeurs sensibles comme les jetons de réinitialisation de mot de passe et les secrets d'API doivent être générées à partir de suffisamment d'octets aléatoires cryptographiquement sûrs.
Générez autant d'UUID que nécessaire avec le générateur d'UUID d'AIBIZAP, et utilisez le générateur d'identifiants client pour les secrets. Si vous concevez des tables à partir d'exemples JSON, le générateur de DDL JSON est un bon complément.