UUID v4, v1, v7 ou ULID : lequel choisir pour votre base de données ?

Toutes les UUID ne se valent pas selon l'usage. Ce guide compare les versions les plus courantes — v4 aléatoire, v1 horodatée, v3/v5 déterministe, v7 triable et l'alternative ULID — pour vous aider à choisir la bonne clé d'identifiant, avec le générateur UUID gratuit ToolPico pour les produire en un clic.

Qu'est-ce qu'une UUID, en pratique ?

Réponse courte Une UUID est un identifiant de 128 bits écrit sous forme de 36 caractères (par ex. 550e8400-e29b-41d4-a716-446655440000), conçu pour être unique sans qu'aucune autorité centrale n'ait besoin de coordonner son attribution.

Concrètement, une UUID sert partout où l'on a besoin d'un identifiant qui ne rentre pas en collision avec un autre, même généré sur une machine différente, sans base de données centrale pour vérifier les doublons : clés primaires, identifiants de session, noms de fichiers uploadés, identifiants de commande, jetons de correspondance entre microservices. Le format est normalisé par la RFC 4122 (mise à jour par la RFC 9562), ce qui garantit qu'un outil ou une bibliothèque, quel que soit le langage, produit et interprète les UUID de la même façon.

Définition Le chiffre juste après le deuxième groupe de tirets (par ex. le « 4 » dans ...-41d4-...) indique la version de l'UUID — la méthode utilisée pour la générer. C'est ce chiffre qui distingue une v4 aléatoire d'une v1 horodatée ou d'une v7 triable.

Un générateur UUID en ligne comme celui de ToolPico permet de produire ces identifiants directement dans le navigateur, sans rien envoyer à un serveur, et de générer plusieurs centaines d'UUID en une seule fois pour peupler un jeu de test ou une migration de base de données.

v4 aléatoire ou v7 triable : lequel pour une base de données ?

Réponse courte Pour de nouvelles clés primaires, l'UUID v7 est en général préférable à la v4 : elle reste imprévisible mais s'insère dans l'ordre chronologique, ce qui limite la fragmentation d'index sur les grosses tables.

L'UUID v4 remplit 122 de ses 128 bits avec de l'aléa cryptographique pur (via crypto.getRandomValues dans un navigateur). C'est excellent pour l'imprévisibilité — personne ne peut deviner la prochaine UUID à partir de la précédente — mais cela veut aussi dire que deux UUID v4 générées à quelques millisecondes d'intervalle n'ont aucun rapport visuel ou numérique entre elles. Insérées comme clé primaire dans un index B-tree, elles atterrissent à des positions complètement dispersées, ce qui peut fragmenter l'index sur de grandes tables.

L'UUID v7 corrige ce point précis : ses 48 premiers bits encodent l'horodatage Unix en millisecondes au moment de la génération, et le reste reste aléatoire. Résultat : des UUID v7 générées dans l'ordre chronologique se trient aussi dans le même ordre en tri alphabétique/numérique simple, un comportement proche de celui d'un entier auto-incrémenté, tout en gardant l'avantage de pouvoir être générées côté application avant même l'insertion en base.

Exemple illustratif — comportement typique selon la documentation technique (chiffres d'exemple, à valider sur votre propre moteur de base de données)
Version	Contient un horodatage	Triable chronologiquement	Cas d'usage typique
v4	Non	Non	Jetons, identifiants publics non devinables
v7	Oui (ms)	Oui	Clés primaires de nouvelles tables
v1	Oui (100ns depuis 1582)	Partiellement	Systèmes hérités, traçabilité
v3 / v5	Non	Non	Identifiant reproductible à partir d'un nom

Scénario concret : une équipe qui migre une table « commandes » de 3 millions de lignes, jusque-là indexée par un entier auto-incrémenté, vers des identifiants publics non séquentiels choisira le plus souvent la v7 plutôt que la v4, précisément pour ne pas dégrader les performances d'écriture de l'index au moment où le volume grossit.

v1 horodatée et v3/v5 déterministe : cas d'usage particuliers

Réponse courte La v1 encode un horodatage et un identifiant de machine (utile pour le débogage ou les systèmes hérités) ; les v3 et v5 sont déterministes — même namespace et même nom produisent toujours la même UUID, utile pour dédupliquer sans base de données de correspondance.

L'UUID v1 combine un horodatage à 100 nanosecondes près depuis le 15 octobre 1582 (date de référence du calendrier grégorien retenue par la norme) avec un identifiant de « nœud », historiquement l'adresse MAC de la machine génératrice. C'est utile quand on veut pouvoir retracer approximativement le moment de création d'un enregistrement directement depuis son identifiant, sans requête supplémentaire — mais cela pose une question de confidentialité si une véritable adresse matérielle est exposée. Le générateur ToolPico utilise à la place un nœud aléatoire avec le bit multicast activé, comme le permet la RFC, pour éviter ce problème tout en gardant le format v1.

Les UUID v3 (basée sur MD5) et v5 (basée sur SHA-1) sont différentes des trois autres : elles ne contiennent aucun aléa. On leur fournit un namespace (une UUID de référence, par exemple celle réservée aux noms DNS) et un nom (par exemple exemple.com), et l'algorithme produit toujours exactement la même UUID pour cette combinaison. C'est pratique pour convertir un identifiant existant (une URL, un nom de domaine, un numéro de série) en UUID de façon reproductible, sans avoir à stocker une table de correspondance quelque part.

À noter : les UUID v3/v5 ne doivent jamais servir à protéger un secret — puisqu'elles sont déterministes, quiconque connaît le namespace et devine le nom d'origine peut recalculer la même UUID.

ULID : l'alternative lisible et triable

Réponse courte Un ULID encode les mêmes 128 bits qu'une UUID mais en 26 caractères Base32, avec un horodatage en millisecondes dans les 10 premiers caractères — il se trie donc naturellement par ordre chronologique, comme la v7, mais avec une écriture plus compacte.

Le format ULID (Universally Unique Lexicographically Sortable Identifier) répond au même besoin que l'UUID v7 — un identifiant triable dans le temps — mais avec un encodage différent : l'alphabet Crockford Base32 (26 caractères) plutôt que l'hexadécimal à tirets. Cela le rend un peu plus court à l'écriture (26 caractères contre 36) et, selon certains développeurs, un peu plus simple à lire ou à copier à la main, tout en restant compatible avec un stockage sur 128 bits en base de données.

Le générateur UUID ToolPico inclut un mini-outil dédié pour produire un ULID en un clic, ainsi qu'un décodeur d'horodatage : en collant une v1, une v7 ou un ULID dans l'onglet « Valider », l'heure de création intégrée est affichée en UTC et en heure locale, ce qui est pratique pour vérifier rapidement quand un enregistrement a réellement été créé.

Générez des UUID v4, v1, v3/v5, v7 ou un ULID — gratuitement, en masse, entièrement dans votre navigateur.

Essayer l'outil →

Questions fréquentes

Quelle version d'UUID choisir pour une clé primaire de base de données ?

Pour une nouvelle table, l'UUID v7 est généralement le meilleur compromis : elle est aléatoire comme la v4 (donc non devinable), mais ses 48 premiers bits encodent un horodatage en millisecondes, ce qui la rend triable dans le temps. Cela limite la fragmentation d'index que provoquent les UUID v4 purement aléatoires sur de grosses tables, tout en gardant l'avantage de pouvoir générer l'identifiant côté application avant l'insertion.

Pourquoi une UUID v4 aléatoire pose-t-elle un problème de performance en base de données ?

Parce que ses octets sont entièrement aléatoires, chaque nouvelle UUID v4 insérée atterrit à un endroit imprévisible de l'index B-tree, au lieu de s'ajouter à la fin comme le ferait un entier auto-incrémenté. Sur une table de plusieurs millions de lignes, cela peut fragmenter l'index et dégrader les performances d'écriture — un effet documenté empiriquement sur des tables volumineuses, à évaluer selon votre propre moteur de base de données avant de généraliser un chiffre précis.

Quelle est la différence entre une UUID et un ULID ?

Les deux encodent 128 bits, mais une UUID standard s'écrit en 36 caractères hexadécimaux avec tirets, tandis qu'un ULID s'encode en 26 caractères avec l'alphabet Crockford Base32, dont les 10 premiers représentent un horodatage en millisecondes. Résultat : des ULID triés par ordre alphabétique se trient aussi automatiquement par ordre chronologique, ce qu'une UUID v4 ne permet pas nativement.

Une UUID v1 peut-elle révéler des informations sur la machine qui l'a créée ?

Historiquement oui : le standard RFC 4122 prévoit d'intégrer l'adresse MAC de la machine dans les derniers bits d'une UUID v1, ce qui a soulevé des inquiétudes de confidentialité. Dans le générateur ToolPico, le mode v1 utilise à la place un identifiant de nœud généré aléatoirement avec le bit multicast activé, comme le permet la RFC, afin de ne jamais exposer de véritable adresse matérielle.

Comment générer des UUID en masse sans les créer une par une ?

Dans le générateur UUID ToolPico, saisissez un nombre entre 1 et 1 000 (ou cliquez sur une puce préréglée comme 100 ou 1000), puis cliquez sur Générer : la liste complète apparaît d'un coup, prête à être copiée en un clic ou téléchargée en fichier .txt ou .csv, entièrement calculée dans le navigateur.

Note méthodologique : les chiffres et scénarios de cet article sont donnés à titre d'exemple pédagogique pour illustrer des comportements documentés (RFC 4122/9562), et non des mesures issues d'un benchmark spécifique. Vérifiez toujours le comportement réel sur votre propre moteur de base de données avant une décision d'architecture. Ce contenu est fourni à titre informatif et ne constitue pas un conseil d'ingénierie personnalisé.