Capacité d'un QR code : combien de caractères peut-il contenir ?

Encodez le mot « bonjour » et vous obtenez une grille de 21 × 21 modules, si aérée qu'on pourrait la recopier sur du papier quadrillé. Encodez un lien de campagne de 300 caractères et le même outil produit un motif touffu qui réclame cinq centimètres à l'impression pour qu'un téléphone accepte de le lire. Même norme, même générateur, deux résultats sans rapport.

On répond généralement à la question de la capacité par un tableau de maximums. Ces chiffres sont réels. Presque personne ne les atteint.

Les plafonds publiés

Au plus grand symbole que définit la spécification, la version 40, avec la correction d'erreurs au niveau le plus bas (L), un seul QR code contient :

• 7 089 chiffres
• 4 296 caractères alphanumériques
• 2 953 octets
• 1 817 caractères kanji

Un symbole de version 40 est une grille 177×177, soit 31 329 modules individuels. Pour l'imprimer de façon qu'un appareil photo de téléphone distingue chaque carré, il faut plusieurs centimètres de côté. Et la correction d'erreurs L est le niveau qui tolère le moins de dégâts. Le code à capacité maximale est donc à la fois la version la plus grande et la plus fragile de lui-même, ce qui fait du plafond une réponse de quiz plutôt qu'un objectif de conception.

Le nombre qui compte n'est pas le maximum. C'est la vitesse à laquelle votre contenu grimpe l'échelle des versions.

Quatre modes d'encodage, quatre densités

Le format tasse les caractères différemment selon ce qu'ils sont. Si vous voulez d'abord la structure sous-jacente, ce qu'est vraiment un QR code en couvre l'anatomie.

Numérique gère les chiffres de 0 à 9 et en comprime trois dans 10 bits. Mode le plus dense de loin, d'où le chiffre vedette de 7 089.

Alphanumérique couvre 45 caractères : les chiffres, les majuscules A à Z, l'espace et la ponctuation $ % * + - . / ainsi que les deux-points. Deux caractères voyagent dans 11 bits.

Le mode octet dépense 8 bits pleins par caractère et accepte tout ce qui entre dans le jeu de caractères, en général Latin-1 ou UTF-8. Aucune astuce de compression ne s'applique.

Le mode kanji utilise 13 bits par caractère Shift-JIS, ce qui bat l'envoi du même caractère sous forme de plusieurs octets UTF-8.

Regardez de près le jeu alphanumérique. Pas de minuscules. Pas de point d'interrogation, pas d'esperluette, pas de signe égal, pas de tiret bas, pas de tilde.

Pourquoi un lien atterrit presque toujours en mode octet

Prenez une URL comme https://example.com/spring-sale?utm_source=flyer. Elle contient des minuscules, un point d'interrogation, un signe égal et un tiret bas. Rien de tout cela n'existe en mode alphanumérique : l'encodeur bascule donc ce contenu en mode octet, à 8 bits par caractère. Chaque caractère ajouté coûte un octet plein.

C'est pourquoi les paramètres de suivi coûtent cher. Un lien propre de 40 caractères et le même lien portant quatre valeurs UTM peuvent différer de plus de cent caractères, et le second peut se situer plusieurs versions plus haut.

La spécification autorise bien le mélange de modes dans un même symbole, et certains encodeurs mettent le schéma et l'hôte en majuscules pour que cette portion voyage en mode alphanumérique. Utile, mais limité : le chemin et la requête distinguent la casse, et coûtent donc toujours un octet chacun.

Les versions 1 à 40 et l'échelle des tailles

La version 1 fait 21×21 modules. Chaque palier ajoute quatre modules par côté : la version 2 fait 25×25, la version 10 fait 57×57, la version 20 fait 97×97, et la version 40 arrive à 177×177.

Votre générateur choisit la plus petite version qui accueille les données au niveau de correction d'erreurs retenu. Ajoutez quelques caractères et rien ne bouge pendant un moment. Ajoutez-en quelques-uns de plus et la grille saute un palier. C'est à cet endroit que les codes imprimés deviennent plus difficiles à lire, car à taille physique constante, plus de modules signifie des modules plus étroits.

La correction d'erreurs consomme la même grille

La redondance n'est pas du stockage gratuit boulonné sur le côté. Elle vit dans les mêmes modules que vos données. Les quatre niveaux récupèrent environ 7 % (L), 15 % (M), 25 % (Q) et 30 % (H) des mots de code. Montez le niveau et, à version égale, vous logez moins de contenu — ou vous passez à une version supérieure.

En pratique : M est une valeur par défaut raisonnable pour l'impression. Choisissez H si un logo couvre le centre ou si la surface va être éraflée, mouillée ou beaucoup manipulée. Réservez L aux codes affichés sur un écran propre, qui ne seront jamais abîmés, et pour lesquels vous vous battez pour garder la grille petite.

La contrainte que vous rencontrez vraiment

Personne ne tombe à court d'octets. On tombe à court de millimètres.

Le rapport de travail que la plupart des gens utilisent tourne autour de 10:1, distance sur largeur du code : un code lu à trois mètres veut donc faire environ 30 centimètres de large. À taille physique constante, chaque version supplémentaire rétrécit chaque module, et dès que les modules approchent la limite de résolution de votre procédé d'impression ou de la caméra qui scanne, les échecs de lecture commencent aux extrémités de la plage de lumière et d'angle. Les règles de dimensionnement pèsent bien plus sur le bon fonctionnement de votre code que n'importe quel tableau de capacité.

Et en France ?

Le français a un piège spécifique : les lettres accentuées. Dans une URL, un « é » n'est pas un caractère mais une séquence encodée, %C3%A9, soit six caractères au lieu d'un. Une adresse comme /carte-été-2026 grossit donc discrètement, et le code devient plus dense qu'il ne devrait.

Dans un texte encodé directement (un message, une vCard), les accents passent en UTF-8 et prennent deux octets chacun. Pour garder un code léger :

• préférez des adresses sans accents (/carte-ete-2026) ;
• utilisez un code dynamique, qui n'encode qu'une courte URL de redirection quelle que soit la longueur de la destination ;
• vérifiez qu'un nom accentué s'affiche correctement sur une vCard avant d'imprimer, comme expliqué dans notre article sur l'encodage des caractères.

Garder la charge utile légère

Commencez par alléger l'URL avant de l'encoder : les paramètres de suivi que personne ne consulte sont les premiers à supprimer. Pour un lien long, passez par un lien court, afin que la chaîne encodée reste brève. Si la destination est longue ou risque de changer, un code dynamique garde un motif aéré pour toujours, puisqu'il n'encode qu'une courte redirection fixe, quelle que soit la longueur de l'adresse finale. Et si vous ne voulez dépendre d'aucun service, un code statique vers une adresse courte de votre propre domaine donne une densité presque équivalente.

Les coordonnées méritent un avertissement particulier. Une vCard complète avec adresse postale, deux numéros de téléphone, un intitulé de poste et l'URL d'une photo vous propulse vite dans les versions élevées. Un lien vers une page de contact s'encode dans une fraction de l'espace et reste modifiable.

Collez votre URL réelle la plus longue dans [le générateur](/), puis une version raccourcie du même lien, et placez les deux résultats côte à côte. La différence de nombre de modules est tout l'argument, et il faut une trentaine de secondes pour la voir.