En bref : UUID v4 est le choix sûr par défaut pour des ID uniques aléatoires, ULID convient mieux quand vous voulez aussi des ID triés par date de création, et NanoID est idéal quand il faut des ID courts et adaptés aux URL. Les trois évitent la coordination entre systèmes, mais arbitrent différemment longueur, tri et comportement dans les index. Ce guide explique ce qu'est chacun et quand y recourir.

Un identifiant unique permet à des systèmes indépendants de créer des enregistrements sans demander à un serveur central « quel est le prochain numéro ? ». Cette indépendance est l'essentiel : deux services, ou deux appareils hors ligne, peuvent chacun forger un ID en restant sûrs que les valeurs n'entreront pas en collision.

Ce qu'est réellement un UUID

Un UUID est une valeur de 128 bits, écrite normalement en 36 caractères — 32 chiffres hexadécimaux plus quatre tirets, comme 550e8400-e29b-41d4-a716-446655440000. La version que vous voulez presque toujours est UUID v4, qui remplit 122 de ces bits d'aléa. Cela donne environ 5,3 × 10³⁶ valeurs possibles : une collision n'est pas quelque chose à anticiper, il faudrait générer de l'ordre d'un trillion de milliards d'UUID avant que la probabilité d'un choc n'atteigne ne serait-ce que 50 %.

« Négligeable » n'est pas « impossible », mais en pratique v4 offre l'unicité sans aucune coordination centrale.

UUID v4 contre v1

UUID v1 est construit à partir d'un timestamp et de l'adresse réseau (MAC) de la machine génératrice. Cela rend v1 à peu près ordonné dans le temps, mais il peut révéler où et quand un ID a été créé — parfois une préoccupation de confidentialité. UUID v4 abandonne tout cela au profit du pur aléa : aucun ordre, aucune métadonnée intégrée, rien à divulguer. Pour la plupart des applications, v4 est le bon défaut, et v1 n'en vaut la peine que si vous voulez précisément sa composante temporelle.

ULID : trié par conception

Un ULID fait aussi 128 bits, mais est encodé en 26 caractères Crockford base32 au lieu d'hexadécimal à tirets. Ses 48 premiers bits sont un timestamp en millisecondes et les 80 restants sont aléatoires. Comme le timestamp est en tête, les ULID se trient lexicographiquement dans l'ordre de création : triez les chaînes et vous obtenez l'ordre chronologique gratuitement. C'est vraiment utile : cela rend peu coûteuses les requêtes « les plus récents d'abord » et garde les insertions ordonnées plutôt que dispersées.

NanoID : court et adapté aux URL

Un NanoID utilise par défaut 21 caractères d'un alphabet URL-safe, il se glisse donc dans un lien sans percent-encoding. La longueur est configurable, ce qui vous fait arbitrer taille et résistance aux collisions : les ID plus courts sont plus nets mais laissent moins d'aléa, gardez-les donc plus longs pour des identifiants publics ou à fort volume. NanoID brille pour les liens de partage, les ID publics courts et partout où un UUID de 36 caractères paraîtrait encombrant dans une URL.

Lequel pour une clé de base de données ?

Ici, le choix a de réelles conséquences de performance. UUID v4 est parfaitement valable comme clé primaire, mais son aléa fait que les nouvelles lignes s'insèrent à des positions aléatoires d'un index B-tree, provoquant fragmentation et éclatements de pages à mesure que la table grandit. Les identifiants ordonnés dans le temps — ULID, ou le plus récent UUID v7 — s'insèrent dans un ordre à peu près croissant, ce qui garde l'index compact et les écritures locales. Pour une clé de grande table à fortes écritures, préférez un ID ordonné dans le temps ; pour de petites tables, la différence compte rarement.

Erreurs courantes à éviter

  • Exposer publiquement des ID entiers séquentiels alors que vous vouliez des ID indevinables — c'est le rôle d'un ID aléatoire, pas d'un auto-incrément.
  • Utiliser un UUID v4 aléatoire comme clé groupée d'une énorme table puis s'étonner que les insertions ralentissent.
  • Tronquer un UUID pour « gagner de la place » — vous jetez l'aléa qui garantit l'unicité.
  • Raccourcir trop un NanoID pour un identifiant à fort volume et augmenter le risque de collision.

Adaptez l'ID à l'usage : utilisez le Générateur d'UUID pour créer des valeurs v4, v1, ULID ou NanoID, choisissez v4 pour l'unicité générale, ULID quand l'ordre compte et NanoID quand l'ID doit vivre dans une URL.