Surveiller la disponibilité et la rapidité des systèmes, et signaler les anomalies avant que les utilisateurs n'en subissent les conséquences, est une tâche largement reprenable. Non pas parce que l'IA comprendrait soudainement l'infrastructure, mais parce que la tâche elle-même est depuis des années structurée autour de valeurs mesurées, de seuils et de répétition. C'est une conclusion différente de celle des tâches où le jugement ou la négociation constituent le cœur du travail.
Trois axes sont ici déterminants : le volume, la structuration et le coût des erreurs.
Le volume est élevé. La surveillance tourne en continu, jour et nuit, sur des centaines ou des milliers de points de mesure. Une personne qui suivrait cela manuellement consulterait des tableaux de bord à intervalles réguliers et manquerait ce qui se passe entre-temps. Un système qui mesure chaque seconde et compare avec une valeur seuil ne manque rien.
La structuration est élevée. La tâche consiste à : mesurer, comparer avec une norme, et émettre un signal en cas d'anomalie. C'est une procédure fixe, pas une question ouverte. Comparez cela au traitement d'une question d'utilisateur sur un logiciel, où la question est formulée différemment chaque fois et nécessite du contexte.
Le coût des erreurs est faible à moyen. Une alerte manquée ou tardive est gênante, mais généralement réparable : le système envoie une nouvelle alerte dès que l'anomalie persiste, et la plupart des valeurs seuils sont fixées avec une marge. C'est différent d'une tâche où une seule étape manquée entraîne immédiatement une application inutilisable pour un utilisateur, comme pour la résolution d'un incident informatique de première ligne.
Deux axes freinent le tableau : la marge de jugement et la créativité se situent respectivement à 2 et 1.
Signaler une anomalie est autre chose que comprendre ce que cette anomalie signifie pour l'organisation. Un pic d'utilisation de la mémoire peut être anodin, ou être le début d'un problème qui mettra la boutique en ligne hors service deux heures plus tard. Déterminer cette signification, et décider d'escalader vers un ingénieur qui intervient, reste un travail humain. L'IA signale l'anomalie ; une personne connaissant l'environnement évalue la valeur de cette anomalie.
C'est aussi pour cette raison que cette tâche ne fonctionne pas isolément. Le signal émis par un outil de surveillance doit aboutir quelque part : sous forme d'incident enregistré avec l'urgence appropriée. La suite de ce processus est décrite dans Enregistrer et prioriser les incidents informatiques, une tâche légèrement moins cadrée que la surveillance elle-même.
L'estimation est la suivante : un agent. Pas un simple script isolé qui contrôle une seule valeur seuil, mais un système qui mesure en continu, combine plusieurs signaux, et détermine lui-même si un schéma justifie une alerte avant qu'une personne ne le voie. C'est une étape au-delà de la simple alerte, et une étape en retrait par rapport à l'autonomie complète : l'agent signale et catégorise, un gestionnaire décide de ce qu'il advient du signal.
Deux conditions déterminent si cela fonctionne. Des valeurs seuils configurées doivent exister, adaptées à ce qui est normal pour ces systèmes spécifiques : un seuil suffisamment strict pour une application peut déclencher constamment de fausses alertes pour une autre. Et il doit y avoir un système d'alerte automatisé qui délivre effectivement le signal à quelqu'un. Sans ces deux éléments, il n'y a rien à reprendre : aucune norme de référence, aucun canal pour transmettre l'information.
Dans une entreprise avec quelques serveurs et des horaires de bureau fixes, la surveillance reste souvent une affaire de vérifications occasionnelles. Le gain de volume lié à l'automatisation y est alors limité, simplement parce que le volume est faible. Dans une entreprise avec de nombreux systèmes, des clients qui s'attendent à un accès à tout moment de la journée, et un historique d'incidents survenus la nuit, le tableau est différent : la capacité en fte libérée par une surveillance automatisée continue y augmente rapidement, car l'alternative est une personne qui doit rester en permanence en astreinte.
L'axe du coût des erreurs varie également selon l'entreprise. Dans un environnement de test interne, une alerte manquée est sans conséquence. Dans un système qui touche directement aux transactions de paiement ou aux données médicales, la barre de conformité est plus haute, ce qui pousse l'axe conformité, déjà à 4 ici, encore plus vers un enregistrement obligatoire et un suivi démontrable.
Ceci n'est pas une déclaration sur le personnel. La question de savoir si et comment une organisation réaffecte la capacité libérée d'un administrateur système est un choix de l'employeur, avec ses propres obligations légales lorsque cela touche aux décisions relatives aux postes. Cette page décrit uniquement le travail, pas les personnes qui l'effectuent actuellement.
La surveillance est rarement une tâche isolée. Elle est liée à l'exécution et au contrôle des sauvegardes, au traitement des incidents, et à la planification de qui doit être disponible et quand pour le suivi. Pour une vision plus large de ce que l'IA peut reprendre dans la fonction informatique dans son ensemble, un point de départ se trouve sur la page consacrée au travail et à la planification.
Cette page donne une estimation basée sur la tâche sous sa forme générale. Ce que cela représente concrètement pour une entreprise spécifique dépend du nombre de systèmes, des valeurs seuils configurées et des conséquences d'une alerte manquée. Une indication pour votre propre situation peut être obtenue avec le quickscan gratuit : douze questions, sans compte, avec une indication de la part des heures de ce profil qui peut aujourd'hui être reprise par l'IA. Le werkscan complet, qui décompose le travail de toute une entreprise en tâches, est encore en construction.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.