Ces dernières années, une nouvelle tendance a émergé dans le monde de l’IT : l’arrivée massive des coachs. Agile, DevOps, SRE… ces coachs viennent avec une promesse d’optimisation, de modernisation des processus et de performance accrue. Mais, est-ce vraiment le cas ? À travers mon expérience, j’ai souvent constaté le contraire. En tant que professionnel ayant plus de 14 ans d’expérience, j’ai eu l’occasion de travailler avec plusieurs types de coachs, et malheureusement, peu d’entre eux apportent une réelle valeur ajoutée à nos équipes.
L’illusion du coach
La première chose à comprendre, c’est pourquoi ces coachs sont introduits. La plupart du temps, ils sont imposés par les décideurs pour montrer que l’entreprise est à la pointe des tendances et des méthodes. Cela peut rassurer la partie prenante, mais sur le terrain, la réalité est toute autre. J’ai rencontré des coachs Agile, qui, au-delà d’un rôle de Scrum Master++ (gestion de réunion, gestion de backlog…), n’avaient jamais vraiment pris part à un projet de développement. Des coachs DevOps, qui n’avaient jamais construit un pipeline de déploiement, ou pire, des coachs SRE (Site Reliability Engineering) sans la moindre expérience en production.
Ce type de profil a souvent un discours bien rodé sur les “bonnes pratiques”, mais ne saisit pas les réalités techniques et opérationnelles des infrastructures complexes. Cela pose un véritable problème lorsque ces coachs commencent à évaluer ou proposer des changements sur des systèmes qu’ils ne maîtrisent pas.
Un cas concret : l’évaluation de notre datalake
Récemment, j’ai eu affaire à un coach SRE qui a voulu évaluer l’infrastructure dont je suis responsable. Son équipe avait préparé un formulaire standard d’évaluation, avec des notes allant de 0 à 4 sur différents axes, appliqué de manière uniforme à tous les projets. En théorie, c’est une bonne idée. Cependant, ils n’avaient pas adapté ce formulaire à la spécificité de notre produit phare : un datalake de 320 To avec réplication et sauvegardes journalières.
Pendant l’évaluation, j’ai soulevé la question des coûts. J’ai expliqué que, malgré les avantages d’un tel dispositif, nous étions en train d’étudier la suppression de certaines fonctionnalités comme le versionning des fichiers et les backups, car cela représentait une charge importante. L’idée était de réduire ces coûts tout en maintenant des objectifs de RTO et RPO raisonnables grâce à la réplication.
Au lieu de comprendre cette démarche d’optimisation, le coach m’a simplement informé que notre score allait chuter en dessous de la norme, sans tenir compte de l’équilibre nécessaire entre haute disponibilité et coût. C’était une incompréhension totale de la complexité de notre infrastructure et des compromis financiers qu’une entreprise doit parfois faire.
Un coach doit être un expert, pas un gestionnaire de formulaires
C’est là que réside le cœur du problème : un coach IT ne devrait pas être quelqu’un qui se contente d’appliquer des formules préétablies. Un bon coach est avant tout une personne ayant une solide expérience (idéalement 20 ans ou plus) dans divers environnements, avec une connaissance approfondie des problématiques de production. Sans cette expertise, le coach devient un obstacle plutôt qu’un atout, car il impose des standards qui ne correspondent pas à la réalité des projets.
Conclusion : Évaluez l’expérience avant d’embaucher un coach
Avant d’embaucher des coachs, il est essentiel que les décideurs s’assurent de leur véritable expertise. Avoir des certifications ou des années d’expérience en tant que consultant ne suffit pas. Ce qu’il faut, ce sont des personnes ayant vécu et surmonté des défis concrets sur le terrain. Sinon, c’est une perte de temps et d’argent, et cela peut même nuire à l’efficacité des équipes en place.
Le coaching est un excellent outil quand il est bien utilisé, mais imposer des coachs sans comprendre les besoins réels et les spécificités des infrastructures n’apportera jamais les résultats attendus.
