NanoID vs UUID : quel identifiant choisir ?

Lors de la conception d'applications web modernes, d'architectures de microservices et de schémas de bases de données, la création d'identifiants uniques, imprévisibles et résistants aux collisions est une nécessité incontournable. Pendant des décennies, l'identifiant universel unique (UUID), en particulier sa version aléatoire UUID v4, a fait figure de référence absolue. Cependant, le développement applicatif contemporain impose souvent des identifiants plus compacts, plus ergonomiques dans les URLs et plus légers que les chaînes hexadécimales traditionnelles de 36 caractères.

C'est précisément pour répondre à cette exigence qu'a été créé NanoID, un générateur d'identifiants textuels compacts, sécurisés et directement utilisables dans les URLs. En résumé : utilisez NanoID lorsque vos identifiants sont exposés dans des URLs publiques, des liens de partage, des paramètres d'API REST ou des bundles JavaScript front-end où la compacité et l'ergonomie visuelle priment ; utilisez l'UUID (notamment l'UUID v7 ou v4) pour vos clés primaires de bases de données relationnelles bénéficiant d'un type natif sur 16 octets ou pour les intégrations d'entreprise exigeant des schémas normalisés par l'IETF.

Vous pouvez configurer, tester et générer ces identifiants immédiatement grâce au générateur NanoID ou au générateur d'UUID de ToolPorta. Ce guide technique analyse en profondeur l'entropie mathématique de chaque format, compare leurs performances de stockage et d'indexation en base de données, met en lumière les pièges de collation et de collision, et propose une méthodologie claire pour choisir l'identifiant le plus adapté à votre pile logicielle.

Anatomie technique : NanoID vs UUID#

Pour comparer objectivement ces deux approches, il convient d'analyser la manière dont elles génèrent leur entropie aléatoire et mettent en forme leurs chaînes de caractères.

L'UUID : Le standard hexadécimal de 128 bits#

Normalisé par la RFC 4122 et actualisé par la RFC 9562, un UUID standard est une valeur binaire de 128 bits représentée sous la forme de 32 chiffres hexadécimaux séparés par quatre tirets selon la structure canonique 8-4-4-4-12 (soit 36 caractères au total) :

1f47ac10b---a567-2|---  --|---|---|---|----  ---|

Dans un UUID v4, 6 bits indiquent la version et la variante, laissant 122 bits variables. La RFC 9562 recommande un générateur cryptographiquement sûr lorsque l'imprévisibilité compte, mais sa qualité dépend de l'implémentation.

L'hexadécimal utilise 16 symboles : chaque chiffre représente donc 4 bits. Avec quatre tirets structurels, la forme canonique d'un UUID compte 36 caractères.

NanoID : Une entropie dense sur 64 symboles compatibles avec les URLs#

Créé en 2017 par Andrey Sitnik, NanoID a été conçu pour éliminer la verbosité des UUIDs tout en conservant une résistance aux collisions équivalente, voire supérieure.

Par défaut, NanoID génère une chaîne de 21 caractères en utilisant un alphabet de 64 symboles non réservés pour les URLs :

• Lettres latines majuscules : A-Z (26 symboles)
• Lettres latines minuscules : a-z (26 symboles)
• Chiffres décimaux : 0-9 (10 symboles)
• Symboles de ponctuation sans risque pour les URLs : _ et - (2 symboles)

Exemple de NanoID :

1V1StGXR8_Z5jdHi6B-myT2|-----  caractères -----|

Avec un tirage uniforme parmi 64 symboles, chaque caractère contribue 6 bits à l'espace des identifiants. Le NanoID par défaut offre donc 21 × 6 = 126 bits de combinaisons possibles.

NanoID rassemble donc 126 bits d'entropie en seulement 21 caractères, offrant une résistance mathématique aux collisions supérieure à celle de l'UUID v4 (122 bits), tout en réduisant la longueur de la chaîne de plus de 41 %. De plus, tous ces caractères respectent scrupuleusement la norme RFC 3986, ce qui garantit qu'ils ne nécessitent aucun encodage pourcent (%20, %2F) au sein d'une URL ou d'une chaîne de requête.

Calculs de sécurité et probabilité de collision#

Une question récurrente des ingénieurs consiste à savoir si le passage de 36 à 21 caractères augmente le risque d'obtenir des doublons d'identifiants.

L'implémentation JavaScript officielle de NanoID utilise la source aléatoire cryptographique de l'environnement. Les bibliothèques UUID v4 maintenues font généralement de même, mais la seule conformité au format RFC ne prouve pas qu'un générateur donné soit sûr.

Selon l'approximation des anniversaires, la probabilité vaut environ 1 - exp(-n² / (2N)), où n désigne le nombre généré et N la taille de l'espace :

Ces estimations supposent des tirages indépendants et uniformes. En pratique, une panne de générateur ou un défaut d'implémentation peut dominer le risque mathématique : conservez une contrainte d'unicité et gérez les conflits d'insertion.

Stockage en base de données et indexation : Les compromis#

Si NanoID s'impose sur le plan de la compacité visuelle et de l'ergonomie web, l'UUID conserve des atouts majeurs au sein des bases de données relationnelles.

1. Encombrement disque : 16 octets natifs vs 21 octets textuels#

Les moteurs relationnels modernes (tels que PostgreSQL et CockroachDB) disposent d'un type natif uuid. En coulisses, le moteur stocke la chaîne de 36 caractères sous la forme d'un entier binaire compact de 16 octets.

À l'inverse, NanoID ne peut pas être compressé dans un type natif standard de 16 octets sans algorithme de décodage spécifique. Il est donc stocké sous forme textuelle :

• VARCHAR(21) : Nécessite 21 octets bruts plus 1 ou 2 octets pour le préfixe de longueur.
• Dans des colonnes textuelles avec encodage UTF-8 multi-octets, l'indexation de chaînes de caractères requiert davantage de mémoire vive et d'espace disque qu'un type uuid binaire optimisé.

2. Fragmentation des index B-tree et tri séquentiel#

L'UUID v4 et le NanoID par défaut sont tous deux purement aléatoires. Lorsqu'ils sont insérés comme clés primaires dans un index B-tree (comme InnoDB dans MySQL ou les index b-tree de PostgreSQL), leur dispersion aléatoire provoque des séparations de pages (page splits), une amplification des écritures et une dégradation du cache mémoire.

L'écosystème UUID dispose d'une réponse normalisée à ce problème : l'UUID v7 (RFC 9562). En incorporant un horodatage Unix en millisecondes sur 48 bits, l'UUID v7 améliore généralement la localité des insertions. Pour comprendre ce mécanisme, consultez notre comparatif sur l'UUID v4 vs UUID v7.

NanoID ne propose pas de standard officiel ordonné dans le temps. Bien qu'il soit possible d'adjoindre un préfixe temporel à une chaîne NanoID, cette pratique ne bénéficie pas du support natif des moteurs SQL.

Pièges fréquents et cas particuliers#

L'utilisation de NanoID ou d'UUID nécessite de prêter attention à plusieurs particularités techniques :

1. Collisions dues aux collations insensibles à la casse#

Par défaut, l'alphabet de NanoID distingue rigoureusement les minuscules et les majuscules (a et A sont deux valeurs distinctes).

Si vous enregistrez des NanoIDs dans une table de base de données relationnelle utilisant une collation insensible à la casse (comme la collation par défaut de MySQL utf8mb4_general_ci ou utf8mb4_unicode_ci) :

• Le moteur de base de données considérera que v1stgxr8... et V1STGXR8... sont strictement identiques.
• La contrainte d'unicité déclenchera alors une erreur de doublon inattendue (Duplicate entry '...' for key 'PRIMARY').

Solution : Configurez systématiquement la colonne ou la table SQL avec une collation binaire ou sensible à la casse (par exemple COLLATE utf8mb4_bin sous MySQL).

2. Réduction excessive de la longueur de NanoID#

L'une des fonctionnalités les plus appréciées de NanoID est sa modularité. Avec les bibliothèques logicielles ou le générateur NanoID de ToolPorta, vous pouvez fixer la longueur à 8, 10 ou 12 caractères.

Réduire la longueur diminue fortement l'espace disponible :

• 10 caractères : 60 bits. À 1 000 identifiants par heure, le risque estimé atteint 1 % après environ 17 ans, pas quelques mois.
• 8 caractères : 48 bits. À la même cadence, le seuil de 1 % arrive après environ 100 jours.

Dimensionnez la longueur selon l'alphabet, le volume total prévu et le risque accepté. Les codes courts nécessitent aussi une nouvelle tentative en cas de conflit et, souvent, un périmètre limité ou une expiration.

3. Confusion visuelle sur les caractères ambigus#

Dans l'alphabet standard de NanoID, des symboles comme 0 (zéro) et O (O majuscule), ou 1 (chiffre un), l (L minuscule) et I (i majuscule) présentent des graphies très proches selon les polices de caractères. Si vos utilisateurs doivent ressaisir l'identifiant manuellement (code SMS, confirmation téléphonique), les erreurs de lecture se multiplient.

Pour les identifiants destinés à une saisie humaine, utilisez un alphabet personnalisé excluant les symboles ambigus, ou utilisez le générateur de mot de passe de ToolPorta avec l'option d'exclusion des caractères similaires.

Tableau comparatif : NanoID vs UUID#

Méthodologie décisionnelle : Quel identifiant adopter ?#

Appliquez cette grille d'analyse en 4 étapes pour arrêter votre choix d'architecture :

1. Où l'identifiant est-il principalement manipulé ?
   • S'il apparaît en premier lieu dans des URLs publiques, des routes d'API, des liens de partage ou des interfaces front-end, choisissez NanoID. Sa compacité de 21 caractères et son absence de tirets offrent une expérience utilisateur optimale.
   • S'il réside principalement au cœur de tables de données, de files de messages ou de traitements batch internes, passez à l'étape 2.
2. Concevez-vous la clé primaire d'une base de données relationnelle à fort volume ?
   • Si oui, optez pour l'UUID v7. Son stockage natif sur 16 octets et son insertion séquentielle évitent la fragmentation des index.
   • Si non, passez à l'étape 3.
3. Devez-vous respecter des schémas d'entreprise rigides ou des environnements Microsoft ?
   • Si votre système dialogue avec .NET, COM ou des structures 128 bits strictes, consultez notre guide sur les différences UUID vs GUID ou utilisez l'UUID v4.
   • Si non, passez à l'étape 4.
4. Avez-vous besoin de codes personnalisés ou lisibles par un humain ?
   • Si vous devez générer des codes promotionnels, des jetons courts ou des chaînes sans caractères ambigus, utilisez NanoID avec un alphabet adapté.

Foire aux questions#

Peut-on remplacer les UUIDs par des NanoIDs dans une base de données ?#

Oui, à condition de stocker les valeurs dans une colonne VARCHAR(21) dotée d'une collation sensible à la casse (comme utf8mb4_bin sous MySQL). Gardez à l'esprit que ce stockage textuel occupe légèrement plus de mémoire qu'une colonne binaire uuid de 16 octets et que les insertions aléatoires dans un index B-tree provoqueront des séparations de pages.

NanoID est-il cryptographiquement sûr ?#

L'implémentation NanoID officielle utilise la source aléatoire cryptographique de l'environnement et un échantillonnage par rejet qui évite le biais de modulo. Cela convient à de nombreux identifiants aléatoires, mais un jeton d'authentification exige aussi une longueur adaptée, une expiration, un modèle de menace et un traitement serveur sûr.

Pourquoi les collations insensibles à la casse posent-elles problème avec NanoID ?#

L'alphabet standard de 64 symboles de NanoID différencie les minuscules et les majuscules. Si une colonne de base de données applique une collation insensible à la casse (comme les collations se terminant par _ci), deux chaînes ne différant que par la casse seront considérées comme des doublons par le moteur SQL, ce qui déclenchera une violation de contrainte d'unicité.

Essayez les outils d'identifiants de ToolPorta#

Affinez l'architecture de vos applications grâce aux outils d'identifiants en ligne de ToolPorta :

• Utilisez le générateur NanoID pour produire des identifiants compacts et sécurisés avec sélection d'alphabet et export par lot.
• Utilisez le générateur d'UUID pour générer des identifiants conformes aux versions v4 et v7 de la RFC 9562 pour vos bases de données.
• Utilisez le générateur de mot de passe pour concevoir des jetons d'accès et des phrases secrètes hautement sécurisées.
• Consultez notre étude sur l'UUID v4 vs UUID v7 pour approfondir la gestion des index de bases de données.
• Explorez notre guide sur les différences UUID vs GUID pour maîtriser l'interopérabilité binaire multi-plateformes.