UUID vs ULID vs CUID Quel identifiant unique devez-vous utiliser ?

Chaque ligne de base de données, chaque ressource API, chaque événement distribué a besoin d’un identifiant. Le problème n’est pas de générer un identifiant — c’est de choisir un format qui ne vous causera pas de soucis six mois plus tard lorsque vos index PostgreSQL seront fragmentés et que vos URLs ressembleront à du bruit.

Voici la totalité de comparaison du générateur de UUID: UUID v4, UUID v7, ULID, CUID2 et Snowflake — ce qu’ils sont, où ils échouent, et quel est le meilleur à utiliser en réalité.

UUID v4 : La valeur par défaut sûre (avec un grand problème)

UUID v4 est 128 bits de aléatoire, formaté comme 550e8400-e29b-41d4-a716-446655440000. Il est universellement compris, pris en charge dans toutes les langues, toutes les bases de données et tous les ORM du monde.

La probabilité de collision est effectivement nulle — vous devriez générer un milliard d’UUIDs par seconde pendant 85 ans avant d’avoir une chance de 50% d’obtenir une seule collision. Ce n’est pas un problème en pratique.

Le problème est l’ordre. UUID v4 est entièrement aléatoire, ce qui signifie que l’insertion de lignes dans une table indexée par UUID répartit les écritures dans l’arbre B. À grande échelle, cela cause des divisions de pages, une fragmentation des index et une performance dégradée des insertions. Si vous insérez des milliers de lignes par seconde dans une table MySQL ou Postgres avec une clé primaire UUID, vous le ressentirez.

UUID v4 est également de 36 caractères sous forme de chaîne — non sécurisé pour les URLs sans encodage, et plus volumineux que les alternatives.

UUID v7 : Le frère meilleur de UUID v4

UUID v7 corrige le problème d’ordre. C’est un UUID chronologique où les bits les plus significatifs codent un instant en millisecondes, et le reste est aléatoire. Le résultat : 01875f3a-7b2d-7f8e-a3d1-4b2e6c1a0f93.

Les lignes insérées dans l’ordre temporel restent approximativement séquentielles dans l’index. C’est un gain significatif pour les charges lourdes en écriture. UUID v7 est compatible avec toute l’infrastructure existante des UUID — même format, même longueur de champ, même attente de prise en charge des bibliothèques — tout en ajoutant une capacité de tri.

Le RFC a été finalisé en 2022 et la prise en charge par les bibliothèques s’accentue rapidement. Si vous utilisez déjà des UUIDs et que vous ne pouvez pas modifier votre schéma, passer de v4 à v7 est à risque bas et à rendement élevé.

ULID : L’option la plus adaptée pour les développeurs

ULID (Universally Unique Lexicographically Sortable Identifier) encode un instant de 48 bits et 80 bits d’aléatoire dans 26 caractères en base32 : 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Ce qui le rend remarquable :

• Triable par défaut — le tri lexicographique est un tri chronologique
• Sécurisé pour les URLs — sans tirets, sans caractères spéciaux
• Insensible à la casse — évite l' 0/O et 1/I ambiguïté en excluant ces caractères de l’alphabet
• Compressible — 26 caractères contre 36 pour une chaîne UUID

ULID est la meilleure option pratique pour de nouveaux projets sans contraintes historiques. Il est suffisamment triable pour la plupart des cas d’utilisation, assez court pour les URLs, et lisible assez pour que l’humain puisse le copier-coller sans erreur de transcription.

Une limitation : si vous générez plusieurs ULID dans le même milliseconde, l’ordre monotone est garanti par processus mais pas entre des nœuds distribués. Pour la plupart des applications, cela est acceptable.

CUID2 : Conçu pour les systèmes distribués

CUID2 est le successeur de CUID, redessiné de zéro pour la sécurité et la résistance aux collisions dans des environnements distribués. Un CUID2 ressemble à : clh3uj5ln0000qzrmn831mbhe.

Il utilise un hachage SHA-3 d’une combinaison d’heure, de compteur, de fingerprint (ID de processus + nom de machine), et de données aléatoires. Le fingerprint est la différence clé — il est conçu spécifiquement pour éviter les collisions lorsque vous exécutez plusieurs générateurs d’identifiants simultanément sur de nombreux serveurs.

CUID2 est non triable. Il privilégie la résistance aux collisions et l’imprévisibilité par rapport à l’ordre temporel. Si vous construisez un système où les identifiants sont générés par des clients non fiables ou à travers de nombreux nœuds indépendants et que la sécurité est une préoccupation, CUID2 vaut la peine du compromis.

Pour la plupart des API backend, c’est trop complexe.

Les identifiants Snowflake : haute performance, mais vous êtes seul

Les identifiants Snowflake ont été inventés à Twitter pour générer des identifiants uniques à des millions par seconde dans un cluster distribué. Un identifiant Snowflake est un entier de 64 bits : instant (41 bits) + ID du centre de données (5 bits) + ID de machine (5 bits) + séquence (12 bits).

Ils sont triables, compacts (sont inclus dans un BIGINT), et extrêmement rapides. Discord, Instagram et de nombreux systèmes à grande échelle les utilisent.

Le problème : vous devez gérer les ID de machine. Cela signifie un service de coordination (ZooKeeper, etcd, une table de base de données) pour attribuer des ID de machine à chaque générateur d’identifiants. Si deux nœuds partagent un ID de machine, vous obtenez des collisions. Configurer cela correctement est non trivial, et le maintien est une charge opérationnelle.

À moins que vous ne génériez des centaines de milliers d’identifiants par seconde, la complexité n’est pas justifiée.

La comparaison

Génération de chaque identifiant en JavaScript

// UUID v4
import { v4 as uuidv4 } from 'uuid';
console.log(uuidv4()); // '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

// UUID v7
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // '01875f3a-7b2d-7000-8000-4b2e6c1a0f93'

// ULID
import { ulid } from 'ulid';
console.log(ulid()); // '01ARZ3NDEKTSV4RRFFQ69G5FAV'

// CUID2
import { createId } from '@paralleldrive/cuid2';
console.log(createId()); // 'clh3uj5ln0000qzrmn831mbhe'

// Snowflake (using @socialgouv/nextid for simplicity)
import Snowflake from '@socialgouv/nextid';
const snowflake = new Snowflake(1n); // machine ID = 1
console.log(snowflake.nextId().toString()); // '1641024000000000001'

Vous pouvez tester la génération de UUID directement avec le IO Tools UUID Generator — il prend en charge les UUID v1 à v7 et la génération en masse sans avoir à installer quoi que ce soit.

Quel est le bon choix à utiliser ?

Voici la recommandation réelle, pas la version « cela dépend » :

• Projet nouveau, sans contraintes historiques : Utilisez UDI. Triable, sécurisé pour les URLs, compact. C’est la meilleure valeur par défaut.
• Déjà utilisant des UUIDs, besoin d’une meilleure performance dans la base de données : Passer à UUID v7. Mise à jour sans changement, gain majeur sur les index.
• Les identifiants générés par des clients ou à travers des nœuds distribués non fiables : Utilisez CUID2. Le fingerprinting rend la résistance aux collisions robuste même dans des conditions adverses.
• Plateforme à haute performance (100 000+ identifiants/seconde), prêt à gérer les ID de machines : Utilisez Snowflake. Sinon, ne pas s’embarrasser.
• UUID v4 : Seulement si vous maintenez du code hérité et que vous ne pouvez pas changer le format. Arrêtez de l’utiliser pour de nouvelles tables.

L’époque de la définition par défaut de UUID v4 pour tout est terminée. ULID est la nouvelle valeur par défaut pour la plupart des cas d’utilisation, et UUID v7 est le bon chemin d’upgrade si vous êtes déjà dans le monde des UUIDs. Choisissez-en un et passez-y.

Vous aimerez peut-être aussi

Nouveau

PDF Signature Verification: What Developers Need to Know

En savoir plus "

Publié le Mai 10, 2026

Nouveau

Markdown vs HTML: When to Use Each for Docs, READMEs, and APIs

En savoir plus "

Publié le Mai 9, 2026

Nouveau

Paramètres UTM : Comment suivre les campagnes de marketing sans deviner

En savoir plus "

Publié le 8 mai 2026

Nouveau

Accessibilité de couleur pour les développeurs : Contraste, simulation de l'aveuglement et correction des problèmes

En savoir plus "

Publié le 7 mai 2026