Coach ou consultant ?

Dans l'industrie du développement logiciel, ces termes sont peu ou pas définis. Nombre de personnes les emploient indifféremment, tandis qu'ils me semblent désigner des modalités d'intervention distinctes.

Comme beaucoup, je suis venu au coaching "par glissement", parce que mon expertise technique était reconnue. Mais être porteur d'une expertise et savoir la transmettre sont deux choses bien différentes, quand d'ailleurs le sujet n'est peut-être pas toujours de transmettre cette expertise (nous y reviendrons).

Ma pratique du coaching consiste à éclairer les décisions, petites et grandes, de mes clients. Il y a donc une dimension "formation", mais surtout "service après-vente" de la formation, pour aider ces organisations à passer de la théorie à une pratique quotidienne. La pratique suppose des choix, chose que l'on perçoit assez bien dès que l'on parle concrètement d'agilité (faire des sprints ? des estimations ?), de stratégie de tests (quels tests ?) ou bien encore de refactoring (quelle stratégie ?) J'aide donc mes clients à se poser les bonnes questions et à appréhender toutes les dimensions du problème.

En revanche, j'évite d'apporter des réponses. À cela 2 raisons :

1. Si le client n'est pas acteur de sa propre décision, s'il fait les choses "parce que Mathieu a dit que c'était mieux ainsi", cette décision aura l'effet d'un pétard mouillé. Il ne déploiera pas l'énergie nécessaire pour la mettre en œuvre et en tirer le meilleur parti malgré les obstacles qui se présenteront sur sa route. À la première difficulté, il remettra la décision en question parce que, au fond, ce n'était pas la sienne. Je préfère que le client prenne sa propre décision, peut-être différente de celle que j'aurais prise à sa place, qu'il mène sa propre expérience, en tire les conclusions et itère. En clair, je fais confiance à mon client.

2. Tout le problème est que, justement, je ne suis pas à la place de mon client. Même si je prends en compte les forces à l'œuvre, je ne fais pas partie de l'entreprise, je ne vis pas son quotidien et ne suis donc que partiellement informé. D'autre part, je valorise les avantages et inconvénients des décisions qui sont prises à ma manière (qui, a priori, n'est pas celle de mon client) et ne subis pas les conséquences de ces décisions. Mais surtout, ma connaissance de son histoire est partielle. Ce point est déterminant parce que si certains axes d'amélioration semblent évidents pour un œil extérieur, leur mise en œuvre s'apparente souvent à une révolution. Parfois il faut faire la révolution, d'autres fois il faut faire une révolution de velours.

Ma pratique de consultant est toute autre : en tant que consultant, j'apporte des réponses, en n'oubliant pas d'expliciter mes raisonnements. Je réserve cette approche à des sujets épineux et particulièrement engageants pour l'entreprise, telle la modularisation des systèmes d'information, sujet sur lequel l'erreur coûte cher. Je m'efforce toutefois d'associer mes interlocuteurs à la démarche, parce qu'il est important qu'ils soient convaincus que la cible que nous définissons est la bonne, vu le coût ultérieur du refactoring. Cela se traduit en général par une journée de formation initiale sur la partie stratégique du Domain-driven design, puis la constitution d'un groupe de travail à effectif réduit incluant les 2 ou 3 personnes qui porteront la démarche en interne une fois ma prestation achevée.

Ces différents positionnements sont complémentaires. À chacun d'expérimenter, de s'adapter et de s'organiser pour porter un regard réflexif sur son activité (échange entre pairs, supervision…) Cette dimension réflexive est essentielle à mes yeux, tant le risque est grand dans ces métiers de l'humain de nuire en cherchant à bien faire.