> 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/pass-architecture/infrastructure.md). # Infrastructure ## Infrastructure The Wallet Crew est une plateforme Wallet as a Service (WaaS) native du cloud et mutualisée, hébergée sur Microsoft Azure en Europe. Elle permet la création et les mises à jour de cartes pour Apple Wallet et Google Wallet. Le trafic public est acheminé via Cloudflare pour la protection WAF et la limitation du débit. Cloudflare fournit également la mise en cache CDN et la terminaison TLS.
Exemples concrets * Un partenaire a besoin de l’adresse IP sortante pour autoriser la livraison de webhooks ou le trafic des connecteurs. * Une équipe de sécurité doit confirmer que `qa` et `prod` sont isolés. * Un déploiement multimarque doit comprendre si les locataires partagent des identifiants Wallet ou des magasins de données.
### En bref * **Cloud** : Microsoft Azure (services gérés, réseau privé) * **Périphérie** : Cloudflare (CDN, WAF, protection DDoS, TLS) * **Données** : Cosmos DB, Azure Data Explorer, Blob Storage * **Secrets** : Azure Key Vault * **Asynchrone** : Azure Service Bus * **Temps réel** : Azure Web PubSub (communication en temps réel basée sur WebSocket) * **Modèle de sécurité** : isolation des locataires, cartes signées, signature de webhook facultative ### Pourquoi cette architecture est importante Les choix d’infrastructure affectent directement les revues de sécurité, la configuration des intégrations et le dépannage opérationnel. L’isolation des locataires définit qui peut accéder aux données et aux identifiants. L’isolation des environnements définit comment les tests et la production restent séparés. Les adresses IP sortantes sont importantes lorsque les systèmes partenaires restreignent le trafic entrant. Les services gérés réduisent les frais opérationnels tout en maintenant une plateforme évolutive et résiliente. ### Composants d’infrastructure La plateforme est construite sur des services Azure gérés au sein de réseaux privés. Azure App Service héberge l’API sans état et les interfaces avec une mise à l’échelle horizontale. Azure Service Bus exécute les charges de travail asynchrones et le traitement en arrière-plan. Les données opérationnelles sont stockées dans Cosmos DB avec un partitionnement au niveau du locataire. Les événements et les analyses sont collectés dans Azure Data Explorer. Les fichiers de configuration et de traitement par lots sont stockés dans Azure Blob Storage. Les secrets et les certificats sont stockés dans Azure Key Vault. L’isolation des locataires est appliquée à chaque couche. Chaque locataire utilise ses propres comptes Apple et Google Wallet. Les cartes sont signées à l’aide de certificats et de clés appartenant au locataire. Les mises à jour Apple utilisent APNs, et les mises à jour Google utilisent les API Google Wallet.
High-level architecture diagram showing the edge, application, data, and integration layers of The Wallet Crew

Architecture de haut niveau de la plateforme couvrant les couches périphérique, applicative, de données et d’intégration.

L’architecture est modulaire et à activation facultative. Les capacités sont activées par locataire selon les besoins réels. Les intégrations sont disponibles via des connecteurs, des API et des webhooks. Une logique métier personnalisée peut être implémentée avec un environnement isolé `nil.js` d’exécution. Cela préserve les limites de sécurité et la stabilité de la plateforme. Les données personnelles ne sont pas stockées à long terme, sauf si vous le configurez explicitement. ### Principes d’architecture La plateforme suit une conception modulaire à activation facultative. Tous les services, intégrations et composants en arrière-plan sont désactivés par défaut et activés uniquement lorsqu’un locataire les requiert. Cela limite la complexité, le coût et la surface d’attaque à ce que chaque client utilise réellement. La sécurité est fondamentale et repose sur un modèle Zero Trust, un accès au moindre privilège et un réseau privé pour tous les services internes. Ces contrôles s’appliquent de manière cohérente à tous les composants activés. L’isolation des locataires est appliquée à chaque couche — API, magasins de données, caches et infrastructure de messagerie — garantissant une séparation stricte entre les clients. La couche de calcul est sans état, ce qui permet une mise à l’échelle horizontale et une résilience accrue. Le traitement asynchrone découple les charges de travail et améliore la fiabilité des opérations en arrière-plan et des intégrations. L’observabilité est intégrée, avec des événements, journaux et métriques disponibles à la fois pour la surveillance interne et les rapports au niveau du locataire. ### Locataires Un locataire constitue la principale limite d’isolation dans The Wallet Crew. Toutes les données et opérations de la plateforme sont délimitées par locataire. * **Données** : les cartes, identifiants, métadonnées, événements et analyses sont stockés dans des magasins de données partitionnés par locataire. Aucun accès aux données entre locataires n’est possible à l’exécution. * **Configuration** : les modèles de cartes, paramètres de connecteur et règles opérationnelles de chaque locataire sont stockés sous forme de fichiers de configuration YAML versionnés. Les modifications apportées à la configuration d’un locataire n’ont aucun effet sur les autres locataires. * **Identifiants** : chaque locataire nécessite son propre compte Apple Developer et son propre certificat Apple Carte Signing Certificate, ainsi que son propre compte émetteur Google Wallet. Les identifiants Wallet ne sont pas partagés entre les locataires. * **Utilisateurs et autorisations** : les rôles et autorisations du back-office sont évalués par locataire. Un utilisateur peut être affecté à plusieurs locataires ; chaque affectation à un locataire est indépendante. * **Appels API** : chaque requête API est validée par rapport au contexte du locataire. Une clé limitée à un locataire ne peut pas accéder aux données d’un autre locataire. La plupart des clients exploitent un seul locataire. Les clients entreprise peuvent exploiter plusieurs locataires, souvent un par marque, région ou programme nécessitant une isolation stricte. Un locataire n’est pas un dossier ou un sous-compte dans un espace de travail partagé. Il s’agit d’un environnement d’exploitation entièrement isolé. {% hint style="info" %} Un utilisateur authentifié sur la plateforme mais non affecté à un locataire ne peut accéder à aucune donnée. L’authentification et l’accès au locataire sont des vérifications distinctes. {% endhint %} ### Environnements The Wallet Crew fonctionne comme une plateforme mutualisée unique répartie sur trois environnements. | Environnement | Objectif | Accès | | ------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------ | | `prod` | Opérations client en production | Clients, partenaires, utilisateurs finaux | | `qa` | Préproduction — reproduit la topologie et la posture de sécurité de la production | Équipes internes et clients de préproduction | | `dev` | Développement et tests internes | Équipes d’ingénierie uniquement — non accessible aux clients | Tous les locataires clients sont provisionnés dans les deux `qa` et `prod`. `dev` n’est pas disponible pour les clients. #### Isolation entre les environnements Les environnements sont entièrement isolés. Ils utilisent des VNets distincts, des magasins de données distincts, des secrets distincts dans Azure Key Vault, des clés API distinctes et des enregistrements de cartes distincts. Les données de production ne sont jamais injectées dans `dev`. #### Portabilité de la configuration Les fichiers de configuration des locataires ne contiennent aucun secret et peuvent être copiés entre les environnements. Les secrets, les données de cartes en production et l’état Wallet installé ne sont pas portables. #### Certificats Wallet Les identifiants Wallet sont stockés par locataire et par environnement. Dans certaines configurations, un client peut choisir d’utiliser le même certificat Apple Wallet dans les deux `qa` et `prod`. Il s’agit d’un choix contrôlé du client, et non d’une fusion de données entre environnements. ### Composants de l’application La plateforme est composée de plusieurs couches qui fonctionnent ensemble à l’exécution. #### Configuration La configuration des locataires, y compris les paramètres des connecteurs et les modèles de cartes, est stockée sous forme de fichiers YAML versionnés dans Azure Blob Storage. Les fichiers sont validés à l’aide de JSON Schema et de tests logiques lors de l’enregistrement. Un cache distribué conserve la configuration active par locataire et est invalidé chaque fois qu’un horodatage de configuration change dans Blob Storage, garantissant un comportement cohérent à l’exécution sur toutes les instances en cours d’exécution. #### API L’API est développée avec .NET 10 et suit une conception REST optimisée pour une évolution additive, tout en maintenant la rétrocompatibilité entre les versions. L’authentification varie selon le point de terminaison : OAuth2 (JWT) pour les flux authentifiés, clés API pour les intégrations partenaires et points de terminaison publics lorsque cela est approprié. Polly est utilisé pour les nouvelles tentatives, les disjoncteurs et la limitation. Des limites de débit sont appliquées par locataire. #### Interfaces utilisateur L’interface publique et le back-office sont développés avec React 19, en utilisant Material-UI, react-hook-form, react-router et i18next. Les ressources statiques sont servies via App Service et mises en cache via le CDN Cloudflare. L’image de marque et la mise en page spécifiques au locataire sont récupérées via l’API à l’exécution. #### Traitement en arrière-plan Les charges de travail asynchrones suivent des modèles CQRS. Les messages opérationnels sont mis en file d’attente ou publiés dans des rubriques Azure Service Bus et consommés par Azure Functions. Les politiques de nouvelle tentative et les files d’attente de lettres mortes garantissent la fiabilité. Les files d’attente et rubriques limitées au locataire assurent l’isolation du traitement. #### Communication en temps réel Azure Web PubSub fournit une communication en temps réel basée sur WebSocket pour les fonctionnalités nécessitant des mises à jour par envoi aux clients connectés. ### Résilience opérationnelle et mise à l’échelle #### Mise à l’échelle La plateforme est hébergée sur Azure App Service avec une mise à l’échelle horizontale activée. Chaque environnement exécute au minimum deux instances actives pour une haute disponibilité. La mise à l’échelle automatique peut étendre la capacité à huit instances selon une charge CPU soutenue. Dans des conditions normales, l’utilisation moyenne du CPU reste inférieure à 20 %, avec des pics autour de 75 %. #### Cycle de développement et de publication Le cycle de développement et de publication passe par Azure DevOps. Les pipelines d’intégration continue exécutent automatiquement les tests unitaires, les contrôles de qualité du code et l’analyse de composition logicielle à chaque compilation. Les déploiements en production utilisent des emplacements de déploiement App Service, permettant de valider les nouvelles versions avant leur mise en ligne. Les contrôles d’intégrité sont surveillés en continu pendant le déploiement, et un retour arrière automatique est déclenché si des anomalies sont détectées. Toutes les étapes de compilation et de déploiement s’exécutent sans secrets à l’aide d’Azure Managed Identity. #### Reprise après sinistre La reprise après sinistre repose sur des capacités gérées par Azure. Cosmos DB et Azure Blob Storage incluent des fonctions intégrées de sauvegarde et de récupération. La plateforme vise une disponibilité globale de 99,5 %. L’état actuel et historique du service est publiquement disponible à l’adresse . ### Adresses IP sortantes Lorsque The Wallet Crew effectue des requêtes API sortantes (trafic de sortie) vers vos systèmes ou des fournisseurs tiers, ces requêtes proviennent d’adresses IP publiques fixes. Il s’agit des adresses IP sources utilisées par les requêtes quittant The Wallet Crew. Vous les verrez comme adresse IP client/source dans vos journaux de passerelle, WAF ou d’application. Ces adresses IP s’appliquent aux appels initiés par The Wallet Crew, tels que les requêtes de connecteurs, la livraison de webhooks et tous les rappels de serveur à serveur que vous configurez. Vous n’avez besoin de ces adresses IP que lorsque vous restreignez l’accès entrant à vos propres points de terminaison. Cela est courant pour les pare-feux d’entreprise, les passerelles API et les API de partenaires privées. {% hint style="info" %} Si vous appelez les API The Wallet Crew depuis vos systèmes, vous n’avez généralement pas besoin d’ajouter des adresses à une liste d’autorisation. Votre trafic sortant provient de votre propre réseau. {% endhint %} Ajoutez à la liste d’autorisation l’adresse IP de l’environnement que vous utilisez. Si vous utilisez plusieurs environnements, ajoutez chaque adresse IP concernée à la liste d’autorisation. * **Production (`prod`)**: `20.111.54.22` * **Assurance qualité (`qa`)**: `51.11.248.115` * **Développement (`dev`)**: `40.66.49.162` #### Webhooks : ne vous fiez pas uniquement aux adresses IP L’autorisation par adresse IP réduit le bruit et bloque le trafic non sollicité évident. Elle ne prouve pas que la requête est authentique. Vous devez toujours vérifier l’authenticité des webhooks au niveau de la couche applicative. The Wallet Crew peut signer les requêtes de webhook à l’aide de `x-neostore-signature` (HMAC SHA-256). Cela vous permet de vérifier que la charge utile a été envoyée par nous et n’a pas été modifiée. Voir [Webhooks](/developers-guides/fr/integration-guides/webhooks.md) pour la configuration et la vérification des signatures. ### Gestion des données The Wallet Crew stocke les données de configuration et les données opérationnelles de cartes nécessaires au fonctionnement du service. Votre source de vérité métier reste généralement dans vos systèmes et est accessible via des intégrations. Cela inclut les plateformes de CRM, de billetterie, de fidélité et d’automatisation du marketing. Les données personnelles ne sont pas stockées par défaut. Lorsqu’un stockage de données personnelles est requis, il dépend de votre configuration et de votre cas d’utilisation. Lorsque des données personnelles sont requises — par exemple, lorsqu’une adresse e-mail est utilisée comme identifiant de carte — elles peuvent être conservées temporairement dans un cache distribué pendant une durée configurable, inférieure à 10 minutes par défaut, après laquelle elles sont automatiquement supprimées. Aucune donnée personnelle n’est conservée dans les journaux, les systèmes d’analyse ou le stockage à long terme, sauf configuration explicite par le locataire. ### FAQ
The Wallet Crew utilise-t-il une seule adresse IP pour tout ? Non. Cela varie selon l’environnement. Certaines intégrations peuvent également disposer de points de terminaison dédiés selon la façon dont elles sont déployées et activées.
Je vois une autre adresse IP source. Que dois-je faire ? Commencez par vérifier que vous atteignez le bon environnement. Vérifiez également que vos journaux affichent l’adresse IP réelle du client. Certaines configurations consignent à la place les adresses IP de proxys intermédiaires. Si elle diffère toujours, contactez l’assistance avec le point de terminaison et un horodatage.
The Wallet Crew peut-il se connecter à nos systèmes via un VPN ? Oui, cela peut être configuré à la demande pour des contraintes réseau strictes. Il s’agit généralement d’une configuration dédiée avec une charge opérationnelle supplémentaire. Cela peut également entraîner des coûts supplémentaires d’infrastructure et d’assistance. La plupart des clients préfèrent plutôt l’autorisation par adresse IP et la signature des requêtes.
Existe-t-il un Security Insurance Plan (SIP) ? Oui. Le SIP résume notre gouvernance de sécurité, nos contrôles et nos responsabilités pour l’exploitation de The Wallet Crew. C’est le meilleur point de départ pour les revues de sécurité des fournisseurs et l’évaluation interne des risques. Le Security Insurance Plan est disponible sur demande.
Existe-t-il une référence d’architecture plus détaillée ? Une référence complète sur l’architecture technique et la sécurité est disponible pour les équipes informatiques des clients et les partenaires techniques. Contactez l’assistance ou votre équipe de compte pour la demander.
--- # 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/pass-architecture/infrastructure.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.