UUID v1 vs v4 vs v5 : Quelle version utiliser ?
Réponse rapide
Utilisez UUID v4 (aléatoire) par défaut : il ne nécessite aucune coordination et présente un risque de collision négligeable. Utilisez la version v1 (basée sur le temps) uniquement lorsque vous avez besoin d'ID pouvant être commandés dans le temps et que vous pouvez sécuriser l'ID de nœud. Utilisez la version v5 (espace de noms+nom) lorsque vous avez besoin d'ID déterministes dérivés d'un nom. Générez n'importe quelle version avec notre générateur UUID gratuit.
Introduction
Un UUID (Universally Unique Identifier) est un identifiant de 128 bits rendu sous forme de 36 caractères dans des groupes hexadécimaux 8-4-4-4-12, par ex. 123e4567-e89b-12d3-a456-426614174000. La RFC 9562 définit plusieurs versions ; les trois que vous rencontrerez le plus sont v1 (heure + MAC), v4 (aléatoire) et v5 (espace de noms + nom, SHA-1). Chacun fait des compromis différents entre les garanties d'unicité, la possibilité de tri et le déterminisme.
Pas à pas
-
UUID v1 — basé sur le temps et le nœud
v1 code l'horodatage actuel de 60 bits (intervalles de 100 ns depuis le 1582-10-15) et un ID de nœud de 48 bits (généralement l'adresse MAC). Les identifiants générés sur le même nœud augmentent de manière monotone et peuvent être triés dans le temps. Risque : l'adresse MAC divulgue l'identité du matériel et un décalage d'horloge entre les nœuds peut perturber l'ordre.
-
UUID v4 — aléatoire
La v4 utilise 122 bits aléatoires (6 bits sont fixes pour la version/variante). Avec 122 bits aléatoires, la probabilité d’une collision entre 2 710 milliards d’identifiants est de 50 % ; pour toute charge de travail réaliste, la chance est effectivement nulle. La v4 ne nécessite aucune coordination et ne révèle aucune information sur l'hôte, ce qui en fait la valeur par défaut la plus sûre.
-
UUID v5 —espace de noms et nom (SHA-1)
La v5 hache un espace de noms UUID et une chaîne de nom avec SHA-1 pour produire un identifiant déterministe de 128 bits. La même paire (espace de noms, nom) génère toujours le même UUID, ce qui est idéal pour la déduplication et les identifiants stables dérivés de clés naturelles. La v3 est la même idée mais utilise MD5 (évitez-la).
-
Comparez les compromis
La v1 est triable mais fuit MAC et nécessite une synchronisation d'horloge. La v4 est aléatoire et privée mais impossible à trier. La v5 est déterministe et déduplique mais n'est pas aléatoire : deviner le nom permet à un attaquant de reproduire le UUID. Choisissez selon que vous avez besoin d'ordre, de caractère aléatoire ou de déterminisme.
-
Choisissez la bonne version pour votre cas
Clés primaires de base de données : v4 (ou v7 dans les systèmes plus récents pour une commande temporelle). Systèmes distribués sans coordination : v4. ID déterministes à partir d'une clé naturelle (par exemple URL →UUID) : v5. Journaux d'audit bénéficiant de l'ordre chronologique : v1 avec un ID de nœud aléatoire sécurisé.
Exemples
UUID v1 (basé sur le temps, triable)
Saisir: Généré le 2026-08-28T12:00:00Z sur le nœud 00:11:22:33:44:55
Sortir: 1ef7c1d0-2d3b-11f0-8000-001122334455 (chiffre de version « 1 », triable dans le temps)
UUID v4 (aléatoire)
Saisir: Random generation
Sortir: f47ac10b-58cc-4372-a567-0e02b2c3d479 (chiffre de version '4', bits aléatoires)
UUID v5 (déterministe à partir de l'espace de noms+nom)
Saisir: Espace de noms DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8) + nom « freeonlinetoolsgo.com »
Sortir: 74738ff5-5367-5958-9aeb-0c1f1f1f1f1f (la même entrée donne toujours la même sortie)
Problèmes courants
- Stockage des UUID en tant que VARCHAR(36) au lieu d'un type BINARY/UUID natif de 16 octets : cela gaspille 2x le stockage et interrompt les performances de l'index. Utilisez un type de colonne natif UUID lorsqu'il est disponible.
- Utilisation de la v1 sans sécuriser l'ID du nœud : l'adresse MAC par défaut divulgue l'identité du matériel et constitue un problème de confidentialité. Remplacez-le par une valeur cryptographiquement aléatoire de 48 bits par nœud.
- En supposant que les collisions v4 soient impossibles : elles ne le sont pas, elles sont simplement astronomiquement improbables. Avec 122 bits aléatoires, vous avez besoin d’environ 2,71 billions d’identifiants pour une chance de 50 %. Pour 1 milliard d'identifiants, la chance est d'environ 0,0000000000000001.
- Utilisation de la v3 (basée sur MD5) au lieu de la v5 (basée sur SHA-1) : MD5 est cassé, la v5 est donc préférée. Les deux sont déterministes, mais la v5 a une plus grande résistance aux collisions.
Conseils
- La valeur par défaut est la version v4 pour presque tous les cas d'utilisation : elle est aléatoire, privée et sécurisée contre les collisions, sans aucune coordination.
- Si vous avez besoin d'ID aléatoires triables dans le temps, consultez UUID v7 (RFC 9562, 2024) qui combine un horodatage Unix avec des bits aléatoires, mieux que la v1 pour les bases de données modernes.
- Utilisez la version 5 pour générer des identifiants stables à partir de clés naturelles (URLs, adresses e-mail) afin que la même entrée corresponde toujours au même UUID — utile pour la déduplication et idempotent APIs.
- Générez des UUID sur le client lorsque cela est possible pour éviter un aller-retour vers le serveur : notre générateur UUID s'exécute entièrement dans votre navigateur à l'aide de crypto.getRandomValues().