Générateur UUID

Les UUID v4 sont 122 bits d'aléa cryptographiquement robuste — le choix par défaut pour les clés d'idempotence, les IDs de session et tout identifiant opaque et non ordonné. Les UUID v7 intègrent un timestamp Unix de 48 bits en millisecondes dans les octets de tête, donc les valeurs générées à des instants proches se trient lexicographiquement côte à côte. Cela rend v7 plus adapté comme clé primaire de base de données, où des insertions aléatoires peuvent fragmenter un index B-tree.

Exemple

Trois UUID v4 (aléatoires, sans ordre) :

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Trois UUID v7 générés dans la même milliseconde (remarquez le préfixe partagé) :

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Erreurs courantes et pièges

Voici les véritables pièges rencontrés lors de l'intégration d'UUID dans une application :

• Utiliser v4 quand l'ordre d'insertion compte. Indexer 10 M de v4 aléatoires provoque beaucoup de splits de page dans un B-tree. Si vous gardez v4, acceptez l'amplification d'écriture ou passez la clé primaire à v7.
• Retirer les tirets et perdre le nibble de version. f47ac10b58cc4372a5670e02b2c3d479 reste un UUID hex valide de 32 caractères, mais le 13e caractère (4) est le marqueur de version — pas un nibble aléatoire. Ne supposez pas que les 32 caractères sont aléatoires.
• S'appuyer sur Math.random(). Les vieilles bibliothèques basées sur Math.random() ne sont pas cryptographiquement solides et peuvent être prévisibles. Utilisez crypto.randomUUID() (navigateurs et Node 19+) ou une bibliothèque v7 qui lit depuis crypto.
• Traiter v7 comme un timestamp. Les 48 premiers bits portent le temps, mais le reste est aléatoire, donc deux v7 dans la même milliseconde ne sont pas ordonnés de manière déterministe. Ne vous fiez pas à un départage.
• Stocker en VARCHAR(36). Ça fonctionne, mais cela double l'espace par rapport à une colonne native UUID / BINARY(16) et ralentit les jointures. Utilisez le type natif du SGBD (uuid dans Postgres, UNIQUEIDENTIFIER dans SQL Server).
• Regex qui exige une version particulière. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i ne correspond qu'à v4. Si vous émettez ensuite des v7, cette regex rejette silencieusement des IDs valides.

Quelle est la différence entre UUID v4 et v7 ?

v4 : 122 bits d'aléa plus les marqueurs de version et de variante, sans composante temporelle. v7 : préfixe de 48 bits en millisecondes Unix, le reste étant aléatoire, si bien que les v7 générés à des instants proches se trient lexicographiquement côte à côte. Utilisez v7 comme clé primaire pour garder les insertions B-tree locales ; utilisez v4 quand vous ne voulez aucun signal d'ordre.

Puis-je obtenir un UUID en doublon ?

Pratiquement non. Un UUID v4 a 122 bits aléatoires, donc la probabilité de collision entre deux dans un lot d'un milliard est de l'ordre de 10^-18. Il faudrait générer environ 2,7 × 10^18 v4 pour atteindre 50 % de chance d'une seule collision. Considérez l'unicité comme acquise et n'ajoutez pas de vérification.

v4 est-il cryptographiquement aléatoire ?

Cet outil utilise crypto.randomUUID(), qui par spécification doit puiser dans un PRNG cryptographiquement solide. C'est suffisant pour des IDs de session, des clés d'idempotence et la plupart des jetons de sécurité. Ce n'est pas un remplacement pour un jeton signé ou un long secret d'API, et vous ne devez pas dériver de clés de chiffrement depuis un UUID.

UUID v7 est-il standardisé ?

Oui. UUID v7 est défini dans la RFC 9562 (mai 2024), qui a remplacé la RFC 4122 et formalisé v6, v7 et v8 aux côtés des versions d'origine. La plupart des langages modernes proposent des implémentations v7 — Postgres, MySQL et SQL Server acceptent des valeurs v7 dans une colonne UUID sans changement.

À quoi ressemble la forme binaire et l'endianness est-elle importante ?

Un UUID fait 16 octets. Le format texte canonique les regroupe en 8-4-4-4-12 caractères hex. Selon la RFC 9562, les octets sont écrits en ordre réseau (big-endian), donc 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 commence par l'octet 0x01. Les GUID Microsoft stockent historiquement les trois premiers groupes en little-endian en mémoire — attention en interopérant avec des dumps binaires .NET.

Sauvegardez-vous les UUID générés par cet outil ?

Non. Nous ne sauvegardons pas les UUID générés ici. Chaque valeur est affichée dans la zone de sortie et disparaît à la fermeture ou au rafraîchissement de l'onglet — rien n'est stocké, aucune télémétrie n'est collectée sur les valeurs. Vous pouvez le vérifier dans les outils de développement de votre navigateur.