Incidents IT : vos équipes ne manquent pas de données, elles manquent de compréhension
Du legacy aux Smart Ops : la fiabilité du S.I. se décide désormais en comité de direction. Ce que l'observabilité, le SRE et l'AIOps y changent vraiment.
Un lundi matin, chez un distributeur agroalimentaire de taille intermédiaire, le service de prise de commande ralentit. En dix minutes, une quarantaine d'alertes arrivent : processeurs, base de données, files de messages, API. Une cellule de crise se réunit et chaque équipe démontre, écran à l'appui, que son périmètre fonctionne. La cause n'apparaît qu'au bout de deux heures : un traitement de nuit, hérité d'une application de quinze ans, a débordé sur la journée et sature la base partagée. La correction prend dix minutes. Le diagnostic en a pris plus de cent. Entre-temps, deux tournées de livraison sont parties incomplètes, et ce sont les enseignes clientes qui ont alerté le service commercial.
J'ai rencontré cette scène, sous des formes proches, dans plusieurs des organisations que j'ai accompagnées. Elle révèle un paradoxe : jamais les systèmes d'information n'ont produit autant de données d'exploitation, et jamais il n'a été aussi difficile de répondre vite à trois questions. Que se passe-t-il ? Qu'est-ce que cela coûte au métier ? Où faut-il agir ?
Le volume de signaux a crû plus vite que la capacité des équipes à les interpréter.
Un sujet de compte de résultat avant d'être un sujet technique
La fiabilité a longtemps été rangée dans la case exploitation. Ce n'est plus tenable. Selon l'enquête annuelle d'ITIC publiée en 2024, une heure d'indisponibilité coûte plus de 300 000 dollars à plus de 90 % des moyennes et grandes entreprises, hors pénalités et contentieux. Pour un directeur financier, l'enseignement est direct : dans l'incident décrit plus haut, ce n'est pas la réparation qui a coûté cher, ce sont les deux heures passées à chercher. Réduire le temps de diagnostic est souvent le levier de rentabilité le plus sous-estimé du budget informatique.
La pression est aussi réglementaire, avec deux cadres distincts. Pour les banques, les assureurs et les autres acteurs financiers, DORA confie à l'organe de direction la responsabilité ultime du risque informatique et impose de classer puis de notifier rapidement les incidents majeurs. Pour les entreprises des secteurs couverts par NIS2 (énergie, transports, santé ou une partie de l'industrie, notamment), les dirigeants doivent approuver les mesures de gestion des risques et peuvent en répondre personnellement. Dans les deux cas, la question posée après un incident sera la même : qu'aviez-vous mis en place pour le détecter, le comprendre et le contenir ?
Voir ce qu'on n'avait pas prévu de regarder
La supervision classique répond aux questions que l'on avait anticipées : ce seuil est-il franchi, ce serveur répond-il ? L'observabilité permet de poser celles que l'on n'avait pas anticipées, en reliant journaux, métriques et traces tout au long d'un parcours métier, depuis l'écran du client jusqu'à la base de données. Dans notre exemple, seule une trace de bout en bout aurait relié la lenteur perçue au traitement hérité. Encore faut-il instrumenter les applications, y compris les plus anciennes : une plateforme d'observabilité ne voit que ce qu'on lui montre, quel que soit son prix. Des standards ouverts comme OpenTelemetry permettent de le faire sans dépendre d'un éditeur. Il faut aussi choisir ce que l'on collecte, car tout conserver, tout le temps, fait exploser la facture de stockage sans améliorer la compréhension.
Le RSSI a tout intérêt à s'associer à ce chantier. Les traces qui expliquent une lenteur révèlent aussi un comportement anormal : un compte de service qui interroge une base inhabituelle, un flux sortant qui n'existait pas la veille. Observabilité et détection de sécurité reposent de plus en plus sur les mêmes données. Les financer séparément revient souvent à payer deux fois pour voir moitié moins.
Décider du niveau de fiabilité au lieu de le subir
Le Site Reliability Engineering (SRE) apporte un langage commun entre l’IT et les métiers : la fiabilité parfaite étant trop coûteuse, elle doit être arbitrée. Un objectif de 99,9 % de disponibilité laisse environ 43 minutes d’interruption par mois : ce "budget d’erreur" guide les priorités entre évolutions et stabilité. Avec quelques parcours critiques, des objectifs clairs, des retours d’expérience sans recherche de coupable et l’automatisation des tâches répétitives, la fiabilité devient un engagement partagé.
AIOps : quand l'outil passe de la recommandation à l'action
L’AIOps apporte surtout une capacité de tri : regrouper les alertes, détecter les dérives et suggérer des causes. Mais elle n’améliore pas un SI mal observé ou mal cartographié : avec des données incomplètes, elle peut produire des corrélations trompeuses. L’AIOps vient donc après l’observabilité, jamais à sa place.
Les agents IA capables d’agir en production deviennent de nouveaux intervenants du SI, pouvant redémarrer un service, annuler un déploiement ou modifier une configuration. Il va falloir définir leurs droits, tracer leurs actions et contrôler leurs décisions, car une automatisation opaque peut transformer un gain d’efficacité en nouveau risque opérationnel.
Rien de cela n'oblige à remplacer le Legacy. Mainframes, ERP historiques et traitements de nuit resteront longtemps au cœur de nombreux SI, parce qu'ils fonctionnent et portent la valeur métier. L'enjeu est de rendre plus intelligentes les opérations qui les entourent, dans le bon ordre : identifier les parcours critiques, les instrumenter, fixer des objectifs de fiabilité, automatiser ce qui est répétitif et maîtrisé, puis confier à l'IA la corrélation et, ensuite seulement, une part encadrée de l'action.
Chaque membre du comité de direction peut mesurer où en est son entreprise avec une seule question. Pour le directeur général : quel est le parcours client dont l'interruption nous coûte le plus, et son objectif de fiabilité est-il écrit ? Pour le directeur financier : lors du dernier incident majeur, combien d'heures ont été consacrées au diagnostic plutôt qu'à la réparation ? Pour le RSSI : quelles actions automatiques s'exécutent aujourd'hui en production sans validation humaine, et qui les a autorisées ? Trois réponses floues dessinent déjà une feuille de route.
La fiabilité d'un S.I. ne se mesure plus au nombre d'alertes traitées, mais à la capacité de l'entreprise à comprendre, anticiper et décider. À ce niveau, elle ne relève plus de l'exploitation. Elle relève de la direction.