Vous commandez une pizza en trois clics sur votre appli de livraison préférée. Cinq minutes plus tard, le restaurateur reçoit la commande, la cuisine s’active, et un livreur part. Magique ? Pas vraiment. Entre votre téléphone et la cuisine du restaurant, il y a un petit intermédiaire invisible qui fait tout le travail : une API. Ce sigle barbare — Application Programming Interface — est partout, et pourtant presque personne ne le voit. Cet article vous explique, avec l’analogie (très) gourmande du restaurant, ce que sont réellement les API et pourquoi elles font tourner le monde numérique sans qu’on leur dise merci.
Qu’est-ce qu’une API, en vrai ?
Une API est un contrat : un ensemble de règles qui permet à deux logiciels de discuter sans se connaître. Votre application joue le client ; un service distant (météo, banque, réseau social) joue le fournisseur. Le client veut une info ou une action, mais ne peut pas fouiller dans les tiroirs du fournisseur : il frappe à une porte bien définie et demande poliment, dans un langage convenu.
Le mot clé est interface : une API expose une partie des capacités d’un programme au monde extérieur tout en cachant le reste. C’est une vitrine, pas l’arrière-boutique. C’est ce qui rend le logiciel moderne possible : on empile des briques qui se parlent, au lieu de tout réinventer.
L’analogie du restaurant, pas à pas
Fermez les yeux (enfin, lisez quand même). Vous êtes dans un restaurant. Voici les rôles :
- Vous (le client) = l’application qui veut quelque chose. Vous avez faim, vous voulez manger.
- Le serveur = l’API. Il prend votre commande, la transmet, rapporte le résultat. Il ne cuisine pas, il fait la liaison.
- La cuisine = le serveur backend, la base de données, le moteur qui produit réellement le plat.
- Le menu = la documentation de l’API. C’est la liste de ce que vous pouvez commander, et comment le formuler.
Vous ne passez pas derrière le comptoir. Vous lisez le menu, dites « pizza n°4, bien cuite », et le serveur s’occupe du reste. Si la demande est claire et la cuisine a les ingrédients, vous récupérez votre pizza ; sinon, le serveur revient avec un code d’erreur poli : « désolé, plus de n°4 ce soir ».
Le menu : les endpoints et la documentation
Dans le langage des API, chaque « plat du menu » s’appelle un endpoint. C’est une adresse précise (une URL) qui correspond à une action donnée : « donne-moi la liste des utilisateurs », « crée une nouvelle commande », « supprime ce fichier ». L’ensemble des endpoints, c’est le menu. Et comme dans un vrai restaurant, un menu bien écrit change tout.
C’est là qu’intervient le protocole HTTP, le même que votre navigateur. Les API modernes « parlent » HTTP via des verbes simples : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. En cas de succès, l’API renvoie un code 200 ; en cas d’erreur, un 404 (introuvable) ou 500 (la cuisine a pris feu). Ces codes sont devenus un réflexe pour des millions de développeurs.
Les langages des API : REST, SOAP et GraphQL
Historiquement, on utilisait SOAP, un format très rigide, pensé pour les banques et administrations. Solide, mais lourd.
Aujourd’hui, le roi est REST : on utilise les verbes HTTP, chaque ressource a sa propre adresse, chaque échange est autonome. Léger et lisible, c’est le standard de fait du web.
REST a une limite : il sert toujours le « plat complet », même pour une petite salade. Pour régler ça est né GraphQL, inventé chez Facebook : le client décrit exactement ce qu’il veut, et l’API renvoie précisément cela. Un peu comme composer soi-même son assiette au buffet.
JSON : le langage universel du dialogue
Le serveur rapporte votre commande via un format de texte structuré, le plus souvent du JSON (JavaScript Object Notation) : des paires « clé : valeur », des listes, des objets imbriqués. Un humain le lit, une machine le parse en millisecondes.
Un exemple tout concret, votre appli reçoit ceci :
{
"plat": "pizza",
"numero": 4,
"cuisson": "bien cuite",
"statut": "en preparation",
"delai_minutes": 12
}Voilà, en huit lignes, toute la réponse de l’API. Pas de protocole abscons, pas de binaire illisible : c’est cette lisibilité qui a fait du JSON l’espéranto du web, supplantant l’ancien XML pour sa compacité.
Sécurité et clés : quand le serveur demande une carte d’identité
Un restaurant ouvert à tous sans contrôle, ça finit mal. Les API sérieuses protègent leurs cuisines. La méthode la plus courante : une clé d’API, une sorte de mot de passe que votre application présente à chaque requête. « Bonjour, voici ma carte, je suis autorisé à voir les menus. »
Pour des échanges sensibles (se connecter, payer), on passe à OAuth, un protocole qui permet de donner accès à ses données sans jamais révéler son mot de passe. C’est ce qui se passe quand une appli vous propose « Continuer avec Google » : vous n’autorisez pas l’appli à lire votre mot de passe, vous lui délivrez un laissez-passer temporaire et limité. Élégant, et rassurant.
Il existe aussi des outils pour tester les API sans écrire de code. Postman, par exemple, est devenu incontournable : on y compose des requêtes, on les envoie, on lit les réponses. Et pour partager du code ouvert, la plateforme GitHub héberge des millions de projets qui exposent leurs propres API, documentées et versionnées.
Pourquoi les API font tourner le monde d’aujourd’hui
Regardez votre matinée. Votre réveil météo a interrogé une API météo. Votre appli de transport a appelé une API de trafic. Votre messagerie se synchronise via une API. Votre banque, vos cartes, votre montre, votre voiture : tous ces appareils ne font qu’échanger par API, en continu, à une vitesse invisible.
C’est aussi le moteur de l’économie des données : des entreprises vendent l’accès à leurs services via API, à la requête. Et l’IA moderne, en particulier les modèles de langage, se consomme comme une API : vous envoyez du texte, elle renvoie du texte.
Sans API, chaque application serait un îlot. Avec elles, elles forment un réseau vivant où chacune apporte sa spécialité. C’est l’équivalent numérique d’une ville où chaque boutique propose ses services par la vitrine, sans jamais laisser entrer le client dans l’atelier.
Conclusion
La prochaine fois que vous passerez commande en ligne, que vous partagerez une photo ou que vous consulterez votre solde, souvenez-vous du serveur invisible. L’API n’est ni glamour ni compliquée : c’est un serveur de restaurant, discipliné et rapide, qui fait circuler les demandes et les réponses dans le silence de vos appareils. Comprendre cette analogie, c’est déjà comprendre une bonne part de l’architecture du web moderne.