Générateur UUID

Créez des identifiants uniques universels (UUID) pour vos applications.

UUID v4 (Recommandé)

Aléatoire, le plus utilisé. 122 bits d'entropie.

UUID v1

Basé sur timestamp + MAC. Triable chronologiquement.

Génération en masse

Nombre d'UUID :

Cliquez sur "Générer" pour créer plusieurs UUID...

Valider un UUID

Guide complet des UUID : l'identifiant qui a révolutionné mes architectures

Pourquoi j'ai abandonné les ID auto-incrémentés

Après avoir vécu plusieurs fusions de bases de données catastrophiques — où des milliers d'ID entraient en conflit — j'ai compris que les identifiants séquentiels étaient une dette technique majeure. Un UUID (Universally Unique Identifier) est un identifiant de 128 bits, standardisé par la RFC 4122, qui garantit l'unicité sans coordination centrale. Son format canonique 8-4-4-4-12 (comme 550e8400-e29b-41d4-a716-446655440000) est devenu un standard que je retrouve partout : APIs REST, logs distribués, tokens de session, noms de fichiers cloud. Avec 2^122 combinaisons possibles pour la version 4, la probabilité de collision est si faible qu'elle est considérée comme mathématiquement nulle en pratique.

Les différentes versions d'UUID et leurs cas d'usage

🕐 UUID v1 — Basé sur le temps

Combine timestamp (100-nanosecondes depuis le 15 octobre 1582) et adresse MAC de la machine. Avantages : triable chronologiquement, traçabilité temporelle. Inconvénients : expose des informations sur l'heure et la machine de création, problématique pour la vie privée.

🎲 UUID v4 — Aléatoire pur

122 bits générés aléatoirement (6 bits réservés pour la version et la variante). C'est la version que j'utilise 90% du temps : aucune information extractible, parfait pour les tokens de sécurité, simple à implémenter avec un bon CSPRNG.

🔗 UUID v3/v5 — Basé sur un nom

Hash d'un namespace + nom (MD5 pour v3, SHA-1 pour v5). Déterministe : la même entrée produit toujours le même UUID. Idéal pour créer des identifiants stables à partir de données existantes (email, URL).

⚡ UUID v7 — Le meilleur des deux mondes

Nouvelle version (RFC 9562) : timestamp Unix en millisecondes + aléatoire. Triable comme v1, mais sans exposer d'informations sensibles. Idéal pour les clés primaires en base de données — c'est devenu mon choix par défaut.

Comment utiliser cet outil

Choisissez la version — v4 pour la plupart des cas, v1 si vous avez besoin de tri chronologique
Générez un UUID — Cliquez sur « Générer » pour obtenir un nouvel identifiant
Copiez le résultat — Un clic copie l'UUID dans votre presse-papiers
Génération en masse — Besoin de 100 UUID ? Utilisez la section « Génération en masse »
Validez un UUID existant — Collez un UUID pour vérifier sa validité et identifier sa version

Mes cas d'utilisation quotidiens

Clés primaires distribuées — Chaque service génère ses propres ID sans coordination, fusion de bases triviale
Tokens de session et CSRF — v4 garantit l'imprévisibilité requise pour la sécurité
Noms de fichiers cloud — Aucune collision possible même avec des millions de fichiers
Correlation ID dans les logs — Trace une requête à travers tous les microservices
Identifiants d'objets métier — Clients, commandes, factures — l'UUID évite le problème des séquences exposées
Idempotency keys — v5 avec les données de la requête garantit l'unicité des opérations

Considérations de performance et stockage

Un UUID occupe 16 octets en binaire, 36 caractères en texte. Pour les bases de données à fort volume, je recommande le stockage en BINARY(16) plutôt qu'en VARCHAR(36) — économie de 55% d'espace et index plus performants. Attention : UUID v4 fragmente les index B-tree car les valeurs sont aléatoires. Solutions : UUID v7 (ordonné), ou ULID/Snowflake pour les cas extrêmes de performance.

Questions fréquentes

UUID v4 peut-il vraiment créer des doublons ? Quelle est la probabilité réelle ?

Théoriquement oui, pratiquement c'est impossible. Avec 122 bits d'entropie, il existe 5.3×10^36 combinaisons possibles. Pour avoir 50% de chance de collision (paradoxe des anniversaires), il faudrait générer environ 2.71×10^18 UUID — soit 1 milliard par seconde pendant 85 ans.

En perspective : même si chaque être humain sur Terre générait 1 million d'UUID par jour, il faudrait des milliers d'années pour atteindre une probabilité de collision de 1%. La seule vraie cause de doublons en pratique est un générateur aléatoire défectueux (comme ce bug célèbre sur certains téléphones Android en 2013).

Dois-je utiliser UUID comme clé primaire en base de données ? Quels sont les pièges ?

Avantages indéniables : génération décentralisée (pas besoin de contacter la BDD), fusion de bases triviale, ID imprévisibles (sécurité), pas de fuite d'information sur le volume de données.

Inconvénients à considérer :

Taille — 16 octets vs 4-8 pour un INT, impact sur les jointures et la mémoire
Fragmentation d'index — UUID v4 aléatoire cause des insertions dispersées dans les B-trees, dégradant les performances sur InnoDB
Lisibilité — Difficile à communiquer verbalement ou mémoriser

Mes recommandations : utilisez UUID v7 (ordonné temporellement), stockez en BINARY(16), ou adoptez une approche hybride avec INT interne + UUID externe public.

Minuscules ou majuscules ? Avec ou sans tirets ? Quelle est la bonne convention ?

La RFC 4122 recommande les minuscules pour la génération, mais spécifie que la comparaison doit être insensible à la casse. Les deux sont techniquement valides et représentent le même identifiant.

Pour les tirets : le format canonique les inclut (8-4-4-4-12), mais certains systèmes les omettent pour économiser 4 caractères. Les deux sont interopérables après normalisation.

Mon conseil : choisissez une convention pour votre projet et appliquez-la partout. Normalisez toujours avant comparaison (toLowerCase() + suppression tirets si nécessaire). Dans les URLs, les minuscules sans tirets sont plus compactes.

Comment identifier la version d'un UUID à partir de sa chaîne ?

C'est encodé dans la structure même de l'UUID. Le 13e caractère (premier du 3e groupe) indique la version :

xxxxxxxx-xxxx-1xxx-yxxx = Version 1 (timestamp + MAC)
xxxxxxxx-xxxx-4xxx-yxxx = Version 4 (aléatoire)
xxxxxxxx-xxxx-5xxx-yxxx = Version 5 (SHA-1 namespace)
xxxxxxxx-xxxx-7xxx-yxxx = Version 7 (timestamp Unix)

Le 17e caractère (premier du 4e groupe) doit être 8, 9, A ou B pour un UUID RFC 4122 valide — c'est l'indicateur de variante. Notre outil de validation détecte automatiquement ces éléments.

UUID v1 expose-t-il vraiment mon adresse MAC ? Est-ce un risque de sécurité ?

Oui, par conception. Les 48 derniers bits d'un UUID v1 authentique contiennent l'adresse MAC de la machine. En pratique, cela permet de :

Identifier la machine qui a généré l'UUID
Déterminer le fabricant de la carte réseau
Potentiellement corréler des activités entre systèmes

C'est pourquoi je déconseille v1 pour les identifiants exposés publiquement. La plupart des implémentations modernes utilisent un « node ID » aléatoire au lieu de la vraie MAC, mais ce n'est pas garanti. Préférez v4 ou v7 pour les identifiants publics.

Quelle est la différence entre UUID, GUID, ULID et Snowflake ID ?

UUID (Universally Unique Identifier) — Standard RFC 4122, 128 bits, format texte 36 caractères avec tirets.

GUID (Globally Unique Identifier) — Terme Microsoft pour UUID. Techniquement identique, parfois affiché avec accolades {xxxxxxxx-xxxx-...}.

ULID (Universally Unique Lexicographically Sortable Identifier) — 128 bits mais encodé en Base32 (26 caractères). Timestamp en tête = triable lexicographiquement. Plus compact et performant sur les index.

Snowflake ID — Format Twitter/Discord, 64 bits : timestamp + worker ID + séquence. Triable, plus compact, mais nécessite une coordination pour assigner les worker IDs.

Comment stocker efficacement les UUID en base de données ?

Plusieurs approches selon votre SGBD :

PostgreSQL — Type natif UUID, optimal en performance et espace (16 octets)
MySQL/MariaDB — BINARY(16) avec fonctions UUID_TO_BIN()/BIN_TO_UUID() (MySQL 8+). Évitez CHAR(36) qui gaspille de l'espace
SQL Server — UNIQUEIDENTIFIER natif, mais attention : ordre de tri non chronologique par défaut
MongoDB — BinData subtype 4 pour un stockage optimal

Astuce MySQL : utilisez UUID_TO_BIN(uuid, 1) avec le flag swap pour réordonner les octets du timestamp, améliorant les performances d'index avec UUID v1/v7.

Les UUID générés par cet outil sont-ils sécurisés pour un usage cryptographique ?

Cet outil utilise l'API Web Crypto (crypto.getRandomValues()), qui est un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG). C'est la même source d'aléa utilisée pour TLS et les opérations cryptographiques du navigateur.

UUID v4 généré avec un CSPRNG est considéré sûr pour :

Tokens de session et d'authentification
Tokens CSRF et nonces
Clés d'API (bien que des formats plus longs soient préférables)
Secrets partagés temporaires

Important : tout le traitement se fait localement dans votre navigateur. Aucun UUID n'est transmis à un serveur — vérifiable dans les DevTools réseau.