Erreurs lors de l’automatisation des processus dans un MSP et comment les éviter

Dans les paroles immortelles de Public Enemy : « Don’t believe the hype ». Un bon conseil en général et excellent en particulier lorsque l’on parle d’automatisation dans les MSP. Car il semble parfois que les plus efficaces soient ceux qui automatisent le plus. Pourtant, dans de nombreux cas, cela peut simplement vouloir dire courir plus vite, oui, mais droit vers le précipice.
Pas d’inquiétude, ceci n’est pas un manifeste luddite, ni le signal que vous attendiez pour lancer la rébellion contre les machines. Lorsque l’automatisation est bien pensée, elle constitue un signe de maturité opérationnelle, mais lorsqu’elle ne l’est pas… L’effet inverse est implacable, car elle accélère les erreurs, multiplie les exceptions et génère une dette technique que quelqu’un devra rembourser avec intérêts.
Une mauvaise automatisation remplace un travail manuel visible par un risque opérationnel invisible, sans pour autant générer toutes les économies attendues, bien sûr.
Et dans un MSP, le risque invisible est celui qui ruine les vendredis, ce que nous ne pouvons tolérer sous aucun prétexte. Voyons donc les principales erreurs d’automatisation dans les MSP et comment les éviter.

Pourquoi automatiser ne signifie pas toujours améliorer

Une automatisation n’apporte de la valeur que si :

• Elle réduit le travail répétitif.
• Elle diminue les erreurs.
• Elle maintient le contrôle.

Mais les trois conditions doivent être réunies en même temps.
S’il en manque une seule, l’automatisation devient un piège qui présente bien dans les PowerPoint de réunion, mais place une bombe sous la chaise du quotidien.
Lorsqu’il n’existe pas de standardisation préalable, de validation suffisante ou de contexte opérationnel clair, automatiser peut :

• Propager des changements erronés à grande échelle.
• Compliquer le diagnostic lorsqu’une défaillance survient.
• Créer une fausse impression de contrôle.
• Accroître la dépendance à une logique que personne ne comprend vraiment ni ne peut maintenir correctement.

Multiplier la vitesse d’un système inefficace revient à accélérer notre voiture en direction du mur.
Et le pire, c’est que son plus grand danger n’est pas tant la défaillance qu’elle provoque, mais le fait qu’on ne la voit pas venir et que son ampleur est généralement supérieure à celle d’une erreur humaine.
Un technicien qui commet une erreur manuelle le fait dans un système précis, mais une automatisation mal conçue peut facilement la commettre sur cent systèmes à la fois, et parfois à trois heures du matin, parce que telle est la loi de Murphy.

Signes indiquant qu’une automatisation génère déjà plus de coûts que d’économies

Lorsque nous sommes jusqu’au cou dans la boue, qu’il s’agisse de celle de l’automatisation ou de toute autre en réalité, nous avons tendance à normaliser des symptômes clairs qui indiquent que quelque chose ne va pas, même si nous ne voulons pas le voir.
Nous nous disons que cela fait partie du terrain, que ce sont des secousses normales du voyage, mais non. Nous devons reconnaître les signes clairs indiquant qu’une automatisation échoue, par exemple :

• Un besoin fréquent d’intervention manuelle : si l’automatisation exige souvent que quelqu’un la « pousse », elle a cessé d’être une automatisation.
• Elle échoue avec trop d’exceptions : si 30 % des cas nécessitent un traitement spécifique, alors le processus n’était pas prêt à être automatisé.
• Seule la personne qui l’a créée la comprend : une automatisation qui vit dans la tête d’une seule personne constitue un point de défaillance unique.
• Elle oblige à vérifier continuellement son résultat : s’il faut superviser l’automatisation comme un junior en qui l’on n’a pas confiance, parce que l’on soupçonne à juste titre qu’il utilise ChatGPT pour tout, les économies sont nulles.
• Elle introduit des incidents qui n’existaient pas auparavant.
• Elle nécessite trop de logique spécifique par client : signe que le processus n’était pas standardisé et que l’on a tenté d’automatiser une variabilité non résolue, multipliant ainsi le chaos.
• Elle consomme plus de temps de maintenance que le processus d’origine : si nous en arrivons là, la boucle s’est refermée dans la mauvaise direction.

Quels types d’automatisations sont généralement les plus problématiques dans un MSP

Toutes les erreurs ne naissent pas sous la même étoile. Certaines catégories concentrent un risque bien plus élevé lorsqu’elles sont automatisées et apparaissent avec une régularité préoccupante dans les autopsies de nombreux MSP.

1. Changements en production sans validation suffisante

C’est le péché capital par excellence.
Appliquer automatiquement des configurations sur des systèmes de production, sans environnement de test préalable ni procédure claire de rollback, revient à dérouler le tapis rouge au désastre et à s’incliner lorsqu’il passe devant nous.

2. Automatisations appliquées à des clients très hétérogènes

Si chaque client est un flocon de neige avec sa propre architecture, ses exceptions et ses habitudes, automatiser sans couche d’abstraction capable de normaliser cette variabilité produit une anarchie plus rapide.

3. Remédiations automatiques sur des systèmes critiques sans seuils fiables

Si les alertes qui déclenchent ces corrections ne sont pas correctement calibrées, le système agira sur des faux positifs, avec des conséquences réelles sur l’infrastructure.
À cela s’ajoutent d’autres maux, tels que :

• Des flux avec des dépendances externes peu maîtrisées.
• Des actions déclenchées par des alertes mal affinées.
• Des automatisations opérant avec des privilèges excessifs.
• Des processus avec de nombreuses exceptions et une faible répétabilité.

Chacun de ces facteurs devrait déjà, à lui seul, freiner l’automatisation, mais ensemble, ils constituent la recette de l’incident que personne ne voudra expliquer lors de la réunion postmortem.

Ce qu’il ne faut pas encore automatiser dans un MSP

Dans l’épisode The Ultimate Computer de la série originale Star Trek, le docteur Richard Daystrom installe l’ordinateur M-5 sur l’Enterprise. Il prend rapidement le contrôle et démontre une capacité supérieure à celle des humains, mais peu après, le désastre commence. Avec la même efficacité opérationnelle avec laquelle il avait auparavant bien fait les choses, il se met à attaquer ses propres vaisseaux, causant des morts.
Au final, la morale est qu’il existe des décisions qui ne peuvent être déléguées à aucun système, aussi sophistiqué soit-il, s’il ne dispose pas du contexte nécessaire pour les prendre correctement.
Dans un MSP moderne, les décisions sont plus prosaïques que dans un vaisseau spatial, mais tout aussi importantes. C’est pourquoi il n’est pas encore recommandé d’automatiser :

• Changements massifs en production : sans validation préalable dans un environnement limité. Le risque est disproportionné par rapport à l’économie théorique supposée.
• Décisions nécessitant fréquemment un contexte humain : si faire le bon choix exige de lire entre les lignes de la situation concrète du client et de tenir compte de nuances subtiles, aucune machine ne peut le faire pour l’instant. Sérieusement, peu importe ce que dit la nouvelle présentation marketing de ceux qui veulent vendre que la leur le peut.
• Automatisations sur des environnements peu documentés : sans inventaire fiable, toute automatisation tire sur des cibles qu’elle ne connaît pas correctement, comme le faisait M-5, avec des résultats imprévisibles.
• Processus sans standardisation préalable : automatiser et standardiser ne sont pas synonymes, et la standardisation doit toujours précéder l’automatisation.
• Réponses automatiques à des événements ambigus : si nous ne savons pas avec certitude ce que signifie une alerte donnée, la réponse automatisée est un tir dans le noir, pas une solution.
• Flux très personnalisés par client : lorsque la logique comporte plus d’exceptions que de règles, aucune politique ne tient debout et aucune automatisation n’évitera de provoquer des incidents.
• Tâches critiques sans rollback ni traçabilité : si quelque chose tourne mal et que nous ne pouvons pas l’annuler, ni savoir exactement ce qui s’est passé, nous avons placé une boîte noire imprévisible au milieu du processus, devant laquelle il ne reste qu’à prier pour éviter des conséquences irréversibles.

L’objectif de cette liste n’est pas de faire peur, ni de devenir le cri de guerre du Jihad Butlérien de Dune. Ce que nous cherchons, c’est à introduire un critère de maturité, une protection pour éviter de tourner la suite de The Ultimate Computer.
C’est pourquoi la question des processus à automatiser en premier est valable et nécessaire, et sa réponse définit également ce que nous ne pouvons pas encore laisser entre les mains d’une machine.

Pourquoi certaines automatisations échouent même lorsque l’outil est performant

Les plus intéressés par l’automatisation disent souvent que le problème vient du fait que nous n’utilisons pas le bon outil, qui est bien sûr celui qu’ils vendent, mais le problème réside généralement davantage dans la conception opérationnelle qui entoure la plateforme que dans la plateforme elle-même.
Car un excellent outil appliqué à des processus non standardisés continuera à produire des résultats incohérents.
Il en va de même lorsque :

• Il n’existe pas d’inventaire fiable.
• Le rollback n’est pas conçu dès le départ.
• La segmentation entre clients est insuffisante.
• Les paramètres sont hardcodés au lieu d’être configurés par typologie.
• Une logique pensée pour un cas précis est réutilisée sans discernement dans des contextes différents.

Dans tous ces cas, l’outil remplira sa fonction, comme Spock l’a bien conclu lorsqu’il a analysé ce qu’a fait M-5. Le problème est que cette fonction est mal définie dès le départ.

Comment réduire le risque lorsqu’il est pertinent d’automatiser

Lorsque le processus est suffisamment mûr pour l’automatisation, certains principes réduisent considérablement le risque et doivent être intégrés en amont :

• Automatiser uniquement des processus préalablement standardisés. Si le comportement attendu n’est pas clairement défini, l’automatisation n’a aucune base solide sur laquelle s’appuyer.
• Valider dans des environnements limités ou sur de petits groupes avant de déployer sur toute la base de clients. Car si quelque chose échoue sur dix machines, cela reste maîtrisable, mais si cela échoue sur deux cents une minute après le déploiement…
• Concevoir le rollback dès le départ, et non comme un ajout ultérieur. Si nous ne pouvons pas annuler, nous ne devrions pas exécuter, et cela devrait être gravé dans chaque département IT d’un MSP.
• Enregistrer l’exécution et le résultat de manière centralisée. Sans traçabilité, diagnostiquer une défaillance devient une exploration archéologique à la Indiana Jones au milieu de logs dispersés.
• Paramétrer par client ou par typologie, afin que la même logique fonctionne dans différents environnements sans nécessiter de versions parallèles que personne ne contrôle.
• Monitorer l’automatisation elle-même, car si personne ne la supervise, elle peut échouer silencieusement pendant des semaines.
• Réviser périodiquement les exceptions et le coût réel de maintenance. Une automatisation qui a été utile peut cesser de l’être si l’environnement change, et personne ne nous préviendra si nous ne le vérifions pas.

Ce qui change lorsqu’un MSP automatise avec discernement plutôt que par impulsion

Le FOMO est puissant. Un feu qui nous fait transpirer nerveusement, alimenté par une énorme quantité de marketing et d’informations, dont une grande partie n’est rien d’autre que du marketing supplémentaire déguisé en connaissance derrière ces lunettes avec un nez et une moustache. Nous ne devons pas céder à la pression externe, et l’automatisation doit résulter d’un critère interne.
Lorsque c’est le cas, les erreurs propagées diminuent, la dépendance aux scripts fragiles se réduit et la confiance de l’équipe dans l’opération augmente. En outre, le besoin de supervision réactive et de support diminue également, car les choses fonctionnent comme elles le doivent, et non parce que quelqu’un les surveille.
En plus de ce qui précède, la réutilisation entre clients devient réelle plutôt qu’une simple aspiration, et il devient possible d’opérer des centaines de clients avec la même équipe technique sans que les coûts augmentent au même rythme que le portefeuille.
Le MTTR s’améliore également dans ce cas, car nos techniciens agissent sur ce qui compte, et non sur ce qu’une automatisation négligente a incendié.
Enfin, la différence entre détecter les incidents avant qu’ils n’impactent le client et éteindre des incendies qui n’auraient jamais dû exister cesse d’être rhétorique avec une bonne automatisation, pour devenir quelque chose de mesurable dans les SLA et le compte de résultat.

Comment Pandora FMS aide à automatiser avec contrôle dans les environnements MSP

Pandora FMS est un outil qui automatise avec contrôle et discernement, non seulement parce qu’il facilite ce processus, mais surtout parce qu’il facilite les actions préalables nécessaires, telles que :

• L’analyse de l’infrastructure pour détecter ce qu’il faut automatiser avec discernement, et non par FOMO.
• La standardisation nécessaire, que je ne me lasserai pas de répéter, et qui constitue le socle de l’automatisation.

C’est pourquoi l’approche de Pandora FMS dans les environnements MSP part du problème opérationnel réel, et non de l’automatisation comme une fin en soi.
Les modèles et politiques réutilisables codifient une seule fois le comportement attendu et l’appliquent à tous les clients ayant la typologie correspondante. Sans cette couche, chaque automatisation est artisanale et fragile, dépendante du souvenir de quelqu’un sur son fonctionnement.
La segmentation par client avec des permissions granulaires garantit qu’une automatisation dans l’environnement du client A ne peut pas affecter l’environnement du client B, même s’ils partagent la même console. Cet isolement est critique dans les environnements multiclients d’un MSP.
La traçabilité des actions, quant à elle, rend le diagnostic de toute défaillance maîtrisable. Chaque exécution est enregistrée avec son résultat, son contexte et son horodatage.
Sans cela, l’autopsie d’un incident devient un cauchemar de plusieurs heures que personne n’a.
La surveillance de l’infrastructure et la surveillance des systèmes IT, intégrées dans une même vision, permettent aux décisions automatiques d’être prises avec des données réelles et non à l’aveugle, ni sous l’effet d’une présentation commerciale qui nous a fait craindre de « prendre du retard ».
L’automatisation contrôlée des réponses (self-healing, escalades automatiques, actions correctives face à des conditions connues) élimine l’intervention humaine là où elle n’apporte pas de valeur. Mais bien sûr, toujours avec des seuils correctement calibrés, avec un enregistrement de ce qui se passe et avec la possibilité d’intervenir lorsque le contexte l’exige, contrairement à The Ultimate Computer.
Enfin, il y a l’inévitable sécurité, sans laquelle rien d’autre ne compte. Dans ce domaine, Pandora SIEM aligne les événements de sécurité avec le reste de l’opération, offrant une vision globale et réduisant la mer de bruit dans laquelle les alertes pertinentes se noient souvent.
Au final, l’automatisation utile dans un MSP est celle qui réduit le travail répétitif sans accroître le risque, l’opacité ni la maintenance inutile.
Et cela, contrairement à ce que vend n’importe quel webinar, ne se produit pas magiquement en adoptant un nouvel outil.
Bien automatiser exige du discernement avant la technologie. Cela suppose de savoir aussi clairement ce qu’il ne faut pas automatiser que ce qu’il faut automatiser, car une automatisation prématurée ou mal conçue peut provoquer le même désastre que M-5 dans Star Trek.