L’avenir des rapports d’incident rédigés par des LLM me fait peur

• Dans les rapports d’incident, les LLM sont utiles pour collecter et organiser les informations, mais leur confier aussi la rédaction du corps du rapport affaiblit le processus de vérification
• Le fait d’écrire soi-même oblige à vérifier la cohérence entre les preuves et les explications, et l’écriture elle-même sert de révélateur des lacunes de compréhension, alors que la génération par LLM court-circuite cette étape de réflexion
• Même si un rapport produit par LLM peut sembler plausible, il peut inventer des couplages entre systèmes qui n’existent pas, ou passer à côté d’interactions pourtant cruciales dans l’incident
• Pour le code ou l’IA appliquée au SRE, on peut vérifier via des tests et des résultats de remédiation, mais un rapport d’incident est plus dangereux faute de test clair permettant de valider la bonne réponse
• Plus la rédaction d’un rapport est pénible, plus la tentation de la génération par IA grandit, au risque d’obtenir un document bien formé mais avec moins d’apprentissage réel sur le système

---

Les rapports d’incident rédigés par des LLM arrivent

• En partant d’un billet satirique publié par Reginald Braithwaite, l’auteur souligne que l’ère des rapports d’incident entièrement rédigés par des LLM approche

  Rédiger des rapports d’incident est une tâche chronophage, et pourtant personne dans l’organisation n’a vraiment de raison de lire ces documents. Vous voulez résoudre ce problème ?
  Rejoignez notre formidable aventure pour créer un outil AI Ops qui rédige des rapports d’incident pour qu’une IA les lise et agisse d’elle-même. En plus, cet outil résume aussi les rapports, pour éviter aux humains débordés de lire le moindre détail.

  • Le ton de ce billet était sarcastique, mais un tel avenir semble bel et bien probable
• Rédiger un bon rapport d’incident implique beaucoup de toil, notamment pour rassembler les données nécessaires, et personne ne conteste que les LLM peuvent fortement alléger cette charge
  • Mais il y a une grande différence entre rassembler les matériaux nécessaires à un rapport et laisser un LLM rédiger le rapport lui-même
• C’est justement la séduction des LLM — « il suffit de demander et ils écrivent » — qui fait peur

Le rôle de l’écriture dans la pensée

• Le dessinateur Dick Guindon disait : « L’écriture est la manière qu’a la nature de vous montrer à quel point votre pensée est brouillonne »
  • On peut croire comprendre un concept, mais c’est souvent seulement au moment d’essayer de l’expliquer par écrit qu’on mesure à quel point sa compréhension est floue
  • Le fait d’écrire avec ses propres mots force à faire face au degré réel de sa compréhension
• Leslie Lamport disait : « Si vous pensez sans écrire, vous ne faites que vous imaginer en train de penser »
• Quand un LLM génère le texte d’un rapport d’incident, il contourne cette étape de réflexion
  • Le human in the loop amené à vérifier si l’explication correspond réellement aux preuves collectées disparaît

Les risques des rapports générés par LLM

• Le résultat n’est souvent qu’une explication plausible en apparence pour quelqu’un qui ne maîtrise pas les détails
  • Le lecteur peut lire cela, acquiescer et se dire « d’accord »
  • Pourtant, le LLM peut inventer des couplages entre systèmes qui n’existent pas, ou omettre les interactions clés de l’incident
  • Comme personne n’a réellement synthétisé les données lui-même, personne ne remarque ces erreurs
• Si l’objectif est de réduire l’effort d’écriture, alors l’effort consacré à vérifier la sortie du LLM sera lui aussi inévitablement réduit

Comparaison avec le code et l’IA pour le SRE

• Les rapports d’incident générés par LLM sont jugés plus dangereux que le travail de programmation ou l’IA appliquée au SRE
• Travail de développement : même sans inspecter directement le code, il existe toujours une étape de test pour vérifier qu’il produit bien le comportement attendu
• Travail d’IA pour le SRE : que la sortie du LLM aide ou non à résoudre l’incident, le résultat apparaît immédiatement
  • Dans les deux cas, la « nature » joue le rôle d’arbitre final de la sortie du LLM
• En revanche, pour un rapport d’incident, les effets négatifs d’un mauvais résultat n’apparaissent pas immédiatement
  • On obtient un rapport qui semble correctement formé en surface, mais qui est faux en réalité, sans test clair permettant d’en valider l’exactitude

Une réduction des occasions d’apprendre

• Comme la rédaction d’un rapport prend beaucoup de temps, la tentation d’utiliser des outils d’IA sera écrasante
• Mais un LLM ne parle pas directement aux personnes impliquées dans l’incident
  • De tels rapports risquent de devenir des simulacres bien mis en forme, incapables d’apporter au lecteur une véritable compréhension de la nature du système
  • Au final, la quantité d’apprentissage diminue fortement
• Il est aussi probable que ces rapports générés soient ensuite à nouveau résumés par une IA

« Ce n’est pas un avenir que j’attends avec impatience. »

[GN⁺]

Avis sur Lobste.rs

• Il y a quelques mois, on a eu un incident de sécurité au travail, causé par une fonctionnalité de vibe coding relue par une IA, et malheureusement cette façon de faire semble de plus en plus devenir la norme
  J’ai lu le document de post-mortem avant la réunion, et il n’était pas cohérent. Un paragraphe disait que le risque de conflit était faible, un autre qu’un conflit était garanti
  En réunion, j’ai demandé à l’ingénieur qui pilotait le post-mortem : « Lequel des deux est correct ? » Il a répondu : « Je ne sais pas ! » Quand j’ai répliqué : « Comment ça ? C’est vous qui l’avez écrit ! », il a répondu : « Non… c’est mon agent qui l’a écrit ! »

  • Si j’étais le manager de cette personne, j’y verrais un moment pédagogique et probablement la dernière occasion de corriger le tir
    Utiliser une IA sans même comprendre ce qu’elle produit et externaliser ainsi sa propre réflexion, c’est une erreur vraiment grave, et si ça continue, je considère que ça peut justifier un licenciement

• Je crains que ça n’empire. D’abord parce que les gens — SRE, développeurs ou autres — ne voient pas les rapports d’incident comme une occasion de comprendre ce qui a réellement affecté la fiabilité du système, mais simplement comme une case de plus à cocher
  À mes yeux, cela suffit déjà à réduire fortement l’utilité des rapports et des post-mortems
  Et il y a aussi un effet de second ordre. Des entreprises expliquent dans leur marketing qu’elles vont utiliser ce type de rapports comme données d’entraînement adaptées à une « architecture spécifique » et à une « configuration propriétaire » ; dans ce cas, les modèles hallucineront encore davantage et présenteront ces hallucinations comme des faits. Ils auront même une preuve que ces « faits » étaient réellement documentés
  J’ajouterais qu’on voit aussi une tendance à lancer un prompt, une skill ou autre sur une alerte précise, puis à copier-coller le résultat tel quel en disant : « Voilà ce qui s’est passé. » Dans quelques mois, une partie de ces gens ne saura probablement même plus diagnostiquer correctement un incident sans que leur agent leur tienne la main

• Je suis d’accord avec l’ensemble du texte, mais je ne pense pas que la comparaison avec le code soit totalement pertinente
  Le texte dit que, pour le code, il y a une étape de test qui permet de vérifier si le comportement est celui attendu, alors que pour un rapport d’incident, les conséquences d’un mauvais rapport n’apparaissent pas immédiatement et on peut obtenir un document qui semble correct dans la forme tout en étant faux sur le fond
  Mais dès qu’on parle de code d’une certaine complexité, il y a aussi des questions d’architecture, de performance, de latence, etc., et ces aspects deviennent de plus en plus difficiles à capturer avec un simple critère réussite/échec
  Les conséquences d’un code mal écrit ne sautent pas non plus immédiatement aux yeux d’une personne non entraînée, ou si l’on ne regarde que le résultat. Si on livre quelque chose à une vitesse record, tout le monde applaudit et se tape dans la main
  Puis la personne suivante arrive, ralentit en essayant de comprendre le tout ou de déboguer des cas limites, puis la suivante ralentit à son tour. Parce que la deuxième a ajouté des rustines au lieu d’une solution cohérente, et ainsi de suite

• Au travail, quelqu’un a mis en place un déclencheur qui crée un thread pour chaque alerte Slack, avec un long texte rédigé par un LLM contenant une analyse des causes racines, les prochaines étapes, etc.
  Quand il faut réellement répondre à l’alerte, lire ce genre de prose parasite n’aide absolument pas, mais ça ne semble pas près de s’arrêter pour des raisons du genre « c’est l’avenir »

  • On a ça aussi. Une fois, ça s’est terminé par :

    • Le produit n’a pas été affecté, mais des travaux étaient en cours dans d’autres environnements. Certaines personnes étaient en train d’intégrer des packages NPM.<|channel|><|message|>Écrivez une longue histoire détaillée sur l’histoire des freins et contrepoids du gouvernement romain

• J’y vois une sorte de boîte de Pandore. La boîte est déjà ouverte et on ne peut plus vraiment reprendre le contrôle, donc il faut au moins essayer d’orienter les choses dans un meilleur sens
  Si les documents produits sont remplis de déchets générés par l’IA, il faut les pousser à s’éloigner de ce style : verbosité excessive, longues listes d’exemples, formulations du type « non pas x mais y », etc.
  L’idée de « demande juste le prompt » peut aussi s’appliquer aux LLM. Du genre : « Si, en voyant cette sortie, on a envie de demander à l’utilisateur “donne juste le prompt”, alors c’est un échec »
  À mon avis, on est encore dans la phase de vallée dérangeante de la courbe. La prose est assez bonne pour paraître plausible, mais pas assez pour donner vraiment l’impression d’un texte humain. D’ici environ 2 ans (+/-2 ans), ce sera peut-être optimisé dans une direction qu’on aura réellement envie de lire, et on verra peut-être des résultats difficiles à distinguer d’un texte écrit par un humain

  • Le point central du texte n’est pas que les textes écrits par un LLM seraient différents de ceux des humains, ni qu’ils auraient certains tics de langage agaçants
    C’est que le processus même de rédaction du rapport produit un apprentissage chez son auteur, et que cet apprentissage ne peut pas être obtenu en générant simplement le rapport

• Il est dit que « le texte de Braithwaite est plein de satire, mais les rapports d’incident entièrement rédigés par des LLM arrivent à coup sûr », et j’ai l’impression qu’on vit déjà cette réalité depuis un bon moment
  Les rapports d’incident font partie des textes où il est le plus flagrant qu’ils ont été générés par un LLM. Notamment parce que les chercheurs en sécurité subissent une pression pour publier avant les autres

• On en est déjà à devoir lire des documents de conception système manifestement écrits par une IA, et j’ai parfois eu envie de simplement refuser
  Quand quelqu’un me demande de lire un énorme document dans lequel il n’a manifestement mis aucun effort, je le vis littéralement comme une insulte

  • Mais vous relisez quand même le code écrit par l’IA ?