Versions UUID expliquées : guide complet

La collision d'identifiants

Votre base de données signale une violation de clé primaire. Deux utilisateurs ont le même identifiant. Comment est-ce possible ? Vous utilisiez des entiers auto-incrémentés.

Puis vous vous souvenez : vous avez fusionné les données de deux systèmes différents. Les deux comptaient à partir de 1. L'utilisateur n°1 du système A entre en conflit avec l'utilisateur n°1 du système B.

C'est pourquoi les systèmes distribués utilisent des UUID. Ils sont pratiquement impossibles à faire entrer en collision entre tous les systèmes, tout le temps.

Qu'est-ce qu'un UUID ?

UUID signifie Universally Unique Identifier. C'est un nombre de 128 bits représenté par 36 caractères : 32 chiffres hexadécimaux plus 4 traits d'union.

Un UUID ressemble à ceci : 550e8400-e29b-41d4-a716-446655440000. Le format est 8-4-4-4-12 caractères.

La probabilité de générer deux UUID identiques est astronomiquement faible. Il faudrait générer des milliards d'UUID par seconde pendant des siècles pour avoir une chance raisonnable de collision.

Versions UUID expliquées

Il existe plusieurs versions d'UUID, chacune avec des méthodes de génération différentes :

• Version 1 – Basée sur l'horodatage et l'adresse MAC. Non recommandée pour la vie privée (révèle des informations sur l'ordinateur).
• Version 4 – Entièrement aléatoire. La plus courante et recommandée pour un usage général.
• Version 5 – Basée sur un espace de noms et un nom. La même entrée produit toujours le même UUID.
• Version 7 – Version la plus récente, combine horodatage et aléa. Bonne pour l'indexation en base de données.

Quand utiliser les UUID

Les UUID sont idéaux pour :

• Clés primaires de base de données – Surtout dans les systèmes distribués
• Identifiants de session – Suivre les sessions utilisateur en toute sécurité
• Clés API – Générer des jetons d'accès uniques
• Noms de fichiers – Éviter les conflits lors de la fusion de fichiers de sources différentes
• Identifiants de transaction – Suivre les opérations entre microservices

Quand ne PAS utiliser les UUID

Les UUID ne sont pas toujours le meilleur choix :

• Motifs d'accès séquentiels – Les UUID sont aléatoires, provoquant une fragmentation d'index
• Très forts volumes d'écriture – Les insertions aléatoires sont plus lentes que les séquentielles
• Identifiants lisibles par les humains – Les UUID sont longs et difficiles à mémoriser
• Petits ensembles de données – Les entiers auto-incrémentés sont plus simples et plus efficaces

UUID v7 en 2026 : le nouveau choix par défaut

L'UUID v7 a été normalisé dans la RFC 9562 (mai 2024) et est rapidement devenu le choix par défaut pour les identifiants qui doivent être triables et adaptés aux bases de données.

Les principales bases de données le génèrent désormais nativement (par exemple uuidv7() dans PostgreSQL 18), et les bibliothèques d'identifiants courantes fournissent v7 par défaut. Comme v7 intègre un horodatage en millisecondes, les valeurs sont ordonnées dans le temps, ce qui réduit la fragmentation des index B-tree en cas de volume d'écriture élevé.

Conseil pratique : utilisez v7 pour les clés primaires et les identifiants d'événements lorsque l'ordre améliore les performances ; utilisez v4 lorsque vous avez besoin de valeurs aléatoires totalement imprévisibles (par exemple des jetons) ; évitez v1 pour les nouveaux projets car il peut divulguer l'adresse MAC de la machine qui l'a généré.

FAQ

Références

Cet article s'appuie sur les normes industrielles et les bonnes pratiques de sources autoritatives :

• RFC 9562 – Universally Unique IDentifiers (UUIDs) : https://www.rfc-editor.org/rfc/rfc9562