Une API (Application Programming Interface) est un intermediary logiciel qui permet à deux applications de communiquer. Elle définit les règles (endpoints, formats de données, méthodes HTTP) pour qu'un programme puisse demander et recevoir des informations sans connaître le fonctionnement interne de l'autre.
Les APIs sont le ciment numérique du web moderne. Types principaux : (1) REST — le standard dominant, utilise HTTP (GET, POST, PUT, DELETE) et retourne du JSON. Exemple : GET /api/products?category=shoes retourne la liste des produits, (2) GraphQL — le client demande exactement les champs nécessaires (requête unique vs plusieurs endpoints REST), (3) Webhook — l'API vous notifie quand un événement se produit (ex: nouveau paiement Stripe), (4) SOAP — protocole plus ancien, encore utilisé en finance. Les APIs sont mesurées en : latence (temps de réponse, target< 200ms), disponibilité (SLA99.9% = 8h downtime/an), et rate limiting (nombre de requêtes/minute autorisé).
Une API, c'est comme un serveur dans un restaurant. Vous (votre application) n'entrez pas dans la cuisine. Vous passez commande au serveur (l'API), qui apporte votre plat (la réponse). Vous n'avez pas besoin de savoir comment le chef prépare votre steak — vous recevez juste ce que vous avez demandé, dans un format que vous comprenez. Et si le serveur est trop lent ou reçoit trop de commandes, il vous dit « désolé, trop de monde, revenez plus tard » (rate limiting).
L'endpoint est l'adresse URL qui expose une fonctionnalité. Les méthodes HTTP définissent l'action : (1) GET — récupérer des données (lecture, idempotent), (2) POST — créer une ressource (nouveau produit, nouvel utilisateur), (3) PUT/PATCH — mettre à jour (PUT = remplacement complet, PATCH = mise à jour partielle), (4) DELETE — supprimer. Exemple Stripe : POST /v1/charges (créer un paiement), GET /v1/charges/:id (récupérer un paiement). Un endpoint mal conçu est la première source de dette technique.
Qui a le droit d'appeler l'API ? Méthodes : (1) API Key — chaîne secrète dans le header, simple mais non révocable par token individuel, (2) OAuth 2.0 — protocole d'autorisation avec jetons d'accès (access token) et refresh tokens, idéal pour les apps tierces, (3) JWT (JSON Web Token) — token signé contenant des claims (utilisateur, rôle, expiration), auto-contenu et vérifiable sans appel DB. Le principe du moindre privilège : chaque API key doit avoir les permissions minimales nécessaires.
Les APIs imposent des limites pour protéger les serveurs. Standard :N req/min ou req/second. Exemples : (1) Stripe — 25 req/s默认, expandable, (2) OpenAI — 3 RPM (requests per minute) sur GPT-4o tier gratuit, 500 RPM sur Enterprise, (3) Google Maps — 50$/mois pour 40000 req/mois. Quand la limite est atteinte : réponse429 Too Many Requests. Monitoring essentiel : latence p95 (le95e percentile détermine l'expérience de5% des utilisateurs les plus lents), uptime (pourcentage de disponibilité).
Une startup SaaS B2B intégre l'API Stripe pour les paiements. Étape 1 : lecture de la documentation Stripe (2h) + génération de la API key test. Étape 2 : implémentation de la création de Payment Intent (POST /v1/payment_intents) + Webhook pour confirmer le paiement. Étape 3 : intégration du dashboard billing (GET /v1/charges). Résultat : 6 jours de développement pour un système de paiement complet. L'erreur常见 : ne pas gérer le rate limit — eniks1000 req/jour, avec bursts à 50 req/min lors des pics. Solution : file d'attente avec rate limiter côté client. Taux de conversion paiement : +12% après optimisation du checkout.
| Métrique | Valeur |
|---|---|
| Latence cible (bon) | < 200ms |
| SLA 99.9% downtime/an | 8.7h/an |
| Rate limit OpenAI gratuit | 3 RPM (GPT-4o) |
| Retry backoff standard | 1s, 2s, 4s, 8s (exponentiel) |
| Code erreur rate limit | 429 Too Many Requests |
| Temps intégration Stripe | 6 jours (MVP complet) |