Le 13 novembre 2026, nous avons posé cette question à Google, en anglais. Parmi les premiers résultats figurait un fil de forum de 2015, en anglais lui aussi. Une réponse s'y termine ainsi : « Sinon, il vous faudra 2 QR codes différents, 1 pour chaque plateforme » (nous traduisons).
C'était vrai d'un code simple, dont les carrés contiennent l'adresse même du store, la boutique d'applications. Aujourd'hui, un seul QR code pour télécharger une application suffit s'il est dynamique : ses carrés contiennent une adresse web courte, et un service décide où elle mène. Donnez-lui trois liens : App Store, Google Play et un lien de repli pour tout le reste.
Nos principaux codes de test ont reçu chacun 25 requêtes de test. Un iPad simulé qui se présente comme un Mac a été traité comme un ordinateur.
Faut-il deux QR codes, un par store ?
Deux clients visent ensemble le chevalet du comptoir, l'un avec un iPhone, l'autre avec un téléphone Android. Un seul carré d'encre, deux stores. Qui décide ?
Pas le code. Il contient une seule adresse et ne peut pas regarder le téléphone. Le choix se fait après le scan, sur un serveur, derrière un lien court : une adresse web courte qui renvoie le visiteur vers la vraie destination.
Option A : deux codes statiques, chacun avec l'adresse de son store dans les carrés. Vous y gagnez l'indépendance : aucun service, rien qui puisse s'éteindre. En échange, ils prennent deux fois plus de place sur le chevalet, et chaque passant se demande lequel est le sien.
Option B : un seul code dynamique, pour gagner de la place et un chevalet plus calme. Les carrés contiennent le lien court, et le serveur choisit le store à chaque scan. C'est là que se séparent les QR codes statiques et dynamiques.
Peut-on se passer d'un store ? Pas avec ces chiffres. StatCounter compte les systèmes qui affichent des pages web sur mobile : des pages vues, pas des téléphones vendus. En octobre 2026, iOS, le système de l'iPhone, en avait 52 % aux États-Unis, 36 % en France et 28 % dans le monde. Android avait presque tout le reste.
Comment un seul QR code sait-il quel téléphone le scanne ?
La réponse déçoit un peu : le code ne détecte rien. Le service derrière lui croit le téléphone sur parole.
Chaque fois qu'un navigateur demande une page, il envoie une ligne qui dit ce qu'il est : le navigateur, le système, souvent le type d'appareil. Son nom technique est le user agent ; nous l'appellerons la signature du navigateur. Pensez à un badge nominatif tendu à l'entrée. Quand une habituée pointe son iPhone vers le chevalet, son navigateur se présente comme Safari sur iPhone. Certains appareils, pourtant, se présentent comme autre chose.
Le serveur du lien court lit cette ligne et répond par une redirection, une consigne d'aller ailleurs, envoyée avant le chargement de toute page. Sur le générateur que nous avons testé, la réponse pointait directement vers l'adresse du store, sans page intermédiaire : le code 302, un code web standard de redirection temporaire.
Autre façon de faire : une petite page avec un bouton par store. Un geste de plus, et c'est la personne qui choisit.
Qui arrive où : ce qu'ont montré 25 requêtes de test
La plupart de nos 25 requêtes de test ont atterri là où on l'aurait parié. L'une des autres représente un appareil qui traîne sans doute en ce moment sur une table de café.
Un script a demandé 25 fois sa réponse au lien, en changeant la signature envoyée. C'étaient des simulations ; un vrai scan d'iPhone est rapporté plus bas. Les trois liens étaient remplis.
- Le lien App Store est allé aux iPhone (Safari, Chrome) et à un iPad qui se présente comme un iPad.
- Le lien Google Play est allé aux téléphones Android.
- Les navigateurs intégrés s'ouvrent dans Instagram, TikTok ou Facebook quand vous touchez un lien. Ils ont suivi leur téléphone : Instagram et TikTok sur iPhone ont reçu l'App Store, Facebook sur Android a reçu Google Play. Nous n'avons pas testé si le store s'ouvre ensuite dans ces applis.
- Le lien de repli est allé aux ordinateurs (Mac, Windows, Linux, Chromebook), et même à une requête sans signature.
Une habituée, près de la fenêtre, scanne l'affiche avec son iPad. L'équipe WebKit construit le moteur de Safari. En décembre 2019, elle a écrit que Safari sur iPad se présente la plupart du temps comme Safari sur Mac, pour que les sites servent leur version ordinateur. Dans notre test, cette signature de Mac, traitée comme un ordinateur, a reçu le lien de repli, pas l'App Store.
Toutes les réponses reçues s'expliquent par une seule règle : le serveur cherche iPhone, iPad ou Android dans la signature, et traite tout le reste comme un ordinateur. Avec les trois liens remplis, un iPad qui se dit Mac arrive donc sur le troisième. Cette page a besoin d'un bouton App Store.
Créer un QR code pour une appli : remplissez les trois liens
Trois adresses à copier-coller. On est tenté d'en remplir deux ; la troisième décide de ce qui se passe quand un appareil inattendu scanne.
- Copiez l'adresse App Store. Les liens d'Apple ressemblent à
apps.apple.com, parfois un code pays, puis/app/, un nom,idet un numéro. Le plus simple : ouvrez la page de votre appli sur le site de l'App Store et copiez la barre d'adresse. - Copiez l'adresse Google Play. Android Developers documente le format :
play.google.com/store/apps/details?id=suivi du nom du paquet, le nom technique unique de l'appli (par exemplecom.yourshop.loyalty). - Créez un code de type application et collez chaque adresse dans le champ de son store.
- Remplissez le troisième champ avec une page web : sur le générateur que nous avons testé, il s'appelle « Lien de repli (ordinateur / autre) ».
- Enregistrez, testez, puis imprimez.
Pourquoi le troisième champ ? Nous avons mesuré un code avec les deux liens de store, sans lien de repli. Toute signature qui ne disait ni iPhone, ni iPad, ni Android a reçu le lien App Store. Cela convient à l'iPad qui se dit Mac. Pas à un ordinateur portable Windows dont le propriétaire a un téléphone Android.
Prenez maintenant le mois du lancement : votre appli est sur l'App Store, la version Android encore en cours d'examen. Le formulaire enregistre sans aucun avertissement un code avec un seul lien de store. Dans notre test, sans lien de repli, les signatures Android sont parties vers l'App Store. Avec Google Play seul, une signature d'iPhone est partie vers Google Play. Avec un lien de repli, chacune a reçu ce lien.
Ne laissez donc jamais le troisième champ vide. Faites du lien de repli une page web avec les deux boutons de store : les ordinateurs y arrivent, l'iPad qui se dit Mac aussi. Pendant le mois du lancement, mettez-y un seul bouton et une ligne « bientôt sur Android ». Quand la version Android sort, un code dynamique permet d'ajouter son lien sans réimprimer.
Avant d'imprimer, testez avec un iPhone, un téléphone Android et un ordinateur, plus un iPad s'il y en a un sous la main. Puis écrivez à côté du code ce que les gens obtiennent, par exemple « Scannez pour obtenir notre appli de fidélité » : voyez quoi écrire à côté d'un QR code.
Un seul QR code pour plusieurs pays ou plusieurs langues
Une deuxième boutique ouvre de l'autre côté de la frontière, dans une ville bilingue. Un code par pays ? Par langue ?
Pour l'App Store, un lien de campagne rend souvent une règle inutile. Il se crée dans les outils développeur d'Apple, pour le marketing. Selon Apple, chaque personne qui en utilise un arrive dans le store de son pays, quel que soit celui que vise le lien. Les règles servent quand l'appli n'est pas disponible partout, ou pour une page par langue.
Le générateur que nous avons testé passe alors par un code de type site web et une section qu'il appelle « Règles intelligentes ». Disons que l'appli n'existe que dans un pays. Une règle envoie iOS plus ce pays vers l'App Store, une autre Android plus ce pays vers Google Play. Les autres reçoivent l'adresse principale du code : une page « bientôt disponible ».
Les règles se lisent de haut en bas, la première qui correspond l'emporte, et les conditions d'une même règle doivent toutes être réunies. Les mêmes règles peuvent aussi changer selon l'heure. Une règle iOS et France a attrapé une signature d'iPhone venant de France. Placée sous une simple règle iOS, elle ne s'est pas déclenchée : mettez la règle la plus précise en haut.
Le pays est celui d'où vient la connexion, testé depuis la France seulement : la règle France s'est déclenchée, pas la règle États-Unis au-dessus. La langue est celle du téléphone, pas de la personne : une requête annonçant l'anglais a reçu la règle anglaise, une requête annonçant le français la règle française.
Vous créez un QR code multilingue ? Vérifiez d'abord que le générateur liste votre pays et votre langue.
Ce qu'un seul QR code ne peut pas faire
Un mois après le lancement, le patron demande combien d'installations l'affiche a rapportées. Le code n'en sait rien.
Il compte des scans, pas des installations. Un code dynamique compte les ouvertures de son lien : ce que mesure un compteur de scans. Les stores mesurent les téléchargements. Les liens de campagne d'Apple comptent un premier téléchargement fait dans les 24 heures suivant l'utilisation du lien, et n'affichent de chiffre qu'à partir de 5. Google Play garde des informations de provenance, que le développeur de l'appli doit récupérer.
Il n'ouvre pas une appli déjà installée. Les habitués qui l'ont déjà sont eux aussi envoyés sur la page du store. Le générateur que nous avons testé a un autre type de code pour ça. Son lien sert une page qui tente d'ouvrir l'appli ; si rien ne s'est passé après 1,5 seconde, elle renvoie vers une adresse de repli. Nous avons lu la page servie, sans l'essayer sur un téléphone où l'appli est installée.
Il vit aussi longtemps que son service. Google avait fixé une date de fin à Firebase Dynamic Links, son propre service de liens pour applis : le 25 août 2025. Après cette date, selon la FAQ du service, « Tous les liens cliqués renverront une réponse de statut HTTP 404 aux utilisateurs finaux » (nous traduisons). Autrement dit : page introuvable ; les codes statiques ne courent pas ce risque. Voyez aussi si un QR code expire.
Ce que nous avons mesuré, et ce que cela ne prouve pas
Nous avons mené les tests le 13 novembre 2026, dans l'environnement de développement du générateur que nous avons testé. Un script a demandé sa réponse à chaque lien court sans la suivre, en changeant la signature et la langue annoncée. Nous avons créé 13 codes de test pour ces mesures ; il n'en reste aucun. Chaque code principal a reçu 25 requêtes : 22 signatures différentes, dont deux envoyées une seconde fois avec des indices en plus sur l'appareil, et une requête sans signature. Ces indices n'ont rien changé.
Nous avons ajouté un vrai scan. Le même jour, un iPhone a scanné un quatorzième code, réglé avec les trois mêmes liens, et a atterri sur la page App Store. Nous avons dessiné nous-mêmes l'image de ce code depuis son lien court ; ce code a disparu lui aussi.
Ce que cela ne prouve pas : en dehors de cet iPhone, aucun vrai téléphone ni iPad n'a scanné nos codes. Le pays n'a été mesuré que depuis un seul endroit, la France. Le cas d'une appli déjà installée n'a pas été testé. L'image exportée par le générateur n'a pas été vérifiée cette fois : qu'elle ne contienne que le lien court, nous le tenons d'un de nos tests précédents. Le service ouvert au public n'a pas été testé, seulement son environnement de développement.
Alors, un code ou deux ?
Un seul code dynamique à trois liens, dont le troisième mène à une page aux deux boutons de store, et un test sur trois appareils avant d'imprimer. Ou deux codes statiques, si vous préférez ne dépendre de personne. Dans les deux cas, écrivez à côté du code ce que les gens obtiennent.
Tous les tests ci-dessus ont tourné sur Oh My Code, notre propre générateur, dans son environnement de développement, avec un abonnement payant. Les codes dynamiques sont une fonction payante, avec un essai gratuit.
Créez le code de votre affiche et envoyez chaque téléphone à la bonne porte.
QR code pour télécharger une application : questions fréquentes
Peut-on créer un QR code pour une appli ?
Oui : soit un code par store, soit un seul code dynamique avec les deux liens de store et un lien de repli. Dans les deux cas, il vous faut les adresses de votre appli dans les stores. Pour un seul QR code iOS et Android, remplissez aussi le lien de repli : tant que l'appli n'est que sur un store, il évite le mauvais store aux téléphones.
Que se passe-t-il si quelqu'un ouvre le lien du code sur un ordinateur ?
Tout dépend du troisième lien. Avec un lien de repli, les ordinateurs arrivent dessus. Sans lui, sur le générateur que nous avons testé, un ordinateur a reçu un lien de store : celui de l'App Store quand les deux étaient remplis. Une page de repli avec les deux boutons de store laisse le choix au visiteur sur ordinateur et donne son bouton App Store à l'iPad qui se dit Mac.
Un QR code peut-il ouvrir une appli déjà installée ?
Pas un code qui mène à la page du store. Un code de type lien profond sert à ça : un lien profond pointe vers un écran de l'appli. Sa page tente d'ouvrir l'appli, puis se rabat sur une adresse web après une courte attente : 1,5 seconde sur le générateur que nous avons testé.
Peut-on savoir combien de personnes ont installé l'appli grâce au QR code ?
Pas avec le code, qui compte des scans. Les stores comptent les téléchargements : les liens de campagne d'Apple attribuent un premier téléchargement fait dans les 24 heures suivant l'utilisation du lien. Apple ne laisse en créer un qu'une fois que l'appli a des données : votre QR code App Store sera donc peut-être imprimé avant. Avec un code dynamique, le lien de campagne pourra remplacer plus tard le lien simple, sans réimprimer.
Un QR code pour une appli est-il gratuit ?
En partie. Deux codes statiques, un pour l'App Store et un QR code pour le Play Store, se créent sans payer. Un code unique qui choisit le store de chaque téléphone est un code dynamique : une fonction payante sur le générateur que nous avons testé. Voyez aussi s'il faut payer un QR code.
