Appeler une fonction “generate UUID” semble être une décision complète. Pourtant, la version choisie influence confidentialité, tri, performance d’index, compatibilité et reproductibilité. Un identifiant n’est pas seulement un format visuel. Il porte des propriétés. Les comprendre évite de découvrir trop tard qu’un ID public révèle le temps de création ou que la base souffre d’insertions trop dispersées.
Version 4 est le choix aléatoire classique
UUID v4 utilise principalement des bits aléatoires. Il est largement supporté, ne révèle pas l’heure de création et convient aux producteurs distribués. Pour des IDs publics sans besoin d’ordre, c’est souvent un bon défaut.
Son coût potentiel se trouve dans les index. Les valeurs aléatoires s’insèrent partout dans un index ordonné. Sur un fort volume d’écriture, cela peut augmenter fragmentation et I/O. La réponse dépend du moteur et du workload.
Les versions ordonnées par temps améliorent la localité
UUID v1 ordonne en partie par temps, mais peut exposer des informations de nœud. Des versions modernes comme v7 placent un timestamp dans une structure plus adaptée et ajoutent du hasard. Elles améliorent le tri approximatif et les insertions en base.
Ce tri ne doit pas remplacer une vraie chronologie. Les horloges peuvent dériver et plusieurs générateurs peuvent produire des valeurs proches. Les timestamps métier restent nécessaires.
Les versions basées sur un nom sont déterministes
UUID v3 et v5 dérivent l’ID d’un namespace et d’un nom. Le même input produit le même résultat. C’est utile lorsque plusieurs systèmes doivent obtenir le même identifiant sans lookup central.
Le nom doit être normalisé avec soin. Casse, espaces et encodage changent le résultat. La confidentialité doit aussi être évaluée, car le déterminisme peut révéler des relations entre enregistrements.
N’inventez pas une version privée
Un string qui ressemble à un UUID mais suit des règles internes trompe les outils. Les validateurs, bibliothèques et opérateurs ne savent plus quelles propriétés il garantit. Si un autre schéma convient mieux, il vaut mieux le nommer clairement.
Utilisez des bibliothèques maintenues et testez version bits, variant bits et collisions attendues. Un générateur faible peut répéter des valeurs dans des environnements clonés.
La politique d’acceptation doit être écrite
Un service peut générer v7, accepter v4 legacy et refuser d’autres versions. Un autre peut accepter tout UUID standard. Ces décisions doivent être documentées afin que les clients comprennent les erreurs.
Une erreur “UUID invalide” ne devrait pas mélanger syntaxe incorrecte et version non autorisée. Les deux problèmes demandent des corrections différentes.
La compatibilité externe compte
Certains SDK, validateurs ou partenaires acceptent seulement v4 par habitude. Avant de basculer vers v7, testez les clients, bases, gateways et systèmes de reporting. Un rollout progressif réduit le risque.
Les fixtures doivent contenir des versions anciennes et nouvelles. Cela évite de casser la lecture de données existantes après un changement de générateur.
La confidentialité dépend de tout l’endpoint
Un UUID aléatoire ne révèle pas l’ordre de création, mais la réponse API peut révéler un compteur, une relation ou une date. Un UUID ordonné par temps peut être acceptable en interne et indésirable pour des ressources publiques sensibles.
Le choix de version fait partie du threat model, mais ne remplace pas permissions, minimisation et contrôle des réponses.
La version préférée peut changer
Une équipe peut commencer en v4 puis adopter v7 pour améliorer les index. Cette évolution ne doit pas réécrire les IDs existants. Les anciens restent des références durables. Les validators, factories et tests doivent accepter la période mixte.
Documenter la version générée et les versions acceptées évite de traiter un ID historique comme une erreur.
Les SDK publics doivent refléter cette politique. S’ils valident trop strictement une seule version, ils peuvent bloquer des données légitimes avant même que la requête atteigne le serveur.
Les benchmarks doivent inclure l’exploitation
Ne mesurez pas seulement la génération. Mesurez taille d’index, temps de join, comportement de backup, recherche dans les logs et outils de support. Un identifiant très performant mais pénible à exploiter peut coûter cher lors des incidents.
Les résultats doivent être relus après changement de moteur de base ou de volume. Une décision correcte à un million de lignes peut ne plus l’être à un milliard, surtout avec des écritures distribuées.
Un rollout progressif révèle les incompatibilités
Avant de changer la version générée partout, activez-la sur un service ou un type de ressource limité. Mesurez les rejets de validation, les erreurs de partenaires et le comportement des index. Cette étape transforme une hypothèse de compatibilité en preuve opérationnelle.
Les anciens UUID doivent continuer à être lus et recherchés. Le nouveau générateur concerne les nouveaux objets, pas l’identité déjà publiée.
Benchmark et exploitation complètent le choix
Mesurez insertion rate, taille d’index, joins, réplication et backup sur des données proches de la production. Évaluez aussi la facilité de recherche dans les logs et outils support. Le meilleur ID est celui qui satisfait les propriétés réelles du système.
Une fois choisi, le standard doit être partagé entre services. L’indépendance de génération ne signifie pas que chaque équipe choisit sa propre convention.