API (interface de programmation)

Une API définit ce qu'un logiciel accepte de recevoir et ce qu'il retourne en échange. Le programme qui envoie la demande n'a pas besoin de savoir comment fonctionne celui qui répond : il suit le contrat décrit dans la documentation de l'API. Ce cloisonnement est précisément ce qui rend les échanges fiables et sécurisés entre systèmes indépendants.

L'exemple le plus courant est le paiement en ligne. Quand un site intègre un formulaire de carte bancaire, le prestataire de paiement traite la transaction via une API : le site envoie les données de la commande, reçoit une confirmation ou un refus, et n'accède à rien d'autre. La même logique s'applique à toute connexion entre une application et un outil externe, qu'il s'agisse de comptabilité, de messagerie ou d'un outil de gestion.

Le format REST (Representational State Transfer) est le standard dominant pour les API web. Il s'appuie sur le protocole HTTP et retourne généralement les données en JSON, un format lisible par la plupart des langages de programmation. Une API REST bien conçue documente chaque route disponible, les paramètres acceptés, les codes de réponse et les conditions d'erreur.

Strapi, le CMS headless utilisé par ISOMORPH, expose une API REST et une API GraphQL générées à partir du modèle de contenus. Un front-end Next.js, une application mobile ou un outil tiers peuvent consommer ces données sans accès direct à la base de données. Ce principe de séparation est l'un des fondements de l'architecture hébergée par ISOMORPH pour ses projets web et applicatifs.

API dans un projet

Dès qu'un projet se connecte à un outil externe, il passe par une API. Les questions à poser avant de commencer : l'outil dispose-t-il d'une API documentée ? Cette documentation est-elle à jour ? La stabilité des versions est-elle garantie dans le temps ? Une API non documentée ou instable alourdit la maintenance quel que soit le soin apporté au développement.

Une API qui change sans préavis casse l'intégration. Certains éditeurs publient des versions numérotées (v1, v2) et maintiennent les anciennes pendant un délai annoncé. D'autres modifient leur API sans notice. Ce choix éditorial conditionne le coût de maintenance bien au-delà du développement initial, et doit être évalué au cadrage.

Les API peuvent aussi imposer des limites de débit (rate limiting) : un nombre maximal de requêtes par seconde ou par jour. Pour un projet qui génère beaucoup d'échanges automatisés, ces limites influencent l'architecture de manière significative. Mieux vaut les connaître au cadrage plutôt que les découvrir en production lors d'une montée en charge.

Un webhook est une forme complémentaire d'API où c'est le logiciel source qui notifie votre système dès qu'un événement se produit, plutôt que votre système qui interroge périodiquement l'autre. Pour un traitement en temps réel (une commande reçue, un paiement validé), le webhook est généralement plus adapté.