Intégration partenaires

C'est le point le plus incertain du projet, et le seul sur lequel nous ne pouvons pas décider seuls. Cette page expose ce que nous savons, ce que nous ne savons pas encore, et l'architecture qui permet de démarrer sans attendre la réponse.

Un renversement de perspective

Les APIs de Western Union, Ria ou MoneyGram ne sont pas conçues pour les sous-agents. Elles s'adressent aux fintechs et aux banques qui veulent intégrer l'envoi d'argent dans leur propre produit — pas à un guichet qui veut récupérer ses propres opérations.

La chaîne réelle est celle-ci :

Réseau (Western Union, Ria…)
        ↓
Agent principal / banque  ← c'est ici qu'est le contrat réseau
        ↓
Sous-agent  ← c'est ici que vous êtes

Vous n'avez probablement pas de relation contractuelle directe avec le réseau. Vous l'avez avec une banque ou un agent principal qui, lui, détient le contrat.

Les quatre niveaux d'accès

Un module d'opérations unique, piloté par une fiche de configuration par partenaire. Le niveau atteint dépend de ce que le partenaire accorde, et il peut évoluer en cours de vie du produit par configuration.

Les deux derniers niveaux ne dépendent d'aucune autorisation extérieure. Votre agent principal vous transmet déjà un relevé quotidien : c'est la matière de l'import. La version 1 est fonctionnelle avec ces deux seuls niveaux, pour les six partenaires — c'est ce qui permet au projet d'aboutir sans dépendre du calendrier d'un tiers.

Ce qui est configurable, et ce qui ne l'est pas

La formule « ajouter un partenaire, c'est remplir une fiche » est vraie dans un cas sur deux. Voici la distinction exacte.

Le périmètre gelé au cadrage précise, partenaire par partenaire, dans laquelle de ces trois situations chacun se trouve, sur la base des informations alors disponibles.

Lecture ou écriture : la distinction qui change tout

Il ne faut pas demander « une API ». Il faut demander laquelle — parce qu'il en existe deux natures, et qu'elles n'engagent pas du tout la même chose.

Une API de lecture vous rend vos propres opérations. Lire ses propres données n'est pas une activité régulée : aucune exposition, aucune responsabilité nouvelle.

Une API d'écriture crée le transfert. AiO cesse alors d'enregistrer ce qui s'est passé ailleurs : il provoque ce qui se passe. Trois choses basculent.

Le statut réglementaire. En zone CEMAC, la réforme en cours crée explicitement une catégorie d'opérateurs de services de paiement couvrant l'initiation de paiement, soumise à agrément de l'autorité monétaire nationale après avis de la COBAC. Si AiO initie des transactions, la question « qui est l'opérateur agréé » se pose immédiatement. Elle ne se pose pas du tout tant qu'AiO se contente d'enregistrer.

La responsabilité. Aujourd'hui, si le terminal partenaire tombe en panne, c'est le problème du partenaire. Si AiO initie et échoue à mi-parcours, c'est le nôtre — et le vôtre. Des espèces sorties de la caisse sans qu'aucune référence n'ait été émise, c'est de l'argent réel à retrouver.

La difficulté technique change d'ordre de grandeur. Le problème concret :

AiO appelle l'API. Le réseau coupe. L'opération est-elle passée ou non ?

Passée et l'on réessaie → double transfert, argent perdu. Non passée et l'on ne réessaie pas → le client a payé, rien n'est parti.

On ne peut pas deviner. Il faut une clé d'idempotence acceptée par le partenaire, un point d'interrogation de statut, et une boucle de réconciliation qui tranche les cas incertains. C'est la partie la plus difficile de l'ingénierie des paiements — et elle n'existe pas du tout en lecture seule.

Où en est chaque partenaire

L'état des programmes partenaires, au mieux de notre connaissance à ce jour. À confirmer contrat en main.

Ce qu'exige un dossier de partenariat API

Si la voie API est poursuivie, voici ce qui sera demandé — et cela explique pourquoi elle est rarement accessible à un guichet :

• Entité juridique immatriculée, statuts et comptes à l'appui
• Statut réglementaire : établissement de paiement agréé, ou partenariat avec un établissement agréé
• Programme LCB-FT écrit et un responsable conformité nommé
• Dossier de due diligence : bénéficiaires effectifs, gouvernance, assurances
• Engagements de volume — c'est un partenariat commercial, pas un abonnement
• Certification technique : bac à sable → certification → production

Délai réaliste : 3 à 9 mois, dominé par le juridique et la conformité, pas par la technique.

La marche à suivre que nous recommandons

1. Demander les relevés à l'agent principal. Coût nul, délai de quelques jours, résout l'essentiel du besoin.

2. Relire chaque contrat d'agence. Ce qu'il autorise en matière d'export et de traitement par un tiers y est écrit — et c'est aussi là que se trouvent les clauses qui interdisent le scraping.

3. Lancer les démarches API en parallèle, sans en dépendre. Si elles aboutissent, on ajoute un connecteur — court, puisque le module est déjà en place.

C'est précisément pourquoi l'architecture prévoit quatre niveaux. Le projet ne doit jamais attendre une API. Il démarre sur les relevés, et tout accès obtenu ensuite est un gain, pas une condition.

Là où finissent les exceptions

Un relevé importé n'est pas un relevé rapproché. Ce qui ne tombe pas juste atterrit au même endroit : la file d'exceptions. C'est l'écran que personne ne dessine et que tout le monde utilise — celui du chef d'agence à 18 h, quand le comptage ne tombe pas juste.

Sélectionnez une ligne : les trois voies du rapprochement s'affichent, et celle qui diverge est mise en évidence. C'est tout le travail du système — dire non pas « il y a un écart », mais « voici laquelle des trois sources ne dit pas la même chose que les deux autres ».

Ce que nous nous engageons à faire

Sur un sujet dont la moitié échappe à notre contrôle, l'engagement doit être précis. Le voici, tel qu'il figure au dossier.

1. Livrer le module et sa file d'exceptions pour les six partenaires, en import de relevés et saisie assistée.
2. Fournir le dossier de demande d'accès pour chaque opérateur — destinataire, intitulé exact, pièces attendues — afin que votre agence puisse l'engager sans délai.
3. Raccorder une API dont l'accès serait ouvert et documenté avant la fin du mois 6, dès lors que son protocole relève des deux premières situations ci-dessus. Compris dans le prix.
4. Chiffrer séparément les raccordements supplémentaires, ou ceux ouverts après le mois 6. Le module étant déjà en place, ces raccordements sont courts.

En version 1, aucun raccordement temps réel n'est promis : un agent qui démarre n'obtient pas d'accès API la première année, et un accès ouvert en cours de route ne pourrait être développé, homologué par le réseau et recetté dans les six mois. Le raccordement relève donc de la phase 3, déclenchée quand un réseau vous l'ouvre. L'inscrire dans la V1 reviendrait à promettre un calendrier que ni vous ni nous ne contrôlons.