> 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/guides-monitoring/fr/monitor/sync-pass-installation-status-to-your-crm.md).
# Envoyer les événements Wallet vers vos outils
The Wallet Crew ne verrouille pas les données dans la plateforme. Chaque événement émis dans un programme Wallet peut être envoyé vers un CRM, un CDP, un outil BI ou un entrepôt de données. Quatre voies d’intégration couvrent la plupart des besoins : **webhooks**, un **connecteur personnalisé**, l’ **API Carte** et l’ **API Insights**.
{% hint style="info" %}
Vos données de Wallet vous appartiennent. The Wallet Crew émet chaque événement de Carte en temps réel — vous décidez où il va et ce que vous en faites.
{% endhint %}
Exemples concrets du monde réel
* Une équipe CRM ou CDP envoie `Carte:Installed` des événements dans Braze ou Salesforce pour déclencher des parcours d’intégration après l’adoption du Wallet.
* Une équipe BI diffuse les événements Wallet vers BigQuery ou Snowflake, puis utilise l’API Insights pour suivre les installations hebdomadaires par `Média`, `Étiquette`, ou `Hôte`.
* Une équipe e-commerce conserve en temps réel l’état des installations dans sa pile avec des webhooks, puis utilise un backfill quotidien via l’API Carte pour corriger les écarts après des interruptions.
### Ce que signifie le « statut d’installation »
Le statut d’installation est un signal de cycle de vie émis lorsqu’un utilisateur ajoute ou supprime une Carte. Il couvre les installations et suppressions sur Apple Wallet et Google Wallet, et chaque Wallet peut changer d’état indépendamment.
C’est important car l’état d’installation dépend du Wallet. Le même client peut installer une Carte sur Apple Wallet, Google Wallet ou les deux, et chaque événement de suppression doit être interprété dans ce contexte.
{% hint style="info" %}
Assurez-vous que chaque Carte inclut un identifiant externe stable, comme `customerId` ou `email`. Cet identifiant est utilisé pour rapprocher les événements avec les enregistrements du reste de la pile.
{% endhint %}
### Choisissez la bonne méthode de synchronisation
Si vous voulez des mises à jour en temps réel, utilisez **webhooks** ou un **connecteur personnalisé**.
Si vous préférez des tâches batch ou des backfills, utilisez l’ **API Carte**.
Si vous avez surtout besoin de comptages et de tendances, utilisez **API Insights**.
### Commencez par l’API Insights pour une analyse agrégée
S’il n’est pas nécessaire de synchroniser par client et que l’objectif est d’interroger les tendances et les données agrégées, commencez par l’ **API Insights**API Insights. C’est la voie la plus rapide vers des questions comme « combien de Cartes ont été installées cette semaine par canal ? »
Utilisez Insights lorsque les comptages, les tendances et l’analyse groupée comptent plus que les mises à jour au niveau des enregistrements. Interrogez des événements tels que `Carte:Installed` et `Carte:Uninstalled` avec KQL.
Étape suivante : configurez l’authentification et lancez une première requête.
Voir [API Insights](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/insights-api.md).
Pour l’analyse agrégée au sein de The Wallet Crew, comparez [Statistiques](broken://spaces/tJnneV8b22BGeGPcyzLG/pages/f6867ac1354ba3babf518fe33153a493bbd2663f) et [Rapport](/guides-monitoring/fr/monitor/report.md).
### Décidez quoi synchroniser dans vos outils
Commencez par définir la « vérité » que la pile doit stocker. La plupart des équipes conservent à la fois un statut simple et quelques horodatages dans le CRM ou le CDP.
Vous voulez généralement un champ global, plus des champs par Wallet. Cela vous permet de segmenter sans perdre le détail.
Champs courants :
* `walletStatus`: `aucun`, `apple`, `google`, `les deux`
* `appleWalletInstalledAt`: horodatage, facultatif
* `googleWalletInstalledAt`: horodatage, facultatif
* `walletLastChangedAt`: horodatage
* `walletLastEvent`: installée ou désinstallée
{% hint style="warning" %}
Traitez les événements comme **une livraison au moins une fois**. Attendez-vous à des doublons et à une livraison hors ordre.
{% endhint %}
### Rapprochez les événements des enregistrements de votre pile
Votre synchronisation a besoin d’une clé de jointure. Utilisez un identifiant externe stable stocké sur la Carte.
De bons identifiants sont `customerId`, `accountId`, ou un e-mail normalisé. Évitez les identifiants susceptibles de changer fréquemment.
Lorsqu’un événement arrive, rattachez-le à un seul enregistrement dans la pile. Puis mettez à jour les indicateurs par Wallet et le statut global conservé dans la pile.
### Comprenez les cas limites
L’installation dépend du Wallet. Un seul client peut installer sur Apple Wallet et Google Wallet.
La désinstallation dépend elle aussi du Wallet. Une désinstallation sur Apple n’implique pas une désinstallation sur Google.
Certains clients réinstallent rapidement. Utilisez les horodatages pour éviter les oscillations de statut dans les outils en aval.
### Option 1 — Webhooks (temps réel, effort minimal)
Les webhooks envoient les événements vers votre point de terminaison au fur et à mesure qu’ils se produisent. Abonnez-vous à `Carte:Installed` et `Carte:Uninstalled`.
Étape suivante : configurez votre point de terminaison webhook et validez les signatures.
Voir [Recevez l’événement The Wallet Crew via webhook](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/webhook.md).
### Option 2 — Connecteur personnalisé (temps réel, charge utile personnalisée)
Utilisez un connecteur personnalisé lorsque la charge utile par défaut du webhook ne suffit pas.
C’est le bon choix pour des structures de charge utile personnalisées. C’est aussi utile pour une authentification personnalisée (clé API, OAuth) ou une logique supplémentaire.
La logique typique comprend le routage, l’enrichissement, la limitation de débit et les nouvelles tentatives.
Étape suivante : implémentez `OnCarteInstalled` et `OnCarteUninstalled`.
Voir [Connecteur personnalisé pour appeler l’API lorsque le statut d’installation de la Carte change](https://github.com/TheWalletCrew/docs/blob/main/guides/connect/custom-connector/installation-changed-extensibility.md).
### Option 3 — API Carte (synchronisation batch + backfills)
Utilisez l’API Carte lorsque vous souhaitez synchroniser périodiquement l’état d’installation.
C’est aussi le meilleur choix pour reconstruire l’état dans les outils en aval après une indisponibilité.
Commencez par la référence de l’API. Recherchez les points de terminaison de liste de Cartes pouvant être filtrés par statut d’installation.
#### Schéma de backfill qui fonctionne bien
Exécutez une tâche planifiée qui recalcule le statut de référence à partir de l’API Carte. La plupart des équipes l’exécutent quotidiennement.
Utilisez vos événements en temps réel pour la rapidité. Utilisez le backfill pour la cohérence.
Si la pile et les Cartes ne concordent pas, fiez-vous à l’API Carte. Puis corrigez l’enregistrement en aval et continuez.
### Un flux de travail pragmatique de bout en bout
{% stepper %}
{% step %}
### 1) Ajoutez un identifiant stable à chaque Carte
Choisissez un identifiant. Utilisez le même champ sur chaque Carte.
{% endstep %}
{% step %}
### 2) Envoyez les événements en temps réel à votre pile
Utilisez les webhooks pour la plupart des configurations. Utilisez un connecteur personnalisé si vous avez besoin d’une charge utile différente.
{% endstep %}
{% step %}
### 3) Mettez à jour les champs et les segments dans vos outils
Mettez à jour les indicateurs par Wallet et les horodatages. Recalculez le global `walletStatus`.
{% endstep %}
{% step %}
### 4) Effectuez des backfills régulièrement
Planifiez une tâche API Carte. Utilisez-la pour corriger les écarts et couvrir les interruptions.
{% endstep %}
{% step %}
### 5) Suivez l’adoption avec Insights
Utilisez Insights pour les tendances et la surveillance. Vérifiez que les installations et désinstallations correspondent aux attentes.
{% endstep %}
{% endstepper %}
### Dépannage
Si vous ne voyez pas d’événements, commencez par valider la signature. Vérifiez ensuite la disponibilité du point de terminaison et la gestion des nouvelles tentatives.
Si vous voyez des doublons, ajoutez de l’idempotence dans le chemin d’écriture en aval. Utilisez l’horodatage le plus récent comme critère de départage.
Si vous ne parvenez pas à associer les événements aux clients, il manque un identifiant. Ajoutez-le aux données de la Carte, puis lancez un backfill pour réparer l’historique.
### FAQ
Quelle option faut-il utiliser en premier ?
Commencez par le **API Insights** lorsque seules les tendances agrégées comptent. Commencez par **webhooks** lorsque les événements doivent atteindre un CRM, un CDP ou un outil d’automatisation en temps réel. Ajoutez le **API Carte** lorsqu’un backfill fiable est également nécessaire.
Pourquoi les événements en temps réel et un backfill par lots sont-ils souvent utilisés ensemble ?
La livraison en temps réel maintient les parcours, les alertes et les segments à jour. Un backfill planifié via l’API Carte corrige les écarts causés par les relances, les interruptions ou les défaillances temporaires en aval.
Pourquoi un identifiant stable est-il obligatoire ?
Les événements Wallet ne sont utiles en aval que lorsqu’ils peuvent être associés au bon enregistrement. Un identifiant stable, tel que `customerId` ou un e-mail normalisé, rend le rapprochement fiable entre les webhooks, les connecteurs et les tâches batch.
Le même client peut-il apparaître comme installé sur Apple et Google ?
Oui. L’installation dépend du Wallet. Le même client peut détenir la même Carte dans Apple Wallet et Google Wallet, donc les modèles en aval doivent conserver des champs par Wallet ainsi qu’un statut global.
---
# 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/guides-monitoring/fr/monitor/sync-pass-installation-status-to-your-crm.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.