Portfolio
Voici des accompagnements que j’ai réalisés, organisés par type de blocage. Vous y reconnaissez-vous ?
Tous les cas présentés ici sont anonymisés : secteurs généralisés, chiffres arrondis, détails identifiants retirés. Ce qui est préservé, c’est la dynamique réelle de chaque situation.
🤝 Résolution de conflit
Trois rôles bloqués dans leur paradigme, jusqu'à retrouver un dialogue commun
Project manager, scrum master et product owner reprenaient chacun le contrôle à leur façon, jusqu’à ce que la crise remonte au top management. Aujourd’hui, ils co-construisent ensemble.
▸
Voir le cas complet
Le point de départ
Une tension entre la project manager d’un côté, le scrum master et le product owner de l’autre, avait dégénéré progressivement sur la manière de gérer le projet.
Ce qui avait déjà été tenté
Chacun·e reprenait le contrôle à sa façon : le scrum master imposait sa manière de mesurer l’avancement, le product owner écartait la project manager du projet, qui répondait par un email hebdomadaire à toute l’équipe pour obtenir un statut. Chaque tentative renforçait la méfiance des autres, jusqu’à ce que la crise remonte au top management.
Mon intervention
J’ai rencontré chacun·e individuellement pour comprendre ce qui coinçait, puis clarifié les besoins du projet avec le scrum master et le product owner. Une proposition de stratégie a été présentée à la project manager, en ma présence, pour l’adapter et créer un alignement à trois. Une réunion bimensuelle avec les 3 personnes a ensuite pris le relais pour suivre les initiatives et construire une compréhension commune.
✅ Chaque personne a trouvé son rôle et appris à faire de la place aux autres
✅ Chacun·e a le réflexe de donner la parole à la bonne personne selon les sujets
✅ Les besoins sont exprimés et des solutions sont trouvées ensemble
✅ Un plan de budget supplémentaire a été co-construit et présenté au top management en trio
Une équipe divisée par un conflit, jusqu'à ce que les deux clans se reparlent
Un conflit entre deux collègues avait escaladé jusqu’à diviser toute une équipe de 10 personnes, et la prochaine intervention envisagée par le management risquait d’aggraver la situation. Aujourd’hui, les deux protagonistes se parlent et collaborent à nouveau.
▸
Voir le cas complet
Le point de départ
Un conflit entre deux collègues a escaladé jusqu’à impacter toute l’équipe de 10 personnes : des clans se sont formés et des membres ne savaient plus comment naviguer dans cette ambiance dégradée. Les autres équipes ont commencé à ressentir le conflit au point d’impacter la collaboration.
Ce qui avait déjà été tenté
Le management avait tenté des interventions directes auprès de certains membres, notamment en renforçant le lien avec une personne clé. Ce rapprochement a créé un questionnement dans l’équipe : est-ce que cette personne devient notre chef ? La prochaine intervention envisagée était frontale, ce qui risquait d’aggraver encore la situation.
Mon intervention
J’ai d’abord travaillé avec les managers pour trouver une manière de participer à la solution sans l’imposer, puis présenté le cadre d’intervention à toute l’équipe en insistant sur le fait que la solution viendrait d’eux. Après des entretiens individuels avec toutes les personnes concernées, j’ai présenté mon diagnostic systémique à l’équipe, au management et aux RH, avec des directions possibles pour réparer les liens. Un accompagnement individuel des personnes clés a été mis en place sur plusieurs mois pour les aider à traverser le conflit sans se trahir et recréer une dynamique collaborative.
✅ Des personnes ont créé des ponts entre les deux clans, permettant le rapprochement des deux protagonistes
✅ Les deux protagonistes se parlent à nouveau et collaborent, à la surprise du management
✅ Le management a revu sa posture en comprenant comment celle-ci peut prévenir ou encourager un conflit
✅ Le management a maintenant le réflexe de faciliter le dialogue pour faire émerger des solutions en cas de conflit
Deux équipes qui se blâmaient, jusqu'à ce qu'elles se redécouvrent
Une équipe performante reprochait à une équipe transversale d’être lente et de ne pas répondre à ses besoins. À la fin de l’atelier commun, une personne a déclaré : “j’ai découvert de nouveaux collègues.”
▸
Voir le cas complet
Le point de départ
Une équipe plutôt performante devait collaborer avec une équipe transversale, jugée lente et peu réactive à ses besoins. L’équipe performante avait l’impression de ne pas être prise en compte et commençait à blâmer l’équipe transversale.
Ce qui avait déjà été tenté
Le management avait tenté de guider les personnes individuellement quand des plaintes remontaient, voire de pousser certaines priorités pour s’assurer qu’elles soient traitées. Mais ça ne réglait pas le problème de fond : la dynamique restait.
Mon intervention
Une manager est venue me voir pour discuter de la manière d’aborder le problème. Elle voulait rassembler les deux équipes pour trouver un terrain d’entente, sans arriver avec une solution toute faite. Plutôt que d’intervenir moi-même, je l’ai guidée dans la mise en place d’un cadre restauratif : elle a planifié une réunion de 2 heures avec les deux équipes, en leur demandant de préparer des réponses à 4 questions issues de la concertation restaurative. Elle a ouvert la réunion en clarifiant les besoins de son organisation et ses craintes face à la dynamique en place. Chaque équipe a ensuite exposé ses réponses, une par une, pour créer une compréhension commune de ce que l’autre vivait. La réunion s’est conclue par un plan d’action commun pour améliorer la collaboration.
“J’ai découvert de nouveaux collègues” — un·e participant·e, à la fin de l’atelier
✅ Les deux équipes ont trouvé une dynamique commune
✅ Ce qui devait être livré a pu l’être dans les temps
✅ La manager a acquis de nouveaux outils pour faciliter l’environnement de travail de ses équipes
🌱 Transition durable
Un scrum master qui portait tout, jusqu'à ce que son équipe apprenne à décider seule
Un scrum master devenu indispensable, trop interventionniste, empêchait sans le vouloir son équipe de se développer. Aujourd’hui, l’équipe prend ses décisions sans attendre sa validation.
▸
Voir le cas complet
Le point de départ
Un scrum master a voulu renverser une tendance dans laquelle il se sentait coincé : il prenait beaucoup de sujets en main et devenait donc indispensable. Il s’impliquait aussi personnellement dans les résultats de ses facilitations au point de devenir trop interventionniste, ce qui empêchait l’équipe de se développer.
Mon intervention
Le travail a porté sur la posture, en nous basant sur des cas concrets en cours. Nous avons exploré différentes manières d’intervenir adaptées à différentes situations, en nous attardant notamment sur ses interactions avec son équipe, mais aussi lors de facilitations d’ateliers pour d’autres équipes dans l’organisation.
✅ Le scrum master laisse son équipe s’exprimer plus
✅ Une personne discrète dans l’équipe a commencé à prendre la parole lors des réunions
✅ Un membre senior a naturellement laissé plus de place suite à l’exemple donné par le scrum master
✅ Le scrum master jongle consciemment entre différentes postures selon le contexte
✅ L’équipe prend des décisions sans attendre la validation du scrum master
✅ Le scrum master fait confiance dans les décisions prises par son équipe
Une équipe sous pression que plus personne n'arrivait à débloquer, jusqu'à ce qu'on arrête d'intervenir
Une équipe accumulait les retards malgré une succession de scrum masters et de plans de redressement. Le déblocage est venu d’une décision à contre-courant : arrêter d’intervenir.
▸
Voir le cas complet
Le point de départ
Une équipe de développement accumule les retards. Quand le dernier scrum master en poste est renvoyé, la question revient : qui mettre à la place ?
Ce qui avait déjà été tenté
Le management réagissait en imposant un reporting régulier et en faisant se succéder les scrum masters pour redresser la situation. Chaque nouveau scrum master arrivait avec un plan. Rien ne changeait.
Mon intervention
J’ai proposé une approche différente : ne pas mettre quelqu’un à la place, et annoncer clairement à l’équipe qu’elle allait être laissée tranquille. Cette décision délibérée et expliquée à l’équipe a permis de couper le cycle pression-intervention-échec dans lequel tout le monde était enfermé. L’hypothèse était que la pression elle-même faisait partie du problème.
✅ L’équipe a retrouvé de la sérénité sans qu’on le lui demande
✅ Les premières livraisons sont apparues, sans plan ni reporting supplémentaire
✅ Le management a compris que son mode d’intervention faisait partie du problème
Un créateur enfermé dans des process qui ne tenaient jamais, jusqu'à trouver une organisation qui lui ressemble
Système de classement, agenda, tableau kanban : aucune de ces solutions n’a tenu plus de quelques semaines. La bonne organisation n’était pas un nouveau process, mais un fonctionnement plus proche de qui il est.
▸
Voir le cas complet
Le point de départ
Un créateur me contacte pour un problème d’organisation : ses tâches finissent systématiquement traitées en dernière minute, avec la crainte de faire des erreurs. Il cherche donc un nouveau process qui fonctionnerait enfin.
Ce qui avait déjà été tenté
Il avait déjà mis en place un système de classement de ses documents, qui s’est retrouvé très vite désordonné. Il inscrivait des deadlines dans un agenda pour se forcer à traiter les tâches à temps, mais il ne les respectait pas vraiment. Il a aussi essayé d’utiliser un tableau kanban qui, très vite, ne reflétait plus la réalité.
Mon intervention
J’ai exploré avec lui son environnement de travail, ses interactions avec son entourage et les administrations, ainsi que ce qui l’anime dans son activité. Cette exploration a révélé que le système qu’il essayait d’imposer répondait moins à ses propres besoins qu’à une injonction sociale (“il faut être organisé”), en décalage avec ses dynamiques naturelles de travail. En revenant à ce niveau, nous avons pu tester une organisation plus organique, ajustée à sa façon réelle de fonctionner.
✅ Une organisation qui suit son fonctionnement naturel plutôt qu’un modèle emprunté
✅ Quasiment plus de tâche traitée en dernière minute
✅ Une légitimité retrouvée à travailler à sa manière, sans avoir à se justifier
🧭 Changement de rôle
Une nouvelle mentor, déjà experte de son métier
Business analyst expérimentée, il lui restait à construire son expertise d’accompagnement, sur un temps limité. Aujourd’hui, l’équipe business collabore beaucoup plus avec le développement.
▸
Voir le cas complet
Le point de départ
Un département business peinait à trouver une manière de travailler adaptée à la transformation agile de son organisation. Le management a créé un poste de mentor pour accompagner l’équipe des business analysts. Une analyste expérimentée a postulé et obtenu le poste : elle avait l’expertise du métier, mais peu d’expérience pour accompagner efficacement une équipe sur un temps limité.
Ce qui avait déjà été tenté
En prenant ses fonctions, elle avait pour réflexe d’expliquer aux mentoré·es ce qu’il fallait faire, voire de faire les analyses à leur place quand elles n’avançaient pas assez vite. Ça la rassurait sur le résultat, mais l’équipe restait dépendante d’elle plutôt que de monter en compétence.
Mon intervention
En partant de ce réflexe, nous avons d’abord clarifié ses objectifs : ce qu’elle attendait de l’équipe, et ce que l’organisation attendait d’elle, pour nous assurer que les deux étaient alignés. Elle a appris à être transparente avec les mentoré·es sur ces objectifs. Nous avons aussi travaillé sa posture, pour distinguer les moments où elle montre en faisant elle-même, ceux où elle accompagne un·e mentoré·e dans la réalisation de son travail, et ceux où elle se limite à poser des questions pour que les mentoré·es trouvent eux-mêmes les réponses, plutôt que de rattraper l’équipe à chaque fois.
✅ Elle a appris à jouer consciemment avec ces différentes postures
✅ L’équipe business a gagné en ownership sur ses analyses
✅ L’équipe business collabore beaucoup plus avec l’équipe de développement
✅ Le management voit une réelle évolution de ses employé·es dans leur manière de travailler
Coincée entre business et IT, jusqu'à devenir le pont entre les deux
Entre l’analyse et le product ownership, elle cherchait sa place, tandis que l’équipe de développement remettait en question ses priorités. Aujourd’hui, elle est le pont dont les deux ont besoin.
▸
Voir le cas complet
Le point de départ
Une business analyst dans une équipe IT devait prendre un rôle de proxy product owner. L’équipe de développement ne semblait pas suivre sa stratégie et remettait en question certaines priorités, et elle n’arrivait pas à cerner son propre rôle, entre analyste et product owner. En explorant son environnement de travail et ses interactions, nous avons découvert qu’elle jouait souvent la messagère entre le business et l’équipe de développement, et se retrouvait prise entre les deux.
Mon intervention
Nous avons travaillé son rapport avec l’équipe de développement, en particulier sur ce que portaient leurs remises en question : nous avons découvert que l’équipe se souciait aussi du business, et que ça valait la peine de prendre ces remarques en compte plutôt que de les percevoir comme une résistance. Pour cerner son rôle, elle a posé la question de manière transparente à l’équipe, qui a pu lui dire comment elle la voyait et l’asseoir dans son rôle de proxy product owner. Elle a aussi été encouragée à être moins dans les analyses et plus dans une posture de pont entre le business et l’IT.
✅ Les remises en question sont devenues de la concertation, au service d’un produit qui répond réellement au besoin
✅ Le business la considère comme essentielle pour faire le lien avec l’IT
✅ Elle assume pleinement son rôle de proxy product owner, et ses conseils sont écoutés
✅ Sa vision globale sert désormais l’IT et le business pour prendre de meilleures décisions
Une de ces situations vous ressemble ?
30 minutes pour comprendre votre contexte et voir ce qui serait utile, gratuit et sans engagement