L’automatisation IT échoue rarement faute d’outil. Elle échoue quand on automatise sans trier ce qui suit une règle et ce qui n’en suit pas.
L’automatisation IT, ou automatisation informatique, couvre des familles de tâches distinctes : provisionner des machines, appliquer une configuration, déployer, sauvegarder, appliquer des correctifs, traiter des demandes. Ce guide traite d’une autre : le travail qui se fait entre les outils d’exploitation, qu’aucun d’eux n’automatise seul.
Que faut-il automatiser en premier dans l’exploitation ?
Le travail répétitif dont le résultat se décrit par une règle. Le livre Site Reliability Engineering de Google appelle ce travail « toil » : manuel, répétitif, automatisable, réactif, sans valeur durable, et qui grandit avec le service. Les équipes décrites dans ce livre visent à le garder sous 50 % du temps de chaque ingénieur. Les enquêtes trimestrielles menées auprès de ces ingénieurs mesurent une moyenne d’environ 33 %, avec des écarts de 0 % à 80 % selon les personnes.
Le critère pratique est simple. Si deux personnes qui appliquent la même consigne arrivent au même résultat, la consigne peut devenir un script. Quelques cas typiques :
- rapprocher deux listes sur une clé stable, comme un numéro de série ;
- contrôler qu’un équipement déclaré en production est bien supervisé ;
- vérifier qu’un seuil, une date d’expiration ou une fin de support n’est pas dépassé ;
- prévenir la bonne équipe quand un état change, avec le contexte utile ;
- ouvrir un ticket dont les champs se déduisent des données déjà connues.
Un script se lance de trois façons : à heure fixe, sur un événement (un changement d’état, un ticket ouvert, un seuil franchi) ou à la demande d’une personne. L’événement fait réagir plus vite, mais il faut savoir rattraper un événement manqué. L’heure fixe se surveille plus simplement : une exécution absente se voit au passage suivant.
Un script de ce genre traite tous les cas de la même façon, coûte presque rien à chaque exécution et se relit. C’est le premier étage, et souvent le plus large.
Qu’est-ce qu’un script ne sait pas faire ?
Lire un texte libre et trancher entre des sources qui se contredisent. Un courriel de fournisseur qui annonce une intervention en prose, avec la date au milieu d’un paragraphe. Une demande où le client décrit un symptôme sans donner d’identifiant. Deux enregistrements dont le nom concorde mais pas le numéro de série.
On peut tenter de couvrir ces cas par des règles. Chaque exception ajoute une branche, et le script devient fragile : il casse au premier format nouveau, et personne n’ose plus le modifier. Ce qui reste après les règles déterministes, c’est le résidu ambigu. Il est en général plus petit que le volume total, mais c’est lui qui consomme le temps de l’équipe.
Quand un agent est-il justifié ?
Quand trois conditions sont réunies : la tâche revient souvent, un résidu ambigu subsiste après les règles, et une personne vérifie la proposition plus vite qu’elle ne la produirait elle-même. Si une seule manque, un script, un formulaire ou une procédure écrite suffit.
Un agent, ici, est un programme qui s’appuie sur un modèle de langage pour lire des textes, recouper des sources et proposer une action. Il ne reçoit que les cas que les règles n’ont pas su traiter, et seulement les éléments utiles à chacun. Il ne parcourt pas tout le parc : il travaille de façon incrémentale, sur ce qui a changé depuis le dernier passage.
| Étage | Ce qu’il traite | Comment il se trompe | Ce qu’il coûte |
|---|---|---|---|
| Script | Règles, clés stables, seuils, formats connus | Toujours de la même façon : l’erreur se voit et se corrige une fois | Presque rien par exécution, coût prévisible |
| Agent | Texte libre, sources contradictoires, cas sans clé | Sur un cas isolé, avec une réponse plausible | Un appel au modèle par cas, des tests, une surveillance |
| Personne | Décision, validation, exceptions | Par fatigue, sur des cas répétitifs | Le temps le plus cher, à réserver aux décisions |
Pourquoi un agent coûte-t-il plus cher qu’un script ?
Parce que chaque cas traité appelle un modèle, et que sa sortie se vérifie au lieu de se démontrer. Un script se teste une fois sur ses règles. Un agent se teste sur un jeu de cas réels, se réévalue quand le modèle ou la consigne change, et se surveille en continu.
Il se trompe aussi autrement. Un script faux se trompe sur tous les cas de la même manière : l’erreur saute aux yeux, et sa correction vaut pour toujours. Le chapitre 7 du livre de Google le dit d’une plateforme d’automatisation : elle centralise les erreurs, et un défaut corrigé l’est une fois pour toutes. Un agent faux produit une réponse vraisemblable sur un cas parmi cent, que seule une relecture attrape.
Le même chapitre rappelle qu’un script n’est pas sans danger. Une automatisation de retrait de machines y a lu un ensemble vide comme « tout », et l’outil d’effacement de disques a effacé les machines d’un réseau de distribution entier. D’où une règle valable pour les deux étages : refuser un lot vide ou anormalement grand, et s’arrêter pour demander une décision.
Pourquoi valider avant toute modification ?
Parce qu’une erreur écrite dans un outil de référence se propage à tout ce qui le lit : tickets, supervision, portail client. L’agent propose, il n’écrit pas. Ses accès restent en lecture seule ; un composant distinct applique uniquement les propositions acceptées.
Une proposition utile contient la modification exacte, les éléments qui la justifient et la source de chacun. La personne responsable l’accepte, la corrige ou la refuse, avec un motif. Pour les scripts, la même règle s’applique aux écritures à fort impact ; une simple notification peut partir sans validation.
Que faut-il garder dans le journal ?
Chaque proposition, avec ce qui permet de la rejouer. Au minimum :
- la date, l’entrée reçue et les sources consultées ;
- la version du script, de la consigne et du modèle ;
- la proposition faite et ce qui la justifie ;
- la décision, son auteur et le motif d’un refus ;
- ce qui a été réellement écrit, et dans quel outil.
Ce journal sert trois fois. Il répond à la question « qui a changé cela, et pourquoi ? ». Il fournit une chronologie fiable le jour d’un incident, comme pour un post-mortem tiré des traces des outils. Et les refus deviennent le jeu de test de la version suivante.
Comment mesurer le résultat ?
En suivant la même tâche avant et après, par étage de l’entonnoir. Les mesures utiles :
- Part traitée sans intervention : cas réglés par le script seul, sans relecture.
- Part envoyée à l’agent : taille du résidu ambigu, qui doit baisser à mesure que des règles nouvelles l’absorbent.
- Taux de propositions refusées, avec la répartition des motifs.
- Taux de propositions corrigées avant acceptation.
- Délai entre détection et décision, par étage.
- Temps humain par cas, avant et après.
- Erreurs découvertes après coup, malgré la validation.
Un taux de refus élevé dit que l’agent est mal cadré, ou qu’il reçoit des cas qu’une règle devrait trancher. Un motif de refus qui revient souvent est une règle à écrire. L’entonnoir se resserre ainsi : le script prend une part croissante, l’agent garde le reste.
Qui maintient une automatisation ?
Une équipe nommée, comme pour un service. Son code est versionné, ses règles sont écrites en clair à côté du code, et ses alertes partent vers cette équipe, pas vers son auteur. Quand un outil qu’elle lit change de format, l’automatisation casse la première : le journal et le refus des lots anormaux servent alors d’alarme.
Par où commencer ?
Par une tâche, pas par une plateforme. Choisissez une tâche fréquente dont le coût se mesure, et notez son volume et le temps qu’elle prend. Écrivez ses règles, puis lancez le script en mode proposition : il signale ce qu’il ferait, sans rien modifier.
Comparez ses propositions à ce que l’équipe aurait décidé. Activez l’écriture sur les cas sûrs seulement quand l’écart est compris. L’agent vient ensuite, sur ce qui reste. Le rapprochement d’inventaire est un bon premier terrain, parce que ses règles s’écrivent bien : voir comment tenir une CMDB à jour. C’est la démarche décrite dans notre chantier automatisation.
Questions fréquentes
Qu’est-ce que l’automatisation IT, en une phrase ?
C’est confier à un programme une tâche d’exploitation répétitive qu’une personne faisait à la main : contrôler, rapprocher, notifier, ouvrir un ticket, appliquer une correction. Elle rend du temps à l’équipe, exécute la tâche de façon identique à chaque passage et laisse une trace. Elle ne corrige pas un processus mal défini : elle le rend seulement plus rapide.
Quelle différence entre un script et un agent ?
Un script applique des règles écrites : même entrée, même sortie. Un agent s’appuie sur un modèle de langage pour lire du texte libre et recouper des sources ; sa réponse n’est pas strictement reproductible. Le premier se trompe de façon systématique, le second de façon plausible et isolée.
Un agent peut-il modifier directement nos outils ?
Nous ne le recommandons pas. L’agent lit et propose ; un composant distinct n’écrit que les propositions acceptées par une personne responsable. Ses accès restent en lecture seule, et chaque proposition est journalisée avec sa décision.
Quelle différence entre automatisation et orchestration ?
Automatiser, c’est confier une tâche à un programme. Orchestrer, c’est enchaîner plusieurs tâches automatisées dans un ordre, avec leurs dépendances, leurs reprises sur erreur et un journal commun. L’orchestration et sa plateforme se justifient quand une tâche dépend du résultat d’une autre ; avant cela, un script versionné et journalisé suffit.
Comment savoir si l’automatisation fonctionne ?
Mesurez la part des cas traités sans intervention, le taux de propositions refusées et leurs motifs, le délai entre détection et décision, et les erreurs découvertes après coup. Comparez au temps passé avant, sur la même tâche.