Capacité d'un code QR : combien de données tiennent, par version du symbole et mode d'encodage

Combien de données un code QR peut-il contenir ?

Un code QR contient au maximum 7 089 chiffres, 4 296 caractères alphanumériques, 2 953 octets ou 1 817 caractères kanji. Ces quatre chiffres décrivent un seul symbole - la version 40, 177 modules de côté, au niveau de correction d'erreurs L - et constituent le plafond du format plutôt qu'un objectif à viser.

La plage utile est bien plus étroite que ne le suggère le plafond. Un symbole de version 40 imprimé au plancher de 0,4 mm par module du papier couché mesure 71 mm avant sa marge, et chacun de ses modules doit survivre à la photographie - donc des codes de cette taille apparaissent dans le marquage industriel et presque nulle part ailleurs.

Pour un usage ordinaire, la question utile est l'inverse du maximum : pour ce contenu, quel est le plus petit symbole qui le contient, et que coûte ce symbole en millimètres imprimés. Les deux dernières sections de cette page y répondent directement.

Ce qu'est une version du symbole

La version du symbole est le nom que la norme QR donne au nombre de modules d'un code, de la version 1 avec 21 × 21 modules à la version 40 avec 177 × 177. Un code de version V compte 4V + 17 modules de côté, donc les versions avancent de quatre en quatre : 21, 25, 29, 33, 37 et ainsi de suite.

Une version ne se choisit pas. L'encodeur retient la plus petite version qui contient le contenu au niveau de correction d'erreurs demandé, ce qui veut dire que la version est le résultat de deux décisions que vous prenez, elles : ce que dit le code et combien de dommages il doit supporter.

Deux conséquences en découlent, et toutes deux surprennent. D'abord, la capacité progresse par paliers plutôt que continûment : ajouter un caractère peut être gratuit ou pousser le code d'une version entière. Ensuite, une version plus élevée n'est pas une image plus grande, mais une image plus dense. À largeur d'impression fixe, les modules d'un code de version 10 sont environ 40 % plus étroits que ceux d'un code de version 4 - 57 cellules dans le même espace au lieu de 33 - et les petits modules sont la matière première des échecs de lecture.

Le symbole n'est pas disponible en entier pour le contenu. Dans un code de version 1, 233 des 441 modules sont des motifs fonctionnels et de l'information de format plutôt que des données : les motifs de détection et l'anatomie d'un code QR détaillent où ils vont. Ce qui reste ensuite se partage entre vos données et leur correction d'erreurs.

Les quatre modes d'encodage QR

Un mode d'encodage est le procédé par lequel un code QR transforme des caractères en bits, et la norme en définit quatre : numérique, alphanumérique, octet et kanji. Chacun loge les caractères à une densité différente, donc le même symbole en contient un nombre très variable selon le mode que le contenu permet.

Le mode alphanumérique est celui qu'il vaut la peine de comprendre, parce que c'est le seul qui s'applique aux URL. C'est le procédé d'encodage QR qui loge deux caractères dans 11 bits, à partir d'un jeu de 45 caractères composé de chiffres, de majuscules, de l'espace et de huit signes de ponctuation. Les minuscules n'en font pas partie, pas plus que le point d'interrogation, l'esperluette, le signe égal ou le tiret bas.

Le mode est choisi par l'encodeur, pas par la personne qui saisit le contenu. Certains encodeurs analysent le contenu et changent de mode automatiquement, d'autres découpent le contenu en segments et emploient un mode différent pour chacun, et beaucoup encodent tout en mode octet quoi qu'il arrive. Ce dernier cas est assez fréquent pour que le seul moyen fiable de savoir soit de générer le code et de compter ses modules.

Capacité d'un code QR par version et par mode

Le tableau ci-dessous est la référence sur laquelle s'appuie le reste de cette page : combien de caractères contient chaque version du symbole, dans chaque mode et à chaque niveau de correction d'erreurs. On le lit en cherchant la ligne de son niveau et la version dont le chiffre dépasse en premier la longueur de son contenu.

Deux cases de ce tableau se lisent utilement ensemble. La version 25 au niveau L contient 1 273 octets, et la version 40 au niveau H contient exactement les mêmes 1 273 octets - un symbole de plus du double de surface en modules, qui dépense toute la différence en récupération. La capacité gagnée en agrandissant le code et celle perdue en montant le niveau sont la même monnaie, et c'est pourquoi les deux décisions appartiennent à un seul tableau et non à deux.

Pourquoi la même URL tient dans un code plus petit en majuscules

Une URL écrite en majuscules peut s'encoder en mode alphanumérique à 5,5 bits par caractère au lieu des 8 bits du mode octet, soit une économie de 31 % qui fait fréquemment descendre le symbole d'une version entière. HTTPS://EXAMPLE.COM/MENU n'utilise que des caractères du jeu alphanumérique de 45 ; https://example.com/menu, non, car les minuscules n'en font pas partie.

Le hic, c'est qu'une partie seulement d'une URL peut passer en majuscules sans risque. Les schémas et les noms d'hôte ne distinguent pas la casse, donc HTTPS://EXAMPLE.COM et https://example.com atteignent le même serveur. Tout ce qui suit l'hôte la distingue sur la plupart des serveurs web, donc mettre le chemin en majuscules peut produire un code qui se scanne parfaitement et aboutit sur une page 404.

Il reste une règle d'application étroite mais réelle : mettez en majuscules le schéma et le domaine, laissez le chemin exactement tel que le serveur l'attend, et vérifiez que le symbole a bien rétréci. Un contenu qui mélange les casses bascule entièrement en mode octet, donc un seul caractère minuscule dans le chemin annule toute l'économie.

Deux autres limites méritent d'être dites franchement. Le jeu alphanumérique ne comporte ni point d'interrogation, ni esperluette, ni signe égal, ni tiret bas, donc toute URL portant des paramètres de requête passe en mode octet quelle que soit sa casse. Et l'encodeur doit prendre en charge le changement de mode : beaucoup produisent tout contenu en mode octet, auquel cas les majuscules ne changent rien. Générez le code des deux façons, comptez les modules d'un côté et comparez : si le nombre est identique, le mode n'a pas changé.

La correction d'erreurs est la moitié de la question de la capacité

Monter le niveau de correction d'erreurs de L à H retire environ 57 % de la capacité d'un symbole, parce que les mots de code de récupération et ceux de données sortent du même budget fixe. À chaque version, les quatre niveaux se partagent le même total : le niveau L consacre environ 7 % à la récupération, M environ 15 %, Q environ 25 % et H environ 30 %.

L'interaction qui surprend joue aussi dans l'autre sens. Comme la capacité progresse par paliers, monter d'un niveau ne coûte souvent rien : si votre contenu fait 40 octets, le niveau M et le niveau Q vous placent tous deux à la version 4, et le niveau supérieur est gratuit. Générez le code au niveau choisi, notez le nombre de modules, générez-le un niveau au-dessus et comparez : gardez le niveau supérieur chaque fois que la grille est inchangée.

Les niveaux de correction d'erreurs L, M, Q et H expliquent ce que cette capacité de récupération achète réellement, quelle taille de logo chaque niveau tolère, et pourquoi monter le niveau après un échec de lecture dégrade généralement le code au lieu de l'améliorer.

De la longueur de l'URL à la taille d'impression

La longueur du contenu décide de la version du symbole, et la version du symbole décide de la plus petite taille à laquelle le code peut honnêtement s'imprimer. C'est la chaîne qui compte dans une maquette, et c'est pourquoi raccourcir une URL est une décision d'impression plutôt qu'une question de propreté.

Les deux dernières lignes rassemblent en un seul endroit l'argument en faveur du raccourcissement de liens. Une URL de suivi de 200 caractères au niveau H ne peut pas s'imprimer en dessous de 34 mm environ sur papier couché, et une URL de 25 caractères descend à 16 mm : la même information, livrée par le même code, sur moins du quart de la surface.

Ce sont des planchers, pas des recommandations. Un code doit aussi être dimensionné pour sa distance de lecture, soit environ 1 cm de largeur pour 10 cm de distance, et c'est la plus grande des deux valeurs qui l'emporte. La taille minimale pour l'impression reprend ce calcul de bout en bout, et le calculateur de taille d'impression QR l'effectue pour une distance donnée.

Que faire quand le contenu ne tient pas

Un contenu qui ne tient pas à une taille exploitable est presque toujours un problème d'URL et non de code QR. Le symbole fait ce qu'on lui demande ; c'est la demande qui est trop longue. À peu près par ordre de gain :

• Retirez les paramètres de suivi. Un jeu UTM complet avec identifiant de clic ajoute couramment 80 à 120 caractères, soit trois ou quatre versions du symbole à lui seul. Attachez les données de campagne à la destination plutôt que dans le code imprimé.
• Supprimez le www et la barre oblique finale. Peu de chose, gratuit, et cela vaut une version sur une URL courte où chaque caractère compte.
• Employez un chemin court. example.com/carte plutôt que example.com/restaurant/nos-cartes/carte-du-midi-2026. À l'impression, le chemin est lu par une caméra et jamais saisi par une personne, donc sa lisibilité n'apporte rien.
• Pointez vers une redirection que vous contrôlez. Un chemin court sur votre propre domaine qui renvoie vers l'URL longue garde le code petit et la destination modifiable, ce qu'un code statique ne peut pas être autrement.
• N'encodez que le strict nécessaire pour ce type de contenu. Un code Wi-Fi porte le nom du réseau, le mot de passe et le type de sécurité, et rien d'autre ; un code téléphonique porte des chiffres. Les champs superflus coûtent des versions - voyez les types de codes QR pour ce dont chaque contenu a réellement besoin.
• Baissez le niveau de correction d'erreurs s'il n'y a pas de logo. Passer de H à M n'est pas une petite économie : cela double presque la capacité à chaque version - de 44 à 84 octets à la version 5 - et le niveau M suffit amplement pour un code propre sur papier couché et plan.
• Divisez le travail. Si le contenu est réellement long - une carte, un document, un certificat -, placez-le derrière une URL plutôt que dans le code. Un code QR contenant 2 000 caractères est un code que personne ne peut scanner.

Une chose à ne pas faire : augmenter la taille d'impression pour faire tenir un contenu long et s'arrêter là. Cela fonctionne, mais cela masque la cause, et la version suivante de la maquette heurtera le même mur avec une URL un peu plus longue et moins de place à lui donner.

Pourquoi les seuils de capacité sont irréguliers

La capacité ne monte pas régulièrement avec la version, et trois mécanismes distincts en sont responsables. Les connaître explique les sauts qui, autrement, paraissent arbitraires dans le tableau ci-dessus.

L'indicateur de nombre de caractères s'élargit. L'indicateur de nombre de caractères est le court en-tête interne d'un code QR qui déclare combien de caractères contient le contenu, et sa largeur en bits change avec la version du symbole. En mode octet, il fait 8 bits aux versions 1 à 9 et 16 bits à partir de la version 10, donc franchir cette frontière coûte un octet de surcharge avant même de stocker le moindre contenu.

Les blocs de correction d'erreurs se répartissent inégalement. À partir de la version 5, les données sont réparties en blocs de tailles différentes pour que l'arithmétique de récupération reste gérable, et la structure des blocs change à presque chaque version. Deux versions voisines peuvent donc gagner 20 octets puis 38.

Il reste des bits résiduels. Certaines versions laissent 3, 4 ou 7 modules après la mise en place des mots de code ; ils sont remplis de zéros et ne portent rien. Ils font partie des raisons pour lesquelles le nombre de modules et la capacité ne suivent pas exactement la même courbe.

Rien de tout cela ne change ce qu'il faut faire. Mais cela explique pourquoi ajouter un caractère à une URL ne coûte parfois rien et ajoute parfois quatre modules de chaque côté - et pourquoi le seul moyen fiable de connaître la version est de générer le code et de compter, plutôt que de l'estimer d'après le nombre de caractères.

Quand la capacité n'est pas la vraie limite

La plupart des codes rencontrent une limite physique bien avant une limite de capacité, et confondre l'une avec l'autre est l'erreur courante sur ce sujet. Un symbole de version 20 contient 666 octets au niveau M, ce qui paraît généreux jusqu'au moment de l'imprimer : 97 modules de côté au plancher de 0,4 mm font 42 mm d'encombrement, et comprimé sur un chevalet de table de 30 mm ses modules tombent à 0,29 mm, en dessous de ce que tiennent la plupart des procédés d'impression et en dessous de ce que résout un appareil photo de téléphone à bout de bras.

Les limites qui mordent en premier, dans l'ordre où elles arrivent :

• La taille du module imprimé. Les modules doivent faire 0,4 mm ou plus sur papier couché et 0,5 mm ou plus sur non couché. C'est ce qui transforme une longueur de contenu en largeur minimale, et le design ne peut pas le négocier.
• La distance de lecture. Un code a besoin d'environ 1 cm de largeur pour 10 cm entre lui et la caméra. Un code dense sur un panneau mural échoue à la distance où les gens se tiennent, pas à celle pour laquelle il a été conçu.
• La mise au point. Les appareils photo de téléphone ont une distance minimale de mise au point d'environ 10 cm. Un code très petit et très dense oblige le lecteur à s'approcher plus près que l'appareil ne peut faire le point, ce qui se traduit par un code qui ne se scanne pas.
• Le contraste et la finition. Un code dense tolère moins bien un contraste faible et les reflets, parce que chaque module apporte moins de pixels - vérifiez un couple de couleurs avec le vérificateur de contraste QR avant de vous y engager.
• La résolution d'export. Un export matriciel a besoin de pixels entiers par module ; un code dense à petite taille en pixels produit des bords de module lissés. Résolution et DPI donne l'arithmétique, et le SVG évite complètement le problème.

KoloQR, un générateur de codes QR gratuit avec des codes QR circulaires et de formes personnalisées, exporte en PNG comme en SVG, de sorte qu'un code dont le contenu impose une version élevée peut être placé en vectoriel et rester géométriquement exact à toute taille d'impression. Cela règle la moitié « export » du problème et aucune des quatre autres : un contenu long exige toujours un code physiquement plus grand, quel que soit son format d'export.

Erreurs fréquentes sur la capacité d'un code QR

L'erreur la plus fréquente consiste à traiter le maximum de 2 953 octets comme un budget de travail. Il décrit un symbole de 177 × 177 modules au niveau de correction d'erreurs le plus bas, ce qui n'a sa place ni sur une carte, ni sur une étiquette, ni sur une affiche - et un contenu approchant ce chiffre aura échoué pour des raisons physiques bien avant que la capacité ne devienne la contrainte.