Redimensionnez le visuel, puis ajoutez le QR code

Nous sommes partis de 12 URL de campagnes fictives. Quatre destinations représentaient un atelier, le livre d’un créateur, un produit et un cours de photographie. Chacune avait une version courte, une version avec des paramètres de campagne et une version plus longue avec des paramètres supplémentaires. L’URL complète restait identique dans chaque comparaison entre les deux méthodes.

Chaque URL a été encodée avec deux niveaux de correction d’erreur et enregistrée dans deux formats. Nous avons ainsi obtenu 48 fichiers par méthode d’export, pour chaque taille de visuel. Ce sont plusieurs conditions appliquées aux mêmes 12 URL, et non 48 clients, campagnes ou essais indépendants. Les deux décodeurs logiciels ont réussi à lire les 24 grandes images sources avant le début de la comparaison des exports.^[1]

La différence était la plus nette à 540 × 540 pixels. Après réduction du visuel terminé, les deux décodeurs ont retrouvé l’URL exacte dans 16 fichiers sur 48. Après réduction de l’arrière-plan, puis ajout du QR code à la taille finale, ils l’ont retrouvée dans les 48 fichiers. L’amélioration apparaissait aux deux niveaux de correction d’erreur, en PNG comme en JPEG.

Dans chaque paire, le QR code disposait de la même zone réservée : un carré de 90 × 90 pixels. La seconde méthode adaptait le code à cette zone en utilisant des pixels entiers pour ses petits carrés. Elle ne raccourcissait pas le lien, ne supprimait aucun paramètre de campagne et ne changeait pas la destination. Le tableau présente les résultats des quatre groupes de 12 fichiers.

Pour une entreprise qui commande un travail créatif, cela change les livrables à demander au designer. Vérifier que le fichier source s’ouvre correctement et que le QR code fonctionne dans la grande version reste utile. Mais le visuel réduit demande son propre contrôle. La validation doit préciser le fichier et les dimensions réellement livrés, sans s’arrêter au fichier source.

Un QR code est une grille de petits carrés appelés modules. Le lien et les réglages d’encodage déterminent cette grille. DENSO WAVE, à l’origine du QR Code, explique que des données plus longues et d’autres niveaux de correction d’erreur peuvent nécessiter des grilles plus grandes. Un QR code standard exige aussi une marge libre, appelée zone de silence, de quatre modules sur chaque côté.^[2][3]

Il faut donc faire tenir la grille complète et sa marge dans le visuel livré. Dans notre première méthode, le QR code faisait déjà partie d’une image de 2 160 × 2 160 pixels lorsque celle-ci était réduite. Le rééchantillonnage pouvait mélanger ses contours ou placer la grille entre les pixels de sortie. Dans la seconde méthode, nous réduisions l’arrière-plan, puis dessinions directement la grille d’origine sur des pixels entiers.

Un exemple mesuré rend la différence concrète. L’URL longue de l’atelier contenait 199 octets. Au niveau de correction M, elle produisait une grille de 57 × 57 modules. Marge comprise, son emprise faisait 65 modules de large. Le visuel source attribuait cinq pixels à chaque module, soit une emprise de 325 pixels de large.

La réduction du visuel à 540 pixels projetait cette emprise sur 81,25 pixels, avec 1,25 pixel entre les limites des modules. Aucun des deux décodeurs n’a retrouvé l’URL dans le PNG obtenu. Dessiner la même grille directement à la taille finale utilisait un pixel par module et une emprise plus petite de 65 pixels. Les deux décodeurs retrouvaient alors l’URL complète.

Nous comparons ici deux méthodes d’export complètes. La taille occupée, la position et le filtrage ont changé ensemble : le test n’isole donc pas une cause unique. Il montre toutefois pourquoi « agrandir le QR code dans le fichier source » est une consigne de production incomplète. Dans cet exemple, c’est le plus petit symbole final que les décodeurs ont réussi à lire.

Conservez l’URL prévue dans son intégralité pendant que vous réglez l’export. Les paramètres de campagne peuvent faire partie d’un plan de mesure convenu. Les supprimer modifie le lien livré. Si l’équipe envisage ensuite une redirection gérée ou une destination plus courte, ce sera une décision distincte, avec ses propres contrôles de destination et d’attribution. Notre expérience n’a pas testé cette autre option.

La comparaison de toutes les tailles permet de situer le résultat principal. À 1 080, 720 et 540 pixels, les deux décodeurs ont retrouvé l’URL dans chaque fichier où le QR code avait été ajouté en dernier. La réduction du visuel terminé donnait un autre profil : respectivement 32, 37 et 16 lectures réussies par les deux décodeurs, sur 48 fichiers à chaque taille.

Réduire davantage le visuel ne donnait pas toujours un moins bon résultat. Les exports de 720 pixels comptaient plus de lectures réussies par les deux décodeurs que ceux de 1 080 pixels. Des rapports de réduction différents et les pixels qui en résultent peuvent changer ce qu’un décodeur parvient à lire. Ces résultats ne définissent pas une taille minimale universelle de QR code en pixels.

À 360 pixels, la zone réservée au QR code ne mesurait plus que 60 × 60 pixels. Certaines grilles, marge comprise, exigeaient 65 ou 85 modules de large. Même un pixel entier par module ne pouvait donc pas tenir. Nous avons classé ces 24 configurations d’ajout final comme impossibles à produire avec la méthode prévue, au lieu de les compter comme des échecs de décodage.

Le tableau compare donc uniquement les 24 paires restantes à 360 pixels. Les deux décodeurs ont retrouvé l’URL dans six fichiers issus d’un visuel réduit et dans 18 fichiers avec ajout final. Six des fichiers réalisables avec ajout final ont tout de même échoué au test commun. La méthode améliorait ce petit ensemble, sans rendre tous les petits exports lisibles.

Pour un visuel de campagne compact, la prochaine décision de design concerne la place à réserver au code et à sa marge. Prenez-la avant de considérer tous les carrés disponibles comme équivalents. Les dimensions de la zone, l’URL complète, l’encodage et la sortie finale ont tous leur place dans le brief. Un module d’un pixel qui a fonctionné dans ce test contrôlé n’est pas une taille recommandée pour un appareil photo de téléphone ou un support imprimé.

La correction d’erreur aide un décodeur QR à retrouver les données encodées lorsqu’une partie de l’information est endommagée. L’augmenter peut aussi exiger une grille plus grande pour le même contenu. Nos encodages M et H impliquaient donc un véritable compromis dans une zone fixe. Un niveau supérieur n’ajoutait pas simplement de la protection à une image par ailleurs identique.^[7]

À 540 pixels, le visuel réduit obtenait cinq lectures réussies par les deux décodeurs sur 12 au niveau M, et trois au niveau H, dans chaque format. Mais H était meilleur dans d’autres comparaisons appariées : huit comparaisons avec les URL détaillées à 1 080 pixels, et deux comparaisons de PNG avec paramètres de campagne à 720 pixels. Dire « choisissez toujours le niveau inférieur » déformerait les résultats.

Les formats ne formaient pas non plus un classement simple. À 720 pixels au niveau M, les deux décodeurs retrouvaient l’URL dans 10 exports PNG et 12 exports JPEG issus du visuel réduit. Cela ne fait pas du JPEG un choix généralement plus sûr. Cela montre pourquoi le résultat d’un format enregistré ne doit pas être transposé automatiquement à un autre.

Les décodeurs ont aussi donné des résultats différents pour 54 des 360 fichiers générés. À 1 080 et 720 pixels, ZXing-C++ lisait tous les fichiers ; quirc expliquait les totaux communs plus faibles. À 540 pixels, chacun des deux décodeurs progressait lorsque le QR code était ajouté en dernier. Nous retenons leur réussite commune comme résultat principal, tout en donnant accès aux résultats de chacun dans le téléchargement.

Pour un créateur qui livre des fichiers à un client, la réponse utile consiste à préciser le format prévu et à confirmer le lien exact livré. Le décodage logiciel vérifie le fichier image. Un contrôle séparé sur le téléphone, l’écran ou le support imprimé prévu vérifie une autre partie de l’expérience réelle. Nous avons mesuré le premier ; le second reste donc une étape pratique pour l’équipe qui utilisera le visuel.

Copiez les champs suivants dans un brief créatif ou une fiche de livraison. Remplissez-les pour chaque taille de sortie requise. Ils relient le choix de destination de l’entreprise, les réglages d’export du designer et la personne chargée de contrôler le support terminé. La version téléchargeable ne demande aucune inscription et peut être adaptée à votre méthode de travail.

Campagne et utilisation : [Nommez la campagne, l’action vers laquelle le QR code doit conduire et l’emplacement de ce visuel.] Responsable du lien : [Nommez la personne qui peut approuver la destination et ses paramètres.] URL complète approuvée : [Collez la chaîne exacte, avec tous les paramètres requis et toutes les séquences encodées avec le signe %.]

Visuel final : [Largeur × hauteur en pixels.] Zone QR : [Position et largeur × hauteur réservées.] Zone de silence : [Confirmez la présence d’une marge libre sur les quatre côtés.] Grille et ajustement : [Indiquez le nombre de modules et le nombre de pixels entiers par module utilisés, si ces informations sont disponibles dans le générateur ou lors de l’export.]

Encodage et export : [Indiquez le générateur, le niveau de correction d’erreur et les options utiles.] Ordre de préparation : [Précisez si le QR code a été ajouté aux dimensions finales.] Format enregistré : [PNG ou JPEG, avec les réglages utilisés.] Fichier livré : [Indiquez le nom du fichier ou un autre identifiant sans ambiguïté.]

Contrôle du fichier : [Indiquez le ou les décodeurs, le fichier testé et le résultat.] URL retrouvée : [Comparez la chaîne complète obtenue à l’URL approuvée.] Résultat non résolu : [Indiquez l’échec, le désaccord ou le problème de place, ainsi que la personne chargée de le résoudre.] Ne cochez pas comme validé un résultat qui n’a pas été testé.

Contrôle d’utilisation : [Indiquez l’écran ou le support imprimé prévu, le téléphone ou autre lecteur utilisé, la personne responsable et la date du contrôle.] Contrôle de destination : [Confirmez que le lien approuvé mène à la page prévue et que les paramètres de campagne requis sont conservés tout au long du parcours prévu.] Ces contrôles vont au-delà de notre comparaison de fichiers image.

Le brief doit clarifier les responsabilités. Le responsable de campagne approuve le lien ; le designer prépare les sorties demandées ; la personne chargée de la vérification contrôle les fichiers réels et l’utilisation prévue. Si quelqu’un modifie ensuite le lien, les dimensions ou les réglages d’export, mettez le brief à jour et vérifiez à nouveau la sortie concernée.

Imaginez une entreprise qui confie à un créateur la promotion d’un atelier d’automne. Il lui faut un visuel numérique carré pour l’écran du lieu et une version plus petite pour un message de campagne. L’entreprise a approuvé un lien contenant des informations sur la source, le support, la campagne et le partenaire. Ce scénario de production est fictif ; il utilise l’une de nos URL effectivement testées pour rendre la fiche concrète.

L’URL approuvée est l’exemple d’atelier de 199 octets fourni dans le téléchargement. Le nom de campagne est autumn_2026, le support est qr et le champ de contenu identifie un créateur partenaire fictif. Ces éléments restent dans l’URL pour les deux sorties. Le créateur ne les supprime pas pour réduire la quantité d’information contenue dans le code.

La fiche d’exemple précise un PNG de 540 × 540 pixels, avec une zone QR de 90 × 90 pixels commençant à x=378, y=378. Elle utilise l’encodage M mesuré : une grille de 57 modules, une zone de silence de quatre modules et un pixel entier par module. L’emprise finale fait 65 × 65 pixels, centrée dans la zone réservée.

Le designer réduit d’abord l’arrière-plan, puis ajoute cette grille. La fiche identifie le fichier enregistré et consigne le résultat mesuré : ZXing-C++ et quirc ont tous deux renvoyé exactement l’URL d’origine. Elle indique aussi le résultat de l’autre méthode : aucun n’a retrouvé l’URL dans le PNG correspondant obtenu en réduisant le visuel source terminé. Ces deux résultats viennent de notre expérience, pas d’une vraie campagne client.

L’entreprise doit encore vérifier l’écran réellement utilisé sur place et le parcours prévu sur téléphone. Si la petite version doit être recompressée ou redimensionnée par un autre service, l’équipe vérifie aussi le fichier ou l’affichage obtenu. Nous n’avons pas mesuré ce service, et la réussite initiale ne démontre pas ce qui se passe après une autre transformation.

Supposons que le brief demande ensuite un visuel de 360 pixels, tout en gardant la même proportion de zone QR. La zone ne fait plus que 60 pixels de large, alors que ce code exige 65 modules, marge comprise. Avec notre méthode en pixels entiers, il est impossible à produire. Le designer doit signaler le conflit de mise en page et convenir d’un espace plus grand ou d’une autre solution de livraison, plutôt que d’annoncer un export réussi qui n’était pas réalisable.

C’est l’intérêt d’une fiche précise : la discussion intervient pendant que le visuel peut encore changer. L’équipe peut conserver le lien approuvé, identifier la sortie qui demande une intervention et éviter de considérer la réussite d’une grande maquette comme une validation de tous les fichiers suivants.

Nous avons fixé les 12 URL fictives, le visuel, les tailles et les réglages avant de décoder les exports de test. Les URL utilisaient example.com et n’ont jamais été ouvertes. Chacune des quatre familles de destinations avait trois profils de contenu, de 39 à 203 octets. Nous avons testé les corrections M et H, quatre largeurs de visuel carré et deux formats enregistrés, soit 384 configurations de fichier prévues pour les deux méthodes.^[1]

Segno 1.6.6 a généré des QR codes standard en mode octet, sans augmentation automatique du niveau de correction. Chaque combinaison d’URL et de niveau a été encodée une seule fois, et les deux méthodes ont réutilisé sa grille exacte. Le visuel source était un carré de 2 160 pixels. Pillow 13.0.0 appliquait un seul redimensionnement LANCZOS ; le JPEG utilisait une qualité de 85, sans sous-échantillonnage de la chrominance. Tous les codes étaient noirs sur blanc, avec une zone de silence de quatre modules.^[4]

Les deux décodeurs recevaient la même image enregistrée complète, convertie en niveaux de gris sur 8 bits. Nous avons utilisé ZXing-C++ 3.1.1 et une compilation de quirc figée, avec des réglages fixes. Une réussite exigeait les octets de l’URL d’origine, sans autre résultat réussi contradictoire. Nous n’avons ajouté ni recadrage, ni image agrandie pour une nouvelle tentative, ni intervention manuelle pour sauver une lecture. Le téléchargement conserve les réglages des décodeurs, la géométrie de chaque fichier et les résultats.^[5]

Les 24 images sources ont passé le test des deux décodeurs. Sur les 384 exports prévus, 360 ont été générés et 24 ne pouvaient pas être produits par la méthode d’ajout final. Il restait donc 168 paires comparables entre méthodes. Nous conservons toutes les conditions, y compris les désaccords, les fichiers produits mais illisibles et les comparaisons favorables à l’un ou l’autre niveau de correction. Les résultats décrivent ces fichiers synthétiques et ces compilations logicielles, pas des taux de lecture chez les consommateurs.

Les recommandations existantes expliquent déjà l’importance de l’espace, des zones de silence et de la qualité d’image. QRotto a également publié une comparaison de résolutions sources après mise à l’échelle et floutage. Notre contribution porte sur un point plus précis : comparer, dans un cadre fixe, le moment où le QR code est ajouté lors de l’export d’un visuel, tout en gardant la même URL complète et la même grille encodée dans chaque paire. Les tableaux complets et les détails de préparation sont disponibles ci-dessous.^[6]