La demande arrive sous des formes variées : ouvrir les données à une application mobile, connecter un outil d'automatisation, brancher un partenaire externe, alimenter un portail client. La réponse classique est souvent la même : « ça va nécessiter un chantier ».
Ce chantier dure des mois parce que les données sont enfouies au cœur d'un système qu'on ne touche pas sans risque. La logique métier, la persistance et la présentation sont emmêlées. Ajouter un usage revient à réécrire une partie du cœur.
L'approche API-first résout ce problème. Ce n'est pas un framework, pas une réécriture, pas une migration vers des microservices. C'est une décision de conception : les capacités métier sont modélisées comme des API avant d'être consommées, y compris par les équipes internes.
Ce que « API-first » signifie concrètement
Un SI conçu de façon classique sépare mal les couches. La logique métier vit parfois dans la base de données, parfois dans le backend, parfois dans le frontend. Quand on veut exposer une capacité, il faut d'abord comprendre où elle se trouve, puis l'extraire sans casser l'existant.
Un SI API-first part du principe inverse : chaque capacité est d'abord modélisée comme une API. Pas nécessairement exposée publiquement, mais conçue comme si elle devait l'être. Cela oblige à clarifier trois questions avant d'écrire la moindre ligne de code : qu'est-ce qu'on expose, pour qui, et sous quel contrat.
Ces questions semblent techniques. En pratique, elles forcent une décision métier que la plupart des SI n'ont jamais formalisée : qui possède quelle donnée, et sous quelles conditions peut-elle circuler ?
Pourquoi le SI résiste aux nouveaux usages
Les SI qui bloquent les nouveaux usages n'ont pas été mal conçus au départ. Ils ont été conçus pour un contexte qui a changé.
Quand le système a été construit, l'application web interne était le seul consommateur prévu. La base de données était le contrat implicite. Les équipes en connaissaient le schéma et écrivaient des requêtes directes. Ça fonctionnait.
Dix ans plus tard, les consommateurs se sont multipliés : une application mobile, un connecteur vers le CRM, un outil de reporting, un partenaire externe. Chacun a été branché à sa façon, souvent en accédant directement à la base ou en contournant la logique métier par des exports planifiés. Le résultat est une toile de dépendances implicites qu'on ne peut plus démêler sans risque.
Ce n'est pas de la dette technique au sens habituel. C'est l'absence de couche contractuelle entre le cœur du système et ses consommateurs. Personne ne sait précisément ce que chaque consommateur utilise, ni comment.
Exposer les données sans réécrire le cœur
Passer à une logique API-first ne nécessite pas de réécrire le système existant. Cela nécessite d'y ajouter une couche.
Cette couche, parfois appelée façade d'API, sert d'intermédiaire entre le cœur du système et ses consommateurs. Elle traduit, contrôle, versione et documente. Elle cache la complexité interne derrière un contrat stable.
Identifier les flux qui ont de la valeur
La première étape n'est pas de tout exposer. C'est de choisir les flux qui alimentent les usages nouveaux envisagés. Un portail partenaire a besoin des commandes et des statuts de livraison, pas de la comptabilité analytique. Partir du besoin du consommateur, pas de la structure du SI.
Définir le contrat avant d'implémenter
Un contrat d'API précise la structure des requêtes et des réponses, les codes d'erreur, les règles de pagination, le versioning. Ce contrat se documente dans une spécification OpenAPI. Les équipes consommatrices peuvent travailler en parallèle dès que le contrat est signé, sans attendre l'implémentation.
Implémenter en lecture seule d'abord
Exposer les données en lecture est toujours moins risqué qu'exposer des actions en écriture. Un portail client qui affiche les commandes via API ne peut pas corrompre les données métier. C'est le point de départ le plus sûr. L'écriture vient au périmètre suivant, en commençant par les actions les moins sensibles.
Gouverner les API comme des produits
Le principal écueil d'un projet API-first n'est pas technique : c'est la gouvernance.
Une API sans propriétaire se dégrade vite. Les consommateurs ajoutent des dépendances implicites sur des champs internes. Une équipe modifie un schéma sans prévenir. Un partenaire externe envoie des requêtes à un débit qui sature le système. Ces situations arrivent quand personne n'a de responsabilité explicite sur l'API.
Traiter une API comme un produit, c'est lui donner un propriétaire, une version, un cycle de vie et des métriques. Le propriétaire répond des contrats signés avec les consommateurs. La version garantit que les consommateurs existants ne cassent pas quand le schéma évolue. Le cycle de vie définit quand une version ancienne sera dépréciée. Les métriques révèlent qui utilise quoi, avec quelle fréquence, avec quel taux d'erreur.
Sans cette gouvernance, une architecture API-first produit une dette différente de la précédente mais tout aussi réelle : une prolifération d'endpoints non documentés, des versions qu'on ne peut pas déprécier parce que personne ne sait si quelqu'un les utilise encore.
Par où commencer quand le SI a dix ans de dette
La question que les DSI posent le plus souvent est pratique : par où commencer quand le SI existant est un monolithe de dix ans avec peu de documentation ?
La réponse tient en trois étapes.
La première est de cartographier les flux existants, pas l'architecture complète du SI, seulement les flux qui alimentent les usages prioritaires. Quels systèmes parlent à quels autres, sous quelle forme, à quelle fréquence ? Cette cartographie révèle les dépendances implicites et identifie les flux candidats à une exposition API.
La deuxième est de choisir un flux pilote : un flux qui a de la valeur pour au moins un consommateur nouveau, dont la logique est relativement délimitée, et dont l'équipe propriétaire est disponible. Un portail partenaire en lecture sur les statuts de commande est souvent un bon candidat.
La troisième est d'implémenter la façade sur ce flux uniquement. Pas un projet d'API platform complet. Un seul flux, un seul consommateur, un contrat OpenAPI documenté. Le temps de livraison doit se compter en semaines, pas en mois. L'objectif est de valider l'approche et de créer un précédent que les autres équipes peuvent imiter.
Ce que Drupal change dans cette équation
Pour les organisations qui opèrent un portail, un extranet ou une plateforme de contenu, Drupal en architecture headless s'intègre directement dans une logique API-first. Son module JSON:API expose les entités de contenu sous forme d'endpoints REST normalisés. Son module REST Views permet d'exposer des données agrégées sans écrire un endpoint custom. Son système de permissions contrôle finement ce que chaque consommateur peut lire ou écrire.
Drupal ne porte pas seul la couche API, mais dans ce contexte il réduit la surface à développer : les endpoints de base existent, les règles d'authentification s'appuient sur les rôles existants, et les migrations s'inscrivent dans le même système. Pour un portail B2B, cette architecture réduit la dette technique dans la durée.
Un SI API-first n'est pas un SI réécrit. C'est un SI qui a décidé de traiter ses données comme des actifs à exposer plutôt que comme des états internes à protéger. Cette décision change la nature des projets qui suivent : brancher un nouveau consommateur prend des jours, pas des mois.