Intégrer une API tierce : ce qu’il faut vérifier avant de s’engager
Brancher un CRM, une solution de téléphonie ou WhatsApp Business paraît simple sur le papier : l’éditeur annonce une API, la documentation existe, il n’y a « qu’à » consommer les points d’entrée. En pratique, l’écart entre deux jours et deux semaines de travail se joue sur sept détails, tous vérifiables avant de chiffrer.
1. Le mode d’authentification
Une clé d’API statique se met en place en une heure. Un flux OAuth 2.0 avec rafraîchissement de jeton demande une journée : il faut stocker les jetons de façon sécurisée, gérer leur expiration, prévoir la reconnexion quand un administrateur révoque un accès. Ce n’est pas difficile, mais ce n’est pas gratuit.
2. Les limites d’appel
La plupart des API imposent un quota : tant d’appels par minute, par heure ou par jour. Deux conséquences concrètes. D’abord, une synchronisation initiale de plusieurs milliers d’enregistrements ne peut pas se faire d’un bloc — il faut un traitement par lots, avec reprise après interruption. Ensuite, le code doit gérer proprement le dépassement de quota et réessayer avec un délai croissant, sinon un pic d’activité produit des pertes de données silencieuses.
3. La direction des échanges
Question déterminante : l’API se contente-t-elle de répondre à vos requêtes, ou sait-elle vous notifier ?
- Avec webhooks — le service vous prévient d’un changement. Les données restent à jour en temps réel, la charge est faible.
- Sans webhooks — il faut interroger régulièrement. Plus de complexité, plus de consommation de quota, et un délai de propagation incompressible.
L’absence de webhooks peut doubler le coût d’une intégration. C’est le premier point que nous vérifions.
4. L’environnement de test
Un bac à sable permet de développer sans polluer les données réelles du client. Sans lui, il faut travailler sur le compte de production, avec toutes les précautions que cela impose — et l’impossibilité de tester les cas d’erreur. Certains éditeurs facturent l’accès au bac à sable : à savoir avant de s’engager sur un prix.
5. Le format des erreurs
Une API bien conçue renvoie des codes HTTP cohérents et des messages exploitables. D’autres répondent 200 OK avec un message d’échec dans le corps de la réponse. Le second cas impose d’analyser chaque réponse et complique le traitement des cas limites. Un coup d’œil à la section « erreurs » de la documentation renseigne immédiatement sur le sérieux de l’API.
6. La stabilité des versions
Regardez l’historique des versions et la politique de dépréciation. Un éditeur qui publie une version majeure tous les six mois avec un préavis de trois mois vous imposera une maintenance récurrente. À l’inverse, une API stable depuis trois ans est un bon signe — à intégrer dans le contrat de maintenance présenté au client.
7. Les données personnelles
Dès qu’une intégration fait transiter des données clients, trois questions se posent : où sont hébergées les données, combien de temps sont-elles conservées, et le fournisseur est-il sous-traitant au sens du RGPD ? Un contrat de sous-traitance des données est souvent nécessaire. Le sujet est juridique, mais il conditionne parfois le choix technique.
Les intégrations que nous rencontrons le plus
- CRM — Salesforce, FrontApp : synchronisation des contacts et des opportunités, quotas généreux, webhooks disponibles.
- Téléphonie — Aircall, Ringover : remontée d’appels et fiches contact, webhooks bien documentés.
- Messagerie — Meta API pour WhatsApp Business : la plus contrainte, avec validation préalable des modèles de message et règles strictes sur les délais de réponse.
- CMS et e-commerce — WordPress, WooCommerce : API REST natives, très ouvertes.
Une méthode simple
Avant tout chiffrage, nous consacrons une à deux heures à lire la documentation en cherchant précisément ces sept points. C’est le meilleur investissement possible : il transforme une estimation au doigt mouillé en fourchette tenable, et évite la mauvaise surprise à mi-parcours.