[J-Story 1] Platform Engineering vu de l’intérieur : Comment passer d’une Plateforme perçue comme un frein à un produit adopté par 95% des équipes. Côme Tresarrieu @Payfit

Dans cette édition, on parle de Platform Engineering vu de l’intérieur : 
Comment passer d’une plateforme perçue comme un frein à un produit adopté par 95% des équipes, sans ajouter d’outils, mais en changeant la posture. 

Pourquoi lire ça ? 

Parce que le Platform Engineering ne se résume pas à des outils. Cette J-Story partage un retour terrain concret sur la transformation d’une plateforme en un produit réellement adopté par les équipes.

Ce que vous allez apprendre ? 

• Pourquoi la posture produit est clé pour une plateforme
• Comment améliorer l’adoption sans ajouter de nouveaux outils
• Comment mesurer et démontrer l’impact business d’une plateforme

À qui cette J-Story s’adresse-t-elle ?  

Engineering Managers, responsables Platform / DevEx / DevOps, Tech Leads, CTO, et toutes les équipes confrontées aux enjeux de CI/CD et d’adoption.

J-Story 1 – Côme Tresarrieu, chez Payfit.

1. Peux-tu te présenter et revenir sur ton parcours jusqu’à ton rôle actuel ?

En dehors du travail, je vis à Lyon et je passe pas mal de temps à bricoler mon appartement et faire du vélo de route (hâte de la fin de l’hiver).

A l’origine, mon parcours est plutôt orienté SRE et DevOps (monter des infras AWS, mettre en place kubernetes, dockeriser des applications, faire de la CI, etc…).

Lors de ma dernière expérience avant PayFit, j’étais le seul DevOps dans une petite équipe tech. Les besoins d’infra étaient assez limités, ça m’a permis de faire assez rapidement la transition vers du backend en NodeJS.

Ce changement m’a beaucoup plu, j’ai pu voir comment une équipe produit (PM + Designer)  travaillaient ensemble, en lien étroit avec les clients finaux pour définir leurs besoins avant de développer des solutions.

Lorsque j’ai commencé à faire le tour de cette expérience, on m’a proposé de rejoindre PayFit dans l’équipe Developer Experience.

La mission m’a parlé: voir les développeurs comme des clients, essayer de comprendre leurs besoins et travailler avec eux pour trouver des manières d’améliorer leur quotidien.

Ces expériences m’ont amené naturellement vers un rôle plus large que la technique pure. Aujourd’hui, je suis Engineering Manager d’une équipe plateforme chez PayFit.

2. Quel est ton rôle aujourd’hui et quels étaient les enjeux techniques avant d’aborder le Platform Engineering ?

En début de 2025, mon Directeur m’a coaché et m’a donné l’opportunité de passer manager de l’équipe Infrastructure et Developer Experience (IDE) en remplaçant un manager qui partait.

IDE venait d’être créé, quelques mois plus tôt, après la fusion de 2 équipes: une équipe d’experts orientés infrastructure et une équipe Developer Experience.

Ces 2 équipes étant composées de profils et manières de travailler différentes, j’ai beaucoup travaillé pour transformer cette fusion en une véritable équipe.

D’abord en améliorant sa cohésion et ses process, et ensuite en proposant une vision.

Cette transformation a demandé de faire évoluer la composition de l’équipe. Tout le monde ne se projetait pas forcément dans cette nouvelle approche, deux personnes ont quitté l’équipe et deux nouvelles nous ont rejoints fin 2025 pour accompagner cette dynamique.

Ayant une affinité avec le produit, j’essaie d’apporter une approche produit à l’équipe en m’assurant que nous suivons un processus de discovery & conception produit: entretien utilisateur, exploration technique, définition des KPIs, découpage en itération.

Tout cela dans un jeu d’équilibriste sur la roadmap pour garder du temps pour explorer de nouvelles idées/technologies (par exemple: tester les outils “d’IA DevOps”) .

J’essaye aussi de garder un œil sur ce que font les 18 équipes produits et les 3 équipes Platform, en plus de rester à jour sur les objectifs business et techs.

• Pour donner du contexte à l’équipe, ce qui les aide à prioriser les projets
• Pour savoir à qui communiquer, de manière opportuniste, pour faire avancer nos sujets
• Est être sur que nos projets s’inscrivent dans la continuité de la stratégie tech/produit 

Et pour finir, je suis aussi chargé de communiquer notre vision et notre avancement au top management, en adaptant le niveau de détails.

Big up à mon équipe. Si je peux parler de Platform Engineering chez PayFit, c’est surtout grâce à leur implication, à l’énergie qu’ils ont mis dans cette transformation et à leur volonté de construire une plateforme pensée pour ses utilisateurs.

Si ce poste vous intéresse et que vous souhaitez rejoindre une entreprise à fort impact, qui permet à 20.000+ entreprises européennes de gérer leur paie et sujets RH, il y a plusieurs postes à pourvoir dans l’Engineering @ PayFit (ici).

3. Comment définirais-tu le Platform Engineering avec tes mots ?

Pour moi, au cœur du Platform Engineering il y a la posture produit. Il faut imaginer la plateforme, non pas comme une collection d’outils, mais comme un produit.

Un produit qui doit offrir une expérience cohérente dans ses différentes strates (CI, CD, Infrastructure, Monitoring, etc…) et surtout pensé pour ses utilisateurs: les développeurs de l’entreprise.

Concrètement, ça veut dire que les besoins des développeurs doivent guider nos priorités. Avoir une jolie liste de technologies, ou ajouter l’outil X ou Y, ne crée pas une plateforme.

Gregor Hohpe propose une comparaison que j’aime beaucoup: panier de fruits vs salade de fruits. Il y a une plus grande valeur ajoutée à fournir un assemblage cohérent d’outils, qui permettent d’offrir une expérience complète vs offrir une collection d’outils et de demander aux développeurs de faire l’assemblage eux-mêmes.

Par contre, voir la plateforme comme un produit implique des problématiques similaires à celles rencontrées par une entreprise SaaS. Comme par exemple, définir la cible de son produit, et donc parfois accepter de ne pas répondre aux besoins de certains utilisateurs.

Un autre point important, les manières de faire du Platform Engineering dépendent énormément du contexte de l’entreprise. On peut trouver sur internet qu’une équipe plateforme doit commencer par un portail de self-service. C’est parfois vrai, mais pas toujours.

Chez PayFit, par exemple, notre réussite sur 2025 ne repose pas sur une nouvelle feature dans notre portail Backstage.

Elle s’est surtout construite autour d’un changement de manière de collaborer, accompagnée d’un projet de simplification de la CI/CD, la plus grosse peine de nos utilisateurs.

Et au final, ce projet n’a pas nécessité de nouveaux outils, mais un gros travail sur l’intégration des outils existants pour offrir la meilleure expérience possible.

4. Concrètement, comment avez-vous mis en place le Platform Engineering ?

En février 2025, plusieurs développeurs nous ont remonté le fait que la plateforme leur faisait perdre trop de temps.

Jusqu’à cet instant, nous avions de bons résultats dans nos questionnaires biannuels, peu de retours négatifs et plutôt l’impression que notre plateforme fonctionnait correctement.

Nous avons donc décidé de conduire une série d’entretiens avec une vingtaine de développeurs. Résultat: les développeurs ont tellement de mal à se servir de notre plateforme qu’ils essayent de s’en servir le moins possible, quitte à en re-développer des bouts ou pire encore, réduire le scope de leur feature pour ne pas y toucher.

Un des témoignages les plus marquants: “Si on me demande d’évaluer un ticket pour une fonctionnalité où je dois toucher à de l’infrastructure, je double mon estimation”.

Ça a été un électrochoc.

En tant que manager, ça a été un moment clé pour moi. Au-delà de l’organisation de l’équipe IDE, il fallait surtout proposer un premier projet concret aux développeurs.
Le sujet qui préoccupait le plus nos développeurs était la CI/CD. La stack était relativement homogène entre les 18 équipes (Typescript, NodeJS), mais le lead time entre un commit et une mise en production restait trop long (en moyenne 50 minutes), avec encore beaucoup d’étapes manuelles et un taux d’échec élevé.

Nous avons travaillé sur un workflow plus cohérent, en mettant surtout l’accent sur les intégrations entre les différents outils existants. L’objectif était simple : réduire la friction et offrir une expérience plus fluide.

Une fois la solution prête, le vrai travail a commencé : l’adoption.

Nous avons commencé par trouver une équipe prête à jouer le rôle de bêta-testeur, à accepter qu’on essuie les plâtres ensemble et à nous aider à améliorer notre workflow.

Peu à peu, nous avons élargi notre groupe d’utilisateurs, en commençant d’abord par les équipes les plus réceptives.

En parallèle, nous avons mis l’accent sur la communication: en faisant des présentations globales, en communicant après chaque étape (migrations, nouvelle feature) et en fournissant un support “premium” pour les utilisateurs de notre workflow.

Un phénomène intéressant est apparu, des équipes qui n’étaient pas prioritaires dans notre plan sont venues directement nous voir pour nous demander de les accompagner. Elles avaient soit vu une équipe qui utilisait le nouveau système et qui les avait convaincues de notre solution, soit elles avaient lu une de nos communications et étaient intriguées par notre solution.

Avec le recul, ça montre bien l’importance de la priorisation et de beaucoup communiquer, tout au long du projet.

Nous voilà 1 an plus tard, 17 des 18 équipes utilisent notre nouveau workflow. Et nous avons une présentation pour migrer la 18ème équipe en février ! 

C’est une réussite interne et nous avons de bons feedbacks: “Ce nouveau workflow est tellement plus simple, c’est la meilleure expérience que j’ai connu jusqu’à présent”.

Je me sers aujourd’hui de ce projet comme exemple pour les suivants:

• Bien comprendre les problèmes de nos développeurs (et sur quel cohort on veut focus)
• Prendre du temps pour concevoir la solution et comment elle s’articule avec le reste de la plateform
• Commencer avec 1 ou 2 équipes de bêta-testeurs
• Investir dans la communication, quitte à se répéter
• Déployer progressivement en priorisant les équipes qui ont le plus de chance d’adopter la solution

5. Quels ont été les principaux obstacles rencontrés et comment les avez-vous dépassés ?

Les plus gros obstacles n’étaient pas techniques, mais humains et culturels, en gros de la conduite du changement.

Le premier a été le changement de posture vis-à-vis des développeurs. Passer à une approche plus orientée produit implique d’être beaucoup plus proches de nos utilisateurs : mieux communiquer, expliquer nos choix, et accepter de prendre davantage de charge de support pour accompagner l’adoption.

C’était indispensable pour améliorer la perception qu’avaient les développeurs de la plateforme et, surtout, pour regagner leur confiance.

Le deuxième obstacle a été le coût humain de cette transformation pour les équipes produits et pour l’équipe IDE.

Pour que les équipes produits puissent adopter notre solution, elles devaient utiliser du Trunk Based Development, un choix qui était en lien avec la stratégie long terme portée par notre CTO. C’est un changement majeur sur la manière de designer, développer et déployer une feature.

Certaines équipes n’avaient pas encore amorcé ce changement, ce qui a demandé un accompagnement supplémentaire à la “simple” migration.

Être disponibles, réactifs, présents sur le support a été clé, mais ça a aussi généré de la frustration et de la fatigue côté équipe IDE.

En tant que manager, je conseillerais de faire attention à la “migration fatigue”. On pense souvent au coût pour les équipes produits mais rarement au coût pour les équipes plateformes. Trop de migration et votre équipe plateforme souffre, pas assez et la migration n’avance pas. L’équilibre est dur à trouver.

Enfin, il a fallu convaincre et embarquer le top management.

Les sujets plateforme peuvent facilement être perçus comme un coût ou comme quelque chose qui ralentit les équipes produit.

J’ai dû expliquer notre stratégie et clarifier pourquoi ce projet était prioritaire. Ce qu’il allait apporter à l’organisation.

Dans notre cas, j’ai dû expliquer l’impact business qu’avait le Lead Time for Change en calculant le coût du temps perdu dans des workflows de CI/CD non optimisés.

Parler avec des métriques compréhensibles pour le top management m’a permis de les embarquer avec nous sur cette transformation.

Et les avoir dans son camp est particulièrement important car dans certains cas leur mandat permet de faire avancer la situation.

Avec le recul, j’ai aussi appris l’importance d’itérer.

Dans une équipe comme IDE, il faut pouvoir pivoter rapidement : incidents en production, besoin de support sur des déploiements critiques, ou priorités qui changent.

Accepter ces contraintes et les intégrer dans la stratégie a été un apprentissage clé de cette transformation.

6. Quels conseils donnerais-tu à une entreprise qui démarre aujourd’hui le Platform Engineering ?

Tout dépend du contexte de l’entreprise. Par exemple, notre projet CI/CD a fonctionné parce qu’on a créé une solution qui répond aux besoins de la majorité de nos développeurs. Avec les contraintes spécifiques que le contexte de PayFit nous impose.

Je pense que la solution serait différente s’il fallait la mettre en place dans une autre entreprise.

Sur les ressources, je conseillerais le livre Platform Strategy de Gregor Hohpe qui m’a beaucoup aidé au début. J’en garde la comparaison salade de fruits vs panier de fruits, et j’y retourne pour voler quelques schémas. Très pratique si vous devez faire des slides ou illustrer des concepts.

Plus récemment je suis tombé sur le Digital Platforms 101 Playbook de Equal Experts. J’ai trouvé la page sur les organigrammes des équipes plateforme assez intéressantes.

Et je terminerais par ce qui a le mieux fonctionné pour moi: aller parler directement avec les développeurs, les questionnaires ne sont pas suffisants.

—————————————————————————————————–

Ce qu’on retient de cette J-Story

• Le Platform Engineering est avant tout une posture produit
• L’adoption compte plus que la sophistication technique
• La communication est un levier clé
• Les métriques sont essentielles pour embarquer le top management
• La fatigue des équipes plateforme est un vrai sujet