Qu’est-ce qu’une API ? Définition et fonctionnement

Une API, ou interface de programmation d’application, est un contrat qui permet à deux logiciels d’échanger des données ou de déclencher des fonctions sans connaître leurs mécanismes internes.

Lorsqu’une application météo affiche une prévision, elle peut envoyer une requête à un service distant, puis interpréter la réponse structurée que ce service renvoie. L’API définit ce qui peut être demandé, à quelle adresse, avec quels paramètres, sous quel format et selon quelles règles d’accès.

Elle joue donc un rôle comparable à un guichet : le client formule une demande autorisée, le système la traite, puis fournit une réponse ou une erreur compréhensible.

Toutes les API ne passent pas par Internet. Un système d’exploitation, une bibliothèque logicielle, un navigateur ou un composant interne peut également exposer une interface de programmation.

Dans les API web, HTTP ou HTTPS sert souvent au transport, tandis que JSON est fréquemment utilisé pour représenter les données, sans être le seul format possible. REST, GraphQL, SOAP et RPC décrivent des approches différentes ; un webhook, lui, inverse le déclenchement en avertissant automatiquement une application lorsqu’un événement survient.

Une clé API peut identifier un projet ou contrôler un quota, mais elle n’est pas toujours une authentification forte d’utilisateur et ne doit jamais être exposée dans du code public.

La sécurité repose aussi sur TLS, des autorisations minimales, la validation des entrées, la limitation de débit, les journaux et la rotation des secrets.

Pour utiliser une API correctement, il faut lire sa documentation, comprendre les endpoints, méthodes, en-têtes, corps, codes d’état, pagination et règles de versionnement.

Ce guide s’appuie sur les normes et documentations officielles afin de distinguer les concepts stables des choix propres à chaque fournisseur.

Qu’est-ce qu’une API ? Définition simple

API signifie Application Programming Interface, soit interface de programmation d’application. Une interface expose un ensemble contrôlé d’opérations, de structures ou de règles. Le logiciel consommateur utilise ce contrat au lieu de manipuler directement l’implémentation, la base de données ou le matériel du fournisseur.

L’abstraction est l’idée centrale. Un développeur peut demander au navigateur la position de l’appareil, à un système d’exploitation d’ouvrir un fichier ou à un service de paiement de créer une transaction, sans réécrire les couches complexes qui rendent ces actions possibles. L’API fournit une entrée stable, documentée et limitée.

Une API n’est donc ni une base de données, ni une interface graphique, ni nécessairement un serveur. Elle peut être locale ou distante, synchrone ou asynchrone, interne ou externe. Une bibliothèque expose par exemple des fonctions directement dans le programme ; une API web reçoit généralement des messages à travers un réseau.

Le contrat précise les opérations disponibles, les données attendues, les réponses possibles et les erreurs. Selon le contexte, ce contrat est décrit par une documentation, des types de langage, un fichier OpenAPI, un schéma GraphQL, une définition WSDL ou une autre spécification lisible par les humains et les outils.

L’analogie du restaurant aide à débuter : le menu indique ce que l’on peut commander, le serveur transmet la demande et la cuisine produit le résultat. Mais une vraie API ajoute des contraintes strictes : format, identité, autorisation, limites, délais, compatibilité et gestion explicite des erreurs.

Pour distinguer l’adresse d’une ressource de l’interface qui la manipule, consultez notre définition complète d’un URI et de son rôle sur le Web.

Comment fonctionne une API, étape par étape ?

Dans une API web classique, un client prépare d’abord une requête. Le client peut être un navigateur, une application mobile, un serveur, un script ou un objet connecté. Il choisit une adresse appelée endpoint, une méthode, des paramètres et parfois un corps de données.

La requête traverse le réseau avec des en-têtes qui décrivent notamment le format accepté, le type de contenu et les informations d’authentification. HTTPS protège les données en transit grâce à TLS, mais ne garantit pas que le client est autorisé à effectuer l’action demandée : le serveur doit encore vérifier identité, droits et contexte.

La passerelle ou l’application serveur reçoit le message, valide sa forme, applique les règles métier et consulte éventuellement une base de données ou un autre service. Elle doit traiter les entrées comme non fiables, limiter les ressources consommées et ne retourner que les données auxquelles le demandeur a droit.

Le serveur renvoie ensuite une réponse composée d’un code d’état, d’en-têtes et éventuellement d’un corps. Un code 2xx indique généralement un succès, 4xx un problème lié à la requête ou aux droits, et 5xx une défaillance côté serveur. Le corps peut fournir le résultat ou un objet d’erreur documenté.

Le client interprète enfin la réponse. Il affiche les données, met à jour son état, réessaie éventuellement ou informe l’utilisateur. Un bon client ne considère pas qu’un message reçu est forcément exploitable : il vérifie le code, le format, le délai, la taille et les champs attendus.

Ce cycle peut être synchrone, lorsque le client attend la réponse, ou asynchrone, lorsqu’un traitement long renvoie d’abord un identifiant de tâche. Dans ce second cas, le client interroge l’état ou reçoit plus tard un événement. Le choix dépend de la durée, du volume et du niveau de fiabilité attendu.

Quel vocabulaire faut-il connaître pour comprendre une API ?

Endpoint

Adresse logique d’une opération ou ressource, par exemple /articles ou /orders/42.

Méthode HTTP

Intention portée par la requête : GET pour lire, POST pour créer ou déclencher, PUT/PATCH pour modifier, DELETE pour supprimer, selon le contrat.

Paramètres

Valeurs placées dans le chemin, la chaîne de requête, les en-têtes ou le corps.

En-têtes

Métadonnées de transport : type de contenu, cache, authentification, langue ou identifiant de corrélation.

Corps

Contenu principal envoyé ou reçu, souvent en JSON pour les API web modernes.

Code d’état

Résultat normalisé de la réponse HTTP, à interpréter avec la documentation de l’API.

Schéma

Définition de la forme, des types, contraintes et relations des données.

Jeton

Valeur représentant une identité, des droits ou un état auprès d’un service. Un jeton d’accès bearer doit être traité comme un secret ; sa durée dépend de l’émetteur et de sa politique.

Quota et rate limit

Volume total autorisé et rythme maximal sur une période.

SDK

Bibliothèque fournie pour appeler une API depuis un langage sans reconstruire chaque requête.

La pagination évite de renvoyer des milliers d’éléments en une seule réponse. Elle peut utiliser une page numérotée, un offset ou un curseur opaque. Le client doit suivre les liens ou marqueurs documentés plutôt que deviner la page suivante, surtout lorsque les données changent pendant la lecture.

L’idempotence signifie qu’une opération répétée produit le même effet observable qu’une seule exécution. GET, PUT et DELETE sont définies comme idempotentes dans la sémantique HTTP, même si les journaux ou compteurs techniques peuvent évoluer. Pour un paiement ou une création, une clé d’idempotence peut empêcher un double traitement après une reconnexion.

Le cache réutilise une réponse lorsque les règles l’autorisent. Il réduit la latence et la charge, mais peut afficher une donnée périmée ou sensible s’il est mal configuré. Les en-têtes HTTP indiquent la fraîcheur et les conditions de revalidation ; chaque API doit documenter ce qui peut être mis en cache.

Quels sont les différents types d’API selon leur accès ?

Une API publique, parfois appelée ouverte, est proposée à des développeurs externes selon des conditions définies. Publique ne signifie pas forcément gratuite, anonyme ou sans limite. Une inscription, une clé, une facturation, un examen de l’application ou des restrictions de données peuvent s’appliquer.

Une API privée est destinée aux systèmes d’une même organisation. Elle relie par exemple la boutique, le stock et la facturation. Son exposition limitée ne la rend pas automatiquement sûre : authentification, autorisation, chiffrement, inventaire, tests et supervision restent nécessaires.

Une API partenaire est accessible à des organisations approuvées dans le cadre d’un contrat. Elle peut fournir des opérations ou données non disponibles publiquement et imposer des obligations de service, de sécurité, de confidentialité et d’audit.

L’expression « API composite » est parfois ajoutée à ces listes, mais elle ne décrit pas un mode d’accès. Elle désigne une interface qui agrège plusieurs opérations ou services pour répondre à un besoin métier. Un endpoint de commande peut ainsi vérifier un client, réserver du stock et créer un paiement ; cette composition relève de l’architecture, pas de l’audience.

Les trois catégories d’accès peuvent se chevaucher dans un même produit. Une capacité peut avoir une façade publique et une version partenaire plus riche, tandis que les services internes utilisent un contrat proche. L’architecture doit décrire l’audience, les droits et les responsabilités, puis documenter séparément toute composition de services.

L’API REST de WordPress illustre une interface web publique pouvant être restreinte selon l’opération. Notre guide sur WordPress MCP et l’API REST explique comment cette base peut être exposée aux agents et aux outils.

REST, GraphQL, SOAP, RPC et webhook : quelles différences ?

REST est un style architectural, pas un protocole ni un format. Une API dite REST organise généralement des ressources identifiées par des URI, utilise la sémantique HTTP et échange des représentations, souvent JSON. Dans la pratique, de nombreuses API sont seulement RESTful à des degrés variables.

GraphQL est un langage de requête et un environnement d’exécution pour API. Le client décrit les champs dont il a besoin à partir d’un schéma typé. Cette précision limite parfois la sur-récupération, mais déplace la complexité vers le schéma, les résolveurs, les autorisations, le cache et le contrôle du coût des requêtes.

SOAP est un protocole de messagerie fondé sur XML, accompagné d’un écosystème de standards. Il demeure présent dans des environnements exigeant des contrats formels, des outils historiques ou certaines garanties de sécurité et de transaction. Il est généralement plus verbeux qu’une API HTTP en JSON.

RPC organise l’échange autour d’actions ou de procédures distantes. JSON-RPC décrit des messages JSON pour appeler une méthode ; gRPC s’appuie sur Protocol Buffers et HTTP/2 dans son usage classique. RPC est efficace pour des interactions explicites, notamment entre services contrôlés, mais crée un couplage différent d’une modélisation par ressources.

Un webhook n’est pas un style d’API concurrent au même niveau. C’est une notification envoyée par un service vers une URL configurée lorsque survient un événement : paiement accepté, livraison créée ou document signé. Le destinataire doit vérifier la signature, répondre rapidement et traiter les doublons.

Choisissez selon le besoin : REST pour une interface web largement compréhensible ; GraphQL pour une lecture flexible d’un graphe de données ; SOAP pour un écosystème qui l’exige ; RPC pour des appels fortement typés ou orientés action ; webhook pour pousser les événements. Plusieurs approches peuvent cohabiter dans un même système.

Approche	Modèle	Format courant	Atout	Vigilance
REST	Ressources	JSON	Simplicité web	Cohérence du contrat
GraphQL	Schéma et champs	JSON	Réponse ciblée	Coût et autorisations
SOAP	Messages	XML	Standards formels	Verbosité
RPC	Procédures	JSON ou binaire	Performance et typage	Couplage
Webhook	Événements poussés	Souvent JSON	Réactivité	Signature et doublons

Comment authentifier et sécuriser une API ?

L’authentification répond à la question « qui appelle ? », tandis que l’autorisation répond à « que peut-il faire ? ». Une API sûre vérifie les deux à chaque opération sensible. Le fait de posséder un identifiant valide ne doit jamais donner accès à toutes les ressources du compte ou d’un autre utilisateur.

Une clé API sert souvent à identifier un projet, mesurer l’usage et appliquer un quota. Elle doit être stockée côté serveur ou dans un gestionnaire de secrets, jamais dans un dépôt public, une URL partagée ou une application cliente où elle peut être extraite. Limitez sa portée, son origine, sa durée si possible et prévoyez sa rotation.

OAuth 2.0 permet à une application d’obtenir un accès délégué sans recevoir le mot de passe de l’utilisateur. Le flux, le type de client, les URI de redirection, les portées et la validation des jetons doivent suivre les recommandations actuelles. OpenID Connect ajoute une couche d’identité au-dessus d’OAuth 2.0 ; les deux ne sont pas synonymes.

TLS protège le transport contre l’écoute et l’altération, mais ne corrige pas une autorisation défaillante. OWASP place notamment les défauts d’autorisation au niveau objet parmi les risques majeurs des API : le serveur doit confirmer que l’appelant peut accéder à l’objet demandé, même s’il connaît son identifiant.

Validez les entrées, imposez des tailles maximales et utilisez des requêtes paramétrées. Limitez le débit par clé, compte, adresse ou opération selon le risque. Les quotas protègent les coûts et la disponibilité, mais une défense DDoS complète demande aussi filtrage, capacité, cache et surveillance.

Journalisez les événements utiles sans enregistrer les secrets, mots de passe ou données personnelles inutiles. Ajoutez un identifiant de corrélation, des métriques de latence, de taux d’erreur et de saturation, puis alertez sur les anomalies. La sécurité doit être testée avant la mise en production et après chaque changement significatif.

Enfin, prévoyez la révocation. Un secret finira parfois par être exposé ; l’équipe doit pouvoir l’invalider, en générer un nouveau et identifier les appels concernés. Les messages d’erreur publics doivent aider le client sans révéler la structure interne, les requêtes SQL ou les détails de configuration.

Exemple concret : appeler une API web

Imaginons une API météo fictive documentée avec l’endpoint HTTPS /v1/forecast. Le client veut obtenir la prévision de Kinshasa. Il envoie une requête GET avec des paramètres de latitude, longitude et unité, plus un en-tête Accept indiquant qu’il attend du JSON. L’URL et les noms exacts dépendraient de la documentation réelle du fournisseur.

Requête illustrative

GET https://api.exemple.test/v1/forecast?lat=-4.32&lon=15.31&units=metric
Accept: application/json
Authorization: Bearer VOTRE_JETON

Le serveur vérifie le jeton, valide les coordonnées, consulte ses données et renvoie par exemple un code 200 avec un objet contenant la ville, l’unité et une liste de prévisions. Si le jeton est absent ou invalide, il peut répondre 401 ; si l’appelant est identifié mais interdit, 403 ; si l’endpoint n’existe pas, 404 ; si la limite est dépassée, 429.

Réponse illustrative

{
  "location": "Kinshasa",
  "unit": "celsius",
  "forecast": [{"time": "2026-09-07T12:00:00Z", "temperature": 29}]
}

Cet exemple est volontairement fictif : il explique la forme sans fournir une clé ni promettre le comportement d’un service réel. Dans un projet, copiez l’exemple officiel, placez le secret dans une variable d’environnement côté serveur, définissez un délai d’attente et gérez chaque famille d’erreur.

Avec JavaScript, l’API Fetch du navigateur peut envoyer une requête. Une clé privée ne doit toutefois pas être intégrée au code livré au navigateur. Lorsque le fournisseur exige un secret, votre serveur appelle l’API puis renvoie au client seulement les données nécessaires.

Testez ensuite les cas limites : paramètre manquant, format incorrect, jeton expiré, quota atteint, absence de résultat, réponse lente, panne et champ nouveau. Un intégrateur fiable traite les erreurs comme une partie normale du contrat plutôt que comme une exception imprévisible.

Pour un exemple lié à l’intelligence artificielle, notre guide sur l’utilisation de l’API Mistral AI montre comment une API de modèle s’intègre dans un workflow plus large.

Comment concevoir, documenter et tester une API ?

Commencez par les consommateurs et les cas d’usage. Décrivez les tâches, données, volumes, exigences de délai et droits avant de choisir REST ou GraphQL. Une API est un produit utilisé par d’autres équipes : sa cohérence, sa documentation et sa stabilité déterminent son coût réel.

Concevez le contrat avant ou en parallèle du code. OpenAPI peut décrire une API HTTP, ses chemins, opérations, paramètres, requêtes, réponses et mécanismes de sécurité dans un document lisible par des outils. Il permet de générer une documentation, des clients ou des validations, sans garantir à lui seul la qualité de la conception.

Utilisez des noms cohérents, des types précis et des erreurs exploitables. Évitez de retourner 200 pour chaque résultat puis de cacher l’échec dans un champ ambigu. Documentez les codes, exemples, limites, pagination, tri, filtres, permissions et comportement en cas de répétition.

Versionnez avec prudence. Un ajout compatible, comme un champ facultatif, ne nécessite pas toujours une nouvelle version si les clients tolèrent les extensions. Une suppression, un changement de type ou de signification peut casser les consommateurs. Annoncez la dépréciation, mesurez l’usage et fournissez une période de migration.

Testez à plusieurs niveaux : unités pour la logique, intégration pour les dépendances, contrat pour vérifier la forme, sécurité pour les droits et entrées, charge pour la capacité, puis parcours de bout en bout. Les environnements et données de test doivent rester suffisamment proches du réel sans exposer de données personnelles.

Ajoutez l’observabilité dès le départ : taux de requêtes, succès et erreurs, distribution des latences, saturation, consommation par client et traces corrélées. Définissez des objectifs de service mesurables et un processus d’incident. Un tableau vert n’est utile que s’il représente l’expérience des consommateurs.

Pour choisir une API tierce, évaluez documentation, disponibilité, sécurité, conformité, prix, quotas, localisation des données, support, export et stratégie d’arrêt. Construisez une couche d’adaptation lorsque la dépendance est critique, afin de limiter la propagation de ses changements dans tout votre produit.

Les API prennent encore plus de valeur dans l’automatisation. Notre guide n8n MCP et agents IA explique comment des outils peuvent découvrir et orchestrer des fonctions avec des contrôles adaptés.

FAQ

API veut dire quoi ?

API signifie Application Programming Interface, soit interface de programmation d’application. C’est un contrat permettant à des logiciels d’utiliser des données ou fonctions de manière contrôlée.

Quelle différence entre API et interface graphique ?

Une interface graphique est destinée à une personne. Une API est destinée au code, même si des outils permettent de l’explorer visuellement.

Une API est-elle toujours sur Internet ?

Non. Les systèmes d’exploitation, bibliothèques et composants locaux exposent aussi des API. Une API web utilise un réseau et souvent HTTP ou HTTPS.

REST et API sont-ils synonymes ?

Non. REST est un style architectural utilisé par de nombreuses API web. Il existe aussi GraphQL, SOAP, RPC et d’autres approches.

JSON est-il obligatoire ?

Non. JSON est courant, mais une API peut utiliser XML, Protocol Buffers, du texte, du binaire ou un autre format documenté.

Une clé API suffit-elle pour sécuriser un service ?

Non. Elle peut identifier un projet, mais il faut aussi TLS, autorisations, stockage sûr, rotation, validation, limites de débit, journaux et surveillance.

Quelle différence entre 401 et 403 ?

401 indique que la requête ne possède pas des informations d’authentification valides. 403 indique que le serveur comprend la demande mais refuse de l’autoriser.

Qu’est-ce qu’un webhook ?

Un webhook est un appel envoyé automatiquement vers une URL lorsque survient un événement. Le destinataire doit vérifier sa signature et tolérer les doublons.

Comment tester une API sans coder ?

Des outils graphiques et la documentation interactive OpenAPI peuvent envoyer des requêtes. Il faut néanmoins protéger les secrets et comprendre l’environnement testé.

Comment savoir si une API est fiable ?

Examinez documentation, historique, statut, objectifs de service, sécurité, limites, support, politique de versionnement et possibilités d’export. Testez aussi les erreurs et la latence.

Sources officielles et normatives

Conclusion

Une API est un contrat d’interaction entre logiciels. Elle cache une implémentation complexe derrière des opérations documentées et permet au client d’envoyer une requête, de recevoir une réponse et de gérer explicitement les erreurs. Les types d’accès — public, privé ou partenaire — ne doivent pas être confondus avec les approches techniques comme REST, GraphQL, SOAP et RPC.

Pour l’utiliser correctement, comprenez l’endpoint, la méthode, les paramètres, en-têtes, corps et codes d’état. Protégez les secrets, appliquez l’autorisation à chaque ressource, limitez les appels et surveillez le service. Enfin, traitez documentation, tests, compatibilité et stratégie de sortie comme des fonctions essentielles : une API fiable est autant un engagement envers ses consommateurs qu’un morceau de code.

Qu’est-ce qu’une API ? Définition, Types et fonctionnement