Pourquoi le choix d'un identifiant compte
Un identifiant semble anodin jusqu'au jour où il devient une contrainte d'architecture. Dans une petite application, un entier auto-incrémenté suffit souvent. Mais dès que plusieurs services créent des données, que des événements circulent entre systèmes, ou que des objets doivent être générés hors ligne, un identifiant global devient beaucoup plus pratique.
Les UUID répondent à ce besoin : ils peuvent être créés sans coordination centrale et restent extrêmement peu susceptibles d'entrer en collision. Le débat actuel n'est donc plus seulement "UUID ou entier", mais plutôt "quelle version d'UUID pour quel usage".
Vous pouvez générer et valider des identifiants avec notre générateur UUID v4/v7, directement dans le navigateur.
UUID v4 : aléatoire, simple et robuste
UUID v4 est la version la plus connue. Il repose sur l'aléatoire : 122 bits utiles sont générés au hasard, le reste encode la version et la variante. Avec un générateur cryptographiquement sûr, la probabilité de collision est négligeable pour les volumes courants, même très importants.
Ses avantages sont clairs : il ne révèle pas l'heure de création, ne dépend pas d'une machine précise, et fonctionne très bien pour les identifiants publics, les tokens non sensibles, les clés d'idempotence et les objets créés par plusieurs services. Son principal défaut apparaît dans les bases de données relationnelles : les valeurs aléatoires dispersent les insertions dans les index B-tree.
Le problème des index avec UUID v4
Dans une table MySQL, PostgreSQL ou SQL Server, un index primaire aime les valeurs ordonnées. Avec un entier auto-incrémenté, les nouvelles lignes s'ajoutent naturellement à la fin de l'index. Avec UUID v4, chaque nouvelle ligne peut tomber n'importe où. Cela provoque plus de pages modifiées, plus de fragmentation et parfois une baisse de performance sur les gros volumes d'écriture.
Ce problème ne rend pas UUID v4 inutilisable. Beaucoup de systèmes l'emploient sans difficulté. Mais si votre table reçoit des millions d'insertions et que l'UUID est la clé primaire clusterisée, vous devez mesurer l'impact et envisager une version ordonnée.
UUID v7 : triable par date
UUID v7, standardisé dans la RFC 9562, combine un timestamp Unix en millisecondes avec une partie aléatoire. Le début de l'identifiant reflète donc l'ordre temporel, tandis que la fin conserve suffisamment d'aléa pour éviter les collisions. Résultat : les UUID v7 se trient naturellement par date de création.
Cette propriété est très utile pour les bases de données et les systèmes d'événements. Les insertions sont plus localisées dans les index, les exports restent approximativement chronologiques, et les logs sont plus faciles à lire. Contrairement à UUID v1, UUID v7 n'expose pas d'adresse MAC.
Quand choisir v4 ou v7 ?
- Choisissez UUID v4 pour les identifiants publics où l'ordre de création ne doit pas être devinable.
- Choisissez UUID v7 pour les tables à forte écriture, les événements, les jobs, les traces et les objets que vous consultez souvent par date.
- Évitez UUID v1 pour les données exposées publiquement, car il peut révéler des informations temporelles et historiques.
- Évaluez ULID si vous voulez un format compact et triable en Base32, mais vérifiez la compatibilité de vos bibliothèques.
Stockage : texte ou binaire ?
Un UUID affiché sous forme texte occupe 36 caractères avec les tirets. En binaire, il occupe 16 octets. Sur une petite table, la différence est négligeable. Sur des dizaines ou centaines de millions de lignes, elle devient importante : taille des index, mémoire, cache disque et bande passante interne.
Lorsque votre base de données le permet, stockez les UUID dans un type natif (uuid dans PostgreSQL) ou en binaire. Gardez l'affichage texte pour les APIs, logs et interfaces d'administration. Cette séparation évite de payer le coût du format humain dans tous les index.
Bonnes pratiques
- Générez les UUID avec une API cryptographique fiable, comme
crypto.getRandomValues()côté navigateur ou la bibliothèque standard côté serveur. - Ne tronquez pas un UUID pour le rendre plus court sans recalculer le risque de collision.
- Ne mettez pas de signification métier dans l'identifiant : gardez les données métier dans des colonnes séparées.
- Mesurez les performances avec vos vraies charges plutôt que de choisir uniquement sur une règle générale.
À retenir
UUID v4 reste un excellent choix général : simple, robuste et très bien supporté. UUID v7 est souvent préférable pour les nouvelles applications orientées événements ou les tables à fort volume, car il conserve l'unicité globale tout en améliorant le comportement des index. Le bon choix dépend surtout de votre besoin de confidentialité temporelle, de tri chronologique et de performance en base.