# Concevoir une API qui tient en production
Une API peut très bien fonctionner en démonstration, puis devenir pénible à exploiter une fois utilisée par de vrais clients, de vrais services et de vrais cas d’erreur.
Le problème ne vient pas toujours du code principal. Il vient souvent de tout ce qui entoure l’API : les erreurs, les logs, les changements de contrat, les timeouts, les cas limites et la manière dont le système se comporte quand quelque chose ne se passe pas comme prévu.
Ce qui casse le plus souvent
Une API fragile n’est pas forcément une API qui plante tout le temps. C’est souvent une API difficile à comprendre, à faire évoluer ou à diagnostiquer.
Les problèmes reviennent souvent aux mêmes endroits :
- mélanger logique métier et validation HTTP
- ne pas versionner les changements cassants
- renvoyer des erreurs trop vagues
- ne pas tracer les appels critiques
- oublier les cas de concurrence
- ne pas prévoir les reprises après échec
- dépendre d’un service externe sans timeout clair
Ces détails semblent secondaires au début. Pourtant, ce sont eux qui font la différence entre une API correcte en local et une API supportable en production.
Ce qui aide vraiment
Une API robuste n’a pas besoin d’être complexe.
Elle a surtout besoin d’être lisible et prévisible.
Un schéma de données clair, des réponses cohérentes, des erreurs explicites, des logs exploitables et des timeouts bien définis suffisent déjà à éviter beaucoup de problèmes.
L’objectif n’est pas de prévoir tous les cas possibles. L’objectif est de rendre le comportement de l’API compréhensible quand un cas inattendu arrive.
En pratique
Une bonne API n’est pas seulement une API qui répond correctement quand tout va bien.
C’est une API que l’on peut tester, déboguer, surveiller et faire évoluer quand la charge augmente, quand les erreurs métier apparaissent et quand les intégrations réelles commencent à l’utiliser.
La vraie qualité d’une API se voit rarement dans la première démo.
Elle se voit au moment où il faut comprendre rapidement ce qui s’est passé, corriger sans casser le contrat existant et continuer à livrer sans rendre le système illisible.