Générateur UUID v4
Génère des UUID v4 aléatoires de manière cryptographiquement sécurisée
…
Formater
UUID v4 est la version UUID la plus largement utilisée dans les logiciels modernes. Contrairement à ses cousins qui dérivent des bits d'un horodatage ou d'un hachage d'espace de noms, UUID v4 est entièrement construit à partir de données aléatoires — ce qui en fait le choix le plus simple et le plus portable lorsque vous avez besoin d'un identifiant unique ne contenant aucune métadonnée sur son origine.
Ce générateur utilise crypto.randomUUID(), l'API native du navigateur et de Node.js, qui tire son entropie du générateur de nombres aléatoires cryptographiquement sécurisé du système d'exploitation — la même source utilisée pour les clés TLS.
Qu'est-ce qu'UUID v4 ?
Un Identifiant Universel Unique (UUID) est un label de 128 bits standardisé dans RFC 4122. Il est généralement représenté par 32 chiffres hexadécimaux regroupés par des tirets selon le modèle 8-4-4-4-12 :
Dans UUID v4, 122 des 128 bits sont aléatoires. Les 6 bits restants sont des champs fixes imposés par la spécification : 4 bits encodent la version (0100 = 4) et 2 bits encodent la variante RFC 4122 (10). Ces bits fixes expliquent pourquoi le troisième groupe commence toujours par 4 et le quatrième groupe commence toujours par 8, 9, a ou b.
Anatomie d'un UUID v4
Décomposition de 550e8400-e29b-41d4-a716-446655440000 :
| Segment | Bits | Signification |
|---|---|---|
| 550e8400 | 32 aléatoires | time_low (nom historique — entièrement aléatoire en v4) |
| e29b | 16 aléatoires | time_mid (nom historique — entièrement aléatoire en v4) |
| 41d4 | 4 fixes + 12 aléatoires | Nibble de version 4 (binaire 0100) + 12 bits aléatoires |
| a716 | 2 fixes + 14 aléatoires | Bits de variante 10 (MSB du premier octet) + 14 bits aléatoires |
| 446655440000 | 48 aléatoires | node (entièrement aléatoire en v4) |
8, 9, a ou b — car les deux bits de poids fort de cet octet sont fixés à 10 (le marqueur de variante RFC 4122), laissant les deux bits restants libres de varier.UUID v4 vs autres versions
RFC 4122 définit cinq versions UUID. Chacune résout un problème différent :
Combine un horodatage de 60 bits (intervalles de 100 nanosecondes depuis oct. 1582) avec l'adresse MAC de l'hôte. Monotoniquement croissant sur une machine.
Use when: vous avez besoin d'identifiants ordonnés dans le temps et n'êtes pas dérangé par la divulgation de l'identité du serveur et du temps de génération.
Déterministe : le même espace de noms + nom produit toujours le même UUID. Utilise le hachage MD5.
Use when: vous avez besoin d'identifiants reproductibles à partir d'un espace de noms connu (ex. noms DNS). Préférez v5 à v3.
122 bits de données aléatoires cryptographiquement sécurisées. Pas d'horodatage, pas de MAC, pas d'espace de noms. Le choix généraliste le plus courant.
Use when: vous avez besoin d'identifiants uniques sans signification structurelle et avec une confidentialité maximale.
Comme v3 mais utilise SHA-1. Toujours déterministe à partir d'un espace de noms + nom.
Use when: vous avez besoin d'identifiants reproductibles adressés par contenu (ex. identifiants stables pour des ressources identifiées par URL).
Plus récent (RFC 9562, 2024). Encode un horodatage Unix en millisecondes dans les bits de poids fort, puis des bits aléatoires. Triable et adapté aux bases de données.
Use when: vous avez besoin d'identifiants favorables aux index de base de données avec un ordre chronologique naturel (préférez à v1 pour les nouveaux projets).
Quand utiliser UUID v4
UUID v4 est l'outil adapté dans la grande majorité des situations où vous avez simplement besoin d'un identifiant unique sans contraintes supplémentaires :
Identifiants d'utilisateurs et de comptes
Identifiants d'utilisateurs opaques ne révélant rien sur l'heure de création du compte ou l'identité du serveur. Impossibles à énumérer ou à deviner.
Clés primaires de base de données
Fonctionne avec tout moteur de base de données. UUID v4 peut être généré côté client et fusionné depuis des sources distribuées sans coordination — aucune table de séquences ni service central d'ID requis.
Identifiants de session et de jeton
122 bits d'aléatoire rendent la devinette par force brute computationnellement infaisable — comparable en force à un jeton aléatoire de 122 bits.
Noms de fichiers et d'objets
Noms de fichiers sécurisés contre les doublons pour les téléchargements, les clés d'objets S3 ou les entrées de cache. Aucun risque que deux clients écrivent sur la même clé.
Clés d'idempotence
Générez un UUID côté client avant de soumettre une requête. Le serveur peut déduplicer en toute sécurité les requêtes réessayées sans compteur partagé.
Identifiants de corrélation et de trace
Attachez un UUID à chaque ligne de journal et à chaque span de trace distribuée. Aucune coordination nécessaire entre services ou machines.
Probabilité de collision
Avec 122 bits aléatoires, l'espace UUID v4 contient 2122 ≈ 5,3 × 1036 valeurs possibles. La probabilité d'une collision suit le problème des anniversaires :
Le repère couramment cité : pour avoir 50 % de chance d'une seule collision, vous devriez générer environ 2,71 × 1018 UUID. À un rythme de 1 milliard d'UUID par seconde, cela prendrait environ 85 ans de génération continue. Pour toute application réelle, les collisions ne sont pas une préoccupation pratique.
Exemples de code
JavaScript — Navigateur et Node.js 14.17+
La méthode crypto.randomUUID() est disponible nativement dans tous les navigateurs modernes (Chrome 92+, Firefox 95+, Safari 15.4+) et dans Node.js 14.17+. Aucune installation de package requise.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — versions plus anciennes (package uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Foire Aux Questions
UUID v4 est-il cryptographiquement sécurisé ?
UUID v4 lui-même n'est pas une primitive de sécurité — c'est un format d'identifiant. Cependant, lorsqu'il est généré via crypto.randomUUID() (navigateur ou Node.js) ou des API équivalentes au niveau OS, l'entropie sous-jacente est cryptographiquement sécurisée. Cela signifie que les valeurs UUID v4 conviennent comme jetons de session ou clés d'idempotence, où l'imprévisibilité importe. N'utilisez pas de générateurs UUID basés sur Math.random() dans des contextes sensibles à la sécurité — utilisez uniquement des API qui tirent explicitement du CSPRNG de l'OS.
Deux UUID v4 peuvent-ils jamais être égaux ?
Théoriquement oui, mais pratiquement non. La probabilité de générer un doublon dans tout ensemble de données réaliste (des milliards d'identifiants) est astronomiquement faible — bien moins probable qu'une défaillance matérielle causant une corruption de données. La collision UUID v4 est traitée comme impossible dans la conception des systèmes de production. Si vous avez vraiment besoin d'une garantie de zéro collision, utilisez un compteur centralisé ou une séquence de base de données.
UUID v4 vs nanoid — lequel utiliser ?
Les deux sont des générateurs d'identifiants aléatoires soutenus par un CSPRNG. Les différences clés :
- UUID v4 suit la norme RFC 4122, est reconnu par toutes les bases de données et frameworks, et ne nécessite aucune dépendance (natif
crypto.randomUUID()). - nanoid utilise un alphabet URL-safe et est plus court par défaut (21 chars vs 36). Utile quand la longueur de l'URL ou la lisibilité compte. Nécessite un package npm.
Préférez UUID v4 quand l'interopérabilité avec des systèmes externes est importante (API, bases de données, infrastructure de journalisation). Préférez nanoid quand vous voulez des identifiants plus courts et contrôlez toute la pile.
Dois-je stocker les UUID comme chaînes ou en binaire dans les bases de données ?
Pour la plupart des bases de données, stocker dans une colonne UUID ou BINARY(16) (16 octets) est plus efficace qu'une chaîne VARCHAR(36) (36 octets). PostgreSQL dispose d'un type uuid natif. MySQL et MariaDB fonctionnent bien avec BINARY(16) et les assistants UUID_TO_BIN() / BIN_TO_UUID(). Les utilisateurs de SQLite stockent généralement en TEXT. Le choix de stockage n'a aucun effet sur l'unicité ou la correction.
Pourquoi UUID v4 a-t-il des tirets — et puis-je les omettre ?
Les tirets font partie de la représentation UUID canonique définie par RFC 4122. Ils sont purement cosmétiques — ils ne portent aucune information et n'affectent pas la valeur de 128 bits. Les omettre donne une chaîne hexadécimale compacte de 32 caractères fonctionnellement équivalente. La plupart des analyseurs UUID acceptent les deux formes. En cas de doute, utilisez la forme canonique avec tirets pour une compatibilité maximale avec les outils et bases de données tiers.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"