UUID v4 vs v7 : quel identifiant unique choisir ?

Un UUID est un identifiant de 128 bits unique sans coordination centrale. La version 4, entièrement aléatoire, domine depuis des années. La version 7, plus récente (RFC 9562, 2024), intègre un horodatage en tête pour produire des identifiants ordonnés dans le temps. Cette différence, anodine en apparence, change radicalement les performances en base de données. Voici lequel choisir.

Qu'est-ce qu'un UUID ?

Un UUID (Universally Unique Identifier) est un nombre de 128 bits représenté par 32 caractères hexadécimaux groupés en cinq blocs, par exemple 550e8400-e29b-41d4-a716-446655440000. Sa raison d'être : générer un identifiant unique sans demander à une autorité centrale, ce qui le rend idéal pour les systèmes distribués. Vous pouvez en générer avec notre générateur d'UUID.

Plusieurs versions existent ; les plus pertinentes aujourd'hui pour des clés d'enregistrement sont la v4 (aléatoire) et la v7 (ordonnée dans le temps).

UUID v4 (aléatoire)

L'UUID v4 est constitué de 122 bits aléatoires (le reste encode la version et le variant). La probabilité de collision est si faible qu'elle est négligeable en pratique. C'est la version par défaut dans la plupart des langages et bibliothèques.

• Imprévisible : parfait pour des jetons ou des identifiants publics qu'on ne veut pas devinables
• Aucune fuite d'information : ne révèle ni date ni ordre de création
• Inconvénient : totalement désordonné, ce qui malmène les index de base de données

UUID v7 (ordonné dans le temps)

L'UUID v7 place un horodatage Unix en millisecondes sur ses 48 premiers bits, suivi de bits aléatoires. Deux UUID v7 générés à des instants différents se trient donc dans l'ordre de leur création, tout en restant uniques et pratiquement impossibles à deviner.

• Triable : l'ordre lexicographique correspond à l'ordre chronologique
• Amical pour les index : les insertions se font en fin d'index, comme un auto-incrément
• Contrepartie : il révèle l'instant de création, ce qui peut être indésirable pour un identifiant public

Tableau comparatif

Impact sur les bases de données

C'est le coeur du sujet. Les bases relationnelles stockent leurs index dans des arbres B (B-tree). Insérer des clés aléatoires (v4) disperse les écritures partout dans l'index, provoquant de la fragmentation, des éclatements de pages et un cache moins efficace. Sur de gros volumes, les performances d'insertion se dégradent nettement.

Les clés ordonnées (v7) s'insèrent toujours à la fin de l'index, comme un identifiant auto-incrémenté. On retrouve des insertions rapides, une meilleure localité et un index plus compact. C'est particulièrement net avec une clé primaire en InnoDB (MySQL), où la clé primaire détermine l'ordre physique des lignes.

Quand choisir l'un ou l'autre

Choisir UUID v4 quand

• L'identifiant est exposé publiquement et ne doit rien révéler
• Vous générez des jetons, des liens de partage, des secrets
• L'ordre et la date de création ne doivent pas être devinables
• Vous voulez une compatibilité maximale avec l'existant

Choisir UUID v7 quand

• L'UUID sert de clé primaire dans une base de données
• Le volume d'insertions est élevé et la performance d'index compte
• Vous voulez trier par ordre de création sans colonne dédiée
• Révéler l'instant de création n'est pas un problème

Recommandation

Pour une clé primaire de base de données, préférez désormais UUID v7 : vous gardez l'unicité distribuée de l'UUID tout en évitant la pénalité d'index de la v4. Conservez UUID v4 pour les identifiants publics, jetons et secrets, où l'imprévisibilité totale et l'absence de fuite temporelle priment.

Vérifiez tout de même le support de la v7 dans votre langage et votre ORM : la RFC est récente, mais l'adoption progresse vite.

Questions fréquentes