3 ans de LEAN, et après ? Comment on a réorganisé notre tech

Trois ans après être passés du SCRUM au LEAN, nous étions satisfaits. Les process étaient rodés, les équipes autonomes, le delivery fluide. Et puis, progressivement, de nouveaux signaux sont apparus. Des silos qui ralentissaient nos projets, un désalignement croissant entre roadmaps produit et technique, des sujets d’architecture qui ne trouvaient pas leur place. Des problèmes structurels qu’on ne pouvait plus ignorer. Cet été, nous avons décidé de repenser notre organisation tech chez Leocare. Voici notre retour d’expérience : d’où on partait, ce qu’on a constaté, et ce qu’on a changé.

D’où on partait

Avec l’adoption du LEAN, nous avions mis l’accent sur les squads fonctionnelles. Leur mission était claire : livrer des features, par petits lots, vite et bien. En théorie, chaque squad consacrait 70 % de son temps aux nouvelles fonctionnalités et 30 % à la technique. Les 70 % étaient pilotés par les Squad Leads et l’équipe produit, garants de l’unique roadmap de Leocare. Les 30 % restants étaient gérés par des guildes, chacune avec sa propre roadmap.

Après trois ans de « test & learn », le modèle des squads nous convenait bien. C’était une mécanique qui tournait. Mais côté technique, les frustrations s’accumulaient.

Ce qu’on a constaté

Au fil du temps, trois familles de sujets techniques avaient émergé, et elles ne se ressemblaient pas du tout.

Il y avait d’abord les sujets qui pouvaient s’intégrer directement dans des features et avancer au rythme des squads. Aucun problème avec ceux-là. Ensuite, il y avait les chantiers transverses ou de longue haleine :

• la refonte du modèle de données
• le passage à une architecture event-driven
• la mise en place d’un RBAC clair.

Des sujets structurants, qui ne rentraient dans aucune feature. Et enfin, les travaux ponctuels mais critiques : des migrations, des montées de version de librairies, des évolutions d’infrastructure. Des choses qui ne peuvent pas attendre mais qui n’ont pas de propriétaire naturel.

Ces trois types de travaux ne demandaient ni les mêmes compétences, ni le même degré de coordination, ni la même temporalité. Pourtant, ils atterrissaient tous au même endroit : les guildes. Et celles-ci n’étaient ni structurées ni animées de façon homogène. Elles fonctionnaient davantage comme des groupes de discussion informels que comme de véritables espaces de montée en compétence. Les guildes avaient besoin de se renforcer et de gagner en cohérence.

À cela s’ajoutait un phénomène révélateur : la moitié des développeurs jouaient un rôle implicite de référent technique, souvent sans périmètre clair ni responsabilité formellement définie. Ça partait d’une bonne volonté, mais ça créait énormément d’ambiguïté. Qui décide ? Qui priorise ? Qui arbitre ? Comment assurer la cohérence technique quand plusieurs personnes s’estiment responsables d’un même périmètre ? La vérité, c’est que quand tout le monde est responsable, personne ne l’est réellement.

Les silos entre équipes ajoutaient une couche de complexité. L’équipe DevOps, par exemple, intervenait souvent trop tard dans les décisions. Le résultat : un manque d’anticipation, des contraintes techniques découvertes tardivement, et un sentiment généralisé que chacun avançait dans sa propre temporalité. Une équipe trop loin des sujets fonctionnels et pas assez incluse dans les réflexions globales.

Côté Data, la maturité et les besoins n’étaient pas alignés avec ceux des équipes produit, ce qui créait des décalages dès la conception. La QA, elle, arrivait parfois trop tard pour peser sur le design initial, avec des difficultés récurrentes à planifier et à suivre l’écriture de tests automatisés.

Comment on a réfléchi

Comme souvent chez Leocare, nous avons voulu mener cette réflexion de manière collective. Toute la tech était invitée, sur la base du volontariat, à participer aux ateliers visant à nous réorganiser.

Le timing n’était pas idéal sur le papier : en plein été, avec les vacances, les sessions se sont étalées sur deux mois. Mais avec le recul, ça n’a pas été un frein, bien au contraire. Ce rythme nous a permis de mûrir notre réflexion, de faire des allers-retours sur les propositions, et d’aboutir à des décisions qui n’étaient pas prises dans l’urgence.

Une fois les constats posés et les frustrations mises à plat, l’ambition s’est clarifiée d’elle-même : réduire les silos et clarifier la gouvernance de la roadmap technique.

Ce qu’on a changé

Le premier changement, et sans doute le plus symbolique, a été d’abandonner le modèle des « référents techniques globaux ». Nous sommes allés vers quelque chose de plus lisible : chaque chantier transverse est désormais porté par une ou deux personnes dédiées. Plus de dilution des responsabilités. Chaque sujet a un pilote clair, identifié par tous.

Nous avons également créé un Conseil Technique, composé des leads techniques (devs, DevOps et Data). Son rôle est de prioriser, arbitrer et assurer la cohérence globale. Il sert aussi de point d’appui pour l’équipe produit, afin d’harmoniser les roadmaps techniques et fonctionnelles. Le but n’est pas de centraliser toutes les décisions, mais d’offrir un espace où elles peuvent être alignées, discutées et assumées.

Les guildes ont elles aussi été profondément repensées. Elles disposent désormais d’un périmètre défini, d’un lead identifié et de rituels réguliers. Leur mission n’est plus de faire du delivery, mais de cultiver la qualité, de partager les bonnes pratiques et d’accompagner la montée en compétence. C’est un changement de posture important.

Nous avons aussi clarifié la place de la QA, de la Data et des DevOps dans le cycle de delivery, pour que chaque métier soit impliqué au bon moment, pour les bonnes raisons. Ces trois équipes, désormais représentées au Conseil Technique, ne sont plus en marge. Elles sont devenues des acteurs à part entière de la tech chez Leocare.

Côté rituels, nous avons revu la manière de mener les revues techniques, les moments d’implication de DevOps et de Data, les processus de validation des PR, et même l’ownership des fonctionnalités. L’idée n’était pas de créer davantage de réunions, mais de structurer les moments qui comptent vraiment pour fluidifier la communication.

Enfin, nous avons acté que la roadmap de Leocare devait être co-construite entre le Conseil Technique et l’équipe produit. C’est un changement culturel autant qu’organisationnel. Cela permet de mieux anticiper les besoins du produit et d’atteindre un vrai équilibre entre technique et fonctionnel.

Ce que ça a changé

Concrètement, nous sommes passés d’une structure où chacun devait deviner qui faisait quoi, à un fonctionnement où les rôles sont explicites, les responsabilités distribuées et la collaboration facilitée.

Les squads fonctionnelles n’ont pas été bouleversées. Elles marchaient bien, et nous avons volontairement limité leur mutation. En revanche, les guildes ont désormais une vraie existence et une cohérence, notamment grâce au Conseil Technique qui leur offre un espace de décision et de mise en commun. Les DevOps, quant à eux, ne sont plus une équipe à part : ils sont pleinement intégrés à nos cycles produit et technique.

Et maintenant ?

Bien sûr, cette organisation n’a pas vocation à être figée. Une organisation tech fonctionne comme un système vivant : elle évolue au rythme du produit, des enjeux techniques et des équipes. Mais avec cette nouvelle structure, nous avons gagné en lisibilité, en cohérence et en capacité à décider.

Et c’est précisément ce dont nous avions besoin.