Qu'est-ce qu'une API ?
Une API est un contrat entre deux systèmes. L'un publie une liste d'opérations, indique ce que chacune accepte et ce qu'elle renvoie, et s'engage à garder ce comportement stable. L'autre appelle ces opérations sans savoir comment elles sont implémentées, et sans avoir accès au code ni à la base de données.
Le mot décrit l'accord, pas la technologie. Des requêtes HTTP renvoyant du JSON en sont la forme courante aujourd'hui, mais la même idée couvre un langage de requête, une file de messages ou un appel de bibliothèque. Ce qui fait une API, c'est que le comportement est déclaré et stable, pas le canal par lequel il transite.
Ce cadrage compte parce qu'il déplace les vraies questions hors de la colonne technique. Savoir si un système a une API n'est presque jamais intéressant. Ce qu'elle expose, ce qu'elle retient, ce qu'elle coûte et combien de temps elle reste inchangée décident si une intégration est un chantier de deux semaines ou une charge permanente.
Pourquoi les API sont importantes
Pour une entreprise qui achète ou construit du logiciel, quatre conséquences en découlent directement.
- Une API décide si vous pourrez partir. Un produit dont les données ne sont accessibles que par un export manuel sera coûteux à remplacer. La présence d'une API documentée, et l'étendue de ce qu'elle expose, sont la mesure pratique de la dépendance fournisseur. Cela mérite une place dans la décision d'achat, pas dans l'annexe technique.
- Elle supprime la double saisie entre systèmes. Si une adresse client est tapée dans trois outils, ce n'est presque jamais parce que les connecter était impossible. C'est que personne n'a cadré la connexion.
- Elle rend l'automatisation possible sans rien remplacer. Connecter deux systèmes qui font chacun bien leur travail coûte généralement bien moins cher que migrer vers une suite unique qui fait les deux à peu près.
- C'est désormais une nécessité légale dans certains cas. La facturation électronique structurée en Belgique impose que les factures sortent et entrent sous forme de données lisibles par machine. Ce chemin passe par une interface, qu'on l'appelle API ou point d'accès.
La contrepartie inconfortable est qu'une intégration n'est jamais terminée. L'autre côté du contrat appartient à quelqu'un d'autre, qui modifiera un champ, retirera une version ou resserrera une limite d'appels à son calendrier et non au vôtre. Budgéter une intégration comme un projet ponctuel est l'erreur de planification la plus fréquente, et elle refait surface six mois plus tard sous forme de correction urgente que personne n'avait provisionnée.
Comment ça fonctionne
Cinq mécanismes couvrent presque tout ce qu'un acheteur a besoin de comprendre.
Requête et réponse. Le consommateur envoie une requête nommant une opération et ses paramètres. Le fournisseur renvoie une réponse structurée, plus un statut indiquant le succès ou la raison de l'échec. Traiter correctement les cas d'échec représente l'essentiel du travail.
Authentification. Chaque appel prouve qui le passe, généralement avec une clé ou un jeton, et ces identifiants portent une portée. Une intégration bien conçue reçoit l'accès le plus étroit qui lui permet de fonctionner, ce qui empêche une clé compromise de devenir une brèche complète.
Limites d'appels. Les fournisseurs plafonnent le nombre d'appels par minute ou par jour. C'est une contrainte fonctionnelle et non un détail : une intégration conçue sans connaître la limite fonctionnera en test et échouera au premier jour de forte activité.
Versionnage. Un fournisseur qui change de comportement casse tous ses consommateurs. Les fournisseurs sérieux publient des versions et une politique d'obsolescence indiquant le préavis accordé. Ceux qui n'en ont pas casseront un jour votre intégration sans avertissement, et ce risque appartient à l'évaluation.
Webhooks. Le sens inverse. Au lieu que votre système demande toutes les cinq minutes si quelque chose a changé, le fournisseur vous prévient quand ça arrive. Moins cher, plus rapide et moins fragile que l'interrogation régulière, et leur absence signifie généralement une file de tâches planifiées que personne n'a envie de maintenir.
Mise en œuvre
La liste ci-dessous est écrite sous forme de questions à poser avant de signer, parce que c'est le moment où les réponses changent encore quelque chose.
- La documentation est-elle publique, et lisible avant l'achat ? Une documentation accessible seulement après signature est un signal d'alerte, pas une formalité administrative.
- L'accès à l'API est-il inclus ou vendu en option ? Le facturer séparément est courant et légitime. Le découvrir après avoir signé le contrat principal n'est pas une bonne position.
- Expose-t-elle tout ce dont vous auriez besoin pour partir ? L'accès en lecture à votre propre historique compte davantage que les opérations à la mode. Testez un vrai export avant de vous engager.
- Quelle est la limite d'appels, et tient-elle vos pics ? Pas votre moyenne. Les fins de mois et les pics de saison sont là où la limite mord.
- Quelle est la politique d'obsolescence ? Quatre-vingt-dix jours de préavis et un journal des changements est une réponse acceptable. Aucune politique signifie que votre intégration est programmée pour casser à un moment choisi par quelqu'un d'autre.
- Des webhooks sont-ils disponibles ? Leur absence oblige à interroger en boucle, ce qui coûte plus cher, réagit plus lentement et ajoute des tâches à maintenir.
- Budgétez la maintenance, pas seulement la livraison. Une intégration est un abonnement à la feuille de route de quelqu'un d'autre. Prévoyez une petite enveloppe récurrente plutôt qu'une urgence.
Technologies et outils liés
- REST et GraphQL : les deux styles dominants. REST expose des opérations fixes, GraphQL laisse le consommateur préciser exactement les champs qu'il veut. Le choix affecte l'effort, pas la capacité.
- OpenAPI : le standard de description d'une interface dans un fichier lisible par machine, à partir duquel documentation et code client se génèrent. Sa présence est un bon indicateur du sérieux avec lequel un fournisseur traite son contrat.
- Webhooks : les notifications à l'initiative du fournisseur, qui suppriment le besoin d'interroger en boucle.
- OAuth 2.0 : le standard d'autorisation déléguée, qui permet à une intégration d'agir au nom d'un utilisateur sans détenir son mot de passe.
- Passerelles d'API : la couche qui centralise authentification, limitation de débit et journalisation devant plusieurs interfaces.
- MCP : le standard émergent d'exposition d'outils et de données aux modèles de langage, qui se pose au-dessus des API existantes plutôt qu'il ne les remplace.
Conclusion
Une API est un engagement commercial exprimé en termes techniques. Jugez-la comme n'importe quel engagement fournisseur : ce qui est promis, ce que ça coûte, quel préavis avant un changement, et ce que vous pourrez emporter si vous partez.
La question à poser avant un achat de logiciel n'est donc pas de savoir si le produit a une API. C'est de savoir ce que cette API vous permet d'emporter. Un éditeur qui répond clairement et vous laisse tester un vrai export propose une relation d'une autre nature que celui qui traite son interface comme une option premium. Cette différence ne coûte rien à vérifier et coûte très cher à découvrir tard.
