UUID expliqué — v4 vs v7

Un UUID (Universally Unique Identifier) est une étiquette de 128 bits conçue pour identifier quelque chose de manière unique sans qu’une autorité centrale ne distribue les numéros. Si vous avez déjà eu besoin d’un identifiant de ligne unique, d’un nom de fichier sans collision ou d’une clé pour un système distribué, vous avez croisé les UUID. Le générateur d’UUID crée des v4, v1 et v7 localement avec Web Crypto — rien n’est envoyé à un serveur.

TL;DR

Un UUID est un identifiant de 128 bits ; la version que vous choisissez change le sens de ces bits.

v4 est entièrement aléatoire (par défaut) — le choix standard quand vous voulez simplement un identifiant unique.
v7 est triable dans le temps — il intègre un horodatage Unix en millisecondes, donc il se trie chronologiquement et fait une bien meilleure clé d’index de base de données.
Généré localement avec Web Crypto — crypto.getRandomValues produit l’aléatoire dans votre navigateur, donc aucun serveur n’intervient et aucune valeur ne quitte l’appareil.

Ce qu’est un UUID

Un UUID, ce sont 128 bits de données, représentés par convention en 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets — la disposition 8-4-4-4-12 :

550e8400-e29b-41d4-a716-446655440000

Quelques bits sont réservés pour marquer la version (le 4 du troisième groupe ci-dessus indique v4) et la variante (le a/b/8/9 de tête du quatrième groupe). Tout le reste porte les données d’identification réelles, et la nature de ces données dépend de la version. L’espace total — 2¹²⁸ valeurs possibles — est si vaste que les UUID aléatoires n’entrent pratiquement jamais en collision à aucune échelle réaliste.

Ce qu’un UUID n’est pas : un secret. C’est un identifiant, comme un numéro de plaque. En connaître un ne vous laisse pas déduire un autre, mais un UUID seul n’offre aucun contrôle d’accès — ne l’utilisez pas comme mot de passe ou comme jeton.

UUID v4 — l’aléatoire par défaut

v4 est la version que la plupart des gens désignent quand ils disent « UUID ». Sur ses 128 bits, 122 sont aléatoires (6 sont fixes pour la version et la variante), tirés d’une source aléatoire cryptographique. Le résultat est un identifiant sans relation avec le temps, le lieu ou toute autre valeur.

Parce que l’espace aléatoire est si grand, la probabilité que deux UUID v4 générés indépendamment entrent en collision est astronomiquement petite — il faudrait générer des milliards par seconde pendant des années pour que ce devienne plausible. Cela fait de v4 le bon choix chaque fois que vous avez besoin d’un identifiant unique et que l’ordre n’importe pas : un identifiant de requête, une clé de session, un nom de fichier. Le compromis, c’est que les valeurs v4 sont réparties uniformément dans l’espace, ce qui est une mauvaise nouvelle pour un index de base de données (voir ci-dessous).

UUID v7 — le triable dans le temps

v7 intègre un horodatage Unix en millisecondes dans ses bits de tête, les bits restants étant aléatoires. La conséquence qui le définit : les UUID v7 se trient dans l’ordre de leur création.

Cela compte pour les bases de données. Un index de clé primaire fonctionne mieux quand les insertions sont séquentielles, parce que les nouvelles lignes se posent les unes à côté des autres dans l’index (un motif d’« ajout ») au lieu d’être éparpillées aléatoirement entre les pages. Les insertions v4 frappent des pages aléatoires — causant des E/S disque aléatoires, des fractionnements de pages et une fragmentation de l’index à mesure que la table grandit. Les insertions v7 se regroupent, donc la base de données écrit séquentiellement et l’index reste compact.

Pour toute table qui grandit dans le temps — commandes, événements, lignes de log — v7 est généralement la meilleure clé primaire. Vous gardez l’unicité entre machines sans coordination, mais avec un index qui se comporte bien.

UUID v1 — l’ancêtre

v1 encode lui aussi un horodatage (60 bits d’une horloge à 100 nanosecondes depuis 1582) plus un identifiant de nœud, historiquement dérivé de l’adresse MAC de la machine. Il est triable au même titre que v7, mais il a deux inconvénients qui en font rarement le bon choix aujourd’hui :

Fuite de confidentialité — intégrer l’adresse MAC dans chaque UUID révèle le matériel réseau de la machine qui l’a généré et rend les UUID d’un même nœud trivialement reliables entre eux. Dans un monde qui vise la confidentialité par défaut, c’est un coût réel.
Pas d’avantage réel sur v7 — v7 vous donne l’ordre temporel avec un horodatage Unix-ms propre et sans empreinte matérielle, donc les raisons de recourir à v1 ont en grande partie disparu.

Si vous avez déjà des données v1, elles continuent de fonctionner ; contentez-vous de ne pas démarrer de nouveaux systèmes en v1. v4 (quand l’ordre n’importe pas) ou v7 (quand il compte) couvre pour l’essentiel tout besoin moderne.

Pas à pas : générer des UUID

Le générateur d’UUID s’exécute entièrement dans votre navigateur avec Web Crypto, donc les octets aléatoires sont produits localement et rien n’est téléversé. Voici la marche à suivre :

Choisissez la version. Les boutons v4 / v1 / v7 sélectionnent la version d’UUID à générer (v4 est sélectionné par défaut).
Choisissez le Nombre. Le sélecteur Nombre indique combien en générer : 5, 10, 25, 50 ou 100 (100 au maximum). La valeur par défaut est 10.
Choisissez un format. Sept formats de mise en forme façonnent le résultat :
- plain — la forme standard 8-4-4-4-12, comme 550e8400-e29b-41d4-a716-446655440000.
- UPPER — tout en majuscules, pour les systèmes qui le préfèrent.
- sans tirets — les 32 chiffres hexadécimaux concaténés, comme 550e8400e29b41d4a716446655440000.
- {accolades} — entre {...}, le style GUID de Microsoft.
- “string” — entre guillemets doubles, prêt à coller comme valeur JSON.
- SQL IN — mis en forme ('...','...') pour une clause SQL IN (...).
- JS array — mis en forme ["...","..."], un littéral de tableau JavaScript prêt à l’emploi.
Générez. Cliquez Nouveau pour un seul UUID, ou Generer pour produire tout le Nombre d’un coup (génération par lot).
Copiez. Cliquez Copier pour copier toutes les valeurs générées dans le presse-papiers.

Changer de version génère immédiatement une seule valeur nouvelle dans cette version, donc vous pouvez comparer les formats côte à côte.

FAQ

Les UUID sont-ils secrets ?

Non. Un UUID est un identifiant, pas un secret. En connaître un ne vous laisse pas prédire un autre, et une valeur v4/v7 seule n’accorde aucun accès. Si vous avez besoin de quelque chose qui doive être difficile à deviner — un mot de passe, un jeton d’API, un secret de session — générez un vrai secret avec le générateur de mots de passe et jetons. Les UUID servent à l’unicité, pas au contrôle d’accès.

v4 ou v7 pour ma base de données ?

Pour une table qui grandit dans le temps, v7 est généralement la meilleure clé primaire : elle se trie par date de création, donc les insertions sont séquentielles et l’index reste compact au lieu de se fragmenter sous les E/S aléatoires. Utilisez v4 quand l’ordre n’a pas d’importance et que vous voulez la compatibilité la plus large — identifiants de requête, clés de cache, ou partout où la valeur n’est qu’une étiquette. Dans le doute, choisissez v7 pour les nouvelles clés primaires et v4 pour tout le reste.

Quel format dois-je choisir ?

Cela dépend de la destination de la valeur. plain est la valeur par défaut sûre et ce que la plupart des systèmes attendent. UPPER convient aux systèmes qui stockent les GUID en majuscules. sans tirets économise 4 octets et s’insère dans les formats serrés. {accolades} suit la convention GUID de Microsoft. “string” se glisse directement dans une valeur JSON, SQL IN dans une requête de base de données et JS array dans du code source JavaScript. Choisissez la forme qui correspond à votre destination.

Puis-je en générer beaucoup à la fois ?

Oui. Réglez le Nombre (jusqu’à 100) et cliquez Generer pour produire ce nombre d’UUID d’un coup, puis Copier pour tous les récupérer. Si vous n’en avez besoin que d’un seul, Nouveau produit une valeur unique sans toucher au nombre.