# 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.

<details>

<summary><strong>Exemples concrets</strong></summary>

* Une marque de détail lance une carte de fidélité et se concentre d'abord sur le scan au point de vente, puis ajoute des campagnes CRM.
* Un lieu intègre d'abord la billetterie pour garantir l'accès, puis ajoute l'engagement post-événement.
* Une marque remplace les cartes d'adhésion en plastique par une Carte numérique, en utilisant un déploiement progressif par région.
* Une marque commence avec un seul modèle « core », puis ajoute des modèles saisonniers ou spécifiques à un événement.

</details>

## Aperçu de la feuille de route

La plupart des projets Wallet réussissent lorsque les opérations guident la conception. La Carte doit fonctionner au point de vente ou à la porte avant de devenir un canal marketing. The Wallet Crew priorise donc la validation précoce de la chaîne de bout en bout : systèmes sources → données de la Carte → distribution → installation du Wallet → utilisation.

La séquence ci‑dessous est la valeur par défaut. Certaines étapes peuvent se chevaucher. L'approche de « lotissement » reste la même : livrer de petits incréments, valider rapidement sur des appareils réels, puis étendre la portée.

## 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 la cadence de travail et définit ce que signifie « terminé » pour la première version.

Les livrables typiques incluent un calendrier de projet, une liste de responsables et un premier objectif de mise en production.
{% endstep %}

{% step %}

#### 2) Collecte des exigences (atelier)

The Wallet Crew organise un atelier dédié pour capturer les besoins et contraintes de la marque. C'est une session de travail, pas une présentation. L'objectif est de converger vers une première expérience Wallet « minimale viable ».&#x20;

L'atelier couvre généralement le cas d'utilisation de la Carte, les canaux de distribution, les contraintes de validation/scan, les champs de données requis, les attentes en matière de consentement/GDPR et les besoins en reporting.
{% endstep %}

{% step %}

#### 3) Configuration technique (tenant + wallets + domaine personnalisé)

Cette phase prépare la plateforme pour des tests sécurisés et une émission en production future.

Elle inclut typiquement :

* Provisionnement du tenant (staging et, le cas échéant, production).
* Configuration Apple Wallet (certificats, clés push, identité de signature).
* Configuration Google Wallet (accès au compte émetteur, compte de service / identifiants API).
* Mise en place d'un domaine personnalisé pour les liens brandés et les pages hébergées, si nécessaire.

Docs associés :

* Configuration du fournisseur Wallet : [Apple & Google wallet](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/apple-and-google-wallet)
* Certificats Apple : [Certificats Apple Wallet](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/apple-and-google-wallet/apple-wallet-certificates)
* Configuration de l'émetteur Google : [Compte Google Wallet](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/apple-and-google-wallet/google-wallet-account)
* Domaine personnalisé : [Configuration du domaine personnalisé](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/platform/configuring-custom-domain)
  {% endstep %}

{% step %}

#### 4) Définition de l'architecture IT (système de référence et propriété des données)

Cette phase définit où The Wallet Crew se situe dans le paysage IT global. Elle précise également quels systèmes restent la source de vérité pour chaque élément de données affiché sur la Carte.

La décision clé porte sur 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 lient une Carte aux systèmes de la marque dans le temps.

Docs associés :

* Modèle de données et identifiants : [Structure](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/develop/architecture/structure)
  {% endstep %}

{% step %}

#### 5) Définition du projet et lotissement (incréments agiles)

Cette phase transforme le périmètre en lots livrables. Chaque lot doit être testable sans travail futur. Cela réduit le risque de mise en production et évite les déploiements « big bang ».&#x20;

Une répartition courante est :

* Lot 1 : un modèle + un canal de distribution + un chemin de validation.
* Lot 2 : cycle de vie des mises à jour (rafraîchissement des champs, changements de statut, règles de désactivation).
* Lot 3 : segmentation, analyses et outils opérationnels.
* Lot 4 : automatisation marketing, notifications et personnalisation à grande échelle.
  {% endstep %}

{% step %}

#### 6) Flux 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 (« Ajouter au Wallet »), les écrans d'installation, les flux de secours (desktop → QR) et la manière dont la Carte est récupérée ultérieurement.

Les choix de distribution correspondent généralement à ces docs :

* [Formulaire d’inscription](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/enroll/enrolment-form)
* [Sur votre site web](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/enroll/on-your-website)
* [Via e‑mail](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/enroll/via-email)
* [Dans votre application mobile](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/enroll/on-your-mobile-app)
  {% 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 du modèle](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration)
* Référence de design : [Conception de la Carte (couleurs, images et champs)](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/configure/wallet/template-configuration/card-design-colors-images-and-fields)
  {% endstep %}

{% step %}

#### 8) Connecter d'abord les outils centraux (billetterie, POS, CRM/fidélité)

The Wallet Crew recommande de connecter les systèmes opérationnels centraux avant d'ajouter les couches marketing. Le Wallet est une preuve d'identité. Il doit fonctionner de manière fiable là où la Carte est utilisée.

Cette phase fournit généralement :

* Un flux de création/mise à jour opérationnel depuis les systèmes centraux.
* Une stratégie d'identifiants stable (numéro d'adhésion, ID de billet, code de carte cadeau, …).
* Un flux de validation validé en conditions réelles (scanner, POS, porte d'entrée).

Une fois cela stable, l'automatisation marketing peut être ajoutée sans mettre en danger les opérations.
{% endstep %}

{% step %}

#### 9) Ajouter le marketing et l'engagement (optionnel, après validation du cœur)

Cette phase ajoute l'engagement tout au long du cycle de vie, comme les notifications Wallet, la géolocalisation et les connecteurs d'automatisation marketing. Il est plus facile d'itérer une fois l'émission et la validation de la Carte stables.

Points d'entrée :

* Notifications : [Notifications push](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/engage-and-animate/push-notification)
* Déclencheurs de localisation : [Notifications géolocalisées](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/engage-and-animate/geolocated-notifications)
* Connecteurs marketing : [Automatisation marketing](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation)
  {% endstep %}

{% step %}

#### 10) Mise en production et opérations

Cette phase complète la préparation à la production : surveillance, runbooks de support et déploiement contrôlé. Elle définit également 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 en production, des vérifications sur appareils réels iOS et Android, et des tests de scan en environnements représentatifs.
{% endstep %}
{% endstepper %}

## Livrables courants (à quoi ressemble le « terminé »)

Lors de la mise en production, le package minimal attendu inclut généralement un modèle de Carte, un flux de distribution et un flux opérationnel de validation. Il inclut également une stratégie claire de mise à jour, afin que la Carte reste digne de confiance après l'installation.

À mesure que le programme s'étend, les livrables s'élargissent pour inclure des modèles supplémentaires, de la segmentation, du reporting et des fonctionnalités d'engagement optionnelles.

## FAQ

<details>

<summary><strong>Le projet peut-il démarrer avant que les comptes Apple/Google ne soient entièrement approuvés ?</strong></summary>

Oui, dans la plupart des cas. Les exigences, la définition UX et la conception des modèles peuvent commencer immédiatement. Les approbations et les identifiants des fournisseurs Wallet doivent être complétés avant l'émission en production.

</details>

<details>

<summary><strong>Pourquoi The Wallet Crew recommande-t-il de connecter les systèmes centraux avant les outils marketing ?</strong></summary>

Parce que le Wallet est utilisé lors de moments opérationnels. Si la validation au POS ou la billetterie est instable, l'amplification marketing augmente la charge de support. Une fois l'émission, les mises à jour et la validation fiables, l'automatisation marketing et les notifications peuvent être ajoutées en toute sécurité.

</details>

<details>

<summary><strong>Peut-on limiter le périmètre à un seul modèle pour la première version ?</strong></summary>

Oui. Un seul modèle est souvent le meilleur premier lot. Il garde le modèle de données et la gouvernance simples et permet une validation plus rapide sur les appareils et dans les magasins/lieux.

</details>

<details>

<summary><strong>Un domaine personnalisé est-il obligatoire ?</strong></summary>

Non. Un domaine personnalisé est recommandé lorsque des liens brandés et des pages hébergées alignées sur la marque sont nécessaires. Certains projets commencent sans, puis l'ajoutent avant la mise en production.

</details>

<details>

<summary><strong>Qu'est-ce qui cause généralement des retards ?</strong></summary>

Les retards proviennent généralement de dépendances externes : approbations des fournisseurs Wallet, modifications DNS pour les domaines personnalisés, revues de sécurité et clarification de la propriété des données entre systèmes. Garder les lots petits réduit l'impact de ces retards.

</details>