Les codes QR dynamiques ne doivent pas envoyer chaque scanneur vers la même URL. Le routage conditionnel — aussi appelé routage de scan ou redirections basées sur des règles — vous permet de diriger différents publics vers différentes destinations à partir d'un seul code imprimé. Si vous avez toujours souhaité que votre flyer du déjeuner redirige vers votre menu, votre foule du soir vers un formulaire de réservation, et vos visiteurs internationaux vers une page localisée, c'est exactement ce que cette fonctionnalité vous permet de faire.
Voici comment fonctionnent les scénarios de routage les plus utiles, ce qu'il faut configurer d'abord et où les gens font couramment erreur.
Ce que « Routage » Signifie Réellement dans un Contexte QR Dynamique
Lorsqu'un scanneur accède à un code QR dynamique, l'URL de destination du code est stockée sur un serveur — elle n'est pas intégrée au code lui-même. C'est sur ce serveur que réside la logique de routage. Au lieu d'une redirection plate (« tous les scans → URL A »), vous ajoutez des règles conditionnelles :
- Si la condition est remplie → envoyer vers l'URL A
- Sinon → envoyer vers l'URL B (la solution de secours)
La plupart des plateformes qui supportent cette fonctionnalité (parfois appelées « codes QR multi-URL » ou « codes QR de redirection intelligente ») vous permettent de superposer deux ou trois règles. L'URL de secours est toujours obligatoire. Comprendre la différence entre le comportement statique et dynamique est fondamental ici — la comparaison complète des codes QR statiques et dynamiques explique pourquoi la redirection réside sur un serveur et pourquoi cela est important pour le routage.
Scénario 1 : Routage Basé sur l'Heure de la Journée
Cas d'usage : Un café imprime un code QR sur une tente de table. Les scanneurs du matin voient le menu du petit-déjeuner ; les scanneurs de l'après-midi voient le menu du déjeuner ; les scanneurs du soir voient la carte des boissons.
Comment le configurer :
- Créez trois URL de destination (ou sections de page) pour chaque période de menu.
- Ajoutez des règles horaires en UTC — n'oubliez pas de tenir compte du décalage de votre fuseau horaire local.
- Définissez le cas d'usage le plus courant comme solution de secours au cas où un scanneur frapperait en dehors des heures définies.
Où cela peut mal tourner : Les équipes oublient que l'heure du scan est enregistrée par le serveur en UTC par défaut. Une règle définie pour « 11:00–14:00 » sans paramètre de fuseau horaire se déclenchera aux mauvaises heures pour les scanneurs de votre ville. Toujours confirmer la gestion des fuseaux horaires de votre plateforme avant l'impression.
Autres exemples pratiques :
- Les salles d'événements routent vers un programme pré-spectacle avant 19h, puis vers une boutique post-spectacle après 21h
- Les détaillants affichent une page d'accueil de vente flash uniquement pendant des fenêtres promotionnelles définies
- Les salles de sport envoient les horaires des cours en semaine et un emploi du temps de fin de semaine le samedi/dimanche
Scénario 2 : Routage par Pays ou Langue
Cas d'usage : Une boîte de produit expédie vers 12 pays. Un code QR route les marchés anglophones vers une page d'assistance en anglais, les marchés francophones vers la version française, et tous les autres vers un sélecteur de langue.
Comment le configurer :
- Le moteur de routage détecte le pays du scanneur via la géolocalisation par IP.
- Mappez des codes pays spécifiques (US, GB, CA → page anglaise ; FR, BE, CH → page française ; DE → page allemande).
- Définissez la page de sélecteur de langue comme solution de secours mondiale.
Mises en garde à documenter en interne :
- La géolocalisation par IP est précise au niveau du pays environ 95–99 % du temps, mais les utilisateurs de VPN vont mal router. C'est acceptable pour la plupart des cas d'usage.
- Ne routez pas en fonction de la préférence de langue détectée par le navigateur — les requêtes de scan QR ne transmettent pas de manière fiable les en-têtes Accept-Language à travers toutes les applications.
- Si votre plateforme facture par URL de destination ou par règle, groupez les pays ensemble plutôt que de lister 40 pays individuels.
Scénario 3 : Routage par Type d'Appareil
Cas d'usage : Une annonce imprimée d'une entreprise de logiciels s'exécute à la fois dans un magazine spécialisé et une newsletter pour développeurs. Les utilisateurs iOS accèdent à la liste de l'App Store ; les utilisateurs Android accèdent à Google Play ; les scanneurs de bureau (quelqu'un photographiant l'annonce sur la caméra de son ordinateur portable) accèdent à l'application web.
Comment le configurer :
- La plateforme lit la chaîne User-Agent de la requête de scan.
- Routez
iOS→ URL de l'App Store ;Android→ URL de Play Store ;Other/Desktop→ application web.
Pourquoi cela importe : Les pages de redirection de l'App Store sont notoirement mauvaises pour la détection automatique de plateforme. Envoyer des utilisateurs Android vers un lien App Store produit une erreur et tue les conversions. Le routage par appareil résout ce problème facilement sans nécessiter une implémentation personnalisée de bannière intelligente sur votre site web.
Scénario 4 : Combinaison de Règles (Routage Multi-Condition)
Certaines plateformes vous permettent d'empiler les règles — par exemple, pays ET appareil. Une configuration du monde réel courante :
| Priorité | Condition | Destination |
|---|---|---|
| 1 | Pays = US + Appareil = iOS | App Store US |
| 2 | Pays = US + Appareil = Android | Play Store US |
| 3 | Pays = DE | Page d'accueil allemande |
| 4 | Solution de secours | Page d'accueil mondiale |
Les règles sont évaluées de haut en bas, donc l'ordre importe. Mettez les conditions les plus spécifiques en premier, les règles géographiques larges au milieu, et la solution de secours en dernier. C'est facile à mal séquencer — testez toujours chaque condition avec un vrai appareil et, si possible, un VPN défini sur le pays pertinent avant d'imprimer à grande échelle.
Ce que Vous Pouvez Suivre par Route
Le routage n'est que la moitié du tableau. Chaque URL de destination doit porter des paramètres UTM pour que vous puissiez séparer les performances par segment d'audience dans votre plateforme d'analyse. Un scan routé vers la page française devrait déclencher ?utm_source=qr&utm_medium=print&utm_content=fr pour que vous puissiez le distinguer d'un scan générique.
Pour un regard plus approfondi sur les métriques à extraire de votre tableau de bord QR, le guide des analytics QR code qui guident vraiment vos décisions couvre le suivi scan-vers-conversion en détail.
Vous pouvez également utiliser les journaux de routage pour identifier les modèles de trafic inattendus — si 40 % des scans sur une impression réservée au Royaume-Uni déclenchent la « solution de secours non-UK », votre configuration de géolocalisation a besoin de vérification avant de augmenter les dépenses.
Liste de Vérification de la Plateforme Avant de S'engager dans le Routage
Pas toutes les plateformes QR dynamiques supportent le routage conditionnel. Avant d'en choisir une, confirmez :
- Règles horaires avec sélection du fuseau horaire (pas seulement UTC)
- Routage de géolocalisation par pays/région
- Détection du type d'appareil (iOS / Android / Autre minimum)
- Support d'empilement de règles ou multi-condition
- Analytics de scan par règle, pas seulement des totaux agrégés
- L'URL de secours est toujours obligatoire et modifiable
Si votre outil actuel manque ces éléments, Super QR Code Generator supporte le routage conditionnel sur l'heure, le pays et l'appareil avec les analytics par règle inclus.
Points Clés à Retenir
- Le routage envoie différents scanneurs vers différentes URLs à partir d'un seul code QR imprimé, en utilisant la logique de redirection côté serveur.
- Le routage horaire nécessite une configuration correcte du fuseau horaire — les défauts UTC vont mal fonctionner dans la plupart des marchés.
- Le routage par pays utilise la géolocalisation par IP, qui est fiable au niveau du pays mais échoue pour les utilisateurs VPN.
- Le routage par appareil est la solution la plus propre pour les campagnes de téléchargement d'applications qui doivent séparer les destinations iOS et Android.
- Ajoutez toujours des paramètres UTM à chaque URL routée pour que les analytics en aval restent segmentées.
- Testez chaque règle de routage avec un vrai appareil (et idéalement un VPN) avant d'imprimer à grande échelle.