Générer des UUID en ligne (et quand les utiliser)

Un UUID (Universally Unique Identifier) est un identifiant de 128 bits standardisé par la RFC 4122. Les UUID sont utilisés pour identifier de manière unique des informations dans des systèmes distribués sans nécessiter de coordination centralisée. Contrairement aux entiers auto-incrémentés, qui exigent qu'une base de données centralisée génère la prochaine valeur séquentielle, les UUID peuvent être générés indépendamment sur n'importe quel nœud d'un système distribué sans communication ni synchronisation entre nœuds. Cette propriété rend les UUID indispensables dans les architectures applicatives modernes qui s'étendent sur plusieurs serveurs, bases de données et régions géographiques.

Le concept d'identifiant universellement unique remonte aux années 1980, lorsque l'Open Software Foundation (OSF) a développé les UUID dans le cadre du Distributed Computing Environment (DCE). La spécification a ensuite été standardisée par l'Internet Engineering Task Force (IETF) dans la RFC 4122, publiée en juillet 2005. Depuis, les UUID ont été adoptés dans pratiquement tous les langages et plateformes de programmation, avec des fonctions de génération intégrées en JavaScript, Python, Java, C#, Go, Rust et bien d'autres.

Format des UUID

Un UUID est généralement représenté comme 32 chiffres hexadécimaux affichés en 5 groupes séparés par des tirets :

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Exemple : f47ac10b-58cc-4372-a567-0e02b2c3d479

Les 32 chiffres hexadécimaux représentent 128 bits de données. Le format se décompose comme suit : les 8 premiers chiffres (32 bits) représentent la composante liée au temps dans les UUID basés sur le temps, suivis d'un groupe de 4 chiffres (16 bits), puis d'un groupe de 4 chiffres (16 bits) qui contient le numéro de version, puis d'un groupe de 4 chiffres (16 bits) qui contient la variante, et enfin d'un groupe de 12 chiffres (48 bits) représentant le nœud ou la composante aléatoire.

Le numéro de version est intégré au troisième groupe. Par exemple, dans l'UUID f47ac10b-58cc-4372-a567-0e02b2c3d479, le chiffre 4 après le troisième tiret indique qu'il s'agit d'un UUID version 4. La variante est indiquée par les bits les plus significatifs du quatrième groupe. Le format UUID prend également en charge une représentation canonique sans tirets (f47ac10b58cc4372a5670e02b2c3d479), ainsi qu'une notation URN (urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479).

Comment les UUID sont générés

Les différentes versions d'UUID utilisent des stratégies différentes pour générer des identifiants uniques. Comprendre ces stratégies vous aide à choisir la bonne version pour votre application.

UUID v1 (basé sur le temps)

L'UUID v1 combine un horodatage actuel, une séquence d'horloge et l'adresse MAC du nœud. Le timestamp est un compteur de 60 bits d'intervalles de 100 nanosecondes depuis le 15 octobre 1582 (date de la réforme du calendrier grégorien). Cela donne à l'UUID v1 la propriété d'être monotoniquement croissant dans le temps, ce qui peut être bénéfique pour la performance des index de base de données.

Cependant, l'UUID v1 a des implications de confidentialité parce que l'adresse MAC identifie la machine spécifique qui a généré l'UUID. Un attaquant qui observe plusieurs UUID v1 peut déterminer l'adresse MAC de la machine et potentiellement la suivre dans différents contextes. Pour cette raison, l'UUID v1 est rarement utilisé dans les applications publiques, sauf si l'adresse MAC est remplacée par une valeur aléatoire de 48 bits.

UUID v4 (aléatoire)

L'UUID v4 génère 122 bits aléatoires (6 bits sont réservés pour les indicateurs de version et de variante), ce qui donne environ 5,3 x 10^36 valeurs possibles. C'est la version d'UUID la plus couramment utilisée car elle ne nécessite ni coordination, ni état, ni accès réseau. N'importe quel nœud peut générer un UUID v4 à n'importe quel moment avec une probabilité de collision astronomiquement faible.

Le caractère aléatoire de l'UUID v4 doit provenir d'un générateur de nombres aléatoires cryptographiquement sûr (CSPRNG) pour que les sorties soient imprévisibles. L'utilisation d'un générateur aléatoire faible, comme Math.random() en JavaScript dans les anciens navigateurs, peut conduire à des collisions en pratique parce que l'état interne du générateur peut se répéter.

UUID v7 (ordonné dans le temps)

L'UUID v7 est une version plus récente définie dans la RFC 9562 qui combine un horodatage Unix en millisecondes avec des bits aléatoires. Le timestamp occupe les bits les plus significatifs, ce qui rend les UUID v7 monotoniquement croissants dans le temps. Cette propriété d'ordre améliore considérablement la performance des index de base de données par rapport à v4, où l'ordre aléatoire provoque une fragmentation d'index et des divisions de pages dans les index B-tree.

Pour les applications modernes, l'UUID v7 est le choix recommandé pour les clés primaires de base de données. Il offre la même résistance aux collisions que v4 tout en offrant les caractéristiques de performance séquentielles des entiers. Les grandes bases de données comme PostgreSQL, MySQL 9+ et SQLite ont ajouté un support natif pour la génération d'UUID v7.

Comparaison des versions d'UUID

Les versions 3 et 5 sont des UUID déterministes. Avec le même espace de noms et le même nom, elles produiront toujours le même UUID. Cela est utile lorsque vous avez besoin d'un identifiant cohérent pour une ressource à travers différents systèmes sans stocker le mappage. Par exemple, vous pouvez générer un UUID v5 pour l'adresse e-mail d'un utilisateur dans l'espace de noms de votre application afin de créer un identifiant utilisateur cohérent entre plusieurs microservices.

Probabilité de collision des UUID v4

La probabilité de collision des UUID v4 est souvent mal comprise. Le paradoxe des anniversaires nous indique que les collisions deviennent probables lorsque le nombre d'UUID générés approche la racine carrée du nombre total de valeurs possibles. Pour l'UUID v4, la racine carrée de 2^122 est approximativement 2^61, soit environ 2,3 x 10^18 UUID.

Pour mettre cela en perspective, si vous génériez 1 milliard d'UUID par seconde, il faudrait environ 73 ans pour atteindre une chance de 50 % d'avoir une collision unique. Pour pratiquement toutes les applications concrètes, vous pouvez considérer les collisions d'UUID v4 comme impossibles.

L'UUID v4 a approximativement 5,3 x 10^36 valeurs possibles. Il faudrait générer environ 2,7 x 10^18 UUID pour avoir une chance de 50 % de collision.

Quand utiliser les UUID

Le choix de la bonne version d'UUID dépend de votre cas d'usage et de votre infrastructure.

Pour les systèmes de base de données distribués où les enregistrements sont créés sur différents serveurs et fusionnés plus tard, les UUID éliminent le besoin d'une génération centralisée d'identifiants. L'UUID v7 est fortement préféré pour ce cas d'usage car sa nature ordonnée par le temps permet aux index B-tree de maintenir de bonnes performances lorsque de nouvelles lignes sont insérées. Les utilisateurs PostgreSQL peuvent utiliser la fonction gen_random_uuid() pour v4, ou des extensions comme pg_uuidv7 pour le support de v7.

Pour les identifiants de session, l'UUID v4 fournit un niveau de randomisation suffisant pour empêcher les attaques de prédiction. Les noms de fichiers générés avec un UUID v4 évitent les conflits lorsque les utilisateurs téléversent des fichiers portant des noms courants comme "document.pdf" ou "image.jpg". Lorsque les UUID doivent apparaître dans des URL, leur encodage en Base64 réduit la longueur de chaîne de 36 caractères à 22, rendant les URL plus lisibles.

Quand ne pas utiliser les UUID

Bien que les UUID soient polyvalents, ce n'est pas le bon choix pour chaque situation.

• Numérotation séquentielle (utiliser l'auto-incrément). Si votre application s'exécute sur un seul serveur de base de données et n'a pas besoin de fusionner des données provenant de plusieurs sources, les entiers auto-incrémentés offrent de meilleures performances, un stockage plus petit et un débogage plus simple.

• URLs courtes (utiliser des identifiants plus courts comme nanoid). Une chaîne UUID complète contient 36 caractères, ce qui est trop long pour les raccourcisseurs d'URL, les codes de parrainage ou tout contexte où la brièveté compte. Des bibliothèques comme nanoid génèrent des identifiants plus courts et sûrs pour les URL avec un alphabet et une longueur configurables.

• Identifiants lisibles par l'humain. Les UUID ne sont pas destinés à être lus, saisis ou mémorisés par des humains. Pour les numéros de facture, les identifiants de commande ou les codes de référence client, utilisez un format plus simple à communiquer verbalement, comme des codes alphanumériques avec chiffres de contrôle.

• Petits ensembles de données (moins de 100 lignes). Si votre jeu de données est suffisamment petit pour que les entiers auto-incrémentés n'épuisent jamais leur plage dans votre vie, il n'y a aucun avantage à utiliser des UUID. Le coût de stockage supplémentaire (16 octets pour un UUID contre 4 octets pour un entier 32 bits) est inutile.

Générer des UUID dans le code

Bien que les générateurs en ligne soient pratiques pour un usage ponctuel, vous générerez généralement des UUID par programmation dans votre application.

JavaScript (navigateur)

const uuid = crypto.randomUUID();
console.log(uuid); // "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Node.js

const { randomUUID } = require('crypto');
const uuid = randomUUID();

Python

import uuid

# Version 4
uuid_v4 = uuid.uuid4()
print(uuid_v4)

# Version 1
uuid_v1 = uuid.uuid1()
print(uuid_v1)

PostgreSQL

-- Version 4
SELECT gen_random_uuid();

-- Version 7 (nécessite l'extension pg_uuidv7)
CREATE EXTENSION IF NOT EXISTS pg_uuidv7;
SELECT uuidv7_generate();

Utilisez l'outil UUID Generator pour générer différentes versions d'UUID en ligne sans écrire de code.