UUID v4 ou v7 : laquelle choisir et pourquoi ça compte

Utilisez un UUID v4 lorsque vous avez besoin d’un identifiant aléatoire, et rien de plus. Utilisez un UUID v7 lorsque l’identifiant servira de clé de base de données, ou lorsque vous voulez que les identifiants se trient par date de création. Les deux font 128 bits et s’écrivent sous la même forme de 36 caractères ; la différence tient donc à la façon dont les bits sont organisés. Le générateur d’UUID ci-dessous crée l’une ou l’autre version, de 1 à 500 à la fois, directement dans votre navigateur.

Générateur d’UUIDBesoin d’identifiants uniques pour mon codeEssayer gratuitement

À quoi ressemble un UUID

Un UUID, ou identifiant unique universel, est un nombre de 128 bits écrit sous forme de 32 chiffres hexadécimaux répartis en cinq groupes de 8, 4, 4, 4 et 12 chiffres, séparés par des tirets. Un exemple : 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63.

Deux parties du nombre sont fixes. Quatre bits indiquent la version, de sorte que le troisième groupe commence par 4 pour la v4 ou par 7 pour la v7. Deux bits indiquent la variante, de sorte que le quatrième groupe commence par 8, 9, a ou b. Le reste porte l’identifiant lui-même. Ce sont les bits de version et de variante qui expliquent qu’un UUID v4 ne contienne que 122 bits aléatoires, et non 128.

UUID v4 : aléatoire

Un UUID v4 est aléatoire, à l’exception de ces bits fixes. Ses 122 bits aléatoires rendent une répétition extrêmement improbable. Supposons que vous en génériez un milliard : la probabilité qu’deux d’entre eux soient identiques est à peu près égale à n au carré divisé par deux fois le nombre de valeurs possibles, soit environ 10 à la puissance -19. Autrement dit, les collisions ne sont pas un problème dont vous devez tenir compte dans votre conception.

Cette estimation suppose que le générateur tire ses bits d’une source aléatoire cryptographique. Un générateur prévisible la rendrait caduque. Cet outil utilise la source aléatoire cryptographique du navigateur, via crypto.randomUUID ou crypto.getRandomValues.

UUID v7 : d’abord le temps

La RFC 9562 définit la v7. Ses 48 premiers bits contiennent l’heure Unix en millisecondes : un identifiant créé plus tard a donc une première partie plus grande qu’un identifiant créé plus tôt. Viennent ensuite les bits de version, puis des bits aléatoires, les bits de variante et encore des bits aléatoires. Une partie de l’espace aléatoire peut accueillir un compteur, ce qui maintient l’ordre lorsque plusieurs identifiants sont créés dans la même milliseconde.

Comme le temps arrive en premier, trier les identifiants v7 comme du texte, dans une casse homogène, les classe par date de création, à la milliseconde près. Cela fonctionne parce que les chiffres hexadécimaux ont une largeur fixe et que le temps se trouve dans les premiers caractères.

Le temps est aussi lisible. Quiconque lit un UUID v7 peut voir à peu près quand il a été créé. Vous pouvez le vérifier vous-même avec le champ Inspecter du générateur d’UUID, qui reconvertit les 48 premiers bits en date et heure.

Pourquoi v7 convient mieux aux index de base de données

Un index de base de données est généralement un B-tree, une structure maintenue dans l’ordre de la clé. Lorsque la clé est aléatoire, comme avec la v4, chaque nouvelle ligne atterrit à un endroit aléatoire de l’index. La base doit alors écrire dans de nombreuses zones différentes de l’index, ce qui provoque davantage de découpages de pages et de défauts de cache. Sur une grande table, ce surcoût s’accumule.

Une clé v7 est plus grande que presque toutes les clés déjà présentes dans l’index, puisque sa partie temporelle augmente. Les nouvelles lignes s’ajoutent donc près de la fin de l’index, un peu comme le ferait un nombre à incrémentation automatique. Les pages récentes restent en mémoire et les écritures restent ordonnées. La différence se remarque surtout dans les grandes tables qui grossissent sans cesse, et elle est à peine perceptible dans une petite.

Choisir entre v4 et v7

• Clés primaires de base de données, ou toute table qui grandit dans le temps : v7. L’index reste ordonné.
• Journaux, événements ou messages que vous triez souvent par date : v7, car l’identifiant porte lui-même l’ordre.
• Identifiants publics dont la date de création doit rester privée : v4. Un identifiant v7 révèle quand il a été créé.
• Nombreux appareils aux horloges peu fiables : v4 comme v7 restent uniques, car ce sont les bits aléatoires qui assurent l’unicité. Seul l’ordre de tri de la v7 dépend de la justesse des horloges.

Les deux versions sont standard, mais les anciennes bibliothèques ne connaissent parfois que la v4. La RFC 4122 a décrit les versions 1 à 5 pendant de nombreuses années. La RFC 9562, publiée en mai 2024, remplace la RFC 4122 et définit les versions 6, 7 et 8. Vérifiez que la version de votre bibliothèque prend en charge la v7 avant de vous y fier.

Stocker les UUID

Un UUID écrit sous forme de texte occupe 36 caractères. Ses 16 octets peuvent être stockés sous forme binaire, ce qui prend beaucoup moins de place. De nombreuses bases de données proposent un type UUID natif ou une colonne binaire de 16 octets à cet usage, et la comparaison y est plus rapide que sur du texte.

Choisissez un format et tenez-vous-y. Majuscules, minuscules, tirets et accolades désignent le même UUID pour un humain, mais une base de données ou une comparaison de chaînes peut les traiter comme des valeurs différentes. Les options du générateur (majuscules, sans tirets, accolades) existent pour les systèmes qui exigent ces formes.

Ne jamais utiliser un UUID comme secret

Un UUID est un identifiant, pas un mot de passe, un jeton de session ou une clé d’accès. Il est conçu pour être unique, et non pour être impossible à deviner. Un UUID v7 contient en outre sa date de création. Et les identifiants finissent collés dans des liens, des journaux, des courriels et des captures d’écran, où n’importe qui qui les voit peut les réutiliser.

Le contrôle d’accès doit se faire côté serveur. Quelqu’un qui connaît un identifiant ne doit pas automatiquement être autorisé à voir ou à modifier l’enregistrement qu’il désigne. Pour les mots de passe, phrases de passe ou jetons, utilisez un générateur conçu pour les secrets. Le générateur de mot de passe crée des mots de passe aléatoires ou des phrases de passe à partir de mots, sur votre appareil, avec une aléa sécurisé, et il en estime la robustesse. Pour comprendre pourquoi la longueur et le caractère aléatoire comptent, lisez mots de passe solides et entropie.

Utiliser l’outil

1. Choisissez la version 4 pour des identifiants aléatoires, ou la version 7 pour des identifiants triables par date.
2. Définissez le nombre, de 1 à 500 à la fois.
3. Cochez majuscules, sans tirets ou accolades si votre code exige une forme particulière.
4. Copiez-les tous, ou téléchargez la liste sous forme de fichier .txt.
5. Collez un UUID dans le champ Inspecter pour lire sa version, sa variante et, pour la v7, le temps qu’il contient.

Réponses rapides

Un UUID v4 est-il unique ? En pratique, oui. Ses 122 bits aléatoires rendent une répétition si improbable qu’il n’est pas nécessaire de la vérifier.

Dois-je utiliser la v7 pour tout ? Pas toujours. Utilisez la v7 pour les clés de base de données et tout ce qui est trié par date. Utilisez la v4 lorsque la date de création doit rester cachée.

Puis-je utiliser un UUID comme mot de passe ? Non. C’est un identifiant. Utilisez un générateur de mot de passe pour tout ce qui doit rester secret.

L’outil envoie-t-il les identifiants quelque part ? Non. Les identifiants sont créés et affichés dans votre navigateur, et ils ne sont pas envoyés à un serveur.