---
term: "API (Interface de Programmation d'Applications)"
seoTitle: "Qu'est-ce qu'une API ? Interface de programmation d'applications"
headline: "Qu'est-ce qu'une API (interface de programmation d'applications) ?"
slug: api
category: api-realtime
shortDefinition: '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.'
relatedTerms:
  - rest-api
  - graphql-vs-rest
  - backend-sdk
  - auto-generated-database-apis
  - api-gateway-architecture
contrastsWith:
  - backend-sdk
faq:
  - question: 'Que signifie API ?'
    answer: "Application Programming Interface — en français, Interface de Programmation d'Applications. « Application » désigne tout logiciel avec une fonction propre ; « interface », le contrat entre deux d'entre eux — l'ensemble défini de requêtes que l'un peut faire et des réponses que l'autre promet de renvoyer. La partie programmation est le point clé : c'est une interface pour le logiciel, là où une UI est une interface pour les humains."
  - question: "Qu'est-ce qu'une API en termes simples ?"
    answer: "Un messager avec un menu. Un programme expose une liste de choses qu'il sait faire — récupérer ces données, exécuter cette action — et d'autres programmes les invoquent via des requêtes définies, sans jamais voir comment le travail se fait à l'intérieur. L'illustration classique : une app météo ne mesure pas le ciel ; elle appelle l'API d'un service météorologique."
  - question: 'Comment fonctionne une API ?'
    answer: "Par requête et réponse. Le client envoie une requête à un endpoint — une URL qui nomme la ressource — avec une méthode qui énonce l'intention, des headers qui portent métadonnées et identifiants, et parfois un corps de données. Le serveur la valide, fait le travail et renvoie un code de statut plus un corps de réponse, généralement du JSON. Chaque intégration que vous avez utilisée se réduit à cette boucle."
  - question: "Quels sont des exemples d'API ?"
    answer: "La connexion via un fournisseur d'identité, l'étape de paiement d'un checkout, une carte intégrée dans une app de livraison, un widget météo — chacun est une application qui appelle l'API d'une autre. Les exemples côté développeur sont encore plus directs : une plateforme backend qui expose votre base de données sous forme d'endpoints HTTP que votre app mobile interroge."
  - question: "Quelle est la différence entre une API et un SDK ?"
    answer: "L'API est le contrat ; un SDK est une boîte à outils pour le consommer. Un SDK enveloppe les appels d'API dans des fonctions idiomatiques de votre langage et ajoute la gestion de session, les retries et les types. Une API s'appelle sur le réseau ; un SDK s'importe dans votre code — et sous le capot, le SDK fait des appels d'API."
  - question: "Quels sont les types d'API ?"
    answer: "Par audience : publiques (ouvertes à tout développeur), partenaires (partagées avec des entreprises sous contrat), internes (privées à une organisation) et composites (regroupant plusieurs appels). Par style : REST, GraphQL, gRPC, SOAP et API WebSocket. Et au-delà du web : les API de bibliothèques et de systèmes d'exploitation — les interfaces existaient bien avant que HTTP ne les transporte."
  - question: "Qu'est-ce qu'un endpoint d'API ?"
    answer: "L'URL spécifique où une API reçoit les requêtes pour une ressource — /users/42 est l'endpoint de l'utilisateur 42. Endpoint plus méthode définissent une opération : GET /users/42 le lit, DELETE /users/42 le supprime. Les endpoints sont la surface adressable de toute l'interface."
  - question: "Qu'est-ce qu'une clé d'API ?"
    answer: "Une chaîne générée que le client envoie avec chaque requête pour que le fournisseur identifie l'appelant, mesure l'usage et applique limites ou révocation. C'est davantage de l'identification que de l'autorisation — les API de production superposent une vraie authentification, comme des tokens émis via OAuth, pour les permissions par utilisateur."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API — MDN Web Docs glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
  - name: 'OpenAPI Specification'
    url: 'https://spec.openapis.org/oas/latest.html'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
    url: 'https://www.rfc-editor.org/rfc/rfc6749'
  - name: 'API — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/API'
cta:
  title: 'Votre backend, déjà une API'
  text: "Définissez un modèle de données sur Back4app et la plateforme génère les API REST et GraphQL correspondantes — endpoints, auth et permissions compris — avec des SDK qui les parlent idiomatiquement depuis chaque grande plateforme."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-08'
translationKey: api
---

**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

| Question | Réponse |
| --- | --- |
| La définition | Un contrat requête/réponse défini entre deux programmes |
| La boucle | Endpoint + méthode + headers + corps → code de statut + réponse |
| Par audience | Publique · partenaire · interne · composite |
| Par style | REST · GraphQL · gRPC · SOAP · WebSocket |
| Le contrat moderne | Une spec lisible par les machines (OpenAPI) qui génère docs, clients et mocks |

## 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é :

```text
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:**

```javascript
// 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
// 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}');
```

**Swift:**

```swift
// 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 ?? "")") }
}
```

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: La boucle de requête et réponse d'une API
  accDescr: Une application cliente envoie une requête avec méthode, endpoint, headers et corps à une API, qui la valide et l'autorise, invoque la logique backend et les données, et renvoie un code de statut avec un corps de réponse au client.
  C["App cliente<br/>(web, mobile, autre serveur)"] -->|"requête :<br/>méthode + endpoint + headers + corps"| A["API<br/>valide · autorise · route"]
  A --> B["Logique backend<br/>+ base de données"]
  B --> A
  A -->|"réponse :<br/>code de statut + JSON"| C
```

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](/glossary/fr/securite-couche-donnees-vs-application/) vivent à l'interface, et c'est pourquoi les clients parlent aux API et jamais à [la base de données](/glossary/fr/nosql-vs-sql/) 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](https://spec.openapis.org/oas/latest.html) 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 :**

| Type | Consommateurs | Préoccupations typiques |
| --- | --- | --- |
| Publique (ouverte) | Tout développeur inscrit | Clés, quotas, qualité des docs, discipline de versionnage |
| Partenaire | Entreprises sous contrat | Accords juridiques, SLA, auth plus stricte |
| Interne (privée) | Vos propres équipes et services | Contrats entre microservices, cycles de changement plus rapides |
| Composite | Clients ayant besoin de lots | Un appel qui en orchestre plusieurs — moins d'allers-retours |

**Par style :** [REST](/glossary/fr/api-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](/glossary/fr/websockets/)) — 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

| Style | Format sur le fil | Modèle | Point fort | Attention à |
| --- | --- | --- | --- | --- |
| REST | JSON sur HTTP | Ressources + méthodes | API CRUD publiques, cacheabilité, ubiquité | Over/underfetching sur des formes fixes |
| GraphQL | JSON sur HTTP | Requêtes composées par le client | Clients divers, données imbriquées | Complexité du cache, N+1 des resolvers |
| gRPC | Protobuf sur HTTP/2 | Appels de procédures typés | Vitesse interne de service à service | Friction navigateur, débogage binaire |
| SOAP | Enveloppes XML | Opérations + standards WS-* | Enterprise legacy, contrats formels | Verbosité, poids de l'outillage |
| WebSocket | Frames sur un socket | Messages bidirectionnels | Push temps réel, présence | Le protocole, c'est vous qui le définissez |

## 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

| Votre situation | Choisissez |
| --- | --- |
| CRUD public sur des ressources | REST — la lingua franca, amie du cache |
| Beaucoup de types de clients, chacun avec ses formes | Les selection sets de GraphQL |
| Maillage interne de services à haut débit | Des contrats gRPC |
| Temps réel, bidirectionnel, toujours connecté | WebSocket (ou une couche de live queries au-dessus) |
| Partenaire enterprise avec exigences WS-* | SOAP — parce que le contrat le dit |
| Un écran qui a besoin de cinq services | Un endpoint composite ou un backend-for-frontend |

## 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](/glossary/fr/rate-limiting-api/) 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](https://www.rfc-editor.org/rfc/rfc6749), 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](/glossary/fr/overfetching-et-underfetching/).

## 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](/glossary/fr/apis-generees-automatiquement/) — 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](/glossary/fr/sdk-backend/) 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.