Qu'est-ce qu'une API (interface de programmation d'applications) ?

Une API est un ensemble de règles qui permet à une application de demander des données et des fonctionnalités à une autre sans connaître son code interne. La fameuse analogie du restaurant — vous commandez sur un menu, la cuisine reste invisible — mérite sa phrase unique et rien de plus, parce que la réalité est plus instructive que la métaphore : une API est un contrat, et les contrats sont précis.

Points clés

Anatomie d’une requête et d’une réponse d’API HTTP

Aucune explication bien classée n’en montre une, alors voici un appel d’API entier — requête et réponse, rien de caché :

POST /classes/Todo HTTP/1.1              ← méthode + endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← identifie l'app qui appelle
Authorization: Bearer eyJhbGci…          ← authentifie l'utilisateur
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← statut : ça a marché, ressource créée
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }

Le même appel à travers un SDK — qui n’est rien d’autre que ce HTTP, enveloppé dans l’idiome de votre langage :

// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);

// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');

// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}

// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}

Comment fonctionne un appel d’API

Trois propriétés de cette boucle expliquent pourquoi les API font tourner le stack moderne. L’abstraction : l’appelant a besoin du contrat, jamais de l’implémentation — le fournisseur peut tout réécrire derrière l’interface sans casser un seul client. La frontière : la validation et les permissions vivent à l’interface, et c’est pourquoi les clients parlent aux API et jamais à la base de données directement — une API n’est pas une base de données ; c’est le gardien devant l’une d’elles. La composition : parce que chaque capacité est invocable, les applications s’assemblent à partir de services — l’auth ici, les paiements là, les cartes chez un tiers — et, de plus en plus, les agents IA utilisent le même substrat : le tool calling, c’est appeler des API avec un modèle qui décide des requêtes.

Le contrat : ce qu’une API promet vraiment

Les pages qui appellent une API « un contrat » en montrent rarement un. Aujourd’hui, le contrat est un document lisible par les machines — l’OpenAPI Specification est le standard pour les API HTTP — qui liste chaque endpoint, paramètre, schéma et code de statut. À partir de ce seul fichier, l’outillage génère la documentation de référence, les bibliothèques clientes, les stubs de serveur, les serveurs mock et les tests de contrat.

La notion de contrat prend tout son poids avec le versionnage. Ajouter un champ de réponse ne casse personne ; en renommer ou en supprimer un casse chaque consommateur en silence — c’est pourquoi les API matures distinguent les changements additifs des changements cassants, versionnent leur surface (/v1/, ou via des headers) et publient des fenêtres de dépréciation. Une API sans politique de changement est un contrat sans clauses : techniquement une promesse, en pratique une surprise.

Les types d’API

En forme de requête de recherche, parce que « types d’API » est une recherche à part entière : deux taxonomies, pas une.

Par audience :

Par style : REST (ressources à des URL, méthodes HTTP), GraphQL (requêtes façonnées par le client sur un seul endpoint), gRPC (binaire, contract-first, de service à service), SOAP (enveloppes XML, standards enterprise/legacy) et les API WebSocket (bidirectionnelles, persistantes) — comparés dans le tableau suivant.

Et un paragraphe que les explications du web sautent : toute API n’est pas une API web. La bibliothèque standard d’un langage, les appels système POSIX et les interfaces fetch et de géolocalisation intégrées au navigateur sont toutes des API — des contrats entre programmes — qui ne traversent jamais un réseau. La variante web n’a fait que mettre le contrat derrière une URL.

REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

Cas d’usage courants

• Backends mobiles et web — les données de chaque écran arrivent par une API ; le frontend ne touche jamais la base de données.
• Intégration de tiers — paiements, identité, messagerie, cartes : des capacités louées via des contrats plutôt que reconstruites.
• Communication entre microservices — les API internes comme frontières qui laissent les services se déployer et se mettre à l’échelle indépendamment.
• Automatisation et scripting — tout ce qui a une API peut être orchestré : pipelines de CI, infrastructure, flux de contenu.
• Agents IA et tool calling — les modèles agissent en invoquant des API ; un contrat bien documenté est désormais consommé deux fois par les machines : par les SDK et par les agents.

Quel style d’API devriez-vous choisir ? Matrice de décision

Limites et trade-offs

• Un contrat lie aussi le fournisseur. Chaque champ publié devient quelque chose dont quelqu’un dépend ; l’évolution passe par la discipline de versionnage, pas par des modifications silencieuses.
• Les API réseau héritent du réseau. La latence, les pannes partielles et les retries font partie de la sémantique de chaque appel distant — les appels de fonctions locaux n’ont jamais eu besoin de politiques de timeout.
• L’abstraction cache le coût. Un appel d’apparence innocente peut déclencher en cascade un travail coûteux ; les consommateurs voient le menu, pas l’addition de la cuisine — c’est à ça que servent les rate limits et les quotas.
• La surface de sécurité grandit avec la surface. Chaque endpoint est une porte ; les clés identifient mais n’autorisent pas, donc la vraie auth (tokens façon OAuth 2.0, permissions par utilisateur) et la validation des entrées sont le minimum syndical.
• Les formes fixes ne vont pas à tous les consommateurs. Les trade-offs d’overfetching/underfetching du design d’endpoints sont un sujet à part — voir l’entrée sœur.

Les API sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le geste qui définit tout : l’API est générée, pas construite — définissez un modèle de données et la plateforme l’expose immédiatement comme endpoints REST et schéma GraphQL — l’appel disséqué ci-dessus est le vrai format échangé par Back4app sur le réseau — avec des clés, des tokens d’utilisateur et des permissions au niveau des classes qui font respecter le contrat à la frontière. Les SDK consomment cette API idiomatiquement depuis chaque grande plateforme, et les opérations sur mesure deviennent des fonctions Cloud Code : de nouveaux endpoints dans un fichier, la même discipline de contrat, aucun serveur à opérer.