UUID/GUID : Ce qu'ils sont et quand les utiliser

31 mars 2026 · 12 min de lecture

Comprendre les UUID en profondeur

Si vous avez déjà travaillé sur un projet logiciel traitant de grandes quantités de données, vous avez probablement rencontré le terme UUID, ou Identifiant Unique Universel. Ces identifiants de 128 bits sont une bouée de sauvetage lorsque vous devez vous assurer que chaque élément de données est unique à travers différents systèmes, bases de données, ou même organisations.

Pensez aux UUID comme à de très longs noms que vous donnez aux choses pour que personne n'ait jamais le même nom. Ils sont comme un code-barres pour vos données, et ils ressemblent à ceci : 550e8400-e29b-41d4-a716-446655440000. La structure se compose de 32 caractères hexadécimaux divisés en cinq groupes séparés par des tirets.

La beauté des UUID réside dans leur unicité statistique. Avec 2¹²⁸ combinaisons possibles (soit environ 340 undécillions), la probabilité de générer des UUID en double est si astronomiquement faible qu'elle est considérée comme négligeable à des fins pratiques. Pour mettre cela en perspective, vous pourriez générer un milliard d'UUID chaque seconde pendant les 100 prochaines années et avoir encore pratiquement zéro chance de collision.

Pourquoi les UUID comptent dans les logiciels modernes

Imaginez un entrepôt massif rempli de produits—chaque article a besoin d'une étiquette unique. Les UUID s'assurent que chaque produit obtient son propre identifiant unique, évitant toute confusion même si le système jongle avec plusieurs tâches à la fois. Ceci est particulièrement précieux pour les systèmes dispersés à différents endroits où il n'y a pas d'autorité centrale distribuant des ID.

Ils aident dans les applications distribuées en prévenant les collisions d'ID, permettant à chaque système de continuer indépendamment sans trébucher sur les données d'un autre. Cette approche décentralisée de la génération d'ID est ce qui rend les UUID indispensables dans les architectures de microservices, les bases de données distribuées et les applications cloud-natives.

Structure et versions des UUID

En coulisses, les UUID ont une structure soigneusement conçue qui aide à éviter les conflits. La façon dont ils sont générés inclut des bits d'information comme des horodatages, des identifiants d'hôte et des nombres aléatoires, selon la version. Cette configuration aide à garder tout unique, ce qui est essentiel lorsque vous travaillez avec des systèmes qui s'étendent sur différentes plateformes.

Décomposition des composants UUID

Un UUID standard suit ce format : xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• Time-low (8 chiffres hexa) : Les 32 premiers bits de l'horodatage
• Time-mid (4 chiffres hexa) : Les 16 bits du milieu de l'horodatage
• Time-high-and-version (4 chiffres hexa) : Les 12 bits supérieurs de l'horodatage plus le numéro de version sur 4 bits
• Clock-seq-and-reserved (4 chiffres hexa) : Séquence d'horloge et bits de variante
• Node (12 chiffres hexa) : Identifiant de nœud sur 48 bits (souvent adresse MAC ou valeur aléatoire)

Versions UUID expliquées

La spécification UUID définit plusieurs versions, chacune optimisée pour différents cas d'usage. Comprendre ces versions vous aide à choisir la bonne pour votre application.

Version 4 : UUID aléatoires

Quand les gens parlent d'UUID Version 4, ils veulent dire des ID entièrement aléatoires, sans aucune trace d'horodatage ou d'identifiant d'hôte. Ils sont parfaits pour les situations où la confidentialité compte et vous ne voulez pas que des informations fuient sur quand ou où l'ID a été généré.

La version 4 est la version UUID la plus couramment utilisée car elle est simple, sécurisée et ne nécessite aucune coordination entre les systèmes. Le caractère aléatoire provient de générateurs de nombres aléatoires cryptographiquement sécurisés, garantissant l'imprévisibilité.

Essayez de générer vos propres UUID avec notre outil Générateur UUID pour voir comment ils fonctionnent dans la pratique.

Version 1 et 6 : UUID basés sur le temps

Les UUID Version 1 incorporent un horodatage et l'adresse MAC de la machine génératrice. Cela les rend triables par temps de création, ce qui peut être utile pour les bases de données et les systèmes de journalisation. Cependant, l'inclusion d'adresses MAC soulève des préoccupations de confidentialité car elle révèle des informations sur la machine génératrice.

La version 6 est une spécification plus récente qui aborde certaines lacunes de la version 1 en réorganisant les bits d'horodatage pour rendre les UUID naturellement triables. Cela améliore considérablement les performances des index de base de données.

Version 7 : Le choix moderne

La version 7 est le dernier ajout à la famille UUID et représente le meilleur des deux mondes. Elle utilise des horodatages Unix pour la triabilité mais remplace l'adresse MAC par des données aléatoires pour la confidentialité. Cela la rend idéale pour les systèmes distribués modernes qui ont besoin à la fois de performance et de sécurité.

De nombreux développeurs choisissent maintenant la version 7 comme version UUID par défaut pour les nouveaux projets car elle combine les avantages du tri basé sur le temps avec la confidentialité de la génération aléatoire.

Le débat : UUID vs ID auto-incrémentés

L'un des débats les plus animés dans la conception de bases de données est de savoir s'il faut utiliser des UUID ou des entiers auto-incrémentés traditionnels comme clés primaires. Les deux approches ont leurs mérites, et le bon choix dépend de vos exigences spécifiques.

Avantages des UUID

• Génération décentralisée : Pas besoin d'autorité centrale ou de séquence de base de données
• Facilité de fusion : Facile de combiner des données de plusieurs sources sans conflits d'ID
• Sécurité par l'obscurité : Les ID non séquentiels rendent plus difficile la devinette d'identifiants valides
• Génération hors ligne : Peut créer des ID avant l'insertion en base de données
• Systèmes distribués : Parfait pour les microservices et les bases de données fragmentées
• Pas de conditions de course : Plusieurs systèmes peuvent générer des ID simultanément

Avantages des ID auto-incrémentés

• Taille plus petite : 4-8 octets vs 16 octets pour les UUID
• Meilleure performance d'index : Les entiers séquentiels sont plus adaptés au cache
• Lisible par l'humain : Plus facile à référencer dans les conversations et le débogage
• Ordre prévisible : Tri chronologique naturel
• Moins de stockage : Économies significatives dans les grandes bases de données
• Jointures plus rapides : Les comparaisons d'entiers sont moins coûteuses en calcul

Comparaison de performance

L'approche hybride

De nombreuses applications modernes utilisent une stratégie hybride : des ID auto-incrémentés pour les opérations internes de base de données et des UUID pour les API externes. Cela vous donne les avantages de performance des entiers en interne tout en exposant des identifiants non séquentiels et sécurisés vers l'extérieur.

Par exemple, votre base de données pourrait avoir une colonne id avec des entiers auto-incrémentés et une colonne uuid séparée qui est utilisée dans les réponses API et les URL. Cette approche est courante dans les plateformes e-commerce et les applications SaaS.

Quand utiliser les UUID : scénarios idéaux

Comprendre quand les UUID brillent vous aide à prendre des décisions architecturales éclairées. Voici les scénarios où les UUID ne sont pas seulement bénéfiques mais souvent essentiels.

Systèmes distribués et microservices

Dans les architectures de microservices, différents services ont souvent besoin de créer des enregistrements indépendamment. Les UUID éliminent le besoin de coordination entre les services lors de la génération d'ID. Chaque service peut créer ses propres identifiants sans se soucier des conflits avec d'autres services.

Ceci est particulièrement précieux dans les architectures événementielles où les événements ont besoin d'identifiants uniques qui peuvent être générés par n'importe quel service du système.

Synchronisation et réplication de données

Lorsque vous synchronisez des données entre plu