Vous utilisez des API tous les jours sans le savoir. Quand une application météo affiche la température de votre ville, elle ne calcule rien elle-même : elle interroge un serveur distant qui lui renvoie les données. Ce dialogue entre deux logiciels passe par une API, ou interface de programmation d’application. Comprendre ce mécanisme, c’est saisir comment la quasi-totalité des services web fonctionnent aujourd’hui.
API : l’analogie du serveur de restaurant
Imaginez un restaurant. Vous êtes assis à table (le client), la cuisine prépare les plats (le serveur). Vous ne pouvez pas entrer en cuisine pour vous servir. Un serveur prend votre commande, la transmet à la cuisine, puis vous rapporte le plat demandé.
A lire aussi : Qu'est-ce qui est accessible numériquement ?
Une API joue exactement ce rôle d’intermédiaire. Elle reçoit une requête formulée selon des règles précises, la transmet au système qui détient les données ou le service, puis renvoie la réponse au demandeur. Le client n’a pas besoin de connaître le fonctionnement interne du serveur.
Cette séparation est volontaire. Le restaurant ne veut pas que chaque convive manipule ses fourneaux. De la même façon, un service web expose uniquement les actions autorisées via son API, et rien d’autre.
A voir aussi : Comment vérifier qu'un site est accessible ?
Exemple concret d’une API : réserver un vol en ligne
Vous cherchez un billet d’avion sur un comparateur de vols. Ce comparateur ne possède pas les horaires ni les tarifs : il interroge les API de plusieurs compagnies aériennes simultanément.
Voici ce qui se passe en coulisses :
- Le comparateur envoie une requête à l’API de chaque compagnie, en précisant la ville de départ, la destination et la date souhaitée.
- Chaque API vérifie les disponibilités dans son propre système de réservation, puis renvoie une réponse structurée (horaires, prix, places restantes).
- Le comparateur reçoit toutes les réponses, les trie et vous affiche les résultats sur une seule page.
À aucun moment le comparateur n’accède directement aux bases de données des compagnies. L’API définit précisément quelles informations sont accessibles et sous quel format. C’est un contrat technique entre deux logiciels.
Ce principe s’applique partout : un site e-commerce qui affiche un plan Google Maps, une application bancaire qui récupère vos transactions, un outil de gestion qui se connecte à un service de facturation.
Requête et réponse : le dialogue technique d’une API web
La plupart des API web modernes utilisent le protocole REST. Le client envoie une requête HTTP (le même protocole que votre navigateur) vers une adresse précise, appelée endpoint. Cette requête contient une méthode (GET pour lire, POST pour créer, PUT pour modifier, DELETE pour supprimer) et parfois des paramètres.
Prenons un exemple simplifié. Pour obtenir la météo de Lyon, l’application envoie quelque chose comme :
GET /meteo?ville=Lyon
Le serveur reçoit cette requête, consulte ses données, puis renvoie une réponse au format JSON, un format texte lisible aussi bien par un humain que par une machine. La réponse pourrait ressembler à : ville: Lyon, température: 18, conditions: ensoleillé.
Le client (l’application météo) lit cette réponse et l’affiche dans son interface. Le format de la requête et de la réponse est documenté par le fournisseur de l’API, ce qui permet à n’importe quel développeur de l’utiliser sans appeler l’équipe technique.
Sécurité des API : le risque que les définitions oublient
Vous avez compris le mécanisme. Mais un point rarement abordé dans les introductions mérite votre attention : la sécurité ne se limite pas à vérifier l’identité de celui qui appelle l’API.
D’après l’édition 2023 de l’OWASP API Security Top 10, le risque classé en première position est la Broken Object Level Authorization. En pratique, cela signifie qu’une API peut très bien vérifier que vous êtes connecté, tout en vous laissant consulter les données d’un autre utilisateur si vous modifiez un simple identifiant dans la requête.
Autre risque identifié par l’OWASP en 2023 : l’accès illimité aux flux métier sensibles. Un attaquant peut automatiser un parcours prévu pour être utilisé manuellement (création de comptes, réservation, remboursement) et détourner le service sans exploiter de faille technique classique.
Dernier point sous-estimé : l’inventaire. Une ancienne version d’API laissée accessible, un endpoint de test non désactivé, une documentation obsolète encore en ligne, tout cela constitue une surface d’attaque. Connaître toutes les API exposées fait partie de leur sécurité.
API REST, SOAP, WebSocket : choisir le bon type pour le bon usage
Toutes les API ne fonctionnent pas de la même manière. Le choix du type dépend du besoin.
- REST est le standard dominant pour les applications web et mobiles. Il utilise HTTP, renvoie du JSON, et convient à la majorité des cas : lecture de données, envoi de formulaires, intégration entre services.
- SOAP repose sur XML et impose un format plus strict. On le retrouve dans des environnements bancaires ou industriels où la fiabilité des échanges prime sur la simplicité.
- WebSocket maintient une connexion ouverte entre client et serveur. Ce type est adapté aux applications qui ont besoin de données en temps réel : messagerie instantanée, cours de bourse, jeux en ligne.
Pour un développeur qui démarre un projet web, REST sera le choix par défaut dans la grande majorité des cas. Les autres types répondent à des contraintes spécifiques.
Une API est un contrat entre deux logiciels : l’un demande, l’autre répond, selon des règles documentées. Ce mécanisme permet à des milliers de services de s’interconnecter sans que chacun réinvente ce qui existe déjà. Si vous regardez de plus près les applications que vous utilisez au quotidien, vous constaterez qu’elles assemblent souvent plusieurs API, de la cartographie au paiement en passant par la recherche d’adresses.
