API
À quoi sert une API et exemples concrets
Une API agit comme un contrat technique entre deux systèmes : elle définit comment demander une information ou déclencher une action, et sous quel format la réponse est renvoyée. Le logiciel appelant n'a pas besoin de connaître le code interne du système appelé, seulement les règles d'échange.
Dans un contexte d'entreprise, les API permettent de connecter des outils qui, sans elles, fonctionneraient en silos :
- Paiement en ligne : un site e-commerce appelle l'API d'un prestataire (type Stripe) pour encaisser une transaction sans gérer lui-même les données bancaires.
- Synchronisation CRM / ERP : une nouvelle commande créée dans l'ERP remonte automatiquement dans le CRM via API.
- Cartographie et géolocalisation : afficher une carte ou calculer un itinéraire en interrogeant l'API d'un fournisseur de cartes.
- Authentification : se connecter à un service via un compte tiers (Google, Microsoft) repose sur des API d'identité.
Pour une PME, l'enjeu n'est pas l'API en soi mais ce qu'elle permet : automatiser des tâches manuelles, éviter les doubles saisies et faire dialoguer des logiciels métier hétérogènes.
Les principaux types d'API web : REST et GraphQL
La majorité des API d'applications web s'appuie sur le protocole HTTP et ses méthodes standard (GET pour lire, POST pour créer, PUT/PATCH pour modifier, DELETE pour supprimer). Deux grandes approches dominent aujourd'hui pour structurer ces échanges.
| Critère | API REST | API GraphQL |
|---|---|---|
| Principe | Accès à des ressources via des URL dédiées (endpoints) | Un point d'entrée unique, le client décrit la donnée souhaitée |
| Récupération des données | Une ressource par requête, structure fixée par le serveur | Le client choisit précisément les champs renvoyés |
| Requêtes multiples | Souvent plusieurs appels pour des données liées | Une seule requête peut agréger plusieurs ressources |
| Sur/sous-récupération | Risque de recevoir trop ou pas assez de données | Limité : on ne récupère que ce qui est demandé |
| Maturité et écosystème | Standard historique, très largement adopté | Plus récent, adapté aux interfaces riches et mobiles |
REST reste le choix par défaut pour la plupart des projets, grâce à sa simplicité et son universalité. GraphQL devient pertinent lorsque les besoins en données sont variables ou que l'on veut limiter le nombre d'appels réseau, typiquement pour des applications mobiles ou des tableaux de bord complexes.
API privée, publique et critères de qualité
Toutes les API ne sont pas exposées au public. On distingue plusieurs niveaux d'ouverture selon les destinataires :
- API privée (interne) : utilisée uniquement entre les services d'une même organisation ou de son système d'information.
- API partenaire : ouverte à des partenaires identifiés, sous conditions contractuelles et techniques.
- API publique : accessible à des développeurs externes, souvent avec une clé d'accès et des quotas.
Quelle que soit sa nature, une API de qualité repose sur quelques fondamentaux : une documentation claire et à jour, une authentification (clés, jetons) et une gestion fine des droits, une gestion des erreurs explicite via les codes de statut HTTP, et un versionnage qui évite de casser les intégrations existantes lors des évolutions. Ces points conditionnent directement la maintenabilité d'une plateforme métier sur le long terme.
Questions fréquentes
Vous devez connecter vos outils ou exposer vos données ? Nous concevons des API robustes et sécurisées.
Voir nos logiciels sur mesureDéfinitions liées