API

Une API, pour interface de programmation applicative, est un contrat technique qui permet à deux logiciels d'échanger des données et de déclencher des actions sans rien connaître du fonctionnement interne l'un de l'autre. Elle définit ce que l'on peut demander, sous quelle forme, et ce qui sera renvoyé.

C'est le comptoir d'un service : vous passez commande selon un format convenu, on vous répond selon un format convenu, et vous n'entrez jamais en cuisine. Tant que le comptoir ne change pas, la cuisine peut être entièrement refaite sans que vous ayez à modifier votre façon de commander.

Comment ça marche

Le style le plus répandu est REST, bâti sur HTTP. Chaque ressource possède une adresse, et les verbes disent l'intention : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. Le serveur répond avec un code de statut — 200 pour un succès, 201 pour une création, 401 si vous n'êtes pas authentifié, 404 si la ressource n'existe pas, 500 en cas d'erreur serveur — et un corps généralement en JSON.

L'accès est contrôlé par une clé, un jeton ou un flux OAuth 2.0. À côté de REST coexistent GraphQL, où le client décrit précisément les champs qu'il veut recevoir, gRPC pour les échanges internes à haute fréquence, et les webhooks, qui inversent la logique : c'est le service distant qui appelle votre serveur dès qu'un événement survient.

À quoi ça sert concrètement

• Brancher un paiement, un CRM, un ERP ou un outil comptable sans ressaisie
• Alimenter un site et une application mobile avec le même back-end
• Ouvrir vos données à un partenaire ou à un revendeur de façon encadrée
• Automatiser des enchaînements de tâches, notamment via des outils comme n8n
• Donner à un agent conversationnel un accès contrôlé à vos systèmes

Les pièges

Ne pas versionner son API est la faute la plus coûteuse : le jour où vous renommez un champ, toutes les applications qui en dépendent cassent en même temps. Préfixer les routes par une version et annoncer les dépréciations évite ce scénario.

Trois autres écueils reviennent souvent : l'absence de pagination, qui fait tomber le serveur le jour où une liste dépasse quelques milliers d'éléments ; l'absence de limitation du nombre d'appels, qui laisse un client mal codé saturer le service ; et le renvoi systématique de toutes les colonnes d'une table, y compris des données personnelles dont personne n'a besoin.

Quand la construire

Une API interne se justifie dès que deux composants distincts doivent partager des données — typiquement un site et une application mobile. Une API publique, en revanche, est un produit à part entière : elle impose une documentation, une politique de compatibilité, un support et une surveillance. Ne l'ouvrez pas au cas où ; ouvrez-la quand un partenaire identifié en a besoin.