Il y a des années, j’ai passé une soirée entière sur un bug qui n’existait pas. Le code était correct. Les tests passaient. Le problème était ailleurs : deux équipes avaient chacune leur définition de ce que le logiciel devait faire, et personne ne l’avait remarqué. Ce soir-là, je n’ai rien corrigé dans le code. Mais quelque chose s’est déplacé dans ma tête. C’est probablement là qu’a commencé, sans que je le sache, ma reconversion de développeur vers le métier de facilitateur. On me demande souvent comment on passe du code à la facilitation. Voici ma réponse, la plus honnête possible.

Développeur : le confort du problème bien posé

J’ai aimé le développement. Sincèrement. Il y a dans ce métier une forme de justice immédiate : le code fonctionne ou il ne fonctionne pas. Le compilateur ne ménage personne, mais il ne ment jamais. Quand vous cherchez, vous trouvez. Quand vous corrigez, vous voyez le résultat.

Ce confort-là, je ne l’ai mesuré qu’en le perdant. Un problème technique est un problème bien posé : il a des conditions de reproduction, une cause, une solution. Vous pouvez le découper, l’isoler, le résoudre morceau par morceau.

Mais au fil des projets, une évidence s’est installée : les problèmes qui coûtaient le plus cher n’étaient presque jamais techniques. Les projets ne déraillaient pas à cause d’une mauvaise architecture. Ils déraillaient parce que deux responsables ne se parlaient plus, parce qu’une décision n’avait jamais été vraiment prise, parce qu’un besoin avait été compris de trois façons différentes par trois équipes.

Et face à ces problèmes-là, mon expertise technique ne servait à rien.

Le jour où j’ai compris que le blocage était humain

Le basculement ne s’est pas fait en un jour. Il s’est fait par accumulation de scènes comme celle-ci.

Une réunion de projet, classique. Deux développeurs s’affrontent sur un choix d’architecture. Les arguments fusent, techniques, précis, documentés. La réunion dure, s’envenime, se termine sans décision. On en reprogramme une autre.

Ce jour-là, quelque chose m’a frappé : le désaccord n’était pas technique. Les deux options se valaient à peu près. Ce qui se jouait, c’était autre chose. L’un des deux avait porté le système pendant des années et voyait la nouvelle proposition comme une remise en cause de son travail. L’autre venait d’arriver et avait besoin d’exister. Le vrai sujet, personne ne l’avait mis sur la table. Alors on parlait de bases de données.

Cette scène, je l’ai revue des dizaines de fois depuis, sous des formes différentes : dans des comités de direction, des équipes RH, des groupes projet. Le contenu change, la mécanique reste. Le blocage apparent est technique ou organisationnel ; le blocage réel est humain. Tant qu’on traite le premier sans toucher au second, on tourne en rond.

C’est cette prise de conscience qui a tout déclenché. Je passais mes journées à résoudre des problèmes de machines alors que les problèmes qui comptaient étaient des problèmes de personnes.

Coach agile : le premier pas hors du code

Je ne suis pas passé du clavier au paperboard du jour au lendemain. Il y a eu une étape intermédiaire, et elle a été décisive : le coaching agile.

L’agilité a été ma passerelle. Elle m’a permis de rester dans un univers que je connaissais — les équipes de développement, les projets logiciels — tout en changeant de posture. Je n’étais plus celui qui produit ; j’étais celui qui aide l’équipe à mieux produire ensemble. Rétrospectives, ateliers de cadrage, résolution de conflits d’équipe : j’apprenais un nouveau métier sur un terrain familier.

Cette étape m’a appris trois choses que je n’ai jamais oubliées :

  • une équipe qui parle de ses problèmes de fonctionnement avance plus vite qu’une équipe qui les évite, même quand la conversation est inconfortable ;
  • le cadre fait la moitié du travail : une question bien posée, un temps bien découpé, des règles claires produisent plus qu’une heure de discussion libre ;
  • ma retenue vaut plus que mes idées : chaque fois que je donnais la solution, l’équipe la portait moins que lorsqu’elle la trouvait elle-même.

Ce troisième point a été le plus difficile. Quand on a passé des années à être payé pour trouver des solutions, se taire est un apprentissage. J’y travaille encore.

Puis le périmètre s’est élargi. On m’a demandé d’animer des ateliers hors des équipes techniques : des séminaires, des comités, des groupes de travail sur des sujets qui n’avaient plus rien à voir avec le logiciel. Et j’ai découvert que la mécanique était la même partout. Un comité de direction qui n’arrive pas à trancher ressemble beaucoup à une équipe de développement qui n’arrive pas à choisir une architecture. Les enjeux diffèrent, les dynamiques se ressemblent.

La pensée visuelle : le déclic de ma reconversion de facilitateur

Il manquait une pièce, et elle est arrivée par le dessin.

Dans un atelier, face à un groupe qui s’enlisait dans une discussion abstraite, j’ai pris un feutre et j’ai dessiné ce que j’entendais : les acteurs, les flux, les points de friction. Rien de sophistiqué — des boîtes, des flèches, quelques pictogrammes maladroits. L’effet a été immédiat. Le groupe s’est levé, s’est approché du mur, a corrigé le schéma : « Non, ce n’est pas comme ça, c’est plutôt ici que ça coince. » En dix minutes, nous avions ce que deux heures de discussion n’avaient pas produit : une représentation partagée du problème.

Ce jour-là, j’ai compris que mes années de développeur ne partaient pas à la poubelle. Modéliser un système, c’est exactement ce que fait un développeur toute la journée : prendre une réalité floue et la traduire en structure claire. La facilitation graphique m’a permis de faire la même chose, mais avec un groupe, en direct, sur un mur plutôt que dans un fichier.

Le dessin a un pouvoir que la parole n’a pas : il externalise le désaccord. Quand deux personnes s’opposent verbalement, elles se font face. Quand elles regardent ensemble un schéma au mur, elles se tiennent côte à côte, tournées vers le problème. Ce simple déplacement change la nature de la conversation. Je m’en sers désormais dans presque tous mes ateliers.

Ce que le code m’a laissé

On pourrait croire qu’une reconversion efface le métier d’avant. C’est l’inverse. Mon passé de développeur irrigue ma pratique de facilitateur tous les jours. Voici ce qu’il m’a laissé :

  • le goût du problème bien posé : avant de chercher une solution, je passe du temps à formuler la question, parce qu’une question floue produit des réponses floues ;
  • la culture du test : je ne suppose jamais qu’un atelier va fonctionner, je le prototype, je l’ajuste, j’itère ;
  • la décomposition : un sujet trop gros pour être traité se découpe en sous-ensembles traitables, comme un programme se découpe en fonctions ;
  • l’attention aux détails d’exécution : en facilitation comme en code, ce sont les petites choses mal réglées — une consigne ambiguë, un timing bâclé — qui font échouer l’ensemble ;
  • l’humilité devant les systèmes complexes : un groupe humain, comme un système informatique, réagit rarement comme prévu, et c’est en observant qu’on comprend, pas en théorisant.

Cette manière de travailler — structurer fort pour libérer la parole, tester plutôt que supposer — est devenue le cœur de mon approche. Elle doit tout à mes deux métiers.

Ce que cette reconversion m’a appris sur le changement

Si vous lisez ceci en vous interrogeant sur votre propre trajectoire, ou sur celle d’un collaborateur, voici ce que mon expérience m’autorise à dire.

Une reconversion réussie ne renie pas le métier d’origine : elle le recycle. Je n’ai pas cessé d’être développeur pour devenir facilitateur ; j’ai déplacé mes compétences d’un objet — le code — vers un autre — les groupes. Les personnes qui changent de métier avec le plus de justesse sont souvent celles qui identifient ce fil de continuité, plutôt que celles qui cherchent une rupture totale.

Ensuite, le déclic vient rarement d’une réflexion abstraite. Il vient d’expériences concrètes : une réunion qui déraille, un dessin qui débloque, une équipe qui se transforme sous vos yeux. Si vous hésitez sur une orientation, multipliez les occasions de tester plutôt que les heures de réflexion.

Enfin, changer de métier prend du temps, et c’est une bonne nouvelle. Chaque étape de mon parcours — développeur, coach agile, facilitateur — a nourri la suivante. Rien n’a été perdu. Le reste de cette histoire, et ce qu’elle dit de ma façon de travailler aujourd’hui, se trouve sur ma page de présentation.

Vous traversez vous-même une transition professionnelle, ou vous accompagnez une équipe qui change ? Prenez rendez-vous pour en parler, ou découvrez mon offre de coaching professionnel.