QR code qui scanne sur iPhone mais pas sur Android : pourquoi

Sur votre stand, une visiteuse lève son iPhone et la page s'ouvre avant même que l'écran soit droit. Son voisin tient un Android devant la même carte, sous la même lumière, à la même distance, et rien ne se passe pendant quinze secondes. Il hausse les épaules et s'éloigne. Le code n'est pas en cause, mais la façon dont chaque téléphone le lit.

Rien du code imprimé n'a changé entre ces deux tentatives. Ce qui a changé, c'est tout ce qui se produit après que la lumière atteint le capteur : la façon dont l'image est convertie en pixels clairs et sombres, quel logiciel a le droit d'essayer, et ce que le téléphone décide de faire de la chaîne récupérée.

Un décodeur n'est pas un seul logiciel

La symbologie elle-même est normalisée. Modules, motifs de repérage, motifs de synchronisation, correction d'erreurs à environ 7, 15, 25 et 30 pour cent pour les niveaux L, M, Q et H, versions 1 à 40, zone de silence de quatre modules. Tous les décodeurs s'accordent là-dessus.

Ce qui n'est pas normalisé, c'est l'effort. Rien n'indique à un décodeur combien d'images tenter avant d'abandonner, où placer le seuil qui sépare les pixels gris en clair et sombre, quelle correction de perspective appliquer, ou s'il faut réessayer à un autre seuil quand la première passe échoue. Ce sont des choix d'implémentation, et ils diffèrent d'un éditeur à l'autre et d'une version à l'autre d'un même produit.

Le résultat concret : un code limite se lit sur un téléphone et cale sur un autre, et les deux appareils se comportent correctement. Si votre code est un peu petit pour la distance de scan, si l'engraissement de l'encre a épaissi les modules sombres, ou si le contraste est plus faible sur papier qu'à l'écran, vous vous reposez sur le décodeur le plus indulgent. L'iPhone de cette histoire n'a pas prouvé que le code va bien. Il a prouvé qu'un décodeur tolère le défaut. La mécanique de cette lecture est traitée dans comment fonctionnent les QR codes.

Android n'est pas une seule application photo

Côté Android, il n'existe pas de chemin de scan unique. Selon l'appareil et la version de l'OS, le code peut être lu par l'application photo d'origine, par une fonction de scan ajoutée par le constructeur à son propre logiciel photo, par Google Lens, par une tuile du panneau de réglages rapides, ou par une application tierce installée par le propriétaire. Certains de ces chemins sont actifs par défaut. D'autres se cachent derrière un interrupteur dans les réglages de l'appareil photo. D'autres n'apparaissent que dans un mode particulier.

N'en déduisez rien à partir de la marque au dos du téléphone. Le comportement varie selon le modèle, la version de l'OS et la version opérateur, et il change avec les mises à jour. La seule affirmation qui tienne, c'est que le même code physique peut rencontrer plusieurs décodeurs différents sur Android, et que l'un d'eux peut être plus faible que les autres.

Donc testez au lieu de deviner :

• Ouvrez l'application photo d'origine, visez le code, et attendez dix secondes sans bouger le téléphone.
• Si rien ne se passe, cherchez dans les réglages de l'appareil photo un interrupteur de scan ou de suggestions intelligentes et activez-le.
• Essayez Google Lens, ou la tuile scanner des réglages rapides si l'appareil en a une.
• Essayez une application de scan dédiée comme témoin. Si l'application dédiée lit le code et pas l'appareil photo, le symbole est limite plutôt que cassé.

Faites parcourir à la personne comment scanner un QR code avant de conclure que l'impression est en cause. Une part non négligeable des signalements « Android n'arrive pas à le lire » se révèle être une fonction de scan jamais activée.

Le scan a pu réussir sans que l'utilisateur le remarque

Les implémentations diffèrent aussi dans la façon d'afficher un résultat. Certaines montrent un bouton persistant ancré au code dans le viseur. Certaines montrent une bannière qui s'efface après une ou deux secondes. Certaines exigent un appui sur la zone détectée avant que quoi que ce soit ne s'ouvre.

Si votre testeur a détourné le regard au mauvais moment, ou si une notification a été supprimée pendant que le téléphone était en mode concentration, le décodage a eu lieu et pas la transmission. Demandez ce qui est apparu à l'écran, pas seulement si le lien s'est ouvert.

Une charge utile pour laquelle personne n'a de gestionnaire

Ici, les plateformes divergent réellement. Une simple URL https a un gestionnaire sur tous les téléphones. D'autres charges utiles, non :

• Les schémas d'application personnalisés échouent quand l'application n'est pas installée. Une plateforme affichera peut-être une alerte « impossible d'ouvrir », l'autre rien de visible du tout.
• Les charges utiles de réseau Wi-Fi sont gérées par le système d'exploitation, et le support a varié selon les versions.
• Les charges geo, tel, sms et mailto dépendent d'une application enregistrée pour elles. Un téléphone sans enregistrement n'a nulle part où envoyer l'utilisateur.

Encodez une simple URL https et laissez la page de destination faire la transmission. Une page peut proposer un lien vers l'application, un lien vers le magasin et un repli web d'une façon que le code lui-même ne permet pas. Avec un QR code dynamique, vous pouvez aussi rediriger cette destination après l'impression des cartes, ce qui compte le jour où un lien profond cesse de fonctionner.

Le navigateur où vous atterrissez n'est pas toujours le navigateur par défaut

Scanner depuis une application sociale ou de messagerie ouvre généralement le navigateur intégré de cette application plutôt que celui par défaut de l'utilisateur. Le navigateur intégré tient ses propres cookies et a ses propres limites : une session créée dans le navigateur principal n'y est pas, et certaines fonctions de page peuvent ne pas s'exécuter.

Deux personnes peuvent décoder des données identiques et voir des pages différentes. Quand le signalement est « ça marche sur iPhone et affiche une page cassée sur Android », le décodage va bien et le problème vit dans la destination.

Et en France ?

Android reste majoritaire sur le parc de smartphones en France, avec une grande diversité de fabricants et de gammes : Samsung, Xiaomi, Oppo, Google, et beaucoup de modèles d'entrée de gamme ou de plusieurs années. C'est précisément sur ces appareils que les codes trop denses ou peu contrastés échouent.

Pour un commerce ou un événement en France, ne validez donc jamais un code sur un seul iPhone récent. Testez au moins un Samsung de milieu de gamme et un téléphone Android de plus de quatre ans : si eux le lisent sans hésiter, la quasi-totalité de vos visiteurs y arrivera aussi.

Diagnostiquer dans cet ordre

1. Reproduisez avec une application de scan dédiée sur le téléphone en échec. Si elle lit, le symbole est lisible et le problème vient du logiciel de l'appareil ou de la charge utile.
2. Lisez la chaîne décodée, pas seulement le résultat. Confirmez que c'est l'URL attendue et qu'elle commence par https.
3. Comparez la taille imprimée à la distance réelle de scan. Un code qui ne se lit qu'à 10 cm sur une affiche prévue pour deux mètres est sous-dimensionné, pas incompatible.
4. Vérifiez le niveau de correction d'erreurs si la surface est manipulée ou frottée. Les codes créés ici portent toujours le plus élevé des quatre, il n'y a donc rien à monter, mais un code venu d'ailleurs peut se trouver au plus bas : les niveaux de correction d'erreurs détaille ce que chacun apporte.
5. Seulement après ces quatre points, déroulez la liste de dépannage complète.

Avant d'envoyer le fichier à l'imprimeur, imprimez une carte de test à la taille réelle, présentez-la à trois téléphones Android de trois marques différentes, et ne validez que lorsque les trois la lisent depuis la distance où se tiendra un vrai client.