Où en êtes-vous ?
Quatre stades de maturité en API management, trois questions factuelles pour se situer, ce qui fait passer au stade suivant, et le cas où une plateforme est inutile.
La maturité d’une organisation en API management ne se lit pas dans ce qu’elle a acheté, mais dans ce qui se passe quand quelque chose change : une API à publier, une policy à modifier, une version à retirer. Quatre stades reviennent, et ils ne se sautent pas, chacun corrige un problème créé par le précédent.
Les quatre stades
Dispersé. Des API existent, chaque équipe expose comme elle veut. Pas de catalogue, pas de policy commune, et personne ne peut donner le nombre d’API en production. C’est l’état de départ normal, pas une faute.
Centralisé. Une gateway est en place, une équipe la tient, le trafic passe par un point contrôlé. Le problème que ce stade crée : toute publication attend l’équipe plateforme, qui devient le goulot.
Industrialisé. Les contrats vivent dans les dépôts, la publication passe par la chaîne d’intégration, la console n’est plus un moyen de modifier la production. Les équipes publient seules dans un cadre. Le détail est dans industrialiser.
Piloté. La plateforme se mesure : délai jusqu’au premier appel réussi, taux d’erreur par consommateur, écart entre configuration déclarée et état réel. Les arbitrages s’appuient sur ces chiffres.
Se situer en trois questions
Les intentions et les feuilles de route ne comptent pas. Ces trois questions se répondent en regardant.
| Question | Lecture |
|---|---|
| Combien d’API en production, au juste ? | Si personne ne sait : dispersé |
| Combien de temps entre le commit d’un contrat et sa publication ? | Si la réponse passe par une demande à une autre équipe : centralisé |
| Quelles modifications manuelles en production le mois dernier ? | Si la liste existe : industrialisé |
La troisième question départage le mieux. Une chaîne d’intégration sans détection d’écart donne un chemin propre à côté d’un chemin manuel que personne ne surveille, et l’organisation se croit industrialisée à tort.
Passer au stade suivant
De dispersé à centralisé : inventorier. Un inventaire honnête tient sur une page et il est régulièrement plus mauvais que ce que la direction croit. C’est le livrable qui débloque le reste.
De centralisé à industrialisé : fermer le chemin manuel. Tant que l’équipe plateforme peut publier à la main, elle le fera sous pression, et la chaîne automatisée restera un chemin de secours. Le droit d’écrire en production se retire, il ne se décourage pas.
D’industrialisé à piloté : publier trois indicateurs. Le délai jusqu’au premier appel réussi, décrit dans découverte, suffit pour commencer.
L’erreur la plus coûteuse est le saut de stade : acheter l’outillage du stade suivant sans avoir traité le problème du stade courant. Une organisation dispersée qui s’équipe d’une plateforme complète obtient une plateforme vide. Une organisation centralisée qui déploie des tableaux de bord mesure un périmètre qui ne couvre pas la moitié du trafic réel.
Faut-il une plateforme d’API management ?
Pas systématiquement. Trois signaux justifient l’investissement : plus d’une dizaine d’API et plus de trois équipes consommatrices, des consommateurs hors du périmètre de confiance, partenaires ou public, ou une contrainte réglementaire de traçabilité des accès.
En dessous, un point d’entrée correctement configuré et des contrats OpenAPI tenus à jour couvrent le besoin pour une fraction du coût. Une plateforme installée trop tôt ajoute un composant à exploiter sans résoudre de problème existant, et l’équipe qui la porte passe son temps à justifier son usage.
Mis à jour en août 2026.