Quand votre équipe plateforme construit une autoroute que personne n'emprunte

Quelques mois après le lancement d'une plateforme interne flambant neuve, un phénomène étrange se produit. L'équipe plateforme voit ses tableaux de bord impeccables. Les golden paths sont documentés. Les pipelines sont standardisés. Tout semble parfait.

Mais les équipes applicatives ne l'utilisent pas.

Au lieu de cela, elles exécutent des scripts de déploiement depuis leur poste. Elles poussent des images Docker qui ne sont jamais passées par le pipeline officiel. Elles lancent des migrations de base de données directement depuis leur terminal. Non pas par esprit de rébellion, mais parce que la plateforme ne correspond plus à leur façon de travailler.

Ce n'est pas un échec technologique. C'est un échec consistant à traiter une plateforme comme un produit fini plutôt que comme un service vivant.

Pourquoi les équipes abandonnent les plateformes internes

Le premier signe de problème est généralement la friction. La plateforme a été construite il y a six mois avec une version spécifique d'une image de base. Depuis, l'équipe applicative a adopté une nouvelle méthode pour gérer la configuration. La plateforme ne la supporte pas. Alors, elles contournent le problème.

Ce contournement commence par un petit raccourci. Un script par-ci, une étape manuelle par-là. Avec le temps, ces raccourcis deviennent des chemins non officiels. Ils ne sont pas surveillés. Ils ne sont pas sécurisés. Et ils sont invisibles pour l'équipe plateforme jusqu'à ce que quelque chose casse.

La cause profonde n'est presque jamais la malveillance. Les équipes applicatives sont évaluées sur leur capacité à livrer des fonctionnalités, pas à suivre les règles de la plateforme. Quand la plateforme les ralentit, elles trouvent un moyen plus rapide. Si l'équipe plateforme ne le remarque pas, l'écart entre les pratiques de déploiement officielles et réelles se creuse jusqu'à ce que la plateforme devienne obsolète.

Traiter la plateforme comme un produit

Les équipes plateforme les plus efficaces cessent de considérer leur travail comme de l'infrastructure. Elles commencent à le considérer comme un produit. Les utilisateurs ne sont pas des clients qui achètent un logiciel. Ce sont d'autres équipes d'ingénierie qui doivent livrer du code chaque jour.

Les équipes produit ne lancent pas une fonctionnalité et ne s'en vont pas. Elles observent comment les gens l'utilisent. Elles demandent ce qui est frustrant. Elles itèrent. Les équipes plateforme ont besoin du même état d'esprit.

Cela ne nécessite pas un processus formel de gestion de produit. Cela peut commencer par des habitudes simples :

• Avoir une conversation régulière avec des représentants des équipes applicatives. Demandez ce qui les a ralentis cette semaine.
• Mener une courte enquête chaque trimestre. Demandez ce qu'ils changeraient s'ils le pouvaient.
• Suivre combien de fois les gens demandent de l'aide pour la plateforme. Chaque question est un signal que quelque chose n'est pas clair ou ne fonctionne pas.

Les retours ne seront pas toujours confortables. Les équipes pourraient dire que le processus de build est trop lent, que la documentation est obsolète, ou qu'il y a une étape manuelle qui devrait être automatisée. Ce n'est pas une critique. C'est une feuille de route.

Maintenir la plateforme à jour

Mettre à jour une plateforme ne consiste pas seulement à mettre à niveau les versions des outils. Il s'agit de maintenir les chemins de déploiement alignés sur la façon dont les équipes travaillent réellement.

Si les équipes commencent à utiliser plus souvent des feature flags, la plateforme doit fournir un moyen sûr de les gérer. Si une vulnérabilité de sécurité est découverte dans un composant, la plateforme doit être mise à jour avant que quelqu'un ne l'exploite. Si une nouvelle version d'un runtime modifie la façon dont les dépendances sont résolues, la plateforme doit s'adapter avant que les équipes ne rencontrent un obstacle.

Les mises à jour signifient aussi faire le ménage. Chaque plateforme accumule d'anciens pipelines, des scripts inutilisés et des environnements obsolètes. Si on les laisse tranquilles, ils deviennent des pièges. Un nouveau membre de l'équipe pourrait trouver un ancien pipeline qui a l'air correct mais qui n'a pas de contrôles de sécurité. Il l'exécute, et maintenant la production a une faille que personne n'avait anticipée.

Nettoyer les anciens chemins demande de la prudence. Vous ne pouvez pas supprimer quelque chose dont les équipes dépendent sans avertissement. C'est là qu'une politique de dépréciation entre en jeu. C'est un accord simple : lorsqu'un chemin ou une fonctionnalité va disparaître, l'équipe plateforme l'annonce tôt, explique pourquoi, et fournit un guide de migration. Pas de surprises. Pas de rupture soudaine.

Le coût d'une plateforme négligée

Une plateforme qui n'est pas maintenue sera abandonnée. Les équipes construiront leurs propres méthodes de déploiement, et ces méthodes seront incohérentes et non surveillées. L'équipe plateforme existera toujours, mais elle maintiendra quelque chose en quoi personne n'a confiance.

Une plateforme qui évolue avec ses utilisateurs devient un endroit où les équipes veulent travailler. Elles n'ont pas à réfléchir à la façon de déployer. La plateforme leur offre un chemin sûr, rapide et qui correspond à la façon dont elles construisent réellement des logiciels.

Quand cela se produit, le déploiement cesse d'être une activité technique que chaque équipe découvre par elle-même. Il devient une capacité organisationnelle sur laquelle toute l'entreprise peut compter.

Une courte checklist pour les équipes plateforme

Si vous êtes responsable d'une plateforme, voici quelques points à vérifier régulièrement :

• À quand remonte la dernière fois que vous avez parlé à une équipe applicative de ce qui la frustre ?
• Existe-t-il des chemins de déploiement non officiels que votre équipe ne surveille pas ?
• Y a-t-il une politique de dépréciation, ou les choses disparaissent-elles simplement ?
• À quand remonte la dernière mise à jour des images de base et des dépendances dans votre golden path ?
• Les équipes doivent-elles demander de l'aide plus d'une fois pour le même problème ?

Ces questions ne portent pas sur les outils. Elles portent sur le fait que votre plateforme est toujours utile aux personnes qui en dépendent.

La véritable mesure d'une plateforme

Une plateforme n'est pas réussie parce qu'elle a une documentation propre ou un tableau de bord magnifique. Elle est réussie parce que les équipes choisissent de l'utiliser, même quand personne ne regarde.

Le moment où une équipe décide de suivre le chemin officiel plutôt que de construire son propre raccourci, c'est le moment où la plateforme gagne sa place. Et la seule façon de gagner cette confiance est de continuer à écouter, à mettre à jour et à supprimer ce qui ne fonctionne plus.