Qu'est-ce que l'API sprawl ? Définition, causes et remèdes

Qu'est-ce que l'API sprawl ?

L'API sprawl est la croissance incontrôlée des APIs au sein d'une organisation : le nombre d'APIs, de versions et d'endpoints augmente plus vite que la capacité de l'équipe à les repérer, documenter, sécuriser et retirer. Signes typiques : personne ne peut lister toutes les APIs en production, plusieurs équipes ont créé des endpoints quasi identiques et la sécurité en découvre d'undocumentés lors d'un audit. Le problème n'est pas d'avoir beaucoup d'APIs, mais beaucoup d'APIs non gouvernées.

Pourquoi cela arrive

Le sprawl est un effet secondaire de la croissance. Les microservices, les intégrations tierces, les outils internes, les backends mobiles, les APIs de partenaires et les anciens systèmes encore en service élargissent la surface d'APIs, et chaque équipe livre ce dont elle a besoin. Sans inventaire commun ni étape de revue, personne n'a la vue d'ensemble. Les APIs internes prolifèrent le plus vite, car elles sont moins examinées ; voir les APIs internes.

Les quatre formes de sprawl

Sprawl de documentation

Les APIs existent, mais leur documentation manque ou est périmée. Les développeurs cherchent le bon endpoint et la spécification OpenAPI ne correspond plus au code. Remède : générer la spécification à partir du code (ou l'inverse) et la contrôler en CI.

APIs en double ou qui se chevauchent

Trois équipes créent trois endpoints "créer un utilisateur" parce qu'aucune ne connaissait les autres, chacun avec une validation légèrement différente. Remède : un catalogue consultable et la règle de le consulter avant de construire du neuf.

APIs fantômes (shadow APIs)

Des APIs qui contournent la passerelle, la revue de sécurité ou le monitoring : parfois un endpoint de test arrivé en production, parfois un contournement délibéré. Ce sont la principale préoccupation de sécurité, car personne ne surveille leur authentification, leurs limites de débit ni leurs données. Remède : la découverte d'APIs à partir du trafic réel et des journaux de la passerelle, comparée au catalogue.

APIs zombies

Des APIs que plus personne n'appelle mais qui tournent toujours, demandent des correctifs et exposent des données. Remède : des données d'usage par endpoint et un processus de retrait ordonné ; voir la dépréciation d'API.

Pourquoi l'API sprawl coûte cher

• Exposition de sécurité : les APIs non gouvernées risquent davantage de n'avoir ni authentification, ni limitation de débit, ni validation des entrées. Voir la sécurité des APIs.
• Travail en double : un bug corrigé dans une copie reste ouvert dans les autres.
• Intégration plus lente : les nouveaux arrivants apprennent ce qui existe auprès des collègues plutôt que dans un catalogue.
• Risque de conformité : les audits demandent où circulent les données personnelles, et on ne peut pas répondre pour des APIs que l'on ignore.
• Coût d'exploitation : chaque service en marche consomme du calcul et du budget d'observabilité, y compris ceux que personne n'utilise.

Comment reprendre le contrôle

1. Un seul catalogue. Un registre unique de toutes les APIs avec propriétaire, spécification et statut. Construisez-le à partir du code ou du trafic de la passerelle, car les listes tenues à la main se périment.
2. Passer par une passerelle. Une entrée centrale garde la trace de chaque API et de chaque consommateur.
3. Écrire d'abord le contrat. Relire la spécification avant de coder, comme dans l'approche API-first.
4. Mesurer l'usage par endpoint. Zéro trafic pendant une durée fixée déclenche une revue de dépréciation.
5. Fixer des règles d'entrée. Une nouvelle API exige une entrée de catalogue, une spécification, une authentification et un propriétaire nommé avant de recevoir du trafic.

API sprawl et monitoring

Un catalogue dit ce qui devrait exister ; le monitoring d'API dit si cela fonctionne. Le monitoring d'API de LoadFocus peut importer une spécification OpenAPI 3.x ou Swagger 2.0 et crée un moniteur par opération : une API cataloguée reçoit ainsi des contrôles de disponibilité, de code de statut et de temps de réponse, avec des alertes vers l'e-mail, Slack, Microsoft Teams, Discord, PagerDuty, Opsgenie ou un webhook générique. Cela couvre les APIs que vous connaissez ; cela ne trouve pas les inconnues, ce qui relève de la découverte et des journaux de la passerelle. Pour choisir des outils, voir les meilleurs outils de monitoring d'API et comment le monitoring d'API aide votre activité (en anglais).

Erreurs courantes

• Interdire les nouvelles APIs. Les équipes contournent l'interdiction. Faites plutôt du chemin gouverné le chemin facile.
• Un catalogue que personne ne met à jour. Un catalogue périmé est pire que rien, car on lui fait confiance.
• Compter au lieu de gouverner. Suivez la part du trafic de production qui passe par des APIs cataloguées, pas le nombre total.
• Oublier les APIs non REST. GraphQL, gRPC, webhooks et APIs d'événements font partie de la surface.
• Ignorer les APIs tierces. Les APIs externes dont vous dépendez ont aussi leur place dans le catalogue.
• Laisser tourner les anciennes versions. Sans date d'extinction, v1, v2 et v3 restent toutes en vie.

Questions fréquentes : API sprawl

Combien d'APIs, c'est trop ?

Ce n'est pas le nombre qui pose problème, mais la capacité à les retrouver et à les gouverner. Un bon indicateur est la part du trafic de production qui passe par des APIs cataloguées et attribuées à un propriétaire.

L'API sprawl est-il réservé aux microservices ?

Non. Les monolithes aussi en souffrent, via des modules internes, des endpoints non documentés et des scripts qui en dépendent. Les microservices aggravent le phénomène, car chaque service est une surface d'API de plus.

Quelle différence avec la dette technique ?

C'est une forme précise de dette technique, où la surface d'APIs croît plus vite que la capacité à la gouverner. La dette technique recouvre aussi le code, les frameworks et l'architecture obsolètes.

Comment repérer les APIs fantômes ?

En comparant ce que dit le catalogue avec ce qui reçoit réellement du trafic, à l'aide des journaux de la passerelle, du répartiteur de charge ou d'une analyse passive du trafic, puis en demandant aux équipes de revendiquer ou de retirer chaque endpoint inconnu.

Quel lien entre versionnage d'API et sprawl ?

Chaque version active est une API de plus à sécuriser et à maintenir. Publiez une fenêtre de dépréciation pour chaque version et tenez-la.