API-first : construire un logiciel qui survit à son propre succès

28 août 2026

L'interface que vous construisez aujourd'hui sera remplacée. Le modèle de données et l'API derrière, non. Construisez en conséquence.

Du code à l'écran représentant une intégration d'API

La plupart des logiciels métier sont construits interface d'abord : on dessine les écrans, puis on écrit ce dont les écrans ont besoin. Cela livre plus vite et fonctionne très bien jusqu'à l'apparition du deuxième consommateur — une application mobile, une intégration partenaire, une automatisation — et là, il n'y a rien à consommer, car la logique vit dans les écrans.

Ce que signifie vraiment API-first

Définissez les opérations que votre système réalise — créer un devis, valider une commande, récupérer l'historique d'un client — comme une interface aux entrées et sorties claires, avant de décider de l'allure du moindre écran. L'interface web devient alors un consommateur parmi d'autres, sans privilège particulier. C'est le raisonnement derrière notre façon de cadrer et construire des applications web, et la raison pour laquelle le cadrage vient en premier.

Ce que cela apporte

Les intégrations deviennent de la configuration plutôt que des projets. Quand un client demande à connecter sa comptabilité, la réponse est une journée, pas un trimestre.
L'interface peut être remplacée sans toucher à la logique métier — ce qui compte, car les interfaces sont refaites environ tous les trois ans et la logique non.
L'automatisation devient possible sans extraction d'écran ni script ponctuel écrit par un développeur à chaque demande.
Les tests coûtent nettement moins cher : les règles métier sont testables sans navigateur.

Bien le faire sans dorure

Concevez autour des opérations métier, pas des tables de base de données. « Valider une commande » est une opération ; « modifier le champ statut » est un détail d'implémentation qui fuit dans votre contrat.
Versionnez dès le premier jour, même en v1. Ajouter un versionnement après coup sur une intégration en production est douloureux et public.
Renvoyez des erreurs sur lesquelles une machine peut brancher et qu'un humain peut lire. Les deux publics comptent, et la plupart des API n'en servent aucun correctement.
Documentez au fil de la construction. Une API non documentée est une API privée, quelles qu'aient été vos intentions.

3 ans durée de vie typique d'une interface
1 opération métier par point d'entrée
2 consommateurs, le seuil de rentabilité

Questions fréquentes

L'approche API-first ralentit-elle la première version ?

Modérément : typiquement dix à vingt pour cent d'effort supplémentaire sur la première version. Ce coût est récupéré dès l'ajout d'une seconde interface ou intégration, et il compose ensuite.

REST ou GraphQL ?

Pour la plupart des applications métier, REST avec des ressources bien conçues est plus simple à construire, mettre en cache et déboguer. GraphQL justifie sa complexité quand de nombreux clients différents ont besoin de formes très différentes des mêmes données — un vrai problème, mais pas le plus courant.