Enquêter sur les incidents et créer des détecteurs personnalisés à partir de cas réels

Le tableau de bord Incidents

Chaque prompt analysé par l'extension navigateur, l'agent de bureau, le CLI ou la couche MCP qui déclenche une détection arrive au même endroit : app.zeuslock.ai/incidents. C'est là que vous passez l'essentiel de votre temps en tant qu'opérateur. Le tableau de bord est conçu pour vous faire passer de « quelque chose a sonné dans la dernière heure » à un ticket clos en quelques clics.

En haut du tableau se trouve la barre de filtres. Chaque filtre est multi-sélection et se combine aux autres :

• Plage de dates — des 15 dernières minutes aux 90 derniers jours, plus une fenêtre personnalisée pour les audits.
• Sévérité — Critique, Élevée, Moyenne, Faible. La sévérité est fixée par le détecteur qui s'est déclenché, pas par l'utilisateur.
• Type de détection — toutes les catégories de détecteurs : api_key, credit_card, IBAN, password, JWT, private_key, source_code, NIR, etc.
• Utilisateur — par e-mail ou par groupe synchronisé depuis SCIM.
• Destination — ChatGPT, Claude, Gemini, Copilot, Mistral, Perplexity, DeepSeek, ou tout domaine personnalisé capturé par le mode Universel.
• Statut — Ouvert, En revue, Résolu, Rejeté.

Triez par horodatage (par défaut), sévérité, utilisateur ou destination. Les filtres actifs sont encodés dans l'URL : vous pouvez partager une vue de triage avec un collègue en copiant le lien.

Lire une carte d'incident

Chaque ligne de la liste est une carte compacte qui contient tout ce qu'il faut pour décider de l'ouvrir :

• Identité et groupe de l'utilisateur.
• Navigateur ou client de bureau et système d'exploitation.
• URL source vers laquelle le prompt allait partir (ex. chat.openai.com).
• Un badge de sévérité coloré.
• Des puces de type de détection — une par détecteur déclenché sur le même prompt.
• Un aperçu rédacté du prompt. Les segments sensibles sont masqués au rendu : la valeur brute n'est jamais envoyée à votre navigateur.
• Horodatage dans votre fuseau opérateur.
• Action effectuée : Monitor, Anonymize ou Block.

Ouvrir un incident

Cliquez sur une carte pour ouvrir la vue détaillée. Vous obtenez la chronologie complète, dans l'ordre :

1. Détection côté navigateur — la couche regex s'est déclenchée, avec le ou les offsets dans le prompt et l'identifiant du détecteur.
2. Confirmation ML optionnelle — si la politique a escaladé vers le modèle NER hébergé en UE, vous voyez le score de confiance renvoyé et la version du modèle.
3. Action — ce que le client a fait : laisser passer, anonymiser sur place, ou bloquer avec une bannière visible par l'utilisateur.

Sous la chronologie figurent la règle de détection d'origine (pour voir exactement ce qui a matché), le score de confiance ML et les positions au caractère près de chaque détection dans le prompt. Survolez une position pour la mettre en évidence dans l'aperçu rédacté.

Flux de triage

Traitez chaque incident comme un petit ticket. Le flux est volontairement court :

1. Ouvrez l'incident et lisez la chronologie.
2. Tranchez : détection réelle ou faux positif. Cliquez sur Confirmer ou sur Rejeter comme faux positif. Les rejets alimentent la file d'ajustement des détecteurs que nous revoyons chaque semaine.
3. Si l'incident est réel et nécessite un suivi, attribuez-le à un membre de l'équipe via le menu Assigné à. L'assigné reçoit une notification par e-mail et, si configuré, en DM Slack.
4. Faites-le progresser dans les statuts : Ouvert → En revue → Résolu. Chaque changement de statut est inscrit au journal d'audit avec acteur, horodatage et motif.

Nous recommandons un passage quotidien de 15 minutes sur Critique et Élevé, et un balayage hebdomadaire sur Moyen. Faible ne nécessite presque jamais de revue humaine, sauf si un motif se dégage dans les rapports.

Créer un détecteur personnalisé à partir d'un incident

La chose la plus utile que vous puissiez faire dans ce tableau de bord est de transformer une détection réelle récurrente en détecteur. Cas typique : vous voyez régulièrement vos propres identifiants clients internes (du genre CUS-12345) fuiter dans des prompts ChatGPT. Un détecteur générique ne les attrapera pas — mais vous pouvez en créer un en moins d'une minute.

1. Ouvrez un incident qui contient l'identifiant récurrent.
2. Dans le panneau de droite, cliquez sur Créer un détecteur à partir de cette détection.
3. Zeuslock propose une regex (ex. \bCUS-\d{5}\b), une sévérité et une action suggérées.
4. Ajustez la regex si besoin, nommez le type de détection (ex. internal_customer_id), choisissez l'action : Monitor, Anonymize ou Block.
5. Cliquez sur Backtest sur les 30 derniers jours. Zeuslock rejoue la regex candidate sur les 30 derniers jours d'incidents (et un échantillon de prompts sains) et vous indique combien d'alertes supplémentaires elle aurait produites et chez quels utilisateurs.
6. Si le niveau de bruit est acceptable, cliquez sur Activer. Le détecteur est diffusé à chaque extension navigateur et agent de bureau au prochain heartbeat de politique (moins de 60 secondes).

Étiquettes, preuves, listes de surveillance, SIEM

Étiqueter les incidents

Les étiquettes libres sur un incident sont reportées dans les rapports et exports. Utilisez-les pour ce que le schéma ne capture pas : erreur-fournisseur, rgpd-art-32, revue-t2. Les étiquettes rendent les revues mensuelles consultables des mois plus tard.

Exporter les preuves

Deux formats d'export, depuis la barre d'outils :

• Export → CSV sur une liste filtrée — une ligne par incident, avec utilisateur, destination, types de détection, action, sévérité, horodatages, étiquettes et assigné. C'est ce que demandent généralement les auditeurs.
• Export → PDF sur un incident — la chronologie, la règle, le prompt rédacté, l'action et la piste d'audit des affectations et changements de statut. C'est l'artefact à joindre à un ticket d'enquête interne.

Listes de surveillance

Dans Incidents → Listes de surveillance, épinglez des utilisateurs, groupes ou destinations spécifiques. Les entités épinglées remontent en tête du tableau, peuvent déclencher des alertes e-mail ou Slack et disposent de leur propre tuile KPI. Cas typiques : épingler l'équipe finance pendant la clôture trimestrielle, épingler deepseek.com pendant que vous finalisez une décision sur le shadow-AI, épingler un prestataire le temps d'une mission.

Envoyer les incidents vers votre SIEM

Chaque incident peut être poussé vers votre SIEM en temps réel. Un webhook se déclenche par incident avec un payload JSON, signé en HMAC-SHA256 pour que votre collecteur vérifie qu'il vient bien de Zeuslock. Pour la forme du payload, la sémantique de retry et la vérification de signature, voir Webhooks et intégration SIEM. Splunk HEC, Microsoft Sentinel et Elastic les consomment sans code spécifique.

À quoi ressemble un bon triage

Vous saurez que le tableau de bord fonctionne quand trois choses seront vraies : votre file d'incidents Ouverts a moins d'une journée d'ancienneté, votre taux de faux positifs par détecteur baisse semaine après semaine, et la majorité des incidents passent par Anonymize plutôt que Block. Ce dernier point est l'objectif : vos collaborateurs continuent à travailler, et vos données sensibles restent à leur place.