Quelques réflexions sur le métier de consultant
Depuis que j'ai rejoint OCTO Technology en 2015, quand je me présente professionnellement je dis que je suis "consultant". Avant ça, j'ai travaillé 15 ans chez des éditeurs de logiciels et je me présentais comme "programmeur".
Ça va bientôt faire 10 ans que je dis "consultant", et j'ai envie de me demander ce que ça veut dire pour moi aujourd'hui. Je propose de passer en revue quelques raisons. Il y en aurait sans doute beaucoup d'autres, mais chercher à être exhaustif ne serait pas très intéressant.
Ce que veux dire pour moi d'être "consultant"
Quand je dis "consultant", dans mon contexte ça veut dire "consultant en informatique". C'est un peu plus précis, mais "informatique", ça reste vague. Et pourquoi "consultant", et pas "prestataire" par exemple ?
Programmeur·ses ⊂ Prestataires ⊂ Consultant·es
Le premier point auquel je pense, c'est que dans mon contexte, celui des missions de delivery logiciel, les prestataires sont aussi des programmeurs et programmeuses, et les consultant·es sont aussi des prestataires. Je simplifie, car chez OCTO on a des consultant·es qui ne font pas ou peu de programmation. Par exemple des Architectes, UX, Product Owner, Coach, ...
Variété des missions
En tant que consultant ou prestataire, j'ai l'occasion de travailler sur plus de projets, car on est plus souvent amené·es à changer de mission et donc de projet qu'une personne interne, qui restera souvent plus longtemps sur le même projet.
Et donc j'ai l'occasion de travailler dans plus d'équipes, ça me permet d'ouvrir mes horizons et de découvrir d'autres façons de travailler.
Cette variété des missions fait qu'en tant que prestataire ou consultant je peux apporter un regard neuf, différent de celui des personnes qui se seront habituées à certaines incohérences et qui ne les voient plus.
Je peux apporter des éléments nouveaux dans une équipe, ou parfois venir confirmer des choses déjà connues, les deux sont utiles.
Le revers de la médaille, c'est que si on change de projet trop souvent, parfois on ne voit pas les conséquences à long terme des choix de l'équipe. Pour cette raison, je veille à faire régulièrement des missions longues, et à ne pas me contenter d'enchaîner les missions de 6 mois. C'est cet équilibre entre mission courtes et longues qui me convient.
Les consultant·es sont consulté·es
Une autre facette de la variété des missions, qui va être un peu différent de la posture classique de prestataire, c'est qu'en tant que consultant on me consulte. En plus des missions de delivery, j'ai régulièrement l'occasion de faire des missions où on me demande mon avis sur quelque-chose. Par exemple des audits de code, des revues d'architecture, des cadrages de missions. Je donne également des formations à des groupes.
C'est alors d'autant plus important pour moi d'être capable d'écouter (ne pas oublier cette partie !), d'expliquer, de vérifier qu'on se comprend le mieux possible, et de convaincre (ça en général on s'en souvient bien).
Note : ça ne veut pas dire qu'en tant que prestataire ou programmeur je ne donnerais pas mon avis et que je ne vais pas écouter ou convaincre, mais ça veut dire qu'en tant que consultant on a plus souvent des missions où ça fait explicitement partie des attentes.
On utilise beaucoup l'intelligence collective
Ce n'est pas forcément plus vrai que dans les autres postures, mais là encore, souvent ça fait explicitement partie de ma mission.
Et comme on arrive avec un regard externe, on prendra plus facilement la posture de facilitateur, avec plus de détachement.
Quelques astuces de consultant·es
Voilà quelques astuces que j'utilise souvent. On pourrait en lister beaucoup d'autres, et ce n'est en rien un résumé des activités du métier de consultant·e. Ce sont plutôt des choses que je vois revenir encore et encore dans la pratique de mon métier, et qui seront utiles pour toute activité où on travaille à plusieurs et où il est important de se comprendre.
Commencer par expliciter l'agenda
Quand on commence un travail à plusieurs en synchrone (réunion, atelier, ...), j'apprécie beaucoup quand on commence par préciser l'agenda, le déroulé à grosse maille, la liste d'étapes qu'on va suivre.
Ça permet aux personnes qui participent de se projeter, de savoir où en est de la réunion / de l'atelier, et d'anticiper un peu comment elles pourront participer ou ce qu'elles pourront apprendre. Également, de vérifier qu'elles sont au bon endroit et ne vont pas perdre leur temps.
Communiquer les heures de début et de fin
En plus d'avoir un agenda de réunion clair, quand j'anime un travail collectif je précise le plus tôt possible la plage de temps qu'on s'accorde pour ce travail. Juste après l'agenda par exemple, ou pourquoi pas avant.
J'aime bien préciser également les horaires approximatifs des pauses si le travail dure plus d'une heure trente.
Ça permet aux personnes qui participent de savoir :
- Qu'on ne rentre pas dans un tunnel sans fin
- À quelle heure environ elles pourront passer un appel ou aller fumer par exemple
- Que leur organisation de déjeuner ou de fin de journée est compatible avec ce travail, et de s'organiser tout de suite si ce n'est pas le cas
Ça apporte tout de suite des réponses à des questions que beaucoup de personnes se posent, et ça permet de mieux se concentrer sur ledit travail.
Rendre visible les conversations
C'est dans une formation donnée par Alberto Brandolini que j'ai compris l'importance de ce point, et depuis je ne peux plus le dé-voir.
Parfois, quand on anime un travail collectif, on voit un groupe qui parle beaucoup et qui semble tourner en rond. Dans ce cas, je leur demande de rendre visible leur conversation, de la poser sur une table pour qu'on puisse regarder la même chose ensemble.
Par exemple en écrivant sur des post-its ou un tableau blanc si on est en présentiel. À distance j'utilise Miro, Excalidraw, ou un document texte collaboratif.
Quelques phrases que j'utilise :
- J'aime bien la façon dont tu viens de dire ça, est-ce que tu pourrais l'écrire ?
- Comment est-ce qu'on pourrait écrire ce qu'on vient de dire ?
Le fait de rendre cette conversation visible permet aux personnes de vérifier qu'elles se comprennent, de repérer les ambiguïtés, de choisir quoi creuser maintenant, et d'arrêter de tourner en rond.
Conclusion
Dans mon contexte, je suis à la fois consultant, prestataire, et programmeur. Et j'ai partagé quelques raison pour lesquelles ça a du sens pour moi de dire que je suis consultant aujourd'hui. Il y a évidemment d'autres raisons qu'on pourrait lister, et beaucoup d'autres définitions du job de consultant, probablement très différentes de ce que j'ai proposé.
J'espère également que les quelques astuces partagées en deuxième partie d'articles seront utiles pour vos réunions et ateliers.