Volume 1 sur 2. Cadre doctrinal
Le présent document est le premier d’un ensemble de deux volumes qui composent ensemble la version 1.0 du cadre RAISE. Cette scission n’est pas un découpage de commodité ; elle reflète la double nature du framework explicitée en §2 du présent volume, à la fois cadre d’architecture et doctrine de gouvernance par l’architecture. Le Volume 1 expose l’architecture doctrinale du cadre. Le Volume 2 (référence interne TI-2026-FRMK-RAISE-v1.0-V2, Application opératoire) en expose la mise en œuvre sectorielle, les limites et la finition.
Le Volume 1 contient le préambule de l’auteur, la note méthodologique (critère de réfutation, transformations irréductibles T1 à T5, implication structurelle endogène, méthode de construction du cadre), la Partie I (Fondations argumentatives, §1 à §3), la Partie II (Cœur architectural, §4 à §6), une clôture courte qui rappelle les formules centrales et renvoie au Volume 2, l’Annexe A (glossaire opérationnel) et l’Annexe E (tableau Claims, Evidence et Conditions de falsification).
Le Volume 2 contient la Partie III (Opérationnalisation, §7 à §9, modèle de maturité et application sectorielle aux trois terrains principaux et aux trois secteurs annexes), la Partie IV (Discussion et finition, §10 à §12, limites authentiques avec modèle de seuil de criticité C*, évolution attendue, FAQ doctrinale), la clôture complète, l’Annexe B (sources réglementaires de référence par secteur), l’Annexe C (carrefour doctrinal Twingital), et l’Annexe D (notice de propriété intellectuelle, version et historique).
La séquence de lecture recommandée est linéaire : Volume 1 puis Volume 2. Le Volume 1 peut être lu seul comme exposé doctrinal sans perte d’intelligibilité interne ; le Volume 2 présuppose l’acquisition du Volume 1 sur les piliers, la matrice et les anti-patterns. Les deux volumes partagent référence interne, dépôt Soleau, et conditions de citation. La notice de propriété intellectuelle est consolidée en Annexe D du Volume 2 et applicable aux deux volumes.
Préambule de l’auteur
Note méthodologique. Critère de réfutation, transformations irréductibles T1 à T5, implication structurelle, méthode de construction
Partie I. Fondations argumentatives
§1. Genèse. Trois échecs qui appellent un cadre d’architecture
§2. Délimitation. Ce que RAISE est, ce qu’il n’est pas
§3. Différenciation. RAISE et les cadres existants
Partie II. Cœur architectural
§4. Les cinq piliers, en détail
§5. Matrice d’interdépendances 5×5
§6. Anti-patterns. Huit configurations à diagnostiquer
Clôture du Volume 1, ouverture sur le Volume 2
Annexes
A. Glossaire opérationnel E. Tableau Claims / Evidence / Conditions de falsification
RAISE n’est pas un cadre de gouvernance ajouté à l’architecture ; c’est l’architecture rendue gouvernable.
Cette phrase est l’énoncé central du document qui suit. Tout ce qui vient après en est l’instruction, la justification, et la mise à l’épreuve. Si elle paraît évidente au premier abord, c’est qu’elle énonce ce qui devrait l’être ; mais la pratique observée des déploiements d’IA en environnement régulé montre qu’elle ne l’est pas. La conformité, la gouvernance, l’auditabilité, l’explicabilité et la sécurité opérationnelle continuent d’être traitées comme des couches ajoutées à un système architecturalement déjà fait, c’est-à-dire, en pratique, à un système architecturalement déjà non gouvernable.
Le présent document ne propose pas un cadre de plus. Il propose un cadre d’une nature distincte de ceux qui circulent. NIST AI RMF gère le risque ; ISO/IEC 42001 manage un système ; l’EU AI Act énonce des obligations ; Microsoft RAI Maturity Model mesure la maturité organisationnelle ; les grilles sectorielles (HAS, EBA, ANSSI) qualifient des dispositifs spécifiques. Aucun des cadres largement adoptés ne fournit explicitement cette grammaire architecturale cyclique au niveau de la conception. Aucun cadre largement diffusé ne paraît occuper explicitement cette fonction architecturale de manière centrale, c’est-à-dire faire de la conception du système son objet primaire plutôt que sa contrainte dérivée. Cette formulation appelle une nuance immédiate, qui sera développée en §3 : les cadres existants ne sont pas indifférents à la conception, ils la touchent par contrainte. La fonction MAP du NIST AI RMF impose des artefacts architecturaux (frontières du système, surfaces de risque) ; ISO/IEC 42001, dans ses implémentations matures, oriente la conception par exigences de contrôle interne ; l’EU AI Act, par son Annexe IV et ses obligations de surveillance post-marché, impose progressivement des obligations design-time. La différence avec RAISE n’est donc pas binaire, elle est graduée : RAISE prend la conception comme objet primaire, là où les cadres existants la touchent comme conséquence dérivée de leur fonction principale. RAISE occupe cette case sans la prétendre absolument vide ; il ne se substitue à aucun des cadres existants, et il les présuppose.
Trois leviers de différenciation justifient la production de ce document plutôt qu’un texte court de positionnement. Premier levier : RAISE modélise les dépendances entre ses cinq piliers comme une structure cyclique, pas comme une chaîne linéaire. C’est, à notre connaissance, la seule cartographie qui rend visible les boucles de retour, par exemple le retour de l’explicabilité décisionnelle vers la lecture réglementaire active, ou le retour de la gouvernance vers la qualification de ce qui compte comme validation. Deuxième levier : le cadre est européen-centré par origine, et opère au niveau où le législateur européen a choisi d’opérer, c’est-à-dire au niveau de la conception du système et non de son déploiement. Troisième levier : la mise à l’épreuve sectorielle conduite en partie III ne se limite pas à une instanciation générique ; chaque secteur (Healthcare, Finance et Assurance, Défense et Sécurité nationale) y est traité par la tension caractéristique qu’il fait apparaître dans la matrice du framework. Aucun cadre concurrent largement diffusé ne paraît effectuer ce travail au niveau et avec cette structure cyclique typée.
Le document est organisé pour trois lectures distinctes. L’architecte système le lira linéairement, des fondations à l’opérationnalisation. Le responsable conformité le lira par section, en mobilisant les piliers comme grille d’évaluation. Le diagnostiqueur, qu’il soit consultant, audit interne ou direction des risques, pourra entrer directement par les anti-patterns du §6, qui lui fournissent un instrument d’analyse rapide. Aucune de ces lectures n’épuise le document, et chacune renvoie aux deux autres.
Une précision méthodologique enfin. Ce document est doctrinal. Il ne contient pas d’études empiriques quantifiées avec mesure avant-après. Cette absence n’est pas une lacune mais une conséquence de la nature d’un cadre d’architecture : le test n’est pas l’amélioration mesurée d’un indicateur agrégé, mais la capacité à supporter la conception de systèmes qui ne pouvaient pas être conçus de manière satisfaisante sans lui. La preuve est de structure, pas de performance. La preuve doctrinale précède l’épreuve empirique ; elle ne s’y substitue pas. Le §10 énonce explicitement les limites de cette posture.
Une doctrine forte doit énoncer comment elle échoue. Le critère ci-dessous est l’épreuve qui distingue, sur n’importe quel déploiement, la mise en œuvre du framework de la simulation d’une mise en œuvre.
RAISE échoue si son application ne modifie aucune décision de conception, ne rend aucune responsabilité plus nominative, ne contractualise aucune interface critique, ne transforme aucun protocole de validation, et ne qualifie aucun destinataire d’explication. Dans ce cas, RAISE n’a pas été appliqué ; il a été récité.
Ce critère prolonge et opérationnalise la formule centrale du document, énoncée en §3 et reprise en clôture : un cadre qui ne change pas la conception ne change que la documentation. Le critère de réfutation lui ajoute une seconde affirmation, plus dure : l’absence d’effet de structure sur l’un quelconque des cinq piliers, observable comme modification de décision, n’est pas une faiblesse de mise en œuvre. C’est une réfutation de l’application elle-même. Le framework reste possiblement valide en doctrine ; ce déploiement, lui, n’a pas eu lieu au sens architectural.
Cette discipline s’applique aussi à la critique du framework. Une démonstration que RAISE, correctement appliqué, n’a pas produit l’un des cinq effets attendus serait une réfutation du framework. Aucune objection moins exigeante ne tient lieu de réfutation.
Le critère ainsi posé reste, à ce niveau d’abstraction, interprétable. Pour le rendre discriminant à un niveau opératoire, le framework distingue cinq transformations irréductibles dont l’absence simultanée disqualifie tout déploiement, et dont la simulation est techniquement plus coûteuse à maintenir dans le temps que la mise en œuvre.
T1. Modification d’au moins une décision de conception structurelle (objet architectural créé, supprimé, déplacé, ou contractualisé), avec trace versionnée et signée par un architecte responsable.
T2. Nomination d’au moins une responsabilité opposable, avec mandat publié et procédure de blocage exercée au moins une fois sur une décision de conception réelle.
T3. Contractualisation d’au moins une interface critique, comprenant schéma versionné, sémantique opposable, garanties de qualité et clause de rupture, avec un consommateur ou un producteur identifié.
T4. Mise en place d’au moins un protocole de validation contextuelle distinct du benchmark, avec cohorte qualifiée, critères de représentativité documentés, et déclenchement de revalidation par signal et non par calendrier.
T5. Qualification d’au moins un destinataire d’explication par cadre d’usage, avec protocole de production tracé, et différenciation observable de l’explication selon le destinataire.
L’asymétrie de coût entre simulation et mise en œuvre est ce qui rend le critère discriminant. Une simulation de T2 par documentation impose à l’organisation de continuer à produire la documentation indéfiniment ; une simulation de T1 ou T3 réclame des traces signées et versionnées qui résistent à l’audit forensique ; une simulation de T4 exige le maintien d’une cohorte distincte que la moindre dérive opérationnelle disqualifie ; une simulation de T5 produit, mécaniquement, des explications différenciées que tout destinataire peut comparer. La discriminabilité du critère vient de cette résistance différentielle à la simulation, pas de la confiance accordée à la déclaration de l’organisation.
La formule centrale du document (un cadre qui ne change pas la conception ne change que la documentation) doit être lue, à ce stade, comme l’énoncé d’une implication structurelle qu’il faut maintenant rendre explicite. Soit Δ(conception) la modification observable des décisions de conception structurelle d’un système, mesurée à travers les transformations T1 à T5. Soit Δ(gouvernabilité) la modification observable de la gouvernabilité du système, mesurée à travers la satisfaction des cinq piliers et leur articulation matricielle. La thèse centrale énonce que :
Si Δ(conception) = 0, alors Δ(gouvernabilité) = 0.
Autrement dit : aucune modification de gouvernabilité n’est obtenue sans modification correspondante de la conception. La contraposée est plus parlante : toute modification réelle de gouvernabilité a une trace observable dans la conception. Une organisation qui prétend avoir amélioré sa gouvernabilité sans pouvoir produire au moins une trace de modification de conception se trompe sur son propre état, ou produit de la conformité par avenant.
L’implication n’est pas un théorème ; c’est un engagement structurel. Sa réfutation serait l’exhibition d’un cas où une amélioration de gouvernabilité, mesurée selon les piliers et la matrice, est obtenue sans aucune modification de conception. Aucun cas de cette nature n’a été identifié dans les déploiements publiquement documentés sur lesquels la doctrine est construite. La thèse centrale tient donc, jusqu’à exhibition d’un contre-exemple, comme implication structurelle de la doctrine.
Cette implication doit être lue dans son périmètre de définition. La gouvernabilité dont il est question est endogène au système, c’est-à-dire produite par sa conception architecturale. Elle se distingue de la gouvernance exogène, qui peut être imposée par voie infrastructurelle ou réglementaire à l’extérieur de l’architecture du système : kill switches de marché, circuit breakers prudentiels, contraintes de capital, plafonds opérationnels imposés par l’autorité de tutelle. Ces dispositifs altèrent l’admissibilité des sorties du système sans en modifier l’architecture interne. Ils constituent une forme distincte de gouvernance, complémentaire à RAISE mais non couverte par lui. L’implication structurelle énoncée ne porte donc pas sur la gouvernabilité au sens absolu, mais sur la gouvernabilité endogène ou architecturale. Cette restriction préserve la thèse de toute confusion avec les mécanismes de gouvernance exogène, et précise le domaine où la falsification serait recevable.
Pour permettre la critique méthodologique du framework au-delà de la critique de ses énoncés, la méthode de construction est explicitée. Quatre étapes ont été suivies.
Premier temps. Observation multi-sectorielle. Déploiements d’IA en environnement régulé entre 2022 et 2026, dans les secteurs Healthcare, Finance, Defense, Public et Infrastructures critiques, par participation directe ou par documentation publique des incidents de gouvernabilité, des décisions d’autorité de tutelle et des contentieux. Les observations ne constituent pas un échantillon statistique ; elles constituent un corpus qualitatif sur lequel la régularité doctrinale est construite.
Deuxième temps. Analyse comparative des cadres existants. NIST AI RMF, ISO/IEC 42001, EU AI Act, Microsoft RAI Maturity Model, grilles sectorielles HAS, EBA Guidelines, recommandations ANSSI, ont été qualifiés selon leur fonction primaire (gestion du risque, système de management, énoncé d’obligations, mesure de maturité, qualification sectorielle) et selon leur point de contact avec la conception du système (par contrainte ou par principe).
Troisième temps. Abstraction des patterns récurrents. Les configurations de défaillance observées et les configurations de réussite ont été abstraites sous forme de cinq dimensions interdépendantes (les cinq piliers), de leurs dépendances cycliques typées (la matrice 5×5), de leurs configurations pathologiques typées (huit anti-patterns canoniques et quatre patterns de second ordre), et de leur trajectoire de mise en œuvre (modèle de maturité à quatre niveaux avec régression contrôlée).
Quatrième temps. Test par contrefactuels et démonstration partielle. Les counterfactuels constructifs §5.6 et la démonstration partielle de nécessité des arêtes §5.5 constituent les premiers tests structurels du cadre. Les transformations irréductibles T1 à T5 constituent les tests opérationnels.
Cette méthode produit un cadre défendable comme régularité doctrinale, non comme théorème formel. Sa réfutation procède par contre-exemple architectural plutôt que par démonstration logique. La table Annexe E synthétise les claims, leurs evidences et leurs conditions de falsification.
RAISE ne naît pas d’une intuition théorique. Il naît de l’observation, conduite sur plusieurs années et plusieurs secteurs régulés, de trois échecs structurels qui se répètent avec une régularité suffisante pour ne plus être traités comme des accidents de mise en œuvre. Ces trois échecs ne sont pas des défaillances d’exécution ; ce sont des défaillances de conception. Ils émergent quand l’architecture du système d’IA est dessinée d’abord, et quand la conformité, la gouvernance et l’auditabilité y sont ajoutées ensuite. Ils ne sont pas réparables par effort de volonté ou supplément de documentation. Ils sont réparables par changement de l’ordre des opérations.
La distinction qui structure tout ce qui suit est la suivante : conformité par construction versus conformité par avenant. Elle n’est pas synonyme de la distinction familière entre security by design et bolt-on security, parce qu’elle ne porte pas sur une couche fonctionnelle, mais sur la grammaire entière de la conception d’un système d’IA. Elle énonce que la conformité à un corpus normatif ne peut être obtenue, dans des systèmes dont la spécification fonctionnelle dépend des données et des cadres normatifs eux-mêmes, qu’à condition que cette spécification soit construite avec la conformité comme contrainte de définition, non comme test de validation.
Le premier échec relève de ce que la littérature sur la dette technique nomme retrofitting, mais qui prend dans l’IA une forme spécifique : la performance est optimisée d’abord, puis la conformité est ajoutée sous forme de couches superposées (logs d’audit, dashboards de gouvernance, dispositifs d’explicabilité a posteriori, registres de décisions automatisées). Chacune de ces couches est, prise isolément, sérieuse. L’agrégat ne l’est pas, parce qu’il ne corrige pas la propriété architecturale qui rend le système non gouvernable : sa décision de conception initiale a été prise sans la contrainte de gouvernabilité.
La signature opérationnelle de cet échec est observable. Le système fonctionne. Les indicateurs de performance sont atteints. Les dispositifs de conformité sont présents. Pourtant, à chaque incident, à chaque demande de l’autorité de tutelle, à chaque cas-limite, le coût marginal de la justification d’une décision augmente plus vite que le volume de décisions. La conformité par avenant produit cette asymptote inverse : plus le système est utilisé, plus il devient lourd à justifier.
Le deuxième échec n’est pas un défaut de gouvernance. Il est un défaut de position de la gouvernance dans l’organisation. Les comités IA existent ; ils se réunissent ; ils émettent des avis. Mais leurs avis n’altèrent pas la conception des systèmes parce que la chaîne de décision architecturale court en parallèle, sans intersection effective. Cette configuration est si répandue qu’elle a sa propre catégorie dans la littérature de gouvernance des risques, celle de la governance theatre. Elle se reconnaît à un signe simple : la gouvernance produit des recommandations qui n’ont pas de force contraignante sur la conception du système, et la conception produit des architectures qui ne demandent pas l’avis de la gouvernance avant d’être figées.
Ce silotage n’est pas réparable par augmentation des effectifs ou par charte interne. Il est réparable par la position structurelle de la gouvernance dans le pipeline architectural, c’est-à-dire par une responsabilité nommée, opposable, et capable d’altérer la décision de conception avant qu’elle ne soit prise. L’écart entre une responsabilité nominée et une responsabilité diffuse n’est pas un détail d’organigramme. Il décide de la gouvernabilité du système.
Le troisième échec est documenté de longue date dans la littérature sur la société d’audit, et reprend dans les déploiements d’IA une forme particulièrement aiguë. L’audit existe ; il est conduit selon les règles de l’art ; ses livrables sont produits dans les délais et archivés selon les exigences de traçabilité. Mais aucune des observations qu’il formule n’est en mesure d’altérer la décision opérationnelle, parce que le moment de l’audit est postérieur au moment où la décision de conception a été prise et au moment où le système est en production. L’audit, dans cette configuration, ne décide rien ; il ratifie ce qui a été décidé sans lui.
La distinction qui tranche cet échec est la suivante : un dispositif de contrôle a une valeur de gouvernance si et seulement s’il a la capacité effective d’altérer la décision. La présence du dispositif n’est pas la preuve de sa fonction. Cette distinction sera reprise dans le §6, où elle structure le diagnostic des huit anti-patterns canoniques. Elle est ici énoncée pour ce qu’elle est : la pierre de touche du framework.
On objectera que l’architecture industrielle a, depuis longtemps, intégré la contrainte réglementaire à la conception. Le génie civil, l’aéronautique, le médicament, ne sont pas conçus puis rendus conformes ; ils sont conçus sous la contrainte de la conformité. L’objection est exacte pour les produits matériels et pour les processus industriels classiques. Elle ne tient pas pour les systèmes d’IA, et la raison de cette différence est précisément ce qui justifie un cadre dédié.
Dans un produit matériel, la spécification fonctionnelle préexiste à la rencontre avec le cadre normatif. Le cadre normatif vient en aval qualifier ce qui a été spécifié. Dans un système d’IA, la spécification fonctionnelle elle-même dépend des données disponibles, des seuils opérationnels, des conditions d’usage et des cadres normatifs qui qualifient l’usage. Il n’y a pas de spécification fonctionnelle d’un système d’IA avant sa rencontre avec le corpus normatif applicable, parce que le corpus normatif est constitutif de ce qui sera fonctionnellement défini comme acceptable. RAISE prend acte de cette circularité et propose une grammaire pour la traiter.
L’objection principale au statut épistémique du framework est l’absence d’ancrage empirique. RAISE construit son cadre par observation multi-sectorielle qualitative, par analyse comparative des cadres existants et par test par contrefactuels. Cette construction laisse ouverte la question : peut-on lire un cas publiquement documenté à travers la grille des cinq piliers, et la lecture rétrospective fait-elle apparaître les défaillances comme architecturales plutôt qu’opérationnelles ? Cette section propose une telle lecture, à valeur illustrative et non démonstrative.
Le cas retenu est l’affaire dite des allocations familiales néerlandaises (Toeslagenaffaire), conduite par l’administration fiscale néerlandaise (Belastingdienst) entre approximativement 2013 et 2019. Le système algorithmique mobilisé pour détecter les fraudes aux allocations de garde d’enfant a accusé à tort plusieurs dizaines de milliers de familles, avec un impact disproportionné sur les familles à double nationalité ou d’origine non-néerlandaise. La séquence est devenue politique : commission d’enquête parlementaire (POK), rapport final Ongekend onrecht en décembre 2020, démission du gouvernement Rutte III en janvier 2021, processus de réparation et de réforme institutionnelle en cours. L’autorité de protection des données néerlandaise (Autoriteit Persoonsgegevens) a confirmé en 2020 des violations de la réglementation européenne en matière de protection des données.
La lecture rétrospective par les cinq piliers fait apparaître les défaillances comme architecturales et non comme accidents opérationnels.
Pilier R, Regulatory Architecture. Le système a été conçu sans intégration active du corpus normatif applicable, notamment des principes anti-discrimination du droit européen et de la réglementation de protection des données mise en application en 2018. L’usage d’indicateurs corrélés à la nationalité ou à l’origine était documenté en interne sans qu’aucune lecture active ne le qualifie comme exposition juridique. Échec de pilier R par lecture déclarative.
Pilier A, Accountability and Governance. La chaîne de responsabilité du système était diffuse entre les services techniques de l’administration fiscale, sa hiérarchie administrative et la tutelle politique, sans qu’une personne nominalement identifiée ait simultanément le pouvoir et l’obligation d’altérer la décision automatisée à la lumière des signalements internes ou des plaintes externes documentées dès 2017. Échec de pilier A par responsabilité diffuse.
Pilier I, Interoperability Standards. Le partage de données entre administrations s’est produit sans contractualisation explicite des conditions de qualification des sources, ce qui a permis la propagation de classifications discutables d’un système à l’autre sans point de contestation effectif. Échec de pilier I par interopérabilité par export informel.
Pilier S, Safety and Operational Validation. La validation du système n’a pas été conduite sur une cohorte représentative neutre vis-à-vis des indicateurs corrélés à l’origine, et le monitoring opérationnel n’a pas détecté la dérive systémique malgré des signaux internes accumulés sur plusieurs années. Échec de pilier S par absence de validation contextuelle et par défaillance du monitoring.
Pilier E, Explainability and Ethics. Les familles concernées n’ont reçu aucune explication exploitable de la décision automatisée, et aucun mécanisme effectif de contestation n’était disponible avant le traitement judiciaire individuel. Échec de pilier E par absence de qualification des destinataires d’explication.
L’analyse rétrospective ne prouve pas que RAISE aurait empêché la défaillance. Elle énonce que les défaillances observées correspondent aux échecs canoniques diagnosticables par les cinq piliers, et qu’une architecture RAISE-aligned aurait, au minimum, rendu ces défaillances diagnostiquables avant l’incident plutôt qu’après. La différence entre diagnosticabilité ex ante et reconstitution ex post est la valeur architecturale que le framework prétend produire. Elle ne dispense pas d’une démonstration empirique stabilisée que la mise en œuvre de RAISE altère effectivement le taux ou la sévérité des défaillances ; elle fournit, à minima, un cas où la grille des cinq piliers rend les défaillances lisibles comme architecturales et non comme accidentelles. Le cas Toeslagenaffaire est ici proposé comme grille de lecture, non comme cas-test ; sa fonction est d’instancier la prétention diagnostique du framework sur un terrain publiquement documenté.
Un cadre dont on ne précise pas la nature finit confondu avec ce qu’il n’est pas. Cette section est courte, opératoire, et a fonction de balisage sémantique. Elle doit être citable telle quelle.
| RAISE est | RAISE n’est pas |
|---|---|
| Un cadre d’architecture, une grammaire pour structurer la conception d’un système d’IA | Un système de management de la qualité ou de l’IA |
| Un modèle d’analyse, un dispositif de cartographie des dépendances entre cinq dimensions architecturales | Un référentiel de certification |
| Un outil de décision de conception, un instrument mobilisé en amont de la spécification fonctionnelle | Une grille d’audit a posteriori |
| Un cadre européen-centré, conçu pour opérer au niveau où le législateur européen a choisi d’opérer | Une transposition d’un cadre américain ou international |
| Un cadre sectoriellement instanciable, éprouvé sur trois secteurs distincts via leur tension caractéristique | Un cadre générique applicable indifféremment à tout déploiement d’IA |
| Un cadre doctrinal, produit par un acteur unique, défendable par construction et critique de son propre périmètre de validité | Une norme adoptée collectivement par un organisme de normalisation |
Cette délimitation a une conséquence directe sur le statut épistémique du document. RAISE ne prétend pas à la légitimité collective d’une ISO ou d’un standard d’organisme intergouvernemental. Il prétend à la robustesse doctrinale d’un cadre conçu, défendu et critiqué par son auteur. Cette posture exige, en retour, une auto-critique explicite ; elle constitue le §10. Une doctrine qui n’énonce pas ses propres limites n’est pas une doctrine ; c’est une opinion.
Un dernier point de clarification est nécessaire avant la suite. RAISE est présenté ici comme un cadre d’architecture ; sa pratique observée le constitue, à un niveau supérieur, comme une doctrine de gouvernance par l’architecture. Cette tension interne mérite d’être nommée plutôt qu’esquivée. Un cadre est un instrument de conception ; une doctrine est un système de pensée structurant des décisions. RAISE est, opérationnellement, les deux à la fois : il fournit la grammaire de conception (cadre), et il porte une posture sur la manière dont la conception doit être instruite par la gouvernabilité (doctrine). Cette double nature est la source de sa puissance opératoire pour un CTO ou un COMEX ; elle est aussi ce qui le distingue d’un cadre purement technique, et ce qui justifie son inscription dans le corpus Twingital Institute comme objet doctrinal et non comme spécification opérationnelle.
Cinq niveaux d’opération de RAISE doivent être distingués pour éviter la confusion qui guette tout objet à la fois doctrinal et opératoire. Au niveau doctrinal, RAISE énonce une thèse sur la gouvernabilité par la conception (préambule, note méthodologique). Au niveau framework, il fournit la grammaire architecturale (cinq piliers, matrice cyclique typée, typologie ternaire des arêtes ; §4 et §5). Au niveau méthode diagnostique, il instrumente le diagnostic des déploiements (huit anti-patterns canoniques §6.2, quatre patterns de second ordre §6.6, faux positifs de maturité §6.5, tests d’intégration). Au niveau modèle de maturité, il décrit la trajectoire de mise en œuvre (quatre niveaux §7.1, régression contrôlée §7.3). Au niveau instrument CTO, il rend défendables les refus stratégiques (§6.4) et formule les transformations irréductibles T1 à T5 (note méthodologique). Ces cinq niveaux ne se chevauchent pas par accident ; ils sont l’expression doctrinale, conceptuelle, diagnostique, dynamique et opératoire d’un même objet d’architecture.
La présente section est centrale aux fondations argumentatives. Sans elle, la thèse-mère reste assertive. Elle se déroule en six temps. D’abord la carte d’orientation, un tableau comparatif synthétique qui situe RAISE par rapport aux cinq cadres existants pertinents. Puis le détail pilier-par-pilier de chacun de ces cadres. Enfin, le sous-paragraphe dédié à l’objection la plus robuste, celle du paysage saturé.
| Cadre | Périmètre | Nature | Finalité | Certifiable | Sectoriel | Opérationnel à lui seul | Capte ce que les autres ne captent pas |
|---|---|---|---|---|---|---|---|
| NIST AI RMF | Tous systèmes IA, U.S., volontaire | Cadre de gestion du risque | Identifier, mesurer, gérer le risque | Non | Non | Non | Cartographie risque non spécifique IA régulée |
| ISO/IEC 42001 | Tous systèmes IA, international | Système de management | Manager une organisation IA | Oui | Non | Non | Maturité organisationnelle de la fonction IA |
| EU AI Act (lu seul) | Tous systèmes IA mis sur le marché UE | Texte normatif | Énoncer les obligations | Sans objet (texte de loi) | Implicite (par classe de risque) | Non | Obligations légales applicables |
| Microsoft RAI Maturity Model | Organisations | Modèle de maturité organisationnelle | Évaluer la maturité d’une fonction IA | Non (auto-évaluation) | Non | Non | Maturité par dimension organisationnelle |
| HAS. Grille IA dispositifs médicaux | Dispositifs médicaux IA, France | Grille sectorielle | Qualifier un DM-IA | Non (note) | Oui (santé) | Non | Qualification sectorielle française |
| RAISE | Systèmes IA en environnement régulé | Cadre d’architecture | Concevoir un système gouvernable par construction | Non | Sectoriellement instanciable | Non ; il présuppose les cadres ci-dessus | Structure cyclique des dépendances de conception entre 5 piliers |
La lecture du tableau ligne à ligne révèle une asymétrie qu’aucun positionnement marketing ne peut masquer : aucun des cadres largement adoptés n’occupe explicitement la case RAISE. Ils gèrent un risque, certifient une organisation, énoncent des obligations, mesurent une maturité, ou notent un dispositif sectoriel. Aucun ne paraît fournir, dans une fonction principale et explicite, la grammaire architecturale qui permet de structurer la conception.
Cette différenciation appelle une nuance que la lecture rapide pourrait manquer. Les cadres existants ne sont pas indifférents à la conception ; ils la touchent par contrainte. La fonction map du NIST AI RMF, qui exige l’identification des contextes d’usage et des sources de risque, opère indirectement sur la conception en imposant des objets que celle-ci devra accommoder. ISO/IEC 42001, dans certaines de ses implémentations avancées, influence la conception via les exigences de contrôle interne et de gestion des changements. RAISE, lui, prétend structurer la conception par principe : sa grammaire opère en amont des contraintes, dans la grammaire elle-même qui rend les contraintes intelligibles. La différence n’est pas de degré, elle est d’ordre des opérations. Mais elle ne consiste pas à dire que les cadres existants ignorent la conception ; elle consiste à dire que leur contact avec la conception est dérivé de leur fonction principale, là où celui de RAISE est constitutif de sa fonction même. RAISE n’est donc pas un concurrent de ces cadres ; il est de nature distincte. Cette distinction n’est pas rhétorique : elle conditionne le mode d’usage. NIST RMF se mobilise pour décider quoi mesurer. ISO 42001 se mobilise pour structurer une organisation. RAISE se mobilise pour structurer un système. Ce ne sont pas les mêmes objets d’intervention.
NIST AI RMF est un cadre américain, volontaire, publié par le National Institute of Standards and Technology, dont la fonction est l’identification, la mesure et la gestion des risques liés au déploiement d’un système d’IA. Il est organisé autour de quatre fonctions (govern, map, measure, manage) qui structurent un cycle de gestion du risque. Sa principale qualité est la rigueur de la cartographie qu’il propose pour identifier les sources de risque ; sa principale limite, du point de vue d’un cadre d’architecture, est qu’il ne dit rien de la conception d’un système. Il dit comment gérer le risque d’un système qui existe. Il ne dit pas comment concevoir un système dont le risque soit gouvernable. La distinction n’est pas mince. Un cadre de gestion du risque présuppose un objet de risque préalable ; un cadre d’architecture en façonne la possibilité.
ISO/IEC 42001 est un système de management de l’IA, certifiable, qui s’inscrit dans la famille des standards de management (ISO 9001 pour la qualité, ISO 27001 pour la sécurité de l’information, ISO 13485 pour les dispositifs médicaux). Son intérêt est précisément ce qu’il revendique : il fournit le cadre de l’organisation qui gère la fonction IA, des rôles et des responsabilités à la mesure de la performance du système de management. Il ne fournit pas, et n’a pas l’intention de fournir, une grammaire de conception du système d’IA lui-même. Un déploiement RAISE-aligné dans une organisation certifiée ISO 42001 n’est pas une redondance ; c’est une articulation. Le système de management gère la fonction ; le cadre d’architecture façonne le système.
L’EU AI Act est un texte normatif, non opérationnel à lui seul. Il énonce des obligations (classification par classe de risque, exigences de documentation technique, supervision humaine, transparence, gestion du risque, qualité des données, robustesse) applicables aux systèmes mis sur le marché ou mis en service dans l’Union européenne. Lu seul, il ne dit pas comment ces obligations s’instancient dans la conception d’un système. Il appelle, par construction, des cadres opérationnels qui en traduisent les exigences en architectures. RAISE est l’un de ces cadres. Il n’est pas un concurrent de l’AI Act ; il est l’un des modes d’opérationnalisation possibles de ses exigences au niveau de la conception.
Le Responsible AI Maturity Model de Microsoft est un modèle de maturité organisationnelle. Il évalue, sur plusieurs dimensions (gouvernance, culture, processus, outillage, compétences), le niveau de maturité d’une organisation dans la pratique de l’IA responsable. La comparaison avec RAISE est asymétrique, et il faut le reconnaître explicitement : un modèle de maturité organisationnelle et un cadre d’architecture sont des objets de natures différentes. Le premier mesure une organisation ; le second structure un système. Si la comparaison est néanmoins pertinente ici, c’est parce que les deux cadres se rencontrent souvent dans les conversations de positionnement, et qu’il est nécessaire de marquer la non-substituabilité. RAISE n’est pas un MM ; un MM n’est pas un cadre d’architecture.
La Haute Autorité de Santé a publié, en France, une grille d’analyse des dispositifs médicaux à base d’IA, qui structure l’évaluation par la HAS des demandes de remboursement. La grille est sectorielle, française, et opère au niveau d’un dispositif spécifique. Elle est citée ici parce qu’elle illustre une catégorie générale : les grilles sectorielles nationales, qu’il s’agisse de l’EBA pour la finance européenne, de l’ANSSI pour les infrastructures critiques en France, ou de la FDA pour les dispositifs médicaux aux États-Unis. Aucune de ces grilles n’est un cadre d’architecture général. Toutes présupposent qu’un système existe et qu’il s’agit de le qualifier. RAISE opère un cran avant : au niveau de la conception qui rend le système qualifiable.
L’objection la plus robuste à RAISE n’est pas frontale. Elle est intégrative. Elle se formule ainsi :
Le paysage normatif est saturé. La combinaison de NIST AI RMF pour la gestion du risque, d’ISO/IEC 42001 pour le système de management, de l’EU AI Act pour les obligations, et des grilles sectorielles pour la qualification des dispositifs, couvre déjà toutes les dimensions que RAISE prétend couvrir. Ce qui est présenté comme un cadre nouveau relève en réalité d’une re-syntaxisation rhétorique d’éléments déjà disponibles. Au surplus, un cadre d’architecture conçu et défendu par un acteur unique ne peut prétendre à la légitimité doctrinale qu’exige un cadre de cette nature ; la légitimité, en matière d’architecture, est un fait collectif.
L’objection est sérieuse, et elle mérite une réponse en deux temps.
Premier temps. La couverture additionnée des cadres existants ne produit pas le cadre d’architecture qu’aucun d’eux n’est. La somme NIST + ISO 42001 + AI Act + sectoriels ne fournit pas une grammaire de conception ; elle fournit une superposition d’instruments hétérogènes, chacun opérant à un niveau distinct, dont l’articulation est laissée à la charge du concepteur. RAISE n’ajoute pas une couche ; il fournit la grille qui rend cette articulation pensable. La différence entre une superposition et une grille n’est pas une différence de quantité d’information ; c’est une différence de structure. Un architecte qui dispose des cinq cadres existants mais pas d’une grammaire qui en organise les dépendances est dans la situation d’un médecin qui dispose de cinq tests biologiques mais pas d’un cadre de diagnostic différentiel.
Second temps. La question de la légitimité d’un cadre produit par un acteur unique n’est pas une question close par appel à l’autorité collective. Elle est une question ouverte par la défendabilité du cadre. Un cadre légitime est un cadre qui énonce ses propres limites, traite ses propres objections, et accepte d’être falsifié par contre-exemples. Le présent document est construit selon cette discipline. §10 énonce cinq limites authentiques, le §6 expose huit anti-patterns qui sont autant de tests de la pertinence du framework, et la matrice §5 est falsifiable par démonstration que l’une de ses arêtes est nulle. La légitimité doctrinale est de cette nature : elle se construit par l’acceptation publique de la critique, pas par l’adoption silencieuse d’une instance de normalisation.
La distinction binaire centrale qui structure tout le document est la suivante : gouverner un système versus concevoir un système gouvernable. Les cadres existants gouvernent un système : ils en gèrent le risque, ils en certifient le management, ils en énoncent les obligations, ils en mesurent la maturité organisationnelle, ils en qualifient les versions sectorielles. RAISE conçoit le système gouvernable. Cette distinction n’est pas un raffinement terminologique. Elle décide de l’ordre des opérations. Un système conçu sans grammaire de gouvernabilité ne devient pas gouvernable par ajout de gouvernance. Il devient gouvernable, ou il ne le devient pas, à la conception.
La formule qui condense cet argument est la suivante :
Un cadre qui ne change pas la conception ne change que la documentation.
Cette formule, à laquelle ce document reviendra en §6 et en clôture, est la pierre de touche du test que tout déploiement RAISE-aligné devra réussir. Si la mise en œuvre du framework n’a altéré aucune décision de conception et seulement augmenté le volume documentaire, l’effort a échoué, peu importe la qualité de la documentation produite.
L’objection académique la plus immédiate à RAISE est l’argument de redondance ou d’incomplétude : pourquoi exactement cinq piliers, pourquoi des dépendances cycliques plutôt qu’orientées, pourquoi une typologie ternaire des arêtes plutôt que binaire ou quaternaire. Cette section répond aux trois questions par un argument de minimalité, présenté comme défendable plutôt que comme démonstratif.
Pourquoi cinq piliers, ni quatre ni six. Le test informel de minimalité consiste à supprimer chacun des piliers et à observer la lacune produite. Sans R, le système est dépourvu d’ancrage normatif, et la gouvernance devient un acte volontaire sans force opposable. Sans A, l’automatisation porte des décisions dont aucune personne nominalement identifiée ne répond, configuration inacceptable au sens du droit comme au sens de l’opérationnel. Sans I, les flux de données traversent le système sans contrat, et la traçabilité devient indistinguable de la trace événementielle. Sans S, la performance déclarée n’a aucune épreuve qui la qualifie comme fiable dans les conditions de déploiement. Sans E, les décisions automatisées sont opaques par défaut, et l’opacité ne peut pas être contestée par leurs destinataires. Aucun des quatre autres piliers ne comble la lacune ainsi produite, parce que les lacunes sont de natures différentes (norme, responsabilité, contractualisation, validation, justification). La minimalité par le bas est donc défendable.
Pour la minimalité par le haut, deux candidats à un sixième pilier ont été examinés. Le premier est la sécurité cyber au sens des cadres NIS2, IEC 62443 et ISO 27001 ; l’analyse §10.3 conclut qu’il s’agit d’un cadre orthogonal, à articuler avec RAISE plutôt qu’à intégrer comme pilier supplémentaire, parce que sa fonction est la protection contre une menace externe intentionnelle, là où les cinq piliers de RAISE traitent de la gouvernabilité interne des décisions automatisées. Le second est la performance économique au sens du coût marginal, du délai et de la scalabilité ; l’analyse §10.6 conclut qu’il s’agit d’une dimension d’arbitrage industriel et non d’une nature de gouvernabilité. Aucun des deux candidats ne satisfait simultanément le critère de non-réductibilité aux cinq piliers et le critère d’orientation gouvernabilité.
Pourquoi cyclique et non orienté. Une représentation par graphe acyclique dirigé (DAG) supposerait qu’un pilier précède causalement les autres, sans retour. Cette hypothèse est observable comme fausse sur deux exemples au moins. Premièrement, la pratique d’explicabilité (E) modifie progressivement la lecture du corpus normatif (R) à mesure que les zones grises de l’écriture législative sont révélées par l’usage ; cette boucle E vers R est documentée dans la jurisprudence européenne récente sur les décisions automatisées. Deuxièmement, l’interopérabilité contractualisée (I) et la validation opérationnelle (S) co-déterminent l’admissibilité des sources entrantes : sans I, S manque de matériau qualifié ; sans S, I manque de critère de qualification. Un DAG ne capture pas cette co-détermination ; il la réduit à une chaîne. La cyclicité n’est pas une élégance graphique ; c’est la conséquence de la pluralité des conditions de qualification.
Pourquoi une typologie ternaire des arêtes. Une typologie binaire (forte / faible, ou cause / effet) écraserait la distinction entre validité (le système satisfait les critères qui le qualifient) et légitimité (le système est opposable à un tiers qualifié). En environnement régulé, ces deux moments sont distincts : un système peut être techniquement valide sans être juridiquement opposable, et l’inverse n’est pas symétrique. Une typologie quaternaire incluant la performance économique introduirait une dimension qui n’est pas de la gouvernabilité au sens de RAISE, et brouillerait la fonction diagnostique du cadre. Une typologie quinaire ou plus tomberait dans la scolastique sans gain pour le diagnostic. La typologie ternaire correspond aux trois moments de contestation possibles d’un objet architectural, ni plus, ni moins.
Cet argument de minimalité est défendable, non démontré au sens formel. Sa réfutation exigerait soit l’exhibition d’un sixième pilier non absorbable par les cinq, soit la démonstration qu’une représentation acyclique préserve la couverture diagnostique, soit la production d’une typologie binaire ou quaternaire dont la fonction discriminative est démontrée supérieure. Aucune des trois n’est, dans la littérature publique consultée, disponible.
Une précision épistémique sur la nature des cinq piliers est nécessaire pour anticiper l’objection de réductibilité. Les cinq dimensions ne sont pas présentées comme ontologiquement irréductibles. Une analyse stricte fait apparaître des recouvrements partiels : A (responsabilité) est partiellement dérivable de R (obligations légales applicables) en environnement régulé ; E (explicabilité) est souvent une fonction de S (contraintes de validation contextuelle) et de R (exigences légales d’explication) ; I (interopérabilité) est fréquemment subordonnée à S (qualité contractualisée des sources entrantes). Cette réductibilité partielle est observable et doit être nommée plutôt qu’esquivée. Une réduction théorique à trois axes (contrainte normative, allocation de responsabilité, validité épistémique) reste logiquement possible.
Les cinq piliers sont donc défendus comme cadres d’analyse opérationnels distincts, non comme dimensions ontologiquement orthogonales. Leur valeur est diagnostique et architecturale, non logique. La confusion entre A et R, entre E et S, ou entre I et S, est précisément la pathologie typique des déploiements défaillants : c’est l’effet de la réductibilité informelle assumée comme fusion. Maintenir cinq piliers distincts est une décision opératoire dont le but est de préserver le pouvoir diagnostique du cadre. Une réduction à trois axes simplifierait la formalisation au prix de la lisibilité opérationnelle, et reproduirait la confusion que les cinq piliers ont précisément vocation à diagnostiquer. Cette défense en termes de lentilles opérationnelles, plutôt qu’en termes de dimensions orthogonales, est la formulation revendiquée.
Les cinq piliers de RAISE ne sont pas une liste d’attributs souhaitables. Ce sont les cinq dimensions architecturales sans lesquelles un système d’IA en environnement régulé n’est pas gouvernable au sens propre. Chacune est ici exposée selon un gabarit identique : définition opératoire, question fondatrice, objets architecturaux concernés, critères de présence et d’absence, confusions à éviter, renvois au corpus doctrinal Twingital. Chaque fiche se clôt par un encadré qui énonce la distinction binaire que le pilier rend opérationnelle. Cette distinction est la pierre de touche qui permet, sur un cas concret, de décider si le pilier est satisfait ou s’il ne l’est pas.
Une précision sur la lecture des cinq piliers s’impose avant de commencer. La présentation tabulaire pourrait suggérer une symétrie complète entre les cinq dimensions ; la pratique observée des déploiements montre une asymétrie de fait. R (lecture du corpus) et A (responsabilité nominée) tendent à structurer prioritairement la conception ; I, S et E s’instancient en grande partie en dérivation des deux premiers, du moins à l’initiation du déploiement. Cette asymétrie n’est pas une faille du cadre ; elle est une régularité empirique observable et qu’il faut nommer. La matrice du chapitre 5, qui établit des dépendances cycliques entre les cinq piliers, n’invalide pas cette asymétrie ; elle la complexifie en introduisant les boucles de retour qui empêchent que R et A puissent être instruits sans considération des trois autres. La hiérarchie de fait existe donc à l’initiation du déploiement ; elle ne persiste pas structurellement à régime de maturité.
Définition opératoire. Capacité du système à intégrer les exigences du corpus normatif applicable comme contraintes de définition, en amont de la spécification fonctionnelle, plutôt que comme tests de validation en aval.
Question fondatrice. Quelles règles s’appliquent à ce système, et comment leur lecture conditionne-t-elle la grammaire de sa conception ?
Objets architecturaux concernés. Modèle de classification réglementaire du système (par classe de risque AI Act, par classe de DM, par catégorie de service financier) ; registre des exigences applicables avec versioning ; mapping exigences vers composants ; processus de veille normative ; protocole de revue d’architecture déclenché par évolution du corpus.
Critères de présence. Le système est conçu en référence à un corpus normatif identifié, daté, tenu à jour. Chaque composant est qualifié quant aux exigences qu’il supporte. Une modification du corpus déclenche une revue d’architecture, pas seulement une mise à jour documentaire.
Critères d’absence. La conformité est documentée a posteriori. Le corpus normatif est figé au moment du go-live. La modification d’une exigence est traitée comme un changement opérationnel sans revue de conception. La classification de risque est apposée plutôt que dérivée.
Confusions à éviter. Confondre conformité ponctuelle (réussir un audit) et conformabilité structurelle (être conçu pour rester conforme aux évolutions). Confondre lecture déclarative (le texte dit X, je note X dans un registre) et lecture active (le texte dit X, je dérive ce que X contraint pour la conception, en distinguant ce qui est tranché et ce qui est laissé à l’arbitrage du concepteur).
Renvois doctrinaux. [Renvoi Twingital, Collision ontologique MDR/AI Act, à formaliser]. [Renvoi Twingital, Apprendre ce qui ne peut pas varier, à formaliser].
Le pilier R est le plus fréquemment réduit à une fonction documentaire. Cette réduction est l’erreur dont tout le reste découle. Un texte normatif n’énonce jamais simplement une obligation ; il définit l’espace dans lequel les choix de conception sont possibles, et il qualifie certaines combinaisons comme inacceptables. La lecture active du corpus consiste à dériver, exigence par exigence, l’ensemble des contraintes qui pèsent sur les degrés de liberté du concepteur. La lecture déclarative se contente de noter que l’obligation existe. La première produit une architecture ; la seconde produit un dossier.
Ce que R coupe : lecture active versus lecture déclarative des textes.
Définition opératoire. Capacité du système à porter, à chaque point de décision automatisée ou semi-automatisée, une chaîne de responsabilité nommée, opposable, et capable d’altérer la décision de conception avant qu’elle ne soit figée.
Question fondatrice. Pour chaque décision que le système prend ou supporte, qui est responsable, sur quel fondement, et avec quelle capacité d’intervention ?
Objets architecturaux concernés. Cartographie des décisions automatisées et semi-automatisées ; matrice RACI étendue aux objets de conception (modèle, données, seuils, interfaces) ; chaîne d’escalade documentée ; mécanismes de supervision humaine dotés de pouvoirs effectifs ; registre des arbitrages avec traçabilité des arbitres.
Critères de présence. Pour chaque décision automatisée, une personne nominée est identifiable, joignable, et disposée à porter la décision en cas d’incident. La supervision humaine, lorsqu’elle est prévue, dispose des informations, du temps et de l’autorité pour altérer effectivement la décision automatisée. Les arbitrages techniques sont tracés avec leurs auteurs.
Critères d’absence. La responsabilité est diffuse, distribuée entre comités, ou portée par une fonction abstraite. La supervision humaine est documentée mais pratiquement impossible à exercer dans les conditions opérationnelles réelles (cadence trop élevée, information insuffisante, autorité inexistante). Les arbitrages techniques sont tracés sans leurs auteurs.
Confusions à éviter. Confondre responsabilité juridique (qui répond en cas de dommage) et responsabilité opérationnelle de conception (qui décide des objets architecturaux). Confondre supervision humaine effective et supervision humaine fictive (l’humain est dans la boucle au sens où son nom apparaît dans le diagramme, mais il ne dispose ni du temps, ni de l’information, ni de l’autorité pour altérer la décision).
Renvois doctrinaux. [Renvoi Twingital, Architecture hexagonale comme condition de gouvernabilité, à formaliser].
Le pilier A est celui où le théâtre est le plus aisé. Un comité IA, un règlement intérieur, une matrice RACI, un dispositif de supervision humaine peuvent être tous présents sans qu’aucune décision opérationnelle ne soit altérable. La distinction entre une responsabilité nominée et une responsabilité diffuse tranche cette ambiguïté. Une responsabilité nominée a un nom, un mandat, des pouvoirs, et accepte d’être engagée. Une responsabilité diffuse a une organisation, une charte, des procédures, et n’est engagée par personne en particulier.
Ce que A coupe : responsabilité nominée versus responsabilité diffuse.
Définition opératoire. Capacité du système à exposer, ingérer et faire circuler des données et des signaux selon des contrats explicites, versionnés, opposables, plutôt que selon des conventions tacites ou des formats d’export ad hoc.
Question fondatrice. Comment les flux de données et de signaux qui traversent le système sont-ils contractualisés vis-à-vis de leur producteur, de leur consommateur, et du régulateur ?
Objets architecturaux concernés. Standards d’interopérabilité applicables (FHIR R5, ESEF, XBRL, STANAG, IEC 62443) ; ports d’admission et ports de promotion contractualisés ; schémas de données versionnés ; mécanismes de qualification des sources entrantes ; politiques de filtrage et de transformation ; registre des contrats d’interface.
Critères de présence. Chaque interface du système est régie par un contrat explicite qui spécifie schéma, sémantique, garanties de qualité, et conditions de rupture. Les changements de schéma sont versionnés et négociés. Les sources entrantes sont qualifiées avant ingestion.
Critères d’absence. L’interopérabilité est obtenue par export en formats génériques (CSV, JSON non typé, PDF) sans contrat sémantique. Les changements de schéma sont propagés sans versioning ni négociation. Les sources entrantes sont ingérées sans qualification, au prétexte que le pipeline aval saura les redresser.
Confusions à éviter. Confondre interopérabilité par contrat (le format et la sémantique sont garantis par un standard opposable) et interopérabilité par export (les données peuvent être transmises, à charge pour le destinataire de les interpréter). La première est un objet d’architecture ; la seconde est un constat technique.
Renvois doctrinaux. [Renvoi Twingital, Contractualised promotion port, à formaliser].
Le pilier I est sous-estimé parce qu’il paraît trivialement résolu : tout système peut, à la rigueur, exporter ses données. Mais l’interopérabilité au sens architectural n’est pas la possibilité de transmettre ; c’est la possibilité de transmettre sous des conditions opposables. Un système qui exporte en CSV est interopérable au sens où ses données sortent ; il n’est pas interopérable au sens où la sémantique des données qui sortent reste à la charge de qui les reçoit. La différence n’est pas une finesse de standardisation : elle décide de la traçabilité, de l’auditabilité, et de la capacité du régulateur à reconstituer une décision après coup.
Ce que I coupe : interopérabilité par contrat versus interopérabilité par export.
Définition opératoire. Capacité du système à être validé non sur la seule performance mesurée sur un jeu de données de référence, mais sur sa fiabilité dans les conditions opérationnelles réelles, sous les contraintes spécifiques de son environnement de déploiement.
Question fondatrice. Sur quelle population, dans quelles conditions, et selon quel protocole le système a-t-il été validé, et ces conditions correspondent-elles à celles de son usage prévu ?
Objets architecturaux concernés. Protocoles de validation contextuelle ; cohortes de validation distinctes des cohortes d’entraînement ; protocoles de stress testing et de robustness testing ; mécanismes de monitoring opérationnel ; seuils d’alerte sur dérive ; processus de revalidation périodique.
Critères de présence. La validation est conduite sur une population représentative des conditions de déploiement, avec un protocole pré-spécifié. Les conditions opérationnelles font l’objet d’un monitoring qui détecte la dérive avant qu’elle n’altère la performance. Une revalidation est déclenchée par les conditions, pas seulement par le calendrier.
Critères d’absence. La validation se résume à la performance sur un benchmark public ou sur un jeu de données interne sans contrôle de représentativité. Le monitoring opérationnel mesure la disponibilité et le débit, pas la dérive de performance. La revalidation est calendaire, déclenchée par l’échéance plutôt que par le signal.
Confusions à éviter. Confondre performance sur benchmark (mesure de capacité dans un cadre expérimental) et validation contextuelle (mesure de fiabilité dans le cadre d’usage). La première peut être excellente sans que la seconde le soit ; l’inverse n’est pas symétrique. Confondre robustesse adversariale (résistance à des perturbations conçues pour tromper le modèle) et robustesse écologique (stabilité de la performance sous les variations naturelles de la population de déploiement).
Renvois doctrinaux. [Renvoi Twingital, Les benchmarks publics ont perdu le droit de décider seuls, à formaliser].
Le pilier S est celui dont la mesure est la plus piégeuse. Un AUC de 0,93 sur un jeu de données de référence est, en soi, une information ; mais une information qui ne dit rien de la fiabilité du système dans les conditions de son usage, sauf à présupposer que les conditions de validation et de déploiement coïncident. Cette présupposition est presque toujours fausse, et son traitement est l’objet propre du pilier S.
Ce que S coupe : performance sur benchmark versus validation contextuelle.
Définition opératoire. Capacité du système à produire, pour chaque décision automatisée, une explication qui soit utile à la personne concernée, défendable devant un tiers qualifié, et conçue comme objet architectural plutôt qu’ajoutée a posteriori comme couche d’interprétation.
Question fondatrice. Pour chaque décision que le système produit, qui est destinataire de l’explication, dans quel but, et selon quel protocole l’explication est-elle générée et validée ?
Objets architecturaux concernés. Typologie des destinataires d’explication (personne concernée, professionnel, régulateur, tribunal) ; modèles d’explication adaptés à chaque destinataire ; protocoles de génération d’explication intégrés à la conception du modèle, pas surimposés ; cadres éthiques applicables et processus de leur invocation ; registres de décisions explicables avec horodatage.
Critères de présence. L’explicabilité est définie par le destinataire et l’usage de l’explication, pas par la disponibilité d’un outil technique générique. La conception du modèle prend en compte les exigences d’explicabilité comme contraintes en amont. Les divergences entre explication produite et décision effective sont détectables et tracées.
Critères d’absence. L’explicabilité est assimilée à l’installation d’un outil de type SHAP ou LIME sans qualification du destinataire ni du cadre d’usage. Les explications sont produites en aval de la décision, sans garantie de cohérence avec le processus interne du modèle. Aucun mécanisme ne distingue une explication décisionnelle (qui justifie la décision) d’une interprétation technique (qui décrit le fonctionnement du modèle).
Confusions à éviter. Confondre explicabilité décisionnelle (production d’une justification que le destinataire peut contester) et interprétabilité technique (production d’une description du fonctionnement du modèle). Les deux sont utiles ; aucune n’est l’autre. Confondre explication a posteriori (générée après la décision, par un dispositif distinct du modèle) et justification de conception (intégrée à la décision elle-même).
Renvois doctrinaux. [Renvoi Twingital, Bayésien et crédibilité réglementaire, à formaliser]. [Renvoi Twingital, Apprendre ce qui ne peut pas varier, à formaliser].
Le pilier E est celui où la confusion entre objet et outil est la plus dommageable. Disposer d’un outil d’interprétation technique ne rend pas le système explicable au sens architectural ; cela permet seulement de produire, pour chaque décision, un objet supplémentaire dont la pertinence pour le destinataire est, dans le meilleur des cas, contingente. L’explicabilité comme pilier architectural exige que le destinataire, son cadre d’usage et le protocole de production soient spécifiés avant la conception du modèle, et que la conception en porte la trace.
Une difficulté technique subsiste sous ce pilier, qu’il faut nommer plutôt qu’esquiver. Certaines décisions automatisées utiles ne sont pas explicables de manière stable sans perte significative de performance. Cette zone, propre aux modèles complexes (réseaux profonds, ensembles, modèles non-paramétriques avancés) opérant sur des espaces à grande dimension, n’est pas résolue par le pilier E ; elle est contenue. RAISE traite cette tension en architecture, en exigeant que la décision de privilégier la performance sur l’explicabilité soit elle-même nominalement portée par une responsabilité (pilier A), validée contextuellement (pilier S), et opposable au régulateur (pilier R). C’est une résolution architecturale, pas technique. Sa portée est conditionnelle : le pilier E est normativement fort, opérationnellement contraint.
Ce que E coupe : explicabilité décisionnelle versus interprétabilité technique.
Les cinq piliers ne s’additionnent pas, ils s’engendrent. Cette section démontre cette assertion en la rendant explicite, paire par paire. La structure habituelle de présentation, qui aligne R, A, I, S, E sur une chaîne linéaire (« d’abord la lecture des textes, puis la gouvernance, puis l’interopérabilité… »), est commode pour l’exposition mais fausse pour l’analyse. Aucun des piliers ne précède causalement les autres ; chacun conditionne, de manière différente, les quatre autres ; chacun est conditionné, de manière différente, par les quatre autres.
La représentation graphique de cette section, dans la mise en page finale, est une figure pentagonale avec les cinq piliers en sommets et les arêtes entre piliers typées par nature de la dépendance. Trois natures sont distinguées :
Condition de possibilité. X est condition de possibilité de Y si, en l’absence de X, Y ne peut pas exister comme objet architectural distinct, indépendamment de toute considération de qualité.
Condition de validité. X est condition de validité de Y si, en l’absence de X, ce qui est produit comme Y est nominalement présent mais ne satisfait pas les critères qui le qualifient comme tel.
Condition de légitimité. X est condition de légitimité de Y si, en l’absence de X, Y existe et fonctionne, mais ne peut être opposé à un tiers qualifié (régulateur, tribunal, personne concernée) comme objet de référence.
Pourquoi trois natures et pas cinq ou deux ? Parce que ces trois natures correspondent aux trois moments où un objet architectural peut être contesté : son existence, sa qualité, son opposabilité. Une typologie à deux natures écrase la distinction entre qualité et opposabilité, qui sont distinctes en environnement régulé : un système peut être techniquement valide sans être juridiquement opposable, et l’inverse n’est pas symétrique. Une typologie à cinq ou plus introduit des sous-catégories qui ne tiennent pas à l’usage. La typologie ternaire est minimale et suffisante. C’est, on le concède, une décision doctrinale qui pourrait être discutée. La discussion porte alors sur des cas d’arête, pas sur la pertinence de la typologie elle-même.
| R | A | I | S | E | |
|---|---|---|---|---|---|
| R | identité | conditionne | informe | délimite | légitime |
| A | requiert | identité | mobilise | encadre | impose |
| I | rend lisible | conditionne | identité | rend possible | rend traçable |
| S | présuppose | rend testable | présuppose | identité | rend défendable |
| E | reformule | rend auditable | exige | rend justifiable | identité |
La lecture du tableau se fait par ligne : R conditionne A, R informe I, R délimite S, R légitime E ; et symétriquement par colonne pour les retours. Les dix paires non-identité sont développées ci-dessous, chacune en une phrase de qualification qui explicite la double dépendance dans les deux sens.
R conditionne A en ce sens que la lecture active du corpus normatif détermine quelles décisions doivent être nommément portées, par qui, et sous quel régime de responsabilité ; sans cette lecture, la matrice de responsabilité est construite sur des intuitions plutôt que sur des obligations dérivées. Symétriquement, A requiert R en ce sens qu’une chaîne de responsabilité nommée n’est opérationnellement opposable que si elle a été instruite par une lecture du corpus normatif applicable ; un responsable nommé sans corpus de référence est nommé pour porter une décision dont les contours juridiques sont indéterminés, ce qui est précisément ce que la nomination devait éviter. La dépendance R vers A est de nature condition de possibilité (sans lecture active, la chaîne de responsabilité n’a pas d’objet) ; la dépendance A vers R est de nature condition de validité (sans responsabilité nommée, la lecture active reste un exercice intellectuel sans force opposable). Test diagnostic. Peut-on dériver, depuis les exigences du corpus normatif applicable, la liste nominale des décisions qui doivent porter une responsabilité ? Si non, R sur A est compromis.
R informe I en ce sens que le corpus normatif applicable spécifie, explicitement ou implicitement, les standards d’interopérabilité que le système doit respecter (FHIR pour la santé sous la directive européenne sur l’espace européen des données de santé, ESEF pour le reporting financier sous la directive Transparence, STANAG pour les systèmes OTAN). Symétriquement, I rend lisible R en ce sens que les contrats d’interface effectivement implémentés dans le système constituent la trace observable de la lecture du corpus, par laquelle un tiers peut vérifier qu’un standard exigé est effectivement intégré et non simplement mentionné. La dépendance R vers I est de nature condition de validité (le standard exigé par le corpus est ce qui qualifie l’interopérabilité comme conforme) ; la dépendance I vers R est de nature condition de légitimité (l’implémentation observable du standard est ce qui rend la conformité opposable). Test diagnostic. Les standards d’interopérabilité requis par le corpus sont-ils effectivement implémentés et observables dans les contrats d’interface du système ? Si non, R sur I est compromis.
R délimite S en ce sens que le corpus normatif spécifie le périmètre dans lequel la validation opérationnelle est conduite (population éligible, conditions d’usage, modalités de surveillance post-commercialisation pour les dispositifs médicaux, conditions de stress testing pour les modèles de risque financier sous Bâle III). Symétriquement, S présuppose R en ce sens qu’aucun protocole de validation contextuelle ne peut être conçu sans un cadre normatif qui qualifie ce qui compte comme représentatif et ce qui constitue un échantillon valide. La dépendance R vers S est de nature condition de validité (le cadre normatif qualifie la validation comme acceptable) ; la dépendance S vers R est de nature condition de possibilité (sans cadre, la validation manque d’objet). Test diagnostic. Le protocole de validation est-il instruit par le corpus normatif applicable, avec qualification de la représentativité de la cohorte au sens de ce corpus ? Si non, R sur S est compromis.
R légitime E en ce sens que le corpus normatif spécifie qui est destinataire d’une explication (article 86 AI Act pour la personne concernée par une décision à haut risque, article 22 du RGPD pour la décision automatisée individuelle, article 17 de la MDR pour le professionnel de santé), avec quelle granularité, et selon quel protocole. Symétriquement, E reformule R en ce sens que la pratique d’explicabilité produite par le système, en circulant auprès de ses destinataires effectifs, oblige à une relecture du corpus pour préciser ce qui était laissé indéterminé dans l’écriture initiale. La dépendance R vers E est de nature condition de légitimité (le corpus rend l’explication opposable) ; la dépendance E vers R est une boucle de retour qui modifie progressivement l’interprétation du corpus à mesure que les pratiques d’explication révèlent les zones grises de l’écriture législative. Test diagnostic. Les destinataires d’explication sont-ils qualifiés par le corpus normatif applicable, et le protocole d’explication respecte-t-il leur cadre d’usage ? Si non, R sur E est compromis.
A mobilise I en ce sens que la chaîne de responsabilité ne peut être exercée que si les flux de données et de signaux qui supportent les décisions sont contractualisés et tracés ; un responsable nommé qui ne dispose pas d’une trace fiable des données ayant supporté la décision n’est pas en position de porter cette décision. Symétriquement, I conditionne A en ce sens que les contrats d’interface définissent les points de bascule où une décision est prise, et donc les points où une responsabilité doit être nommée. La dépendance A vers I est de nature condition de validité (sans I, les nominations de responsabilité sont nominales) ; la dépendance I vers A est de nature condition de possibilité (sans I, les points de responsabilité sont indéterminés). Test diagnostic. Les flux qui supportent les décisions sont-ils tracés au niveau qui permet la reconstruction par le responsable nommé ? Si non, A sur I est compromis.
A encadre S en ce sens que la responsabilité nommée porte la décision de qualifier une validation comme suffisante ou insuffisante ; sans nomination, la décision de validation est diffuse, et son caractère contestable est, en pratique, neutralisé. Symétriquement, S rend testable A en ce sens que les critères de validation opérationnelle constituent les épreuves auxquelles la chaîne de responsabilité accepte d’être soumise ; un responsable nommé qui refuse les épreuves de validation n’est pas un responsable au sens architectural. La dépendance A vers S est de nature condition de légitimité (sans nomination, la validation n’engage personne) ; la dépendance S vers A est de nature condition de validité (sans S, la nomination de responsabilité est cérémonielle). Test diagnostic. La chaîne de responsabilité accepte-t-elle les épreuves de validation comme tests opposables, et les responsables nommés sont-ils engagés sur ces épreuves ? Si non, A sur S est compromis.
A impose E en ce sens que la responsabilité nommée appelle l’explicabilité comme condition d’exercice : un responsable qui ne peut produire l’explication d’une décision n’est pas en position de la défendre. Symétriquement, E rend auditable A en ce sens que la pratique d’explicabilité, lorsqu’elle existe au sens architectural, fournit la trace par laquelle un tiers qualifié peut reconstituer l’exercice de la responsabilité et en évaluer la pertinence. La dépendance A vers E est de nature condition de validité (la responsabilité non explicable n’est pas exerçable) ; la dépendance E vers A est de nature condition de légitimité (sans explicabilité, la responsabilité n’est pas opposable). Test diagnostic. Chaque responsable nommé peut-il produire l’explication d’une décision pour laquelle il s’engage, et cette explication est-elle défendable devant un tiers qualifié ? Si non, A sur E est compromis.
I rend possible S en ce sens que les protocoles de validation contextuelle exigent des flux de données qualifiés, contractualisés, et traçables, sans lesquels la mesure de performance opérationnelle est non interprétable. Symétriquement, S présuppose I en ce sens qu’aucune mesure de dérive ne peut être conduite sur des sources entrantes non qualifiées ; la mesure ne distingue alors pas la dérive du système de la dérive de ses entrées. La dépendance I vers S est de nature condition de possibilité (la validation sans contrats d’interface n’a pas de matériau) ; la dépendance S vers I est de nature condition de validité (les contrats d’interface sans validation ne garantissent pas la fiabilité opérationnelle). Test diagnostic. Les sources entrantes sont-elles qualifiées au point de permettre la mesure de dérive sans confusion entre dérive du système et dérive des entrées ? Si non, I sur S est compromis.
I rend traçable E en ce sens que la production d’une explication décisionnelle exige, pour être défendable, l’accès aux signaux et aux données qui ont supporté la décision, et donc à des flux contractualisés. Symétriquement, E exige I en ce sens que la spécification des protocoles d’explicabilité contraint la spécification des contrats d’interface : l’explicabilité décisionnelle exige certaines informations dans le format où elles peuvent être mobilisées, ce qui rétroagit sur les contrats d’admission et de promotion du système. La dépendance I vers E est de nature condition de possibilité (sans I, l’explication ne peut pas être instruite) ; la dépendance E vers I est de nature condition de validité (sans E, les contrats d’interface ne sont pas calibrés sur le bon usage informationnel). Test diagnostic. Les flux contractualisés portent-ils l’information nécessaire à l’explicabilité décisionnelle au format où elle est mobilisable par le destinataire qualifié ? Si non, I sur E est compromis.
S rend défendable E en ce sens que la validation opérationnelle fournit la base empirique sur laquelle l’explication décisionnelle peut s’appuyer pour être tenue comme crédible ; une explication qui n’est pas adossée à une validation contextuelle est une rationalisation. Symétriquement, E rend justifiable S en ce sens que la pratique d’explicabilité explicite ce que la validation opérationnelle a mesuré et ce qu’elle n’a pas mesuré, et permet ainsi d’instruire le périmètre de fiabilité du système plutôt que de le présupposer. La dépendance S vers E est de nature condition de validité (sans validation, l’explication est non fondée) ; la dépendance E vers S est de nature condition de légitimité (sans explicabilité, la validation n’est pas opposable au-delà de l’expert technique). Test diagnostic. Les explications produites sont-elles adossées à la validation contextuelle, et la validation est-elle traduite en termes utilisables par les destinataires non-experts ? Si non, S sur E est compromis.
La matrice 5×5 présente trois objections que la lecture rapide pourrait formuler. Elles sont anticipées ici, sans répétition.
Plausibilité, non démonstration. La matrice est un modèle plausible, non un modèle contraint. Trois questions académiques restent ouvertes : pourquoi cinq piliers et non quatre ou six, pourquoi ces dépendances et non d’autres, pourquoi cette typologie ternaire et non binaire ou quaternaire. La réponse complète à ces questions est l’objet du §3.8 (argument de minimalité) et du §5.5 (démonstration partielle de nécessité des arêtes). La matrice énonce une régularité doctrinale défendable, falsifiable par contre-exemple architectural, non une démonstration formelle au sens mathématique.
Asymétrie d’intensité. La matrice ne prétend pas que toutes les paires aient la même intensité. Certaines dépendances sont structurellement déterminantes (R sur l’ensemble des autres, A sur S et E) ; d’autres sont opérationnellement plus faibles (I sur E hors contexte d’audit). L’énoncé que toutes les arêtes sont non-nulles n’implique pas qu’elles soient équivalentes. L’asymétrie observée est instruite en §4 (note sur l’asymétrie de fait des piliers à l’initiation du déploiement).
Exclusion explicite de la dimension économique. La typologie ternaire (possibilité, validité, légitimité) exclut volontairement la dimension efficacité opérationnelle, coût, scalabilité. Cette exclusion est méthodologique : la performance économique structure l’arbitrage industriel mais ne qualifie pas la gouvernabilité au sens où la matrice l’instruit. Elle est traitée séparément en §10.6 et §10.7. Cette séparation est cohérente avec la délimitation §2 du cadre comme architecture, et reconnue comme stratégiquement exposée à la critique COMEX, qui la réintroduira spontanément dans tout arbitrage de portefeuille.
La matrice n’est donc pas une démonstration formelle ; c’est un cadre d’analyse qui rend visibles, sur n’importe quel cas concret, les zones où la conception est sous-contrainte ou sur-contrainte. Sa valeur ne se mesure pas à sa rigueur logique mais à son utilité diagnostique.
L’assertion que toutes les arêtes de la matrice sont non-nulles est forte. Elle ne sera pas démontrée en bloc, parce qu’une démonstration formelle exigerait un cadre logique que cette section ne mobilise pas. Trois arêtes critiques sont en revanche défendues ici par argument de collapsus : on suppose l’arête nulle, on dérive la conséquence, et on observe la contradiction ou la perte de fonction.
Arête R conditionne A. Supposons que R ne conditionne pas A. Alors la chaîne de responsabilité peut être conçue indépendamment de la lecture du corpus normatif applicable. Conséquence : un responsable nommé porte une décision dont les contours juridiques sont indéterminés, parce que la nomination n’a pas été instruite par les obligations effectivement applicables. Cette configuration est précisément celle de l’anti-pattern §6.2.3 gouvernance déclarative. La nomination existe, mais sans force opposable. Le pilier A est nominalement satisfait, opérationnellement vide. L’arête R conditionne A est donc nécessaire à la non-vacuité du pilier A.
Arête A encadre S. Supposons que A n’encadre pas S. Alors le protocole de validation contextuelle peut être conçu et conduit sans qu’une responsabilité nommée porte la décision de qualifier la validation comme suffisante. Conséquence : les critères de validation sont diffus, contestables mais non contestables par quelqu’un en particulier. La validation devient cérémonielle, satisfait l’audit standard, et n’engage personne. Cette configuration est l’anti-pattern §6.2.6 audit comme cérémonie projeté sur le pilier S. Sans A vers S, la validation n’a pas de porteur ; sans porteur, elle n’a pas de force. L’arête A encadre S est donc nécessaire à la non-vacuité du pilier S.
Arête E reformule R. Supposons que E ne reformule pas R. Alors la pratique d’explicabilité, une fois en production, n’a aucun retour sur la lecture du corpus normatif. La lecture initiale du corpus est figée au moment de la conception. Conséquence : le corpus normatif évolue (publications d’actes délégués, décisions de l’AI Office, jurisprudence administrative), mais l’architecture n’absorbe pas cette évolution. Le système se met en dérive normative sans s’en apercevoir, jusqu’au moment où une autorité de tutelle requalifie une obligation et produit la régression de niveau au sens de §7.3. L’arête E reformule R est donc nécessaire à la stabilité dans le temps de l’alignement R.
Trois arêtes sur dix paires sont ainsi défendues. Les sept autres acceptent un argument de même nature, omis ici par discipline de longueur. La défendabilité partielle ne suffit pas à constituer une démonstration formelle ; elle suffit à constituer une revendication de plausibilité robuste, qui exigerait pour être réfutée un argument de non-collapsus comparable.
L’argument de plausibilité prend une forme plus concrète si on l’instancie sur des cas comparés. Deux counterfactuels sont proposés ci-dessous, chacun confrontant un système A non-RAISE-aligned et un système B RAISE-aligned, sous une perturbation identique. La prétention de RAISE est que la différence de comportement sous perturbation est attribuable à une caractéristique architecturale spécifique, identifiable dans les piliers et dans la matrice.
Counterfactuel 1. Système d’aide à la décision clinique en oncologie sous évolution de la jurisprudence article 86 AI Act.
Système A est conçu en optimisant la performance prédictive sur cohorte rétrospective ; la conformité AI Act est instruite a posteriori par documentation ; l’explicabilité est ajoutée par installation de SHAP ; l’évaluation clinique MDR est conduite sur la cohorte du benchmark. Système B est conçu sous lecture croisée AI Act × MDR (pilier R), avec destinataire de l’explication qualifié dès la conception (pilier E, contractualisé sur trois niveaux : patient, oncologue, autorité de tutelle), avec validation prospective sur cohorte territoriale qualifiée (pilier S), avec responsabilité nominée au niveau du fabricant et du chef de service (pilier A), et avec contrats d’interface FHIR R5 versionnés sur les sources de données (pilier I).
Perturbation : une décision de la Cour de justice de l’Union européenne précise, par jurisprudence, que l’explication exigée par l’article 86 doit comporter une trace de raisonnement compréhensible par le clinicien, et non seulement une attribution de poids par feature.
Comportement de Système A : l’installation SHAP ne satisfait pas la nouvelle exigence ; le système doit refondre sa couche d’explication, ce qui implique une nouvelle évaluation clinique et un re-marquage. L’exposition contractuelle vis-à-vis de l’organisme notifié et des praticiens utilisateurs est significative pendant la transition. Comportement de Système B : la qualification du destinataire et la chaîne de production différenciée sont déjà en place ; la nouvelle exigence est instruite par la boucle E vers R, qui requalifie l’attendu pour l’oncologue comme destinataire qualifié, sans reconception structurelle. La régression de niveau §7.3 est exercée mais reste contenue.
Le delta est attribuable au pilier E (qualification ex ante du destinataire) et à l’arête E reformule R (boucle d’absorption de la jurisprudence). Sans ces deux éléments, le système A subit la perturbation comme refonte ; le système B la traite comme requalification.
Counterfactuel 2. Modèle de scoring de crédit individuel sous demande régulatoire de détection de dérive en temps réel.
Système A est conçu sur secret commercial, avec explication dégradée fournie au demandeur sur la base de l’article 22 RGPD ; le modèle est protégé contre toute désanonymisation. Système B est conçu sur la Tension d’opacité concurrentielle nommée en §8.2 : explicabilité différenciée par destinataire (régulateur, demandeur, tribunal), avec chaînes de désanonymisation contrôlées par procédure (pilier E + I), validation contextuelle par cohorte de stress testing distincte du training (pilier S), responsabilité nommée au CRO et à la direction effective (pilier A).
Perturbation : l’autorité de tutelle (EBA ou autorité nationale) demande la mise en place d’un mécanisme de détection en temps réel de la dérive de la décision automatisée par catégorie de demandeur, sous DORA et sous l’article 22 considérant 71 du RGPD.
Comportement de Système A : la demande ne peut être satisfaite sans exposer la logique du modèle, qui est précisément ce que le secret commercial protège. Le système est en impasse architecturale ; le compromis observé en pratique est la production d’un dashboard interne non communicable, qui satisfait la lettre de la demande sans satisfaire son esprit, et qui expose l’établissement à la contestation ultérieure. Comportement de Système B : la chaîne d’explicabilité différenciée par destinataire est conçue pour intégrer le régulateur comme destinataire qualifié avec accès à la dérive sans accès à la logique interne ; le mécanisme demandé est instruit par contractualisation de l’interface (pilier I) sur le canal régulateur, sans modification du modèle ni exposition concurrentielle.
Le delta est attribuable à la combinaison E (différenciation des destinataires) et I (contrats d’interface différenciés par canal), avec retour sur A (la responsabilité du CRO porte la procédure de désanonymisation). Sans cette combinaison, l’établissement A subit la perturbation comme contradiction architecturale ; l’établissement B la traite comme mobilisation d’une chaîne préexistante.
Ces deux counterfactuels sont des constructions doctrinales, non des observations empiriques publiques. Leur fonction est d’illustrer la prétention de RAISE comme cadre architectural produisant une asymétrie de comportement sous perturbation, attribuable à des caractéristiques identifiables. Leur réfutation exigerait l’exhibition d’un cas réel où un système non-RAISE-aligned absorbe une perturbation équivalente sans coût architectural, ou d’un cas où un système RAISE-aligned subit une perturbation comme refonte plutôt que comme requalification.
Les anti-patterns sont les pathologies typées du déploiement RAISE. Ils sont nommés par leur signature opérationnelle, identifiables par un signe diagnostique, c’est-à-dire par la phrase qu’on entend en réunion qui révèle leur présence. Cette section commence par les huit signes diagnostiques regroupés ; elle développe ensuite, pour chacun, la description et les piliers compromis.
- « On rendra ça conforme au moment de la mise en prod. »
- « On a ajouté SHAP, on est explicables. »
- « On a un comité IA. »
- « On peut toujours exporter en CSV. »
- « Le contrat de service couvre ça. »
- « L’audit est passé l’an dernier. »
- « L’AUC est de 0,93 sur le dataset de référence. »
- « Il y a toujours un humain dans la boucle. »
Si l’une de ces phrases a été prononcée dans une réunion d’architecture sans susciter une objection technique précise, l’anti-pattern correspondant est probablement présent dans le déploiement concerné. Chacun est une réponse linguistiquement irréprochable à une question de gouvernance, et c’est précisément ce qui les rend dangereux : ils déchargent l’interlocuteur de poursuivre la question.
La conformité est traitée comme une couche ajoutée en fin de cycle, après que l’architecture a été figée. Les dispositifs de conformité (logs, dashboards, dispositifs d’explicabilité) sont sérieux pris isolément, mais l’agrégat ne corrige pas la propriété architecturale qui rend le système non gouvernable. Pilier compromis : R principalement, par retour A et E. Correction architecturale minimale. Reprendre la spécification fonctionnelle d’au moins une exigence du corpus normatif comme contrainte de définition, pas comme test de validation, et tracer la chaîne de dérivation jusqu’aux composants concernés.
L’installation d’un outil d’interprétation technique (SHAP, LIME, attention maps) est traitée comme la satisfaction du pilier E, sans qualification du destinataire de l’explication, ni du cadre d’usage, ni du protocole de production. L’outil est présent, l’explicabilité au sens architectural est absente. Pilier compromis : E, par retour A. Correction architecturale minimale. Qualifier le destinataire de l’explication, son cadre d’usage et le protocole de production, avant l’installation de tout outil d’interprétation, et faire dériver le choix de l’outil de cette qualification, pas l’inverse.
Un comité IA, une charte, une matrice RACI sont produits, archivés, et présentés comme la satisfaction du pilier A. Aucun de ces objets n’a le pouvoir d’altérer une décision de conception. La responsabilité est diffuse au moment où elle aurait besoin d’être nominée. Pilier compromis : A, par retour R. Correction architecturale minimale. Identifier au moins une décision de conception qui peut être bloquée par une instance de gouvernance, et matérialiser ce pouvoir de blocage par une procédure tracée, opposable, et exercée au moins une fois.
Le système est présenté comme interopérable parce qu’il peut produire des exports en formats génériques. La sémantique des données exportées est laissée à la charge du consommateur, sans contrat opposable. Pilier compromis : I, par retour A et S. Correction architecturale minimale. Établir un contrat d’interface explicite avec un consommateur identifié, comprenant schéma versionné, sémantique opposable, garanties de qualité et clauses de rupture, sur au moins l’un des flux critiques du système.
La validation opérationnelle est externalisée au prestataire ou au fournisseur de modèle, sur la base d’une clause contractuelle qui transfère le risque. Le contrat couvre le risque juridique, pas la fiabilité opérationnelle ; la confusion entre les deux est l’anti-pattern. Pilier compromis : S, par retour A. Correction architecturale minimale. Définir, à l’intérieur de l’organisation, le protocole de validation contextuelle qui qualifierait la prestation du fournisseur comme conforme avant l’engagement contractuel, et conserver ce protocole comme exigence de spécification.
L’audit est conduit selon les règles de l’art, ses livrables sont produits dans les délais, il est mentionné dans les rapports annuels. Aucune de ses observations n’est en mesure d’altérer la décision opérationnelle, parce qu’il intervient en aval du moment où la décision est prise. Pilier compromis : A, par retour R, S, E. Correction architecturale minimale. Donner à l’audit un point d’intervention en amont d’au moins une décision de conception, avec capacité d’arrêt explicite et tracée, plutôt qu’une intervention exclusivement post-déploiement.
La performance du système est mesurée sur un jeu de données public, classique du domaine, et cette mesure est tenue comme suffisante pour qualifier la validation opérationnelle. La représentativité de la cohorte de benchmark vis-à-vis de la population de déploiement n’est pas examinée. Pilier compromis : S, par retour E et R. Correction architecturale minimale. Construire une cohorte de validation distincte des cohortes d’entraînement et de benchmark public, qualifiée comme représentative des conditions de déploiement, avec critères de représentativité documentés et opposables.
Un humain est positionné dans le diagramme de décision, conformément aux exigences réglementaires, mais sans disposer du temps, de l’information ou de l’autorité nécessaires pour altérer effectivement la décision automatisée. La supervision est nominalement présente, opérationnellement absente. Pilier compromis : A, par retour S et E. Correction architecturale minimale. Mesurer le temps, l’information et l’autorité dont dispose effectivement l’opérateur dans les conditions opérationnelles réelles, publier la mesure, et redimensionner soit le système, soit la position de l’humain, jusqu’à ce que la supervision soit exerçable.
La distinction binaire qui structure ces huit configurations est la suivante : présence d’un dispositif versus capacité effective du dispositif à altérer la décision. Aucun des anti-patterns ci-dessus ne procède d’une absence ; tous procèdent d’une présence sans capacité. Diagnostiquer un anti-pattern, c’est faire la différence entre un objet qui existe et un objet qui décide. Le diagnostic est rapide ; sa correction ne l’est pas, parce qu’elle exige de revenir sur la décision de conception qui a produit l’objet sans capacité.
Un dispositif de gouvernance se mesure à ce qu’il empêche, pas à ce qu’il documente.
Le framework, mobilisé en posture CTO, ne se mesure pas seulement à ce qu’il permet de produire ; il se mesure à ce qu’il permet de refuser sans perdre la main. Cinq refus archétypaux émergent de l’application des cinq piliers et de leur matrice. Ces refus ne sont pas des objections d’ingénieur ; ce sont des décisions d’architecte, qui engagent la trajectoire industrielle et la responsabilité du CTO.
Refus d’un go-live sans responsabilité nominée. Aucune mise en production d’un système d’IA en environnement régulé ne peut être validée tant que la chaîne de responsabilité n’a pas été établie nominalement sur chaque décision automatisée significative. Le pilier A donne au CTO le langage de ce refus.
Refus d’un benchmark comme validation. Aucune performance mesurée sur un jeu de données de référence ne tient lieu de validation contextuelle au sens du pilier S. Le CTO peut refuser un dossier de validation qui se limite à la performance sur benchmark, sans avoir à argumenter au cas par cas.
Refus d’un export CSV comme interopérabilité. Aucune capacité d’export en formats génériques ne tient lieu de contrat d’interface. Le pilier I autorise le CTO à exiger une contractualisation explicite avant l’admission d’un flux dans le système ou avant l’engagement d’un consommateur.
Refus d’une supervision humaine nominale. Aucune présence d’un humain dans le diagramme de décision ne tient lieu de supervision si l’opérateur ne dispose pas du temps, de l’information et de l’autorité pour altérer la décision. Le pilier A et la matrice 5×5 instruisent ce refus avec une précision qui rend la position défendable face aux exigences de cadence opérationnelle.
Refus d’un audit sans pouvoir d’altération. Aucun audit dont les observations ne peuvent altérer la décision opérationnelle ne tient lieu de gouvernance. Le pilier A, lu sous la critique de l’anti-pattern de la cérémonie d’audit, donne au CTO la grammaire de ce refus.
Ces cinq refus sont la traduction la plus directe de la formule centrale du document. Un cadre qui ne change pas la conception ne change que la documentation ; un CTO qui ne refuse pas les configurations ci-dessus ne change pas davantage la conception.
Les huit anti-patterns du §6.2 isolent des configurations où le diagnostic est rapide parce que la défaillance est complète et caricaturale. La pratique avancée des déploiements montre une catégorie supplémentaire, structurellement plus dangereuse parce qu’elle échappe au diagnostic immédiat : les faux positifs de maturité. Un faux positif de maturité est un déploiement où chacun des cinq piliers est partiellement satisfait, où aucun anti-pattern caricatural n’est observable, et où le système échoue néanmoins sous contrainte de cas-limite ou de stress combiné.
La signature opérationnelle d’un faux positif de maturité est typiquement la suivante. La conformité ponctuelle est démontrable sur l’audit standard ; la responsabilité est nommée sur le périmètre nominal ; l’interopérabilité est contractualisée sur les flux principaux ; la validation est conduite sur la cohorte attendue ; l’explicabilité est produite pour le destinataire prévu. Tous les piliers passent le test pris isolément. Le test combiné, lui, échoue : un cas-limite révèle qu’aucun des piliers n’a été instruit au niveau de profondeur qui résiste à la combinaison de plusieurs déviations simultanées.
Le diagnostic d’un faux positif de maturité exige donc un type d’évaluation distinct des huit anti-patterns. Quatre tests d’intégration sont mobilisables.
Test de propagation. Une perturbation injectée dans un pilier (par exemple une évolution réglementaire R) altère-t-elle effectivement les autres piliers, ou reste-t-elle confinée à la documentation ? Un déploiement gouvernable propage la perturbation jusqu’aux décisions de conception ; un faux positif l’absorbe par mise à jour documentaire.
Test de cas-limite combiné. Un cas opérationnel qui combine une donnée hors distribution, une responsabilité ambiguë et une explication contestée, est-il traité par l’architecture ou produit-il un fallback indéterminé ? Un déploiement gouvernable trace une décision défendable ; un faux positif produit une décision dont aucun des piliers ne peut être tenu pour responsable.
Test d’audit forensique. Un auditeur indépendant peut-il reconstruire la chaîne complète de décision d’un cas individuel à partir des seules traces conservées par le système, sans information additionnelle fournie par l’organisation ? Un déploiement gouvernable supporte cette reconstruction ; un faux positif exige des compléments oraux qui ne peuvent pas être audités.
Test de coût marginal. L’extension du périmètre de gouvernance à un nouveau cas d’usage produit-elle une augmentation du coût marginal proportionnelle à la complexité ajoutée, ou exponentielle parce que l’architecture initiale ne supportait pas l’extension ? Un déploiement gouvernable absorbe l’extension à coût proportionnel ; un faux positif révèle son architecture sous-instruite par l’explosion du coût.
Une organisation qui passe les huit anti-patterns du §6.2 mais échoue à l’un des quatre tests ci-dessus est en faux positif de maturité. C’est, statistiquement, la configuration la plus fréquente dans les déploiements RAISE-aligned déclarés. La détecter est l’usage propre du framework au-delà du diagnostic basique.
Un système qui passe l’audit standard mais échoue le cas-limite combiné est en faux positif de maturité.
Les huit anti-patterns du §6.2 sont des défaillances de premier ordre : un pilier est manqué, le diagnostic est rapide. Les faux positifs de maturité du §6.5 sont des défaillances de deuxième ordre : tous les piliers sont localement satisfaits, mais la composition échoue. Cette section formalise les patterns de défaillance de composition comme opérateurs diagnostiques réutilisables.
Anti-pattern P-O-1. Optimalité locale, incohérence globale. Chaque pilier est optimisé pour son indicateur propre, sans contrainte de cohérence transverse. Le pilier R intègre tous les textes applicables ; le pilier A nomme toutes les responsabilités ; le pilier I contractualise toutes les interfaces ; le pilier S valide toutes les cohortes ; le pilier E qualifie tous les destinataires. Aucun mécanisme ne vérifie que la lecture R, la chaîne A, les contrats I, les cohortes S et les destinataires E sont mutuellement consistants. Sign diagnostique : « chaque dashboard pilier est au vert, mais aucun n’a la vue cross-pilier. » Opérateur diagnostique : injecter dans la lecture R une exigence dérivée d’un texte ; observer si la chaîne A, les contrats I et les cohortes S y répondent. Proxies quantifiables : nombre de divergences détectées par audit transverse trimestriel ; ratio de KPIs piliers cohérents sur l’ensemble des KPIs piliers (objectif supérieur à 0,95). Seuil critique : moins de 0,80 vaut diagnostic positif.
Anti-pattern P-O-2. Couverture sans propagation. Chaque pilier couvre son périmètre attendu. Une perturbation injectée dans un pilier ne se propage pas aux autres : elle est confinée à la documentation du pilier perturbé. Une publication d’acte délégué AI Act met à jour le registre R, mais ne déclenche aucune revue d’architecture en A, I, S ou E. Sign diagnostique : « la mise à jour est notée, l’architecture est inchangée. » Opérateur diagnostique : tracer, sur les douze derniers mois, le nombre de modifications de R qui ont produit une modification observable dans au moins un autre pilier. Proxies quantifiables : time-to-propagation moyen entre publication d’une exigence normative et modification observable d’au moins un composant architectural (objectif inférieur à 90 jours pour les exigences à effet immédiat) ; nombre de composants impactés par perturbation R (objectif supérieur ou égal à un par perturbation effective) ; pourcentage de décisions opérationnelles requalifiées dans le trimestre suivant une perturbation R majeure. Seuil critique : time-to-propagation supérieur à 180 jours, ou zéro composant impacté, vaut diagnostic positif.
Anti-pattern P-O-3. Repli composite indéterminé. Chaque pilier traite son cas nominal. Une combinaison de cas-limites simultanés (donnée hors distribution, responsabilité ambiguë, explication contestée) produit un fallback dont aucun pilier n’est responsable. Le système traite chaque cas pris isolément, mais n’a pas de comportement défini pour la combinaison. Sign diagnostique : « on n’a jamais eu ce cas exact. » Opérateur diagnostique : injecter, dans un environnement de test contrôlé, une combinaison de trois déviations simultanées choisies dans des piliers différents ; observer la décision produite et son traçage. Proxies quantifiables : ratio (cas combinés produisant une décision tracée et défendable par responsable nommé) sur (cas combinés testés), avec objectif supérieur à 0,90 ; temps de reconstruction d’une décision composite par un auditeur externe. Seuil critique : moins de 0,70, ou production de fallback non traçable, vaut diagnostic positif.
Anti-pattern P-O-4. Asymétrie d’audit. Chaque pilier passe son audit individuel. Aucun auditeur n’a la vue cross-pilier qui permettrait de diagnostiquer une défaillance de composition. Le pilier R est audité par le service juridique ; le pilier A par le contrôle interne ; le pilier I par l’IT ; le pilier S par les data scientists ; le pilier E par le DPO. Aucun ne lit les rapports des quatre autres. Sign diagnostique : « tous les audits sont favorables et le système échoue quand même. » Opérateur diagnostique : commander un audit transversal dont le mandat est explicitement la cohérence des cinq piliers, conduit par un auditeur indépendant des cinq audits sectoriels. Proxies quantifiables : nombre d’audits transversaux composites conduits par an (objectif supérieur ou égal à un par cycle annuel) ; pourcentage des observations transversales ayant déclenché une revue d’architecture (objectif supérieur à 0,50). Seuil critique : zéro audit composite annuel, ou zéro revue déclenchée, vaut diagnostic positif.
Ces quatre patterns ont une caractéristique commune : leur diagnostic est plus coûteux que celui des huit patterns de premier ordre, parce qu’il exige une vue cross-pilier qui n’est ni produite ni demandée par les audits standards. Leur correction exige typiquement une révision des points de gouvernance composite, c’est-à-dire des instances ou des procédures qui prennent les cinq piliers comme un objet d’évaluation unique. Sans cette gouvernance composite, les patterns de second ordre sont, en pratique, indétectables jusqu’à l’incident.*
Le présent volume a exposé l’architecture doctrinale du cadre RAISE. Trois formules de compression condensent ce que les cinq piliers, leur matrice d’interdépendances et leurs anti-patterns, pris ensemble, défendent.
Un cadre qui ne change pas la conception ne change que la documentation.
Un dispositif de gouvernance se mesure à ce qu’il empêche, pas à ce qu’il documente.
Un système qui passe l’audit standard mais échoue le cas-limite combiné est en faux positif de maturité.
Le Volume 2, Application opératoire (référence interne TI-2026-FRMK-RAISE-v1.0-V2), prolonge cet exposé doctrinal par sa mise à l’épreuve sectorielle, ses limites authentiques, son articulation économique au seuil de criticité C*, ses huit questions canoniques et la formule de repositionnement final qui ferme la boucle ouverte au préambule. La lecture du Volume 2 présuppose l’acquisition du Volume 1 sur les cinq piliers, la matrice 5×5 et les douze anti-patterns (huit canoniques de §6.2 et quatre de second ordre de §6.6).
Les termes ci-dessous reçoivent leur définition opératoire dans le contexte de RAISE. Les définitions ne se substituent pas aux définitions juridiques ou techniques par ailleurs établies ; elles précisent l’usage que le framework en fait.
Auditabilité. Capacité d’un système à supporter une reconstruction ex post de ses décisions par un tiers qualifié, à un niveau de détail compatible avec le cadre de classification ou de confidentialité applicable. À distinguer de la disponibilité d’une documentation, qui en est la condition mais non l’équivalent.
Supervision humaine effective. Présence dans la chaîne décisionnelle d’un opérateur humain disposant simultanément de l’information, du temps et de l’autorité nécessaires pour altérer la décision automatisée. À distinguer de la supervision humaine fictive, qui satisfait l’exigence formelle sans la satisfaire opérationnellement.
Réversibilité. Capacité d’une décision automatisée à être annulée ou révisée selon un protocole tracé, dans un délai compatible avec la nature du dommage potentiel. La réversibilité n’est ni la simple disponibilité d’une fonction d’annulation technique, ni l’engagement contractuel d’un fournisseur ; elle est une propriété d’architecture.
Légitimité décisionnelle. Caractère d’une décision automatisée qui peut être tenue pour acceptable par les destinataires de ses effets, sous le double régime de la conformité aux règles applicables et de la justifiabilité de son raisonnement. Distinct de la conformité formelle, qui peut être obtenue sans légitimité.
Conformité par construction. Propriété d’un système dont la spécification fonctionnelle a été établie sous la contrainte des exigences normatives applicables, et dont l’architecture porte la trace de cette contrainte. À distinguer de la conformité par avenant.
Traçabilité ontologique. Capacité du système à conserver, pour chaque décision, l’identité des objets architecturaux qui ont supporté la décision, dans un registre opposable. Distincte de la traçabilité événementielle, qui enregistre les actions sans qualifier les objets.
Ports d’admission. Interfaces par lesquelles des données ou signaux entrent dans le système, régies par des contrats explicites qui spécifient schéma, sémantique et conditions d’acceptation. Le concept est repris du corpus doctrinal Twingital.
Validation contextuelle. Mesure de la fiabilité d’un système conduite sur une cohorte représentative des conditions de déploiement, selon un protocole pré-spécifié. À distinguer de la performance sur benchmark public.
Explicabilité décisionnelle. Production d’une justification d’une décision automatisée qualifiée par son destinataire, son cadre d’usage, et son protocole de génération. À distinguer de l’interprétabilité technique, qui décrit le fonctionnement du modèle sans qualifier la pertinence pour le destinataire.
Justification de conception. Trace, intégrée à l’architecture du système, qui rend explicite la chaîne de décisions architecturales ayant conduit à la spécification fonctionnelle effective. À distinguer de l’explication a posteriori, qui est produite après la décision et indépendamment d’elle.
Responsabilité nominée. Engagement formel et opposable d’une personne physique nommément identifiée à porter une décision de conception ou d’exploitation. À distinguer de la responsabilité diffuse, portée par une organisation ou une fonction abstraite.
Tension caractéristique. Configuration spécifique à un secteur dans laquelle une boucle particulière de la matrice 5×5 devient structurante au point d’imposer le ton de l’ensemble du déploiement. Trois tensions principales sont nommées dans le présent document, trois autres sont mentionnées en synthèse.
Cette annexe synthétise, sous forme tabulaire, les principales revendications doctrinales du document, les éléments d’evidence qui les soutiennent, et les conditions sous lesquelles chacune serait réfutée. La table sert de colonne vertébrale académique au cadre. Elle est complémentaire des limites authentiques du §10 : ces limites énoncent ce que RAISE ne fait pas ; cette table énonce ce que RAISE fait, sur quel fondement, et sous quelles conditions cette prétention serait abandonnée.
| Revendication | Evidence mobilisée | Conditions de falsification |
|---|---|---|
| Cinq piliers couvrent la gouvernabilité de l’IA en environnement régulé | Test de minimalité §3.8, observation multi-sectorielle (méthode), absence de sixième pilier non-orthogonal documenté | Exhibition d’un sixième pilier non-réductible aux cinq et non-orthogonal aux cadres existants |
| Toutes les arêtes de la matrice 5×5 sont non-nulles | Démonstration de collapsus partielle §5.5 sur trois arêtes (R→A, A→S, E→R), argument de cohérence interne | Démonstration qu’une paire admet une dépendance nulle dans un déploiement réel, sans équivalent fonctionnel |
| La représentation cyclique est plus expressive qu’un graphe acyclique dirigé | Boucles documentées E→R (jurisprudence absorption) et co-détermination I/S §3.8 | Architecture acyclique préservant la couverture diagnostique de la matrice cyclique |
| La typologie ternaire (possibilité, validité, légitimité) est minimale et suffisante | Trois moments de contestation possibles §5.1, comparaison avec typologies |
Renseignez vos coordonnées pour accéder au document. Accès gratuit — aucun démarchage commercial.
Document nominatif · Accès gratuit · Aucun démarchage commercial