Générateur d'UUID — v4, v7 et nil

Générez des UUID frais (v4 ou v7) dans votre navigateur via l'API Web Crypto. Choisissez le nombre, copiez une seule valeur ou toutes d'un coup. Rien n'est envoyé à un serveur.

Qu'est-ce qu'un UUID ?

Un UUID (identifiant unique universel) est une valeur de 128 bits formatée en 32 caractères hexadécimaux répartis en cinq groupes séparés par des tirets (8-4-4-4-12). Deux UUIDs bien choisis ont une probabilité infime de collision, même générés sur des machines distinctes sans coordination — propriété idéale pour les clés primaires, IDs de requête, noms de fichiers et tokens d'idempotence.

L'UUID v4 est entièrement aléatoire et a longtemps été le défaut. L'UUID v7 (RFC 9562, 2024) embarque un timestamp Unix en millisecondes dans les 48 premiers bits, ce qui rend les IDs triables par date de création et bien plus efficaces dans les index de bases de données. L'UUID nil est un placeholder tout-zéro pour signifier « pas de valeur » dans les champs qui exigent un UUID.

Comment utiliser cet outil

Choisissez la version : v4 pour de l'aléatoire pur, v7 pour des IDs triables par le temps, nil pour la sentinelle tout-zéro.
Choisissez la quantité à générer (1 à 100). La liste se régénère instantanément à chaque changement de paramètre.
Cliquez sur Copier à côté d'une ligne pour récupérer une seule valeur, ou Tout copier pour mettre toute la liste (un UUID par ligne) dans votre presse-papiers.

Questions fréquentes

Ces UUIDs sont-ils cryptographiquement sûrs ?

Oui. Nous utilisons crypto.randomUUID() (ou crypto.getRandomValues() en repli) du navigateur, qui exposent tous deux le CSPRNG de la plateforme. Les bits aléatoires conviennent à des identifiants de session non devinables et à des tokens secrets.

Faut-il utiliser v4 ou v7 en base de données ?

v7 est généralement le meilleur défaut. Comme les IDs v7 sont triés par date de création, les index B-tree (PostgreSQL, MySQL, SQL Server par défaut) restent compacts et les insertions touchent la page la plus à droite. v4 fragmente les index et ralentit les insertions sur les grandes tables.

Deux UUIDs générés peuvent-ils entrer en collision ?

En théorie oui ; en pratique, non. v4 a 122 bits aléatoires — générer un milliard d'UUIDs par seconde pendant cent ans donne encore une probabilité de collision inférieure à 1 sur un milliard. v7 mélange 74 bits aléatoires et un timestamp, donc deux collisions exigeraient la même milliseconde et le même suffixe aléatoire.

Que signifie « triable » pour v7 ?

Triez les IDs lexicographiquement (tri de string) et vous les obtenez par ordre de création. Cette propriété élimine le besoin d'une colonne created_at séparée quand un tri grossier suffit, et rend les requêtes par tranche de temps efficaces même sans index sur une colonne timestamp.

L'UUID nil est-il sûr à utiliser ?

C'est un UUID valide, utile comme placeholder, mais ne l'utilisez jamais pour une vraie entité — beaucoup d'ORM et de frameworks le traitent comme « absent ». Si votre base a une colonne UUID NOT NULL avec un défaut, préférez DEFAULT gen_random_uuid() (Postgres) ou un v7 généré plutôt que la valeur nil.

Cas d'usage courants

Là où sortir un UUID est le bon choix.

Clés primaires de base de données

Évitez les IDs séquentiels qui exposent le volume métier dans les URLs et permettent aux attaquants d'itérer. Les UUIDs sont non devinables, peuvent être générés côté client sans aller-retour à la base, et fusionnent proprement entre systèmes distribués.

Clés d'idempotence pour les API

Générez un UUID par action utilisateur logique et passez-le en header Idempotency-Key. Le serveur peut alors dédupliquer les retries en sécurité — exactement le pattern utilisé par Stripe et d'autres APIs de paiement.

Correlation IDs dans les logs distribués

Attachez le même UUID à chaque ligne de log, span et requête downstream produits par une seule action utilisateur. Chercher cet ID dans votre agrégateur ramène toute la trace cross-services.

Noms de fichiers uniques

Nommer les fichiers uploadés <uuid>.<ext> évite les collisions de noms, supprime le besoin d'assainir l'entrée utilisateur et prévient les attaques par path-traversal via des noms de fichiers craftés.

Conseils et astuces

Habitudes qui rendent les UUIDs plus faciles à vivre.

Préférez v7 pour les nouveaux schémas

Sauf raison spécifique de vouloir des IDs entièrement non triés (sécurité par obscurité dans les URLs, par exemple), v7 est plus rapide sur disque, plus facile à déboguer — vous pouvez lire le timestamp — et tout aussi résistant aux collisions que v4.

Stockez en UUID natif, pas en string

PostgreSQL, MySQL 8 et SQL Server ont des types UUID/UNIQUEIDENTIFIER natifs qui stockent 16 octets au lieu de 36. L'économie compte à grande échelle et la comparaison est plus rapide.

N'exposez pas v1 ou v2 publiquement

v1 fuit l'adresse MAC de la machine génératrice. v2 (DCE Security) fuit l'UID POSIX. Les deux sont obsolètes ; utilisez v4 ou v7 à la place.

Coupez les tirets si vous devez raccourcir

Retirer les quatre tirets fait passer la string de 36 à 32 caractères et reste réversible. Évitez d'encoder les octets en Base64 — le résultat est plus court (22 caractères) mais n'est plus reconnaissable comme UUID et casse les outils attendant le format canonique.