D’Excel au tableau de bord HSE et à l’analyse des accidents sans transmettre de données personnelles. Étape 1 : le masqueur hors ligne

Pratique de préparation sécurisée des données pour le vibe coding et pour le travail avec des agents d’IA dans le cloud.

L’idée de la démarche : les données de travail restent dans le périmètre de l’entreprise. Seule une copie anonymisée ou un document déjà masqué est transmis à l’environnement d’IA externe. Le rétablissement des valeurs personnelles se fait en local.

Pourquoi un masqueur séparé s’est avéré nécessaire

L’usage pratique de l’intelligence artificielle en santé et sécurité au travail se heurte très vite à la question des données sources. Les tableaux de travail et les pièces d’un accident peuvent contenir des noms complets, des matricules, des noms de sous-traitants, des contacts, des montants et d’autres informations que l’on ne peut pas charger dans un service externe sans évaluation des risques.

En même temps, c’est précisément la structure réelle des données qui est nécessaire pour construire un outil utile. Un tableau de bord doit comprendre les champs et les liens réels du tableau, et un agent d’analyse des accidents doit comprendre la structure des explications écrites, des premiers signalements et des autres pièces. C’est pourquoi nous avons séparé les données de l’outil.

Résultat : le masqueur hors ligne est devenu l’élément de base de deux directions à la fois — la préparation de modèles Excel anonymisés pour le vibe coding ultérieur et la préparation de documents Word pour l’analyse des pièces d’un accident avec des agents d’IA dans le cloud.

Où faire le vibe coding et où coller les prompts

Pour un débutant, c’est plus simple qu’il n’y paraît : le Prompt 1 de la section « Prompts prêts à l’emploi » (à la fin de l’article) n’a pas besoin d’être collé dans un éditeur de code particulier. On le saisit comme un texte ordinaire dans un service d’IA capable de créer et de modifier des applications ou du code. La démarche est toujours la même : ouvrir le mode développement, coller l’intégralité du Prompt 1, obtenir la première version, la vérifier, puis donner dans le même dialogue le Prompt 2, le Prompt 3 et le Prompt 4 l’un après l’autre.

En pratique, plusieurs options fonctionnent. Dans ChatGPT — le mode « Travail » ou Codex, s’ils sont disponibles dans votre compte ; dans Claude — Artifacts ; dans Gemini — Canvas ; dans Perplexity — le mode Create files and apps, s’il est disponible dans votre offre ; dans Replit — Agent. Par exemple, dans ChatGPT il suffit d’ouvrir « Travail » ou Codex, de créer une nouvelle tâche et de coller le texte du Prompt 1 dans le champ du message. Dans Gemini : « Ajouter des fichiers » → Canvas → coller le Prompt. Dans Perplexity : choisir Create files and apps et coller le Prompt dans la ligne de requête. Dans Replit : ouvrir Agent, activer d’abord Plan si nécessaire, coller le Prompt et vérifier le résultat dans Preview après la construction.

Les noms des modes sont à jour au moment de la publication ; les interfaces et la disponibilité des fonctions de ces services peuvent évoluer.

Pour une première expérience, je conseillerais de commencer par ChatGPT, Claude ou Gemini : il y est plus simple de travailler en langage courant et de préciser les exigences étape par étape. Si le programme existe déjà et qu’un travail plus poussé sur le code est nécessaire, Replit, Codex et d’autres outils de développement spécialisés sont pratiques.

Important :quelle que soit la plateforme choisie, une exigence doit être posée séparément au début de la demande : « le résultat est un seul fichier HTML autonome, sans API externes, sans CDN ni dépendances réseau, capable de fonctionner internet coupé ». Et une règle de plus : on ne charge jamais dans un service de vibe coding de vrais fichiers Excel/Word contenant des données personnelles. Pour le développement, on n’utilise qu’une copie anonymisée vérifiée ou un fichier de test.

Direction 1. Excel : un modèle anonymisé pour le vibe coding

Pour l’analyse de grands volumes de données, il nous importe de conserver la structure du tableau : noms des feuilles et des colonnes, types de données, dates, catégories, hiérarchie « site — atelier — secteur », processus et autres attributs. Les vrais noms et identifiants ne sont pas nécessaires pour développer l’enveloppe du programme.

Le tableau Excel de travail est donc chargé dans le masqueur HTML local. Sur l’ordinateur de l’utilisateur, le programme trouve les valeurs potentiellement sensibles, les montre avant remplacement et permet de corriger les règles à la main. Par exemple : « Ivan Ivanovitch Ivanov → Employé_001 », « Sous-traitant SARL → Organisation_001 », « matricule → ID_001 ».

En sortie, on obtient une copie anonymisée qui conserve la logique du tableau d’origine. C’est déjà avec elle que l’on peut travailler avec l’IA pour construire le programme : filtres, KPI, graphiques interactifs, recherche et détail jusqu’à l’enregistrement. Le fichier Excel d’origine, lui, reste dans l’entreprise.

Une fois le développement terminé, la vraie base ne doit pas du tout se trouver à l’intérieur du HTML créé. Le programme fini prévoit un bouton de chargement local du fichier Excel source : le fichier est lu par le navigateur sur l’ordinateur de l’utilisateur, et le tableau de bord recalcule les indicateurs à l’intérieur de la session locale. Ce sera la deuxième étape de cette série.

L’énoncé de base pour créer ce mode figure dans le Prompt 1 et le Prompt 2 (voir « Prompts prêts à l’emploi » à la fin de l’article).

Direction 2. Word : les pièces d’un accident sans divulgation des données personnelles

La deuxième utilisation du masqueur est la préparation des documents d’un accident pour une analyse ultérieure dans une IA dans le cloud. Au stade initial, il peut s’agir du premier signalement, des explications écrites, des déclarations des salariés et d’autres pièces au format Word.

Le masqueur crée une copie anonymisée du fichier Word : les noms complets et les autres valeurs choisies sont remplacés par des étiquettes conventionnelles stables. Il est important que la même personne conserve la même étiquette dans l’ensemble du dossier, sinon l’agent perd les liens entre les déclarations et les événements.

En parallèle, une clé de restitution chiffrée distincte est générée en local. La clé contient les correspondances entre les étiquettes conventionnelles et les valeurs d’origine. Un mot de passe lui est attribué ; ce mot de passe n’est pas transmis avec les documents et n’est pas conservé dans l’agent cloud.

Ensuite, seul le Word masqué est transmis à l’IA. L’agent peut analyser la chronologie, comparer les explications, repérer les contradictions, formuler des questions de clarification, chercher des liens de causalité et préparer un projet d’analyse d’enquête. L’enquête formelle et les décisions finales restent évidemment du ressort de la commission et des spécialistes responsables.

Lorsque le document masqué retravaillé revient de l’environnement cloud, la restitution se fait de nouveau en local. Trois éléments sont chargés dans le masqueur hors ligne : le Word reçu, le fichier de clé correspondant et le mot de passe. Le programme rétablit les valeurs d’origine là où les étiquettes conventionnelles ont été conservées dans le texte.

Ainsi, l’agent cloud travaille avec la logique de l’événement, mais ne reçoit ni les noms complets d’origine ni les autres valeurs masquées. La clé de restitution et le mot de passe ne sont pas transmis à l’environnement cloud.

L’architecture du travail bidirectionnel avec Word est décrite dans le Prompt 3 (voir « Prompts prêts à l’emploi » à la fin de l’article).

Comment l’outil lui-même a été créé

Le masqueur a lui aussi été créé avec le vibe coding. Ici, il est important de ne pas voir cette démarche comme l’ordre « fais-moi un programme » avec l’attente d’un résultat parfait. Le schéma de travail était différent : formuler une fonction, la vérifier, consigner le défaut ou la nouvelle exigence, et seulement ensuite passer à la version suivante.

La première exigence était un seul fichier HTML autonome sans installation. Puis sont venues la vérification manuelle des remplacements, la liste « Remplacer en plus », la liste « Ne pas modifier », l’effacement de la session en cours, le travail avec Word, la création d’une clé chiffrée distincte et la restitution locale du document.

Une étape à part a été l’autocontrôle technique. L’IA a reçu cette fois non pas le rôle de développeur, mais celui d’auditeur de son propre code : vérifier fetch, XMLHttpRequest, WebSocket, les bibliothèques externes, les CDN, les API, les iframes, les stockages locaux et les autres mécanismes par lesquels les données pourraient quitter l’ordinateur ou subsister après la fin du travail. Un tel audit ne remplace pas la revue des services informatiques et de sécurité de l’information, mais il permet d’écarter les risques évidents dès le stade du prototype.

La demande de vérification figure dans le Prompt 4 (voir « Prompts prêts à l’emploi » à la fin de l’article).

Ce que l’on obtient au final

Un seul outil local couvre deux tâches différentes. Pour Excel, il permet de préparer un modèle sûr et, sur cette base, de créer avec l’IA une analytique hors ligne de grands volumes de données. Pour Word, il permet de transmettre à une IA dans le cloud les pièces d’un accident sans divulguer les valeurs personnelles masquées, puis de restituer le document en local après l’analyse.

Le principe clé reste le même : d’abord exclure du périmètre externe ce que l’IA n’a pas besoin de connaître pour faire le travail, et seulement ensuite utiliser ses capacités.

Dans les prochaines publications, je montrerai séparément les deux prolongements de ce schéma : comment, à partir du modèle Excel anonymisé, on crée un tableau de bord HSE autonome avec chargement local de la vraie base, et comment un agent d’IA est utilisé pour analyser les pièces d’une enquête d’accident.

Prompts prêts à l’emploi pour créer et vérifier un masqueur local Excel/Word

Ces formulations sont destinées à un développement par étapes et à une adaptation à un scénario d’entreprise concret.

Prompt 1. Architecture de base d’un masqueur autonome Excel et Word

Crée une application locale autonome pour masquer des données dans Excel (.xlsx) et Word (.docx).

Format de l’application : un seul fichier HTML qui s’ouvre dans un navigateur ordinaire et fonctionne sans installer de logiciel supplémentaire.

Exigences critiques :
1. Après son ouverture, l’application ne doit pas accéder à internet.
2. N’utiliser aucune API externe, aucune télémétrie, aucun traitement dans le cloud ni transfert automatique des fichiers de l’utilisateur.
3. Toutes les bibliothèques nécessaires doivent être intégrées localement dans le HTML.
4. L’utilisateur doit pouvoir charger un ou plusieurs fichiers Excel/Word depuis son ordinateur.
5. Ne pas modifier les fichiers sources. Enregistrer le résultat dans une copie séparée.
6. Effectuer toutes les opérations dans la mémoire de l’onglet courant du navigateur.
7. Ajouter un bouton effaçant entièrement la session en cours.

Fonctions de masquage :
- rechercher les noms complets, les noms avec initiales et les autres valeurs personnelles choisies ;
- rechercher les organisations et les autres valeurs indiquées manuellement ;
- si nécessaire, masquer les numéros, les contacts et les montants ;
- une même valeur d’origine doit recevoir la même étiquette conventionnelle au sein d’une session ;
- avant l’enregistrement, montrer à l’utilisateur la liste des remplacements au format « emplacement / avant / après » ;
- permettre de désactiver ou de modifier à la main n’importe quel remplacement ;
- ajouter un champ « Remplacer en plus » ;
- ajouter un champ « Conserver tel quel », prioritaire sur les remplacements.

Pour Excel, conserver la structure des tableaux et les champs nécessaires à l’analyse ultérieure. Pour Word, conserver la structure du document autant que possible.

Après la première version, énumère séparément les limites de la reconnaissance automatique et les endroits que l’utilisateur doit vérifier à la main.

Prompt 2. Mode Excel : un modèle anonymisé pour le vibe coding et l’analytique HSE

Améliore le masqueur HTML local pour préparer en toute sécurité un modèle Excel qui pourra ensuite servir au développement d’un programme analytique avec l’IA.

Objectif : l’IA doit voir la structure du tableau de travail, mais pas les vraies valeurs personnelles ni les autres valeurs sensibles choisies.

Exigences :
1. Conserve les noms des feuilles, les en-têtes de colonnes, les types de données, les dates, les catégories et les attributs hiérarchiques, sauf si l’utilisateur les a marqués pour remplacement.
2. Remplace les noms complets par des étiquettes stables du type Employé_001, Employé_002, etc.
3. Remplace les organisations par des étiquettes Organisation_001, Organisation_002, etc.
4. Remplace les identifiants et les matricules, s’ils ont été sélectionnés pour le masquage, par des étiquettes ID_001, ID_002, etc.
5. Une même valeur d’origine doit recevoir le même remplacement dans tous les fichiers Excel de la session en cours.
6. Montre une liste préalable de tous les remplacements et permets à l’utilisateur de la corriger à la main.
7. Ne supprime pas des lignes ou des colonnes au motif que le programme ne les utilise pas.
8. Ne modifie pas le fichier source.
9. Après le traitement, permets de télécharger une copie anonymisée séparée.
10. Ajoute un avertissement bien visible : avant de transmettre le résultat à une IA externe, l’utilisateur doit vérifier à la main le fichier anonymisé.

Important : la restitution inverse d’Excel n’est pas nécessaire. La vraie base de travail reste dans le périmètre de l’entreprise ; la copie anonymisée ne sert qu’à concevoir la logique et l’interface du futur tableau de bord HTML.

Prompt 3. Mode Word : masquage, clé séparée et restitution locale

Améliore le masqueur HTML autonome pour un travail bidirectionnel avec Word (.docx).

Scénario :
1. L’utilisateur charge les documents Word d’origine relatifs à l’accident.
2. Le programme remplace en local les noms complets, les organisations et les autres valeurs choisies par des étiquettes conventionnelles stables.
3. L’utilisateur vérifie et confirme la liste des remplacements.
4. Le programme crée :
   a) un document Word masqué ;
   b) un fichier de clé chiffré séparé contenant les correspondances exactes « étiquette conventionnelle ↔ valeur d’origine ».
5. Pour le fichier de clé, l’utilisateur définit un mot de passe d’au moins 10 caractères. Ne conserve pas le mot de passe dans l’application et ne l’écris pas en clair dans la clé.
6. Le Word masqué peut ensuite être transmis à un agent d’IA externe pour l’analyse du contenu.
7. Après réception du Word retravaillé, l’utilisateur revient dans l’application locale.
8. Pour la restitution, il charge :
   - le Word masqué retravaillé ;
   - le fichier de clé correspondant ;
   - et saisit le mot de passe.
9. Le programme rétablit en local les valeurs d’origine à la place des étiquettes conservées et crée un Word restitué séparé.

Exigences de sécurité :
- la clé de restitution et le mot de passe ne doivent jamais être transmis automatiquement sur le réseau ;
- conserve la clé séparément du document masqué ;
- utilise un chiffrement moderne pour la clé (par exemple AES-256-GCM via la Web Crypto API) ;
- en cas de mot de passe erroné, ne révèle pas le contenu de la clé ;
- à la fin du travail, offre la possibilité d’effacer entièrement la session en cours ;
- affiche un avertissement indiquant que les étiquettes supprimées ou fortement modifiées par l’IA externe ne peuvent pas être restituées automatiquement ;
- ne reconnais pas automatiquement le texte à l’intérieur des images et avertis explicitement l’utilisateur de la nécessité de vérifier visuellement les images et les logos.

Conserve la structure du Word : paragraphes, tableaux, styles, en-têtes et pieds de page et images, autant que cela est techniquement possible. Ne modifie pas le fichier source.

Prompt 4. Audit technique de l’autonomie et des canaux de fuite possibles

Réalise un audit technique de l’application HTML créée en tant qu’outil local hors ligne destiné au travail avec des données sensibles.

Vérifie tout le code et énumère tous les mécanismes détectés susceptibles de créer un échange réseau ou une conservation durable du contenu des fichiers de l’utilisateur.

Vérifie séparément :
- fetch ;
- XMLHttpRequest ;
- WebSocket ;
- EventSource ;
- navigator.sendBeacon ;
- script src externes ;
- CSS et polices externes ;
- CDN ;
- API externes ;
- iframe ;
- envoi automatique de formulaires HTML ;
- Service Worker ;
- localStorage ;
- sessionStorage ;
- IndexedDB ;
- cookies ;
- URL externes dans les bibliothèques et le code ;
- télémétrie, analytique et crash-reporting.

Résultat attendu :
1. Le programme doit fonctionner pleinement internet coupé.
2. Les fichiers Excel/Word de l’utilisateur ne doivent pas être transmis sur le réseau.
3. Les clés de restitution et les mots de passe ne doivent pas être envoyés ni conservés automatiquement par l’application.
4. Si des stockages locaux du navigateur sont utilisés, explique pourquoi ; pour les données sources, les clés et les mots de passe, exclus leur usage.
5. Ajoute une Content-Security-Policy stricte interdisant les connexions réseau et l’intégration de contenu externe, dans la mesure où cela reste compatible avec le fonctionnement de l’application.
6. Après la commande « Tout effacer », supprime les données de la session en cours de l’état de l’application.
7. Après les corrections, vérifie de nouveau le code et rends un rapport court : quels canaux potentiels ont été trouvés, ce qui a été supprimé, ce qui est resté et pourquoi.

Important : précise qu’un tel autocontrôle du code ne remplace pas la revue informatique et sécurité de l’information de l’entreprise, ni l’évaluation juridique de l’admissibilité du scénario d’usage concret.

Règle pratique : ne transmettre à l’environnement d’IA externe qu’une copie anonymisée vérifiée. Le fichier de clé de restitution et le mot de passe doivent rester dans le périmètre local et ne pas être joints à la demande adressée à l’agent.