> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/docs/fr/demarrer/readme/implementation-roadmap.md).
# Feuille de route de mise en œuvre
Cette feuille de route décrit la séquence typique pour lancer un programme Wallet avec The Wallet Crew. Elle commence à la signature du contrat et se termine à la mise en production, avec une approche de livraison agile et de petits incréments testables.
Exemples concrets
* Une marque de distribution lance une carte de fidélité et se concentre d’abord sur le scan en point de vente, puis ajoute des campagnes CRM.
* Un lieu intègre d’abord la billetterie pour s’assurer que l’entrée fonctionne, puis ajoute l’engagement après l’événement.
* Une marque remplace les cartes d’adhérent en plastique par une carte numérique, avec un déploiement progressif par région.
* Une marque commence avec un unique modèle « core », puis ajoute des modèles saisonniers ou spécifiques à un événement.
## Vue d’ensemble de la feuille de route
La plupart des projets Wallet réussissent lorsque les opérations pilotent la conception. La carte doit fonctionner au point de vente ou à l’entrée avant de devenir un canal marketing. The Wallet Crew privilégie donc la validation précoce de la chaîne de bout en bout : systèmes sources → données de la carte → distribution → installation dans le Wallet → validation.
La séquence ci-dessous est la valeur par défaut. Certaines étapes peuvent se chevaucher. L’approche de livraison par lots reste la même : livrer de petits incréments, valider rapidement sur de vrais appareils, puis élargir le périmètre.
## Phases du projet (contrat → mise en production)
{% stepper %}
{% step %}
#### 1) Contrat et lancement
Cette phase aligne le périmètre, les parties prenantes et les contraintes. Elle fixe le rythme de travail et définit ce que signifie « terminé » pour la première version.
Les livrables typiques incluent un calendrier de projet, une liste des responsables et une première cible de mise en production.
{% endstep %}
{% step %}
#### 2) Collecte des besoins (atelier)
The Wallet Crew organise un atelier dédié pour recueillir les besoins et contraintes de la marque. Il s’agit d’une séance de travail, pas d’une présentation. L’objectif est de converger vers une première expérience Wallet « minimale viable ».
L’atelier couvre généralement le cas d’usage de la carte, les canaux de distribution, les contraintes de validation/de scan, les champs de données requis, les attentes en matière de consentement/RGPD et les besoins de reporting.
{% endstep %}
{% step %}
#### 3) Configuration technique (tenant + Wallets + domaine personnalisé)
Cette phase prépare la plateforme pour des tests sécurisés et de futures émissions en production.
Elle comprend généralement :
* Provisionnement du tenant (préproduction et, le cas échéant, production).
* Configuration Apple Wallet (certificats, clés de push, identité de signature).
* Configuration Google Wallet (accès au compte émetteur, compte de service / identifiants API).
* Configuration d’un domaine personnalisé pour les liens de marque et les pages hébergées, si nécessaire.
Docs associées :
* Configuration du fournisseur de Wallet : [Apple et Google Wallet](/configure/fr/advanced-configuration/wallet/wallet-card-security.md)
* Certificats Apple : [Certificats Apple Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/apple-wallet-certificates.md)
* Configuration de l’émetteur Google : [Compte Google Wallet](/configure/fr/advanced-configuration/wallet/apple-and-google-wallet/google-wallet-account.md)
* Domaine personnalisé : [Domaine personnalisé](/configure/fr/advanced-configuration/platform/custom-domain.md)
{% endstep %}
{% step %}
#### 4) Définition de l’architecture informatique (système de référence et propriété des données)
Cette phase définit la place de The Wallet Crew dans le paysage informatique global. Elle précise aussi quels systèmes restent la source de vérité pour chaque élément de données affiché sur la carte.
La décision clé concerne le flux de données : ce qui déclenche la création de la carte, comment les mises à jour sont calculées et comment les identifiants relient une carte aux systèmes de la marque dans le temps.
Docs associées :
* Modèle de données et identifiants : [Structure](/developers-guides/fr/pass-architecture/structure.md)
{% endstep %}
{% step %}
#### 5) Définition du projet et livraison par lots (incréments agiles)
Cette phase transforme le périmètre en lots livrables. Chaque lot doit pouvoir être testé sans travail ultérieur. Cela réduit le risque de mise en production et évite les déploiements « big bang ».
Une découpe courante est la suivante :
* Lot 1 : un modèle + un canal de distribution + un parcours de validation.
* Lot 2 : cycle de vie des mises à jour (actualisation des champs, changements de statut, règles de désactivation).
* Lot 3 : segmentation, analytics et outils opérationnels.
* Lot 4 : automatisation marketing, notifications et personnalisation à grande échelle.
{% endstep %}
{% step %}
#### 6) Parcours d’expérience utilisateur (installation → présentation → mise à jour)
Cette phase définit le parcours client et le parcours opérationnel. Elle inclut les points d’entrée (« Add to Wallet »), les écrans d’installation, les parcours de repli (ordinateur de bureau → QR) et la manière dont la carte est récupérée plus tard.
Les choix de distribution renvoient généralement aux docs suivantes :
* [Formulaire d’inscription](/guides-enrolment/fr/inscription/enrolment-form.md)
* [Sur votre site web](/guides-enrolment/fr/inscription/on-your-website.md)
* [Par e-mail](/guides-enrolment/fr/inscription/via-email.md)
* [Dans votre application mobile](/guides-enrolment/fr/inscription/readme-1.md)
{% endstep %}
{% step %}
#### 7) Configuration de la carte (modèles + champs + code-barres)
Cette phase traduit l’UX et le modèle de données en une configuration de modèle de carte pour Apple Wallet et Google Wallet. Elle couvre les éléments de branding, la disposition des champs, les liens et la charge utile du code-barres/QR.
La configuration des modèles se trouve sous :
* [Configuration des modèles](/configure/fr/advanced-configuration/wallet/template-configuration.md)
* Référence de conception : [Conception de carte (couleurs, images et champs)](/configure/fr/advanced-configuration/wallet/template-configuration/cards-design-colors-images-and-fields.md)
{% endstep %}
{% step %}
#### 8) Connecter d’abord les outils cœur (billetterie, POS, CRM/fidélité)
The Wallet Crew recommande de connecter d’abord les systèmes opérationnels cœur avant d’ajouter des couches marketing. Wallet est un justificatif. Il doit fonctionner de manière fiable là où la carte est utilisée.
Cette phase livre généralement :
* Un flux opérationnel de création/mise à jour fonctionnel depuis les systèmes cœur.
* Une stratégie d’identifiants stable (numéro d’adhérent, identifiant de billet, code de carte cadeau, …).
* Un parcours de validation validé en conditions réelles (scanner, POS, tourniquet d’entrée).
Une fois cela stabilisé, l’automatisation marketing peut être ajoutée sans mettre les opérations en risque.
{% endstep %}
{% step %}
#### 9) Ajouter le marketing et l’engagement (optionnel, après la validation du cœur)
Cette phase ajoute des actions d’engagement sur le cycle de vie, telles que les notifications Wallet, la géolocalisation et les connecteurs d’automatisation marketing. Il est plus facile d’itérer une fois que l’émission et la validation de base sont stabilisées.
Points d’entrée :
* Notifications : [Notifications push](/guides-animation/fr/engagement-et-animation/push-notification.md)
* Déclencheurs de localisation : [Notifications géolocalisées](/guides-animation/fr/engagement-et-animation/geolocated-notifications.md)
* Connecteurs marketing : [Automatisation marketing](/connectors/fr/marketing-automation.md)
{% endstep %}
{% step %}
#### 10) Mise en production et opérations
Cette phase finalise la préparation à la production : supervision, modes opératoires de support et déploiement contrôlé. Elle définit aussi comment les changements sont livrés après la mise en production (mises à jour de modèles, ajouts de champs, nouveaux lots).
La validation typique inclut un pilote de production, des vérifications sur appareils réels iOS et Android, ainsi que des tests de scan dans des environnements représentatifs.
{% endstep %}
{% endstepper %}
## Livrables courants (à quoi ressemble « terminé »)
À la mise en production, le package minimal attendu comprend généralement un modèle de carte, un flux de distribution et un flux opérationnel de validation. Il inclut aussi une stratégie de mise à jour claire, afin que la carte reste fiable après l’installation.
À mesure que le programme prend de l’ampleur, les livrables s’étendent à des modèles supplémentaires, à la segmentation, au reporting et à des fonctionnalités d’engagement optionnelles.
## FAQ
Le projet peut-il commencer avant que les comptes Apple/Google soient entièrement approuvés ?
Oui, dans la plupart des cas. La collecte des besoins, la définition de l’UX et la conception du modèle peuvent commencer immédiatement. Les approbations et identifiants du fournisseur de Wallet doivent être finalisés avant l’émission en production.
Pourquoi The Wallet Crew recommande-t-il de connecter les systèmes cœur avant les outils marketing ?
Parce que le Wallet est utilisé dans des moments opérationnels. Si la validation en POS ou en billetterie est instable, l’amplification marketing augmente la charge de support. Une fois que l’émission, les mises à jour et la validation cœur sont fiables, l’automatisation marketing et les notifications peuvent être ajoutées en toute sécurité.
Le périmètre peut-il être limité à un seul modèle pour la première version ?
Oui. Un seul modèle est souvent le meilleur premier lot. Il simplifie le modèle de données et la gouvernance, et permet une validation plus rapide sur les appareils et en magasin/dans les lieux.
Un domaine personnalisé est-il obligatoire ?
Non. Un domaine personnalisé est recommandé lorsque des liens de marque et des pages hébergées alignées sur la marque sont nécessaires. Certains projets démarrent sans lui, puis l’ajoutent avant la mise en production.
Qu’est-ce qui cause généralement des retards ?
Les retards proviennent généralement de dépendances externes : approbations du fournisseur de Wallet, changements DNS pour les domaines personnalisés, revues de sécurité et clarification de la propriété des données entre systèmes. Garder des lots petits réduit l’impact de ces retards.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/docs/fr/demarrer/readme/implementation-roadmap.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.