Systèmes automatisés et IA en exploitation industrielle

Lorsqu’un système automatisé ou d’intelligence artificielle intervient dans une séquence accidentelle, l’expertise doit établir trois choses : ce que le système a recommandé ou exécuté, ce que l’opérateur pouvait vérifier, et qui disposait de quelle information à quel moment. J’apporte à l’expert une double lecture, d’exploitant de sites à haut risque et de spécialiste de l’assurance des systèmes d’IA en exploitation.

De quels systèmes parle-t-on ?

• L’automatisme classique : régulation, séquences automatiques, arrêts d’urgence. Son comportement est déterministe et documenté.
• Les systèmes d’IA en exploitation : maintenance prédictive, optimisation de production, détection d’anomalies, aide à la décision en salle de contrôle. Ils peuvent être développés en interne ou achetés, et leur comportement dépend des données sur lesquelles ils ont été entraînés.

La seconde catégorie pose des questions nouvelles, parce que son raisonnement ne se lit pas dans une procédure.

Quelles questions pour l’expertise ?

• Qu’a fait le système ? Qu’a-t-il recommandé ou exécuté ? Sur quelles données, et la trace en a-t-elle été conservée ?
• Qu’a vu l’opérateur ? Que lui présentait l’interface ? Le système filtrait-il ou hiérarchisait-il l’information ?
• L’opérateur pouvait-il détecter une erreur ? Disposait-il d’un moyen indépendant de vérifier la recommandation, et du temps pour le faire ?
• Qui pouvait passer outre ? Le système pouvait-il être désactivé ou contourné, et selon quelle règle ?
• L’étude de dangers intégrait-elle le système ? Son introduction, ou la mise à jour du modèle, a-t-elle fait l’objet d’une gestion des modifications ?

Ces questions restent techniques. Le sapiteur décrit qui disposait de quelle information et qui a exécuté quelle action. Il ne qualifie pas les responsabilités (art. 238 CPC).

Et lorsque le déploiement n’était pas gouverné ?

Le cas se présente lorsque des systèmes d’IA développés en interne ou achetés, intégrés à l’exploitation sans être traités comme des modifications, sans évaluation de leur effet sur les barrières, sans inventaire ni suivi de leur performance. Après un incident ou dans un litige, l’absence de gouvernance devient elle-même un objet d’expertise :

• le système avait-il été approuvé selon des critères définis, et par qui ?
• son introduction était-elle passée par la gestion des modifications ?
• l’étude de dangers et les procédures avaient-elles été mises à jour ?
• quelqu’un était-il chargé de surveiller sa performance et ses dérives ?
• les opérateurs avaient-ils été formés à ses limites ?

Ces questions sont de fait. Elles se documentent dans les pièces de l’exploitant, ou dans leur absence.

Quels documents l’expertise peut-elle demander ?

La profession s’est dotée d’un référentiel. Le rapport IOGP 817-1, IOGP’s Principles for Responsible use of AI with guidelines for implementation (avril 2026), décrit ce que l’industrie pétrolière et gazière attend d’un exploitant qui déploie l’IA. Il n’a pas de valeur réglementaire et ne se présente pas comme tel, mais il indique quelles traces un exploitant diligent est censé conserver. Autant de pièces que l’expert peut demander, et qu’un sapiteur sait lire :

• la documentation technique du modèle : capacités, limites, données d’entraînement, performances, modes de défaillance (§ 3.2.1) ;
• l’inventaire des systèmes d’IA en service, avec leur finalité, leurs données et l’évaluation de leurs risques (§ 3.2.3) ;
• les essais de robustesse et leurs résultats (§ 3.2.5) ;
• les dispositifs de supervision humaine : validation humaine des décisions critiques, protocoles d’intervention, mécanisme d’arrêt d’urgence du système et ses essais (§ 4.2.2) ;
• l’évaluation des facteurs humains avant déploiement : charge de travail, conscience de la situation, risque d’erreur (§ 4.2.3) ;
• les journaux des décisions, des données d’entrée et des performances du système, que le référentiel prévoit infalsifiables et conservés pour l’audit et l’enquête ; le suivi de la dérive du modèle et la gestion de ses versions (§ 4.2.5).

L’absence de l’une de ces pièces est en soi un fait technique que l’expertise peut constater.

Les autres références sont le règlement (UE) 2024/1689 sur l’intelligence artificielle, la norme ISO/IEC 42001 sur les systèmes de management de l’IA, et la recommandation DNV-RP-0671 (Assurance of AI-enabled systems). Formation : ISO/IEC 42001 Foundation (PECB).

Quelle grille d’analyse ?

J’analyse ces situations avec la grille ABR, AI Assurance Boundary Review (revue des limites d’assurance de l’IA). Elle part d’un constat : un modèle validé, performant et correctement employé dans son périmètre d’observation peut néanmoins compromettre une barrière. Le risque est identifié, la barrière est spécifiée, mais le modèle placé dans le processus de décision ne perçoit pas la condition que cette barrière a pour fonction de détecter. Pendant ce temps, l’organisation assimile la performance validée du modèle à l’accomplissement de la fonction de barrière.

Il s’agit d’une défaillance d’intégrité de barrière, non d’un défaut d’identification des dangers. Dans une expertise, cette grille permet de distinguer, en fait, une barrière mal spécifiée d’une barrière dont la fonction a été confiée à un modèle qui ne pouvait pas l’assurer.

Situations types

• Système automatisé ou d’IA impliqué dans une séquence accidentelle
• Défaillance d’une barrière de sécurité : système instrumenté, alarmes
• Modification non maîtrisée d’une installation

Voir aussi : barrières de sécurité, le sapiteur, cadre juridique.

Rédigé par Carl Goodwin, sapiteur en risque industriel. Mise à jour : 24 septembre 2026.

Définitions : Gestion des modifications (MOC) · Barrière de sécurité