Générateur UUID

Qu'est-ce qu'un UUID ?

Un UUID (Universally Unique Identifier) est un nombre de 128 bits utilisé pour identifier de manière unique des informations à travers des systèmes distribués, sans avoir besoin d'une autorité centrale. Les UUID sont normalisés par la RFC 4122 et utilisés partout — des clés primaires de bases de données au suivi de requêtes API, en passant par la gestion de session et la nomenclature de fichiers.

Le format standard d'un UUID comporte 36 caractères avec quatre traits d'union : xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, où M indique la version (1 à 5) et N la variante. La version la plus utilisée est l'UUID v4, qui génère des identifiants à partir d'aléa cryptographique. Cet outil génère par défaut des UUID v4.

Format UUID v4

L'UUID v4 utilise 122 bits aléatoires (les 6 bits restants encodent la version et le variant). Le format est xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, où chaque x est un chiffre hexadécimal aléatoire et y vaut 8, 9, A ou B. Le 4 dans le troisième groupe l'identifie comme version 4. Chaque UUID v4 est généré indépendamment grâce à un aléa cryptographique.

Comment utiliser cet outil

Cliquez sur le bouton de génération pour créer un nouveau UUID v4. Chaque clic produit un identifiant inédit, généré de manière cryptographiquement aléatoire. Vous pouvez générer plusieurs UUID à la fois pour des opérations par lot. Cliquez sur le bouton de copie pour copier le UUID dans votre presse-papiers, prêt à être utilisé dans du code, des configurations ou des bases de données.

Cas d'usage courants des UUID

• Clés primaires de base de données : les UUID permettent à des systèmes distribués de créer des enregistrements de manière indépendante sans collision de clés, contrairement aux entiers auto-incrémentés qui imposent une coordination.
• ID de requête API : associez un UUID à chaque requête API pour assurer une traçabilité de bout en bout entre microservices.
• Jetons de session : créer des identifiants de session uniques et impossibles à deviner.
• Noms de fichiers : générez des noms uniques pour éviter les collisions lorsque plusieurs utilisateurs téléversent en même temps.
• Clés d'idempotence : utiliser des UUID dans les API de paiement pour garantir qu'une même transaction n'est pas traitée deux fois.

Probabilité de collision

L'UUID v4 dispose de 122 bits aléatoires, soit 5,3 × 10³⁶ valeurs possibles. La probabilité de générer deux UUID identiques est astronomiquement faible. Il faudrait générer 2,71 × 10¹⁸ UUID (2,71 quintillions) avant d'atteindre 50 % de probabilité d'une seule collision. En pratique, les collisions ne constituent pas une préoccupation réaliste, quelle que soit l'application.

UUID nul

Le UUID nul (00000000-0000-0000-0000-000000000000) est une valeur spéciale définie dans la RFC 4122 comme valeur fictive ou par défaut. Certaines applications l'utilisent pour représenter « aucune valeur » ou « inconnu » dans des colonnes de base de données typées UUID, à la manière dont null fonctionne pour d'autres types de données.

Comparaison des versions d'UUID

L'UUID v1 utilise l'horodatage actuel et l'adresse MAC de l'appareil — rapide, mais susceptible de divulguer des informations sur la machine. Les UUID v3 et v5 génèrent des UUID déterministes à partir d'un espace de noms et d'un nom, en utilisant respectivement MD5 et SHA-1. L'UUID v4 repose sur l'aléa pur et offre le meilleur compromis entre unicité, simplicité et confidentialité. L'UUID v7 (standard en projet) combine un préfixe d'horodatage et de l'aléa pour produire des UUID triables dans le temps.

Mon UUID est-il sûr ?

Oui. La génération utilise l'API native crypto.randomUUID() du navigateur, qui fournit un aléa cryptographiquement sûr. Tous les traitements ont lieu localement sur votre appareil. Aucun UUID n'est journalisé, stocké ni transmis à un serveur.

Questions fréquentes

Faut-il utiliser des UUID ou des identifiants auto-incrémentés ?

Les UUID sont mieux adaptés aux systèmes distribués, aux architectures microservices et à tous les contextes où des enregistrements sont créés sur plusieurs serveurs. Les identifiants auto-incrémentés sont plus simples, plus compacts (4 à 8 octets contre 16) et plus efficaces pour l'indexation en base de données. Choisissez en fonction de votre architecture : les systèmes centralisés peuvent utiliser l'auto-incrémentation, les systèmes distribués profitent des UUID.

Les UUID doivent-ils être stockés sous forme de chaînes de caractères en base de données ?

Non. La plupart des bases de données prennent en charge un type UUID natif qui stocke la valeur sur 16 octets, au lieu de la représentation en chaîne de 36 caractères. PostgreSQL propose un type de colonne UUID, MySQL peut utiliser BINARY(16) et MongoDB dispose de son propre sous-type binaire UUID. Le recours aux types natifs économise de l'espace de stockage et améliore les performances des requêtes.