Qu'est-ce qu'un UUID, et quand l'utiliser ?

Vous avez sans doute déjà croisé une chaîne comme f47ac10b-58cc-4372-a567-0e02b2c3d479 dans une URL, une base de données ou un fichier de configuration, en vous demandant ce que c’est et pourquoi c’est aussi long. Il s’agit d’un UUID, dont le seul rôle est de servir d’identifiant unique que n’importe quelle machine peut générer toute seule, sans compteur partagé et avec quasiment aucun risque d’entrer en conflit avec celui d’un autre. Comprendre son fonctionnement vous indique précisément quand l’employer et quand un simple nombre fait mieux l’affaire.

En bref : un UUID est un identifiant de 128 bits, généralement présenté sous la forme de 32 chiffres hexadécimaux répartis en cinq groupes (8-4-4-4-12). Il existe pour que n’importe quelle machine puisse créer un identifiant de manière autonome tout en évitant les collisions, sans serveur central. Les UUID aléatoires (version 4) sont uniques à toutes fins pratiques. Utilisez-en un pour des identifiants distribués ou générés côté client, et pour des identifiants publics qui ne doivent pas être devinables ; préférez un simple entier auto-incrémenté quand une seule base de données détient les clés.

Ce qu’est réellement un UUID

Un UUID est une valeur de 128 bits. Pour rendre ces bits lisibles, on les écrit sous la forme de 32 chiffres hexadécimaux regroupés en 8-4-4-4-12 et reliés par des traits d’union, comme 550e8400-e29b-41d4-a716-446655440000. Les traits d’union n’ont aucune signification ; ils ne font que découper la suite de chiffres. Le nom complet est « universally unique identifier », et GUID, le terme que l’on voit dans les outils Microsoft, désigne exactement la même chose sous une autre étiquette.

Tous ces bits ont un but : l’étendue. Avec 128 bits, il existe environ 3,4 fois 10 puissance 38 valeurs possibles, un nombre si grand que tirer une valeur au hasard et retomber un jour sur la même ne se produira pratiquement jamais. C’est cet espace immense qui permet au système de tenir sa promesse centrale : un identifiant généré sur une machine n’entrera pas en collision avec un autre généré sur une autre machine, alors même que les deux ne se sont jamais concertées.

Pourquoi les UUID existent

Le problème que résolvent les UUID, c’est de générer un identifiant sans autorité centrale. Une base de données classique distribue des identifiants à partir d’un compteur unique : ligne 1, ligne 2, ligne 3, chaque numéro étant attribué par un seul serveur qui sait ce qu’il a donné en dernier. Cela fonctionne à merveille jusqu’à ce que vous ayez plusieurs serveurs, des clients hors ligne ou des systèmes qui doivent créer des enregistrements sans solliciter le serveur au préalable. Deux d’entre eux réclameront « le prochain numéro » et entreront en conflit.

Un UUID se passe complètement du compteur. Au lieu de demander la valeur suivante à un serveur, une machine génère un UUID localement à partir de l’aléatoire ou d’un horodatage, et compte sur l’immense espace de valeurs pour rester unique. Aucune coordination, aucun aller-retour, aucun point unique que tout le monde doit interroger. Un téléphone en mode avion peut créer l’identifiant d’un enregistrement, un serveur peut en créer un autre, et lors de la synchronisation ultérieure, les deux identifiants n’entreront pas en collision. Cette indépendance est la raison d’être même du format.

Quelle est vraiment la probabilité d’une collision ?

Pour un UUID de version 4, qui remplit ses bits d’aléatoire, une collision est possible en théorie et négligeable en pratique. Un UUID v4 fixe quelques bits pour marquer sa version et sa variante, laissant 122 bits aléatoires, soit environ 5,3 fois 10 puissance 36 valeurs distinctes. Pour avoir ne serait-ce qu’une chance sur un milliard de voir un seul doublon, il faudrait générer de l’ordre d’un trillion d’UUID.

Pour le dire en termes concrets, vous pourriez générer un milliard d’UUID v4 par seconde pendant environ un siècle et auriez encore plus de chances de remporter à plusieurs reprises un gros lot à la loterie que d’observer une seule collision. Ainsi, même si « universellement unique » n’est pas une garantie mathématique, l’écart entre la théorie et la réalité est si large que les systèmes en production traitent les UUID v4 comme uniques sans hésiter. Vous pouvez en créer un vous-même avec un générateur d’UUID gratuit sur dev.hivly.net et observer le format directement.

Les versions courantes, et pourquoi la v7 compte

Les UUID existent en plusieurs versions, et le chiffre qui ouvre le troisième groupe vous indique laquelle vous avez en main. Les deux que vous rencontrez le plus souvent sont la version 4 et les versions basées sur le temps. Un UUID de version 4 est construit à partir de bits aléatoires, il ne porte donc aucune information sur le moment ou le lieu de sa création ; c’est du pur aléatoire à l’intérieur de la structure fixe. C’est précisément cet aléatoire qui en fait un bon identifiant public, puisqu’on ne peut pas deviner le suivant.

La version 1 est l’ancienne conception basée sur le temps, qui combine un horodatage avec l’adresse réseau de la machine, ce qui a soulevé des inquiétudes en matière de confidentialité parce qu’elle pouvait révéler l’identité du matériel. La version 7 est l’option moderne basée sur le temps, et elle corrige le défaut notable de la v4 : le tri. Un UUID v7 place un horodatage en millisecondes au début, si bien que trier des UUID v7 sous forme de texte revient à les trier par date de création. Cela peut paraître mineur, mais c’est très important pour les bases de données : les clés v4 aléatoires dispersent les insertions dans un index, tandis que les clés v7 arrivent dans l’ordre, ce qui garde l’index bien rangé et plus rapide à écrire.

Quand utiliser un UUID, et quand s’en abstenir

Recourez à un UUID quand les identifiants naissent à de nombreux endroits qui ne peuvent pas partager un compteur : services distribués, bases de données multiples ou clients qui génèrent des clés hors ligne avant de se synchroniser. Utilisez-en un quand vous voulez un identifiant public qui ne révèle pas combien d’enregistrements vous avez ni ne permet à quelqu’un de parcourir la suite. Une URL qui se termine par /orders/8 invite à essayer /orders/9 ; une URL qui se termine par un UUID, non.

Un simple entier auto-incrémenté est le choix plus simple, et souvent meilleur, quand une seule base de données détient tous les identifiants. Les entiers sont minuscules à côté d’une valeur de 128 bits, ils s’indexent plus vite, ils sont faciles à lire et à saisir, et ils se trient naturellement. Le coût d’un UUID est réel : il prend plus de place, il est plus lent à indexer lorsqu’il est aléatoire, et personne ne le lit à voix haute sans peine. La décision n’est donc pas « les UUID sont modernes, les entiers sont dépassés ». Elle tient à qui crée les identifiants et au fait que la valeur doive ou non rester opaque. Si un seul serveur détient les clés et qu’elles peuvent être séquentielles, utilisez un entier. Si la création est répartie ou si l’identifiant ne doit pas être devinable, utilisez un UUID, et privilégiez la v7 quand vous voulez aussi qu’ils se trient par date.