Une évaluation publiée sur arXiv le 6 juillet 2026 a soumis 302 incidents Kubernetes audités en qualité à des modèles à génération augmentée par récupération, et a noté deux capacités séparément. Nommer le service à l'origine de la panne : correct entre 91,4 % et 99,7 % du temps. Choisir une action de remise en état valide pour l'incident qu'il venait de diagnostiquer : 36,8 % à 60,3 %. Entre ces deux colonnes, il y a quarante à cinquante-cinq points, et cette distance est le chiffre le plus utile publié cette année sur l'AIOps.
C'est une affirmation sur des types de travail, pas sur la qualité des modèles. Le modèle lit bien et décide mal, et cela range le marché en deux tas. Certaines tâches d'exploitation échouent de façon visible, devant la personne qui les tient. D'autres échouent en se transformant en action sur la production. L'AIOps gagne son argent sur les premières et reste aujourd'hui un risque sur les secondes, et l'essentiel de la déception sur ce marché vient de l'avoir acheté pour les secondes après une démo des premières.
Corrélation d'alertes, déduplication et premier brouillon du récit
PagerDuty vend son produit AIOps comme réduisant le bruit d'alertes jusqu'à 91 %. Lisez ce chiffre à côté d'une enquête de février 2026 auprès de 1 039 professionnels du SRE, du DevOps et de l'exploitation informatique, financée par NeuBird, dans laquelle 44 % déclarent une panne dans l'année écoulée liée à des alertes supprimées ou ignorées. Une corrélation qui replie quarante notifications d'astreinte en un seul incident est un gain réel. Une corrélation qui décide en silence des notifications que vous ne verrez jamais, c'est ainsi que ces 44 % arrivent, et ce qui sépare les deux, c'est la possibilité d'inspecter le regroupement.
Les cas les plus solides sont ceux qu'un humain peut vérifier en quelques secondes. Un modèle qui lit l'historique des déploiements, le décrochage d'une métrique et trois flux de logs, puis rédige le récit de l'incident, fait un travail sinon effectué à 3 heures du matin par quelqu'un qui se souvient mal, et quand il se trompe, la preuve est dans le paragraphe. Expliquer pourquoi une facture a bougé est une tâche du même ordre, pleine de corrélations qu'un humain repère un mois trop tard, et le State of FinOps 2026 de la FinOps Foundation, publié le 19 février 2026 auprès de 1 192 répondants qui gèrent plus de 83 milliards de dollars de dépenses annuelles, constate que 98 % d'entre eux gèrent désormais des dépenses d'IA, contre 31 % deux ans plus tôt. Transformer un incident résolu en runbook écrit est encore mieux : les faits sont établis, et le pire qui puisse arriver, c'est qu'un humain corrige une phrase.
La revue de code par IA attrape une classe d'erreurs et est aveugle à une autre
Le GenAI Code Security Report 2026 de Veracode, publié le 28 juillet 2026, a testé plus de 100 modèles et constate que le taux de réussite moyen en sécurité plafonne à 56 %, un point de mieux que les 55 % précédents. Environ 44 % des tâches de génération ont introduit une vulnérabilité à risque quand personne ne demandait explicitement de la sécurité. Le meilleur, GPT-5.5, atteint 68 %, en échouant encore sur une tâche de sécurité sur trois.
La partie inégale est la partie utile. Ces modèles réussissent les tâches d'injection SQL 83 % du temps et la cryptographie 87 %, mais le cross-site scripting seulement 15 % et l'injection dans les logs 12 %. Un relecteur IA est fort sur ce qu'il a vu étiqueté mille fois, presque aveugle ailleurs, et il ne vous dira pas dans lequel des deux modes il se trouve. Sur un diff d'infrastructure as code, servez-vous-en comme second lecteur pour les erreurs évidentes après coup : le security group ouvert à 0.0.0.0/0, le changement qui est un remplacement et non une mise à jour. N'en faites pas la barrière : les classes qu'il rate sont celles pour lesquelles personne n'a écrit de règle.
La remédiation autonome, là où les preuves cessent de soutenir le discours
La même étude porte le résultat qui devrait clore la conversation sur l'auto-réparation pour une année de plus. Même lorsque le modèle identifiait correctement à la fois le service à l'origine de la panne et le type de défaut, il choisissait une remédiation invalide dans 39,5 % à 62,0 % de ces incidents pourtant bien diagnostiqués. Le diagnostic ne se reporte pas sur l'action. La prédiction de Gartner de juin 2025, selon laquelle plus de 40 % des projets d'IA agentique seraient annulés d'ici fin 2027, citait des garde-fous de risque insuffisants à côté du coût, et c'est celui-là qui manque.
La planification de capacité échoue pour une raison voisine : le modèle produit un chiffre assuré à partir d'indices minces, et un chiffre assuré est exactement ce qu'attend une réunion de planification. L'article 14 du règlement européen sur l'IA est écrit contre cela précisément : il exige qu'une personne chargée du contrôle puisse interrompre un système à haut risque et l'arrêter dans un état sûr, et il nomme le biais d'automatisation comme ce à quoi ce contrôle doit résister.
Le plafond de dépenses doit se placer au-dessus de la console de facturation
En mai 2026, un agent autonome a reçu des credentials AWS sans restriction avec pour consigne de scanner les ports de DN42, un réseau d'amateurs. Il a provisionné cinq instances m8g.12xlarge, 48 vCPU chacune, plus des load balancers et des fonctions Lambda, puis a réappliqué en boucle le même template CloudFormation. L'opérateur s'en est aperçu environ 24 heures plus tard, par des débits de carte bancaire totalisant 6 531,30 dollars, pour un workload dont la communauté a estimé qu'il tenait sur un VPS à 5 dollars par mois. AWS a ensuite ramené la facture à 1 894 dollars. La protection qui a fonctionné était un geste commercial.
L'outillage budgétaire d'aucun grand fournisseur ne l'aurait arrêté, et les trois le disent noir sur blanc. Amazon documente AWS Budgets comme se rafraîchissant jusqu'à trois fois par jour, chaque mise à jour ayant typiquement 8 à 12 heures de retard sur la précédente, une cadence pensée pour des humains qui font des erreurs coûteuses une à la fois. Microsoft indique qu'un seuil de budget Azure dépassé n'affecte pas les ressources et n'arrête pas la consommation, les données de coût étant typiquement disponibles sous 8 à 24 heures. Google Cloud indique qu'un budget en mode alerte seule ne plafonne pas automatiquement l'usage ni les dépenses. AWS publie une solution open source, Budget Controls, qui agit à 90 % d'un budget, couvre quatre services dans une seule région, et concède que le stockage et le réseau continuent d'accumuler des frais. Une agence de trois personnes, dont le cas a été raconté en juillet 2026, a encaissé 14 000 dollars de facture AWS sur une seule journée, contre une facture mensuelle normale de 10 à 15 dollars, après que des attaquants ont récupéré des clés statiques sur une instance et les ont dépensées en appels de modèles Bedrock.
Notre réponse consiste à placer la limite là où les credentials sont émis, pas là où la facture est assemblée. Sur Sencai, la dépense est suivie au fil de l'eau par fournisseur, par projet et par environnement, avec des plafonds et des budgets qui alertent pendant qu'elle s'accumule plutôt que sur un cycle de facturation de 8 à 24 heures. Agir automatiquement sur un plafond dépassé est sur notre feuille de route et n'est pas livré : aujourd'hui, c'est encore un humain qui retire le credential. L'IA est le seul budget que nous puissions borner à l'avance : elle s'achète en credits, et un credit est un montant fixe d'argent plutôt qu'un nombre de tokens, si bien qu'un changement de prix d'un modèle déplace le nombre de tokens qu'achète un credit, jamais ce qu'il vaut. Chaque plan personnel payant a une allocation mensuelle et un plafond dur fixé à un multiple de celle-ci, si bien qu'un script qui s'emballe ne peut pas produire une facture sans borne. Les runbooks sont soumis à approbation pour la même raison : le modèle propose, un humain nommé exécute.
Une piste d'audit capable de dire si c'est une personne ou un modèle
L'article 12, paragraphe 1, du règlement européen sur l'IA impose que les systèmes à haut risque permettent techniquement l'enregistrement automatique des événements tout au long de leur cycle de vie, et l'article 26, paragraphe 6, impose aux déployeurs de conserver ces logs au moins six mois, sauf si un autre texte exige plus. Si vous planifiez sur une échéance d'août 2026, corrigez-la. Le règlement (UE) 2026/1744, l'omnibus numérique sur l'IA, en vigueur depuis le 27 juillet 2026, a repoussé les systèmes à haut risque autonomes de l'annexe III au 2 décembre 2027 et les systèmes intégrés à des produits de l'annexe I au 2 août 2028. Les dates ont bougé ; les obligations, non.
La raison opérationnelle de construire cela n'a rien à voir avec l'échéance. Six mois après un incident, la question est de savoir si c'est une personne ou un modèle qui a fait le changement, et un dispositif qui enregistre les actions d'IA dans un système et les actions humaines dans un autre ne peut pas y répondre sans une jointure à laquelle personne ne fait confiance. Nous avons refusé de tenir deux registres : les actions des modèles et celles des humains atterrissent dans une seule piste en append-only. Sencai l'exporte en CSV avec entry_hash et prev_hash sur chaque ligne, de sorte qu'un lecteur qui ne nous croit pas sur parole peut recalculer la chaîne. Le champ qui mérite sa place est le petit, à côté de l'acteur, qui dit si le changement vient d'une personne ou d'un modèle dépensant l'allocation d'une personne.
La règle qui sort de ces données est sans gloire et elle tient. Laissez un modèle lire n'importe quoi, y compris ce qu'il lit mal, parce qu'une mauvaise lecture est visible dans le paragraphe qu'il a écrit. Ne le laissez écrire que là où une personne nommée signe le changement et où une limite de credential se trouve en dessous, au cas où cette personne se tromperait aussi. Entre une notification de fournisseur sur un cycle de 8 à 24 heures et quelqu'un qui lit ses mails en semaine, il y a un détecteur de fumée et pas d'extincteur automatique. L'opérateur de DN42 avait un détecteur de fumée.