UUID v4 vs UUID v7 : lequel choisir pour vos applications ?

Le choix d'une clé primaire influence le stockage, les index, la réplication et la génération distribuée. L'UUID v4 permet une création décentralisée et rend la simple devinette séquentielle peu pratique, mais son ordre aléatoire peut réduire la localité d'un index B-tree par rapport à une clé temporelle.

La RFC 9562 normalise l'UUID v7 ordonné dans le temps. En pratique, envisagez le v7 pour les clés de base et événements qui profitent d'une meilleure localité temporelle ; utilisez le v4 lorsqu'un identifiant aléatoire ne doit pas incorporer sa date de création. Aucune version ne doit servir de secret d'authentification ou de jeton porteur : utilisez pour cela une API cryptographique dédiée.

Vous pouvez générer les deux versions avec le générateur d'UUID de ToolPorta. Ce guide explique leur structure, leurs effets possibles sur la localité des index, l'exposition de l'horodatage et les critères qui doivent guider le choix.

Anatomie technique : UUID v4 vs UUID v7#

Un identifiant universellement unique (UUID) est une valeur de 128 bits représentée sous la forme de 32 chiffres hexadécimaux séparés par des tirets selon le schéma 8-4-4-4-12 (soit 36 caractères au total). L'UUID v4 et l'UUID v7 respectent rigoureusement cette présentation canonique, mais répartissent leurs bits selon des logiques radicalement différentes.

UUID v4 : L'aléa pseudo-aléatoire pur#

La RFC 9562 définit l'UUID v4 comme des données aléatoires ou pseudo-aléatoires comportant six bits structurels. Elle recommande un générateur cryptographiquement sûr lorsque l'imprévisibilité compte ; la qualité d'un UUID v4 dépend donc de son générateur.

• Bits de version (4 bits) : Fixés à 4 (0100 en binaire) au début du troisième groupe.
• Bits de variante (2 bits) : Fixés à 10 en binaire (représentés par les chiffres hexadécimaux 8, 9, a ou b) au début du quatrième groupe.
• Entropie aléatoire (122 bits) : Les 122 bits restants sont purement aléatoires.

Exemple d'UUID v4 :

1f47ac10b---a567-2               ^    ^3         version   variante 

Les 122 bits variables offrent 2^122 valeurs possibles. Avec un bon générateur, les collisions accidentelles sont extrêmement improbables, mais cela ne remplace ni une contrainte d'unicité en base ni un contrôle d'autorisation.

UUID v7 : Ordonnancement temporel et entropie aléatoire#

Normalisé en mai 2024 par la RFC 9562, l'UUID v7 comble la lacune majeure de la version 4 : l'absence totale d'ordonnancement séquentiel. L'UUID v7 incorpore un horodatage Unix en millisecondes dans ses bits de poids fort, suivi d'une réserve d'aléa :

• Horodatage Unix (48 bits) : Un entier non signé de 48 bits mesurant les millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). Ce compteur ne saturera pas avant l'an 10889 de notre ère.
• Bits de version (4 bits) : Fixés à 7 (0111 en binaire) au début du troisième bloc.
• Zone rand_a (12 bits) : Aléatoire par défaut ; une implémentation peut l'utiliser en partie pour une précision supplémentaire ou un compteur.
• Bits de variante (2 bits) : Fixés à 10 en binaire.
• Zone rand_b (62 bits) : Données aléatoires par défaut ; certaines méthodes monotones peuvent en employer une partie comme compteur.

Exemple d'UUID v7 :

1----2|--- Horodatage  bits ---| ^    ^  |--- Aléa / données monotones optionnelles ---|3                        version   variante

Puisque les 48 bits les plus significatifs encodent un horodatage croissant en millisecondes, deux UUID v7 se comparent et se trient naturellement par ordre chronologique selon un tri lexicographique ou binaire standard.

Pourquoi l'UUID v4 dégrade les bases de données (Le problème des arbres B-tree)#

Pour comprendre la genèse de l'UUID v7, il convient d'analyser le fonctionnement interne des moteurs de stockage des bases de données relationnelles (PostgreSQL, MySQL InnoDB, SQLite).

Entrées/sorties aléatoires et séparations de pages (Page Splits)#

Les moteurs relationnels indexent leurs clés primaires sous forme d'arbres B+ (B-trees). Un arbre B+ maintient les lignes triées sur le disque dans des blocs de mémoire de taille fixe appelés pages (couramment 8 Ko ou 16 Ko).

Lorsque vous insérez des enregistrements identifiés par un entier auto-incrémenté ou un UUID ordonné dans le temps, chaque nouvelle ligne s'ajoute à la fin de la dernière page physique de l'index. Lorsqu'une page est saturée, le moteur en alloue une nouvelle séquentiellement. Ce processus correspond à des entrées/sorties séquentielles optimales.

Avec l'UUID v4, chaque clé générée possède une valeur totalement imprévisible. Lors de l'insertion de 100 000 enregistrements :

1. Le moteur doit insérer chaque clé dans une page feuille aléatoire au cœur de l'arbre B-tree.
2. Si la page cible manque d'espace, le moteur peut la scinder ou la réorganiser puis mettre à jour les pointeurs d'index.
3. Des insertions réparties dans tout l'espace des clés peuvent augmenter les écritures, les mouvements de pages et la pression sur le cache. L'effet dépend du moteur, du facteur de remplissage, du volume, du stockage et de la charge.

Saturation du cache mémoire (Buffer Pool Thrashing)#

Dès qu'une table dépasse la capacité de la mémoire vive (RAM) disponible, le moteur ne peut plus conserver l'intégralité de l'index dans son cache mémoire (le buffer pool InnoDB ou les shared buffers PostgreSQL).

Avec l'UUID v7, les valeurs de millisecondes ultérieures se classent après les précédentes : les insertions récentes tendent donc à viser une zone plus étroite de l'index. Le v4 répartit les insertions dans l'espace des clés. Le v7 améliore souvent la localité, mais l'écart de débit doit être mesuré avec votre schéma, matériel, concurrence et profil de requêtes.

Erreurs courantes et pièges à anticiper#

Arbitrer entre v4 et v7 impose d'évaluer plusieurs contreparties techniques liées à la confidentialité, aux horloges et aux collisions.

1. Fuite d'horodatage et sécurité des données#

Le principal inconvénient de l'UUID v7 est qu'il révèle publiquement la date et l'heure exactes de création de la ressource.

Les 12 premiers caractères hexadécimaux d'un UUID v7 décrivent la milliseconde précise de sa génération. Dans de nombreuses architectures, cette divulgation pose des risques notables :

• Énumération d'utilisateurs : Si les identifiants d'utilisateurs sont en UUID v7, un observateur peut déterminer précisément la date et l'heure d'inscription de n'importe quel compte.
• Métadonnées opérationnelles : Une valeur v7 observée révèle sa milliseconde de création. Elle ne révèle pas, à elle seule, le nombre total de commandes ou d'enregistrements.
• Jetons secrets : N'utilisez aucune version d'UUID comme justificatif porteur. Le v7 est moins opaque à cause de son horodatage, et la RFC 9562 avertit qu'un UUID ne doit jamais être supposé difficile à deviner.

Règle : Préférez le v4 au v7 si l'identifiant ne doit pas révéler sa date. Pour les réinitialisations, sessions, clés d'API et confirmations, générez un jeton cryptographique dédié avec expiration, usage unique et validation côté serveur.

2. Dérive d'horloge et ajustements NTP#

L'UUID v7 dépend de l'horloge système physique. Si l'horloge d'un serveur recule brutalement en raison d'une synchronisation NTP ou de la mise en pause d'une machine virtuelle, les nouveaux identifiants générés pourraient théoriquement porter une date antérieure aux précédents.

La RFC décrit des compteurs et techniques aléatoires monotones optionnels. Une implémentation exigeant un ordre strict doit traiter explicitement le recul de l'horloge, le débordement du compteur et les lots créés dans la même milliseconde. L'aléa réduit le risque de collision entre nœuds, mais ne corrige pas l'ordre chronologique d'horloges désynchronisées.

3. Risque de collision au sein d'une même milliseconde#

Certains développeurs craignent que la création de milliers d'UUID v7 durant la même milliseconde sur une machine entraîne des doublons.

Dans la disposition de base, les 74 bits hors horodatage et structure peuvent être aléatoires. Deux valeurs indépendantes créées dans la même milliseconde coïncident avec une probabilité de 1 sur 2^74, mais le risque d'un lot suit le paradoxe des anniversaires et croît avec le carré du nombre généré. Utilisez une bibliothèque maintenue et conservez une contrainte d'unicité.

Tableau comparatif : UUID v4 vs UUID v7#

Arbre décisionnel : Quelle version choisir ?#

Appliquez cette démarche en 4 étapes pour choisir l'identifiant approprié à votre besoin :

1. L'identifiant sert-il de clé primaire ou d'index ordonné en base de données ?
   • Oui → Testez l'UUID v7 sur votre charge ; sa localité peut réduire les insertions aléatoires.
   • Non → Passez à l'étape 2.
2. L'identifiant est-il un jeton de réinitialisation, une clé d'API ou un secret de session ?
   • Oui → Utilisez l'UUID v4, avec un générateur de confiance.
   • Non → Passez à l'étape 3.
3. L'identifiant est-il exposé dans des URL publiques dont la volumétrie métier doit rester secrète ?
   • Oui → Choisissez l'UUID v4 ou un identifiant compact correctement dimensionné.
   • Non → Passez à l'étape 4.
4. Devez-vous assurer l'interopérabilité avec des technologies Microsoft Windows ou COM ?
   • Oui → Vérifiez précisément les conventions textuelles et binaires du GUID attendu.
   • Non → Choisissez selon les besoins ci-dessus ; le v7 convient bien aux identifiants orientés base, sans être un choix universel.

Pour vos développements backend, consultez notre guide JavaScript d'UUID ou notre guide Python d'UUID pour intégrer des générateurs v7 conformes à la RFC 9562.

Foire aux questions#

Peut-on stocker un UUID v7 dans une colonne UUID PostgreSQL ou MySQL existante ?#

Oui. L'UUID v4 et l'UUID v7 partagent exactement la même structure binaire de 128 bits définie par la RFC 9562. Dans PostgreSQL, l'UUID v7 s'enregistre nativement dans le type de colonne uuid. Dans MySQL, il se stocke parfaitement dans BINARY(16) et bénéficie du tri chronologique. Vous n'avez pas besoin de modifier votre schéma de base de données.

L'UUID v7 remplace-t-il définitivement l'UUID v1 ?#

Oui. L'UUID v1 intégrait également un horodatage, mais son implémentation présentait deux défauts majeurs : il divulguait l'adresse MAC physique de la machine (faille de sécurité critique) et son ordonnancement de bits plaçait les parties temporelles faibles en tête, empêchant le tri lexicographique naturel. L'UUID v7 a été expressément conçu par l'IETF pour supplanter l'UUID v1.

Comment extraire la date de création à partir d'un UUID v7 ?#

Il suffit de lire les 12 premiers caractères hexadécimaux, de les convertir en nombre entier décimal et de les interpréter comme un horodatage Unix en millisecondes. En JavaScript par exemple :

1function extraireDateUuidV7(uuid) {2  const hex = uuid.replace(/-/g, "").slice(, );3  return new Date(parseInt(hex, ));4}

L'UUID v7 est-il officiellement standardisé par l'IETF ?#

Oui. La RFC 9562 de mai 2024 normalise le v7 et remplace la RFC 4122. La prise en charge dépend des versions : Python fournit uuid.uuid7() depuis 3.14, .NET propose Guid.CreateVersion7() depuis .NET 9 et le paquet Node.js uuid maintenu gère le v7. Vérifiez la documentation de la version réellement déployée.

L'UUID v7 rend-il les entiers auto-incrémentés obsolètes ?#

Non. Les entiers auto-incrémentés restent compacts, simples et efficaces lorsqu'une base possède l'allocation. Le v7 est utile lorsque l'identifiant doit être créé avant l'insertion ou sur plusieurs nœuds indépendants. Le choix influence aussi la taille des clés étrangères et index, la réplication, l'exposition du volume d'enregistrements et l'outillage.

Essayez les outils d'identifiants de ToolPorta#

Adopter le format d'identifiant adéquat garantit la montée en charge de vos systèmes sans migrations complexes ultérieures. Découvrez la suite d'utilitaires ToolPorta :

• Utilisez le générateur d'UUID pour générer des identifiants conformes aux versions v4 et v7 de la RFC 9562.
• Utilisez le générateur de GUID pour formater des identifiants adaptés aux environnements Microsoft .NET et C#.
• Utilisez le générateur NanoID pour créer des identifiants compacts et sécurisés pour vos URL web.
• Consultez notre guide JavaScript d'UUID pour comparer les performances de génération en production.