Ce que Cisco a réellement testé
Cisco ne vient pas d’annoncer un énième assistant IA promettant de « révolutionner » le SOC. Le cas est plus intéressant : l’équipe Cisco Talos Incident Response a publié, le 21 mai 2026, un retour d’expérience concret sur l’usage de grands modèles de langage pour produire des rapports de cybersécurité à partir de notes opérationnelles. Le sujet a été repris le 22 mai par The Register et TechRadar, qui soulignent tous deux le même paradoxe : l’IA peut accélérer la rédaction, mais elle introduit aussi des erreurs, des incohérences et des risques de contamination contextuelle.
Le test de Cisco portait sur un rapport de type tabletop exercise, ou TTX : un exercice de simulation où des parties prenantes discutent d’un incident fictif, de la réponse attendue et des lacunes éventuelles dans les processus. C’est important : il ne s’agissait pas d’un rapport forensique complet sur une compromission réelle, avec journaux, horodatages, artefacts techniques et chaîne de conservation de preuve. Cisco le reconnaît d’ailleurs implicitement : le TTX est un bon terrain d’essai parce que le contenu consiste surtout à réorganiser des notes et parce qu’un humain peut plus facilement repérer une hallucination.
Dans ce cadre contrôlé, les résultats sont encourageants. Cisco Talos affirme que le processus a permis de prévoir une réduction d’environ 50 % du temps total de rédaction, en incluant la rédaction humaine des parties que l’IA ne pouvait pas produire efficacement et la révision manuelle du texte généré. L’équipe a utilisé plusieurs prompts spécialisés : un pour organiser la discussion, un pour polir les recommandations et un pour résumer le rapport au niveau exécutif. Selon Cisco, un test à l’aveugle dans son processus d’assurance qualité n’a pas montré de baisse notable de la qualité rédactionnelle globale.
Le gain de productivité existe, mais il a un coût caché
La conclusion superficielle serait simple : l’IA fait gagner du temps aux analystes SOC. Mais la leçon la plus utile est ailleurs. Pour arriver à un résultat acceptable, Cisco Talos a dû fortement encadrer le modèle : prompts granulaires, tâches limitées, sources explicitement définies, structure rigide, gabarits imposés et sessions séparées. Autrement dit, le gain de temps à la rédaction est partiellement remplacé par un travail d’ingénierie du processus.
C’est précisément ce que The Register met en avant : il faut beaucoup d’instructions détaillées pour obtenir une sortie solide, et même alors, des erreurs ou des fautes peuvent subsister. TechRadar insiste de son côté sur les défis propres au contenu technique long : incohérences, pertes d’information, recommandations changeantes et styles variables. Ces observations recoupent le billet primaire de Cisco, mais elles doivent être lues avec nuance : la source de départ reste Cisco, entreprise qui vend aussi des produits de cybersécurité et des capacités IA pour SOC. Ce n’est donc pas une validation indépendante d’un produit, mais un retour d’expérience interne utile parce qu’il expose aussi les limites.
Le problème n’est pas seulement que les modèles peuvent halluciner. Cisco décrit quatre familles d’incohérences : variation des sources utilisées, conclusions différentes à partir de données similaires, formats imprévisibles et dérive du contexte. Dans un environnement SOC, ces détails ne sont pas cosmétiques. Une recommandation mal formulée peut conduire à une remédiation trop large, trop étroite ou non priorisée. Une section mal structurée peut compliquer l’examen par la direction, les équipes juridiques ou les assureurs. Une perte de contexte peut faire disparaître une information critique.
La contamination entre rapports, le signal faible le plus inquiétant
Le point le plus préoccupant du test concerne la contamination entre documents. Cisco Talos indique qu’en éditant plusieurs rapports dans une même session, du contenu provenant d’un rapport pouvait se retrouver dans un autre, même après suppression des notes du premier rapport dans les documents de référence du projet. La mitigation proposée est pragmatique : lancer une nouvelle session ou un nouveau projet pour chaque rapport et réintroduire les prompts.
Pour un SOC, ce détail devrait déclencher une réflexion de gouvernance. Un rapport d’incident contient souvent des informations sensibles : noms de systèmes, comptes compromis, adresses IP internes, hypothèses d’attribution, données clients, informations légales ou éléments couverts par privilège avocat-client. Si le modèle mélange des contextes, l’organisation ne fait pas seulement face à une erreur documentaire ; elle peut créer un nouvel incident de confidentialité.
Ce risque s’inscrit dans une tendance plus large. Le Top 10 OWASP pour les applications LLM 2025 place l’injection de prompt, la divulgation d’informations sensibles, la mauvaise gestion des sorties et la dépendance excessive parmi les risques structurants des systèmes fondés sur des modèles de langage. La leçon pour les équipes SOC est claire : un assistant de rédaction connecté à des notes d’incident doit être traité comme un composant sensible du système d’information, pas comme un simple traitement de texte amélioré.
Pourquoi les SOC veulent malgré tout cette automatisation
La demande est facile à comprendre. La documentation d’incident est indispensable, mais elle est souvent perçue comme une tâche lente et peu gratifiante. Un livre blanc Cisco XDR publié en 2024 rappelait déjà que les analystes doivent non seulement comprendre des événements multiples, mais aussi produire un rapport en fin d’investigation. Le même document présentait l’IA comme un moyen de générer des résumés et des brouillons de rapports à partir d’événements corrélés.
Le rapport SANS SOC Survey 2025 confirme le terrain opérationnel : 69 % des SOC indiquent encore utiliser des processus manuels ou majoritairement manuels pour rapporter leurs métriques, tandis que l’IA et le machine learning sont largement présents mais souvent mal intégrés. Le même rapport observe que beaucoup d’équipes utilisent des outils IA sans workflow défini, sans supervision suffisante et avec une satisfaction encore faible pour les outils de langage génératif.
Cette tension explique l’intérêt du cas Cisco. Les équipes de sécurité ne cherchent pas nécessairement une IA qui « enquête » seule. Beaucoup veulent d’abord réduire la charge administrative : transformer des notes en chronologie, produire un résumé exécutif, homogénéiser le format, lister les actions prises et préparer une section recommandations. Sur ces tâches, l’IA peut être utile si elle reste dans un rôle d’assistant.
Ce que les cadres de référence changent dans l’analyse
Le NIST a publié en avril 2025 la révision 3 de sa publication SP 800-61, qui relie la réponse à incident au Cybersecurity Framework 2.0 et insiste sur l’intégration de la réponse à incident dans la gestion globale du risque. Cette approche rend les rapports encore plus importants : ils ne sont pas seulement des archives, mais des instruments de pilotage, d’amélioration continue et de reddition de comptes.
De son côté, le NIST AI Risk Management Framework et son profil sur l’IA générative rappellent que les risques propres à la GenAI doivent être identifiés, mesurés et gouvernés selon le contexte d’usage. Appliqué aux rapports SOC, cela signifie que l’organisation doit définir ce que l’IA a le droit de voir, ce qu’elle a le droit de produire, qui valide le résultat, comment les prompts sont versionnés et comment les erreurs sont mesurées.
IBM, dans son Cost of a Data Breach Report 2025, ajoute un autre angle : l’IA peut réduire les coûts lorsqu’elle est utilisée de manière extensive dans les opérations de sécurité, mais l’adoption sans gouvernance crée aussi un « AI oversight gap ». IBM indique notamment que de nombreuses organisations manquent de politiques de gouvernance pour gérer l’IA non approuvée. Pour les SOC, c’est un avertissement direct : l’automatisation documentaire ne doit pas devenir du shadow AI avec des données d’incident.
Ce que cela annonce pour l’avenir des SOC
À court terme, le bon modèle ne sera probablement pas l’autonomie complète, mais la coproduction contrôlée. L’IA pourra produire un premier jet, mais l’humain devra rester propriétaire de chaque phrase. Cisco Talos le formule clairement : les auteurs doivent comprendre, éditer et assumer chaque mot du rapport final. C’est une contrainte, mais aussi une protection.
À moyen terme, les SOC les plus matures ne se contenteront pas de « meilleurs prompts ». Ils industrialiseront la documentation comme un pipeline : collecte structurée des notes, classification des sources, gabarits approuvés, isolation stricte par incident, journalisation des interactions avec le modèle, comparaison automatique avec les données sources, revue humaine et validation finale. Le prompt deviendra un artefact de conformité au même titre qu’un playbook ou une règle SIEM.
La perspective est donc moins spectaculaire qu’un discours marketing, mais plus crédible : l’IA générative peut devenir un excellent stagiaire documentaire, rapide et utile, à condition de ne jamais être confondue avec un analyste responsable. Le retour d’expérience de Cisco est précieux précisément parce qu’il ne raconte pas une réussite parfaite. Il montre que même une grande entreprise technologique, dotée d’équipes Talos expérimentées, doit composer avec des prompts complexes, des sorties instables, des faux positifs grammaticaux, des recommandations inutiles et des risques de mélange de contexte.
Pour les équipes SOC qui évaluent aujourd’hui l’automatisation de leurs rapports, le message est simple : commencez petit, standardisez fortement, isolez les dossiers, interdisez les outils publics non approuvés, mesurez les erreurs et gardez la signature humaine. Le gain de temps est réel. Mais dans la réponse à incident, un rapport plus rapide n’a de valeur que s’il reste exact, traçable et défendable.