Pourquoi vos équipes contournent la plateforme

Le symptôme se découvre en général par accident : une API en production depuis des mois, exposée directement par son équipe, sans passer par la plateforme. L'équipe concernée n'est pas embarrassée, elle explique posément : « passer par la plateforme prenait trois semaines, on avait deux jours ».

La réaction classique est de rappeler la règle. Note d'architecture, comité, obligation réaffirmée. Cela ne change rien, et il faut comprendre pourquoi : le contournement n'est pas un problème de discipline, c'est un verdict sur le service rendu.

La plateforme est en concurrence

Une équipe de développement compare toujours deux chemins : exposer via la plateforme, ou exposer elle-même avec les outils qu'elle maîtrise, une route Gateway API et trois lignes de YAML.

Le second chemin prend une heure. Si le premier prend trois semaines, la règle d'architecture demande aux équipes de choisir volontairement un chemin cent fois plus long. Certaines le feront par civisme. Les autres feront ce que vous auriez fait à leur place.

On ne gagne pas cette concurrence par l'autorité. On la gagne en rendant le chemin officiel plus rapide que le contournement, ou au moins comparable. Tant que ce n'est pas vrai, chaque nouvelle règle augmente le stock d'API fantômes au lieu de le réduire.

D'où viennent les trois semaines

Le délai d'exposition se décompose toujours de la même façon, et la technique y pèse peu :

• un formulaire ou un ticket pour demander l'exposition, traité par une équipe centrale déjà saturée.
• des allers-retours sur le contrat OpenAPI, par mail, avec des règles découvertes au fil de l'eau.
• une configuration faite à la main par l'équipe plateforme, seule habilitée.
• une recette qui attend un créneau.

Chaque étape existe pour une bonne raison historique. Leur somme est un délai que plus personne ne défend, mais que personne n'a le mandat de réduire.

Mesurer le contournement avant de le combattre

On ne dimensionne pas un problème qu'on découvre par accident. L'ampleur réelle se recoupe en une journée, sans projet, à partir de sources qui existent déjà et dont aucune ne suffit seule.

Les enregistrements DNS publiés de votre zone, comparés aux noms d'hôte que sert la gateway : tout écart est une exposition qu'elle ignore. Les certificats émis pour vos domaines, qui racontent la même histoire et attrapent ce que le DNS interne ne montre pas. Les règles de filtrage entrantes ouvertes vers autre chose que la plateforme. Et le catalogue de services de vos équipes, confronté au catalogue d'API : les services appelés depuis un autre domaine et absents de la plateforme sont votre stock.

Le nombre obtenu n'a pas besoin d'être exact. Il a besoin d'être dit en comité, parce qu'il transforme une conversation sur la discipline en conversation sur le service rendu.

À quoi ressemble la version qui marche

Le modèle cible est connu : le libre-service gouverné. L'équipe qui possède l'API l'expose elle-même, par sa pipeline, et les règles deviennent des vérifications automatiques au déploiement, plutôt que des revues humaines en amont. L'équipe plateforme garde la main sur le socle et sur les règles, plus sur chaque API : elle passe de guichet à fournisseur d'outillage.

C'est le modèle décrit dans Industrialiser, et son indicateur de succès est un seul chiffre : le délai entre « l'API est prête » et « l'API est appelable en production ». Sous une journée, le contournement perd son intérêt.

Reste à savoir par quoi commencer, parce que ce modèle ne s'installe pas d'un coup.

Les quatre leviers, du plus rentable au plus long

Rendre les fonctions utiles évidentes. Rate limiting, validation de jeton, validation de schéma, circuit breaker : ce sont des choses que l’équipe devrait autrement écrire elle-même. Elles doivent s’activer en une ligne et se documenter comme des services rendus, pas comme des policies à configurer. C’est le levier qui retourne l’arbitrage, parce qu’il fait gagner du temps au lieu d’en coûter.

Livrer l’observabilité clé en main. Traces, latences décomposées, taux d’erreur par consommateur, disponibles sans rien brancher. Une équipe qui obtient gratuitement ce qu’elle aurait dû instrumenter cesse de se demander si la plateforme vaut le détour.

Simplifier l’exposition. Exposer une API ne doit demander ni langage propriétaire ni formation : un contrat dans le dépôt, un fichier déclaratif, une publication par la chaîne. Si exposer suppose d’apprendre le langage de policies d’un éditeur, l’équipe plateforme reste le passage obligé, donc le goulot.

Industrialiser la documentation. Elle se génère du contrat, elle ne se ressaisit pas dans un portail. Une documentation à écrire à la main est une raison de plus de ne pas passer par la plateforme, et le sujet est traité dans industrialiser.

Aucun des quatre ne relève de l’autorité. Ils déplacent la plateforme du statut d’obligation à celui de service, et un service utile ne se fait pas contourner.

Un cinquième facteur ne relève pas de l'outillage : beaucoup d'équipes contournent la plateforme parce qu'elles redoutent d'y perdre la maîtrise de leur mise en production. Il se traite en accompagnant une équipe sur son propre cas jusqu'à sa première API en production, jamais par un support de présentation.

Le chiffre par lequel commencer

Mesurez le délai d'exposition réel, aujourd'hui, sur la dernière API publiée. C'est le chiffre qui dit si vos règles d'architecture sont applicables ou décoratives. Tout le reste, gabarits, automates, accompagnement, se priorise à partir de lui.