Dossier argumenté de sûreté

Le concept de safety case est né au Royaume-Uni, d'une catastrophe industrielle : l'explosion de la plateforme de forage offshore Piper Alpha de la société américaine Occidental Petroleum, en 1988, au large de l'Écosse^[5],[6]. Cet accident industriel, ayant causé en 22 minutes, 167 morts et une perte approchant les 3 milliards et demi de dollars US de l'époque, a montré la dangerosité d'une approche fragmentée de la sécurité dans les grands systèmes dangereux^[7],[8].

Le « rapport Cullen »^[9], commandé pour comprendre la catastrophe, et en tirer des leçons, a formulé 106 recommandations. Elles furent toutes acceptées par l'industrie au Royaume-Uni, et mise en œuvre de manière répartie entre le régulateur (Health and Safety Executive ou HSE), les opérateurs et l'ensemble du secteur. Dès 1993, les opérateurs avaient appliqué la quasi‑totalité des recommandations qui leur incombaient. La recommandation centrale de Lord Cullen adoptée en 1992 (et aussitôt intégrée dans la législation anglaise)^[10] a été l' Offshore Installations (Safety Case) Regulations, qui impose à chaque exploitant d'installation offshore opérant dans les eaux britanniques de soumettre à la HSE un safety case pour approbation, visant notamment un niveau de risques « aussi bas que raisonnablement possible » (ALARP). Toutes les plateforme off-shore anglaises avait soumis un safety case en 1993, acceptés par la HSE entre 1993 et 1995^[7]. Au lieu de supposer qu'un système est sûr parce qu'il respecte une liste d'exigences, il faut désormais produire un argumentaire structuré, fondé sur des preuves et sur la science, démontrant que les risques ont été identifiés, évalués et réduits à un niveau acceptable^[11].

Plusieurs analyses, par exemple faites par Sefton (1994)^[12], Mansfield (1994) ou Baldwin, Cave et Lodge (2011)^[13] estiment que le nouveau régime des safety cases s'inscrit dans un mouvement plus large d'auto‑regulation (self-regulation) où l'État fixe des objectifs généraux et laisse aux opérateurs la responsabilité de démontrer la sécurité, un modèle généralement perçu comme moins contraignant que des prescriptions règlementaires strictes, en accord avec l'émergence d'une tendance ultralibérale plus large, d'effacement de l'État, au profit d'un passage d'une règlementation prescriptive à un approche de type better regulation et « goal‑setting » (c'est à dire qui fixe des objectifs de sécurité à atteindre, plutôt que des règles imposant les moyens de les atteindre ; laissant aux exploitants la responsabilité de démontrer — par des moyens qu'ils choisissent — que ces objectifs sont effectivement remplis.

Ces approches sont caractéristique de la philosophie politique britannique libérale puis ultralibérale de self‑regulation, issue du Health and Safety at Work Act des années 1970, et développée durant les 11 ans de gouvernement de Margaret Thatcher^[14],[13]. Ce glissement sociopolitique de la gestion du risque, du gouvernement vers les entreprises, n'est pas qu'une simple réforme technique de la sécurité industrielle ; c'est un changement de culture du risque et de « régime de régulation des risques », cohérent avec le contexte thatchérien de libéralisme économique et de transfert de responsabilité de l'État vers le monde économique, résultant selon Christopher Hood et al. (2001) d'une combinaison de pressions venues du marché, de l'opinion publique, des intérêts organisés et des stratégies industrielles et gouvernementales d'évitement du blâme (après les catastrophes ou dans le contexte de la sécurité routière ou des pollutions chroniques)^[15].

La notion de safety case a en effet émergée sous le gouvernement conservateur de John Major pour mettre en œuvre les recommandations du « Rapport Cullen » d'une manière immédiatement jugée satisfaisante par les industriels, dans le contexte politique et idéologique de l'époque. L'argument souvent cité était qu'il est préférable d'apporter une telle réponse à la difficulté de garantir la sécurité industrielle d'installations dangereuses, plutôt qu'uniquement s'appuyer sur des règles prescriptives imposées aux industriels, surtout quand les systèmes deviennent complexes, évolutifs et/ou fortement interdépendants^[12].

Cet accident et de nombreux autres ont aussi en Europe et dans le monde poussé l'idée qu'un exploitant doit assumer la responsabilité de démontrer la sûreté de son installation dans son contexte — réel — d'exploitation. Dans plusieurs pays de culture juridique anglo-saxonne, cette logique a été reprise et même consolidée dans des secteurs comme le nucléaire, l'aéronautique et certains systèmes de défense, où le safety case a pris la forme d'un dossier de sécurité (DS) obligatoire, vivant, reliant revendications de sûreté, argumentation technique et ensemble de preuves ; mis à jour tout au long du cycle de vie du système concerné.
Ce dossier a été formalisé par la norme Européenne EN 50129 en 2003 (mise à jour en 2018) ; un DS est « une démonstration documentée que le produit (par exemple,un système, un sous-système ou un équipement) satisfait les exigences de sécurité spécifiées ». Cette définition remonte à l’objectif initial de la norme EN 50129 visant l’acceptation des systèmes électroniques liés à la sécurité dans le domaine de la signalisation ferroviaire » (...) « un ensemble de preuves documentées qui fournissent un argument convaincant et valide selon lequel un système est suffisamment sûr pour une application donnée dans un environnement donné »^[16].

Le safety case est en l'une des déclinaisons anglosaxones du principe de précaution^[17], en ce sens qu'il organise l'action face à l'incertitude, et exige de justifier explicitement les décisions lorsque les conséquences potentielles d'une défaillance sont graves. Les safety cases sont principalement utilisés au Royaume-Uni, en Australie et en Nouvelle Zélande, et localement en Norvège), tandis que les pays de l'Union européenne recourent plutôt à l'étude de dangers, à l'évaluation des risques via l'étude d'impact ou à des dossiers techniques sectoriels (pour l'aéronautique, le ferroviaire, les dispositifs médicaux...), sans nécessairement adopter le modèle d'argumentation unifiée du safety case. Dans le reste de l'Europe, hormis quelques exceptions (comme en Norvège pour le secteur pétrolier), le droit ne reprend pas le terme safety case ni d'équivalent direct dans ses textes juridiques, semblant privilégier une approche normative et modulaire, plutôt qu'une argumentation unique. Mais plusieurs directives européennes imposent des démonstrations de sécurité qui s'en rapprochent, par exemple :

• pour le secteur nucléaire (directive 2009/71/Euratom) : obligation d'une démonstration de sûreté complète avec le principe ALARA (As Low As Reasonably Achievable)... compte tenu des facteurs économiques et sociaux ; principe introduit dès 1996 dans la directive Euratom 96/29 sur la radioprotection et issu de la doctrine internationale de la Commission internationale de protection radiologique (CIPR), puis consolidé dans la directive 2013/59/Euratom ;
• pour le secteur ferroviaire (directive 2016/798) : système de gestion de la sécurité + évaluation des risques ;
• pour les dispositifs médicaux (règlement 2017/745) : dossier technique démontrant sécurité et performance.

Au milieu des années 2020, le concept de safety case connaît un regain d'intérêt, y compris hors du monde anglo-saxon, dans le domaine de l'IA, même si l'AI Act de 2024 ne le mentionne pas dans les obligations de produire une documentation technique et de mise en place d'outils d'évaluation et de gestion des risques de l'IA. Dans la littérature spécialisées et certains médias, cette modalité de gestion du risque est notamment invoqué dans le débat sur les IA frontière (IA les plus avancés, beaucoup plus susceptibles de produire des effets inattendus, systémiques ou difficilement réversibles). Des travaux récents proposent d'adapter le safety case à l'évaluation des IA, pour obliger les développeurs d'IA et d'agents intelligents à expliciter leurs hypothèses, leurs tests, leurs limites connues, les mesures de précaution et de réduction des risques, et les conditions dans lesquelles un déploiement peut être jugé acceptable. Dans ce nouveau contexte, le safety case pourrait devenir un instrument central de gouvernance de l'IA, à l'interface de l'ingénierie, du droit et des politiques publiques et de bien commun, parce qu'il permet, selon ses promoteurs, de relier la performance technique à une démonstration documentée de sûreté. Selon ses promoteurs, l'outil semble bien adapté aux objets, systèmes ou services nouveaux que des industriels souhaitent mettre sur le marché alors qu'on manque encore de retours d'expérience, et donc souvent de bonnes pratiques et de règlementation adaptée à leur propos.

Il est à noter que l'IA est elle-même — et de plus en plus — utilisée pour produire ou améliorer des safety cases. Par exemple dans les secteurs ferroviaires ou des lignes électriques, l'IA combine des analyses prédictives, des diagnostics de sécurité et des prévisions de charge pour de détecter les anomalies (surcharge, fluctuations, risques de déraillement) et pour anticiper les défaillances du réseau. Elle peut optimiser la signalisation ferroviaire via l'apprentissage par renforcement, ce qui réduit les retards et fluidifie le trafic. En réduisant les accidents, les pertes d'énergie et les inefficacités opérationnelles, cette approche contribue à rendre des infrastructures plus résilientes, intelligentes et durables. Elle est utilisables par les acteurs publics comme privés^[18].

Le « dossier argumenté de sûreté » doit, autant que possible, prouver que les allégations de sécurité sont fondées, c'est à dire que le système évalué ne présente pas de risque déraisonnable dans un contexte d'usage donné (taxis ou véhicules autonomes par exemple) ; C'est lui qui détermine quand un système est jugé « prêt à être déployé »^[19] ; c'est un outil de mise en œuvre minimale du principe de précaution.

En documentant de manière transparente l'identification des dangers, il justifie les mesures d'atténuation et leur suffisance. Il permet par exemple de « montrer à un décideur (par exemple, des conseils d'administration, des clients, des tiers) qu'un système est sûr »^[20].

Le droit européen n'a pas défini de modèle général de « safety case » mais il impose dans certains domaines un ensemble de preuves documentées de sûreté et de conformité incluant cette logique, y compris depuis peu pour les systèmes d'intelligence artificielle à haut risque (IA de pointe, IA frontière...).

Dans un certain nombre de juridictions, dont au Royaume-Uni, les risques doivent être maintenus par les industriels à un niveau aussi bas que raisonnablement possible (ALARP).

Par exemple aux États-Unis, la FDA a publié en 2010 un document d'orientation exigeant des fabricants de pompes à perfusion qu'ils soumettent des dossiers de sécurité dans le cadre des demandes 510(k).

La norme britannique de défense 00-56 définit cette approche^[21] comme fondée sur des preuves, ce qui la distingue d'une simple approche prescriptive de la certification de sécurité, qui exige que la sécurité soit justifiée par une procédure prédéfinie. Ces normes partent du principe que le respect de la procédure prescrite permettra de recueillir les preuves de sécurité requises pour justifier la sécurité^[22].

L'outil NSO pour « notation de structuration des objectifs » (ou GSN pour Goal Structuring Notation) est de plus en plus utilisée dans des industries où la sûreté est un enjeu critique, afin d'améliorer la structure, la rigueur et la clarté des arguments en matière de sécurité. La GSN permet de structurer, visualiser et présenter clairement l'argumentaire de sûreté d'un système complexe et dangereux. Ceci se fait notamment en représentant, de manière semi‑formelle, les liens entre objectifs, arguments et preuves devant démontrer que ce système est sûr^[27].

La NSO (ou GSN) décompose des objectifs de sécurité de haut niveau en exigences testables portant sur des attributs clés, comme la robustesse ou l'exactitude, ce qui améliore la traçabilité, facilite la conformité aux normes et permet la réutilisation d'arguments dans des systèmes similaires^[28].

Elle contribue à assurer la cohérence, l'exhaustivité, la lisibilité et la solidité de l'ensemble du « Dossier argumenté de sûreté » (safety case), en particulier lorsque celui‑ci est distribué et très détaillé. Les auteurs identifient trois usages typiques de la GSN :

1. au niveau du produit, où elle facilite une argumentation systémique couvrant plusieurs technologies et normes ;
2. au niveau technologique, où elle décrit la décomposition structurelle des solutions ;
3. au niveau fonctionnel, où les instances de motifs GSN assurent la traçabilité depuis chaque objectif de sûreté jusqu'aux exigences et aux éléments de preuve associés.

Aux États‑Unis, certains grands programmes du Département de la Défense — comme le système de gestion de vol du F‑35 — utilisent le GSN, l'IA et des méthodes modernes d'ingénierie appelées MBSE (ingénierie système basée sur des modèles) pour concevoir et vérifier des systèmes très complexes faisant eux-mêmes appels à de nombreux logiciels et sous-systèmes essentiels pour la sécurité.

Au Royaume‑Uni, l'usage du GSN dans les dossiers de sûreté a montré qu'il permettait de fournir des preuves de sécurité plus objectives et plus faciles à comprendre. Les analyses de sécurité et les dossiers de sûreté construits avec GSN ne seront efficaces, qu'à condition d'aussi y intégrer des arguments remettant en question les hypothèses, ainsi que des méthodes classiques d'analyse des dangers, et des modèles qui décrivent le comportement réel du système.

Des modèles plus avancés et des méthodes formelles peuvent aussi renforcer les preuves de sécurité.

Le comité G-48 de ka SAE (Society of Automotive Engineers, une organisation internationales qui publie des normes techniques très utilisées dans l'aéronautique, la défense et l'ingénierie système) a engagé en 2014, avec plusieurs agences du département de la Défense et des maîtres d'œuvre importants, un travail d'approfondissement, de formalisation et d'amélioration des processus et méthodes d'élaboration des dossiers de sécurité, en vue d'une possible intégration future dans plusieurs normes de sécurité^[29] (déjà adoptées comme bonnes pratiques par plusieurs organisations. Le G-48 comprend le bureau de sécurité de la NASA, des agences du DoD et des représentants de plusieurs grands groupes de défense. Il cite plusieurs avantages, fondés sur des preuves, des dossiers de sécurité par rapport aux normes ANSI/GEA-STD-010 et MIL-STD-882, notamment : 1. la formulation préalable des arguments (justification et affirmations) à utiliser et 2. un examen indépendant pour les vérifier et les valider. Étant donné que les dossiers de sécurité sont des approches structurées et fondées sur des preuves visant à satisfaire l'argumentaire de sécurité établi au début des programmes, ils peuvent s'avérer utiles pour compléter les méthodes et techniques d'analyse des risques existantes et éprouvées. Ce comité postule qu'à mesure que les dossiers de sécurité seront intégrés aux meilleures pratiques actuelles, ils ne remplaceront aucune méthode de sécurité efficace actuelle, telle que les analyses fonctionnelles des risques (AFR), mais pourront être intégrés à celles-ci, dès le début, ainsi qu'à des méthodologies de sécurité plus complètes et intégrées, afin d'argumenter et d'améliorer la collecte et la documentation de preuves objectives de sécurité tout au long du programme.

Dans les années 1990, le safety case est testé comme moyen d'évaluer et justifier la dangerosité de défauts de conception dans certains logiciels, en s'inspirant des méthodes d'évaluation d'installations industrielles dangereuses.

Trente ans plus tard, avec l'émergence de LLM de plus en plus puissants, la notion de « dossiers de sécurité » réapparait, mais elle a besoin d'un changement de paradigme » car les processus de safety cases ne sont plus assez structurés ni assez profonds pour évaluer la sûreté des intelligences artificielles, et en particulier celle des IA frontière et l'IA agentique, en raison de leurs propriétés émergentes^[20]. La possible émergence d'IA quantiques.

En mai 2024, lors du Sommet de Séoul sur l'IA 2024, 16 entreprises développant des modèles d'IA avancés ont signé un engagement volontaire^[30] pour :

• évaluer les risques liés à leurs systèmes d'IA ;
• identifier et mettre en œuvre des mesures d'atténuation ;
• établir des processus internes garantissant la sécurité de leurs modèles.

Selon Benjamin Hilton et ses collègues de l'AI safety Institute, en 2025 les développeurs d'IA frontière gagneraient à utiliser l'approche Security cases pour mieux remplir de nombreux engagements de sécurité, même si l'IA pose dans ce domaine des questions nouvelles en termes de méthodologie, de mise en œuvre de la méthode, et en 2025, cette méthode est déjà utilisée par Google DeepMind et Anthropic^{[20],[31],[32]}. Selon eux, en 2025, on pense savoir rédiger des safety cases pour les systèmes existants, mais on ne sait pas encore comment en produire qui soient robustes et crédibles pour des systèmes d'IA futurs, plus puissants. Les esquisser pourrait toutefois aider à identifier les lacunes de connaissances^[20].

La pandémie de Covid-19 et de nombreux problèmes de santé environnementale (zoonoses notamment) invitent les entreprises et organisations de santé à s'inspirer (en les adaptant) des safety cases utilisés par les industries à haut niveau de risque et/ou de sécurité (pharmacochimie, vaccins) pour prouver (aux autorités de régulation, notamment) qu'un produit ou un système est acceptablement sûr^[33].

Dans les années 2010, leur usage suscite un intérêt croissant dans le domaine des dispositifs médicaux et des technologies de l'information en santé, mais leur intégration dans la gestion générale de la sécurité sanitaire est encore émergente. Pour autoriser un médicaments, une autre procédure est requise (Common Technical Document). Selon Sujan et al. (2016), le safety case pourrait aider le secteur de la santé, en tant qu'outils d'analyse des risques et d'exposition à ces risques, plutôt que comme instrument règlementaire, au profit d'une gestion plus proactive de la sécurité^[33], mais cette possibilité est freinée par le fait que dans certains secteurs, les safety cases ont parfois conduit à une approche formaliste et centrée sur la conformité, au détriment d'une véritable culture du risque et de la sécurité^{[33], [11]}.

Dans certains secteurs (l'IA par exemple) les risques évoluent plus vite que la règlementation et les dispositifs de suivi et d'évaluation.

Des méthodes de développement agiles ont donc été testées pour la production des dossiers de sécurité^[34].

Par exemple, pour évaluer la sécurité de véhicules autonomes sur autoroute, en se basant sur « l'ingénierie dirigée par les modèles » et en utilisant les simulations informatiques, Kaiser et al. ont en 2025 proposé d'utiliser « SysML v2 » (une évolution du langage de modélisation SysML conçue pour décrire formellement et avec cohérence l'architecture, le comportement et les contraintes d'un système complexe), comme fil conducteur tout au long du cycle de développement du système. L'approche respecte plusieurs normes ISO, mais est dite « agile » car reposant sur des itérations courtes où à chaque niveau d'abstraction, les modèles SysML v2 servent de base commune à la conception, aux analyses de sécurité et à la validation par simulation, permettant un retour d'information précoce, et une amélioration progressive du système, au fur et à mesure des évolutions du modèle. Quand de nouvelles preuves sont disponibles, elle génèrent, automatiquement, une argumentation de sûreté complémentaire, en Goal Structuring Notation (GSN), facilitant la cohérence documentaire et l'analyse d'impact en cas de modification^[35]. D'importants gains de rapidité (et des économies de coûts) sont obtenus par le recours au développement virtuel et à une validation en partie faite à partir de la simulation basée sur des modèles (notamment en présence de risques humains et de matériels couteux) : il est bien plus rapide de simuler des tests matériels en environnement virtuel, d'améliorer le système puis de le simuler à nouveau, etc. plutôt que de le réaliser physiquement ces tests les uns après les autres. Il est ainsi possible de mieux réagir aux nombreuses surprises attendues lors des tests de systèmes complexes impliquant l'IA^[35]. De même, les fonctionnalités destinées au client peuvent souvent être évaluée dans des environnements virtuels à partir de modèles exécutables précoces, bien avant l'écriture du logiciel embarqué final ou la sélection des composants matériels (capteurs, calculateurs, etc.)^[35].

Selon Greenwell et al. dans la revue Nature en 2004, « La défaillance d’un système critique pour la sécurité, bien qu’indésirable, est souvent une source précieuse de leçons qui peuvent aider à prévenir de futures défaillances. Les pratiques d’analyse actuelles ne fournissent pas toujours autant de connaissances qu’elles le pourraient sur les éventuelles failles de l’argumentaire de sécurité des systèmes »^[36], souvent faute de cadre méthodologique rigoureux, ce pourquoi des auteurs ont proposé d’utiliser la structure du dossier de sûreté (safety case) pour aussi formaliser les retours d'expérience (en partant du constat que quand un objectif de sûreté n’a pas été atteint, on peut rétrospectivement identifier dans les argumentaires les les hypothèses ou preuves qui étaient défaillantes, puis en tirer des leçons explicites à intégrer dans le cycle de vie du dossier de sûreté^[36].

Les safety cases sont de plus en plus utilisés dans le monde anglo-saxon, mais l'accidentologie et les retours d'expérience montrent qu'ils peuvent être trompeurs quand ils sont concernés par des erreurs logiques (fallacies, raisonnements incorrects ou fallacieux donnant l'illusion d'être valide)^[37].

En 2006, pour aider les ingénieurs et évaluateurs à respectivement éviter et détecter ces erreurs, des chercheurs de la NASA ont proposé une taxonomie des failles logiques (par exemple émotionnelles, malveillantes, formelles, syllogistiques, causales), les plus graves et fréquente dans les arguments de sûreté étant, par exemples : conclure qu'un système est sûr parce qu'il n'a jamais échoué ; confondre « absence de preuve de risque » et « preuve d'absence de risque », utiliser des données non pertinentes ; ignorer des hypothèses critiques, comme quand on n'a pas imaginé qu'une centrale nucléaire pouvait être doublement affectée par un tremblement de terre et un Tsunami, ce qui a conduit aux accidents nucléaires de Fukushima de 2011^[38]. Les erreurs logiques, quasi-systématiques, relevées par ce groupe de la Nasa sont notamment les justifications inadéquates ; les mots, expressions ou phrases flous ou d'autres ambiguïtés ; les généralisations hâtives ; les preuves ignorées ; les causalités douteuses ; les arguments circulaires ; les analogies faibles ; les appels d'autorité mal fondés. Le même groupe, après avoir fait analyser des safety cases par des experts différents a aussi constaté qu'ils y détectent ou interprètent souvent mal ces failles logiques. Il a classé en 8 thèmes les erreurs logiques, résumés dans le tableau ci-dessous. Cette taxonomie permet de confronter successivement les arguments du dossier, pour plus facilement vérifier leur structure logique, leur pertinence, leur clarté et leur valeur de preuves.

Plusieurs autres analyses ont souligné les limites du modèle des safety cases, notamment quand ces dossiers deviennent trop complexes et trop volumineux pour être utilisés comme outils opérationnels, ou quand ils reposent excessivement sur l'auto‑déclaration des exploitants.

En particulier, les enquêtes faites après une autre catastrophe pétrogazière en offshore : l'explosion de la plateforme Deepwater Horizon en 2010, plate forme qui disposait d'un SAR case' (Safety Assessment Report case) validé par les autorités américaines, a montré que les procédures de sécurité de la plateforme y étaient incomplètes, obsolètes et insuffisamment intégrées aux décisions techniques, ce qui a selon les enquêteurs contribué à l'échec des couches de sécurité lors de la catastrophe, qui sans cela, aurait pu être évitée ou minimisée^[39]. L'analyse de cette catastrophe par les autorités américaines a eu diverses conséquences :

• elle a suscité la création du BOEMRE (Bureau of Ocean Energy Management, Regulation and Enforcement, une nouvelle agence américaine créée, dès 2010, après la catastrophe pour remplacer le Minerals Management Service (MMS), jugé trop proche de l'Industrie (plus tard, cette agence sera subdivisée en : BOEM (Bureau of Ocean Energy Management) et BSEE (Bureau of Safety and Environmental Enforcement) ;
• elle a suscité une mise à jour des recommandations internationales de sécurité faite par l'OMI pour les plateformes offshore dans le monde a également été faite, mais toujours en soutenant le principe du safety case:

« Il est recommandé que le commandant travaille avec le BOEMRE pour évaluer les avantages d'un passage à une approche de « dossier de sécurité » similaire à celle utilisée en mer du Nord, une méthode qui privilégie une approche plus holistique de la sécurité^[40]. »

Des travaux en sociologie de la régulation et de la gouvernance du risque, en analyse des organisations à haut risque et en ingénierie des systèmes complexes ont montré que l'efficacité des safety cases dépend fortement de la culture de sécurité, du partage fluide d'information entre entre opérateurs, sous‑traitants et autorités, mais aussi de la capacité des autorités à exercer un contrôle et des vérifications indépendantes. L'Industriel peut tendre à ne pas communiquer certaines informations critiques pour la sécurité en utilisant le secret industriel ou le secret des affaires. Dans les domaines hautement spécialisés et à forte asymétrie d'information, l'expertise de haut niveau est rare, coûteuse et concentrée dans l'industrie (c'est le cas par exemple dans les domaines de la fission ou fusion nucléaire, de la finance, de la santé, de l'agrochimie, des biotechnologies, du transport autonome ou d'autres technologies avancées, pour les modèles frontière de l'IA notamment, où seuls quelques acteurs possèdent les moyens de tester ou comprendre les modèles) ; l'indépendance du vérificateur est alors souvent difficile. La littérature évoque à ce propos :

• les phénomènes de capture réglementaire (regulatory capture, théorisés par Stigler en 1971, et devenu un actif immatériel stratégique pour nombre des grandes entreprises, leur permettant, via le lobbying et le pantouflage de façonner les règles du jeu économique à leur avantage^{[41],[42],[43]} ;
• le phénomène de « dépendance à l'expert » (expertise dependency, développé par Hood et Rothstein en 2001 dans leur travail sur la bonne gouvernance du risque^[44] ;
• le manque d'ouverture et de transparence de certains opérateurs ou organisations qui sont à la source du risque : certains entretiennent une dynamique autopoïétique (où l'organisation se protège en maintenant ses routines internes) et/ou en répondant en phases, chacune structurée autour de stratégies d'évitement du blâme, selon un modèle proposé par les auteurs, dit modèle de la « roue de Catherine » (métaphore basée sur un dispositif de feu d'artifice dit « Catherine Wheel », qui tourne rapidement en projetant des flux impressionnant d'étincelles... mais sans avancer), évoquant ici la manière dont les organisations tournent en rond entre adaptation minimale, justification, et gestion du blâme, plutôt que d'entamer les transformations profondes qui seraient nécessaires pour la bonne application des politiques publiques^[45] ;
• le problème de l'asymétrie des connaissances (knowledge asymmetry, par exemple traité par Perrow, Vaughan), parfois exacerbé par le secret industriel et en Europe par le secret des affaires.