Qu'est-ce qu'un UUID exactement ?
Un UUID (Universally Unique Identifier) est un identifiant de 128 bits standardisé par la RFC 4122. Il se présente sous cette forme :
550e8400-e29b-41d4-a716-446655440000
Cinq groupes de caractères hexadécimaux séparés par des tirets, toujours 36 caractères au total. L'aspect "universellement unique" vient de la combinaison du temps, de l'aléatoire et/ou d'un espace de noms selon la version choisie.
Les UUID s'utilisent quand vous devez générer des identifiants sans autorité centrale comme un compteur auto-incrémenté en base de données. Ils conviennent parfaitement aux systèmes distribués, aux identifiants créés côté client, et aux situations où un aller-retour vers un serveur est inenvisageable.
Quelles sont les différentes versions d'UUID ?
La version d'un UUID détermine la stratégie de génération. Elle est encodée dans le troisième groupe de l'identifiant (le chiffre après le second tiret).
UUID v1 - Basé sur le temps Généré à partir du timestamp courant combiné à l'adresse MAC de la machine. Unique entre machines au même instant, mais l'adresse MAC expose l'identité de la machine - un problème de confidentialité dans certains contextes.
UUID v3 - Basé sur un nom (MD5) Déterministe : le même nom et le même espace de noms produisent toujours le même UUID. Utilise MD5. Utile pour générer des identifiants stables pour des ressources connues. MD5 étant cryptographiquement faible, préférez v5 pour les nouveaux projets.
UUID v4 - Aléatoire (le plus répandu) Généré à partir de 122 bits de données aléatoires. La version la plus utilisée aujourd'hui. La probabilité de collision entre deux UUID v4 est astronomiquement faible - environ 1 sur 5,3 x 10^36 pour deux identifiants donnés.
UUID v5 - Basé sur un nom (SHA-1) Identique à v3 mais utilise SHA-1 au lieu de MD5. À préférer pour les nouveaux projets nécessitant des identifiants déterministes basés sur un nom.
UUID v7 - Aléatoire ordonné par le temps (nouvelle norme) Introduit dans la révision 2022 de la RFC. Combine un préfixe horodatage à précision milliseconde avec des bits aléatoires. Ce préfixe temporel permet aux UUID v7 d'être triés chronologiquement, un avantage décisif pour les clés primaires en base de données car l'insertion séquentielle préserve la localité des index B-tree.
Comment choisir la bonne version ?
Le choix dépend de votre cas d'usage précis.
Pour les clés primaires en base de données, UUID v7 est le choix moderne recommandé. Les bases de données relationnelles comme PostgreSQL et MySQL subissent une fragmentation des index avec UUID v4 car les valeurs sont entièrement aléatoires. UUID v7 résout ce problème grâce à son préfixe temporel croissant.
Pour les identifiants d'API et les URL publiques, UUID v4 reste le standard universel. Il ne révèle aucune information sur l'heure de création ni sur le volume de données, contrairement aux entiers séquentiels.
Pour les identifiants déterministes basés sur une ressource connue (par exemple, toujours générer le même UUID pour un email donné), UUID v5 avec un espace de noms approprié est la solution correcte.
En JavaScript, crypto.randomUUID() est disponible nativement dans les navigateurs modernes et Node.js depuis la version 14.17 - il génère du v4.
UUID vs ULID vs NanoID : quelles différences ?
Ces trois formats répondent à des besoins proches mais avec des compromis différents.
ULID (Universally Unique Lexicographically Sortable Identifier) : similaire à UUID v7 dans son principe. Encodé en base 32 Crockford, ce qui le rend plus compact visuellement (26 caractères) et triable lexicographiquement par le temps. Bon choix quand la lisibilité humaine et le tri comptent.
NanoID : plus court (21 caractères par défaut), composé de caractères URL-safe, avec un alphabet configurable. Populaire pour les URL courtes et les identifiants visibles dans l'interface utilisateur. Pas de version temporelle - entièrement aléatoire.
UUID v4 reste le choix le plus universellement supporté quand la compatibilité avec les systèmes existants prime. Chaque base de données majeure, chaque framework, chaque langage le comprend nativement.
Pour les bases de données à fort volume d'insertions, UUID v7 ou ULID surpassent v4 sur les performances d'index. Pour les URL publiques courtes, NanoID gagne en lisibilité.
Quels sont les cas d'usage concrets en développement ?
Dans les projets réels, les UUID apparaissent à de nombreux endroits.
Clés primaires distribuées : dans un système avec plusieurs nœuds d'écriture (microservices, bases répliquées), chaque service peut générer ses propres identifiants sans coordination. Avec des entiers séquentiels, il faudrait une source centrale - un goulot d'étranglement.
Identifiants de ressources API : exposer /api/commandes/12345 révèle que vous avez au moins 12 344 commandes. Exposer /api/commandes/550e8400-e29b-41d4-a716-446655440000 ne révèle rien. C'est une pratique courante pour protéger des informations commerciales sensibles.
Nommage de fichiers uploadés : renommer un fichier uploadé avec un UUID v4 avant stockage élimine les conflits de noms et les traversées de chemin malveillantes. Amazon S3, Cloudflare R2 et les services similaires fonctionnent bien avec cette approche.
Clés d'idempotence pour les paiements : lors d'une transaction par carte, le client génère un UUID côté client et l'envoie avec la requête. Si la requête est rejouée (timeout réseau, retry automatique), le serveur de paiement reconnaît la clé et renvoie le résultat existant sans débiter deux fois.
Tokens de session et de réinitialisation de mot de passe : UUID v4 génère un token suffisamment long et aléatoire pour être résistant à la force brute, sans nécessiter de bibliothèque cryptographique supplémentaire pour ce type d'usage.
Les UUID posent-ils des problèmes de performance ?
Sur des tables de petite taille (moins de quelques millions de lignes), la différence est imperceptible. Sur des tables à fort trafic d'insertion, UUID v4 peut causer une fragmentation des pages d'index car les nouvelles valeurs sont insérées aléatoirement dans l'arbre B, forçant des réorganisations fréquentes.
PostgreSQL 17 intègre le support natif d'UUID v7 via la fonction gen_random_uuid() étendue. MySQL 8 propose UUID_TO_BIN(UUID(), 1) pour ordonner les bits temporels en tête.
En pratique, si votre table dépasse quelques dizaines de millions de lignes avec des insertions continues, passez à UUID v7 ou ULID. En dessous, UUID v4 est parfaitement acceptable et sa simplicité prime.
Comment générer des UUID sans dépendance externe ?
Dans les navigateurs modernes et Node.js, crypto.randomUUID() suffit pour v4. Côté serveur, PHP propose Ramsey\Uuid\Uuid::uuid4()->toString(), Python import uuid; uuid.uuid4(), Go github.com/google/uuid.
Pour UUID v7, les bibliothèques dédiées sont encore nécessaires dans la plupart des langages en dehors de ceux qui ont déjà adopté la RFC révisée nativement.
Si vous avez besoin de générer rapidement un ou plusieurs UUID sans installer quoi que ce soit, le générateur ci-dessous fonctionne directement dans votre navigateur, sans compte ni serveur.