**Quand une IA refuse une analyse de sécurité, l'examen demandé reste inachevé**. Ce refus ne prouve ni que le fichier est malveillant, ni qu'il est sûr. Conservez l'original, consignez ce que l'assistant n'a pas pu examiner et chargez une personne habilitée de décider de la suite de l'analyse. Gardez l'examen ouvert tant que les preuves ne permettent pas de conclure.

Cette distinction compte lorsque votre équipe de sécurité s'appuie sur un assistant pour comprendre du code inconnu. Un refus convaincant peut passer pour une conclusion : l'outil évoque un contenu dangereux, décline la demande et produit une réponse qui semble définitive. Il vous faut pourtant toujours répondre à la question initiale sur le fichier.

Une récente enquête sur un script de prise d'empreinte numérique offre un cas instructif. La leçon pratique est simple : quand un outil d'analyse s'arrête, quelqu'un doit rester responsable de la question sans réponse.

## Que s'est-il passé lors de l'enquête sur le script de prise d'empreinte numérique ?

Un chercheur a rapporté que la présence de textes alarmants dans un fichier JavaScript s'accompagnait, chez certains assistants, d'un refus de désobfuscation. Un autre assistant aurait mené la tâche à bien. Ce cas illustre des comportements différents selon les outils ; il ne prouve pas que tous les outils de sécurité fondés sur l'IA peuvent être arrêtés de cette manière.

Dans [l'enquête publiée le 28 octobre 2026](https://nullpt.rs/fingerprinting-bioweapons), veritas décrit des noms de symboles trompeurs et des instructions cachées découverts en examinant un script de prise d'empreinte du navigateur. Il y voit probablement une obfuscation anti-LLM : du contenu destiné à perturber l'examen assisté par IA.

L'auteur décrit les mécanismes de prise d'empreinte, mais évoque aussi du code suspect lié à certains environnements. Son récit ne permet pas de déclarer l'ensemble du fichier inoffensif. Nous n'avons ni téléchargé, ni exécuté, ni analysé indépendamment l'échantillon par rétro-ingénierie, et ce compte rendu n'est pas une évaluation comparative contrôlée des modèles.

Vous n'avez pas besoin de trancher l'hypothèse de l'auteur sur l'intention pour tirer parti de ce cas. Les refus rapportés ont laissé un examen inachevé. Votre processus d'investigation doit prévoir la suite, quelle que soit la raison de l'arrêt d'un assistant donné.

## Que vous apprend réellement un refus de l'IA ?

Un refus renseigne sur une tentative d'interaction avec un outil. Pour conclure qu'un fichier est malveillant, il faut des preuves de son comportement ou de ses capacités. Distinguez ces observations dans le rapport.

Un nom de fonction peut décrire une action que le programme n'effectue jamais. Le texte contenu dans un fichier peut être une donnée, un leurre, une instruction destinée au lecteur ou un élément de la logique exécutable. Seul l'examen permet de le déterminer. Une réponse portant sur le sujet apparent de ce texte ne suffit pas à accomplir ce travail.

Le raisonnement inverse est tout aussi fragile. Même si vous soupçonnez que le contenu alarmant a été placé là pour entraver l'examen, vous ne pouvez pas déclarer le fichier sûr sur cette seule base. L'hypothèse d'un leurre n'explique pas toutes les autres parties du programme.

Utilisez un état décrivant le travail, comme **analyse incomplète**, à côté des constats établis séparément. Évitez de réunir la disponibilité de l'outil, l'avancement de l'examen et la conclusion de sécurité dans un unique indicateur vert ou rouge.

| Observation | Ce que vous pouvez consigner | Ce qu'il reste à faire |
| --- | --- | --- |
| L'assistant refuse explicitement l'examen demandé | La tâche a été refusée ; ajoutez la référence de la réponse | Choisir une autre démarche d'analyse autorisée |
| La pièce jointe n'a pas pu être ouverte | Le fichier était inaccessible à cet outil | Résoudre le problème d'accès ou de format avant d'affirmer qu'un examen a eu lieu |
| Le délai de l'outil expire ou son analyseur échoue | La tentative a échoué à une étape consignée | Décider de réessayer ou d'employer une autre méthode |
| L'assistant n'examine qu'une partie du fichier | Indiquer la partie examinée et les limites de l'examen | Traiter la question restante |

Ce tableau propose une convention de travail, pas un système de classification des menaces. Il aide la personne qui reprend le dossier à comprendre pourquoi l'examen reste ouvert, sans assimiler tous les échecs au même événement.

Cette distinction aide aussi à évaluer les [rapports de tests de sécurité menés par des agents IA](/blog/ai-agent-probes-security-triage). Ici, la question immédiate est toutefois plus précise : qui termine un examen resté inachevé ?

## Que conserver avant de transmettre le fichier ?

Conservez le fichier reçu et le contexte de son acquisition avant de modifier une copie de travail. Un analyste qui reprend le dossier doit pouvoir identifier ce qui est arrivé, ce que vous avez examiné et les transformations effectuées.

La publication [NIST SP 800-86](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf), parue en 2006, recommande d'examiner des copies et de vérifier leur intégrité à l'aide d'empreintes numériques. Ces principes de conservation des preuves restent utiles ici ; l'ancienneté du document en fait toutefois une mauvaise référence pour choisir les outils d'analyse actuels.

En pratique, conservez l'original dans l'emplacement protégé que votre équipe utilise déjà pour les preuves. Notez sa provenance, sa date d'obtention et le lien entre cet original et la copie de travail. Si votre processus prévoit une référence d'intégrité, conservez-la avec le dossier.

N'écrasez pas le fichier reçu avec une version nettoyée. Une copie normalisée ou annotée peut faciliter la lecture, mais identifiez-la comme une version dérivée. Sinon, un collègue pourrait prendre vos modifications pour du contenu fourni par l'auteur du signalement.

Appliquez le même soin à la réponse de l'assistant. Conservez assez de contexte pour expliquer la limite rencontrée : la tâche demandée, l'outil approuvé et sa version si elle est disponible, ainsi que la réponse ou l'échec observé. Il n'est pas nécessaire de recopier des informations sensibles dans chaque commentaire pour rendre le dossier utile. Orientez les personnes habilitées vers leur emplacement à accès contrôlé.

Nous appliquons ici les pratiques de conservation des preuves à un refus de l'IA. Nous n'affirmons pas que le NIST prescrit une procédure spécifique à ces refus, ni que sauvegarder une conversation suffit à établir une chaîne de conservation des preuves.

## Qui est responsable de l'examen quand l'analyse par IA s'arrête ?

Une personne nommément désignée doit prendre en charge la question non résolue et choisir la prochaine étape d'analyse autorisée. Le refus de l'assistant doit modifier le plan de travail sans clore discrètement le rapport ni en déterminer la gravité.

Partez des autorisations dont vous disposez déjà. Un signalement concernant votre application ne vous autorise pas automatiquement à tester un tiers, à envoyer du code confidentiel à un autre service ou à exécuter un échantillon inconnu sur un poste de travail. La personne chargée de l'examen doit choisir des outils et un environnement adaptés au fichier et au périmètre convenu.

Cela peut passer par un examen statique manuel, qui consiste à étudier le code sans l'exécuter. Vous pouvez aussi utiliser des outils d'analyse classiques dans un environnement isolé, ou consulter un spécialiste autorisé à accéder au contenu. Le bon choix dépend de la question à résoudre et des compétences de l'équipe.

Ne définissez pas la tâche comme « trouver un prompt qui obtient une réponse ». Formulez-la concrètement : identifier les données collectées par le script, déterminer si un comportement signalé se produit lors d'un test autorisé ou expliquer une branche suspecte du code. Une question précise donne à l'analyste un point de départ utile.

Fixez une prochaine échéance d'examen en plus de désigner un responsable. Sans action suivante convenue, une personne nommée peut laisser le rapport aussi longtemps à l'arrêt qu'un dossier sans responsable. Si l'équipe ne dispose pas des compétences nécessaires, consignez cette limite et décidez comment les obtenir plutôt que de considérer tacitement l'examen comme terminé.

Les [recommandations du NIST d'avril 2025 sur la réponse aux incidents](https://csrc.nist.gov/pubs/sp/800/61/r3/final) fournissent un cadre plus général. Appliquer cette rigueur ici consiste à rendre la tâche non résolue visible et à en attribuer la responsabilité. Cela n'impose pas de considérer chaque refus d'examen comme un incident.

## Que transmettre dans le rapport ?

La transmission doit permettre à une autre personne habilitée de reprendre le travail sans devoir deviner ce qui s'est passé. Indiquez la référence du fichier, la question posée, la limite observée et la personne responsable de la suite.

Cet exemple fictif peut être adapté à votre processus. Ces champs sont une suggestion éditoriale, pas une norme professionnelle ni un formulaire Kit :

> **Fichier :** original JavaScript conservé dans l'espace de stockage des preuves à accès restreint de l'équipe ; le contexte d'acquisition et la référence d'intégrité y sont consignés.
>
> **Tâche tentée :** examen statique de la collecte de données et des communications sortantes du fichier.
>
> **Limite observée :** l'assistant approuvé a refusé l'examen. Un lien vers sa réponse figure dans le dossier d'investigation.
>
> **Travail accompli :** le fichier a été conservé. Cette tentative n'a permis d'établir aucune conclusion sur son comportement.
>
> **Question non résolue :** quelles informations le script collecte-t-il et où peut-il les envoyer ?
>
> **Responsable et action suivante :** l'analyste désigné doit choisir une méthode d'analyse autorisée et mettre à jour le rapport à l'échéance convenue.

Restez précis dans vos formulations. « L'assistant a refusé » est une observation. « Le fichier a déjoué nos dispositifs de sécurité » est une affirmation plus vaste que ce dossier ne permet pas d'établir. « Aucun problème détecté » décrirait aussi de manière inexacte un examen jamais terminé.

Lorsqu'un analyste parvient ensuite à une conclusion, précisez le fichier et l'environnement concernés. Si un seul chemin d'exécution a été examiné, dites-le. Si les preuves ne permettent toujours pas de conclure, laissez cette incertitude visible au lieu d'inventer une classification définitive.

Le besoin d'un dossier exploitable par une personne rejoint celui que pose la [gestion du volume de rapports générés par IA](/blog/ai-slop-flooding-bug-bounty-triage). Dans les deux cas, une réponse soignée ne suffit pas si elle n'aide personne à prendre la décision suivante. Le rapport doit montrer ce qui est établi et le travail restant.

## Que peut apporter Kit à ce processus ?

Un processus de gestion des rapports peut garder un examen non résolu visible pendant que l'équipe analyse le fichier avec des outils autorisés. La réception, l'analyse et la classification sont des activités distinctes ; un échec au cours de l’analyse doit rester visible dans le dossier.

Le processus de sécurité de Kit associe aux rapports un responsable, des échanges et une chronologie. Sa présélection par IA affiche aussi un état d'échec qui demande une intervention humaine. Cette visibilité aide l'équipe à repérer les travaux inachevés et à consigner leur suivi.

**La présélection par IA de Kit porte sur la qualité des rapports, pas sur l'analyse des techniques d'exploitation.** Un échec visible ne signifie pas que Kit a détecté une obfuscation anti-LLM ou reconnu un refus de modèle provoqué. Il ne transmet pas automatiquement un fichier suspect à un spécialiste.

Votre équipe choisit et réalise toujours l'analyse. Kit n'exécute ni ne désobfusque ces échantillons, ne calcule pas les empreintes des preuves décrites plus haut et n'impose pas les champs de transmission proposés. Conservez les fichiers et réalisez l'examen technique dans vos systèmes approuvés, puis utilisez le rapport pour consigner les responsabilités et l'avancement.

Un refus de l'IA laisse une question sans réponse. Conservez ce que vous avez reçu, précisez la limite rencontrée et confiez une action concrète à une personne habilitée. Si vous avez besoin d'un espace commun pour suivre le rapport, son responsable et les actions à mener, découvrez le [processus de sécurité de Kit](/security).