API : Application Programming Interface
Infrastructure
API : Application Programming Interface. « Interface de programmation d'application », par analogie avec un guichet qui reçoit une demande, la transmet au bon service et rapporte la réponse.
Contrat d'échange : Une API définit les règles à respecter pour demander une donnée ou déclencher une action. Elle précise notamment le format des demandes, des réponses et des erreurs.
Requêtes et réponses : Un programme envoie une requête à une API, qui renvoie une réponse exploitable. Le programme n'a pas besoin de connaître les rouages internes du service appelé, seulement son interface.
Accès et sécurité : Une API peut exiger une clé, un jeton ou une authentification. Des limites de fréquence évitent aussi qu'un client monopolise le service, volontairement ou par accident.
Versions : Faire évoluer une API sans casser les programmes existants demande de gérer les versions et la compatibilité. Sinon, le changement de format arrive en production avec ses gros sabots.
Ce qui arrive si on s'en passe
Une API est une surface d'exposition, donc elle se traite en couches. À l'entrée, un garde : authentification de l'appelant, autorisation par ressource et par verbe, quotas et limitation de débit, validation stricte du schéma d'entrée avec rejet de tout champ inattendu. Ensuite, la détection : journaliser chaque appel avec identifiant de corrélation, surveiller les taux d'erreur, les explorations d'identifiants séquentiels et les pics par client. Les messages d'erreur restent uniformes vers l'extérieur : un statut qui distingue trop finement les causes d'échec devient un oracle exploitable. Enfin, la réponse : révocation ciblée des clés compromises, versionnement permettant de retirer un point d'entrée vulnérable sans interrompre les autres, et documentation du contrat pour que la surface réelle reste celle qui est auditée.
Comment le mettre en place
Monter un labo minimal : exposer un service HTTP avec un point d'entrée `/v1/ressource` renvoyant un objet JSON à trois champs, puis écrire un client qui consomme strictement ces champs. Renommer ensuite un champ ou changer son type (entier devenu chaîne) sans toucher au numéro de version, et relancer le client sans le modifier. Observer où la casse apparaît : erreur de désérialisation immédiate, ou pire, valeur silencieusement nulle propagée en aval. Répéter en ajoutant seulement un champ facultatif pour vérifier qu'un client tolérant ne casse pas. Ce test prouve qu'une API est un contrat, pas un simple accès : ce qui protège les appelants n'est pas le code du serveur mais la discipline de versionnement et la validation de schéma des deux côtés.
Explication de la marmotte
Une interface de programmation est comme un guichet entre deux logiciels. Pour demander une information, un logiciel remplit un formulaire avec des règles précises. Le guichet transmet la demande au bon service, puis rapporte une réponse compréhensible par le logiciel. Il peut aussi refuser l'accès si la personne n'a pas l'autorisation. Grâce à ce fonctionnement, des applications différentes coopèrent sans connaître tous leurs rouages. Chacune respecte simplement les consignes du guichet. Changer ces consignes sans prévenir pourrait casser les échanges, comme déplacer un guichet sans afficher la nouvelle adresse.
Où ce terme est utilisé
- OIDC, SAML et OAuth 2.1 en fédération (15 occurrences)
- Jeton de compte de service Kubernetes monté par défaut (14 occurrences)
- Séparer plan de contrôle et plan de données (14 occurrences)
- AI Act : transparence des chatbots, hypertrucages et contenus générés (article 50) (12 occurrences)
- Comment sécuriser une API GraphQL en production (12 occurrences)
- Rétention des données envoyées à une API d'IA générative (11 occurrences)
- Backend Foundry Local expliqué et comparé à LM Studio (10 occurrences)
- Partage de données inter-organisations par API (10 occurrences)
- AI Act et modèle d'IA à usage général appelé par API (9 occurrences)
- Différence entre IA et LLM : un champ entier, un type de modèle (9 occurrences)