Dépendance vis-à-vis des techniciens indispensables dans un MSP : comment la réduire

Dans Star Trek, lorsque le capitaine Kirk avait besoin de l’impossible, il se tournait toujours vers Scotty. Seul Scotty savait tirer le meilleur parti des cristaux de dilithium, seul il comprenait les entrailles de l’Enterprise et seul il pouvait accomplir le miracle salvateur au dernier moment, contre vents et marées. Quelque chose de brillant pour la télévision, mais un désastre comme modèle opérationnel. Car si Scotty attrapait la grippe klingon, tout le vaisseau dérivait à la dérive.

La même chose se produit dans trop de MSP. Nous avons notre Scotty particulier — ce technicien brillant capable de porter la moitié du portefeuille clients sur ses épaules — et nous le célébrons peut-être même comme un atout parce que nous avons un génie inimitable dans nos effectifs. Mais comme nous allons le voir, il s’agit en réalité d’un point de défaillance humain unique qui nous empêche de monter en charge en toute sécurité.
La spécialisation technique est précieuse, cela est indéniable, mais lorsqu’elle franchit la frontière de la dépendance excessive envers des individus précis, elle cesse de l’être. Et la différence entre spécialisation et dépendance est un défaut de conception opérationnelle, non un problème de talent ni de ressources humaines.

Ce que signifie réellement dépendre de techniciens indispensables

Nous souffrons d’une dépendance opérationnelle lorsque le fonctionnement quotidien du MSP gravite autour d’individus précis, plutôt que de processus partagés.
C’est la prémisse fondamentale, car si le savoir critique réside dans les têtes de ces génies — et non dans la base de connaissances ou réparti parmi les autres techniciens — notre quotidien se compose généralement de :

• Des clients que seule une personne « comprend ». Parce que personne d’autre n’a touché à cette infrastructure, ni ne sait par où commencer, faute de documentation dans le wiki interne.
• Des tâches critiques de maintenance qui ne sont elles non plus documentées nulle part, sauf dans la mémoire de celui qui les réalise depuis trois ans.
• Des incidents systématiquement escaladés au même technicien. Non pas parce que c’est la procédure, mais parce que notre Scotty particulier est le seul à savoir les résoudre.
• Des connaissances opérationnelles éparpillées. Vivant dans des chats WhatsApp, des notes mentales, des post-its et ce carnet que Laura porte toujours avec elle, mais dont le contenu arcane n’apparaît dans aucune base de connaissances partagée.

Si cela nous définit, nous ne sommes pas spéciaux, quoi qu’on nous ait dit à l’école. Il s’agit d’un schéma structurel qui se répète avec insistance dans de nombreux MSP et que nous devons traiter avant qu’il n’explose entre nos mains.

Les signes qu’un MSP a déjà ce problème

Les humains ont une capacité maîtresse, l’adaptation, laquelle joue ici contre nous, car ce qui rend la dépendance dangereuse, c’est qu’elle se normalise.
Comme la grenouille plongée dans l’eau chaude, nous nous habituons sans rien faire jusqu’à ce qu’elle finisse par bouillir autour de nous.
Cependant, il existe des symptômes clairs que nous devons passer à une autre façon de faire si nous prenons la peine de regarder honnêtement et de ne pas enfouir la tête dans le sable :
Les principaux sont :

• Des tickets bloqués pendant des heures ou des jours jusqu’à ce qu’un technicien précis prenne son service ou revienne de vacances.
• Un onboarding de nouveaux profils qui s’éternise, car les connaissances nécessaires ne sont pas écrites ni partagées. Elles restent piégées dans des conversations informelles et l’expérience accumulée des vétérans.
• Des vacances ou des arrêts maladie qui ralentissent les opérations et génèrent de la nervosité au sein de l’équipe.
• Des clients ou des environnements que personne ne peut assumer sereinement, sauf les habituels, transformant chaque absence en une roulette russe avec le SLA.
• Une documentation qui existe, mais est si générique ou si dépassée qu’elle est inutile pour les opérations quotidiennes.
• Une dépendance chronique à l’historique informel. « Demande à Marcos, c’est lui qui a monté ça. » Si nous entendons souvent ce genre de phrase depuis notre bureau, nous avons un problème.

L’impact de la dépendance sur les SLA, la scalabilité et la rentabilité

La dépendance envers des techniciens indispensables est un bâton dans les roues du fonctionnement quotidien, mais aussi une hémorragie opérationnelle qui affecte directement l’entreprise et ses résultats.

Les goulots d’étranglement

Si seul le génie du moment peut résoudre certains types d’incidents, le temps de résolution dépend de sa disponibilité, alors qu’il devrait être en adéquation avec la gravité du problème.
Lorsque cela se produit, le Temps Moyen de Réparation (MTTR selon son acronyme anglais) s’emballe pour des raisons qui ont peu à voir avec la complexité technique, et beaucoup avec le fait que le savoir est enfermé sous sept verrous dans une tête à laquelle on pourrait proposer un meilleur salaire ailleurs dès demain.

Les escalades inutiles

Des techniciens de niveau 1 qui pourraient parfaitement résoudre un incident le transfèrent constamment à l’« expert », parce que personne ne leur a fourni le contexte nécessaire pour le résoudre.
Là encore, ce n’est pas une question de manque de capacité chez ces techniciens juniors, mais un mauvais design des opérations du MSP.
Cela embourbe les seniors dans des tâches à faible valeur ajoutée. Ou comme je l’ai mentionné parfois, nous utilisons des Ferrari pour aller au supermarché — elles consomment trop et ne sont ensuite plus disponibles pour l’essentiel.

Incapacité à absorber les pics de charge ou les absences

Si deux personnes concentrent 80 % des connaissances critiques et que l’une tombe malade pendant que l’autre est en vacances, l’opération vacille comme un château de cartes.
Et cela sans même évoquer la rotation du personnel. Car lorsque l’un de ces génies décide de partir vers des horizons qu’il estime plus verts, il arrache un morceau de notre capacité opérationnelle qui nous laisse gravement blessés.

L’impossibilité de monter en charge de façon robuste

Parce que chaque nouveau client augmente la charge sur les mêmes épaules qu’à l’accoutumée, et que les épaules solides ne sont pas légion dans le secteur informatique.
C’est ainsi que nous ne grandissons pas — nous grossissons et devenons plus fragiles. Nous avons un château plus grand, mais il est en verre. Ainsi, l’efficacité opérationnelle se dégrade à chaque nouveau contrat que nous fêtons au champagne au départ, pour ensuite le gérer avec des doses malsaines de stress.

Quels sont les leviers pour réduire notre dépendance opérationnelle

Nous connaissons désormais l’ennemi, comme le prêchait Sun Tzu dans L’Art de la Guerre — trouvons maintenant des solutions, mais avec l’avertissement habituel : il n’existe pas de baguettes magiques dans la vie réelle.
Ce qu’il existe en revanche, ce sont des leviers clairs que nous devons actionner.
Le cadre général d’une opération optimale repose sur quatre piliers :

• Une documentation opérationnelle utile et vivante. Ce qui ne signifie pas les classiques wikis fossilisées que personne ne consulte. Nous parlons d’une documentation qui reflète comment les choses sont réellement opérées aujourd’hui — à jour et accessible.
• Standardisation des processus et des environnements. Si chaque client est un flocon de neige unique, ça sonne comme un compliment, mais la dépendance envers celui qui connaît chaque flocon devient inévitable. La standardisation brise cette chaîne.
• Automatisation des tâches répétitives ou sensibles. Ce qu’une machine peut faire de manière fiable ne devrait pas dépendre de la mémoire d’un humain — qui stocke dans ce même neurone l’hypothèque, les enfants et les mauvais jours.
• Visibilité partagée du contexte technique et de l’état des services. Si toute l’équipe voit la même chose dans le NOC, le savoir cesse d’être un secret et devient des données accessibles qui permettent de prendre des décisions optimales et d’opérer comme une horloge.

À présent, la première tâche est de faire le tour de notre maison et de jeter un regard honnête sur ces quatre colonnes. Laquelle vacille le plus ? Laquelle présente des fissures ? Laquelle est un échafaudage provisoire collé avec du scotch, plutôt qu’une colonne ?

Comment réduire la dépendance sans perdre la qualité technique

Toute la théorie que j’ai développée ci-dessus est nécessaire pour ce « connaître l’ennemi », mais sans une approche pratique et progressive, elle reste quelque chose qui ne fait bonne figure que dans un PowerPoint.
Alors, une fois les colonnes du temple examinées, descendons dans la boue avec un processus applicable par étapes.

1. Identifier où le savoir est concentré

C’est un exercice aussi simple que de se demander : « Si cette personne disparaît mystérieusement demain, qu’est-ce qui se casse ? »
Les réponses sont généralement révélatrices — et parfois terrifiantes.

2. Dresser une cartographie des tâches critiques et répétitives

Toutes les dépendances techniques n’ont pas le même poids. Il faut distinguer ce qui est critique pour le service et ce qui se fait ainsi simplement parce que « Untel s’en est toujours chargé ».
Si c’est juste une question d’habitude et non quelque chose de critique, cela passe en bas des priorités dans cette cartographie. Et en parlant de priorités…

3. Documenter en priorité ce qui est le plus critique et le plus fréquent

Voltaire a dit que « le mieux est l’ennemi du bien » et, même s’il ne le savait pas, il parlait aussi de documentation technique.
Nous n’avons pas besoin d’une base de connaissances parfaite et totalement terminée pour qu’elle soit utile. Commençons par y intégrer ce qui causerait le plus de dommages s’il était perdu, et ce qui revient le plus souvent dans le quotidien.
Cela inclut quelque chose de complexe : que les génies du moment — avec leurs têtes remplies de sagesse — la déversent pour tous de manière pédagogique.
Ici entre un autre aspect clé qui contribue à la dépendance : beaucoup de ces techniciens seront réticents. Et d’autant plus en ces temps d’incertitude où une bonne partie de cette dépendance vient du fait que de nombreux techniciens veulent se rendre indispensables, que ce soit par sécurité d’emploi, statut, etc.
Avec beaucoup de diplomatie, nous devons extraire le savoir de ces neurones pour le verser dans une base de connaissances vivante.

4. Standardiser avant d’automatiser

Maintenant qu’on nous vend l’idée que les machines feront tout, nous nous précipitons à appliquer des correctifs d’automatisation avant de comprendre ce que nous voulons accomplir.
Cependant, automatiser un processus chaotique ne produit que du chaos plus rapidement.
La solution consiste à définir d’abord clairement le comportement optimal ou attendu d’un processus, et ensuite seulement laisser les machines l’exécuter.

5. Valider que le reste des techniciens peut travailler et résoudre sans support constant

Il ne sert à rien d’avoir la Bibliothèque d’Alexandrie si personne n’est ensuite capable de suivre la documentation de l’étape 3 sans avoir recours à la personne habituelle.
La preuve réelle que nous n’avons pas seulement un joli wiki est qu’un technicien qui ne s’appelle pas Scotty résout le problème en toute autonomie. S’il n’y parvient pas, la documentation n’est pas prête, même si elle semble complète.

6. Réviser périodiquement

Les dépendances techniques dans les organisations se régénèrent comme les mauvaises herbes.
Nouveaux clients, nouvelles technologies, nouvelles habitudes… Il faut les auditer régulièrement pour éviter que les mauvaises pratiques ne cristallisent à nouveau.

Comment Pandora FMS aide à réduire la dépendance opérationnelle dans un MSP

Pandora FMS est né dans les tranchées du pragmatisme et de l’expérience. Cela se perçoit dans la façon dont il aborde précisément ce problème de dépendance, en corrigeant ce que nous avons vérifié, au cours de plus de vingt ans, en être la cause.
Ainsi, la visibilité centralisée de Pandora FMS permet à n’importe quel technicien de l’équipe de voir l’état complet de n’importe quel client depuis un seul endroit — notre Metaconsole.
Nul besoin de déranger le génie en vacances pour savoir ce qui se passe, ni de fouiller dans les chats de l’année passée. Le contexte est là, dans une surveillance d’infrastructure accessible à tous.
De son côté, l’inventaire et le contexte partagé éliminent la nécessité que quelqu’un connaisse par cœur l’infrastructure du client. Ce qu’il y a, comment c’est configuré, quel est son historique d’événements… Avec Pandora FMS, tout est enregistré et disponible dans le système.
Les modèles réutilisables permettent que le savoir opérationnel soit codifié une fois et appliqué à tous les clients similaires. Ainsi, ce qui vivait auparavant dans la tête d’un technicien réside maintenant dans une politique que n’importe qui peut déployer.
L’automatisation opérationnelle intégrée à Pandora FMS prend en charge les tâches répétitives : self-healing, escalades automatiques, réponses prédéfinies face à des conditions connues… Si le système sait quoi faire, plus personne n’a besoin d’être réveillé à trois heures du matin.
Par ailleurs, la traçabilité des événements et des alertes fournit un registre auditable de ce qui s’est passé, quand et ce qui a été fait à ce sujet. Cela signifie qu’un novice fraîchement arrivé, ou un technicien couvrant l’absence d’un autre, peut rapidement comprendre l’historique sans dépendre de neurones partis en vacances.
Et dans les environnements où la sécurité fait partie du service, Pandora SIEM complète cette vision avec la corrélation d’événements de sécurité et une visibilité unifiée, conformément aux meilleures pratiques de l’ENISA et d’autres cadres de référence.
L’idée centrale de Pandora FMS est simple :
Que les opérations dépendent du système et de ses processus, non pas de Scotty accomplissant une fois de plus le miracle — car je crains que la vie ne soit pas une série télévisée et encore moins une utopie.
Un MSP mature doit cultiver le talent sans engendrer de dépendance, de manière à assurer une continuité de service qui ne repose pas exclusivement sur quelques individus, aussi brillants soient-ils.
J’insiste sur le fait que le génie individuel est à la fois admirable et un point de défaillance unique inacceptable lorsqu’il y a des SLA à respecter et des clients qui nous font confiance — c’est pourquoi des prémisses comme la recherche des fameux ingénieurs 10x sont une arme à double tranchant.
De plus, une condition indispensable à une scalabilité réelle est de libérer le savoir de l’esprit d’individus élus, pour le mettre en sécurité dans les processus, les outils et les connaissances communes du MSP.
De cette façon, nous pourrons accepter davantage de clients, éviter qu’un support réactif ne consume la marge, et n’avoir nul besoin de héros. Après tout, il a été prouvé de nombreuses fois qu’une bonne équipe surpasse toujours une poignée de superstars qui font chacune la guerre dans leur coin.
C’est ce que nous voulons, car avec la dépendance technique nous vivrons une aventure chaque jour — mais celles-là ne font bonne figure que dans la fiction.