De Monitor à Bloquer : playbook de déploiement DLP IA en 90 jours

Le déploiement, c'est le produit

Un outil DLP IA allumé du jour au lendemain est un outil DLP IA éteint trois semaines plus tard. Tous les opérateurs que nous avons vus réussir à l'échelle ont déroulé le même type de plan : un pilote serré, une longue période en Monitor, un passage progressif à Anonymiser, un basculement final en Bloquer sur les catégories qui comptent, et une revue trimestrielle avec le sponsor exécutif. Quatre-vingt-dix jours entre l'installation et une posture d'application défendable.

Ce playbook est la version que nous déroulons avec les RSSI d'ETI européennes de 500 personnes. Opérateur-direct : qui fait quoi chaque semaine, à quoi ressemble le succès, quoi surveiller, et quoi dire en couloir aux RH, au juridique, à la DAF et au sponsor exécutif. Le schéma est toujours le même : faites confiance aux données, avancez lentement, et l'organisation suivra.

Le tableau des jalons à 90 jours

Jours 0-7 : pilote sur l'équipe sécurité uniquement

Installez l'extension navigateur Zeuslock et l'agent de bureau sur les 20 personnes de l'équipe sécurité et IT. Personne d'autre. Toutes les politiques en Monitor. Poussez via Intune ou MDM Workspace pour exercer le canal de déploiement que vous utiliserez plus tard, pas une installation manuelle. SSO/SCIM lié à Okta ou Azure AD dès le premier jour.

L'objectif de cette semaine n'est pas de tester la détection. C'est de détecter les faux positifs causés par les habitudes de votre propre équipe. Un ingénieur sécurité colle des chaînes hexadécimales légitimes prises pour des clés API. Un admin IT colle un identifiant d'actif interne qui matche la regex NIR. L'infrastructure colle des UUID pris pour des tokens. Vous voulez ce bruit visible dans la Console Opérateur avant de toucher un seul utilisateur final.

Qui fait quoi. L'opérateur Zeuslock (une personne nommée, ingénieur sécurité senior) pilote la console. Le responsable IT pilote le canal de déploiement. Le RSSI est briefé deux fois cette semaine-là, pas plus.

À quoi ressemble le succès. Vingt installations saines, 100 % de couverture des politiques, les dix premiers détecteurs en faux positifs identifiés, file de réglages ouverte. Heures-jusqu'au-premier-réglage consignées. Dans un pilote sain ce nombre est sous 24.

Conversation à avoir. Aucune en dehors de la sécurité pour l'instant. N'annoncez pas en amont. Vous voulez d'abord la version brute du comportement de vos équipes.

Jours 8-21 : 50 power users et la première mesure de référence

Étendez à 30 développeurs et 20 analystes support. 70 personnes sur la plateforme. Toujours en Monitor. C'est la phase où vous produisez les chiffres qui piloteront le reste du déploiement.

Envoyez une note courte aux équipes R&D et support. Pas un e-mail marketing. "Nous avons activé la détection IA mais pas le blocage. Vos prompts partent normalement. Nous mesurons. Rien ne change pour vous aujourd'hui. Nous vous préviendrons avant tout changement." Tout le script tient là. Résistez à l'envie d'ajouter un visuel.

Métriques à suivre. Prompts-par-ETP-et-par-jour, ventilés par direction. Taux de détection de données sensibles en pourcentage. Top cinq des types de détection. Latence médiane ajoutée par l'extension (sous 50 ms). Nombre de destinations IA distinctes — attendez-vous à au moins trois inconnues, dont un onglet Claude que personne n'a demandé à licencier.

À quoi ressemble le succès. Un rapport hebdomadaire propre à montrer au sponsor exécutif au jour 21, avec volume, taux, top détecteurs et top destinations. Aucune plainte, puisque rien n'est bloqué. La DAF demandera le coût — préparez le tarif par siège et le cadrage incident-évité.

Jours 22-45 : Monitor à l'échelle et sprint de réglage des faux positifs

Poussez l'extension et l'agent sur les 500 collaborateurs via Intune, Workspace ou GPO. Toujours en Monitor pour tout le monde. Trois semaines de visibilité totale avant la moindre application.

Tenez une revue hebdomadaire des faux positifs avec l'opérateur et un ingénieur. Réglez les dix détecteurs les plus bruyants. Utilisez des surcharges de détecteurs personnalisés pour les identifiants propres à l'organisation — tickets internes, codes de référence client, SKU entrepôt — tout ce qui est mal classé en carte bancaire ou identifiant national. Backtestez chaque surcharge contre le trafic de la semaine précédente avant promotion.

Si vous sautez le sprint de réglage, chaque faux positif en semaine 6 devient une plainte au helpdesk et une réunion RH. Réglez maintenant, économisez cinq heures de réunions plus tard.

Conversation avec les RH. Briefing de 30 minutes. Les salariés ne voient rien — la protection est invisible côté poste. La donnée n'est stockée que dans la Console Opérateur, restreinte à des opérateurs nommés. Montrez la piste d'audit. Confirmez la posture RGPD : résidence des données en UE, droit à l'effacement honoré, DPA signé, fiche au registre des traitements rédigée. Accord écrit avant la semaine 6.

Conversation avec le juridique. Déroulez la base légale (intérêt légitime, test de mise en balance documenté) et l'information du CSE. En France, c'est le moment d'informer le CSE. En Allemagne, le Betriebsrat doit être consulté avant tout mode d'application. Ratez cette étape et votre déploiement meurt en semaine 7.

Jours 46-65 : passer le financier et les PII de Monitor à Anonymiser

Activez Anonymiser pour credit_card, IBAN, e-mail, téléphone, NIR, DNI/NIE et Steuer-ID. L'anonymisation préservant le format envoie au LLM une valeur structurellement valide — un IBAN factice qui passe la clé de contrôle, un e-mail factice à example.com — pour que le raisonnement aval continue de marcher. L'utilisateur reçoit sa réponse. La donnée sort assainie.

C'est la première semaine où l'utilisateur final peut théoriquement remarquer quelque chose. La plupart ne remarquent rien, parce que les réponses du LLM restent utiles. Surveillez les métriques d'expérience : réponses toujours utiles, plaintes, contournement par reformulation. Le taux de contournement est le signal d'alerte précoce. Au-dessus de deux pour cent, votre anonymisation est trop agressive.

Conversation avec l'ensemble du personnel. Une note d'une page. Exemples concrets, zéro jargon. "À partir de lundi, quand vous collez un e-mail client dans ChatGPT, il sera remplacé par user@example.com avant de quitter votre poste. La réponse du modèle restera pertinente. L'alternative est une notification à la CNIL que nous préférons ne pas écrire." Signez avec le RSSI et le DRH. Les gens lisent les notes co-signées.

Métriques à suivre. Taux d'anonymisation par détecteur, volume de tickets helpdesk taggés ai-dlp, tentatives de contournement, satisfaction en pulse survey. Le taux de détection doit baisser sur les catégories basculées.

Jours 66-80 : passer identifiants et code source de Monitor à Bloquer

Activez Bloquer pour api_key (toutes variantes : AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, Bearer), password, private_key, jwt, aws_access_key et github_token. Ces catégories ne sont pas négociables. Aucune raison métier légitime de coller une clé AWS dans ChatGPT, jamais. Le message de blocage doit être poli, nommer ce qui a été bloqué et renvoyer vers le formulaire d'exception.

Ajoutez Bloquer pour le code source, cantonné aux groupes R&D. Le reste de l'entreprise n'a rien à coller comme code, et la R&D a besoin d'un workflow pour les cas qui le justifient. La CLI Zeuslock donne aux développeurs un pré-vol local avant de solliciter une exception.

À quoi s'attendre. Un pic mesurable de tickets helpdesk en semaine 11. La plupart ne sont pas des plaintes, c'est de la surprise plus un premier blocage déstabilisant. Formez le helpdesk au workflow d'exception avant le pic, pas après. Script : "Oui, nous l'avons bloqué. Voici le formulaire. L'opérateur répond sous quatre heures ouvrées. Si c'est urgent, voici le numéro d'astreinte." Les tickets reviennent au niveau de base à la fin de la semaine 12.

Conversation avec la DAF. Note courte au premier blocage d'identifiant. "À 14h03 aujourd'hui la plateforme a bloqué une clé d'accès AWS de production qu'un prestataire allait coller dans ChatGPT. C'est le type d'incident que le comité d'audit vous demandera. Nous avons maintenant la preuve que nous l'évitons." C'est comme ça que le budget de l'année 2 se valide.

Jours 81-90 : revue, reporting, renouvellement

Construisez le deck trimestriel. Six slides, pas seize. Incidents évités par catégorie. Top types de détection. Top directions par taux. Taux de faux positifs par semaine, avec la courbe qui s'aplatit après le sprint de réglage. Temps moyen de résolution. Une slide sur les 90 jours suivants.

Briefez le sponsor exécutif dans la langue qui lui parle. Pas le décompte des détections, le cadrage incident-évité. "Sur les 90 premiers jours, la plateforme a prévenu une douzaine d'incidents estimés qui auraient exigé une notification à la CNIL au titre de l'article 33 du RGPD, et trois incidents impliquant des identifiants de production qui auraient imposé une rotation de clés et une communication client." Choisissez les deux ou trois chiffres que le comité d'audit vous répétera, mettez-les en tête.

Puis décidez de la suite. Politiques plus strictes sur les catégories retenues. Plus de détecteurs personnalisés pour les identifiants découverts en semaine 5. Extension aux filiales mises de côté. Intégration du flux d'incidents au SIEM via Splunk HEC ou Microsoft Sentinel, routage des findings critiques vers PagerDuty, résumés hebdomadaires Slack pour l'équipe opérateur.

La checklist

1. Jours 0-7 : 20 utilisateurs sécurité/IT, Monitor, régler le bruit créé par votre propre équipe.
2. Jours 8-21 : ajouter 50 power users, baseline prompts-par-ETP et taux de détection, premier rapport hebdomadaire.
3. Jours 22-45 : déployer aux 500 en Monitor, sprint de réglage des faux positifs, briefer RH et juridique par écrit.
4. Jours 46-65 : basculer PII et financier en Anonymiser, envoyer la note sobre d'une page co-signée RSSI et DRH.
5. Jours 66-80 : basculer identifiants et code en Bloquer, préparer le helpdesk avant le pic, briefer la DAF sur la première prévention réelle.
6. Jours 81-90 : livrer le deck six slides au sponsor exécutif, cadrer les incidents évités en langage régulateur, sécuriser le trimestre suivant.

Pour le détail opérateur de chaque phase, voir le guide des politiques de détection et la checklist de déploiement.