API REST et intégrations : vos logiciels, vos paiements et vos messageries reliés par un code documenté, sécurisé et fiable

Que recouvre une API REST sur mesure, et qu'est-ce qui n'en relève pas ?

Une API, ou interface de programmation, est la porte par laquelle un logiciel demande ou envoie des données à un autre, sans écran ni personne au milieu. Le style REST organise cette porte autour de ressources (un client, une commande, une facture) désignées par des adresses et manipulées avec les méthodes du protocole HTTP. La RFC 9110 de l'IETF, publiée en juin 2022, fixe le sens de ces méthodes et des codes de statut. S'y conformer permet à n'importe quelle bibliothèque HTTP, en PHP, en JavaScript ou en Python, d'utiliser votre API sans code particulier.

Le service a deux faces. La première consiste à construire une API : vous détenez des données, un catalogue, un stock, des dossiers clients, qu'une application mobile, un partenaire ou un revendeur doit pouvoir lire ou modifier. La seconde consiste à intégrer : vos outils existent déjà, chacun avec sa propre API, et il faut écrire le code qui les relie, traduit les formats, absorbe les pannes et garde la trace de chaque échange. Les deux obéissent aux mêmes règles de conception, de sécurité et de fiabilité, détaillées plus bas.

Certains besoins voisins relèvent d'autres pages. Un enchaînement de tâches entre outils standard, sans règle métier lourde ni gros volume, se monte souvent plus vite avec n8n ou Make : c'est le terrain de l'automatisation, et le comparatif n8n, Make et Zapier aide à choisir l'outil. Un logiciel métier complet, avec ses écrans et ses utilisateurs, relève d'une application web sur mesure, dont l'API n'est qu'une partie. L'ouverture d'un numéro sur la plateforme de Meta et la validation des modèles de messages relèvent de l'intégration WhatsApp.

La frontière se fixe au cadrage, avec une question simple : faut-il un code qui vous appartient, versionné, testé et documenté, ou un scénario visuel suffit-il ? Le code s'impose dès que l'échange touche de l'argent, des données personnelles en nombre, une règle de calcul propre à votre métier, ou un débit que les plateformes sans code facturent cher. Dans les autres cas, il est plus honnête de proposer la solution la plus légère, quitte à la remplacer par du code le jour où le volume la dépasse.

Pourquoi décrire l'API en OpenAPI avant d'écrire le code ?

La spécification OpenAPI, dont la version 3.2.1 a été publiée le 10 septembre 2026 selon l'OpenAPI Initiative, définit une description standard des API HTTP, indépendante du langage de programmation, rédigée en JSON ou en YAML. Elle décrit chaque chemin, chaque paramètre, chaque schéma de données et chaque mécanisme de sécurité : clé d'API, authentification HTTP par jeton, OAuth 2.0, OpenID Connect ou TLS mutuel. Ses schémas reposent sur JSON Schema, version 2020-12, ce qui permet de valider automatiquement une requête ou une réponse.

Écrire cette description d'abord change la conversation. Vous, votre développeur mobile et votre partenaire lisez le même contrat avant qu'une ligne de code n'existe : noms des champs, format des dates, montants en francs CFA sans décimales, cas d'erreur. Les désaccords se règlent sur un document de quelques pages plutôt que sur une application déjà livrée. Le fichier produit ensuite une page de test interactive, un serveur simulé qui permet à l'équipe mobile d'avancer en parallèle, et des tests qui vérifient que le code respecte toujours le contrat.

Le contrat protège aussi la suite. Quand une nouvelle version se prépare, la comparaison automatique de deux descriptions signale les ruptures : champ supprimé, type modifié, paramètre devenu obligatoire. Le jour où un autre prestataire reprend le projet, il trouve la liste exacte de ce qui est exposé, ce que l'OWASP range sous la gestion de l'inventaire des API. Une API non documentée n'est donc pas seulement pénible à utiliser : c'est une API dont plus personne ne sait quelles routes restent ouvertes, ni pour qui.

Comment un échange reste-t-il fiable quand le réseau ou un service tiers tombe ?

Un échange entre deux logiciels échoue tôt ou tard : coupure de connexion, serveur du partenaire saturé, délai dépassé. La question n'est pas de l'éviter mais de savoir ce qui se passe ensuite. La RFC 9110 pose la base : une méthode est idempotente quand plusieurs requêtes identiques laissent le serveur dans le même état qu'une seule. Un GET, un PUT ou un DELETE peuvent donc être rejoués sans danger. Un POST qui crée une commande ou déclenche un paiement, non : le rejouer à l'aveugle peut créer deux commandes, ou débiter deux fois.

La parade s'appelle la clé d'idempotence. Selon la documentation de Stripe consultée le 4 octobre 2026, le client joint à sa requête un en-tête Idempotency-Key, chaîne aléatoire de 255 caractères au plus ; Stripe conserve le code et la réponse de la première requête, renvoie le même résultat aux suivantes, refuse une clé réutilisée avec d'autres paramètres, et peut effacer les clés après au moins 24 heures. Les API livrées appliquent ce principe sur leurs routes de création, et les intégrations l'utilisent chez chaque partenaire qui le propose.

Les reprises suivent des règles. On ne relance que ce qui peut l'être : erreur réseau, délai dépassé, code 429 ou 503. Un code 400 ou 422 signale une requête fausse, qu'aucune répétition ne corrigera. Les tentatives s'espacent de plus en plus, avec une part de hasard pour éviter que mille clients reviennent à la même seconde, et respectent l'en-tête Retry-After quand le serveur l'envoie, ce que la RFC 6585 d'avril 2012 prévoit avec le code 429. Au-delà d'un nombre fixé, l'échange rejoint une file des échecs, visible et rejouable.

Les files d'attente font le reste. Plutôt que d'appeler le logiciel comptable pendant que le client attend sa confirmation, l'application enregistre une tâche et répond tout de suite ; un processus séparé traite les tâches une à une, et les garde tant que le service distant reste indisponible. Avec Laravel, ce sont les files de tâches adossées à la base de données ou à Redis ; avec Node.js, des bibliothèques équivalentes. Pour une boutique de Cotonou dont la connexion tombe en pleine journée, c'est la différence entre une commande retardée de dix minutes et une commande perdue.

Paiement, WhatsApp, Odoo, Dolibarr : que faut-il savoir avant de brancher chaque outil ?

Côté paiement, les trois agrégateurs ouest-africains se ressemblent dans le principe : une page ou un widget de paiement, une validation par le client sur son téléphone, puis une notification à votre serveur. Selon la documentation des webhooks de FedaPay, consultée le 4 octobre 2026, une notification sans réponse est retentée jusqu'à 9 fois à intervalles exponentiels, et le webhook est désactivé après 10 échecs. La documentation de KkiaPay annonce 5 tentatives à intervalle croissant. Frais, pays et délais de versement sont comparés dans le comparatif FedaPay, KkiaPay et CinetPay.

FedaPay sépare aussi ses environnements : selon sa page d'authentification, les objets créés en mode test sont totalement distincts de ceux du mode live, et la clé secrète, qui donne accès à toutes les fonctions de l'API, ne doit jamais figurer dans un système de gestion de versions. Concrètement, la clé vit dans une variable d'environnement du serveur, chaque environnement a la sienne, et une clé exposée par erreur se régénère immédiatement. Stripe, utile pour les clients européens ou canadiens qui paient par carte, suit la même logique de clés séparées.

Pour WhatsApp, la vue d'ensemble de l'API Cloud de Meta, consultée le 4 octobre 2026, fixe le débit par défaut à 80 messages par seconde par numéro, et limite les envois répétés vers un même destinataire. Le code d'intégration doit donc réguler ses envois au lieu de tout lancer d'un coup après une campagne. Côté réception, la documentation des webhooks de Meta exige un HTTPS avec un certificat valide, refuse les certificats autosignés, et supprime les notifications non acquittées au bout de 36 heures.

Pour les ERP, deux points comptent. La documentation de l'API externe d'Odoo 20.0 indique qu'une clé d'API ne peut pas durer plus de trois mois : une intégration qui tourne seule doit donc prévoir la rotation de sa clé, sinon elle s'arrête au bout d'un trimestre. Elle annonce aussi le retrait des services XML-RPC et JSON-RPC avec Odoo 22, à l'automne 2028. Le wiki de Dolibarr décrit un module API REST authentifié par l'en-tête DOLAPIKEY, avec un explorateur Swagger intégré ; le paramétrage de chaque ERP relève de l'intégration Odoo ou de l'intégration Dolibarr.

Mobile money, connexion, données personnelles et langue : que change le contexte local ?

Le mobile money impose un temps d'attente que la carte ne connaît pas : le client valide le paiement sur son téléphone, parfois une ou deux minutes plus tard, parfois jamais. L'API doit donc gérer un état « en attente » durable, expirer proprement les paiements abandonnés et ne jamais bloquer la page du client pendant ce temps. Les montants en francs CFA se transmettent en entiers, sans décimales, et chaque paiement garde la référence de la commande, le numéro de l'opérateur et l'identifiant de l'agrégateur, pour que la comptabilité retrouve chaque encaissement.

La connexion ensuite. Une application de terrain au Bénin, au Togo ou au Burkina Faso doit supposer que le réseau tombera au mauvais moment. D'où des réponses légères et paginées, une compression des échanges, un enregistrement local des opérations sur le téléphone et un envoi différé avec clé d'idempotence, pour qu'une commande saisie hors réseau ne soit ni perdue ni doublée. Côté serveur, les webhooks exigent un HTTPS avec certificat valide : un serveur au bureau, derrière une connexion grand public sans adresse fixe, convient mal pour les recevoir.

Les données personnelles enfin. L'article 426 de la loi n° 2017-20 du 20 avril 2018 portant code du numérique oblige le responsable du traitement et son sous-traitant à protéger les données, notamment lorsque le traitement comporte des transmissions dans un réseau, et cite le chiffrement, la pseudonymisation et des tests réguliers des mesures. L'article 391 subordonne tout transfert vers un État tiers à un niveau de protection équivalent constaté par l'Autorité. Une intégration qui envoie des fichiers clients vers un service hébergé hors du Bénin doit donc être examinée sous cet angle avant d'être branchée.

En Europe, le RGPD, présenté par la CNIL, impose un contrat de sous-traitance à l'article 28, des mesures de sécurité adaptées à l'article 32, dont le chiffrement, et à l'article 33 la notification d'une violation à l'autorité si possible dans les 72 heures. Une API qui journalise sans filtre, ou qui renvoie plus de champs que nécessaire, complique chacune de ces obligations. Pour la langue, les messages d'erreur destinés aux utilisateurs se rédigent en français, tandis que les noms de champs suivent une convention unique, souvent en anglais, fixée dès le contrat.

Pourquoi confier votre API ou vos intégrations à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Il compte plus de 6 ans d'expérience dans le numérique, une formation à EPITECH (2022) et plus de 50 projets livrés, pour des organisations au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada. Il développe ses propres produits : Wapy, un assistant WhatsApp à intelligence artificielle pour les entreprises d'Afrique francophone, et il est co-fondateur d'Audyxa. Relier une messagerie, un paiement et un logiciel de gestion fait donc partie de son quotidien de développeur.

Son travail sur les API se vérifie en public. Son compte GitHub contient le dépôt bj-decoupage, une API REST du découpage administratif du Bénin construite avec Laravel et publiée en mars 2024. Ses routes, toutes en lecture, suivent la hiérarchie réelle du pays : la liste des départements, les communes d'un département, les arrondissements d'une commune, puis les quartiers. N'importe quel développeur peut lire ce code avant de vous le confier, ce qui vaut mieux qu'une promesse ; son parcours complet figure sur la page Richard SALANON.

Sa méthode tient en engagements vérifiables : un contrat d'interface validé avant le code, des lots livrés avec leurs tests, des tests de panne avant la mise en production, des comptes, des clés et un dépôt Git à votre nom, une documentation remise à chaque lot, et une réponse sous 24 heures. Il a formé plus de 200 personnes au numérique ; si votre équipe veut reprendre la main sur le code, la formation au développement web couvre la consommation et la création d'API.