Caractère alphanumérique : définition, utilisation en cryptographie, sécurité

Soixante-deux. C'est le nombre total de symboles distincts disponibles lorsqu'on vous demande d'utiliser uniquement des caractères alphanumériques. Vingt-six majuscules, vingt-six minuscules et dix chiffres. Sans tenir compte de la casse, ce nombre tombe à trente-six. Ces deux chiffres sont importants, car presque tous les identifiants numériques que vous avez déjà saisis (adresse de portefeuille, mot de passe Wi-Fi, hachage de transaction, jeton GitHub) sont construits à partir d'un sous-ensemble de ces soixante-deux symboles.

Le choix du sous-ensemble pertinent, et les raisons de ce choix, est une étape souvent négligée dans les explications. Pourtant, c'est précisément ce qui relie la définition encyclopédique d'un caractère alphanumérique à la sécurité concrète de votre portefeuille crypto. Cet article détaille le décompte des caractères, la norme sous-jacente, la manière dont la cryptographie moderne sélectionne ses sous-ensembles, et les recommandations actuelles de l'autorité américaine de sécurité des mots de passe. Certaines de ces recommandations ont évolué de façon trop récente pour être pleinement intégrées dans la plupart des conseils de sécurité.

Qu'est-ce qu'un caractère alphanumérique ? Définition et nombre

Commençons par la définition. Un caractère alphanumérique est une lettre de A à Z (en minuscules ou majuscules) ou un chiffre décimal de 0 à 9. C'est tout. Le calcul est ensuite évident : vingt-six lettres (en minuscules) et dix chiffres donnent soixante-deux caractères distincts en tenant compte de la casse, et trente-six sans. Tout le reste est considéré comme « spécial ». La ponctuation, les espaces, les symboles mathématiques, les lettres accentuées et les émojis ne sont pas considérés comme alphanumériques.

Les ingénieurs se conforment généralement à la définition grâce à l'une des deux notations abrégées suivantes. Les outils POSIX comme grep, sed et awk reconnaissent `[:alnum:]`, qui correspond aux soixante-deux caractères mentionnés précédemment. La plupart des langages d'expressions régulières modernes (Python, JavaScript, Java, PCRE) utilisent plutôt `\w`. Le problème avec `\w` est qu'il inclut subrepticement le tiret bas. Le tiret bas n'est pas formellement alphanumérique. La plupart des syntaxes de programmation le considèrent comme honorifique, ce qui explique pourquoi les préfixes de clés Stripe `sk_live_` et AWS `AKIA` mélangent tirets bas, lettres majuscules et chiffres sans que cela ne pose problème.

D'où vient ce terme ? Des cartes perforées, figurez-vous. Dans les années 1930, les machines de tabulation IBM nécessitaient un terme unique pour désigner les codes mêlant lettres et chiffres, et « alphanumérique » s'est imposé. Dès l'IBM 1401, au début des années 1960, le terme était entré dans le vocabulaire courant de l'informatique de gestion. Cette distinction avait une réelle importance pratique : un champ « alphanumérique » acceptait toute lettre ou tout chiffre ; un champ exclusivement numérique, en revanche, rejetait catégoriquement l'alphabet. De là, le terme s'est répandu dans les plaques d'immatriculation, les codes IBAN, les mnémoniques des claviers téléphoniques, les références produits et bien d'autres domaines.

La distinction entre les mots de passe sensibles et insensibles à la casse est plus importante qu'il n'y paraît. L'entropie des mots de passe double lorsque les majuscules sont autorisées. Les adresses Base58 de Bitcoin conservent volontairement les deux casses. Bech32, quant à lui, ignore volontairement la casse. Chaque choix implique un compromis entre expressivité et risque d'erreur humaine. Un mauvais choix peut entraîner des pertes financières dues à des fautes de frappe.

De l'ASCII à l'Unicode : un bref historique technique

« Alphanumérique » est aujourd'hui le survivant d'une guerre des normes qui a duré soixante ans. La plupart des utilisateurs se sont retrouvés pris entre deux feux et ne s'en sont jamais aperçus.

L'ASCII est apparu en premier. Il a été commercialisé en 1963 par l'American Standards Association et officialisé cinq ans plus tard sous la norme ANSI X3.4-1968. Deux révisions ont suivi : l'une en 1977, l'autre en 1986. La version de 1968 attribuait le numéro 65 à la lettre A majuscule, le numéro 97 au numéro 0, et les chiffres de 0 à 9 aux numéros 48 à 57. Ouvrez votre éditeur de texte : l'octet « A » a toujours la valeur 65. Rien n'a bougé en soixante ans.

Pendant près de quarante ans, l'ASCII a été l'ensemble alphanumérique de référence. Puis est arrivé le web. Sept bits ne suffisaient plus. Les problèmes étaient catastrophiques : courriels illisibles, bases de données corrompues, sites web japonais parfaitement fonctionnels à Tokyo mais illisibles sur un ordinateur portable américain. Unicode a fait son apparition en 1991 avec une ambition démesurée : attribuer un numéro unique à chaque caractère de chaque système d'écriture jamais créé. L'UTF-8 a suivi en 1992, devenant l'encodage permettant la diffusion d'Unicode sur les réseaux. Son atout ? La rétrocompatibilité : les 128 premiers points de code de l'UTF-8 correspondent exactement aux octets ASCII originaux de 1968. Les textes anglais diffusés avant 1991 sont restés fonctionnels indéfiniment.

Le changement s'est opéré en décembre 2007. Ce mois-là, les statistiques publiques d'exploration du Web ont finalement montré que l'UTF-8 dépassait l'ASCII comme encodage le plus courant en ligne. Dès lors, le terme « alphanumérique » a cessé de désigner strictement les soixante-deux symboles ASCII. Unicode répertorie désormais les blocs alphanumériques pour les alphabets cyrillique, grec, arabe, hébreu et CJK. Chaque alphabet possède ses propres lettres et ses propres chiffres.

En pratique, les logiciels qui doivent gérer des caractères à l'étranger utilisent toujours par défaut le sous-ensemble ASCII d'origine : les lettres latines de A à Z et les chiffres arabes de 0 à 9. Rien d'autre. La raison est simple : tous les claviers produisent des caractères ASCII, toutes les bases de données les acceptent et tous les moteurs d'expressions régulières les reconnaissent. Sortir de cette plage expose à une multitude de bogues d'encodage, de caractères similaires et aux attaques de phishing que j'aborderai plus loin.

Caractères alphanumériques en cryptographie : adresses, hachages, clés de chiffrement

Voici un point souvent négligé dans les explications générales : les systèmes de cryptomonnaie n’utilisent jamais l’intégralité des soixante-deux caractères alphanumériques. Ils sélectionnent des sous-ensembles soigneusement choisis. Chaque sous-ensemble représente un compromis technique documenté, et non un choix esthétique arbitraire.

Bitcoin d'abord. Une adresse Bitcoin classique (commençant par 1 ou 3) est encodée en Base58. Cet alphabet a été conçu à la main par Satoshi Nakamoto. La recette : prenez l'ensemble alphanumérique de soixante-deux caractères et supprimez-en quatre. Supprimez le zéro, le O majuscule, le I majuscule et le l minuscule. Pourquoi ces quatre-là ? Écrivez-les sur un Post-it avec une écriture illisible. Éloignez-vous. Revenez cinq minutes plus tard. Essayez de les distinguer. Impossible. C'est précisément le problème que Base58 a été conçu pour résoudre. Il reste cinquante-huit caractères. Une adresse classique compte donc entre vingt-six et trente-cinq caractères, suffisamment courts pour être recopiés à la main si nécessaire.

SegWit a été activé en août 2017. Avec lui est apparu un second format d'adresse Bitcoin : Bech32, défini dans le BIP-173. Bech32 propose une approche différente. La sensibilité à la casse disparaît complètement : toutes les adresses sont en minuscules. Quatre caractères spécifiques sont supprimés : le chiffre 1, ainsi que les lettres b, i et o. Les trente-deux caractères restants contiennent une somme de contrôle intégrée. Cette somme de contrôle détecte automatiquement la quasi-totalité des fautes de frappe. Taproot, en ligne depuis novembre 2021, a affiné le format en Bech32m (BIP-350) après la découverte d'une faille dans les calculs initiaux.

Ethereum a opté pour une troisième voie : l’utilisation de l’hexadécimal. Une adresse Ethereum est composée de `0x` suivi de quarante caractères hexadécimaux, soit quarante-deux caractères au total. L’hexadécimal réduit les caractères alphanumériques à seize éléments seulement : les chiffres de 0 à 9 et les lettres de a à f. Ce choix paraissait judicieux en 2015. Aujourd’hui, après des années passées à déchiffrer des amas hexadécimaux bruts dans MetaMask, le résultat est peu lisible. L’EIP-55 a apporté la solution. Elle consiste à mettre en majuscules certaines lettres selon un modèle dérivé du hachage Keccak-256 de l’adresse en minuscules. On obtient ainsi une détection automatique des fautes de frappe. L’EIP-55 détecte les fautes de frappe avec une fiabilité d’environ 99,975 %. Le taux d’erreur est d’environ 0,0247 %. Faible, certes, mais pas nul.

Les hachages constituent le cas le plus simple. Un hachage SHA-256 est codé sur 256 bits et s'affiche sous forme de 64 caractères hexadécimaux. Le Keccak-256 d'Ethereum produit un résultat de longueur identique. L'identifiant d'une transaction Bitcoin (txid) est le hachage SHA-256 de la transaction elle-même ; il est donc également composé de 64 caractères alphanumériques hexadécimaux. Sur un explorateur de blocs, leur apparence peut paraître intimidante, mais il s'agit de caractères purement alphanumériques.

Les phrases de récupération rompent avec la tradition. La récupération de portefeuille BIP-39 est le seul cas où les cryptomonnaies abandonnent le format alphanumérique pour revenir à un format purement alphabétique. La norme encode 128 ou 256 bits d'entropie sous forme de douze ou vingt-quatre mots anglais tirés d'une liste fixe de 2 048 mots. Chaque mot est composé uniquement de lettres minuscules : ni chiffres, ni majuscules et minuscules. Pourquoi ? Parce que le but est de permettre à une personne d'écrire sur papier à 3 h du matin après la panne de son téléphone, et que les chiffres introduisent une ambiguïté que les lettres n'ont pas.

Chaque sous-ensemble est un élément de conception centré sur l'humain, dissimulé au sein d'un système profondément technique.

Mots de passe alphanumériques : ce que le NIST dit réellement en 2024

La plupart des conseils relatifs aux mots de passe disponibles sur Internet sont obsolètes depuis plusieurs années. Utiliser une combinaison de majuscules et de minuscules, ajouter des chiffres, inclure au moins un caractère spécial, le changer tous les 90 jours : ces règles ont fait jurisprudence pendant vingt ans. L’Institut national des normes et de la technologie des États-Unis les a officiellement abandonnées.

La publication spéciale 800-63B du NIST, référence fédérale en matière de recommandations sur l'identité numérique, a finalisé sa révision 4 en septembre 2024. Cette nouvelle version se distingue par l'ampleur des simplifications qu'elle apporte. La longueur minimale recommandée pour l'authentification à facteur unique a été portée à quinze caractères. Les règles de composition des caractères sont formulées comme une interdiction : les services ne doivent pas exiger de classes de caractères spécifiques. L'expiration périodique des mots de passe, cette rotation de 90 jours tant impopulaire, a également été supprimée. Désormais, le NIST exige que les services vérifient les mots de passe soumis par rapport à une liste noire d'identifiants compromis connus.

Ce changement se justifie par les calculs d'entropie. Un ensemble alphanumérique de 62 caractères produit environ 5,95 bits par caractère. L'ensemble complet des 95 caractères ASCII imprimables (alphanumériques et caractères spéciaux) en produit 6,57. L'ajout de tous les caractères spéciaux augmente la complexité de 0,62 bit par caractère. L'ajout d'un caractère supplémentaire de longueur donnée permet d'atteindre les 5,95 bits. La longueur du caractère influence la complexité d'un ordre de grandeur.

Le rapport 2025 de Verizon sur les enquêtes relatives aux violations de données révèle que les identifiants représentent 22 % des points d'entrée confirmés des violations de données. Le bourrage d'identifiants (réutilisation automatisée de listes de mots de passe divulguées) concerne en moyenne 19 % des tentatives d'authentification, avec des pics à 44 %. Quarante-neuf pour cent des utilisateurs réutilisent leurs mots de passe pour différents services. L'obligation d'utiliser une majuscule ne résout aucun de ces problèmes.

Un mot de passe alphanumérique long, sans caractères spéciaux, est plus difficile à pirater qu'un mot de passe court conçu pour répondre à des critères de complexité. Si votre banque vous impose encore un mot de passe de douze caractères comprenant une majuscule, un chiffre et un caractère spécial, sachez que cette politique est désormais officiellement non conforme à la norme fédérale américaine.

Où apparaissent les caractères alphanumériques

En dehors du cryptage, les mots de passe et les chaînes alphanumériques restent indispensables dès lors qu'un système a besoin d'un identifiant que les humains peuvent saisir et que les ordinateurs peuvent analyser sans ambiguïté.

Les codes bancaires en sont un exemple simple. Un IBAN peut comporter jusqu'à trente-quatre caractères alphanumériques et commence toujours par un code pays ISO à deux lettres. Les codes SWIFT/BIC comportent huit ou onze caractères. Les plaques d'immatriculation varient selon les pays — une plaque britannique est très différente d'une plaque allemande — mais toutes deux utilisent des sous-ensembles alphanumériques du même ensemble de soixante-deux symboles. Les numéros d'identification des véhicules (VIN) comportent exactement dix-sept caractères dans le monde entier, et les lettres I, O et Q y sont délibérément exclues afin de les distinguer visuellement des chiffres.

Les clés API sont des exemples courants que la plupart des utilisateurs ne prennent jamais la peine d'examiner. Une clé Stripe Live ouvre `sk_live_` suivi d'un jeton alphanumérique. Une clé d'accès AWS ouvre `AKIA` suivi de seize caractères alphanumériques. Un jeton d'accès personnel GitHub émis après 2021 ouvre `ghp_`. Ces préfixes sont eux-mêmes alphanumériques, choisis pour permettre aux fournisseurs d'analyser les dépôts publics et les journaux à la recherche de clés divulguées. Dans de nombreux cas, cette analyse permet de détecter une faille avant même qu'un attaquant ne la repère.

Les codes QR méritent d'être brièvement mentionnés. La norme ISO/IEC 18004 définit un « mode alphanumérique » dédié qui encode un ensemble spécifique de 45 caractères (lettres majuscules, chiffres, espaces et quelques signes de ponctuation) plus efficacement que le mode binaire général. Un code QR contenant uniquement des caractères alphanumériques majuscules stocke environ 1,6 fois plus de données par carré que le même contenu encodé sous forme d'octets bruts.

Base32, Base58, Base64 : quand les cryptomonnaies choisissent un sous-ensemble

Il existe quelques normes d'encodage permettant de convertir des données binaires en un sous-ensemble alphanumérique. La référence est la RFC 4648, publiée par l'IETF en 2006. Elle définit trois encodages.

L'hexadécimal est le plus simple. Officiellement appelé Base16, il utilise seize caractères : 0 à 9 et a à f. Il sert aux adresses Ethereum, aux hachages cryptographiques et à presque tous les débogages de bas niveau nécessitant la lecture d'octets bruts. La Base32 est plus intéressante. Son alphabet de 32 caractères a été choisi pour être insensible à la casse et, dans certaines variantes, pour omettre les chiffres 0, 1, 8 et 9, visuellement sources de confusion. Quiconque a configuré l'authentification à deux facteurs et saisi un code secret dans Google Authenticator a utilisé la Base32, la plupart du temps sans le savoir.

Base64 est le format le plus utilisé. Il comprend soixante-deux caractères alphanumériques, ainsi que les deux symboles « + » et « / ». Une variante compatible avec les URL remplace ces symboles par « - » et « _ ». Base64 est utilisé pour les pièces jointes des e-mails, l'encodage des URL dans le HTML et la création des jetons Web JSON pour OAuth.

L'alphabet Base58 de Bitcoin ne fait pas partie de la RFC 4646. Satoshi Nakamoto l'a créé indépendamment. L'objectif était différent : la saisie manuelle d'adresses, et non l'optimisation du nombre d'octets par caractère. Il en a résulté un alphabet personnalisé, unique en son genre. Le Base85, parfois appelé Ascii85, fonctionne à l'inverse. Il condense quatre octets en cinq caractères et apparaît dans les fichiers PDF et PostScript, où la densité accrue justifie la perte de lisibilité.

Pièges courants : confusion visuelle et ressemblances

Les mêmes raisons qui poussent les systèmes de cryptographie à sélectionner des sous-ensembles alphanumériques expliquent pourquoi tout le monde fait des erreurs. Une poignée de paires de caractères seulement sont à l'origine de la plupart des problèmes.

Les confusions classiques : zéro et O majuscule ; un, l minuscule, I majuscule ; l minuscule et I majuscule. Le Bitcoin Base58 les ignore pour cette raison. D’autres systèmes utilisent des solutions différentes : les numéros d’identification des véhicules (VIN) suppriment le I, le O et le Q ; certains codes financiers suppriment complètement le O ; et il existe des réglementations nationales concernant les plaques d’immatriculation qui interdisent la lettre qui ressemble le plus à un 0 dans la police de caractères du pays.

Un problème plus complexe et plus récent concerne les attaques par homographe Unicode. Ce concept a été décrit dans un article de 2001 par Evgeniy Gabrilovich et Alex Gontmakher. Un homographe consiste à intervertir un caractère visuellement identique provenant d'un système d'écriture différent ; par exemple, le « а » cyrillique (U+0430) à la place du « a » latin (U+0061). En enregistrant un nom de domaine avec cette substitution, il est possible d'héberger une page d'hameçonnage parfaitement indiscernable de celle de la banque légitime. Les navigateurs modernes affichent la représentation Punycode brute — par exemple `xn--80akhbyknj4f` — lorsqu'un domaine mélange les systèmes d'écriture. Cette protection permet de détecter la plupart des attaques, mais pas toutes.

Comment créer un mot de passe alphanumérique fort en 2026

Trois règles. Toutes issues directement des calculs mathématiques du NIST.

Premièrement : la longueur prime sur le type de caractères. Visez au moins seize caractères. Cette règle s’applique que le système n’accepte que des lettres et des chiffres ou l’ensemble complet des caractères ASCII imprimables.

Deuxièmement : si vous devez le mémoriser, utilisez une phrase de passe. Quatre mots choisis au hasard dans une longue liste (la liste Diceware est la référence) sont plus efficaces que presque tous les mots de passe courts qu’un humain pourrait inventer.

Troisièmement : pour tout le reste, utilisez un gestionnaire de mots de passe. Laissez-le générer de longues chaînes alphanumériques que vous n’aurez jamais à lire ni à saisir manuellement. Une fois le gestionnaire chargé, la lisibilité du résultat n’a plus aucune importance.

Guide de référence rapide : dénombrements alphanumériques et exemples

Soixante-deux caractères sensibles à la casse. Trente-six non sensibles. Codes ASCII : 48 à 57 pour les chiffres, 65 à 90 pour les majuscules et 97 à 122 pour les minuscules. L’ensemble complet est représenté par l’expression régulière `[A-Za-z0-9]` ou la classe POSIX `[:alnum:]`. Ce pool de soixante-deux symboles est à la base de presque tous les identifiants numériques que vous utiliserez cette semaine : mots de passe, clés API, IBAN, plaques d’immatriculation, identifiants de transaction et toutes les adresses de portefeuille que vous générez.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.