> 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/send-wallet-events-to-your-tools.md).

# Envoyer les événements Wallet à vos outils

Envoyer les événements d’installation, de désinstallation, de scan et de notification du Wallet vers les outils CRM, CDP, BI et d’entrepôt de données avec des webhooks, des connecteurs personnalisés, l’API Carte ou l’API Insights.

Le Wallet Crew ne verrouille pas les données à l’intérieur de 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" %}
Les données Wallet appartiennent à la marque. Le Wallet Crew émet chaque événement de Carte en temps réel, et la marque décide où il va et ce qui en est fait.
{% endhint %}

<details>

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

* 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 dans BigQuery ou Snowflake, puis utilise l’API Insights pour suivre chaque semaine les installations par `canal`, `Étiquette`, ou `Hôte`.
* Une équipe e-commerce conserve en temps réel l’état des installations dans sa stack avec des webhooks, puis utilise un backfill quotidien de l’API Carte pour corriger les écarts après des interruptions.

</details>

## 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 les suppressions sur Apple Wallet et Google Wallet, et chaque Wallet peut changer d’état indépendamment.

C’est important parce que l’état d’installation est spécifique au 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" %}
Chaque Carte doit inclure un identifiant externe stable, tel que `customerId` ou `e-mail`. Cet identifiant est utilisé pour réconcilier les événements avec les enregistrements dans le reste de la stack.
{% endhint %}

## Choisissez la bonne méthode de synchronisation

Pour les mises à jour en temps réel, utilisez **webhooks** ou un **connecteur personnalisé**.

Pour les tâches par lot ou les backfills, utilisez l’ **API Carte**.

Lorsque seuls les totaux et les tendances sont nécessaires, utilisez l’ **API Insights**.

## Commencez par l’API Insights pour l’analyse agrégée

Lorsqu’il n’est pas nécessaire de synchroniser chaque client et que l’objectif est d’interroger les tendances et les données agrégées, commencez par l’ **API Insights**. C’est le chemin le plus rapide vers des questions telles que « combien de Cartes ont été installées cette semaine par canal ? »

Utilisez Insights lorsque les totaux, les tendances et l’analyse groupée comptent plus que les mises à jour au niveau de l’enregistrement. Interrogez des événements tels que `Carte:Installed` et `Carte:Uninstalled` avec KQL.

Étape suivante : configurez l’authentification et exécutez une première requête.

Voir [API Insights](/developers-guides/fr/integration-guides/insights-api.md).

Pour l’analyse agrégée dans le back-office, utilisez [Tableaux de bord analytiques](/guides-monitoring/fr/monitor/tableaux-de-bord-analytics.md). Pour les enregistrements au niveau de la Carte, utilisez [Rapport](/guides-monitoring/fr/monitor/report.md).

## Décidez quoi synchroniser dans la stack

Commencez par définir la « vérité » que la stack doit stocker. La plupart des équipes conservent à la fois un statut simple et quelques horodatages dans le CRM ou le CDP.

Un champ global plus des champs par Wallet fonctionne généralement le mieux. Cela permet la segmentation sans perdre de détails.

Champs courants :

* `walletStatus`: `aucun`, `Apple`, `Google`, `les deux`
* `appleWalletInstalledAt`: horodatage, facultatif
* `googleWalletInstalledAt`: horodatage, facultatif
* `walletLastChangedAt`: horodatage
* `walletLastEvent`: installé ou désinstallé

{% hint style="warning" %}
Traitez les événements comme **une livraison au moins une fois**. Attendez-vous à des doublons et à des livraisons hors ordre.
{% endhint %}

## Réconciliez les événements avec les enregistrements dans la stack

La synchronisation a besoin d’une clé de jointure. Utilisez un identifiant externe stable stocké sur la Carte.

Les bons identifiants sont `customerId`, `accountId`, ou un e-mail normalisé. Évitez les identifiants susceptibles de changer fréquemment.

Lorsqu’un événement arrive, associez-le à un seul enregistrement dans la stack. Puis mettez à jour les indicateurs par Wallet et le statut global conservé dans la stack.

## Comprenez les cas limites

L’installation est spécifique au Wallet. Un même client peut s’installer sur Apple Wallet et Google Wallet.

La désinstallation reste elle aussi spécifique au Wallet. Une désinstallation sur Apple Wallet n’implique pas une désinstallation sur Google Wallet.

Certains clients réinstallent rapidement. Utilisez des 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 un point de terminaison récepteur au fur et à mesure qu’ils se produisent. Abonnez-vous à `Carte:Installed` et `Carte:Uninstalled`.

Étape suivante : configurez le point de terminaison du webhook et validez les signatures.

Voir [Webhooks](/developers-guides/fr/integration-guides/webhooks.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 formats de charge utile personnalisés. 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 du débit et les nouvelles tentatives.

Étape suivante : implémentez `OnCarteInstalled` et `OnCarteUninstalled`.

Voir [Hooks d’installation et de désinstallation de Carte](/connectors/fr/custom-connector/installation-changed-extensibility.md).

## Option 3 — API Carte (synchronisation par lot + backfills)

Utilisez l’API Carte pour 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 interruption.

Commencez par la documentation 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 les événements en temps réel pour la rapidité. Utilisez le backfill pour la cohérence.

Si la stack et les Cartes divergent, faites confiance à l’API Carte. Réparez ensuite l’enregistrement en aval et poursuivez.

## Un workflow 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 vers la stack

Utilisez les webhooks pour la plupart des configurations. Utilisez un connecteur personnalisé lorsqu’une charge utile différente est nécessaire.
{% endstep %}

{% step %}

### 3) Mettez à jour les champs et les segments dans les outils en aval

Mettez à jour les indicateurs par Wallet et les horodatages. Recalculez le statut global `walletStatus`.
{% endstep %}

{% step %}

### 4) Effectuez régulièrement un backfill

Planifiez une tâche d’API Carte. Utilisez-la pour corriger les dérives et couvrir les interruptions.
{% endstep %}

{% step %}

### 5) Suivez l’adoption avec Insights

Utilisez Insights pour les tendances et la supervision. Vérifiez que les installations et les désinstallations correspondent aux attentes.
{% endstep %}
{% endstepper %}

## Dépannage

Lorsque aucun événement n’arrive, commencez par valider la signature. Vérifiez ensuite la disponibilité du point de terminaison et la gestion des nouvelles tentatives.

Lorsque des doublons apparaissent, ajoutez de l’idempotence dans le chemin d’écriture en aval. Utilisez l’horodatage le plus récent comme critère de départage.

Lorsque les événements ne peuvent pas être associés aux clients, un identifiant manque. Ajoutez-le aux données de la Carte, puis effectuez un backfill pour corriger l’historique.

## FAQ

<details>

<summary>Quelle option faut-il utiliser en premier ?</summary>

Commencez par l’ **API Insights** lorsque seules les tendances agrégées comptent. Commencez par **webhooks** lorsque les événements doivent atteindre en temps réel un CRM, un CDP ou un outil d’automatisation. Ajoutez l’ **API Carte** lorsqu’un backfill fiable est également nécessaire.

</details>

<details>

<summary>Pourquoi utilise-t-on souvent ensemble les événements en temps réel et un backfill par lot ?</summary>

La livraison en temps réel maintient les parcours, alertes et segments à jour. Un backfill planifié de l’API Carte corrige les écarts causés par les nouvelles tentatives, les interruptions ou les défaillances temporaires en aval.

</details>

<details>

<summary>Pourquoi un identifiant stable est-il obligatoire ?</summary>

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 la réconciliation fiable sur les webhooks, les connecteurs et les tâches par lot.

</details>

<details>

<summary>Le même client peut-il apparaître comme installé sur Apple Wallet et Google Wallet ?</summary>

Oui. L’installation est spécifique au 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.

</details>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.thewalletcrew.io/guides-monitoring/fr/monitor/send-wallet-events-to-your-tools.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.