Quand utiliser UUID v4 ?

Utilisez UUID v4 quand vous voulez des identifiants aléatoires opaques, sans tri par date de création ni exposition d’information temporelle.

Puis-je retirer les tirets ou mettre la sortie en majuscules ?

Oui. La page UUID v4 verrouillée conserve le panneau d’options UUID, avec bascules pour les tirets et les majuscules.

Générateur UUID v4

Générateur d’UUID v4: aléatoire, formatable, produit dans le navigateur

Ce générateur produit des identifiants UUID version 4 — des chaînes de 36 caractères hexadécimaux dans le format standard 8‑4‑4‑4‑12. L’utilisateur contrôle le nombre (1 à 100), l’emploi des majuscules et la présence des traits d’union. Chaque identifiant est généré localement, sans appel serveur, et peut être copié individuellement par un clic ou collectivement par un bouton. La page expose des toggles spécifiques au format v4 (majuscules, traits d’union) qui n’apparaissent pas pour les autres types d’identifiants du site.

Pourquoi ce générateur est différent

L’UUID v4 utilise 122 bits de pur aléa par identifiant. Les 6 bits restants sont fixés par la norme: 4 bits pour la version (v4) et 2 bits pour la variante (RFC 4122). Contrairement aux UUID v7 ou aux ULID, il n’y a aucune information de temps ou d’ordre dans la valeur. Cela a des conséquences pratiques importantes.

Les UUID v4 se trient de manière arbitraire. Utilisés comme clé primaire dans une base de données, ils fragmentent les index B‑tree, ce qui dégrade les performances en écriture et en lecture séquentielle.
La probabilité de collision est négligeable: avec 122 bits de hasard, même en générant des milliards d’identifiants, le risque de trouver deux valeurs identiques reste infime.
Les options de format (majuscules, traits d’union) ne sont pertinentes que pour les UUID (v4 et v7) — les autres types d’identifiants du site utilisent des contrôles différents.

Le générateur repose sur l’API crypto.randomUUID() du navigateur ou, si elle n’est pas disponible, sur une chute vers crypto.getRandomValues() pour construire manuellement les octets. Tout est calculé en mémoire, instantanément.

Structure et standardisation de l’UUID v4

L’UUID v4 est défini dans la RFC 4122 (et plus récemment dans la RFC 9562). Sa représentation canonique est une chaîne de 36 caractères, dont 32 hexadécimaux et 4 traits d’union, disposés ainsi:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

Les 6 premiers octets (12 caractères hexadécimaux) sont entièrement aléatoires.
Le 7ᵉ octet contient le nibble de version fixé à 4 (bits 12-15: 0100). C’est ce qui donne le « 4 » juste après le deuxième trait d’union.
Les 8 octets suivants (16 caractères) sont aléatoires à l’exception de deux bits dans le 9ᵉ octet: le nibble de variante (bits 6-7) vaut 10 (valeur 8, 9, A ou B selon la RFC 4122). Dans la représentation, c’est le y dans yxxx — sachant que y ne peut prendre que les valeurs 8, 9, A ou B en hexadécimal.
Les 6 derniers octets (12 caractères) sont totalement aléatoires.

Ainsi, seuls 122 bits sur 128 sont libres pour le hasard. Les 6 bits restants (4 pour la version, 2 pour la variante) garantissent l’interopérabilité.

Exemple concret avec analyse:

f47ac10b-58cc-4372-a567-0e02b2c3d479
          ^      ^
          version=4   variante=0xA (1010)

Si l’utilisateur désactive les traits d’union, la chaîne devient simplement une séquence de 32 hexadécimaux, sans perte d’information. La validation d’un UUID v4 (avec ou sans traits) doit vérifier le 4 à la position 14 (ou 12 dans la version sans traits) et le y à la position 19 (ou 16) pour le respect de la variante.

Probabilité de collision et implications pratiques

Avec 122 bits aléatoires, l’espace des UUID v4 possibles est de 2¹²² ≈ 5,3 × 10³⁶ valeurs. La probabilité de collision lors de la génération de n identifiants est approximée par la formule de l’anniversaire généralisée:

P_(collision) ≈ 1 - e^(-n² / (2 × 2¹²²))

Prenons des ordres de grandeur concrets:

Nombre d’UUID générés	Probabilité d’au moins une collision
1 million	1,9 × 10⁻²⁵
1 milliard	1,9 × 10⁻¹⁹
10¹² (1 000 milliards)	1,9 × 10⁻¹³

Même en générant un billion d’identifiants, la probabilité de collision est inférieure à 2 × 10⁻¹³. La borne supérieure pratique est donc: pour tout usage réaliste, la collision n’arrive jamais. C’est pourquoi l’UUID v4 reste un choix standard pour les systèmes distribués sans coordination centrale, les jetons d’accès et les identifiants de session.

Impact sur l’indexation en base de données

L’absence totale d’ordre dans l’UUID v4 est son principal défaut lorsqu’il est utilisé comme clé primaire. Les index B‑tree des bases de données relationnelles (MySQL InnoDB, PostgreSQL, SQL Server) sont conçus pour des valeurs qui croissent séquentiellement ou de manière monotone. Lorsqu’on insère une ligne avec un UUID v4 aléatoire, la base doit souvent réorganiser l’index pour placer la nouvelle entrée au milieu de l’arbre, ce qui provoque une fragmentation et des écritures disques supplémentaires.

Conséquences mesurées sur PostgreSQL avec une table de 10 millions de lignes:

Insertion avec UUID v4: environ 30 à 50 % plus lente qu’avec un entier séquentiel.
Taille de l’index: jusqu’à 40 % plus grande à cause des pages partiellement remplies.
Opérations de lecture par plage (range scan): quasi impossibles à optimiser car les valeurs ne sont jamais proches.

En revanche, un UUID v7 (basé sur le timestamp) ou un ULID offrent un ordre temporel, ce qui réduit la fragmentation. Le générateur de cette page propose d’ailleurs ces deux alternatives dans la même interface. Pour les applications où l’ordre n’est pas nécessaire et où la non-séquentialité est un atout (masquer le nombre d’enregistrements, éviter les attaques par énumération), l’UUID v4 reste pertinent.

Cas d’usage où l’UUID v4 excelle

Identifiants non séquentiels dans une API: les clients ne peuvent pas deviner l’ID suivant, ce qui empêche l’énumération des ressources (par exemple GET /api/users/1, /api/users/2…). Avec un UUID v4, l’URL devient /api/users/f47ac10b-58cc-4372-a567-0e02b2c3d479.
Systèmes hors ligne: un appareil sans connexion réseau peut générer un identifiant unique localement et le synchroniser plus tard, sans risque de conflit avec d’autres appareils.
Traçage distribué: chaque requête ou événement reçoit un identifiant unique qui traverse plusieurs services, sans nécessité de coordinateur central.
Bases de test: remplir une base de développement avec des UUID aléatoires simule un environnement réaliste où les clés ne sont pas monotones.

Personnalisation du format: majuscules et traits d’union

Deux toggles permettent d’adapter la sortie:

Uppercase (majuscules): active l’affichage des lettres hexadécimales de a à f en A à F. Certains systèmes (par exemple, des API legacy ou des macros VBA) requièrent des UUID en majuscules. La RFC 4122 ne spécifie pas la casse, mais recommande la cohérence. Le générateur respecte cette liberté.
Include hyphens (traits d’union): si désactivé, la chaîne passe de 36 à 32 caractères. Utile pour les contextes où les traits d’union compliquent l’encodage (URL, noms de fichiers, clés de dictionnaire). Attention: un UUID sans traits d’union n’est pas techniquement un UUID selon la RFC 4122 si on suit la représentation canonique, mais la plupart des bibliothèques l’acceptent en entrée (ex. uuid.Parse() en C# le gère).

Le changement de l’un ou l’autre toggle déclenche une régénération complète de tous les identifiants affichés. Ce comportement est intentionnel: l’utilisateur peut ainsi obtenir un jeu de valeurs homogène après avoir modifié le format.

Génération côté navigateur: confidentialité et rapidité

Contrairement à de nombreux générateurs en ligne qui envoient la demande à un serveur (avec les risques de latence et de fuite de données), ce générateur exécute tout le calcul dans le navigateur, via crypto.randomUUID() ou crypto.getRandomValues(). Les identifiants ne quittent jamais la machine de l’utilisateur.

crypto.randomUUID() est disponible depuis Chrome 105, Firefox 95, Safari 15.4 et Edge 105. Il produit un UUID v4 standard conforme à la RFC 4122.
Pour les navigateurs plus anciens, la page utilise crypto.getRandomValues() pour tirer 16 octets et modifie manuellement les bits de version et de variante. La qualité aléatoire est identique.

La génération est instantanée même pour 100 UUID, car l’opération est purement locale et ne nécessite qu’une microseconde par identifiant.

Foire aux questions (FAQ)

Q: Quelle est la différence entre UUID v4 et UUID v7? R: L’UUID v4 est entièrement aléatoire (122 bits), tandis que l’UUID v7 encode un timestamp Unix en millisecondes sur les 48 premiers bits, ce qui le rend triable temporellement. Le v7 réduit la fragmentation d’index mais révèle l’instant de création. Le v4 ne révèle aucune information temporelle.

Q: Puis-je générer plus de 100 UUID à la fois? R: L’interface limite le nombre à 100. Pour un lot plus important, il faut exécuter plusieurs générations. La limite évite de paralyser le rendu avec un trop grand nombre d’éléments dans le DOM.

Q: Les UUID générés sont-ils cryptographiquement sûrs? R: Oui, car ils utilisent crypto.getRandomValues(), une source d’aléa cryptographique. Cela les rend adaptés aux jetons d’API, aux sessions et aux sels de hachage.

Q: Pourquoi mon UUID commence-t-il souvent par un f ou un 9 au niveau du 4ᵉ groupe? R: Le 4ᵉ groupe contient le nibble de variante qui ne peut être que 8, 9, A, a, B ou b. Les valeurs les plus probables sont 9 (si le bit de poids faible est 1) et 8 (s’il est 0). C’est une contrainte de la norme, pas un biais.

Q: Puis-je utiliser un UUID sans traits d’union comme clé primaire? R: Oui, la plupart des bases de données acceptent la forme compacte de 32 caractères. Cependant, certains ORM attendent la forme canonique avec traits. Vérifiez le driver.

Q: Est-ce que la casse affecte l’unicité? R: Non, un UUID en minuscules et sa version en majuscules représentent la même valeur hexadécimale. Les bases de données stockent généralement en binaire (16 octets), donc la casse n’a aucun impact.

Comment cet ID est construit

FAQ