Générateur d’UUID v7: identifiants triés par le temps, générés localement
L’UUID v7 (Universally Unique Identifier version 7) est un format récent normalisé par la RFC 9562. Contrairement à son prédécesseur le plus répandu, l’UUID v4, il incorpore un horodatage au début de chaque identifiant, ce qui permet un tri chronologique naturel sans sacrifier l’imprévisibilité. L’outil présenté ici génère instantanément entre 1 et 100 identifiants UUID v7 dans le navigateur, avec des options d’affichage (casse, tirets) et un copie individuelle ou groupée.
Pourquoi l’UUID v7 est différent: horodatage + aléa
La structure interne d’un UUID v7 occupe 128 bits, comme tous les UUID. Les 48 premiers bits représentent le nombre de millisecondes écoulées depuis l’époque Unix (1er janvier 1970 00:00:00 UTC). Les 80 bits restants sont aléatoires (ou pseudo-aléatoires cryptographiquement). En texte, l’UUID v7 s’écrit en 36 caractères – 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets (par défaut). Exemple: 018f3a6e-2b7c-7a00-b000-123456789abc.
Le premier octet du champ horodatage occupe les positions 0 à 7 du premier groupe. Cela signifie que si vous générez deux UUID v7 à quelques millisecondes d’intervalle, leurs premiers caractères seront différents et ordonnés chronologiquement. Ce mécanisme résout le problème majeur de l’UUID v4: son absence totale de localité temporelle, qui entraîne une fragmentation des index dans les bases de données utilisant des arbres B (B‑trees).
Tri chronologique et performance des bases de données
Les SGBD relationnels comme PostgreSQL, MySQL ou SQL Server stockent les index primaires sous forme d’arbres B. Lorsqu’une clé primaire est un UUID v4, les nouvelles lignes s’insèrent à des positions aléatoires dans l’arbre. Chaque insertion force le rééquilibrage de plusieurs pages d’index, ce qui dégrade les performances en écriture, surtout à fort volume.
Avec un UUID v7, toutes les lignes créées dans une même milliseconde (ou dans des millisecondes successives) s’insèrent à la fin de l’index – ou du moins très près les unes des autres. Cela réduit drastiquement le nombre de pages d’index touchées par insertion. Pour une table recevant des millions de lignes par heure, le gain peut atteindre un ordre de grandeur.
Il faut toutefois nuancer: l’UUID v7 ne garantit pas un ordre strict entre plusieurs identifiants générés dans la même milliseconde. Les 80 bits aléatoires ne sont pas triés. Si votre application produit 10 000 identifiants dans une même milliseconde, leur ordre dans l’index sera aléatoire entre eux, mais ils resteront groupés temporellement derrière les identifiants de la milliseconde précédente et avant ceux de la milliseconde suivante. C’est suffisant pour la plupart des cas d’usage, mais insuffisant pour un séquencement granulaire (comme un journal d’événements où l’ordre intra‑milliseconde compte).
Comparaison UUID v7 contre UUID v4
| Caractéristique | UUID v4 | UUID v7 |
|---|---|---|
| Structure | 122 bits aléatoires + 6 bits de version/variante | 48 bits d’horodatage + 74 bits aléatoires + 6 bits de version/variante |
| Tri chronologique | Aucun | Oui, par milliseconde |
| Taille texte | 36 caractères (32 hex + 4 tirets) | 36 caractères (32 hex + 4 tirets) |
| Collision | Probabilité négligeable (128 bits) | Probabilité négligeable (aléa 74 bits + horodatage) |
| Index B‑tree | Fragmentation élevée | Bonne localité temporelle |
| Unguessabilité | Oui (aléa cryptographique) | Oui (aléa cryptographique, horodatage ne réduit pas l’imprévisibilité) |
| Standard | RFC 4122 (obsolète) / RFC 9562 | RFC 9562 |
Le principal avantage de l’UUID v7 est donc l’indexabilité. On sacrifie un peu d’aléa (74 bits au lieu de 122) mais la sécurité reste suffisante: 2^74 combinaisons restent inaccessibles à toute attaque par force brute raisonnable. De plus, l’horodatage étant public (on peut le lire en décodant les 48 premiers bits), il n’affaiblit pas l’imprévisibilité.
Génération locale dans le navigateur: confidentialité et rapidité
L’outil fonctionne entièrement côté client. Aucune donnée n’est envoyée au serveur (BroBroGo ou autre). Les UUID sont produits avec l’API Crypto.getRandomValues() disponible dans tous les navigateurs modernes. Cette méthode fournit un aléa cryptographiquement fort, certifié par les spécifications W3C.
Chaque modification d’un paramètre – le nombre d’identifiants (entre 1 et 100), le choix d’afficher en majuscules ou minuscules, l’inclusion ou non des tirets – déclenche une régénération immédiate. Il n’y a pas de bouton « Générer »: le résultat se met à jour en temps réel. Cela évite toute ambiguïté entre un état obsolète et un état à jour.
La limite de 100 identifiants par tirage est volontaire: au‑delà, l’affichage deviendrait difficile à parcourir, et la génération par lots plus grands n’apporterait rien pour les cas d’usage courants (test de schémas, insertion de quelques dizaines de lignes, génération de clés pour un prototype).
Options d’affichage: casse et tirets
La représentation canonique d’un UUID est en minuscules, avec tirets, comme spécifié dans la RFC 9562: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Cependant, certains systèmes imposent l’usage de majuscules (par exemple dans des logs normalisés ou des interfaces utilisateur à casse fixe). L’outil offre donc un commutateur Uppercase qui transforme tous les chiffres hexadécimaux en majuscules. Exemple: 018F3A6E-2B7C-7A00-B000-123456789ABC.
De même, le commutateur Include hyphens retire les tirets. Un UUID sans tirets s’écrit alors sur 32 caractères: 018f3a6e2b7c7a00b000123456789abc. Cette forme est parfois plus pratique pour les identifiants dans des URL ou des clés de fichier, mais elle doit être évitée pour le stockage si l’on veut préserver la compatibilité avec les standards.
Attention: si vous désactivez les tirets, le format n’est plus un UUID valide au sens RFC – il devient simplement une chaîne hexadécimale de 128 bits. L’outil affiche toujours le statut « UUID v7 » mais le résultat ne respecte plus la représentation textuelle officielle. Pour un usage en base de données, conservez les tirets et la casse minuscule.
Cas d’usage concrets
- Systèmes distribués: Les microservices peuvent générer localement des identifiants uniques et triables sans coordination centralisée (pas de SGBD séquentiel, pas de Snowflake). L’horodatage permet de reconstituer l’ordre des événements a posteriori.
- Audit trails: Chaque entrée de journal reçoit un UUID v7. Un tri simple par ordre alphabétique (ou numérique) sur l’identifiant restitue l’ordre chronologique des événements.
- Migration depuis UUID v4: Pour améliorer les performances d’insertion sans changer tout le schéma, remplacer la clé primaire UUID v4 par UUID v7 est une opération relativement légère. L’outil permet de générer en masse les identifiants pour les nouvelles lignes.
- Tests et benchmarks: Générer rapidement 100 UUID v7 pour peupler une table de test, avec ou sans tirets, pour mesurer l’impact sur l’index.
Questions fréquentes
Q: L’UUID v7 garantit‑il l’absence de collision?
R: Non, aucun UUID ne le garantit à 100 %. Mais la probabilité est si faible qu’elle est considérée comme négligeable pour toute application pratique. Avec 74 bits d’aléa et 48 bits d’horodatage, il faudrait générer des milliards d’identifiants par milliseconde pendant des années pour atteindre 50 % de chance de collision.
Q: Puis‑je utiliser l’UUID v7 comme clé primaire dans MySQL?
R: Oui, et c’est même recommandé si vous utilisez InnoDB avec un index clusterisé (B‑tree). L’insertion sera bien plus rapide qu’avec UUID v4. Notez que MySQL stocke les UUID en binaire (BINARY(16)) pour plus d’efficacité; vous pouvez retirer les tirets et convertir en hexadécimal compressé.
Q: Pourquoi l’outil limite‑t‑il le nombre à 100?
R: Pour des raisons d’ergonomie et de performance d’affichage. Si vous avez besoin de plus (par exemple 10 000), générez plusieurs lots ou utilisez un script en ligne de commande. L’outil est conçu pour une utilisation interactive rapide.
Q: La génération est‑elle vraiment cryptographiquement sécurisée?
R: Oui. L’API crypto.getRandomValues() est implémentée sur tous les navigateurs modernes avec un générateur de nombres aléatoires cryptographiquement fort, généralement basé sur l’entropie du système d’exploitation (comme /dev/urandom sur Linux ou CryptGenRandom sur Windows).
Q: Que se passe‑t‑il si je change l’option « Inclure les tirets » après avoir copié des identifiants?
R: Les identifiants affichés sont immédiatement regénérés. Les anciens copiés ne sont pas modifiés. Si vous aviez copié la liste entière, vous devez recopier après changement.
Q: L’UUID v7 est‑il préférable à ULID?
R: Les deux sont très proches. ULID utilise 48 bits d’horodatage (comme UUID v7) mais encode en base32 (26 caractères). UUID v7 est standardisé par l’IETF (RFC 9562) et bénéficie d’une large compatibilité avec les bibliothèques existantes (Java, Python, Go, etc.). Le choix dépend souvent de l’écosystème existant.