Générer des Identifiants UUID v4 Aléatoires
Générez autant d'UUID v4 aléatoires que nécessaire pour vos bases de données et votre code, instantanément.
Les valeurs ne quittent jamais votre appareil
Rien n’est journalisé nulle part
Aléa au niveau du système
Fonctionne dans tout navigateur moderne
Comment ça marche
- 1
Choisissez une version
v4, sauf si l’identifiant part dans un index de base de données : envisagez alors v7.
- 2
Choisissez la quantité
Un pour un test rapide, ou un lot pour des données initiales et des jeux de test.
- 3
Copiez le résultat
Emportez-le dans un schéma, une requête, un fichier de configuration ou un test.
Pourquoi cet outil
Version 4 et version 7
Aléatoire pour l’usage courant, ou ordonné par horodatage quand la valeur devient une clé primaire.
Aléa cryptographique
Produit par la source sécurisée du navigateur, non par une fonction pseudo-aléatoire prévisible.
Génération en lot
Un identifiant ou mille, produits d’un coup et prêts à coller dans un fichier de données initiales.
Avec ou sans tirets
La forme canonique de 36 caractères ou la version nue de 32, selon ce qu’attend la destination.
Rien n’est transmis
Les valeurs sont produites dans votre navigateur : aucun tiers n’apprend quels identifiants vous avez utilisés.
Gratuit et sans compte
Aucune inscription, aucun filigrane et aucune limite sur le nombre généré.
La version compte plus qu’on ne le croit
On dit UUID et l’on pense version 4, soit 122 bits aléatoires et rien d’autre. C’est le bon réglage par défaut, mais ce n’est pas la seule version et les différences ont des conséquences. La version 1 construit l’identifiant à partir d’un horodatage et de l’adresse matérielle réseau de la machine : un UUID v1 révèle donc discrètement quand il a été créé et, historiquement, quelle machine l’a créé — acceptable à l’intérieur d’un système, gênant dans tout ce qu’un client peut voir. La version 7, normalisée récemment, conserve l’aléa mais place un horodatage à la milliseconde dans les bits de tête, si bien que les valeurs se trient chronologiquement. Si vous avez déjà généré un UUID sans réfléchir à son type, c’était presque certainement du v4, et pour la plupart des usages c’est la bonne réponse. L’exception est ci-dessous.
Les identifiants aléatoires malmènent un index de base de données
C’est le fait pratique le plus lourd de conséquences au sujet des UUID, et il surprend ceux qui viennent des entiers. Un index est une structure triée, et les structures triées aiment les valeurs qui arrivent dans l’ordre. Une suite d’entiers s’ajoute à la fin de l’index, touche une seule page encore et encore et la garde en mémoire. Un flux d’UUID v4 est aléatoire par conception : chaque insertion tombe ailleurs, ce qui force l’index à écrire dans des pages dispersées, à les scinder et à conserver bien plus de structure en cache pour suivre. Sur une grande table, l’écart est mesurable, et le symptôme est l’histoire connue d’un système devenu lent après l’adoption de clés UUID. La version 7 existe précisément pour cela : l’horodatage de tête fait que les nouvelles valeurs se trient les unes près des autres, si bien que les insertions redeviennent locales tandis que les identifiants restent indevinables.
Un UUID n’est pas un secret, sauf si vous en faites un délibérément
Deux affirmations se mélangent ici, et les deux comptent. La première : un UUID v4 est réellement indevinable — 122 bits aléatoires dépassent de loin la force brute — mais seulement si l’aléa est cryptographique. Beaucoup de code produit des UUID à partir d’une fonction aléatoire généraliste, rapide et prévisible ; or des identifiants issus d’une source prévisible peuvent être énumérés par quiconque retrouve la graine. Vérifiez ce qu’utilise votre générateur. La seconde : même un v4 parfait est un identifiant, pas une autorisation. Employer un UUID indevinable comme lien de partage fonctionne, et cela signifie que l’URL est le mot de passe : elle restera dans l’historique, dans des en-têtes de référence, dans un journal de discussion et dans tout e-mail qui l’a transmise. C’est acceptable pour un lien vers un document, inacceptable pour ce qui doit pouvoir être révoqué.
Ce que dit réellement la garantie de collision
Si les UUID fonctionnent sans coordination, c’est grâce à un argument de probabilité, et les chiffres valent d’être connus pour cesser de s’en inquiéter. Avec 122 bits aléatoires, il faudrait générer environ 2,7 trillions d’UUID version 4 avant qu’il y ait cinquante pour cent de chances que deux d’entre eux coïncident. À un million par seconde, cela fait des dizaines de milliers d’années : voilà pourquoi des systèmes aux antipodes peuvent frapper des identifiants sans registre central et sans jamais se concerter. Ce dont la garantie dépend entièrement, c’est la qualité de l’aléa. Un générateur faible ou mal amorcé fait s’effondrer ce chiffre sans le moindre avertissement, et des UUID dupliqués en production remontent presque toujours à une source défaillante plutôt qu’à la malchance — plusieurs incidents connus impliquaient des appareils amorçant leur source d’aléa à l’identique au démarrage.
Les stocker coûte plus cher qu’on ne l’imagine
Un UUID fait 128 bits — 16 octets — mais la forme habituellement visible compte 36 caractères de texte, car la représentation canonique écrit chaque octet en deux chiffres hexadécimaux et ajoute quatre tirets. Stockez cela en chaîne et vous consommez 36 octets par ligne au lieu de 16, plus ce que votre base ajoute pour une colonne de longueur variable, et chaque index sur cette colonne subit la même inflation. Sur une table de quelques milliers de lignes, personne ne le remarque. Sur une table de cent millions, dans un index qui doit tenir en mémoire, c’est la différence entre tenir et ne pas tenir. La plupart des bases disposent d’un type natif de 16 octets exactement pour cela, et l’employer est en général le bon choix. Les détails de format sont mineurs à côté : les tirets relèvent de la convention, la comparaison ignore la casse et les minuscules constituent la sortie canonique.
Pourquoi générer en local compte même pour des valeurs aléatoires
On peut légitimement demander ce que la confidentialité vient faire avec un nombre aléatoire : la réponse est que le nombre cesse d’être anonyme dès qu’il est rattaché à quelque chose. Un générateur hébergé voit chaque identifiant qu’il délivre et peut le consigner avec l’adresse demandeuse et l’heure. Si ces UUID deviennent ensuite des références de commande, des liens de partage, des clés d’API ou des identifiants en base dans votre système, quelqu’un d’autre détient une liste de valeurs valides et une bonne idée de ce à quoi elles se rapportent. Le risque est faible et parfaitement évitable, car générer en local le supprime entièrement : votre navigateur embarque une source d’aléa cryptographique, les valeurs ne quittent pas la page, et vous pouvez vérifier qu’aucune requête n’a été émise dans l’onglet Réseau des outils de développement.
Erreurs courantes à éviter
- Employer des UUID v4 comme clés primaires sur une grande table. Les valeurs aléatoires dispersent les écritures d’index et le fragmentent — utilisez v7, dont l’horodatage de tête garde les insertions locales tout en restant indevinable.
- Générer des UUID avec une fonction aléatoire généraliste. Seule une source cryptographique les rend indevinables ; une graine prévisible permet d’énumérer les identifiants.
- Prendre un UUID indevinable pour une autorisation. Un lien de partage bâti dessus signifie que l’URL est le mot de passe, et les URL finissent dans l’historique, les en-têtes de référence et les e-mails transférés.
- Stocker un UUID en chaîne de 36 caractères à grande échelle. La valeur fait 16 octets ; la forme textuelle plus que double cela dans chaque ligne et chaque index — la plupart des bases ont un type natif.
- Employer v1 dans quoi que ce soit de visible par le client. Il encode l’heure de création et, historiquement, l’adresse matérielle réseau de la machine : plus qu’un identifiant n’a besoin de révéler.
Comparaison
| Critère | Cet outil | Générateurs en ligne | Un appel de bibliothèque |
|---|---|---|---|
| Valeurs transmises ou journalisées | Jamais | Possible | Non |
| v7 disponible | Oui | Rarement | Selon la bibliothèque |
| Aléa cryptographique | Oui | Rarement précisé | Le plus souvent oui |
| Génération en lot | Oui | Parfois | Oui |
| Fonctionne sans ouvrir de projet | Oui | Oui | Non |
| Prix | Gratuit | Gratuit / offres payantes | Gratuit |
Fonctionnalités
UUID v4
La version à 122 bits aléatoires que la plupart des systèmes désignent en disant UUID.
UUID v7
Préfixé par un horodatage et donc triable, ce que réclame un index de base de données.
Majuscules ou minuscules
La forme canonique est en minuscules ; certains systèmes exigent des majuscules, les deux sont là.
Génération en lot
Des centaines d’un coup, un par ligne, prêts pour un script de données initiales ou une colonne.
Utilise le CSPRNG de la plateforme
Les valeurs proviennent du générateur cryptographique du navigateur, non d’un générateur généraliste.
Instantané, sans requête
Rien n’est téléchargé : la génération est immédiate et fonctionne l’onglet déjà chargé.
Rien à installer
Pas de bibliothèque, pas d’environnement d’exécution, pas de dépendances : tout se passe sur la page web.
Compatible arabe et RTL
Interface complète en huit langues, dont l’arabe de droite à gauche.
Sécurisé par défaut
Servi en HTTPS, sans suivi ni requête vers un tiers.
Qui l’utilise
Développeurs
Obtenir un identifiant valide pour un jeu de test ou une ligne insérée à la main sans ouvrir de console.
Ingénieurs base de données
Produire des valeurs v7 quand une table réclame des clés indevinables qui s’indexent bien.
Ingénieurs QA
Générer d’un coup un lot d’identifiants uniques pour des données de test.
Intégrateurs d’API
Créer une clé d’idempotence ou un identifiant de corrélation pour une requête.
Questions Fréquentes
Non. Tout s’exécute localement dans votre navigateur — votre texte n’est jamais envoyé, stocké ni partagé.
Oui — entièrement gratuit, sans compte et sans limite.