Quels processus automatiser en premier dans un MSP pour protéger la marge

On peut faire ce qu’il faut pour de mauvaises raisons, et cela fait toute la différence. Cela arrive avec l’automatisation des MSP qui, trop souvent, est mise en œuvre comme quelqu’un qui achète pendant les soldes : dans la précipitation, par FOMO, sans liste claire, convaincu que quelque chose de bon en sortira parce que le marketing n’arrête pas de le répéter… Ou parce qu’un type sur LinkedIn qui ressemble à un véritable gourou l’a dit. Et ensuite, la marge reste identique ou empire, parce que nous nous noyons dans les tokens ou que la licence de cet outil qui devait nous sauver comme Gandalf à l’aube du troisième jour nous étrangle, mais ne fait que nous plumer.
Cela peut sembler hérétique à notre époque, mais la réalité est qu’automatiser n’est pas toujours optimal par défaut. Cela l’est lorsque l’on choisit correctement quoi automatiser, quand le faire et dans quel ordre.
Mais un MSP qui automatise d’abord ce qu’il ne faut pas ne gagne pas en efficacité : il gagne en complexité sans retour, en dette technique que quelqu’un devra payer et en fausse impression d’innovation qui n’apparaît pas dans le compte de résultat.
C’est pourquoi il ne s’agit pas d’une nouvelle ode à l’automatisation abstraite pour que nous aussi ayons l’air de gourous sur LinkedIn. C’est un guide pour la prioriser là où cela fait le plus mal : dans les processus qui érodent la marge.

Pourquoi tous les processus ne méritent pas d’être automatisés en premier

Jusqu’à ce que nous transcendions le plan matériel, ou que le futur de Star Trek se réalise, rien n’est gratuit dans la vie et l’automatisation non plus.
Temps de conception, mise en œuvre, tests, maintenance, licences… Si ce coût n’est pas récupéré sous forme d’efficacité réelle et mesurable, l’automatisation est un luxe déguisé en amélioration.
Alors, comment commencer du bon pied ?
En sélectionnant correctement les processus.
Pour qu’un processus mérite d’être automatisé, il doit remplir plusieurs conditions en même temps :

• Fréquence élevée.
• Le temps qu’il consomme est significatif.
• Il existe une probabilité réelle d’erreur humaine.
• Il offre une possibilité de standardisation préalable.
• Il est potentiellement réutilisable entre clients.

Nous pouvons ainsi utiliser ces 5 facteurs comme checklist et, si l’un d’eux échoue ou manque, la priorité d’automatisation baisse.
Si, par exemple, une tâche n’a lieu que deux fois par an, comporte de nombreuses exceptions ou dépend d’un contexte que seul un humain peut bien interpréter, l’automatiser en premier n’est pas de l’efficacité, c’est une distraction.
Et cette distraction n’a pas un impact nul : elle génère une complexité technique supplémentaire que quelqu’un devra maintenir, déboguer et expliquer aux techniciens qui arriveront ensuite.
C’est pourquoi automatiser sans discernement est pire que ne pas le faire.

Quels processus érodent généralement le plus la marge d’un MSP

Tous les MSP se ressemblent, même si à l’école on nous a menti en nous disant que nous étions spéciaux. C’est pourquoi la première étape consiste à cartographier les processus et, d’après notre expérience, il existe une série de suspects habituels qui se répètent souvent, dévorant plus de marge que le monstre des cookies.

• Tâches répétitives de support à faible valeur : redémarrages de services, contrôles d’état, nettoyages de disque, réponses à des incidents déjà connus et résolus cent fois auparavant…
• Validations manuelles : comme des contrôles de santé que quelqu’un doit lancer à la main parce que le système ne les exécute pas seul.
• Opérations de maintenance récurrente : comme les correctifs, les mises à jour, la rotation des logs, la vérification des sauvegardes, etc.
• Déploiements répétés : configurations appliquées encore et encore pour différents clients ayant des infrastructures similaires.
• Onboarding technique des clients : un processus qui consomme des semaines la première fois et devrait consommer des heures à partir de la deuxième.
• Reporting manuel : des rapports que quelqu’un construit à la main chaque mois et qui pourraient être générés automatiquement.
• Revue dispersée des alertes et événements : lorsqu’il n’y a ni corrélation ni filtrage, le technicien passe des heures à écarter le bruit avant de trouver l’incendie qui compte.

Toutes ces sangsues du bénéfice ont quelque chose en commun :

• Elles se répètent.
• Elles consomment le temps de personnes qui ont été formées pour faire des choses plus précieuses.
• Elles génèrent des erreurs évitables lorsque la fatigue ou la pression entrent en jeu.

Elles sont comme une carte au trésor inversée, car elles indiquent par un X où la marge se perd.

Quels processus un MSP doit automatiser en premier

C’est la question à un million, et la réponse à un million consiste à identifier, dans notre cas, ce qui a le plus grand impact cumulé sur la marge lorsque nous le laissons entre des mains humaines.
Voici par où commencer à regarder si cela correspond à notre cas particulier.

1. Découverte et inventaire des actifs

Si nous ne savons pas ce que nous avons, nous ne pourrons rien gérer de manière fiable.
L’inventaire manuel est lent, incohérent et devient obsolète presque au moment même où il est enfin terminé.
L’automatiser offre une visibilité réelle et constitue le point de départ de tout le reste.
Sans cette étape, les autres automatisations seront des constructions bâties sur du sable.

2. Déploiement et configuration initiale de la supervision

Chaque nouveau client implique de configurer des agents, de définir des seuils et d’établir des alertes.
Si ce processus est réalisé à la main, il devient coûteux, lent et sujet aux erreurs. Mais avec des modèles et des déploiements automatisés, ce qui prenait des jours passe à des heures, et le résultat est plus homogène entre les clients.
Moins de variabilité signifie moins de support réactif futur.

3. Application de politiques et de modèles standard

Lorsqu’un nouveau dispositif entre dans le système, il doit hériter automatiquement de la politique qui lui correspond selon son type, son client et sa fonction.
Sans cela, la standardisation des services MSP reste un vœu pieux.

4. Actions correctives de base et auto-remédiation

Si le système sait que lorsqu’un service de file d’impression se bloque, la solution consiste à le redémarrer, quel sens cela a-t-il qu’un technicien le fasse ?
Le self-healing (détecter la condition, exécuter l’action corrective, vérifier le résultat et fermer l’incident) est le type d’automatisation qui libère le plus d’heures par euro investi.
Si nous le laissons entre des mains de silicium automatisées, le client ne s’en aperçoit pas, le technicien ne perd pas de temps et le SLA reste intact.

5. Validations récurrentes de l’état et de la capacité

Contrôles d’espace disque, disponibilité des services critiques, consommation de mémoire par tendance… Ces validations doivent se produire seules, selon des cycles définis, sans que personne n’ait à se souvenir de les lancer.
Et elles doivent agir par tendance, pas seulement par seuil ponctuel.
Ainsi, nous ne voulons pas savoir que le disque est plein ; nous voulons le savoir quarante-huit heures avant qu’il ne ruine notre vendredi.

6. Génération de rapports périodiques

Le reporting manuel est l’un des puits les plus silencieux de la marge.
L’automatiser libère du temps et oblige à définir ce que l’on veut mesurer, ce qui améliore généralement la qualité des rapports eux-mêmes.
En outre, les rapports automatiques de supervision bien construits ont aussi une valeur commerciale. Ils démontrent au client que le service fonctionne sans que personne n’ait à rédiger quoi que ce soit.

7. Escalade et classification initiale des événements répétitifs

Tous les événements ne méritent pas la même réponse ni le même technicien qui finit par tout faire.
Automatiser la classification initiale (niveau de priorité, type et route d’escalade) réduit le bruit et protège le temps des profils senior pour les choses qui nécessitent réellement leur jugement.

8. Tâches de maintenance planifiées

Correctifs, nettoyages, vérifications des sauvegardes… Ils sont prévisibles, répétables et parfaitement automatisables.
Les faire à la main n’ajoute aucune valeur artisanale, seulement un risque d’oubli et une variabilité inutile.
Comme nous le voyons, tous ces processus n’ont pas une grande valeur différentielle s’ils sont exécutés par un humain ou une machine, mais ils ont bien un coût important lorsqu’on les laisse croître sans contrôle.

Quels processus ne devraient pas être la première priorité

Voyons maintenant le côté obscur, et ici Spock et sa sagesse vulcaine dans La Colère de Khan prennent la parole lorsqu’il disait : « Les besoins du plus grand nombre l’emportent sur ceux du plus petit nombre ».
Appliqué à l’automatisation dans un MSP, cela signifie que les ressources limitées doivent aller là où elles impactent plus de processus, plus souvent et avec plus de conséquences réelles.
Ce qui impacte peu, tard ou de manière imprévisible peut attendre.
C’est pourquoi il convient de laisser pour plus tard les processus qui ne se produisent que quelques fois par an, car le coût de leur automatisation est rarement amorti.
Il est également préférable de mettre de côté ceux qui comportent de nombreuses exceptions non standardisées, car automatiser une variabilité non résolue ne simplifie rien, cela ne fait que produire du chaos plus rapidement.
Et bien sûr, il ne faut pas automatiser les processus qui affectent des changements critiques en production sans environnement de validation préalable ni procédure de retour arrière claire.
Si cela donne déjà des sueurs froides lorsque des humains tremblants s’en chargent, l’automatiser précipitamment revient à prendre les mesures du cercueil de notre MSP.
Enfin, les flux qui dépendent de décisions humaines basées sur un contexte que le système ne peut pas lire (relations clients, gestion des attentes, critères qualitatifs…) ont encore besoin de personnes.
Automatiser ici supprime de la valeur.

Comment décider du bon ordre d’automatisation dans un MSP

Nous avons déjà vu les composants de l’équation, il faut maintenant en définir l’ordre. Heureusement, la logique de priorisation n’a pas besoin d’être complexe pour être utile.
Une matrice simple pour ces processus identifiés suffirait, en considérant :

• Fréquence : combien de fois cela se produit-il par mois ou par semaine ?
• Heures consommées : combien de temps technique cela prend-il en termes absolus ?
• Répétabilité : le processus est-il toujours identique ou présente-t-il des variations significatives entre clients ?
• Niveau de variation entre environnements : plus la variabilité est élevée, plus la priorité est faible.
• Risque d’erreur humaine : que se passe-t-il lorsque quelqu’un se trompe ici ?
• Facilité de standardisation préalable : le processus est-il bien défini ou faut-il d’abord le structurer ?
• Retour opérationnel attendu : combien d’heures sont libérées si cela est automatisé ?

La règle pratique fondamentale se résume ainsi :

Volume élevé + Faible variabilité + Impact clair = Priorité élevée.

Tout ce qui ne remplit pas ces trois conditions en même temps peut attendre une deuxième ou une troisième phase, inutile de s’étrangler.
Ce cadre de travail est également lié au modèle d’automatisation et de standardisation dans les MSP. Comme nous l’avons déjà vu en abordant le sujet, sans standardisation préalable, l’automatisation ne passe pas à l’échelle.
C’est pourquoi il faut d’abord définir le comportement attendu du processus, puis laisser les machines l’exécuter avec garanties.

Ce qui change dans l’exploitation lorsque l’automatisation est appliquée avec discernement

Lorsque l’automatisation est construite sur une bonne priorisation, les changements dans l’exploitation sont concrets et mesurables, et non un simple discours creux sur l’amélioration continue dans le PowerPoint des réunions.
Les signaux indiquant que nous nous rapprochons un peu du Nirvana que l’automatisation nous promet se reflètent dans des pousses vertes comme celles-ci.
Les techniciens cessent d’effectuer des tâches qui ne requièrent pas leur connaissance et gagnent du temps pour un travail à plus fort impact, comme des projets d’amélioration, l’analyse de tendances, l’installation d’un serveur de jeux sans que personne ne s’en aperçoive ou une attention proactive.
De même, l’exploitation ne repose plus sur le dos des mêmes personnes que toujours. Si le processus vit dans le système et non dans la tête de Jean le Génie, il ne s’arrête pas lorsque cette personne est en arrêt maladie ou a décidé que la vie est meilleure chez la concurrence.
En outre, les erreurs opérationnelles diminuent parce que les machines ne se distraient pas, ne se fatiguent pas et n’oublient pas d’étapes après huit heures à fixer l’écran avec les yeux injectés de sang.
La qualité du service est plus homogène pour les clients, indépendamment de la personne d’astreinte.
Nos capacités de mise à l’échelle augmentent, ce qui permet d’exploiter des centaines de clients avec la même équipe technique.
La conséquence de tout ce qui précède est la clé de tout cet article : la protection de la marge. Elle est la conséquence naturelle du fait d’effectuer moins de travail répétitif à faible valeur avec le même nombre de personnes.

Pourquoi l’outil importe moins que le processus que vous décidez d’automatiser

Nous sommes tous tombés dans les chants de sirène du marketing d’un outil qui promettait le paradis ou qui était à la mode, pour ensuite tenter de l’intégrer coûte que coûte à nos processus.
Ainsi, nous automatisons ce dans quoi l’outil est expert (ou ce qui est le plus facile), mais si cela ne coïncide pas avec nos processus à plus fort impact, nous payons pour un placebo et nous érodons probablement la marge que nous étions venus sauver.
Un bon outil aide beaucoup, mais il ne compense ni ne remplace une mauvaise priorisation, ni une mise en œuvre sans standardisation préalable.
L’efficacité opérationnelle IT ne s’obtient pas en achetant la solution la plus sophistiquée du marché, même si un commercial insistant le répète. Réduire la charge de support dans un MSP est une décision opérationnelle avant d’être une décision technologique.

Comment Pandora FMS aide à automatiser les processus MSP à fort impact

Rassurez-vous, je ne vais pas être ce commercial du paragraphe précédent. Je pense qu’il est d’ailleurs clair que je suis un très mauvais vendeur.
Ce qui est certain, c’est que Pandora FMS est construit sur la réalité opérationnelle des tranchées des environnements multiclients.
Dans ce contexte, l’efficacité dépend de la capacité à appliquer les mêmes processus à de nombreuses organisations différentes sans perdre le contrôle ni le contexte, et où la supervision IT doit aller au-delà du simple fait de savoir si un serveur répond au ping.
En termes de déploiement, Pandora FMS permet de configurer des agents, d’appliquer des modèles et de définir des seuils de manière centralisée et répétable.
Ainsi, ce qui, dans une opération manuelle, demande des jours de travail par client devient, avec Pandora, un processus réplicable dès le premier onboarding. Cela se traduit par :

• Moins de temps de mise en route.
• Moins de variabilité entre les environnements.
• Moins de support réactif à long terme.

Dans Pandora FMS, les politiques et modèles réutilisables codifient une fois la connaissance opérationnelle et l’appliquent à tous les clients ayant la typologie correspondante. Nous obtenons ainsi qu’un nouveau dispositif hérite automatiquement de la politique qui lui correspond, sans intervention manuelle, sans risque d’oubli ni dépendance vis-à-vis de la personne disponible à ce moment-là.
De son côté, l’automatisation 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 différentielle.
Le système détecte, agit, vérifie et enregistre, de sorte que le technicien n’intervient que lorsque la situation l’exige. Exactement comme cela devrait être.
La visibilité multiclient, centralisée dans notre Métaconsole, qui est comme un Palantir mais bienveillant, permet de superviser l’état de tous les environnements depuis un point unique, avec ségrégation des données, permissions granulaires et contexte complet.
C’est ce qui permet de détecter les incidents avant qu’ils n’impactent le client et d’agir de manière planifiée plutôt que réactive, ce qui est toujours moins cher et moins stressant.
Le reporting automatisé génère des rapports périodiques sans intervention manuelle, avec le format et la périodicité requis par chaque client. D’autre part, la gestion des événements avec corrélation et filtrage intelligent réduit le bruit opérationnel et protège le temps de l’équipe technique pour ce qui compte vraiment.
Et comme aujourd’hui c’est une bataille après l’autre (le film le plus surestimé de la décennie), Pandora SIEM complète cette vision dans les environnements où la sécurité fait partie du service, alignée sur des cadres de référence comme ceux de l’ENISA ou de la CISA, en unifiant la visibilité des événements de sécurité avec le reste de la supervision de l’infrastructure et des systèmes IT sous gestion.
Ainsi, la sécurité n’est pas un élément à part ; Pandora SIEM agit comme tout un système immunitaire dans notre infrastructure, détectant anomalies et schémas suspects.
Récapitulons un peu, car ma professeure de littérature disait déjà que résumer est une compétence précieuse.
Un MSP protège sa marge lorsqu’il automatise d’abord ce qui génère le plus de travail répétitif, d’erreur humaine et de coût opérationnel au quotidien. Pas ce qui est le plus voyant, pas ce qui est le plus intéressant du point de vue technologique, ni ce que le fournisseur de l’outil du moment a présenté dans son dernier webinaire.
L’automatisation rentable est celle qui réduit systématiquement la friction opérationnelle, libère du temps aux seniors pour qu’ils en fassent quelque chose de mieux que d’envoyer des CV ailleurs parce qu’ils se noient sous les tickets, et permet de croître sans que les coûts augmentent au même rythme.
C’est ainsi que les personnes et les machines travaillent vraiment ensemble, dans ce Nirvana qui prendra fin lorsqu’elles nous planteront un couteau dans le dos et que nous sortirons le fusil à canon scié.