Apr\u00e8s trois ans de \u00ab\u00a0test & learn\u00a0\u00bb, le mod\u00e8le des squads nous convenait bien. C’\u00e9tait une m\u00e9canique qui tournait. Mais c\u00f4t\u00e9 technique, les frustrations s’accumulaient.<\/strong><\/p>\n\n\n\n Au fil du temps, trois familles de sujets techniques avaient \u00e9merg\u00e9, et elles ne se ressemblaient pas du tout.<\/strong><\/p>\n\n\n\n Il y avait d’abord les sujets qui pouvaient s’int\u00e9grer directement dans des features et avancer au rythme des squads.<\/strong> Aucun probl\u00e8me avec ceux-l\u00e0. Ensuite, il y avait les chantiers transverses ou de longue haleine :<\/p>\n\n\n\n Des sujets structurants, qui ne rentraient dans aucune feature. Et enfin, les travaux ponctuels mais critiques : des migrations, des mont\u00e9es de version de librairies, des \u00e9volutions d’infrastructure.<\/strong> Des choses qui ne peuvent pas attendre mais qui n’ont pas de propri\u00e9taire naturel.<\/p>\n\n\n\n Ces trois types de travaux ne demandaient ni les m\u00eames comp\u00e9tences, ni le m\u00eame degr\u00e9 de coordination, ni la m\u00eame temporalit\u00e9. Pourtant, ils atterrissaient tous au m\u00eame endroit : les guildes<\/strong>. Et celles-ci n’\u00e9taient ni structur\u00e9es ni anim\u00e9es de fa\u00e7on homog\u00e8ne. Elles fonctionnaient davantage comme des groupes de discussion informels<\/strong> que comme de v\u00e9ritables espaces de mont\u00e9e en comp\u00e9tence. Les guildes avaient besoin de se renforcer et de gagner en coh\u00e9rence.<\/p>\n\n\n\n \u00c0 cela s’ajoutait un ph\u00e9nom\u00e8ne r\u00e9v\u00e9lateur : la moiti\u00e9 des d\u00e9veloppeurs jouaient un r\u00f4le implicite de r\u00e9f\u00e9rent technique<\/strong>, souvent sans p\u00e9rim\u00e8tre clair ni responsabilit\u00e9 formellement d\u00e9finie. \u00c7a partait d’une bonne volont\u00e9, mais \u00e7a cr\u00e9ait \u00e9norm\u00e9ment d’ambigu\u00eft\u00e9. Qui d\u00e9cide ? Qui priorise ? Qui arbitre ? Comment assurer la coh\u00e9rence technique quand plusieurs personnes s’estiment responsables d’un m\u00eame p\u00e9rim\u00e8tre ? La v\u00e9rit\u00e9, c’est que quand tout le monde est responsable, personne ne l’est r\u00e9ellement<\/strong>.<\/p>\n\n\n\n Les silos entre \u00e9quipes ajoutaient une couche de complexit\u00e9. L’\u00e9quipe DevOps, par exemple, intervenait souvent trop tard dans les d\u00e9cisions. Le r\u00e9sultat : un manque d’anticipation, des contraintes techniques d\u00e9couvertes tardivement, et un sentiment g\u00e9n\u00e9ralis\u00e9 que chacun avan\u00e7ait dans sa propre temporalit\u00e9. <\/strong>Une \u00e9quipe trop loin des sujets fonctionnels et pas assez incluse dans les r\u00e9flexions globales.<\/p>\n\n\n\n C\u00f4t\u00e9 Data, la maturit\u00e9 et les besoins n’\u00e9taient pas align\u00e9s avec ceux des \u00e9quipes produit, ce qui cr\u00e9ait des d\u00e9calages d\u00e8s la conception. <\/strong>La QA, elle, arrivait parfois trop tard pour peser sur le design initial, avec des difficult\u00e9s r\u00e9currentes \u00e0 planifier et \u00e0 suivre l’\u00e9criture de tests automatis\u00e9s.<\/strong><\/p>\n\n\n\n Comme souvent chez Leocare, nous avons voulu mener cette r\u00e9flexion de mani\u00e8re collective. <\/strong>Toute la tech \u00e9tait invit\u00e9e, sur la base du volontariat, \u00e0 participer aux ateliers visant \u00e0 nous r\u00e9organiser.<\/p>\n\n\n\n Le timing n’\u00e9tait pas id\u00e9al sur le papier : en plein \u00e9t\u00e9, avec les vacances, les sessions se sont \u00e9tal\u00e9es sur deux mois. Mais avec le recul, \u00e7a n’a pas \u00e9t\u00e9 un frein, bien au contraire.<\/strong> Ce rythme nous a permis de m\u00fbrir notre r\u00e9flexion, de faire des allers-retours sur les propositions, et d’aboutir \u00e0 des d\u00e9cisions qui n’\u00e9taient pas prises dans l’urgence.<\/strong><\/p>\n\n\n\n Une fois les constats pos\u00e9s et les frustrations mises \u00e0 plat, l’ambition s’est clarifi\u00e9e d’elle-m\u00eame : r\u00e9duire les silos<\/strong> et clarifier la gouvernance de la roadmap technique<\/strong>.<\/p>\n\n\n\n Le premier changement, et sans doute le plus symbolique, a \u00e9t\u00e9 d’abandonner le mod\u00e8le des \u00ab\u00a0r\u00e9f\u00e9rents techniques globaux\u00a0\u00bb. Nous sommes all\u00e9s vers quelque chose de plus lisible : chaque chantier transverse est d\u00e9sormais port\u00e9 par une ou deux personnes d\u00e9di\u00e9es<\/strong>. Plus de dilution des responsabilit\u00e9s. Chaque sujet a un pilote clair, identifi\u00e9 par tous.<\/p>\n\n\n\n Nous avons \u00e9galement cr\u00e9\u00e9 un Conseil Technique, <\/strong>compos\u00e9 des leads techniques (devs, DevOps et Data). Son r\u00f4le est de prioriser, arbitrer et assurer la coh\u00e9rence globale.<\/strong> Il sert aussi de point d’appui pour l’\u00e9quipe produit, afin d’harmoniser les roadmaps techniques et fonctionnelles. Le but n’est pas de centraliser toutes les d\u00e9cisions, mais d’offrir un espace o\u00f9 elles peuvent \u00eatre align\u00e9es, <\/strong>discut\u00e9es et assum\u00e9es.<\/p>\n\n\n\n Les guildes ont elles aussi \u00e9t\u00e9 profond\u00e9ment repens\u00e9es. Elles disposent d\u00e9sormais d’un p\u00e9rim\u00e8tre d\u00e9fini, d’un lead identifi\u00e9 et de rituels r\u00e9guliers. Leur mission n’est plus de faire du delivery, mais de cultiver la qualit\u00e9, de partager les bonnes pratiques et d’accompagner la mont\u00e9e en comp\u00e9tence<\/strong>. C’est un changement de posture important.<\/p>\n\n\n\n Nous avons aussi clarifi\u00e9 la place de la QA, de la Data et des DevOps dans le cycle de delivery, pour que chaque m\u00e9tier soit impliqu\u00e9 au bon moment, pour les bonnes raisons<\/strong>. Ces trois \u00e9quipes, d\u00e9sormais repr\u00e9sent\u00e9es au Conseil Technique, ne sont plus en marge. Elles sont devenues des acteurs \u00e0 part enti\u00e8re de la tech chez Leocare.<\/p>\n\n\n\n C\u00f4t\u00e9 rituels, nous avons revu la mani\u00e8re de mener les revues techniques, les moments d’implication de DevOps et de Data, les processus de validation des PR, et m\u00eame l’ownership des fonctionnalit\u00e9s. L’id\u00e9e n’\u00e9tait pas de cr\u00e9er davantage de r\u00e9unions, mais de structurer les moments qui comptent vraiment pour fluidifier la communication.<\/strong><\/p>\n\n\n\n Enfin, nous avons act\u00e9 que la roadmap de Leocare devait \u00eatre co-construite entre le Conseil Technique et l’\u00e9quipe produit<\/strong>. C’est un changement culturel autant qu’organisationnel. Cela permet de mieux anticiper les besoins du produit et d’atteindre un vrai \u00e9quilibre entre technique et fonctionnel.<\/p>\n\n\n\n Concr\u00e8tement, nous sommes pass\u00e9s d’une structure o\u00f9 chacun devait deviner qui faisait quoi, \u00e0 un fonctionnement o\u00f9 les r\u00f4les sont explicites, les responsabilit\u00e9s distribu\u00e9es et la collaboration facilit\u00e9e<\/strong>.<\/p>\n\n\n\n Les squads fonctionnelles n’ont pas \u00e9t\u00e9 boulevers\u00e9es. Elles marchaient bien, et nous avons volontairement limit\u00e9 leur mutation. En revanche, les guildes ont d\u00e9sormais une vraie existence et une coh\u00e9rence, notamment gr\u00e2ce au Conseil Technique<\/strong> qui leur offre un espace de d\u00e9cision et de mise en commun. Les DevOps, quant \u00e0 eux, ne sont plus une \u00e9quipe \u00e0 part : ils sont pleinement int\u00e9gr\u00e9s \u00e0 nos cycles produit et technique.<\/p>\n\n\n\n Bien s\u00fbr, cette organisation n’a pas vocation \u00e0 \u00eatre fig\u00e9e. Une organisation tech fonctionne comme un syst\u00e8me vivant : elle \u00e9volue au rythme du produit, des enjeux techniques et des \u00e9quipes. Mais avec cette nouvelle structure, nous avons gagn\u00e9 en lisibilit\u00e9<\/strong>, en coh\u00e9rence<\/strong> et en capacit\u00e9 \u00e0 d\u00e9cider<\/strong>.<\/p>\n\n\n\n Et c’est pr\u00e9cis\u00e9ment ce dont nous avions besoin.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Trois ans apr\u00e8s \u00eatre pass\u00e9s du SCRUM au LEAN, nous \u00e9tions satisfaits. Les process \u00e9taient rod\u00e9s, les \u00e9quipes autonomes, le delivery fluide. Et puis, progressivement, de nouveaux signaux sont apparus. Des silos qui ralentissaient nos projets, un d\u00e9salignement croissant entre roadmaps produit et technique, des sujets d’architecture qui ne trouvaient pas leur place. Des probl\u00e8mes […]<\/p>\n","protected":false},"author":50,"featured_media":40632,"comment_status":"closed","ping_status":"closed","template":"","categorie_leocare_lab":[37],"class_list":["post-40626","leocare_lab","type-leocare_lab","status-publish","has-post-thumbnail","hentry","categorie_leocare_lab-developers"],"acf":[],"yoast_head":"\n![\"organisation](\"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/03\/organisation-leocare-avant-1024x1011.webp\")
<\/figure>\n\n\n\nCe qu’on a constat\u00e9<\/h2>\n\n\n\n
\n
![\"renforcer](\"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/03\/renforcer-la-coherence-technique.jpg\")
<\/figure>\n\n\n\nComment on a r\u00e9fl\u00e9chi<\/h2>\n\n\n\n
Ce qu’on a chang\u00e9<\/h2>\n\n\n\n
![\"avantages](\"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/03\/avantages-reorg-1024x801.jpg\")
<\/figure>\n\n\n\nCe que \u00e7a a chang\u00e9<\/h2>\n\n\n\n
![\"reorganisation](\"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/03\/reorganisation-apres-1024x925.png\")
<\/figure>\n\n\n\nEt maintenant ?<\/h2>\n\n\n\n