Générez des UUID v1, v4 ou v7 dans votre navigateur avec le générateur UUID. Rien n'est envoyé.
Pourquoi les systèmes distribués ont besoin d'UUID
Les entiers auto-incrémentés sont simples jusqu'à ce que vous ayez plusieurs serveurs, des clients hors ligne ou des ensembles de données fusionnés. Les UUID permettent à n'importe quel nœud de générer des identifiants globalement uniques sans coordination.
Le compromis avec les UUID aléatoires classiques (v4) est la performance des index : les valeurs aléatoires dispersent les insertions dans les arbres B et LSM, provoquant des scissions de pages et une amplification d'écriture sur les grandes tables.
Imaginez une table de journal d'événements alimentée par plusieurs services. Avec des clés auto-incrémentées, il faut un seul écrivain ou un service d'attribution. Les UUID suppriment cette étape : chaque service crée les siens puis les fusionne.
Un UUID v4 porte 122 bits aléatoires ; les collisions restent un problème théorique.
Côte à côte
Les deux versions produisent des identifiants de 128 bits ; la différence tient à ce que ces bits encodent. Le tableau ci-dessous résume ce qui compte.
| Propriété | UUID v4 | UUID v7 |
|---|---|---|
| Triabilité | Aléatoire, non triable | Ordonné dans le temps, triable |
| Horodatage | Aucun | Horodatage Unix 48 bits (ms) |
| Localité d'index | Médiocre sur les grandes tables | Bonne, proche des insertions séquentielles |
| Prévisibilité | Imprévisible | La partie horodatage révèle l'heure de création |
| Norme | RFC 4122 | RFC 9562 |
Anatomie d'un UUID v7
Un UUID v7 commence par un horodatage Unix de 48 bits en millisecondes, suivi d'un nibble de version, d'un champ de variante et de bits aléatoires.
Le préfixe d'horodatage est ce qui rend les valeurs triables : les nouveaux identifiants sont généralement plus grands que les anciens, donc les index de base de données restent denses et les insertions rapides.
Exemple : un UUID v7 du 17 août 2026 à 00:00 UTC commence par 01a00d04-9800-7000-8000-…. Les douze premiers caractères encodent l'horodatage, le 7 la version, le 8 la variante, le reste est aléatoire.
Au total, 74 des 128 bits sont aléatoires, moins que les 122 de v4 ; les collisions restent improbables.
const uuid = crypto.randomUUID(); // v4// v7 builds on the same random source but prefixes the 48-bit ms timestamp// The browser generator on this site does this for you automatically.Générer un UUID v7 dans votre navigateur
Le générateur s'occupe de l'horodatage et des bits aléatoires :
- Ouvrez le générateur UUID.
- Sélectionnez la version v7 dans les options de version.
- Choisissez le nombre d'identifiants nécessaires, ou activez le mode par lots pour un tableau de valeurs.
- Copiez la sortie et collez-la dans votre migration, fichier de seeds ou fixtures de test.
Remarque: Si vous avez aussi besoin d'identifiants aléatoires et impossibles à deviner pour les URL publiques, gardez v4 dans votre boîte à outils et utilisez v7 pour les clés triables.
Quand utiliser v7 plutôt que v4
Règle simple : si vous triez, paginez ou fusionnez par heure de création, v7 vous aide. Pour une étiquette unique, v4 reste le choix prudent ; le générateur UUID fait les deux.
- Clés primaires pour les tables à forte écriture où la localité d'index compte
- Flux d'événements et files de messages qui bénéficient d'un ordre naturel
- Bases de données distribuées qui fusionnent les écritures de nombreux nœuds
- Identifiants opaques publics quand la fuite d'horodatage est acceptable
- Clés de cache et de déduplication où les entrées récentes expirent ensemble
- Applications hors ligne qui créent des enregistrements puis synchronisent
Avertissement: N'utilisez pas v7 pour les jetons, identifiants de session ou tout ce qui doit rester impossible à deviner. L'horodatage intégré rend les valeurs partiellement prévisibles.
FAQ
Q.Les identifiants UUID v7 sont-ils sécurisés ?
A.Ils sont uniques mais pas secrets. Le préfixe d'horodatage révèle approximativement quand un identifiant a été créé, donc utilisez v7 pour les clés et v4 pour les identifiants impossibles à deviner comme les jetons. La partie aléatoire rend l'énumération difficile.
Q.Les valeurs UUID v7 révèlent-elles des horodatages ?
A.Oui, les 48 premiers bits encodent l'heure de création en millisecondes. C'est ce qui les rend triables, et c'est aussi la considération de confidentialité à connaître. L'horodatage étant au début, trier les v7 les trie aussi par heure de création.
Q.L'UUID v7 est-il pris en charge par les bases de données ?
A.La plupart des bases de données stockent les UUID comme valeurs de 128 bits, donc v7 fonctionne partout où v4 fonctionne. Certaines bases de données offrent en plus des fonctions UUIDv7 ou une gestion d'index optimisée pour les valeurs ordonnées dans le temps. Si vous générez les clés côté base, vérifiez les fonctions.
Q.Deux UUID v7 peuvent-ils entrer en collision dans la même milliseconde ?
A.Théoriquement oui, mais 74 bits aléatoires rendent cela peu probable : deux valeurs d'une même milliseconde diffèrent encore.
Q.Le générateur du navigateur a-t-il besoin d'un serveur ?
A.Non. L'outil fonctionne dans le navigateur : rien n'est envoyé, même hors ligne.
Références
- RFC 9562 – Universally Unique IDentifiers (UUIDs) : https://www.rfc-editor.org/rfc/rfc9562
- RFC 4122 – A Universally Unique IDentifier (UUID) URN Namespace : https://www.rfc-editor.org/rfc/rfc4122
- Brouillon IETF uuidrev, à l'origine de la RFC 9562 : https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
- MDN Web Docs – crypto.randomUUID() : https://developer.mozilla.org/fr/docs/Web/API/Crypto/randomUUID
Clés triables, horodatages visibles
Utilisez v7 pour les clés primaires des tables à forte écriture et les flux d'événements où l'ordre aide. Utilisez v4 pour tout ce qui doit rester impossible à deviner.
Générez l'un ou l'autre dans le navigateur avec le générateur UUID.
Pour trancher : v4 quand l'identifiant doit rester impossible à deviner, v7 quand il doit porter un ordre. Les deux se génèrent ici.