Un golden path est un cas d'usage, pas un composant

Dans toute initiative de plateforme interne, la même question revient : un golden path, est-ce un service tout-en-un ou une pièce de puzzle que chaque équipe assemble ? Voici quelques apprentissages de terrain sur cette question de granularité, y compris quand la plateforme est répartie entre plusieurs équipes.

Le débat revient dans presque toutes les initiatives d'Internal Developer Platform (IDP). D'un côté, ceux qui veulent proposer des chemins complets : « je veux une application web avec sa base de données », et la plateforme livre l'ensemble, prêt à l'emploi. De l'autre, ceux qui préfèrent un catalogue de briques : une base, un bucket, un namespace, une identité, et chaque équipe compose ce dont elle a besoin. Les deux camps veulent exactement la même chose, standardiser et accélérer. Pourtant, ils dessinent des plateformes opposées.

Ce qui suit n'est pas une doctrine. Ce sont quelques apprentissages accumulés en accompagnant ce type de projet, confrontés à ce que disent les sources de référence du platform engineering. La plupart valent pour toute plateforme interne ; l'un d'eux concerne un cas plus particulier, celui où le portail développeur et l'expertise technique sont tenus par des équipes différentes.

Deux niveaux, pas deux camps

Le premier apprentissage tient en une phrase : un golden path est un cas d'usage, pas un composant. Le débat « tout-en-un ou puzzle » vient souvent de ce qu'on mélange deux niveaux qui coexistent légitimement dans une plateforme.

Le premier niveau, ce sont les capabilities : des briques composables et réutilisables, chacune avec son propre contrat, possédées par l'équipe qui en détient l'expertise. Une base de données managée, un bucket, une identité de workload. Le second niveau, ce sont les golden paths : un besoin récurrent, couvert par un assemblage de capabilities décidé et testé à l'avance, avec un seul cycle de vie, et possédé par la plateforme. Le puzzle existe bien, mais à l'intérieur de la plateforme. L'utilisateur final reçoit l'image, pas les pièces.

C'est d'ailleurs le choix de Spotify, à qui l'on doit le terme. Dans l'article de 2020 qui l'a popularisé, l'entreprise décrit un golden path par discipline d'ingénierie (backend, web, data, machine learning…). Elle explique avoir envisagé une approche plus modulaire, un tutoriel par tâche, avant de s'en tenir aux disciplines. Pour un humain, la cohérence d'un parcours complet l'emporte sur un catalogue d'étapes à enchaîner soi-même.

Team Topologies en donne la raison de fond : la plateforme existe pour réduire la charge cognitive des équipes qui livrent les produits. Savoir comment obtenir une base, un secret ou un pipeline n'est pas leur métier, et leur exposer des briques brutes leur renvoie exactement cette charge.

Le cycle de vie fournit un argument plus terre à terre. Une application bâtie sur cinq briques consommées séparément, ce sont cinq cycles de vie à câbler : dépendances, ordre de création, mises à jour, suppression. Un golden path composé, c'est une demande, un propriétaire, un cycle de vie. Créer, faire évoluer et décommissionner deviennent une opération au lieu de cinq à coordonner. Kaspar von Grünberg le formulait à PlatformCon 2023 : il faut construire les golden paths pour le jour 50, pas pour le jour 1. L'échafaudage initial ne représente qu'une petite part de la vie d'une application.

Déléguer l'assemblage multiplie la décision

Pourquoi le catalogue de briques est-il si tentant ? Souvent parce qu'il évite une conversation difficile. Définir trois à cinq cas d'usage cibles, c'est arbitrer : ce que la plateforme couvre, ce qu'elle ne couvre pas, quelles options elle propose. Quand une organisation n'y parvient pas, la voie de moindre résistance consiste à laisser chaque projet assembler lui-même ses briques dans le portail. Cela ressemble à de la flexibilité.

La décision d'architecture n'est pourtant pas évitée. Elle est prise N fois, par N équipes, avec moins de contexte que l'équipe plateforme n'en aurait eu. La plateforme se retrouve à maintenir N assemblages uniques, dont aucun n'a été testé comme un tout. La conformité dépend de chaque assemblage au lieu d'être construite dans le pattern, et l'exploitation comme le décommissionnement deviennent le problème de tout le monde. Ce que Spotify appelait le « rumour-driven development », où la seule façon de savoir comment faire est de demander à un collègue, revient par la petite porte.

L'effort est faible au départ, puis sans limite. Le rôle de la plateforme est précisément de prendre cette décision une fois, de bien la prendre et de la maintenir. Définir peu de patterns est difficile ; ne pas les définir, c'est laisser chaque projet définir le sien.

Composer là où vit l'expertise

Les deux premiers apprentissages valent quelle que soit l'organisation. Celui-ci concerne une situation plus particulière : le portail développeur et l'expertise technique (infrastructure, identité, sécurité, middleware) sont tenus par des équipes différentes, parfois dans des directions différentes. Ce n'est ni la situation idéale, ni la plus simple. La littérature raisonne le plus souvent avec une équipe plateforme qui porte l'expérience de bout en bout, et c'est le modèle à viser quand on a le choix. On ne l'a pas toujours : dans beaucoup de grandes organisations, chaque domaine technique a déjà son équipe. Une question se pose alors vite : si le portail compose les golden paths, qui compose quoi ? Dans cette situation, il peut être utile de distinguer deux niveaux de composition, et donc deux niveaux de golden paths, chacun placé là où vit l'expertise.

Le livre blanc du CNCF sur les plateformes appelle ces équipes des capability providers : des fournisseurs de capabilities, qui peuvent être internes à l'entreprise. Ces fournisseurs composent leurs services unitaires (modules Terraform, ressources cloud) en golden paths de domaine : opinionated, conformité embarquée, avec leur propre contrat et leur propre cycle de vie. Vu du portail, ce sont des capabilities ; vu de l'équipe qui les construit, ce sont déjà des golden paths, le chemin supporté pour obtenir, par exemple, une base de données conforme. Un module brut, lui, est une brique, pas un contrat : il n'a ni schéma d'API, ni cycle de vie, ni policy, ni retour d'état. Une Composite Resource Crossplane, en revanche, est exactement un contrat : une API sur mesure qui n'expose que les champs choisis et fixe le reste.

Le portail compose ensuite ces golden paths de domaine en golden paths end-user, qui traversent plusieurs domaines et dont il maîtrise ce que voit l'utilisateur final. Chaque niveau cache la topologie du niveau inférieur : l'utilisateur ne voit jamais les modules, le portail ne câble jamais de ressources cloud.

Reste le contrat entre le portail et les fournisseurs. Le portail a raison de vouloir un protocole unique vers tous les fournisseurs : même adressage, même identité, même corrélation des demandes, même cycle de statut. Le piège est d'aller plus loin et d'uniformiser aussi le contenu dans un format commun, à plat et non typé.

Ce format nivelle tous les fournisseurs vers le plus petit dénominateur commun : tout ce que le schéma d'un fournisseur savait valider et documenter est perdu à l'entrée. Il impose un convertisseur implicite par fournisseur, à l'aller comme au retour, qui devient un contrat de fait, non structuré, multiplié par le nombre de fournisseurs. Et il fait porter au portail une connaissance de domaine qu'il ne devrait pas avoir.

La règle que j'en retiens : uniformiser l'enveloppe, pas le payload. Chaque fournisseur publie le schéma typé de ses golden paths de domaine (champs, valeurs autorisées, valeurs par défaut, validation ; l'XRD d'une Composite Resource se traduit par exemple directement en JSON Schema) ainsi qu'un statut typé. La couche de composition du portail mappe les paramètres du golden path sur ces schémas et agrège les statuts en un statut unique. L'adaptation ne disparaît pas, elle change de nature : au lieu d'un convertisseur ad hoc par fournisseur, une composition typée des deux côtés, avec un propriétaire identifié.

Conway est une contrainte de design

Tout cela repose sur une réalité organisationnelle. La loi de Conway l'énonce depuis 1968 : la structure d'un système reflète la structure de communication de l'organisation qui le produit. Une plateforme répartie entre plusieurs équipes et plusieurs directions produira une offre morcelée, sauf si les interfaces entre ces équipes sont conçues comme des produits : explicites, possédées, versionnées. Chaque frontière d'équipe devient une interface à gouverner, ou une couture que l'utilisateur final ressentira.

Team Topologies propose un mode cible pour ces interfaces, le X-as-a-Service : un contrat clair, des engagements de service, du self-service, sans coordination quotidienne. On y arrive généralement après une phase de collaboration limitée dans le temps, le temps de découvrir ce qu'il faut construire. Sans stratégie globale explicite, chaque équipe optimise localement, et la fédération ne converge pas d'elle-même.

Pour être utile, une stratégie globale doit permettre à chaque équipe d'en dériver ses propres décisions. Elle fixe donc quelques éléments : les patterns cibles côté utilisateur final (peu nombreux, nommés, avec ce qu'ils ne couvrent pas), le contrat entre les couches, la règle de composition (qui compose quoi, à quel niveau), la politique de sortie du chemin, et quelques indicateurs partagés comme l'adoption, le lead time, le taux de déviation ou les tickets évités. Le modèle de maturité du CNCF aide à situer ces choix, à condition de suivre son propre avertissement : viser le niveau le plus élevé partout n'est ni nécessaire, ni toujours souhaitable.

Et les agents IA ?

La question se pose désormais dans chaque projet d'IDP : faut-il des golden paths différents pour les agents ? Les données disponibles poussent la granularité dans le même sens, vers le haut.

Plus un agent voit d'outils, plus il se trompe en les choisissant. Dans l'étude RAG-MCP, la sélection reste fiable tant que le bon outil figure parmi une trentaine de candidats, se dégrade au-delà et s'effondre passé la centaine. Plus la chaîne d'étapes est longue, plus l'échec est probable : en relisant les mesures de METR, Toby Ord montre que le taux de succès d'un agent décroît à peu près exponentiellement avec la longueur de la tâche. Un golden path humain en cinq étapes devient, pour un agent, cinq appels dont les fiabilités se multiplient. Exposé comme un seul outil, validé puis exécuté de façon déterministe par la plateforme, il n'en reste qu'un.

Les fournisseurs de modèles en tirent la même règle. Anthropic, dans son guide sur l'écriture d'outils pour agents, déconseille de transposer chaque endpoint en outil et recommande des outils qui couvrent un workflow complet. OpenAI conseille de rester sous la vingtaine de fonctions et de fusionner celles qui sont toujours appelées en séquence. Un outil qui couvre un workflow entier : c'est la définition même d'un golden path.

Les praticiens convergent aussi sur un principe qu'on peut résumer ainsi : un contrat, deux surfaces. Le même golden path est exposé par l'interface du portail pour les humains et par une API ou un serveur MCP pour les agents, sur le même backend et derrière les mêmes contrôles. Les schémas typés des capabilities y gagnent une seconde valeur : des champs avec valeurs autorisées et valeurs par défaut sont exactement ce qu'un agent sait consommer, là où des paramètres à plat le laissent deviner. Aucune étude ne compare encore directement les deux approches sur des tâches de plateforme, c'est un consensus d'architecture plus qu'une mesure. Mais concevoir pour les humains aujourd'hui et pour les agents demain mène à la même granularité.

Opinionated, pas une cage

Des golden paths à la taille d'un cas d'usage ne doivent pas enfermer les équipes. Un golden path couvre la grande majorité des besoins avec de bons choix par défaut et quelques paramètres bornés. Pour le reste, il faut une sortie gouvernée : un accès direct aux capabilities sous-jacentes pour les cas avancés, avec un support plus limité. Spotify l'assumait déjà : on peut quitter le chemin, on perd simplement le support.

La boussole, c'est le taux de déviation. Si beaucoup d'équipes quittent un golden path, ce n'est pas le principe qui est faux, c'est ce golden path-là. Il faut alors comprendre ce qui lui manque, plutôt que d'ouvrir la boîte de briques à tout le monde.

Ce sont des apprentissages en cours, pas des certitudes. Ils évolueront avec les plateformes que nous construisons, et avec l'arrivée des agents parmi leurs utilisateurs. Si vous travaillez sur les mêmes questions, échangeons.

Pour aller plus loin

Golden paths et plateformes

• How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem, l'article de Spotify (2020) qui a popularisé le terme, avec le choix d'un golden path par discipline.
• The "Paved Road" PaaS for Microservices at Netflix, la même idée chez Netflix sous le nom de paved road : un ensemble pré-assemblé, et une échappatoire assumée.
• How to pave golden paths that actually go somewhere, le résumé du talk de Kaspar von Grünberg sur les golden paths « pour le jour 50, pas pour le jour 1 ».
• CNCF Platforms White Paper, un vocabulaire commun pour parler de plateformes : capabilities, capability providers, interfaces.
• Platform Engineering Maturity Model, le modèle de maturité du CNCF, pour situer sa plateforme sans viser le niveau maximal partout.
• Crossplane : Compositions, la documentation pour construire une API de plateforme typée qui n'expose que les champs choisis.

Organisation

• What is a Thinnest Viable Platform (TVP)?, la plateforme minimale de Team Topologies, pensée pour réduire la charge cognitive des équipes.
• Team Topologies : key concepts, les types d'équipes et leurs modes d'interaction, dont le X-as-a-Service.

Agents IA

• Writing effective tools for AI agents, le guide d'Anthropic : moins d'outils, chacun couvrant un workflow complet.
• Building effective AI agents, la distinction d'Anthropic entre workflows orchestrés par du code et agents autonomes.
• Function calling, le guide d'OpenAI et sa recommandation de rester sous la vingtaine de fonctions.
• RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection, l'étude sur la dégradation de la sélection d'outils quand leur nombre augmente.
• Is there a half-life for the success rates of AI agents?, l'analyse de Toby Ord sur la décroissance du taux de succès avec la longueur des tâches.
• 1,500+ PRs Later: Spotify's Journey with Our Background Coding Agent, un retour d'expérience où l'agent emprunte le chemin existant (revue, CI, merge) au lieu d'en avoir un à part.