Atulpriya Sharma, en tant qu’ambassadeur de la CNCF et organisateur du Platform Engineering TCG, estime que la question la plus importante en ingénierie des plateformes n’est pas de savoir si l’organisation a construit une plateforme, mais comment les développeurs interagissent réellement avec ses capacités. Les organisations qui ne disposent pas encore d’une plateforme officielle s’appuient généralement sur des scripts dispersés et des connaissances individuelles, tandis que d’autres peuvent avoir un portail développeur, une interface CLI et des parcours prêts à l’emploi, tout en traitant encore les demandes manuellement. Dans les deux cas, le problème réside dans la maturité de l’interface par laquelle les équipes consomment les capacités de la plateforme.
L’article s’appuie sur le modèle de maturité de l’ingénierie des plateformes de la CNCF, qui mesure indépendamment cinq aspects : l’investissement, l’adoption, les interfaces, les opérations et la mesure. Chaque aspect comporte quatre niveaux : ad hoc, opérationnel, évolutif et optimisé. Selon le modèle, l’organisation ne progresse pas comme un tout ; elle peut avancer sur un aspect tout en restant en retard sur un autre. L’analyse se concentre sur l’aspect des interfaces, c’est-à-dire les modèles, les interfaces CLI, les portails et les API utilisés par les développeurs.
Quatre étapes pour l’interface de la plateforme
Au premier niveau, l’organisation s’appuie sur des procédures personnalisées : demandes manuelles, processus différents selon les équipes et connaissances transmises d’une personne à l’autre. L’absence de nom officiel pour la plateforme ne signifie pas qu’elle n’existe pas réellement : les messages répétés adressés à un ingénieur précis pour configurer une base de données constituent l’interface actuelle de la plateforme, même si celle-ci n’est pas gérée.
Le deuxième niveau est celui des outils standardisés. C’est à ce stade qu’apparaissent les golden paths, ou parcours balisés, ainsi que des documents, des modèles et des interfaces cohérents pour fournir et surveiller les capacités. Les résultats semblent généralement positifs : adoption accrue, intégration plus rapide des nouveaux employés et amélioration des indicateurs. Toutefois, les demandes qui sortent du parcours prévu nécessitent encore l’intervention de l’équipe plateforme ; l’interface est donc uniformisée sans être autonome.
Au troisième niveau apparaissent les solutions en libre-service, qui permettent au développeur d’exécuter la plupart des demandes courantes sans passer par l’équipe plateforme. Ce niveau évalue davantage le comportement des équipes que les seuls indicateurs : les tickets de provisionnement courant diminuent, les nouveaux ingénieurs commencent à utiliser directement la plateforme et le travail de l’équipe plateforme passe de l’exécution de demandes individuelles à l’amélioration du cadre qui les gère. Selon les exemples cités par l’auteur, des organisations ont signalé une baisse de 40 % à 60 % des demandes d’exception après l’ajout d’options de configuration en libre-service.
Au quatrième niveau, celui des services intégrés, les capacités de la plateforme deviennent une composante transparente des outils de travail quotidiens. Lors de la création d’un nouveau service, la supervision, la journalisation et la sécurité peuvent être intégrées automatiquement, tandis que les politiques de sécurité imposent leurs règles par l’intermédiaire de la plateforme au lieu de demander au développeur de les négocier manuellement. La plateforme devient presque invisible, et son succès se mesure à la rareté des situations dans lesquelles les développeurs doivent réfléchir à l’infrastructure.
Pourquoi les organisations s’arrêtent-elles au deuxième niveau ?
L’analyse identifie quatre problèmes récurrents. Le premier est le problème des files d’attente : les golden paths couvrent les cas courants, mais les cas exceptionnels peuvent représenter 30 % du travail dans les grandes organisations. L’auteur cite l’exemple d’une entreprise de vente au détail qui a utilisé un golden path pour déployer Kubernetes au moyen de Helm charts et d’ArgoCD. L’adoption a atteint 85 % en six mois, mais 40 cas d’exception se sont accumulés et l’équipe consacrait 60 % de son temps à des configurations situées en dehors du parcours.
Le deuxième est l’écart d’expertise : les équipes plateforme peuvent concevoir des capacités générales qui ne répondent pas exactement aux besoins des équipes spécialisées, ce qui pousse ces dernières à développer leurs propres solutions. Le troisième est le piège de la maintenance : chaque nouvelle capacité ajoute une surface à mettre à jour, tester et corriger lorsqu’une vulnérabilité apparaît ou que Kubernetes est mis à niveau. L’auteur mentionne un cas où les anciens Helm charts, les dépendances propres à un fournisseur cloud et les hypothèses réseau se sont accumulés, au point que leur mise à jour est devenue risquée.
Le quatrième problème est la rigidité. Le golden path reflète des hypothèses valides au moment de sa conception, mais celles-ci peuvent devenir des contraintes lorsque les technologies, les processus et les besoins des équipes évoluent. Les exceptions et l’infrastructure fantôme se multiplient alors, et l’équipe plateforme se transforme en usine de solutions individuelles au lieu d’améliorer l’interface fondamentale.
Qu’est-ce qui change concrètement ?
Pour passer du premier au deuxième niveau, l’auteur propose de nommer ce qui existe avant de construire un nouveau portail : repérer les demandes les plus fréquentes, celles qui consomment le plus de temps et celles qui se prêtent le mieux à la standardisation, puis choisir un seul golden path et l’améliorer réellement avant d’élargir le catalogue.
Pour passer du deuxième au troisième niveau, il faut cesser de faire de l’équipe plateforme un intermédiaire humain obligatoire. Cela nécessite de rendre les golden paths configurables, avec des options validées et des contraintes imposées par les politiques plutôt que par des valeurs codées en dur, tout en prévoyant des issues pour les cas légitimes. L’analyse recommande également de mesurer les demandes avant de les automatiser ; dans un exemple issu du secteur des médias, l’enregistrement des demandes pendant trois mois a révélé que 20 % des types de demandes représentaient 80 % du volume. Le libre-service a donc été construit en priorité pour ces modèles, et l’arriéré a diminué de 60 % en six mois.
Il faut également considérer l’interface comme un produit, et pas uniquement les capacités dorsales. La découvrabilité, les règles de validation, les contrats et la manière de traiter les demandes inattendues font tous partie du produit. À l’approche du quatrième niveau, l’automatisation passe d’une exécution choisie par le développeur à des valeurs par défaut intelligentes imposées par les politiques dans Git, l’environnement de développement et les systèmes CI/CD, avec une répartition de la responsabilité des capacités entre les équipes chargées de la sécurité, des bases de données et de la supervision, dans le cadre de contrats clairs.
Lecture de certi.news
Le changement concret mis en évidence par l’article est le passage d’un critère de réussite de la plateforme développeur fondé sur le nombre d’outils et de parcours lancés à la quantité d’autonomie obtenue par les utilisateurs, puis au degré d’intégration de ces capacités dans le flux de travail. Cela concerne les équipes plateforme, car elles peuvent augmenter l’adoption en apparence tout en transférant la charge d’exécution vers une file d’exceptions et de maintenance.
Les exemples et les chiffres présentés ici sont toutefois donnés par l’auteur comme des observations issues d’échanges avec des organisations, et non comme une étude quantitative indépendante démontrant que les mêmes pourcentages s’appliquent à toutes les organisations. Par ailleurs, l’accès au quatrième niveau suppose une certaine maturité des contrats, des politiques et de la répartition des responsabilités ; l’achat d’un portail ou l’ajout d’un agent d’intelligence artificielle ne suffit pas à les fournir. La conclusion pose une question ouverte importante : l’interface en libre-service conçue pour les développeurs n’est pas nécessairement une interface consommable par des agents d’intelligence artificielle, qui interagissent avec les API à une fréquence et selon des modes différents des flux de travail humains. La maturité des interfaces lisibles par les machines pourrait donc être la prochaine étape que les équipes plateforme devront mesurer.