· Par Youssef Oubihi
- api
- architecture
- stratégie
La plupart des organisations que nous rencontrons ont déjà une plateforme d'API management. Peu ont une stratégie API. La différence n'est pas sémantique : elle se lit dans le taux d'adoption des interfaces publiées, et il est souvent proche de zéro.
Le symptôme habituel
Une direction technique achète une plateforme, publie une trentaine d'interfaces issues du catalogue applicatif existant, et constate dix-huit mois plus tard que trois d'entre elles sont réellement consommées. Les vingt-sept autres exposent des modèles internes que personne d'extérieur ne sait interpréter.
Le problème n'est pas l'outil. Il est en amont : on a exposé ce qui existait plutôt que ce dont quelqu'un avait besoin.
Trois décisions qui déterminent la suite
Qui est le consommateur. Une API destinée à une équipe interne, à un partenaire contractuel ou à un développeur inconnu ne se conçoit pas de la même manière. Le niveau de documentation, la stabilité du contrat et le modèle de sécurité en découlent directement. Ne pas trancher revient à concevoir pour le plus exigeant des trois, au prix du plus simple.
Quel modèle de domaine on expose. Une API qui projette la structure de la base de données transfère la complexité interne au consommateur. Elle sera contournée. Le travail de conception consiste précisément à construire un modèle d'exposition distinct du modèle de stockage — et c'est un travail métier, pas technique.
Qui possède le contrat. Une interface sans propriétaire identifié dérive. La question n'est pas de savoir quelle équipe l'héberge, mais qui a l'autorité pour refuser une évolution qui casserait ses consommateurs.
Ce que cela change concrètement
Une organisation qui a tranché ces trois points publie moins d'interfaces, plus tard, et obtient une adoption mesurablement supérieure. La plateforme redevient ce qu'elle est : un outil d'exécution, pas une stratégie.