> 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/developers-guides/fr/integration-guides/wallet/connector-triggered-pass-creation.md).

# Création de cartes déclenchée par un connecteur

## Création de Carte déclenchée par le connecteur

Certaines intégrations créent des Cartes automatiquement à partir d’événements du système source. Au lieu qu’un frontend ou un SDK crée la Carte pendant un parcours d’inscription destiné à l’utilisateur, le connecteur crée la Carte lorsqu’un événement pertinent se produit dans le système en amont.

Ce modèle est utile lorsque le système source est déjà le système de référence pour les événements d’éligibilité ou de cycle de vie. La règle clé reste la même : la Carte doit être créée avec les bons identifiants externes, car les rendus ultérieurs dépendent de ces identifiants pour récupérer les données en direct.

<details>

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

* Un événement CRM crée une Carte de fidélité lorsqu’un client rejoint un programme.
* Un événement de billetterie crée une Carte lorsqu’une commande est confirmée.
* Un système d’adhésion crée une Carte lorsqu’un abonnement actif démarre.

</details>

### Quand ce modèle est utilisé

La création déclenchée par le connecteur est le bon modèle lorsque l’émission de la Carte doit suivre un événement système plutôt qu’une action utilisateur dans un frontend personnalisé.

Les exemples courants sont la création d’un client, la confirmation d’une commande, l’activation d’un abonnement ou tout autre événement en amont qui prouve qu’une Carte doit exister. Une fois la Carte créée, la distribution et l’installation peuvent avoir lieu plus tard via le canal choisi par le projet.

Si le projet a plutôt besoin d’un parcours de création destiné à l’utilisateur, utilisez [Flux d’inscription](/developers-guides/fr/integration-guides/wallet/enrolment-flows.md).

### Ce que le connecteur doit fournir

Au moment de la création, le connecteur doit fournir les identifiants nécessaires pour les recherches ultérieures.

Ces identifiants externes constituent le lien durable entre la Carte et l’enregistrement source. Sans eux, les rendus ultérieurs ne peuvent pas récupérer de manière fiable les données client ou transactionnelles.

Le connecteur peut également définir des valeurs au niveau de la Carte, comme des données supplémentaires, lorsque le projet nécessite des remplacements stockés qui ne proviennent pas d’une recherche en direct du connecteur.

Utilisez [Données de Carte et synchronisation](/developers-guides/fr/pass-architecture/pass-data-and-sync.md) pour le modèle de données derrière ce flux.

### Ce qui se passe après la création

Une fois que le connecteur a créé la Carte, le reste du cycle de vie suit le même modèle que pour toute autre Carte.

La plateforme ne copie pas les données source dans un stockage à long terme pour les garder synchronisées en arrière-plan. Les rendus ultérieurs récupèrent toujours les données en direct depuis les systèmes source. Si les données source changent, un déclencheur de rendu est toujours nécessaire avant que la Carte installée ne change.

Les déclencheurs courants sont l’installation dans le Wallet, l’aperçu et la mise à jour push.

Utilisez [Comment une Carte est rendue](/developers-guides/fr/pass-architecture/how-a-pass-is-rendered.md) pour le pipeline de rendu complet et [Prise en main de l’API](/developers-guides/fr/integration-guides/getting-started-with-the-api.md) pour les mises à jour pilotées par l’API après la création.

### Conséquences opérationnelles

Ce modèle de création change l’endroit où les erreurs apparaissent généralement.

Si une Carte n’est pas créée, le premier endroit à examiner est l’événement en amont et le chemin du connecteur qui le traite. Si la Carte existe mais que les rendus ultérieurs affichent des champs vides, le premier endroit à examiner est celui des identifiants externes stockés sur la Carte.

{% hint style="warning" %}
Créer une Carte à partir d’un événement de connecteur ne garantit pas que les recherches ultérieures du connecteur réussiront. La création de la Carte et les récupérations de données ultérieures au moment du rendu dépendent du stockage des bons identifiants sur la Carte.
{% endhint %}

### Comparer les modèles de création

#### Création déclenchée par le connecteur

Un événement système crée automatiquement la Carte. Cela fonctionne bien lorsque le système source décide déjà qui doit recevoir une Carte.

#### Création via flux d’inscription

Un frontend ou un flux hébergé crée la Carte pendant un parcours destiné à l’utilisateur. Cela fonctionne bien lorsque le projet contrôle directement l’inscription, l’enregistrement ou le paiement.

Dans les deux modèles, l’API est utilisée après la création pour les mises à jour, les notifications, les scans et d’autres opérations du cycle de vie. Utilisez [Prise en main de l’API](/developers-guides/fr/integration-guides/getting-started-with-the-api.md) pour ces appels de gestion.

### Liste de contrôle de validation

Un flux de création déclenché par le connecteur doit confirmer quatre choses.

* L’événement source attendu se produit.
* La Carte est créée exactement une fois pour cet événement.
* Les bons identifiants externes sont stockés sur la nouvelle Carte.
* Un rendu ultérieur peut récupérer les données source avec succès.

Les webhooks sont souvent utiles ici, car ils facilitent l’observation des événements du cycle de vie de la Carte, comme la création et l’installation de la Carte.

Utilisez [Webhooks](/developers-guides/fr/integration-guides/webhooks.md) lorsqu’une visibilité sur le cycle de vie est nécessaire.

### FAQ

<details>

<summary><strong>La création déclenchée par le connecteur stocke-t-elle les données client dans The Wallet Crew ?</strong></summary>

Non. Elle crée un enregistrement de Carte et stocke les identifiants ainsi que toutes les valeurs au niveau de la Carte qui doivent être conservées. Les données client restent dans les systèmes source.

</details>

<details>

<summary><strong>Un connecteur peut-il à la fois créer une Carte et fournir plus tard des données au moment du rendu ?</strong></summary>

Oui. Ce sont des moments distincts dans le cycle de vie. La création établit la Carte et les identifiants. Les rendus ultérieurs récupèrent à nouveau les données en direct.

</details>

<details>

<summary><strong>Ce modèle est-il meilleur qu’un flux Cinto SDK ?</strong></summary>

Aucun des deux modèles n’est universellement meilleur. Le bon choix dépend de l’endroit où se prend la décision d’émission et du système qui contrôle le parcours utilisateur.

</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 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/developers-guides/fr/integration-guides/wallet/connector-triggered-pass-creation.md?ask=<question>&goal=<endgoal>
```

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