Un UUID (Universally Unique Identifier) est un identifiant de 128 bits utilisé pour identifier de manière unique des ressources dans les systèmes distribués, bases de données et APIs. Sa probabilité de collision est si faible qu'il est considéré comme pratiquement unique dans n'importe quel système.

L'UUID version 4 est le plus courant : il est généré de manière pseudo-aléatoire selon la norme RFC 4122. Il est représenté en hexadécimal avec des tirets : 8-4-4-4-12 caractères (xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx). L'UUID v4 n'est pas trié : des UUID générés successivement ne sont pas ordonnés, ce qui peut poser des problèmes de performance avec les index B-tree des bases de données. L'ULID (Universally Unique Lexicographically Sortable Identifier) résout ce problème en intégrant un timestamp dans les premiers bits.

📐 Formule

UUID v4 : 122 bits aléatoires sur 128 bits | Probabilité de collision : 1 sur 5,3 × 10³⁶ pour 2 UUID

📊 Tableau de référence

Format Longueur Trié Collision probability Cas d'usage
UUID v4 36 chars (avec tirets) Non ~10⁻³⁶ ID général, base de données
UUID v1 36 chars Partiel ~10⁻³⁶ ID avec timestamp MAC
ULID 26 chars Oui (lexico.) ~10⁻³⁶ Logs, événements triables
NanoID 21 chars (défaut) Non ~10⁻³⁰ URL courtes, ID compacts
Cuid2 24 chars Non ~10⁻³⁶ ID sécurisé, web

💡 Exemples pratiques

Exemple 1 : UUID v4 comme clé primaire PostgreSQL CREATE TABLE users (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), ...); — gen_random_uuid() génère un UUID v4. Avantage : aucun conflit entre serveurs distribués. Inconvénient : index moins performant qu'un SERIAL.
Exemple 2 : UUID comme identifiant de session session_id = crypto.randomUUID() — en JavaScript natif (navigateur + Node.js 14.17+). Générer un UUID côté serveur pour chaque session garantit l'unicité sans base de données partagée.
Exemple 3 : ULID pour des logs triables Un ULID comme 01ARYZ6S41TPTWGY5UDXX5 intègre un timestamp (48 bits) + aléatoire (80 bits). Les logs peuvent être triés naturellement par ordre d'insertion sans index séparé.