Générateur UUID

Génération d'identifiants UUID v4: aléatoire, local et personnalisable

Cette page permet de produire un ou plusieurs identifiants UUID version 4 – des chaînes de 36 caractères au format hexadécimal standard 8-4-4-4-12. Vous contrôlez le nombre d’identifiants (jusqu’à 100), la casse (minuscules par défaut, majuscules si souhaité) et la présence des tirets (inclus par défaut). Les identifiants sont générés instantanément dans votre navigateur grâce à un générateur de nombres aléatoires cryptographique; aucun échange de données avec un serveur n’a lieu. Vous pouvez copier un identifiant unique en cliquant dessus ou l’ensemble des identifiants via le bouton « Copier tout ».

Qu’est-ce qui distingue cette page des autres générateurs UUID?

Contrairement à UUID v7 ou ULID, UUID v4 utilise 122 bits d’aléa pur, sans horodatage intégré. Chaque valeur est imprévisible et la probabilité de collision est négligeable. Mais cette absence d’information temporelle signifie que les UUID v4 se trient arbitrairement – ils ne portent aucune chronologie. Pour une base de données, cela fragmente les index lorsque l’UUID sert de clé primaire. La page vous permet de basculer entre minuscules et majuscules, d’activer ou désactiver les tirets, mais le noyau aléatoire et le format restent fixes. Le comportement est immédiat: tout changement d’option (nombre, casse, tirets) régénère l’intégralité du jeu d’identifiants.

Structure technique d’un UUID version 4

Un UUID v4 est un identifiant de 128 bits défini par la spécification RFC 4122. Sur ces 128 bits, 122 sont aléatoires (générés par le navigateur), les 6 bits restants sont réservés pour la version et la variante. La version (4) occupe 4 bits dans le troisième groupe, et la variante (RFC 4122) en occupe 2 dans le quatrième groupe. Les 122 bits d’aléa se répartissent sur les 16 octets de l’identifiant.

Visuellement, un UUID v4 se présente sous la forme xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, où x est un chiffre hexadécimale aléatoire, 4 indique la version, et y est un chiffre hexadécimale dont les bits de poids fort valent 10 (soit 8, 9, a, ou b en hexadécimal). Au total, 32 caractères hexadécimaux plus quatre tirets, soit 36 caractères.

La page respecte strictement cette structure. Elle utilise l’API crypto.getRandomValues() du navigateur, un générateur de nombres pseudo-aléatoires cryptographiquement solide, disponible dans tous les environnements modernes (navigateurs, Node.js, etc.). Cela garantit que les bits aléatoires proviennent du système d’exploitation et offrent une qualité suffisante pour des applications sensibles (jetons de sécurité, identifiants de session).

Probabilité de collision et qualité du hasard

Avec 122 bits d’aléa, la probabilité de générer deux UUID v4 identiques est extrêmement faible. En pratique, pour atteindre une probabilité de collision de 50 %, il faudrait générer environ 2,7 × 10^18 identifiants (environ 2,7 trillions). C’est le fameux « birthday paradox » appliqué à un espace de 2^122 ≈ 5,3 × 10^36 valeurs possibles. Pour des volumes de génération de quelques milliers d’identifiants, le risque est négligeable.

Le générateur utilisé côté navigateur produit chaque UUID en une fraction de milliseconde. Les 122 bits aléatoires sont tirés de l’entropie du système: horloge, interruptions, mouvements de souris, etc. Comme tout traitement est local, la qualité du hasard ne dépend pas de la latence réseau ni d’un serveur distant. C’est un atout pour les applications hors ligne ou soumises à des contraintes de confidentialité.

Impact sur les performances des bases de données

L’un des inconvénients majeurs de l’UUID v4 est le désordre d’insertion dans un index B-tree (comme celui d’une clé primaire en PostgreSQL ou MySQL). Contrairement à un entier auto-incrémenté ou à un UUID v7 (qui intègre un timestamp ordonnable), les UUID v4 sont dispersés uniformément dans l’espace des valeurs. Chaque nouvel enregistrement peut se trouver n’importe où dans l’index, ce qui provoque des éclatements de pages (page splits) et fragmente l’index. Sur des tables volumineuses, cela dégrade les performances en écriture.

Cette page ne fait pas de recommandation sur l’utilisation d’UUID v4 comme clé primaire – elle fournit simplement l’outil pour en générer. Mais le fait de mentionner cet inconvénient dans la fiche source montre l’importance de comprendre le choix: si l’ordre temporel est pertinent, il vaut mieux préférer UUID v7 ou ULID. Pour des identifiants imprévisibles et non séquentiels (jetons, identifiants anonymisés), UUID v4 reste le meilleur choix.

Personnalisation de l’affichage: casse et tirets

La page offre deux bascules simples: « Uppercase » (faux par défaut) et « Include hyphens » (vrai par défaut). Le changement de l’une ou l’autre régénère immédiatement tout le lot.

• Uppercase: les lettres hexadécimales (a-f) passent en majuscules. Par exemple, 550e8400-e29b-41d4-a716-446655440000 devient 550E8400-E29B-41D4-A716-446655440000. Certains systèmes ou formats (ex. certains logs, fichiers CSV) préfèrent la majuscule pour la lisibilité.
• Hyphen suppression: les quatre tirets sont retirés. Le format passe de 36 à 32 caractères. 550e8400e29b41d4a716446655440000 est valide comme représentation d’un UUID, bien que moins lisible. Certaines API ou collisions acceptent cette chaîne compacte.

Il est important de noter que ces options n’altèrent en rien la valeur sous-jacente. L’UUID reste le même; seules les conventions de notation changent. Le copier-coller d’un identifiant conserve exactement la forme affichée.

Utilisations pratiques et cas d’usage

Les développeurs ont fréquemment besoin d’identifiants uniques et imprévisibles. UUID v4 est utilisé pour:

• Jetons d’authentification (sessions, accès API): l’absence d’horodatage évite de fuir des informations temporelles.
• Identifiants de transaction: nécessité d’unicité à l’échelle d’un système distribué.
• Données de test: génération de jeux de données avec des clés non séquentielles.
• Identifiants anonymisés: remplacer des données personnelles par des UUID v4 garantit qu’on ne peut pas déduire l’ordre de création.

La page permet de générer jusqu’à 100 identifiants en une seule opération. Cela couvre les besoins courants: un lot de 10 ou 20 identifiants pour un petit projet, ou 100 pour remplir une table de test. Le nombre minimum est 1. Tout nombre en dehors de l’intervalle 1–100 n’est pas accepté.

Questions fréquentes

Pourquoi les UUID générés commencent-ils parfois par un « 4 » dans le troisième groupe? C’est le bit de version. Le troisième groupe affiche toujours 4xxx (le 4 est fixe selon RFC 4122). Cela permet de reconnaître immédiatement un UUID v4.

Puis-je utiliser ces UUID hors ligne? Oui. Toute la génération a lieu dans votre navigateur, sans appel réseau. Même déconnecté, vous pouvez produire des identifiants valides.

Que se passe-t-il si je change le nombre d’identifiants après avoir copié certains résultats? Le changement de l’un des paramètres (nombre, casse, tirets) régénère immédiatement tous les identifiants. Les valeurs précédentes sont perdues. Copiez d’abord ce dont vous avez besoin avant de modifier les options.

Les identifiants sont-ils vraiment imprévisibles? Oui, car ils reposent sur crypto.getRandomValues(), une source d’aléa cryptographique. Même si un attaquant connaissait la valeur d’un UUID, il ne pourrait pas en déduire les suivants. C’est adapté pour des jetons de sécurité.

Puis-je obtenir les 122 bits exacts d’aléa en sortie? L’UUID affiché est la représentation hexadécimale standard. Si vous avez besoin des octets bruts, vous pouvez convertir la chaîne, mais l’interface propose uniquement la forme texte.

Pourquoi le format 8-4-4-4-12 est-il imposé? C’est la représentation canonique des UUID depuis la RFC 4122. Même sans tirets, la disposition des 32 chiffres hexadécimaux suit cet ordre, mais sans les séparateurs. Le navigateur ne propose pas d’autre disposition – et tout autre format ne serait pas un UUID standard.