Générer un UUID
La v4 est purement aléatoire ; la v7 place 48 bits d'horodatage en tête, ce qui rend les identifiants croissants dans le temps — et c'est ce qui change tout pour un index de base de données.
Le tirage utilise crypto.randomUUID() ou crypto.getRandomValues(), l'API cryptographique du navigateur. Rien n'est envoyé ni conservé.
Comment le contrôle fonctionne
- 1
Choisissez la version
v4 pour un identifiant sans ordre ni signification. v7 quand les identifiants servent de clé primaire ou d'index : ils se rangent naturellement par date de création.
- 2
Le tirage est cryptographique
122 bits d'aléa pour la v4. La collision est théoriquement possible et pratiquement hors d'atteinte : il faudrait des milliards d'identifiants par seconde pendant un siècle.
- 3
Les bits de version et de variante sont posés
Un UUID conforme porte son numéro de version au 13ᵉ caractère hexadécimal et sa variante au 17ᵉ. Un générateur qui les oublie produit une chaîne qui ressemble à un UUID sans en être un.
Pourquoi la v7 vaut souvent mieux comme clé primaire
Un index B-tree aime les insertions ordonnées. Avec des UUID v4, chaque insertion tombe à un endroit aléatoire de l'index, fragmente les pages et fait grossir le volume écrit. Avec des v7, les nouvelles lignes s'ajoutent à la fin, comme un identifiant auto-incrémenté.
Le prix à payer : un UUID v7 divulgue l'instant de création à la milliseconde. Ce n'est pas un secret dans la plupart des cas, mais si l'ordre de création est une information sensible, la v4 reste le bon choix.
Questions fréquentes
Deux UUID peuvent-ils être identiques ?
Mathématiquement oui, pratiquement non. Un UUID v4 porte 122 bits d'aléa : générer un milliard d'identifiants par seconde pendant cent ans laisserait encore une probabilité de collision négligeable. La vraie source de doublons est un générateur mal implémenté qui n'utilise pas de source cryptographique.
Quelle différence entre v1, v4 et v7 ?
La v1 combine l'horodatage et l'adresse MAC de la machine — elle divulgue donc du matériel. La v4 est purement aléatoire. La v7, normalisée par la RFC 9562, garde l'ordre temporel de la v1 sans en exposer le matériel : c'est aujourd'hui le meilleur compromis pour une clé primaire.
Faut-il stocker un UUID en texte ou en binaire ?
En binaire quand la base le permet : 16 octets contre 36 caractères, soit plus de deux fois moins de place dans chaque index. PostgreSQL a un type uuid natif ; MySQL utilise BINARY(16) avec UUID_TO_BIN(). En texte, on paie l'espace à chaque ligne et à chaque entrée d'index.
Le même contrôle par API
Cet outil tourne dans votre navigateur. Pour le même contrôle dans votre code, en masse ou côté serveur, l'API répond en JSON.
Voir la documentation