Platform Engineering : la gouvernance avant les outils, pas l'inverse

Dans un précédent article : Platfrom Engineering, de quoi parle-t-on vraiment, nous avons exploré ce qu'est le Platform Engineering et pourquoi placer l'expérience développeur au cœur d'une IDP change tout. Mais connaître le concept ne suffit pas : encore faut-il savoir par où commencer et surtout, éviter les erreurs de gouvernance qui font échouer la plupart des projets avant même le premier déploiement.

Penser la gouvernance avant l'outil

Lorsqu'une entreprise décide de se lancer dans le Platform Engineering, elle parle tout de suite de Backstage, son futur Internal Developer Platform.

Le scénario que nous observons est malheureusement un grand classique de l'IT. Au départ, l'entreprise identifie un problème. On peut prendre par exemple le fait que les développeurs passent trop de temps sur des tâches opérationnelles, que l'onboarding des nouveaux arrivants prend des semaines ou que chaque équipe crée ses propres pipelines CI/CD. 

Lorsque la décision de construire une plateforme interne est quasiment décidée, l’outillage est alors choisi à la hâte. L'équipe déploie Backstage, définit une poignée de Golden Paths, et attend que l'adoption se fasse d'elle-même.

Quel est le bilan six mois plus tard ? La plateforme existe, elle est en ligne, mais personne ne l’utilise. Les développeurs, faute d'y trouver une vraie valeur ajoutée au quotidien, la contournent et reprennent leurs vieilles habitudes. Les demandes continuent de pleuvoir sur les Ops. Quant à la toute nouvelle "équipe plateforme", au lieu d'innover et de créer de l'autonomie, elle finit découragée avec un outil qu'elle est la seule à maintenir, sans aucun utilisateur…

Et si le problème n’était pas technologique ? Et si le problème n'était pas Backstage ? 

Le problème se situe en amont. Il vient de la conviction qu'un catalogue de services allait régler des dysfonctionnements liés à l'organisation et aux processus. Avant de parler logiciel, il faut parler gouvernance.

Qu'est-ce qui bloque réellement l'adoption ?

Avant de dérouler un catalogue d'outils, il faut regarder l'organisation de l'entreprise. Déployer un outil sur une structure dysfonctionnelle ne va faire qu’empirer les choses.

Les équipes sont fragmentées. D'un côté, une équipe "Build" qui conçoit des pipelines, de l'Infrastructure as Code et qui tente de définir des standards. De l'autre, une équipe "Run" qui gère la production au quotidien. Le problème ? Ces deux entités travaillent en parallèle mais ne partagent ni les mêmes priorités, ni les mêmes méthodes, ni les mêmes contraintes opérationnelles. Sans une gouvernance partagée qui réconcilie la création de la plateforme et son exploitation, l’alignement est presque impossible.

Une autre question se pose. Comment demander à des équipes Ops de construire la plateforme de demain si leur quotidien consiste à éteindre des incendies ? Si ces équipes gèrent les alertes et les incidents, elles ont forcément moins de temps disponible pour le travail de fond. Elles n'ont pas le temps d'automatiser proprement. On se retrouve dans une situation bien trop connue où les tickets de support s'accumulent, les délais s'allongent… Et l'équipe Ops devient malgré elle le goulet d'étranglement de l'entreprise. Installer un outil comme Backstage, dans ce contexte, ne fera qu'ajouter une charge de maintenance supplémentaire sur une équipe déjà sous l’eau.

De plus, toutes les équipes de développement ne se valent pas techniquement, et c'est normal. Certaines maîtrisent déjà Docker et Kubernetes, tandis que d'autres peinent encore avec les concepts de base de la CI/CD. Vouloir imposer la même plateforme, avec le même niveau d'abstraction et les mêmes exigences à tout le monde, en même temps, est une erreur. Les équipes les plus avancées se sentiront bridées et contourneront l'outil. Les moins matures se sentiront dépassés et abandonneront.

L'adoption ne se décrète pas par un choix technologique, elle se prépare par l'ingénierie et le cadrage.

L'ingénierie avant le catalogue produit

Aujourd'hui, les entreprises ne manquent pas d’outils. L'écosystème Cloud Native regorge d'outils. Bien souvent, ce qui fait défaut, c'est un cadre défini et une méthode pour assembler le tout de manière cohérente. C'est pourquoi les équipes Kaliop appliquent une approche qui se déroule en trois phases :

Phase 1 : comprendre. Avant de construire, il faut auditer. 

Auditer le niveau de maturité de l'Infrastructure as Code, de l’observabilité, des chaînes CI/CD, des capacités de self-service... pour que cet audit reflète la réalité du terrain, nous interrogeons les développeurs, ops, architectes, sécurité… pour capter les points de friction. De cette analyse découle une trajectoire en trois temps :

• gérer la dette technique,
• identifier les premiers Golden Paths,
• déployer à l'échelle de l'organisation. 

Dès le début, nous incluons systématiquement un plan FinOps. Le self-service est une excellente chose, mais sans garde-fous sur les coûts, il peut vite se transformer en gouffre financier.

Phase 2 : co-concevoir

C'est à cette étape que la question de l'outillage se pose. Nous n'arrivons jamais avec Backstage sous le bras par défaut parce que nous sommes persuadés que l'outil suit le besoin et non l’inverse. Si un portail SaaS léger ou une interface maison suffit à résoudre vos problèmes, c'est cette voie que nous privilégierons. 
Puis, nous définissons ensemble une stratégie Make or Buy avec pour objectif de livrer une architecture adaptée et un backlog priorisé.

Phase 3 : co-construire

Les ingénieurs Kaliop s'intègrent à vos effectifs et construisent avec vos équipes, et non à leur place. Ce modèle de "pair-programming" appliqué à l'infrastructure garantit un transfert de compétences continu. Notre but n'est pas de vous rendre dépendants de nos services à long terme, mais bien de vous laisser les clés d'un produit que vos équipes maîtrisent de bout en bout et sauront faire évoluer.

Remettre la gouvernance avant l'outil

Avant de vous lancer dans la construction d'un portail de bout en bout, ou à l'inverse, avant de débrancher un outil que vous jugez inefficace, faites ce simple auto-diagnostic. Observez-vous l'un de ces trois symptômes dans votre organisation ?
Vous avez une plateforme, mais le taux d’adoption est désespérément bas. Les équipes continuent de contourner les standards et préfèrent utiliser leurs propres méthodes.
Au lieu de construire de nouvelles capacités de self-service et d'innover, votre "Platform Team" passe 80 % de son temps à répondre à des tickets d'assistance et à faire de la maintenance.
Malgré vos investissements techniques, votre fréquence de déploiement ne décolle pas, le temps de mise en production ne s'améliore pas et les incidents restent fréquents. 
Si vous cochez l'une de ces cases, il faut chercher à comprendre les points de friction qui bloquent votre plateforme.

Sur un projet de Platform Engineering, les équipes Kaliop n'entrent jamais par l'outil, mais toujours par un audit.
Vous souhaitez évaluer la maturité de votre plateforme, remettre votre projet sur de bons rails ou simplement savoir par où commencer sans tomber dans le piège de l'outil ? Parlons-en directement.