53% de Recall : Pourquoi l'AIOps de Microsoft Lui-Même Confirme que l'Ingénieur Reste Indispensable

Microsoft vient de publier un papier d'ingénierie sur ActionNex, un "Virtual Outage Manager" déployé en pilote sur Azure qui ingère des signaux opérationnels multimodaux, les compresse en événements critiques et recommande des actions de mitigation. C'est exactement le type de système que l'industrie vend depuis des années comme la fin du on-call humain : un agent qui voit l'incident, se souvient des incidents passés et vous dit quoi faire.

Ce qui est intéressant dans ce papier n'est pas l'architecture — la perception layer, la hierarchical memory, le reasoning agent sont essentiellement déjà l'état de l'art pour les systèmes agentiques sérieux. Ce qui compte ce sont les chiffres rapportés sur huit outages réels d'Azure, 8M de tokens, 4 000 événements critiques :

• Precision : 71,4%
• Recall : 52,8–54,8%

Et c'est là où, en tant que CTO et en tant que quelqu'un qui a porté le on-call en production à l'échelle entreprise, je m'arrête et je dis : c'est la preuve empirique la plus claire qu'on peut donner en 2026 que l'IA en opérations est implémentable, mais pas substitutive.

Ce que ces chiffres signifient sur le terrain

Je traduis les chiffres dans le langage du on-call :

Une precision de 71,4% veut dire que sur chaque 10 actions qu'ActionNex recommande, environ 3 sont fausses. Pas marginalement sous-optimales — fausses. Dans un outage réel, où chaque action modifie l'état du système, exécuter 3 recommandations sur 10 sans filtre humain c'est comme avoir un ingénieur de garde fraîchement arrivé à qui vous ne donneriez pas encore les permissions de production lors de son premier mois.

Un recall de 53% est le chiffre le plus conséquent. Cela veut dire que près de la moitié des actions correctes qu'une équipe humaine a exécutées pendant ces outages, le système ne les a pas proposées. Il ne s'agit pas d'erreurs — il s'agit de ne pas les voir. La moitié du judgment de mitigation nécessaire pour résoudre un incident Azure reste en dehors de la sortie du modèle.

Si vous êtes le CTO et que la position du fournisseur est "laissez l'IA porter le on-call", la lecture immédiate est : l'IA portera la première moitié. La deuxième moitié — celle qui distingue une mitigation partielle d'un service restoration complet — c'est toujours l'ingénieur qui la porte.

Pourquoi ces chiffres ne s'améliorent pas avec le temps

L'argument optimiste est "ouais, mais ce sont des chiffres d'un système en pilote, ils s'amélioreront". Je suis sceptique pour trois raisons concrètes que je vois chaque semaine en faisant DevOps dans une entreprise avec une infrastructure non triviale.

Premièrement : la longue traîne d'incidents ne se répète pas. ActionNex a une episodic memory des incidents antérieurs. Tout ce qui tombe dans des patterns connus a une forte probabilité d'avoir raison. Mais dans des systèmes complexes, une partie importante des outages qui comptent sont des combinaisons nouvelles — l'incident que votre infrastructure n'avait jamais vu dans cette combinaison de régions, dépendances et état de déploiement. Les chiffres agrégés cachent que la precision et le recall sur incidents nouveaux sont systématiquement pires que sur patterns récurrents. Les SREs senior ne coûtent pas ce qu'ils coûtent parce qu'ils se souviennent des runbooks ; ils coûtent ce qu'ils coûtent parce qu'ils reconnaissent des patterns qui n'étaient pas dans le runbook.

Deuxièmement : les incentives du modèle ne s'alignent pas avec le coût asymétrique d'une action erronée. En production, une action erronée pendant un outage n'est pas une prédiction erronée — c'est une mitigation qui potentiellement aggrave le blast radius. Le coût d'un faux positif (exécuter une action inutile ou dommageable) et le coût d'un faux négatif (ne pas voir la bonne action) ne sont pas symétriques, et les objectifs d'entraînement de la plupart des modèles reasoning ne les distinguent pas bien. Vous pouvez optimiser la precision en montant le threshold, mais alors le recall baisse encore plus. Pas de sortie facile uniquement avec plus de données.

Troisièmement : la vérification en runtime n'est pas gratuite. Une des trouvailles implicites du papier est que les "human-executed actions" sont le feedback qui améliore le système. Pour faire simple : le système s'améliore parce que l'ingénieur continue à juger chaque recommandation. Si vous retirez l'ingénieur du loop, vous retirez aussi le signal d'apprentissage. L'IA en opérations a besoin de l'ingénieur non seulement comme safety net, mais comme source de gradient.

Le contraste avec le papier de vision "self-managing"

J'ai lu en parallèle un papier de vision de l'IEEE de fin 2025, AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), qui décrit l'avenir de la discipline ainsi :

"...emerging technologies such as generative AI enable fully automated pipeline capable of code generation, error detection, deployment, and performance monitoring with minimal human intervention. ... a future where software systems evolve into self managing, self improving ecosystems."

C'est le langage que j'entends chaque trimestre dans les comités de fournisseurs. Minimal human intervention. Self-managing. Self-improving. Et, en tant que CTO, vous devez savoir le traduire.

Quand vous mettez le papier d'ActionNex et le papier de l'IEEE l'un à côté de l'autre, l'asymétrie est inévitable : l'un est la réalité empirique du meilleur système en pilote dans l'un des plus grands clouds du monde, l'autre est la vision aspirationnelle. La distance entre les deux est exactement l'espace où vivent vos ingénieurs. Et il est grand. Un recall de 53% n'est pas un système "self-managing" ; c'est un système qui a besoin d'un humain pour les 47% restants de toute décision non triviale.

Ce qui change (et ce qui ne change pas) dans une pratique DevOps mature

Soyons clairs : ActionNex et les systèmes similaires sont utiles. Je les implémenterais. Mais avec les jointures que la maturité opérationnelle exige.

Ce qui change :

• Le premier triage peut s'accélérer significativement. Les recommandations correctes sont correctes ; dans un outage l'horloge coûte cher, et avoir un agent qui vous offre les hypothèses les plus probables avant que vous n'ouvriez le dashboard est de la vraie valeur.
• La découverte de patterns historiques cesse de dépendre de la mémoire humaine. L'episodic memory est exactement la chose que les humains font le pire — se souvenir de quel incident similaire est arrivé il y a seize mois et quelle mitigation a fonctionné. Là, l'IA bat l'humain clairement.
• La documentation post-mortem peut être générée avec beaucoup moins de friction. Ce qui était trois jours de rédaction peut devenir un brouillon révisé en une heure.

Ce qui ne change pas :

• L'autorité de prendre l'action reste humaine. Aucun mécanisme de gouvernance sérieux en 2026 ne devrait autoriser un agent à exécuter des actions à grand blast radius sans approbation humaine explicite pour 100% des cas avec une confidence < 99%, et la confidence calibrée à 99% sur incidents nouveaux est un fantasme.
• L'ownership de l'incident reste humain. Quelqu'un doit répondre au postmortem. L'IA ne répond pas aux postmortems. C'est la frontière qui ne se franchit pas avec un upgrade de modèle.
• Le judgment sur ce qui est acceptable de dégrader reste humain. La question "qu'est-ce qu'on laisse tomber pour que le reste survive" dépend du contexte business, du client, du contrat. L'IA peut proposer des candidats ; l'humain décide.

La question à poser quand quelqu'un vous vend un AIOps "autonome"

Quand un fournisseur ou un consultant vous présente un système AIOps avec le discours "self-healing", la question n'est pas "quelle est votre precision ?". La question est :

"Dans votre échantillon de validation, parmi les cas où le système a décidé de ne pas agir, dans combien la décision correcte était de ne pas agir ?"

C'est le recall sur le complément. La plupart des fournisseurs ne vous donneront pas le chiffre, parce qu'il n'est pas joli. ActionNex, crédit à Microsoft, le publie indirectement : 47% des cas où il y avait une action correcte, le système ne l'a pas proposée. Pas "ne pas agir" — ne pas la voir. C'est un chiffre honnête. La plupart des démos commerciales vous montrent le subset où le système brille.

C'est la question diagnostique : si le fournisseur ne peut pas y répondre, vous n'achetez pas un système d'opérations, vous achetez une démo.

Ce que je recommanderais ce trimestre

Trois actions concrètes pour un CTO ou head de DevOps qui reçoit la pression "automatiser le on-call avec l'IA" :

1. Implémentez AIOps comme copilot, pas comme operator. L'agent suggère ; l'ingénieur approuve et exécute. Aucune action avec blast radius plus grand qu'un changement réversible n'est déléguée de façon autonome. Cette ligne s'écrit dans la politique, pas dans le runbook.
2. Mesurez le recall sur incidents nouveaux, pas sur l'ensemble agrégé. Si votre fournisseur ne rapporte que des chiffres agrégés, exigez la séparation entre patterns récurrents et cas nouveaux. La différence est habituellement dramatique.
3. Investissez dans l'ingénieur comme source de gradient. Traitez chaque décision humaine de mitigation comme donnée d'entraînement. La valeur de votre équipe SRE n'est pas seulement de résoudre des incidents ; c'est de générer le corpus qui rend le copilot meilleur. Si vous les traitez comme substituables, vous perdez aussi le flux d'amélioration.

La ligne que je défends est simple et, il me semble, maintenant empiriquement soutenue : l'IA en DevOps est implémentable et a un ROI clair en tant qu'augmentation. Elle n'est pas substitutive. Le papier d'ActionNex n'est pas la preuve de l'échec de l'IA — c'est la preuve que les fournisseurs d'AIOps les plus capables du monde, avec les meilleures données et les meilleurs ingénieurs, construisent encore des systèmes qui ont besoin de l'ingénieur pour les 47% restants. Si c'est vrai pour Microsoft sur Azure, c'est vrai pour votre infrastructure, presque certainement avec des chiffres plus modestes.

L'ingénieur ne se substitue pas. Il se met en levier. Les équipes et les CTOs qui comprennent la différence sont ceux qui livreront des systèmes fiables cette décennie.

---

Sources :

• Lin, Z., Hu, H., Hao, M., et al. ActionNex: A Virtual Outage Manager for Cloud Computing. arXiv:2604.03512 (2026). arxiv.org/abs/2604.03512
• Kiran Raj K M, Karthik K Poojary, Abhay, Aishwarya R S, Lathesh Kumar S R. AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines. ICECMSN 2025. DOI:10.1109/ICECMSN68058.2025.11382867

Vous construisez une capacité DevOps/SRE et avez besoin d'ingénieurs senior qui savent où l'IA augmente et où non ? Parlez à un CTO sur le déploiement d'un squad nearshore avec une vraie maturité opérationnelle, pas seulement des certifications de fournisseur.