Générateur UUID

Générez gratuitement des UUID/GUID v1, v4, v5 ou Nil. Production en lot, options de formatage, copie rapide et téléchargement. Idéal pour les développeurs.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Générateur UUID - Identifiants uniques universels

Créez instantanément des UUID dans les versions 1, 4, 5 ou Nil avec des réglages de formatage. Pratique pour les clés primaires, IDs de session ou tout scénario nécessitant des identifiants uniques.

L'UUID v4 est-il vraiment unique ?

L'UUID v4 n'est pas garanti unique — il est probabilistiquement unique au point où les collisions ne sont pas une préoccupation pratique. Un UUID v4 a 122 bits aléatoires (6 bits sont réservés aux marqueurs de version et variante), donnant 2^122 valeurs possibles (environ 5,3 × 10^36). Par le paradoxe des anniversaires, vous devriez générer environ 2,71 quintillions d'UUIDs pour avoir 50% de chance d'une seule collision — à un milliard par seconde, cela prend 85 ans. Pour comparaison, chaque grain de sable sur Terre est environ 7,5 × 10^18, donc l'espace UUID v4 est plus de 10^17 fois plus grand. Le hic est la qualité de votre source aléatoire : un PRNG faible (Math.random au lieu de crypto.getRandomValues, ou un RNG mal initialisé au premier démarrage) réduit dramatiquement l'entropie effective. Ce générateur utilise l'API Web Crypto pour de l'aléa de qualité cryptographique.

Quelle version d'UUID devrais-je utiliser : v1, v4, v6 ou v7 ?

UUID v1 (timestamp + adresse MAC, RFC 4122) est principalement déprécié car il divulgue le MAC de l'hôte et révèle le temps de création. UUID v4 (aléatoire, RFC 4122) est le choix par défaut pour les identifiants généraux — IDs qui ne devraient rien révéler. UUID v6 réordonne les octets timestamp de v1 pour être triables mais divulgue toujours le MAC. UUID v7 (RFC 9562, finalisé 2024) est le gagnant moderne pour les clés primaires de base de données : les 48 premiers bits sont un timestamp Unix en millisecondes suivi de 74 bits aléatoires, donc les IDs v7 trient chronologiquement et fonctionnent bien avec les index B-tree tout en restant imprévisibles. UUID v8 est une version personnalisée libre réservée pour des layouts spécifiques à l'application. Pour les nouveaux systèmes en 2026, par défaut v7 pour les clés de base de données, v4 pour tout ce qui ne devrait pas divulguer d'information.

Quels sont les bits de version et variante, et où sont-ils dans l'UUID ?

Un UUID est rendu comme huit-quatre-quatre-quatre-douze chiffres hex (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). Le premier nibble du troisième groupe (M) est la version : 1, 4, 7, etc. Les deux premiers bits du quatrième groupe (N) encodent la variante : 10 en binaire (donc le premier caractère est toujours 8, 9, a ou b) marque les UUIDs RFC 4122 / RFC 9562. C'est pourquoi un UUID v4 valide a toujours le motif xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Une vérification regex rapide rejette les IDs mal formés avant qu'ils n'atteignent votre base de données. Les bits réservés coûtent six au total — laissant 122 bits aléatoires en v4 — et garantissent que les UUIDs de différentes specs (l'ancienne variante GUID de Microsoft, futures versions) sont distinguables sans ambiguïté.

Devrais-je utiliser des UUIDs comme clés primaires dans ma base SQL ?

Cela dépend de la base de données et de la version UUID. Les UUIDs v4 comme clés primaires nuisent significativement aux performances d'InnoDB et SQL Server : les positions d'insertion aléatoires causent des divisions de page et la fragmentation de l'index groupé, et la taille de 16 octets double le stockage de chaque index secondaire par rapport à un int de 4 octets. PostgreSQL avec le type uuid et un index btree gère mieux v4 mais perd encore certains avantages d'insertion séquentielle. Le préfixe monotoniquement croissant d'UUID v7 résout le problème de fragmentation — les insertions s'ajoutent à la fin de l'index comme un entier auto-incrément. Les avantages des UUIDs : globalement uniques sans coordination, sûrs pour fusionner les bases de données, pas d'attaques d'énumération sur les URLs /users/123, compatibles systèmes distribués. Pour les nouveaux schémas, par défaut UUID v7.

Générateur UUID — Générez gratuitement des UUID/GUID v1, v4, v5 ou Nil. Production en lot, options de formatage, copie rapide et télécharg — **Générateur UUID**

Quelle est la différence entre un UUID et un GUID ?

Fonctionnellement aucune — « GUID » (Globally Unique Identifier) est le nom de Microsoft pour le même identifiant 128 bits défini dans la RFC 4122. La disposition des octets encodés est identique : 16 octets bruts. Le rendu textuel est le même : huit-quatre-quatre-quatre-douze hex. La légère différence historique est l'ordre des octets : le format GUID hérité de Microsoft stockait les trois premiers champs en little-endian (Data1, Data2, Data3) sur disque, tandis que la RFC 4122 spécifie big-endian (ordre des octets réseau). Cela signifie qu'un GUID binaire exporté depuis une API COM Windows et relu comme octets sur un système Unix apparaîtra avec les octets échangés dans les 8 premiers octets. Les systèmes modernes se normalisent sur la représentation hex textuelle. Pour le type uniqueidentifier de Microsoft SQL Server, les octets sur disque sont toujours dans l'ordre hérité.

Puis-je raccourcir un UUID pour utiliser dans les URLs sans perdre l'unicité ?

Oui — les 128 bits d'un UUID peuvent être encodés de manière plus compacte que la forme hex à 36 caractères (avec tirets) en changeant d'alphabet. UUID encodé en Base64 fait 22 caractères (24 avec remplissage), Base64 URL-safe avec remplissage retiré fait 22 caractères, et Base58 (sans caractères confondables comme 0/O/l/I) fait 22 caractères. Crockford Base32 fait 26 caractères et est convivial pour les humains. Tous sont sans perte : le destinataire décode vers les mêmes 16 octets. Ne JAMAIS couper de caractères — cela détruit la garantie d'unicité. Un hash 64 bits comme FNV ou xxHash depuis l'UUID donne une sortie de 16 caractères mais échange les collisions contre la longueur et n'est plus un UUID. Des alternatives comme Nano ID ou ULID donnent une convivialité URL similaire dès le début sans l'étape de traduction UUID. ULID utilise même Crockford Base32 triable par design.

Les UUIDs sont-ils cryptographiquement sûrs ou sûrs pour les tokens de sécurité ?

UUID v4 généré depuis un RNG cryptographique (Web Crypto, /dev/urandom, BCryptGenRandom) a 122 bits d'entropie, ce qui dépasse la directive symétrique 128 bits moins les 6 bits fixes de version/variante. C'est suffisant pour les tokens de session, les liens de réinitialisation de mot de passe et les clés d'idempotence — comparable à une chaîne Base64 aléatoire de 21 caractères. La mise en garde : les UUIDs de bibliothèques de langages plus anciens qui s'appuient sur Math.random ou un seeding basé sur le temps ne sont PAS cryptographiquement sûrs et ont été cassés en pratique (attaques de prédiction du prochain UUID contre uniqid de PHP, java.util.UUID avec seeds non sûrs). Vérifiez que votre source utilise crypto.randomUUID (navigateur/Node 19+), uuid.uuid4 soutenu par os.urandom (Python), ou System.Security.Cryptography (.NET). Les UUIDs v1, v6 et v7 exposent des timestamps et ne devraient pas être utilisés comme secrets.

Pourquoi mon UUID ressemble-t-il à 00000000-0000-0000-0000-000000000000 et qu'est-ce que l'UUID nil ?

L'UUID tout-zéros est l'UUID nil (RFC 4122 section 4.1.7), réservé comme sentinelle signifiant « absent » ou « pas encore assigné ». C'est l'équivalent UUID de NULL, utile dans les bases de données où la colonne est NOT NULL mais la ligne n'a pas encore reçu d'identifiant réel. Son homologue, l'UUID max (tout-Fs, ffffffff-ffff-ffff-ffff-ffffffffffff) a été formalisé dans la RFC 9562 comme la borne supérieure universelle — utile pour les requêtes de plage et comme équivalent LSN dans les logs append-only. Les deux sont des UUIDs légaux mais n'apparaissent jamais comme sortie aléatoire : la chance de générer l'un par accident est de 1 sur 2^122, effectivement zéro. Si vous voyez l'UUID nil dans les données de production, votre code a très probablement échoué à initialiser la valeur avant l'insertion — ajoutez une vérification défensive et tracez jusqu'au constructeur.