Les recommandations de sécurité IA d'Ivanti ont réduit des heures de travail, mais sa skill Claude a inventé des détails
Ivanti a révélé que sa skill d'analyse des correctifs basée sur Claude avait inventé des détails, malgré la réduction d'un flux de travail récurrent de plusieurs heures à quelques minutes. Le système de recommandations de sécurité IA d'Ivanti a confondu des éditions de Microsoft Office et interprété à plusieurs reprises de manière erronée le calendrier de publication d'Adobe pendant son développement.
Cet aveu est important, car les résultats aident les équipes de sécurité à prioriser les vulnérabilités après le Patch Tuesday mensuel de Microsoft. Une fabrication plausible peut fausser les systèmes auxquels l'attention est accordée en premier, même lorsque chaque vulnérabilité citée est réelle.
Ivanti a réagi en ajoutant une étape d'approbation humaine et a publiquement identifié le rôle de Claude dans un graphique de juin. CrowdStrike et Palo Alto Networks maintiennent également des personnes impliquées dans des automatisations de sécurité aux conséquences importantes, mais aucun des deux n'a publiquement décrit avoir détecté une fabrication comparable.
L'histoire dépasse donc les erreurs d'un seul modèle. Elle teste la volonté des fournisseurs de révéler comment l'IA façonne les recommandations opérationnelles, ce que leurs réviseurs vérifient réellement et quelles erreurs restent invisibles.
Les recommandations de sécurité IA d'Ivanti sont entrées en production après des mois de corrections
Ivanti n'a mis sa skill Claude en production qu'après que ses développeurs ont détecté à plusieurs reprises des détails fabriqués ou amalgamés durant l'entraînement.
Chris Goettl, vice-président de la gestion produit pour la sécurité des endpoints chez Ivanti, a conçu la skill autour d'un processus qu'il effectuait manuellement depuis environ une décennie. Elle ingère les avis publiés par les fournisseurs et les propres feuilles de calcul d'Ivanti, puis applique la méthode de priorisation des risques liés aux menaces de l'entreprise.
Dans ce contexte, une skill est un ensemble réutilisable d'instructions, de sources et de règles de flux de travail fourni à un modèle d'IA. Cela ne signifie pas que le modèle comprend de manière autonome le système de divulgation de chaque fournisseur.
Goettl a entraîné le système fournisseur par fournisseur. Microsoft est arrivé en premier, car ses feuilles de calcul téléchargeables offraient des données relativement structurées. Adobe a exigé une approche différente, car le modèle devait interpréter des pages individuelles et leurs mises en page changeantes.
Cette différence a révélé une faiblesse importante. La skill produisait de façon répétée un mauvais calendrier de publication pour Adobe. Elle a également amalgamé des éditions de Microsoft Office, que Microsoft répartit entre plusieurs familles de produits.
Il ne s'agissait pas de défauts stylistiques. Le calendrier de publication et l'identité des produits influencent la manière dont les analystes interprètent une activité inhabituelle, les logiciels concernés et l'urgence des correctifs. Un résumé soigné reposant sur le mauvais schéma peut tout de même orienter une équipe dans la mauvaise direction.
Goettl a décrit avoir confronté le système lorsqu'une réponse semblait manifestement sans fondement. Selon son récit dans le pipeline assisté par IA, Claude a reconnu que le contenu inventé ne reposait sur aucune base pouvant être référencée.
Ivanti indique que la skill utilise uniquement des avis publics de fournisseurs et des feuilles de calcul contrôlées par l'entreprise. Elle ne traite pas de données clients, et chaque résultat généré reste un brouillon jusqu'à son approbation par une personne.
Todd Schell, chef de produit senior, a rejoué le système sur deux mois de briefings auparavant assemblés à la main. Ivanti a fait état d'un alignement de 98 %, tout en reconnaissant l'existence de cas limites persistants.
Ce chiffre exige une interprétation prudente. VentureBeat n'a pas audité de manière indépendante les données sources, la méthode de notation, la taxonomie des erreurs ou les résultats des relectures. L'alignement ne démontre pas non plus que chaque vulnérabilité pertinente figurait dans le résultat généré.
La première exécution en production a eu lieu en août 2026, alors que Goettl était en vacances. Une feuille de calcul qui nécessitait auparavant environ quatre heures de travail pour chacun de deux employés aurait été traitée en moins de 30 minutes.
Le flux de travail mensuel élargi consommait environ 48 heures cumulées autour de chaque Patch Tuesday. Ivanti a estimé que cet effort représentait au moins 5 % du temps de travail cumulé de Goettl et Schell.
Le gain opérationnel est facile à comprendre. Une machine peut collecter, normaliser et trier une publication volumineuse plus vite que deux spécialistes ne peuvent copier manuellement des champs entre des feuilles de calcul.
Cependant, Ivanti n'a pas retiré le spécialiste du processus. L'entreprise a fait évoluer son rôle, qui consistait à assembler chaque ligne, vers la relecture d'un brouillon produit par la machine.
Cette distinction définit le conflit central. L'automatisation fait gagner du temps en réduisant la construction manuelle, tandis que des recommandations de sécurité fiables dépendent encore du jugement humain et de la vérification au niveau des sources.
Ivanti avait également laissé une divulgation visible avant que l'histoire plus large n'émerge. Son article sur le Patch Tuesday de juin indiquait qu'un graphique avait été généré avec Claude à l'aide de prompts conçus par l'auteur et du jeu de données de Goettl.
Aucune réglementation n'imposait cette légende. Aucune norme industrielle commune n'en dictait la formulation. La divulgation est restée publiquement disponible pendant environ trois mois avant de faire l'objet d'un examen plus large.
Cette discrète légende a pris de l'importance une fois les échecs de développement connus. Elle reliait un élément généré par IA à un modèle nommé, un auteur humain, une date et un jeu de données défini.
C'est davantage de transparence qu'une étiquette générique « assisté par IA ». Cela ne révèle toutefois pas quelles lignes ont été vérifiées, comment l'exhaustivité a été mesurée ou si les niveaux de risque publiés ont reçu une validation indépendante.
Le problème des données du Patch Tuesday a rendu l'automatisation attrayante
La pression immédiate venait d'un processus Patch Tuesday devenu plus vaste, moins standardisé et plus dépendant de l'interprétation de chaque fournisseur.
Le 8 septembre 2026, Microsoft a publié ce que plusieurs chercheurs en sécurité ont décrit comme son plus grand Patch Tuesday. Pourtant, les totaux publiés différaient sensiblement entre les organisations analysant la même publication.
Tenable a compté 964 vulnérabilités, dont 104 jugées critiques et 860 importantes. Son analyse de septembre a également identifié deux vulnérabilités exploitées dans la nature avant que des correctifs ne soient disponibles.
Ivanti en a compté 973. Senserva en a compté 1 169, car l'entreprise a mis les vulnérabilités en correspondance avec des articles de la base de connaissances au lieu d'utiliser la même méthode centrée sur les avis que d'autres outils de suivi.
L'écart entre les totaux de Tenable et de Senserva était de 205 vulnérabilités. Cet écart dépassait le précédent record de Patch Tuesday cité par Ivanti, qui était de 175 vulnérabilités en octobre 2025.
Ces différences ne prouvent pas qu'un modèle d'IA a commis une erreur. Elles peuvent résulter de choix légitimes concernant le périmètre, les entrées dupliquées, les variantes de produits, les limites des avis et les correspondances avec les bases de connaissances.
Elles montrent pourquoi un seul total mensuel ne peut être traité comme un fait neutre. Chaque décompte publié reflète désormais une méthode d'analyse et une définition de ce qui appartient à l'ensemble.
Microsoft a accentué ce problème lorsqu'il a cessé de présenter une liste mensuelle consolidée de CVE dans son Security Update Guide. Rapid7 a documenté ce changement en préparant son bilan des correctifs de juillet.
Chaque fournisseur de sécurité doit désormais reconstruire la publication à partir des données disponibles de Microsoft. Cette reconstruction peut impliquer du code déterministe, une analyse manuelle, un modèle d'IA ou une combinaison des trois.
Un analyseur déterministe suit des règles explicites et produit le même résultat lorsqu'il reçoit des données identiques. Un grand modèle de langage peut interpréter avec plus de souplesse des pages incohérentes, mais il peut aussi générer des relations non étayées.
Ce compromis devient particulièrement important lorsque le résultat n'est pas un simple décompte. Les équipes de sécurité ont besoin d'une priorisation fondée sur l'exploitation active, la divulgation publique, la gravité, l'exposition des actifs et l'importance pour l'entreprise.
Un décompte erroné peut semer la confusion dans les rapports. Une priorité incorrecte peut détourner des capacités de correction limitées d'une menace que des attaquants exploitent déjà.
Le briefing webinaire d'Ivanti atteindrait entre 500 et 700 participants chaque mois. Ces participants ne reprennent pas nécessairement chaque recommandation directement en production, mais l'audience donne à chaque décision de priorisation une portée significative.
La pression temporelle est également réelle. Les équipes de sécurité ne peuvent pas examiner sereinement près d'un millier d'entrées avant que les attaquants n'agissent.
CrowdStrike a indiqué que 88 % des exploitations observées impliquant une preuve de concept publique avaient commencé dans les 48 heures. Une preuve de concept est du code ou une documentation technique disponible publiquement démontrant comment une vulnérabilité peut être exploitée.
Les exigences fédérales peuvent être encore plus strictes. La Binding Operational Directive 26-04 de la CISA a établi un délai de correction de trois jours pour les vulnérabilités les plus risquées au sein des agences civiles fédérales.
Dans ces conditions, les fournisseurs ont une forte incitation à automatiser la collecte et la classification préliminaire. Attendre une relecture manuelle parfaite peut lui-même créer un risque.
La question n'est pas de savoir si les organisations doivent utiliser l'IA. Elle est de savoir si elles peuvent prouver que l'accélération n'a pas supprimé des vulnérabilités critiques, corrompu des correspondances de produits ou élevé des signaux faibles.
L'expérience d'Ivanti montre pourquoi cette preuve ne peut pas venir de la seule fluidité du texte. Le résultat incorrect du modèle paraissait suffisamment convaincant pour exiger la reconnaissance d'un expert et une confrontation directe.
Les acheteurs de solutions de sécurité subissent donc une pression des deux côtés. Ils ont besoin de recommandations plus rapides, mais ne peuvent pas supposer qu'un briefing rapide et bien rédigé contient un ensemble complet ou correctement priorisé.
Le véritable revirement est la transparence, pas la fabrication
Ce qui surprend n'est pas que Claude ait fabriqué des détails ; c'est qu'Ivanti ait décrit les échecs et conservé une étape humaine visible.
Les grands modèles de langage génèrent du texte en prédisant des séquences probables à partir de leur entraînement et du contexte fourni. Ils ne garantissent pas intrinsèquement que chaque affirmation corresponde à une source fournie.
La fabrication, souvent appelée hallucination, se produit lorsqu'un modèle présente des informations non étayées comme si elles étaient fondées. Dans ce flux de travail, l'échec est apparu sous la forme de schémas de fournisseurs incorrects et de familles de logiciels amalgamées.
Ces faiblesses sont déjà connues dans les systèmes d'IA à usage général. Ce qui change l'enjeu est leur intégration dans un pipeline produisant des recommandations de sécurité.
Une erreur de chatbot grand public peut faire perdre du temps à un lecteur. Une ligne de vulnérabilité manquante dans des recommandations opérationnelles peut retarder la correction d'un système exposé.
La divulgation d'Ivanti n'a pas éliminé ce risque. Elle l'a rendu vérifiable.
L'entreprise a associé un nom de modèle et une responsabilité humaine à au moins un graphique publié. Goettl a également expliqué quels problèmes sont apparus durant l'entraînement et pourquoi l'étape de relecture restait nécessaire.
Ce niveau de précision aide les clients à poser de meilleures questions. Ils peuvent distinguer la collecte assistée par modèle de la priorisation autonome, et demander quelle étape reçoit une vérification humaine.
Cet aveu complique aussi les messages conventionnels sur la confiance. Les fournisseurs mettent généralement l'accent sur les gains de précision, la vitesse de traitement ou la productivité des analystes lorsqu'ils annoncent des fonctionnalités d'IA.
Les échecs de développement reçoivent rarement une attention équivalente. Ce déséquilibre encourage les acheteurs à évaluer un flux de travail à partir de son meilleur benchmark plutôt que de ses modes de défaillance connus.
L'alignement de 98 % rapporté par Ivanti illustre ce danger. Le chiffre paraît rassurant, mais sa signification pratique dépend de ce qui relevait de l'écart restant.
Un écart de mise en forme sans importance et une vulnérabilité activement exploitée omise ne devraient pas recevoir le même poids. Une évaluation utile doit classer les erreurs selon leurs conséquences opérationnelles.
L’exhaustivité mérite un traitement distinct de l’exactitude. Un examinateur peut détecter une gravité erronée ou une description mal formée dans une ligne visible, mais il ne peut pas facilement remarquer une ligne absente.
C’est le défi le plus aigu pour la thèse de la revue humaine. Lire du contenu généré n’est pas la même chose que le rapprocher d’un inventaire de sources faisant autorité.
Kayne McGladrey, directeur virtuel indépendant de la sécurité de l’information et membre senior de l’IEEE, a soutenu que les clients ont besoin d’une description écrite de la chaîne de traitement. Selon lui, les fournisseurs devraient expliquer où le modèle opère, comment les CVE sont analysées, qui examine les résultats et quelle part bénéficie d’une vérification à la source.
Sa critique allait au-delà de la demande d’une signature humaine. Une réexécution sur des mois antérieurs produits par des humains peut mesurer la similarité sans prouver l’exactitude du mois en cours.
Un examinateur humain peut également partager l’angle mort du modèle. Si tous deux se concentrent sur les entrées visibles, aucun ne découvrira un élément disparu avant le début de la revue.
La norme pertinente est donc la traçabilité. Chaque recommandation publiée devrait être reliée à une source faisant autorité, tandis que chaque élément source devrait avoir un traitement consigné.
Cette seconde direction compte le plus. Elle transforme la revue de « Ce brouillon semble-t-il raisonnable ? » en « Peut-on rendre compte de chaque élément source ? »
C’est là qu’une fusion des connaissances rigoureuse devient pertinente au-delà de la gestion des correctifs. Combiner des sources n’est utile que si le flux de travail préserve la provenance et met en évidence les conflits plutôt que de les lisser.
La divulgation d’Ivanti fournit un point de départ, pas une norme achevée. Elle indique aux acheteurs que l’IA a participé au processus et que des fabrications connues ont façonné le processus de revue.
Elle n’établit pas publiquement la filiation au niveau des lignes, des tests indépendants des niveaux de risque, les taux de faux négatifs, ni le pourcentage de sources automatiquement rapprochées.
Néanmoins, cet aveu exerce une pression sur les concurrents. Un fournisseur qui commercialise des recommandations de sécurité assistées par IA sans décrire sa chaîne de validation fournit désormais aux clients moins d’informations qu’Ivanti.
Le renversement est inconfortable, mais constructif. Reconnaître publiquement les échecs d’un modèle peut devenir une preuve de maturité des processus, tandis que le silence peut masquer soit d’excellents contrôles, soit l’absence totale de contrôles.
La revue humaine ne fonctionne que lorsqu’elle peut détecter les preuves manquantes
Un examinateur n’apporte de valeur que lorsque la conception de la revue cible les omissions, les affirmations non étayées et les erreurs de classification à fort impact.
Le flux de travail d’Ivanti maintient une personne entre le brouillon de Claude et le briefing publié. C’est plus sûr que d’autoriser un modèle à publier automatiquement les priorités.
Toutefois, « humain dans la boucle » décrit une conception, pas une mesure de qualité. Son efficacité dépend de ce que la personne voit, vérifie et peut arrêter.
Un examinateur parcourant le texte peut repérer une formulation étrange, un produit connu attribué à la mauvaise famille ou un calendrier de publication invraisemblable. L’expertise de Goettl semble avoir permis de détecter ces anomalies visibles pendant l’entraînement.
L’échec le plus difficile est l’exclusion silencieuse. Si un analyseur ou un modèle ne crée jamais de ligne pour une vulnérabilité, un examinateur ne recevant que la feuille de calcul finale ne dispose d’aucun avertissement évident.
Un système plus robuste nécessite des contrôles de rapprochement en dehors du modèle de langage. Des vérifications déterministes peuvent comparer les identifiants des sources, signaler les enregistrements non appariés, détecter les CVE en double et compter les éléments attendus par fournisseur.
Le modèle peut alors prendre en charge les tâches qui bénéficient de l’interprétation. Il peut résumer des avis, normaliser des descriptions incohérentes ou proposer des catégories de risque à faire approuver par un expert.
Cette répartition attribue des responsabilités différentes aux machines. Le code protège l’exhaustivité et la reproductibilité, tandis que le modèle aide à traiter le langage ambigu et le contexte de priorisation.
Elle crée également des signaux d’échec plus clairs. Une divergence de rapprochement peut interrompre la publication même lorsque le récit généré paraît soigné.
La validation des niveaux de risque exige une rigueur similaire. Le système devrait consigner pourquoi un élément a reçu son classement, quels faits sources étayaient cette décision et ce qui a changé après la revue humaine.
Sans cette trace, une approbation finale établit une responsabilité, mais offre peu d’éléments sur la qualité. Elle ne peut pas montrer si l’examinateur a étudié chaque recommandation ou simplement échantillonné les lignes présentant le plus haut risque.
Ivanti affirme que ses signaux d’exploitation connue, de divulgation publique et de volume anormal déclenchent une escalade. Il s’agit d’un ensemble de règles sensé, mais les rapports publics n’en vérifient pas indépendamment l’application.
Les échecs liés à Adobe et Office montrent aussi pourquoi des tests propres à chaque fournisseur sont nécessaires. Un flux de travail performant sur les feuilles de calcul Microsoft peut échouer lorsqu’un autre éditeur utilise des pages web, des conventions de dénomination différentes ou des calendriers de publication irréguliers.
L’évaluation doit donc couvrir chaque source de données et chaque étape de transformation. Une moyenne agrégée peut masquer un connecteur fournisseur défaillant derrière de solides performances avec Microsoft.
CrowdStrike a décrit un schéma de revue différent lors de Fal.Con 2026. Son approche dite « human on the loop » demanderait à un analyste de traiter la même détection en parallèle avec l’agent, puis de comparer les verdicts.
Le travail parallèle peut révéler des désaccords que la revue séquentielle ne détecte pas. Il conserve également davantage d’effort humain qu’un flux de travail dans lequel une personne vérifie un brouillon déjà achevé.
Palo Alto Networks a présenté Cortex XSIAM AgentiX en février 2026, avec des agents prédéfinis et des étapes d’approbation pour les actions à fort impact. Sa conception de SOC agentique préserve de même le contrôle humain lorsque les décisions automatisées entraînent des conséquences plus importantes.
Aucune de ces conceptions ne résout automatiquement le problème des entrées manquantes. Un humain et un agent peuvent tous deux raisonner à partir d’un flux incomplet, tandis qu’une étape d’approbation peut autoriser une action fondée sur des preuves erronées.
La comparaison révèle néanmoins un consensus émergent. Les principaux fournisseurs ne considèrent pas l’autonomie sans restriction comme une option par défaut acceptable pour les opérations de sécurité à fort impact.
Ce consensus importe, car le langage du secteur brouille souvent la distinction entre assistance et autonomie. Un système qui prépare un briefing diffère matériellement d’un système qui déploie un correctif, isole un appareil ou clôture un incident.
Les acheteurs devraient associer chaque action de l’IA à sa réversibilité et à son préjudice potentiel. Les résumés à faible impact peuvent tolérer des contrôles plus légers que les décisions qui modifient les systèmes de production.
Ils devraient également exiger des preuves issues de cas d’échec réels. Un benchmark ne rapportant que les concordances masque si les erreurs concernent la formulation, le périmètre, la gravité ou les omissions.
Les fabrications connues détectées par Ivanti fournissent des informations plus utiles qu’une simple affirmation d’exactitude. Elles identifient les conditions concrètes dans lesquelles le système est devenu peu fiable.
La question non résolue est de savoir si les contrôles de production détectent de nouveaux modes d’échec, et pas seulement ceux découverts lors de l’entraînement. Les sites des fournisseurs changent, les taxonomies évoluent et des publications inhabituelles peuvent invalider les hypothèses d’analyse d’hier.
La revue humaine reste nécessaire, mais elle devrait s’inscrire dans un système de contrôle mesurable. Dans le cas contraire, l’expression peut devenir rassurante sans démontrer que les erreurs les plus dangereuses sont détectables.
L’aveu d’Ivanti relève la barre pour tous les fournisseurs de sécurité
Les fournisseurs de sécurité sont désormais soumis à une pression pour divulguer non seulement qu’ils utilisent l’IA, mais aussi comment celle-ci influence précisément les priorités destinées aux clients.
Ivanti n’est pas seul à automatiser l’analyse de sécurité. CrowdStrike, Palo Alto Networks et d’autres fournisseurs intègrent des modèles et des agents dans des flux de travail de détection, d’investigation, de triage et de réponse.
La différence concurrentielle révélée ici est la transparence. Ivanti a nommé son modèle, décrit ses entrées, identifié des schémas de fabrication connus et expliqué que la publication exige une approbation humaine.
VentureBeat a indiqué n’avoir trouvé aucune divulgation publique comparable de fabrications chez CrowdStrike ou Palo Alto Networks. Cette absence ne prouve ni que leurs systèmes ont échoué ni que leurs contrôles sont plus faibles.
Elle signifie que les clients ne disposent pas d’informations comparables. Un fournisseur a révélé une partie de son historique d’échecs, tandis que les autres décrivent surtout leur architecture et leurs protections.
La divulgation publique crée un difficile problème d’incitation. Une entreprise qui signale ses erreurs peut paraître moins fiable qu’un concurrent qui ne publie que des évaluations positives.
Les achats de solutions de sécurité peuvent inverser cette incitation en récompensant les preuves. Les acheteurs peuvent poser les mêmes questions à chaque fournisseur et considérer les réponses manquantes comme une lacune de contrôle non résolue.
Premièrement, les clients devraient demander quels artefacts sont générés par l’IA. La réponse devrait distinguer la collecte, l’analyse, la synthèse, la notation, la recommandation et l’action automatisée.
Deuxièmement, ils devraient demander comment l’exhaustivité est vérifiée. Une réponse valable devrait traiter des lignes manquantes, des enregistrements en double, des changements de sources et des échecs d’ingestion.
Troisièmement, ils devraient demander qui examine le résultat et ce que couvre cette revue. Un rôle d’approbation identifié est utile, mais une liste de contrôle documentée et une piste d’audit offrent une assurance plus solide.
Quatrièmement, ils devraient demander des catégories d’erreurs plutôt qu’un seul pourcentage d’exactitude. Les acheteurs doivent savoir si les échecs affectent la grammaire, l’attribution des produits, le statut d’exploitation, la gravité ou l’inclusion.
Ces demandes sont proportionnées à la décision en jeu. Les équipes de correctifs utilisent la priorisation parce qu’elles ne peuvent pas remédier à tous les problèmes simultanément.
La publication de septembre démontre l’ampleur du problème. Tenable a identifié 964 CVE, Ivanti 973 et Senserva 1 169 selon une méthode de comptage différente.
Un acheteur n’a pas nécessairement besoin que chaque fournisseur produise un chiffre identique. Il doit toutefois exiger que chacun explique son périmètre et rapproche ses recommandations de ce périmètre.
La même logique s’applique aux niveaux de risque. Les fournisseurs peuvent raisonnablement pondérer différemment l’exploitabilité, l’exposition et le contexte métier, mais ces jugements devraient rester traçables.
La transparence protège aussi les fournisseurs contre les comparaisons injustes. Une méthodologie documentée peut montrer que deux totaux diffèrent en raison d’un périmètre défini, et non parce qu’un système a silencieusement perdu des données.
Cette question dépasse la cybersécurité. Toute recherche générée par IA, tout briefing de conformité, résumé financier ou rapport opérationnel peut contenir des omissions plausibles que la revue de surface ne détectera pas.
La sécurité rend le problème particulièrement visible parce que les CVE possèdent des identifiants et des avis faisant autorité. Cette structure offre aux fournisseurs un moyen pratique de tester l’exhaustivité.
Les organisations travaillant avec des preuves moins structurées font face à une tâche plus difficile. Elles ont toujours besoin de provenance, de détection des conflits et d’un traitement explicite des éléments manquants.
L’approche d’Ivanti est donc remarquable sans être suffisante. Sa divulgation informe davantage les clients que le silence, tandis que ses contrôles rapportés laissent encore d’importantes questions de vérification sans réponse.
Le contexte de sécurité passé de l’entreprise rend l’examen particulièrement important. Les clients évaluant les recommandations de correctifs jugeront non seulement l’efficacité du modèle, mais aussi la capacité d’Ivanti à communiquer les risques avec précision.
Cet examen devrait rester fondé sur des preuves. La compétence Claude abordée ici a analysé des données publiques sur les correctifs et n’aurait pas accédé aux environnements des clients.
Il ne s’agissait pas d’un agent autonome de remédiation. Elle produisait des brouillons pour un briefing récurrent, une personne étant responsable de la publication.
Confondre ces catégories exagérerait l’événement. Minimiser la fabrication au motif qu’« un humain l’a vérifiée » sous-estimerait le défi de contrôle.
La conclusion mesurée se situe entre ces deux extrêmes. Ivanti a créé un processus sensiblement plus rapide, détecté de véritables échecs du modèle, divulgué l’implication de l’IA et conservé une revue experte.
Elle n’a pas démontré publiquement que son processus détecte chaque vulnérabilité manquante ni qu’il valide indépendamment chaque décision de priorité. C’est la norme que les clients devraient désormais lui demander, ainsi qu’à ses concurrents, de respecter.
Trois signaux montreront si les recommandations de correctifs par IA gagnent la confiance
Le prochain test consistera à déterminer si les fournisseurs transforment une supervision humaine générale en une validation visible, reproductible et exhaustive vis-à-vis des sources.
Le premier signal arrivera avec le prochain Patch Tuesday, le 13 octobre 2026. Les analystes devront comparer les totaux publiés, les définitions du périmètre, les indications d’exploits connus et le traitement des données inhabituelles des fournisseurs.
Si la production d’Ivanti reste rapide tout en tenant clairement compte des divergences entre les sources, son argument en faveur d’une automatisation supervisée se renforcera. Une omission inexpliquée ou une erreur de correspondance l’affaiblirait.
Le deuxième signal serait une divulgation plus détaillée de la part d’Ivanti ou de ses concurrents. Une documentation utile préciserait où les modèles interviennent, quels contrôles déterministes protègent l’exhaustivité et quelles décisions nécessitent une approbation humaine.
Ces informations renforceraient l’idée que la transparence peut devenir une norme concurrentielle. Une dépendance persistante à un discours général sur « l’humain dans la boucle » laisserait sans réponse la lacune centrale en matière de vérification.
Le troisième signal viendrait d’éléments issus d’évaluations en production. Les fournisseurs devraient communiquer les catégories d’erreurs, la couverture des sources, les corrections apportées par les réviseurs et les faux négatifs à fort impact, sans exposer de détails exploitables concernant les clients.
De tels éléments montreraient si les systèmes s’améliorent après avoir rencontré de nouveaux formats et des cas limites. Un simple taux d’accord agrégé ne répondrait pas à cette question.
Le rapport de CrowdStrike sur l’exploitation rapide explique pourquoi ce travail ne peut pas revenir entièrement à un traitement manuel. Ses constats sur l’exploitation montrent que les défenseurs opèrent souvent dans une fenêtre de réponse qui se réduit.
Le bon résultat n’est donc pas de réduire l’automatisation. C’est de disposer d’une automatisation dont les éléments de preuve peuvent être examinés avant que ses recommandations n’orientent des personnes ou des machines.
Pour les responsables de la sécurité, la réponse concrète consiste à recenser chaque source externe de recommandations qui utilise l’IA. Demandez si le modèle compte, interprète, classe ou agit, car chaque rôle crée un chemin de défaillance différent.
Testez ensuite l’affirmation du fournisseur concernant la révision face à une question difficile : comment le processus détecterait-il une vulnérabilité qui n’est jamais apparue dans le brouillon généré ?
Si la réponse dépend d’une personne qui remarque une absence, le contrôle est incomplet. Si elle comprend un rapprochement des sources, la gestion des exceptions et l’enregistrement des décisions humaines, le flux de travail est plus crédible.
Les recommandations de sécurité IA d’Ivanti fournissent désormais une étude de cas publique pour cette discussion. Sa compétence Claude a permis d’économiser un temps substantiel aux analystes, a fabriqué des détails durant le développement et a forcé l’entreprise à concevoir son système autour de ces défaillances.
Cette divulgation ne doit pas susciter une confiance automatique, mais elle mérite de l’attention. Elle offre aux clients des faiblesses concrètes à examiner et aux concurrents un niveau de transparence qu’ils peuvent dépasser.
Avant de vous appuyer sur le prochain briefing de sécurité assisté par IA, demandez quel est le rôle du modèle, comment est vérifiée l’exhaustivité des sources et quelle est la tâche réelle du réviseur. Ces réponses en diront davantage que n’importe quel score de précision affiché.
