Formation Intégrations API en no-code et low-code : lire une documentation, s'authentifier, envoyer des requêtes et recevoir des webhooks dans n8n, Make ou Zapier, sans écrire de code

Que saurez-vous faire à la fin de la formation, et qu'est-ce qu'elle ne couvre pas ?

À la fin des deux jours, chaque participant sait mener seul une intégration simple de bout en bout. Ouvrir la documentation d'un service inconnu et y trouver en dix minutes l'adresse à appeler, la méthode, les champs obligatoires et le mode d'authentification. Créer les identifiants au bon endroit dans n8n, Make ou Zapier, sans recopier la clé dans un champ de texte. Envoyer une requête en mode test, lire la réponse et s'en servir dans la suite du flux. Recevoir un webhook, vérifier qu'il vient du service attendu et répondre comme celui-ci l'exige. Enfin, reconnaître une limite de débit ou une erreur, puis décider s'il faut réessayer, corriger ou alerter.

Ces objectifs se vérifient sur pièce. L'évaluation finale remet à chacun la documentation d'une API qu'il n'a jamais ouverte et une tâche précise : lire un enregistrement, en créer un autre, réagir à une notification. Le participant travaille sans aide, en mode test, pendant que le formateur observe la méthode plus que le résultat. Celui qui sait où chercher dans la documentation et comment interpréter un code d'erreur a atteint l'objectif, même si son flux demande encore une retouche.

Plusieurs sujets voisins restent hors programme. Les bases de n8n et de Make sont supposées acquises : la formation n8n de zéro à l'autonomie et la fiche Make de zéro à expert les couvrent. Concevoir et publier sa propre API relève de la fiche API REST, écrite pour les développeurs. Les modèles de messages, les coûts et le robot de la plateforme WhatsApp ont leur fiche Chatbot WhatsApp et API WhatsApp Business ; ici, WhatsApp sert seulement à apprendre à lire une documentation versionnée et ses codes d'erreur. L'appel aux modèles d'IA depuis un logiciel se traite dans intégrer l'IA dans ses logiciels existants.

La formation ne remplace pas non plus un projet de développement. Quand une intégration touche des paiements en volume, des écritures comptables ou des données sensibles, un code écrit, testé et documenté par un professionnel reste préférable : c'est l'objet du service API REST et intégrations. La formation donne alors à l'équipe de quoi comprendre ce qui a été livré, poser les bonnes questions au prestataire et assurer les retouches courantes. Les autres formations du domaine automatisation sont proposées en bas de page.

Connecteur prêt à l'emploi ou requête HTTP : quand faut-il lire la documentation soi-même ?

Un connecteur, qu'on l'appelle nœud, module ou application, est une requête d'API déjà écrite par l'éditeur de l'outil d'automatisation. Il choisit à votre place l'adresse, la méthode et les champs, et il ne propose que les actions que cet éditeur a jugées utiles. Tant que votre besoin entre dans ce menu, il faut s'en servir : c'est plus rapide et mieux entretenu. La documentation de l'API n'entre en jeu que dans trois situations, et la formation apprend d'abord à les reconnaître.

Première situation : le service n'a pas de connecteur du tout, ce qui arrive souvent avec les outils locaux ; lors de la préparation de cette page, FedaPay n'avait de page d'intégration ni dans le catalogue de n8n ni dans celui de Zapier. Deuxième situation : le connecteur existe mais ne fait pas ce qu'il faut, par exemple lire un champ personnalisé ou appeler une méthode métier. Troisième situation : le connecteur casse après une évolution de l'API, et il faut comprendre pourquoi. Dans les trois cas, le module HTTP générique de l'outil prend le relais, et c'est la documentation qui dit comment le remplir.

Les trois outils l'ont prévu. Make présente son application HTTP comme le moyen de joindre les services qui n'ont pas d'intégration ; sa version 4, selon le centre d'aide consulté le 5 octobre 2026, range les identifiants dans un trousseau et gère la pagination. n8n propose le nœud HTTP Request, qui importe une commande cURL copiée depuis une documentation. Zapier présente API by Zapier, encore en bêta, pour appeler avec une clé ou OAuth2 les API dépourvues d'intégration. Le geste est le même partout : traduire une page de documentation en réglages.

Comment se lit une requête d'API, morceau par morceau ?

Une requête ressemble à une lettre recommandée. L'adresse dit à qui elle va : une adresse de base, puis un chemin qui désigne la ressource, comme /v1/transactions chez FedaPay. La méthode dit ce que l'on veut faire : GET pour lire, POST pour créer, PUT pour modifier, DELETE pour supprimer, selon la liste que la page « Envoi de requêtes » de FedaPay donne elle-même. Les en-têtes forment l'enveloppe : qui écrit, avec quelle clé, dans quel format. Le corps, enfin, contient la lettre, presque toujours en JSON, avec des accolades, des noms de champs entre guillemets et leurs valeurs.

La réponse suit le même schéma. Un code de statut à trois chiffres résume l'issue, puis un corps JSON donne le détail. L'exemple que Meta publie pour envoyer un texte par WhatsApp renvoie l'identifiant du message créé et le numéro du destinataire tel que WhatsApp l'a compris. Un participant qui sait retrouver ces deux informations sait déjà prouver qu'un envoi est parti, et retrouver plus tard le message en cause quand un client affirme n'avoir rien reçu.

Les documentations se contredisent parfois, et la formation le montre exprès. Chez FedaPay, la page générale sur l'envoi de requêtes indique qu'une réponse réussie porte « généralement » le code 200, alors que la référence de la création d'une transaction annonce 201. Les deux codes signalent un succès, mais un flux réglé pour n'accepter que 200 échouerait. La règle enseignée : la référence d'un point d'accès l'emporte sur la page générale, et un essai en mode test tranche toujours.

Dernier réflexe : regarder la version. L'exemple d'envoi de texte de Meta appelle graph.facebook.com/v25.0, alors que le journal des versions de la Graph API donne la 26.0, sortie le 29 juillet 2026, comme la plus récente. Meta garde chaque version au moins deux ans, puis redirige les appels vers la plus ancienne version encore servie. Noter la version utilisée et sa date de fin dans la fiche de l'intégration évite de découvrir un changement de comportement par la plainte d'un client.

Clé d'API ou OAuth 2.0 : comment s'authentifier sans fragiliser l'entreprise ?

La clé d'API est la forme la plus courante : une longue chaîne que l'on place dans un en-tête de la requête. Elle se traite comme la clé d'un coffre. FedaPay distingue une clé publique, prévue pour les pages web et les applications mobiles, et une clé secrète qui « donne accès à toutes les fonctionnalités de l'API » ; sa page d'authentification demande de ne jamais la partager, de ne jamais la placer dans un système de gestion de versions et de la régénérer aussitôt en cas de doute. Dans un flux, seule la clé secrète de test entre en jeu pendant la formation.

Odoo ajoute deux règles utiles. Sa documentation de l'API externe, dans la version 20.0, interdit les clés de plus de trois mois et conseille une journée pour un usage interactif ; une intégration qui tourne seule doit donc changer de clé au moins chaque trimestre, sous peine de s'arrêter un matin sans prévenir. La clé ne s'affiche qu'une fois, au moment de sa création. Odoo recommande enfin un utilisateur technique dédié, aux droits réduits au strict nécessaire, plutôt que le compte d'une personne. La fiche de l'intégration note donc la date d'échéance de chaque clé et le nom de la personne qui la renouvelle.

OAuth 2.0 répond à une autre question : laisser un outil agir sur un compte sans lui confier le mot de passe. La RFC 6749, publiée en octobre 2012, décrit le principe : un jeton d'accès de courte durée, obtenu après l'accord du titulaire du compte, et un jeton de rafraîchissement qui permet d'en obtenir de nouveaux. Pour le participant, cela se résume à un écran de consentement, à une liste de périmètres demandés et à un jeton que l'outil d'automatisation renouvelle tout seul, tant que rien ne le casse.

Google montre ce qui peut le casser. Selon sa documentation OAuth 2.0, un projet dont l'écran de consentement est configuré pour des utilisateurs externes et resté au statut « Testing » reçoit des jetons de rafraîchissement valables 7 jours : le flux qui marchait en formation tombe en panne la semaine suivante. Un jeton inutilisé pendant six mois expire aussi, et Google limite à 100 le nombre de jetons de rafraîchissement par compte et par identifiant client, le plus ancien étant invalidé sans avertissement. Côté périmètres, la documentation de Google Sheets conseille le plus étroit possible : drive.file, non sensible, plutôt que spreadsheets, qui ouvre tous les tableurs du compte.

Que faire quand une API répond « trop de requêtes » ?

Toute API publique rationne ses appels. La RFC 6585, publiée en avril 2012, définit le code 429 : l'utilisateur a envoyé trop de requêtes dans un délai donné, et la réponse peut contenir un en-tête Retry-After qui indique combien de temps attendre. Les limites varient beaucoup d'un service à l'autre, et la rubrique qui les annonce est celle que les débutants lisent en dernier. Un flux qui fonctionne sur dix lignes de test peut s'effondrer le jour où il traite le fichier de fin de mois.

Google Sheets en donne un exemple chiffré. Sa page des limites, consultée le 5 octobre 2026, accorde 300 requêtes de lecture et 300 d'écriture par minute et par projet, mais seulement 60 par minute et par utilisateur ; au-delà, le service répond 429. Il n'y a pas de plafond quotidien tant que l'on respecte ces quotas par minute. Google recommande d'attendre de plus en plus longtemps entre deux essais, en doublant l'attente à chaque fois et en ajoutant une part de hasard, avec un plafond de 32 à 64 secondes. Il conseille aussi des envois de 2 Mo au plus et coupe toute requête qui dépasse 180 secondes.

Dans les outils, cela se traduit par trois réglages. Regrouper : une seule requête qui ajoute cinquante lignes vaut mieux que cinquante requêtes d'une ligne. Espacer : n8n propose dans le nœud HTTP Request un nombre d'éléments par lot et un intervalle entre deux lots, en millisecondes. Réessayer avec mesure : une erreur 429 ou 503 se relance après une attente, une erreur 400 ou 422 jamais, puisque la même requête produira la même erreur. La formation fait écrire ces trois choix dans la fiche de chaque intégration.

Certaines limites ne visent pas le volume total mais un destinataire précis. La liste des codes d'erreur de la plateforme WhatsApp distingue le code 130429, débit global du numéro atteint, et le code 131056, trop de messages envoyés au même destinataire depuis le même numéro. Le second se règle en espaçant les messages vers une même personne ou en les regroupant, pas en ralentissant tout le flux. Savoir lire le code exact évite de corriger le mauvais problème.

Comment recevoir un webhook proprement, sans perdre ni doubler d'événement ?

Un webhook inverse le sens de l'échange : au lieu d'interroger le service toutes les cinq minutes, on lui donne une adresse, et c'est lui qui prévient quand quelque chose se passe. La documentation de FedaPay décrit la mécanique : une requête POST contenant l'événement, par exemple transaction.approved ou transaction.declined, et une réponse attendue dans la famille 2xx ; toute autre réponse compte comme un échec. Il est possible, dans le tableau de bord, de ne recevoir que les événements choisis, ce que FedaPay recommande pour ne pas encombrer le flux.

Les outils d'automatisation ajoutent leur propre logique. Dans n8n, le nœud Webhook a deux adresses : l'adresse de test, active quand on écoute un événement depuis l'éditeur, et l'adresse de production, enregistrée à la publication du flux ; un service resté branché sur l'adresse de test ne déclenchera plus rien une fois l'éditeur fermé. Make répond « Accepted » avec un code 200 dès que la requête entre dans la file, et désactive au bout de 5 jours, soit 120 heures, un webhook relié à aucun scénario. Zapier répond 200 par défaut et peut renvoyer une réponse vide si l'on ajoute silent/ à l'adresse.

Deux incidents reviennent toujours. Le premier est l'échec répété : FedaPay réessaie au plus 9 fois à intervalles croissants, sans dépasser 2 minutes d'attente, puis désactive le webhook après 10 essais infructueux, sauf si l'option correspondante a été décochée. Une adresse en panne pendant un après-midi peut donc couper toutes les notifications suivantes. Le second est le doublon : FedaPay prévient que le même événement peut arriver plusieurs fois et conseille d'enregistrer les identifiants déjà traités. Le flux d'exercice tient ce registre dans un tableur, ce qui suffit à un volume modeste.

Un fonds de formation continue peut-il financer cette session ?

Peut-être, selon le pays et le dossier, et cette page ne garantit aucune prise en charge. En Côte d'Ivoire, le FDFP accepte le plan de formation de toute entreprise qui justifie du paiement régulier de ses deux taxes ; une session animée chez elle par un intervenant extérieur entre dans la catégorie intra. Le fonds ne paie qu'une fois le suivi et le contrôle de ses services effectués, puis la décision de sa Commission permanente rendue : la trésorerie doit donc pouvoir avancer la dépense.

Au Bénin, le FODEFCA, fonds de développement de la formation professionnelle continue et de l'apprentissage, fonctionne selon les statuts approuvés par le décret n° 2022-286 du 11 mai 2022. Au Sénégal, le 3FPT ouvre un guichet consacré au financement du personnel des entreprises et des membres des organisations professionnelles. En France, France Compétences rappelle qu'à partir du 1er janvier 2022 tout prestataire qui veut accéder aux fonds publics ou mutualisés doit être certifié Qualiopi ; Richard SALANON n'a pas cette certification et n'est agréé par aucun fonds.

En pratique, adressez au fonds le programme demi-journée par demi-journée et le devis avant toute signature, conservez sa réponse écrite et bâtissez le budget comme si l'aide n'arrivait pas. Les feuilles de présence, l'évaluation sur l'API inconnue et l'attestation remises en fin de session alimentent le dossier, quel que soit le dispositif. Les règles de chaque fonds sont détaillées sur la page formation en entreprise.

Connexion, langue, données personnelles : que change le contexte local pour une intégration ?

Une intégration fait voyager des données entre plusieurs services, souvent hébergés hors du pays. Au Bénin, l'article 391 de la loi n° 2017-20 du 20 avril 2018 portant code du numérique ne permet de transférer des données personnelles vers un État tiers que si l'Autorité constate qu'il assure un niveau de protection équivalent. Un flux qui fait passer un numéro de client par Zapier, Make ou n8n Cloud, puis par un tableur Google, franchit plusieurs frontières en quelques secondes. La fiche de chaque intégration liste donc les services traversés et les données transmises, pour que la question puisse être posée avant la mise en service.

En Europe, le RGPD, dont la CNIL publie le texte, aborde la même réalité sous deux angles. L'article 28 impose de ne recourir qu'à des sous-traitants offrant des garanties suffisantes, ce que deviennent l'outil d'automatisation et chaque API appelée. L'article 32 exige des mesures de sécurité adaptées au risque : une clé d'API rangée dans un coffre, aux droits limités et renouvelée à échéance en fait partie. La fiche d'intégration ne remplace pas le registre des traitements, mais elle donne à la personne qui le tient la liste exacte des outils concernés.

La connexion pèse sur la conception. Selon l'UIT, en 2025, 36 % des habitants de l'Afrique utilisent Internet, contre 74 % de la population mondiale. Un flux hébergé dans le cloud continue de recevoir les webhooks quand le bureau est coupé, ce qu'un ordinateur local ne fait pas ; en revanche, les envois groupés des équipes de terrain arrivent par vagues et heurtent les limites de débit. D'où l'importance, enseignée ici, des lots, des délais croissants et des réessais bornés.

Restent les moyens de paiement et la langue. La documentation de FedaPay liste, pour les collectes, MTN, Moov, Celtiis, BMO et Coris Money au Bénin, Mixx By Yas et Moov au Togo, MTN en Côte d'Ivoire, Airtel au Niger, Free au Sénégal, et les cartes Visa et Mastercard partout ; un flux de paiement se conçoit avec les opérateurs réellement utilisés par vos clients. Côté langue, FedaPay documente en français, mais Google, Meta, Odoo et les trois outils d'automatisation surtout en anglais. Les séances se font en français, lexique des termes techniques à l'appui.

Pourquoi apprendre les intégrations API avec 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 connaît les API des deux côtés. Comme développeur, il en conçoit et en branche pour ses clients : agrégateurs de paiement, Odoo, Dolibarr, messageries. Son compte GitHub contient le dépôt bj-decoupage, une API REST du découpage administratif du Bénin publiée en mars 2024. Comme utilisateur de n8n et de Make, il relie ces mêmes services sans code quand c'est suffisant. Il a créé Wapy, un assistant WhatsApp à intelligence artificielle pour les entreprises d'Afrique francophone, et co-fondé Audyxa.

Formé à EPITECH (2022), il exerce dans le numérique depuis 6 ans et indique avoir formé plus de 200 personnes au numérique, à l'IA, à l'automatisation et aux ERP. Il a travaillé, sur place ou à distance, 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 n'est ni certifié ni partenaire de FedaPay, d'Odoo, de Google, de Meta, de n8n, de Make ou de Zapier ; la formation se conclut par une évaluation sur une API inconnue et une attestation. Il forme sur vos comptes de test plutôt que sur les siens, répond sous 24 heures, et dit franchement quand une intégration mérite un vrai développement plutôt qu'un module HTTP. Son parcours est présenté sur la page Richard SALANON, les pays servis sur la page zones d'intervention.