L’IA au service de la commission d’enquête : d’un agent dans le cloud à l’enquête hors ligne sur les incidents
Comment nous sommes passés des premières expériences dans le cloud à un circuit opérationnel « outil de masquage → agent IA → démasquage », puis avons créé un système d’enquête hors ligne en phase de test, et comment nous préparons l’étape suivante : Fire, l’environnement d’IA d’entreprise sécurisé.
Idée maîtresse : l’IA ne doit pas « désigner un coupable » et ne remplace pas la commission. Son rôle utile est d’aider la commission à rassembler plus vite des éléments épars en un tableau cohérent, à repérer les lacunes, à vérifier la logique causale et à préparer un premier projet de rapport d’enquête exploitable.
Comment tout a commencé
Nous avons fait nos premières tentatives d’utiliser l’IA dans l’enquête sur les incidents dès 2023. L’idée paraissait alors assez simple : créer notre propre agent, y charger la méthodologie d’enquête et les pièces d’un événement concret, puis lui demander d’établir la chronologie, de relever les contradictions dans les déclarations écrites, de proposer des causes et des actions.
En 2024, les capacités des modèles se sont nettement élargies : ils ont commencé à travailler avec aisance non seulement sur du texte, mais aussi sur des images. L’une des premières expériences n’avait d’ailleurs rien d’une véritable enquête. Sur un site éloigné, une salariée a chuté et s’est blessée au pied. Une radiographie a été réalisée sur place, mais aucun spécialiste n’était là pour l’interpréter immédiatement. Nous avons chargé le cliché dans l’IA, et le modèle a signalé une zone évoquant une fracture du cinquième métatarsien.
J’insiste sur ce point : il ne s’agissait pas d’un avis médical, et cela ne doit pas en être un. L’interprétation définitive d’une image médicale relève du médecin. Mais pour nous, cet épisode a été un signal technique important : le modèle est capable de remarquer sur une image des détails qu’un non-spécialiste pourrait manquer. Dans une enquête, il peut donc potentiellement travailler non seulement sur du texte, mais aussi sur des schémas, des photographies et d’autres supports.
Première version opérationnelle : un agent dans le cloud
Lorsque des agents personnalisés plus fiables sont apparus, nous avons commencé à les configurer directement selon notre méthodologie d’entreprise. Nous avons créé des versions dans GPT, Gemini et Perplexity ; au début, nous avons aussi essayé Grok. On chargeait dans l’agent la méthodologie, puis les déclarations écrites, la description initiale, divers documents et d’autres pièces.
L’effet pratique a été immédiatement perceptible. L’IA recoupait rapidement les témoignages, proposait une séquence des événements, relevait les divergences d’horaires et de formulations, dressait la liste des questions complémentaires. Pour la commission, elle jouait le rôle d’un « second analyste » qui ne se lasse jamais de relire des dizaines de pages.
Mais cette première version avait un défaut évident : nous confiions en réalité à un service externe les véritables pièces de l’enquête. Pour les incidents, c’est particulièrement sensible : ces pièces peuvent contenir des noms et prénoms, des fonctions, des informations médicales, des déclarations écrites, des photographies et des informations internes à l’entreprise.
Plus nous utilisions l’outil, plus il devenait évident que la commodité ne peut pas justifier la transmission de données superflues vers l’extérieur.
Voir l’annexe des prompts : Prompt 1 — version sécurisée de l’agent cloud, destinée à travailler uniquement sur des pièces anonymisées au préalable.
La méthodologie est devenue plus rigoureuse — et cela a changé les exigences envers l’IA
Parallèlement, la méthodologie d’enquête interne de l’entreprise évoluait elle aussi. Pour moi, c’est un point essentiel : on ne peut pas laisser l’IA « inventer elle-même la manière d’enquêter ». Il faut d’abord une méthodologie, et c’est sur elle que l’on construit ensuite l’outil numérique.
Dans la méthodologie en vigueur, l’objectif principal de la commission n’est pas de rechercher un coupable, mais d’élaborer les mesures les plus efficaces possible pour éliminer ou réduire la probabilité qu’un événement similaire se reproduise. Si la chaîne comporte une action humaine, il faut aller plus loin et comprendre pourquoi cette action a été possible ou jugée acceptable.
L’enquête s’appuie sur la logique des barrières de sécurité : source de danger → événement indésirable → conséquences ; les barrières de prévention et les barrières d’atténuation sont examinées séparément. Au stade de l’analyse des informations, on établit la chronologie et on dégage les facteurs critiques. On construit ensuite l’arbre des causes, qui doit mener des causes immédiates et intermédiaires jusqu’aux causes profondes systémiques.
Dans les analyses plus simples, l’enchaînement des « Pourquoi ? » peut être court. Dans un événement complexe, il se ramifie et devient un véritable arbre des causes. La logique des barrières du « nœud papillon » permet de vérifier séparément pourquoi l’événement s’est produit et pourquoi les conséquences ont été précisément celles-là.
C’est précisément cette séquence qui est devenue plus tard l’ossature de notre application locale.
Voir Prompt 2–6 : chronologie et facteurs critiques → questions et contradictions → barrières → arbre des causes → actions.
Deuxième version : le masquage manuel
L’étape suivante était bien plus sûre, quoique assez peu pratique. Avant de charger les pièces dans l’agent cloud, nous remplacions à la main les noms de famille et les autres données sensibles : « Salarié 1 », « Salarié 2 », « Responsable 1 », « Unité 1 », etc.
Du point de vue de la confidentialité, c’était déjà un progrès. L’agent voyait la logique de l’incident, mais pas les vrais noms. Une fois l’analyse terminée, il fallait rétablir manuellement les désignations d’origine — souvent à coups de Ctrl+F.
Tant qu’il n’y a que deux ou trois personnes impliquées, ce processus reste supportable. Lorsque l’enquête compte de nombreuses déclarations écrites, des témoins, des documents et des noms qui reviennent sans cesse, le masquage manuel et la restauration inverse deviennent un travail à part entière et créent un risque d’erreur.
Troisième version : un outil de masquage local et le problème particulier de l’audio
Lorsque nous avons acquis des compétences en vibe coding, nous avons remplacé l’opération manuelle par un outil de masquage local, dont j’ai parlé dans le premier article de cette série. Le document Word est traité sur l’ordinateur, reçoit des désignations conventionnelles, et une clé de démasquage est enregistrée séparément. Cette clé est protégée par un mot de passe et n’est pas transmise à l’agent.
Dès lors, seules les déclarations écrites et autres pièces masquées peuvent être envoyées à l’IA dans le cloud. Le résultat obtenu revient sur l’ordinateur et y est restauré localement. C’est ce circuit qui est aujourd’hui opérationnel chez nous : outil de masquage local → agent d’enquête configuré → démasquage local. Il permet déjà de tirer parti des points forts du modèle cloud sans lui transmettre les noms d’origine ni la clé de restauration.
Mais il restait un autre point vulnérable : les enregistrements audio. Il est pratique d’enregistrer à l’oral les déclarations et les entretiens, mais pour les analyser, il faut d’abord les convertir en texte. Auparavant, on utilisait pour cela des services en ligne et des applications mobiles dédiés. Plus tard, la transcription est apparue directement dans les grands services d’IA. C’est pratique, mais l’enregistrement d’origine, avec la voix de la personne, part toujours à l’extérieur.
Nous avons donc créé un outil de plus : un outil de transcription local. Il utilise Whisper directement sur l’ordinateur. Lors de nos essais, la qualité de la transcription s’est révélée tout à fait comparable à celle des solutions cloud habituelles, alors que l’enregistrement audio d’origine ne quitte pas l’ordinateur. Après la transcription locale, le texte peut être masqué et seulement ensuite, si nécessaire, transmis à l’agent d’enquête opérationnel.
La chaîne de cette étape : transcription locale → outil de masquage local → agent cloud. Pour l’analyse des pièces, voir Prompt 1–6.
Quatrième version : le système hors ligne existe déjà — nous le testons maintenant
C’est là qu’une autre question s’est posée. Si la transcription, la lecture des documents et le modèle savent déjà fonctionner en local, pourquoi ne pas réunir le tout dans un seul environnement sécurisé ? C’est ainsi qu’est né un système expérimental d’enquête hors ligne. Il est déjà développé et fonctionne, mais aujourd’hui nous le considérons délibérément comme un outil de test : nous le vérifions sur des cas d’école et des cas anonymisés, nous comparons ses résultats avec le travail de la commission et nous cherchons les prochaines itérations qui rendront le processus plus rapide, plus pratique et plus robuste.
L’objectif était le suivant : créer un poste de travail unique pour la commission, où l’on peut charger le guide méthodologique, les informations initiales, les déclarations écrites, des fichiers Word et PDF, des enregistrements audio, des photographies et des schémas ; convertir localement en texte la parole et les documents ; suivre les étapes de la méthodologie et obtenir un premier projet de rapport Word modifiable.
Cela ne paraît simple que résumé en une phrase. En pratique, les itérations ont été innombrables. La reconnaissance vocale locale n’a pas fonctionné tout de suite, puis il a fallu venir à bout des PDF scannés, des images, des gros volumes de pièces, du modèle local, de la chronologie, des causes et du document final. Le schéma de développement était le même que dans nos autres projets : une modification → un lancement → un résultat ou une capture d’écran de l’erreur → l’itération suivante avec ChatGPT.
Au final, nous avons obtenu un système local doté d’une interface dans le navigateur et de son propre environnement d’IA local. Il transcrit déjà bien les enregistrements, lit les pièces préparées et produit un projet d’enquête structuré. Notre objectif aujourd’hui n’est pas de le déclarer « produit fini », mais de le tester sereinement, de comparer les résultats et d’améliorer la logique de travail. Pour faire tourner un modèle local complet et traiter rapidement de gros volumes, mieux vaut disposer d’un ordinateur suffisamment puissant.
Voir Prompt 8 — le prompt maître pour développer en vibe coding le poste de travail local de la commission.
Ce que sait déjà faire la version de test hors ligne
Dans la version de test hors ligne, tout le cycle est déjà organisé autour de la méthodologie, et non autour d’un simple chat avec l’IA.
La commission commence par consigner les informations initiales : ce qui s’est passé, la source de danger, l’événement indésirable, les conséquences, les personnes impliquées, les résultats de l’inspection des lieux. On établit ensuite un plan : à quelles questions il faut répondre, qui interroger, quels documents et quelles expertises obtenir.
Dans la section des pièces, on peut charger des fichiers DOCX et des PDF texte. Les documents scannés et les photos peuvent être reconnus localement ; les schémas et les images sont conservés dans le dossier, et le modèle peut proposer une description des détails visibles. L’audio et la vidéo sont transcrits localement. On peut aussi enregistrer un entretien directement au micro, puis en obtenir la transcription.
Une fois les pièces vérifiées, l’application aide à établir la chronologie. L’IA propose des événements et des citations, mais c’est la commission qui décide d’inclure ou non chaque entrée. Les facteurs critiques sont signalés séparément.
Le bloc suivant porte sur les barrières de sécurité et les causes. La commission examine les barrières de prévention et d’atténuation et construit deux branches de départ : pourquoi l’événement indésirable s’est produit et pourquoi il a eu de telles conséquences. Les causes proposées par l’IA restent des hypothèses jusqu’à leur confirmation par la commission.
Une fois les causes établies, on définit les actions : à quelle cause se rattache la mesure, qui en est responsable, dans quel délai, quel résultat vérifiable on peut en attendre, si une barrière temporaire est nécessaire, si la mesure doit être étendue au-delà d’un seul site.
Et ce n’est qu’ensuite que l’on prépare le projet de rapport. L’application peut assembler un premier projet Word selon la structure du guide méthodologique, en y intégrant la chronologie, l’arbre des causes, les barrières, le registre des pièces et les annexes.
Voir Prompt 2 — chronologie ; Prompt 3 — contradictions et données manquantes ; Prompt 4 — barrières ; Prompt 5 — arbre des causes ; Prompt 6 — actions ; Prompt 7 — projet de rapport final.
Ce que fait l’IA locale — et ce qu’elle ne doit pas faire
Il est important ici de ne pas surestimer l’automatisation. L’IA lit les textes vérifiés par fragments, propose une chronologie, des questions, des barrières, des hypothèses de causes et des pistes d’actions. Elle peut relever une contradiction entre deux déclarations écrites ou remarquer qu’il manque une période importante dans la chronologie.
Mais une citation tirée d’un document prouve seulement que ces mots figurent bien dans la pièce. Elle ne prouve pas la véracité du témoignage. Le texte reconnu peut contenir une erreur. Un schéma peut être mal interprété. Un lien de causalité peut n’être qu’une hypothèse.
C’est pourquoi l’application repose sur un principe : l’IA propose, la commission accepte, rejette ou modifie. Une cause ne devient pas confirmée automatiquement. Les responsables et les délais ne sont pas attribués par le modèle. Le projet Word n’est qu’un premier projet de travail, et non un document « prêt à signer ».
C’est d’autant plus important que le rapport interne ne remplace pas les documents prévus par la législation et par les procédures établies. La responsabilité de l’enquête reste entre les mains de la commission.
Voir Prompt 9 — contrôle de la qualité, de la confidentialité et des limites de l’automatisation avant d’utiliser le résultat.
La confidentialité est devenue partie intégrante de l’architecture, et non une consigne à part
Dans les enquêtes, la question de la confidentialité ne peut pas être remise « à plus tard ». La méthodologie elle-même classe les pièces de l’enquête interne parmi les documents à diffusion restreinte et exige expressément de protéger les données personnelles lors de la création et de la transmission des fichiers.
Dans la version de test hors ligne, les pièces du dossier, les transcriptions, les résultats d’analyse et le fichier Word restent sur l’ordinateur. Le modèle local fonctionne via une adresse loopback, et une fois les modèles nécessaires préparés, une session de travail sur le dossier peut se dérouler sans aucune connexion à Internet.
Mais là non plus, il n’y a pas de magie. Travailler en local ne signifie pas anonymiser automatiquement. Si l’on charge dans le dossier des noms et des informations médicales, ils resteront sur cet ordinateur et dans les annexes du dossier. Il faut donc appliquer les mesures habituelles de sécurité de l’information : un compte utilisateur protégé, des droits d’accès, des règles de conservation, des sauvegardes et, si nécessaire, un masquage supplémentaire.
Autrement dit, notre évolution ne s’est pas conclue sur le slogan « tout est hors ligne, donc tout est sûr ». Il est plus juste de dire que nous avons supprimé la transmission inutile des pièces vers l’extérieur et laissé le contrôle des données là où il doit être : au sein de l’entreprise.
Ce que nous utilisons aujourd’hui
Aujourd’hui, nous disposons en pratique de deux circuits. Le premier est opérationnel : nous masquons localement les pièces, transmettons une copie anonymisée à l’agent d’enquête configuré, puis démasquons localement le résultat obtenu. C’est ce schéma que l’on peut déjà utiliser dans le travail réel.
Le second est un circuit de test : un système entièrement hors ligne qui transcrit lui-même l’audio en local, lit les pièces, aide à construire la chronologie, les barrières et les causes, et produit un premier projet de rapport. Il fonctionne déjà, mais nous continuons à le vérifier et à l’améliorer. Pour nous, c’est une question de principe : on ne peut pas faire passer un pilote pour un système de production abouti simplement parce qu’il a belle allure.
Circuit opérationnel : outil de masquage → agent IA d’enquête configuré → démasquage.
Circuit de test : poste de travail entièrement local de la commission → vérification et itérations suivantes.
Prochaine étape : Fire, l’IA d’entreprise sécurisée
En parallèle, le service IT du Groupe développe l’IA interne Fire dans l’environnement d’entreprise Collab. Pour nous, c’est l’étape suivante logique : transférer la logique méthodologique de l’assistant de la commission vers un environnement d’entreprise sécurisé côté serveur, où il n’est plus nécessaire de choisir entre la puissance d’un grand modèle et les exigences de confidentialité.
Nous ne voyons pas Fire comme un « enquêteur automatique », mais comme un environnement de plus pour appliquer le même principe : les pièces restent à l’intérieur d’une infrastructure protégée, l’IA aide la commission à analyser la chronologie, les barrières, les contradictions et les causes, et les décisions restent prises par l’humain.
Avant le transfert, il faut d’abord vérifier les capacités techniques de Fire : le traitement des documents et de l’audio, la taille du contexte, la gestion des droits d’accès, la journalisation, le stockage des données et l’export des résultats. Là encore, nous partons de la méthodologie et de la protection de l’information, et non de l’envie d’utiliser à tout prix le dernier modèle en date.
Regardez la vidéo : le cycle complet de l’enquête locale
Dans cet article, j’ai délibérément choisi de ne pas surcharger le texte de dizaines de captures d’écran identiques. Un enregistrement d’écran de trois minutes montre mieux comment les éléments s’articulent entre eux, ce que fait réellement l’humain et ce que fait le logiciel.
Les captures d’écran servent là où il faut s’arrêter sur l’architecture : types de pièces, chronologie, causes, actions et fichier Word final. Le reste de la mécanique se voit mieux en vidéo — elle se trouve à la fin de l’article.
Où se situe le gain de temps
L’enquête sur un incident exige de toute façon des personnes : inspecter les lieux, interroger les personnes impliquées, obtenir les documents, discuter des faits, prendre des décisions. On ne peut pas automatiser la raison d’être de la commission.
En revanche, on peut éliminer une bonne part de la routine administrative : la retranscription des enregistrements audio, le recoupement des déclarations écrites, la recherche manuelle des incohérences temporelles, le report des citations dans la chronologie, la première répartition des barrières, la mise en forme de l’arbre des causes, la préparation d’une liste provisoire de mesures et l’assemblage du premier projet de rapport.
Et pour moi, l’effet principal ne réside pas dans la réduction du nombre de spécialistes. Bien au contraire : si le spécialiste passe moins de temps sur le travail mécanique avec les documents, il dispose de plus de temps pour ce qui justifie l’enquête elle-même — parler avec les gens, travailler sur le terrain, vérifier les barrières et aider les responsables à éviter que l’événement ne se reproduise.
Ce que nous avons obtenu au final
En quelques années, le parcours s’est révélé parlant : agent cloud ouvert → masquage manuel → outil de masquage et démasquage locaux → transcription locale → système hors ligne en test → prochaine étape vers Fire, l’environnement d’entreprise sécurisé.
Cela dit, l’outil de travail d’aujourd’hui n’est pas la version expérimentale hors ligne, mais le circuit éprouvé avec masquage : les pièces d’origine restent chez nous, l’agent reçoit une version anonymisée et la restauration s’effectue localement. Le système hors ligne, nous le testons actuellement et le perfectionnons pas à pas.
Le changement le plus important n’est même pas technique. Nous avons cessé de demander à l’IA « qui est coupable ? » et avons commencé à lui poser une autre question : « quelles données manquent, quelles barrières n’ont pas fonctionné, pourquoi n’ont-elles pas fonctionné et quelles mesures réduiront réellement le risque que l’événement se reproduise ? »
C’est dans ce rôle que l’IA est utile à l’enquête : ni juge ni président de la commission, mais un second analyste rapide qui aide les humains à travailler plus en profondeur sur les faits.
Encore une chose : ne pas oublier l’intelligence naturelle
Plus les modèles deviennent puissants, plus il est important de ne pas leur abandonner notre propre réflexion. L’intelligence artificielle est utile lorsqu’elle renforce l’intelligence naturelle : elle aide à voir plus vite les liens, à tester une hypothèse, à rédiger un brouillon et à libérer du temps pour parler avec les gens et travailler sur le terrain.
C’est pourquoi, pour moi, la bonne voie consiste à ne pas être de simples utilisateurs de boutons tout faits, mais des créateurs de nouvelles solutions : comprendre la méthodologie, définir l’architecture, vérifier le résultat, corriger les erreurs et devenir soi-même plus fort en même temps que l’outil.
Il faut utiliser l’IA, mais il faut tout autant mettre en œuvre et développer sa propre intelligence naturelle. Et si ce tandem aide à enquêter plus en profondeur sur les événements, à mieux en tirer les leçons et à éviter qu’ils ne se reproduisent, alors la technologie œuvre vraiment au service de la sécurité.
Les prompts de l’article
Circuit opérationnel avec masquage → système hors ligne en test → prochaine étape vers Fire, l’environnement d’entreprise sécurisé
Statut actuel : dans le travail réel, on utilise le circuit « outil de masquage local → agent cloud configuré → démasquage local ». Le système entièrement hors ligne est déjà développé, mais il est en phase d’essais et d’amélioration. Fire est envisagé comme la prochaine étape, celle de l’environnement d’entreprise sécurisé.
Prompt 1. L’agent opérationnel actuel : uniquement des pièces anonymisées
Lien avec l’article : sections « Troisième version » et « Ce que nous utilisons aujourd’hui ». C’est le circuit opérationnel actuel, après masquage local.
Tu es l’assistant analytique d’une commission d’enquête interne sur un incident en matière de santé et sécurité au travail et de sécurité industrielle.
CIRCUIT DE TRAVAIL :
Les documents d’origine sont d’abord masqués localement. Tu ne reçois que des copies anonymisées. Après ton travail, le résultat est démasqué localement à l’aide d’une clé et d’un mot de passe distincts, dont tu ne disposes pas.
IMPORTANT :
- travaille uniquement sur des pièces anonymisées au préalable ;
- n’essaie pas de reconstituer les noms, services, adresses ou autres valeurs masquées ;
- n’utilise ni Internet ni des faits externes, sauf s’ils te sont fournis séparément ;
- ne désigne pas de coupables ;
- ne présente pas une hypothèse comme un fait établi ;
- ne te substitue pas à la décision de la commission.
Objectif : aider la commission à structurer les pièces et à vérifier l’exhaustivité de l’enquête.
Pour chaque conclusion, distingue :
FACT — directement confirmé par une pièce ;
ASSUMPTION — supposition fondée ;
CONFLICT — contradiction entre des pièces ;
GAP — information manquante ;
QUESTION — question à résoudre ;
HYPOTHESIS — cause possible nécessitant confirmation.
Déroulement :
1. Établis le registre des pièces reçues.
2. Extrais uniquement les faits vérifiables, en indiquant leur source.
3. Établis une chronologie préliminaire.
4. Montre les contradictions et les lacunes.
5. Formule les questions complémentaires pour la commission.
6. Une fois la chronologie validée, propose une analyse des barrières.
7. Ne formule les causes que sous forme d’hypothèses jusqu’à la décision de la commission.
8. Ne rattache les actions qu’à des causes confirmées.
Dans tous les tableaux, indique la source : numéro de la pièce, document/fichier et courte citation ou emplacement exact sur lequel repose la conclusion.Prompt 2. Chronologie des événements et facteurs critiques
Lien avec l’article : section sur la chronologie dans l’agent opérationnel et dans le système hors ligne en test.
Je te transmets les textes vérifiés des pièces relatives à l’incident.
Établis un PROJET de chronologie.
Règles :
1. N’ajoute aucun événement absent des pièces.
2. Si l’heure est exacte, indique-la comme exacte.
3. Si l’heure est approximative, marque-la « approximative ».
4. Si deux sources donnent une heure ou une séquence différente, ne choisis pas une version en silence ; signale un CONFLICT.
5. Pour chaque ligne, indique : date/heure ; événement ou condition ; source ; statut FACT / ASSUMPTION / CONFLICT ; pourquoi c’est important.
6. Propose séparément une liste de facteurs critiques : événements/conditions sans lesquels l’événement indésirable ou la gravité des conséquences auraient probablement été différents.
7. Ne considère pas les facteurs critiques comme validés avant la décision de la commission.
À la fin, fournis :
A. le projet de chronologie ;
B. la liste des contradictions ;
C. la liste des données manquantes ;
D. le projet de facteurs critiques à soumettre à la discussion de la commission.Prompt 3. Contradictions, lacunes et plan d’entretiens complémentaires
Lien avec l’article : sections sur la planification, la collecte des pièces et le rôle de l’IA comme second analyste.
À partir des pièces et du projet de chronologie, prépare une fiche de travail pour la commission.
Il faut :
1. Relever les contradictions entre les déclarations écrites, les documents, les horaires et les données techniques.
2. Ne pas interpréter une différence de formulation comme un mensonge sans preuve.
3. Pour chaque contradiction, indiquer : source A ; source B ; en quoi consiste précisément la différence ; ce qu’il faut vérifier.
4. Formuler des questions pour des entretiens complémentaires.
5. Les questions doivent être ouvertes et neutres, sans suggérer la réponse.
6. Établir séparément la liste des documents, mesures, expertises, photos ou schémas susceptibles de combler une lacune.
7. Signaler quelles questions sont critiques pour établir les circonstances, les barrières de sécurité, les causes et la gravité des conséquences.
Ne conclus pas au manque de fiabilité d’un témoignage du seul fait qu’il existe une contradiction.Prompt 4. Logique des barrières et « nœud papillon »
Lien avec l’article : section sur la logique des barrières et le passage aux causes.
Utilise la chronologie et les facteurs critiques validés par la commission.
Établis un PROJET d’analyse des barrières.
1. Source(s) de danger.
2. Événement indésirable.
3. Conséquences.
4. Barrières de prévention : quelle barrière aurait dû empêcher l’événement/le contact ; existait-elle ; était-elle disponible ; était-elle appliquée ; a-t-elle fonctionné ; source de confirmation.
5. Barrières d’atténuation : quelle barrière aurait dû empêcher les conséquences ou en réduire la gravité ; existait-elle ; a-t-elle fonctionné ; source de confirmation.
6. Pour chaque barrière absente ou inefficace, formule la question « Pourquoi ? ».
Ne qualifie pas automatiquement l’absence d’une barrière de cause profonde.
N’invente pas de barrières absentes de la méthodologie, des documents ou de la logique du procédé sans la mention HYPOTHESIS.
Le résultat est un tableau à soumettre à la discussion de la commission, et non une conclusion validée.Prompt 5. Arbre des causes et causes profondes
Lien avec l’article : section « La méthodologie est devenue plus rigoureuse » et bloc consacré aux causes.
En entrée :
- la chronologie validée ;
- les facteurs critiques ;
- l’analyse des barrières ;
- les décisions de la commission sur les faits confirmés.
Construis un PROJET d’arbre des causes.
Point de départ : « Événement indésirable + conséquences ».
Deux premières branches :
A. Pourquoi l’événement indésirable s’est-il produit ?
B. Pourquoi ces conséquences sont-elles survenues / pourquoi leur gravité a-t-elle été celle-là ?
Ensuite :
1. Pour chaque nœud, pose la question « Pourquoi ? » autant de fois que nécessaire pour remonter jusqu’à une cause systémique.
2. Rattache chaque cause à sa question parente.
3. Chaque facteur critique doit apparaître dans l’arbre ou faire l’objet d’une explication distincte justifiant son exclusion.
4. Ne pas retenir une action/erreur humaine comme cause profonde. Poursuivre l’analyse : pourquoi l’action a-t-elle été possible ou jugée acceptable.
5. Ne proposer une cause profonde que si elle décrit une défaillance concrète d’un processus/système ; peut être éliminée ; relève du champ de maîtrise de l’entreprise/du Groupe ; permet de proposer une mesure concrète.
6. Les formulations générales non explicitées sont interdites : « faible culture », « imprudence personnelle », « mauvaise organisation », « lacunes de formation ».
Pour chaque nœud :
- formulation ;
- type : immédiate / intermédiaire / candidate au statut de cause profonde ;
- sources à l’appui ;
- facteurs critiques associés ;
- statut FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.
Ne valide pas une cause profonde à la place de la commission.Prompt 6. Actions correctives et préventives
Lien avec l’article : section sur les actions et le gain de temps dans la préparation du premier projet.
Utilise uniquement les causes que la commission a décidé d’inclure dans la liste pour l’élaboration des mesures.
Pour chaque cause, propose 2 à 4 options d’actions.
Pour chaque option, indique :
- quelle cause concrète elle élimine ou quelle barrière elle renforce ;
- type : technique / organisationnelle / formation / contrôle / autre ;
- le résultat vérifiable attendu ;
- comment vérifier son efficacité ;
- le périmètre d’application : lieu de l’événement / sites similaires / entreprise / Groupe ;
- si une mesure de protection temporaire est nécessaire avant la mise en œuvre de la mesure permanente ;
- les risques induits possibles ;
- les données nécessaires pour fixer le délai et désigner le responsable.
Ne renseigne ni le nom du responsable ni un délai précis sans décision de la commission.
Ne propose pas une action du type « organiser une instruction de sécurité non programmée » comme solution universelle si elle n’élimine pas la cause établie.
Signale séparément les actions qui ne font que renforcer le contrôle sans éliminer la cause profonde.Prompt 7. Projet de rapport final conforme à la méthodologie
Lien avec l’article : section sur la génération du fichier Word et le principe « un premier projet, et non un document à signer ».
Prépare un PROJET de texte du rapport interne en te fondant uniquement sur les éléments validés par la commission.
Utilise :
- la fiche de l’incident ;
- la chronologie validée ;
- la liste des facteurs critiques ;
- l’analyse des barrières validée ;
- l’arbre des causes final ;
- la liste des causes validée ;
- les actions convenues ;
- le registre des pièces.
N’intègre pas comme faits dans le document final des hypothèses non confirmées, des versions contestées sans mention ni des conclusions sans source.
Structure :
1. Informations succinctes et circonstances.
2. Pièces et méthodes de collecte des informations.
3. Chronologie.
4. Facteurs critiques.
5. Barrières de sécurité.
6. Analyse des causes.
7. Causes profondes.
8. Actions correctives et préventives.
9. Annexes / registre des pièces.
Dans la mesure du possible, conserve à côté de chaque conclusion importante le renvoi à la pièce sur laquelle elle repose.
En haut du document, indique : « PROJET. À vérifier et à valider par la commission ».
Ne formule aucune conclusion sur la culpabilité.Prompt 8. Prompt maître pour le système hors ligne en test
Lien avec l’article : section « Le système hors ligne existe déjà — nous le testons maintenant ».
Je ne suis pas programmeur. Aide-moi à créer une application locale DE TEST pour l’enquête interne sur les incidents selon la méthodologie de l’entreprise. L’objectif de cette étape est un pilote et une vérification de la qualité, et non une mise en exploitation industrielle automatique.
Travaille étape par étape. À chaque étape :
1. explique ce que nous faisons et pourquoi ;
2. donne une seule action ou un seul fichier/patch prêt à l’emploi ;
3. attends mon résultat ou ma capture d’écran ;
4. vérifie-le ;
5. ce n’est qu’ensuite que tu passes à la suite.
ARCHITECTURE CIBLE
- Windows 10/11 ;
- backend local sur 127.0.0.1 et interface dans le navigateur ;
- après une préparation unique des modèles, travail sur les pièces du dossier sans accès à Internet ;
- prévoir le fonctionnement sur un poste de travail performant ; pour une machine peu puissante, proposer un modèle allégé, sans cacher la baisse de qualité/de vitesse ;
- stockage local des dossiers ;
- archive du dossier avec sommes de contrôle ;
- historique des versions ;
- aucun envoi obligatoire des pièces vers des API externes.
PIÈCES
- DOCX : paragraphes, tableaux, en-têtes et pieds de page ;
- PDF avec texte ;
- PDF scannés / images — reconnaissance locale ;
- schémas / photographies — conserver l’original et ne proposer une description qu’à titre de brouillon ;
- audio / vidéo — transcription locale ;
- enregistrement au micro ;
- saisie et modification manuelles ;
- mention obligatoire « vérifié par rapport à l’original » avant toute utilisation du texte dans l’analyse IA.
MODÈLES LOCAUX
- LLM via un moteur local (par exemple Ollama) ;
- modèle de reconnaissance vocale multilingue Whisper ;
- si nécessaire, modèle vision local ;
- l’application ne doit pas télécharger de modèles à l’insu de l’utilisateur pendant une enquête.
MÉTHODOLOGIE / ÉTAPES
1. Informations initiales.
2. Plan de la commission.
3. Collecte des pièces.
4. Chronologie et facteurs critiques.
5. Barrières et causes.
6. Actions.
7. Rapport.
RÈGLES POUR L’IA
- L’IA ne fait que proposer.
- Chaque conclusion conserve sa source et sa citation.
- Distinguer FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Les causes restent des hypothèses jusqu’à leur confirmation par la commission.
- Le modèle ne désigne pas lui-même les responsables et les délais.
- La commission doit pouvoir accepter, rejeter ou modifier chaque proposition.
- Le fichier Word final est un projet modifiable.
- Inclure dans le rapport l’arbre des causes, les barrières, le registre et les annexes.
SÉCURITÉ
- pas de CDN ni de télémétrie externe ;
- appels réseau de l’enquête uniquement en loopback ;
- indiquer à l’utilisateur que travailler en local ne signifie pas anonymiser automatiquement ;
- ne pas stocker de secrets en clair dans le code client ;
- prévoir la suppression du dossier, sa sauvegarde et son transfert.
Commence par l’arborescence des répertoires, le format des données du dossier et le modèle de menaces. N’écris pas de code avant ma confirmation.
STATUT PILOTE
- marque explicitement la version « TEST / PILOTE » ;
- ajoute un jeu de cas d’école de référence ;
- pour chaque cas, compare le résultat de l’IA avec les conclusions de l’humain/de la commission ;
- tiens un journal des défauts détectés et des itérations ;
- ne qualifie pas le système de prêt pour l’exploitation industrielle avant la fin des essais.Prompt 9. Audit du système pilote hors ligne
Lien avec l’article : sections sur les limites de l’automatisation, la confidentialité et le statut de test actuel.
Réalise un audit de l’application finalisée et du projet d’enquête avant leur transmission à la commission.
VÉRIFIE SUR LE PLAN TECHNIQUE
1. Y a-t-il des appels réseau externes pendant le travail sur le dossier ?
2. Utilise-t-on des CDN, des polices externes, un speech-to-text dans le cloud, des API externes ?
3. Où sont stockés les documents sources, les transcriptions, les modèles locaux et les sauvegardes ?
4. Que se passe-t-il lors de la suppression d’un dossier ?
5. Les documents d’origine se retrouvent-ils dans les journaux de diagnostic ?
6. Le contenu du dossier est-il exporté en cas d’erreur ?
VÉRIFIE SUR LE PLAN MÉTHODOLOGIQUE
7. Toutes les conclusions importantes ont-elles une source ?
8. Les faits sont-ils séparés des hypothèses ?
9. Tous les facteurs critiques sont-ils pris en compte dans l’analyse des causes ?
10. Des actions humaines ont-elles été qualifiées de cause profonde sans analyse des conditions systémiques ?
11. Les actions sont-elles rattachées à des causes/barrières concrètes ?
12. Le modèle a-t-il désigné des responsables et des délais sans décision de la commission ?
13. Le projet de rapport est-il présenté comme un document validé ?
VÉRIFIE LA CONFIDENTIALITÉ
14. Quelles données personnelles/médicales se trouvent dans le dossier local ?
15. Un masquage supplémentaire est-il nécessaire pour une démonstration, une publication ou une transmission ?
16. Les noms de fichiers et les captures d’écran contiennent-ils des noms de personnes superflus ?
Présente le résultat sous forme de tableau :
Vérification | Statut | Risque détecté | Ce qu’il faut corriger | Qui doit valider.
Ne corrige pas automatiquement les conclusions de fond de l’enquête.
VÉRIFIE LE NIVEAU DE MATURITÉ
17. Existe-t-il un jeu de cas de référence et des résultats de comparaison ?
18. Quelles fonctions sont déjà stables et lesquelles restent expérimentales ?
19. Quelles erreurs/limitations doivent être éliminées avant une utilisation industrielle ?
20. L’interface donne-t-elle la fausse impression que la sortie de l’IA est une décision de la commission ?Comment utiliser les prompts
- Prompt 1 — le circuit opérationnel d’aujourd’hui : uniquement des pièces anonymisées au préalable ; la clé de démasquage n’est pas transmise à l’agent.
- Prompt 2–7 — blocs de travail méthodologiques, utilisables aussi bien dans l’agent actuel que dans le futur circuit local/serveur.
- Prompt 8 — création et amélioration continue du système de test entièrement hors ligne.
- Prompt 9 — audit du pilote avant l’extension de son utilisation.
Le principe fondamental de la série reste le même : d’abord protéger les données et définir la méthodologie, ensuite automatiser. L’IA renforce le travail de la commission, mais ne dispense ni de la réflexion professionnelle, ni de la vérification des faits, ni de la responsabilité humaine.