Étude de cas : comment Baifo envoie un seul QR vers l’App Store sur iOS et le web ailleurs

Baifo est une app de prière / bénédiction en ligne — et un client DYQR. Ils ont récemment ajouté deux supports de partage : une affiche « recommander à un proche » et une affiche de journal de prière. Les deux portent un QR avec une règle simple : si l’appareil qui scanne est un iPhone, l’envoyer vers l’App Store pour télécharger l’app ; s’il s’agit d’un autre type d’appareil (pas encore d’app), guider l’utilisateur vers la version web.

Presque toutes les équipes qui promeuvent une app mobile y passent. Voici à la fois leur parcours d’intégration et un tutoriel dont vous pourriez avoir besoin.

Pourquoi pas une bascule maison sur le User-Agent ?

Au départ, ils envisageaient une route /get sur baifo.life : lire le User-Agent, détecter iOS par regex, puis 302 vers la bonne cible. Le QR pointerait toujours vers cette URL.

C’est faisable — mais cela signifie bâtir toute une infrastructure :

• Règles de routage — plus tard, liens store Android, destinations par région : chaque changement = code, tests, redéploiement
• Analytique QR — au-delà du simple scan, il faut des stats de clics, de devices, etc.
• Croissance des canaux — plus de campagnes = plus de QR ; reconstruire un système de liens courts en interne est trop lourd à maintenir

L’équipe Baifo a donc confié ce travail à une plateforme QR / liens courts — la nôtre.

Tutoriel : routage par OS avec DYQR

Les étapes suivent l’assistant Nouveau lien en cinq étapes (captures réelles depuis app.dyqr.me). Smart Routing (dont les règles OS) est une capacité payante — un compte gratuit voit « Upgrade required » à l’étape 2. Vous préférez le terminal ? CLI / API en bas de page.

1. Créer un lien court avec une cible web par défaut

Tableau de bord → Nouveau lien. Définissez la destination par défaut (tout scan qui ne matche aucune règle y atterrit) :

• Title : par ex. « Téléchargement app Baifo »
• Default destination : https://baifo.life/

Choisissez le défaut pour « la plupart des gens » — pour Baifo, c’est le web. iOS sera surchargé par une règle à l’étape suivante.

2. Ajouter Smart Routing : OS = iOS → App Store

À l’étape Smart Routing, ajoutez une règle :

• When : Operating system
• Matches : iOS
• Then go to : https://apps.apple.com/cn/app/id6782394476 (votre URL App Store)

Points clés :

• Utilisez Operating system, pas Device — Device ne fait que mobile / desktop et ne sépare pas iPhone et Android
• Avec la règle active, iPhone (y compris le navigateur intégré WeChat) fait un 302 vers l’App Store ; le reste suit l’URL web par défaut
• Un store Android ou des stores par pays plus tard = édition de règles seulement, sans nouveau QR ni release app

3. Exporter le QR et l’intégrer à l’affiche

Dernière étape de l’assistant : prévisualisez et exportez le QR. L’affiche n’embarque que cette image (elle encode le lien court, pas l’URL finale) :

L’app et l’ops n’ont plus à maintenir la bascule. L’aperçu = ce que voient les scanners.

4. Après création

Une fois enregistré, le lien apparaît dans Links & QR codes avec une miniature QR ; titre, URL courte et destination par défaut sont visibles d’un coup d’œil.

Effet d’un scan :

• iPhone (y compris WeChat in-app) → App Store (règle)
• Android / navigateurs desktop → web baifo.life (défaut)
• Analytics → chaque scan est enregistré automatiquement

Optionnel : CLI / API

Si votre équipe préfère le terminal ou l’automatisation :

npx @dyqr/cli login
dyqr link create "https://baifo.life/" --title "Baifo App download"
dyqr qr <alias> --format svg -o poster-qr.svg

Attacher la règle OS (jeton Bearer : tableau de bord → Account → Connected apps) :

curl -X PATCH https://app.dyqr.me/api/links/<alias> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetUrl": "https://baifo.life/",
    "routingRules": [{
      "id": "ios_app_store",
      "enabled": true,
      "targetUrl": "https://apps.apple.com/cn/app/id6782394476",
      "conditions": [{ "type": "os", "os": ["ios"] }]
    }]
  }'

Ce que cette intégration réelle a appris au produit

Les besoins clients réels touchent souvent juste nos points faibles. Cette intégration nous a poussés à combler plusieurs trous rapidement — et à revalider tout le chemin :

• Nouvelle condition os : { type: 'os', os: ['ios'|'android'|'windows'|'macos'|'linux'] } de bout en bout — types partagés, resolvers gateway + admin, droits de plan, UI des règles, schéma de l’assistant IA. L’ordre UA compte : les UA iOS contiennent like Mac OS X (iOS avant macOS) ; les UA Android contiennent Linux (Android avant Linux).
• npx @dyqr/cli ne s’installait pas : les deps publiées pointaient vers une version workspace non publiée → 404 dès le premier login.
• Docs et MCP désalignés : le skill agent disait « routage uniquement en dashboard » alors que l’API le supportait déjà — le MCP n’exposait simplement pas le champ.

Les trois problèmes sont apparus sur un vrai parcours client, ont été corrigés, puis revérifiés sur le même parcours.

Pour qui

Si vous avez aussi besoin d’un QR « un scan, plusieurs destinations » — téléchargement d’app, landing par canal, contenu par région ou appareil — inutile de reconstruire une pile UA / GEO dans votre backend. Confiez cette couche aux liens courts DYQR + Smart Routing : changez les règles dans le dashboard ou via API / CLI / MCP ; le QR imprimé n’a jamais besoin de changer.