Volume 2 sur 2. Application opératoire
Le présent document est le second d’un ensemble de deux volumes qui composent ensemble la version 1.0 du cadre RAISE. Le Volume 1 (référence interne TI-2026-FRMK-RAISE-v1.0-V1, Cadre doctrinal) expose l’architecture doctrinale du cadre : ses cinq piliers, leur matrice 5×5 d’interdépendances, leurs douze anti-patterns canoniques et de second ordre, le critère de réfutation et les transformations irréductibles T1 à T5. Le présent Volume 2 prolonge cet exposé par sa mise à l’épreuve opérationnelle.
Le Volume 2 contient la Partie III, qui développe le modèle de maturité à quatre niveaux avec sa dimension de régression contrôlée (§7), l’application sectorielle aux trois terrains principaux (Healthcare, Finance, Defense, §8) avec asymétrie de statut explicite, et trois secteurs annexes en synthèse (§9). Il contient la Partie IV, qui énonce les sept limites authentiques du framework (§10), incluant le modèle de seuil de criticité C* avec ses trois conditions de validité, l’évolution attendue (§11), et la FAQ doctrinale en huit questions canoniques (§12). Il se ferme par une clôture intégrale et trois annexes : sources réglementaires de référence par secteur (B), carrefour doctrinal du corpus Twingital (C), notice de propriété intellectuelle, version et historique (D).
La lecture du Volume 2 présuppose l’acquisition du Volume 1. Les piliers R, A, I, S et E, la matrice cyclique typée, les anti-patterns canoniques et leurs corrections architecturales minimales, ainsi que le critère de réfutation et les transformations irréductibles, sont mobilisés sans redéfinition. Le lecteur qui ouvre directement ce Volume 2 sans avoir lu le Volume 1 est invité à se reporter à l’Annexe A du Volume 1 (glossaire opérationnel) pour la définition des termes techniques mobilisés.
La notice de propriété intellectuelle (Annexe D du présent volume) est applicable conjointement aux deux volumes.
Partie III. Opérationnalisation
§7. Modèle de maturité. Quatre niveaux, livrables, critères
§8. Application sectorielle. Trois terrains, trois tensions
§9. Trois secteurs annexes en synthèse
Partie IV. Discussion et finition
§10. Limites authentiques du framework
§11. Évolution attendue
§12. FAQ doctrinale. Huit questions canoniques
Clôture
Annexes
B. Sources réglementaires de référence par secteur C. Carrefour doctrinal du corpus Twingital Institute D. Notice de propriété intellectuelle, version, et historique
Le déploiement RAISE ne se mesure pas à la satisfaction simultanée des cinq piliers ; il se mesure à la trajectoire par laquelle une organisation atteint, puis maintient, l’alignement de ses systèmes d’IA aux cinq dimensions du cadre. Le modèle de maturité ci-dessous fournit la grille de cette trajectoire. Quatre niveaux sont distingués, chacun caractérisé par sa question fondatrice, ses livrables attendus, ses critères de transition vers le niveau suivant, et un ordre de durée typique.
| Niveau | Question fondatrice | Livrables attendus | Critères de transition | Durée typique observée |
|---|---|---|---|---|
| 1. Diagnostic | Où sommes-nous sur les cinq piliers ? | Cartographie RAISE, registre des écarts, priorisation des chantiers | Diagnostic validé en direction, plan d’architecture engagé | 4 à 8 semaines |
| 2. Architecture | Comment intégrons-nous RAISE dans la conception ? | Spécification d’architecture RAISE-aligned, contrats d’interface, modèle de données, protocoles de validation contextuelle | Architecture validée, prototype pilier-conforme | 3 à 6 mois |
| 3. Gouvernance | Comment maintenons-nous l’alignement dans la durée ? | Comités opérationnels avec pouvoir d’altération, procédures d’auditabilité, chaînes de responsabilité documentées et signées | Gouvernance auditée, premier incident traité conformément | 6 à 12 mois |
| 4. Maintenance | Comment surveillons-nous la dérive ? | Tableau de bord RAISE, revue périodique, reporting régulateur, mécanismes de revalidation déclenchés par signal | Atteinte d’une stabilité observable, incidents traités sans régression structurelle | continu |
Le modèle est cumulatif et non-substitutif. Atteindre le niveau 3 ne dispense pas des livrables des niveaux 1 et 2 ; il les présuppose et les met à jour. Une organisation qui prétend exercer la gouvernance sans avoir produit l’architecture ne gouverne rien ; elle décrit des intentions. La séquence des niveaux n’est pas un ordonnancement temporel arbitraire ; c’est l’ordre des conditions de possibilité.
Les durées indiquées sont des ordres de grandeur indicatifs, dérivés de l’observation multi-sectorielle 2022-2026 (cf. méthode de construction du Volume 1) et non d’une étude systématique. Elles dépendent du périmètre engagé, de la maturité initiale de l’organisation, et de la disponibilité d’une expertise transverse capable de tenir à la fois la lecture normative, l’architecture système, et la gouvernance opérationnelle. Une organisation qui revendique le niveau 4 en six mois a, dans le meilleur des cas, traité un périmètre trivial ; dans le moins bon, un problème de définition de ses propres niveaux.
Une dimension absente des modèles de maturité conventionnels mérite d’être introduite : la régression de niveau. Un projet qui était au niveau 3 et qui retombe au niveau 2 n’est pas, en soi, le signe d’une défaillance de gouvernance. C’est le signe que l’une des dépendances de la matrice du chapitre précédent vient de devenir saillante au point d’imposer un retour à l’architecture. La régression la plus fréquemment observée est la chute de gouvernance vers architecture (niveau 3 vers niveau 2) déclenchée par une saillance R vers A, c’est-à-dire par une évolution du corpus normatif qui rend la chaîne de responsabilité existante insuffisamment instruite. C’est le scénario typique d’une publication d’acte délégué ou d’une décision de l’AI Office qui précise une obligation jusque-là indéterminée.
La régression vers l’architecture n’est pas un échec ; c’est un succès du dispositif de veille. Le seul échec serait de ne pas la diagnostiquer, et de continuer à exercer la gouvernance sur une architecture désormais sous-instruite. Le modèle de maturité doit donc être lu non comme un escalator où l’on monte, mais comme une trajectoire où l’on peut, et parfois où l’on doit, redescendre. Les organisations matures sont celles qui ont normalisé la régression contrôlée comme procédure d’adaptation, plutôt que comme aveu d’incompétence.
Les cinq piliers de RAISE n’ont pas le même poids relatif d’un secteur à l’autre. Ce qui distingue un déploiement en santé d’un déploiement en finance ou en défense, ce n’est pas le fait que des piliers seraient présents dans l’un et absents dans l’autre, mais le fait qu’une boucle particulière de la matrice du chapitre 5 devient, dans chaque secteur, structurante au point d’imposer le ton de tout le déploiement. Cette boucle, nous la nommons tension caractéristique. Trois tensions caractéristiques sont développées ci-dessous, une par secteur. Chacune est nommée comme objet doctrinal, pour permettre sa citation et son débat ultérieurs.
Une précision sur le statut épistémique des trois tensions s’impose avant le déroulé. Les sections Healthcare (§8.1) et Finance (§8.2) sont fondées sur des cadres juridiques publiquement documentés et des cas de jurisprudence accessibles, dont les divergences (article 86 AI Act et Annexe XIV MDR pour la santé ; RGPD article 22 et secret des affaires pour la finance) sont des objets de débat publié et de jurisprudence stabilisée. Ces deux tensions sont qualifiées de validées par cadre juridique et jurisprudence. La section Defense (§8.3) est en revanche présentée comme extension prédictive du cadre, conformément à la note de §8.3.4 : son statut empirique est contraint par la nature classifiée des déploiements et par l’indisponibilité des retours d’expérience publiquement instructibles. La symétrie de présentation entre les trois sections ne reflète pas une symétrie de validation. Cette asymétrie de statut est revendiquée plutôt qu’esquivée, et le lecteur est invité à pondérer la lecture des trois sections en fonction de cette différence de statut.
Dans le secteur de la santé, l’explicabilité d’un système d’IA est l’objet d’une exigence régulatoire dédoublée. L’EU AI Act, en son article 86, accorde à la personne concernée par une décision à haut risque le droit à une explication des éléments de la décision automatisée. La directive sur les dispositifs médicaux, en son Annexe XIV, exige du fabricant une évaluation clinique fondée sur des preuves de performance, accompagnée d’une surveillance après commercialisation qui mesure la performance dans les conditions réelles d’usage. Les deux exigences ne s’opposent pas formellement ; elles définissent deux objets d’explication distincts dont la cohérence n’est pas garantie. Ce que l’AI Act qualifie comme explication suffisante pour le patient n’est pas nécessairement ce que la MDR qualifie comme évaluation clinique défendable, et l’inverse. La Tension d’explicabilité contestée est l’objet doctrinal qui nomme cette divergence et la traite comme contrainte de conception, plutôt que comme problème d’interprétation à résoudre au cas par cas.
Le pilier R s’instancie comme lecture croisée AI Act × MDR/IVDR. La lecture isolée de l’un ou de l’autre des textes produit deux architectures différentes ; la lecture croisée produit une architecture qui prend acte des points de divergence et les traite comme des décisions de conception explicites. Le RGPD, le règlement HDS, les normes ICH E6 R3 pour les essais cliniques et FHIR R5 pour l’interopérabilité, complètent ce corpus. [Renvoi Twingital, Collision ontologique MDR/AI Act, à formaliser].
Le pilier A en santé est porté par une chaîne de responsabilité tripartite peu commune : le fabricant du dispositif médical répond de la conformité MDR, l’opérateur de soin répond de la conformité d’usage, et le délégué à la protection des données répond de la conformité RGPD. La superposition de ces trois régimes crée des zones de chevauchement où la responsabilité doit être nominée explicitement, faute de quoi elle est diffuse par construction. L’organisme notifié sous MDR ajoute une quatrième dimension de surveillance, qui ne se confond avec aucune des trois autres.
Le pilier I s’instancie autour des standards d’interopérabilité de santé : FHIR R5 pour l’échange clinique, le connecteur SNDS pour l’accès aux données de santé françaises, InteropSanté pour les profils d’intégration, le Health Data Hub comme infrastructure de mise à disposition. Aucun de ces standards n’est nominalement obligatoire pour tout déploiement, mais leur absence rend, en pratique, l’interopérabilité par contrat impossible et renvoie au pilier I déficient de l’anti-pattern de l’export en formats génériques.
Le pilier S en santé est qualifié par l’évaluation clinique au sens de l’Annexe XIV de la MDR. Cette évaluation peut exiger, selon la classe du dispositif, son intended purpose, sa nouveauté et le niveau de preuve disponible, la génération de données cliniques propres, parfois prospectives, sur une cohorte représentative de la population de déploiement, complétées par un plan de post-market clinical follow-up (PMCF). Selon le cas, la validation rétrospective sur jeux de données publics peut alimenter le dossier de pré-marquage mais ne suffit pas, à elle seule, au dossier de conformité.
Le pilier E s’instancie comme explicabilité décisionnelle, lorsque le système entre dans le champ pertinent du droit à explication tel qu’établi par l’article 86 de l’AI Act pour les systèmes à haut risque relevant de l’Annexe III, ou lorsque le régime sectoriel (notamment la MDR pour les dispositifs médicaux relevant de l’Annexe I, ou le RGPD article 22 pour les décisions automatisées affectant la personne) impose fonctionnellement une exigence analogue de justification. Sous l’une de ces conditions, l’explication doit être utile au patient ou à l’utilisateur, défendable devant un professionnel de santé, et cohérente avec le raisonnement clinique sans le contredire. C’est cette contrainte de cohérence qui produit la tension caractéristique. [Renvoi Twingital, Bayésien et crédibilité réglementaire, à formaliser].
PREDICARE est un dispositif de médecine prédictive territoriale dont l’architecture mobilise les cinq piliers de RAISE de manière simultanée, sous la Tension d’explicabilité contestée identifiée ci-dessus. Le dispositif articule des modèles prédictifs spécifiques à des cohortes territoriales qualifiées, sous un protocole de validation prospective en condition d’usage clinique réel, avec un dispositif d’explicabilité décisionnelle dont la conception intègre, en amont, les exigences article 86 AI Act et la cohérence avec le raisonnement bayésien clinique. PREDICARE n’est pas, dans ce document, une preuve de la généralité du framework ; c’est un terrain d’implémentation où les contraintes de conception décrites par la Tension d’explicabilité contestée sont prises au sérieux. Sa documentation d’architecture est instruite séparément ; sa mention ici sert uniquement à indiquer que la tension n’est pas une abstraction mais une contrainte d’usage observable.
Le secteur financier opère sous trois temporalités réglementaires distinctes qui imposent, chacune à leur manière, une exigence de traçabilité et de justifiabilité des décisions automatisées : DORA pour la résilience opérationnelle numérique, MiFID II pour la qualification du conseil en investissement, et la directive AI Act pour les systèmes d’IA à haut risque dont relèvent notamment les modèles d’évaluation de la solvabilité des personnes physiques. Solvency II et Bâle III ajoutent, pour l’assurance et la banque, des exigences de model risk management qui imposent la justifiabilité interne des modèles d’estimation de capital et des modèles internes de scoring. Ces exigences entrent en collision frontale avec le fait que l’avantage concurrentiel des établissements financiers repose, pour partie, sur l’opacité partielle de leurs modèles internes. La Tension d’opacité concurrentielle est l’objet doctrinal qui nomme cette divergence : ce que le régulateur exige comme transparence justifiable, le marché le qualifie comme atteinte à un actif concurrentiel, et la décision de conception doit trancher dans une zone que ni la jurisprudence ni les guidelines de l’EBA ou de la BCE n’ont stabilisée.
Le pilier R s’instancie comme lecture croisée DORA × MiFID II × AI Act. Les trois temporalités réglementaires ne se synchronisent pas : DORA s’applique depuis janvier 2025, l’AI Act monte en phase progressive jusqu’en 2027, MiFID II évolue par actes délégués. Lire les trois ensemble exige de qualifier, exigence par exigence, la temporalité d’opposabilité, et de concevoir une architecture qui supporte les trois sans imposer la rigidité de l’une à toutes.
Le pilier A en FSI est codifié par le modèle des trois lignes de défense, dont l’interprétation européenne sous DORA requiert que le directeur des risques (CRO) et la direction effective (au sens de l’article L. 511-13 du Code monétaire et financier en France, transposé dans les autres juridictions européennes) portent la responsabilité opérationnelle des décisions automatisées. Les guidelines de l’EBA sur les outsourcing arrangements ajoutent que cette responsabilité ne peut être transférée à un fournisseur externe par voie contractuelle. La nomination de responsabilité est ici structurellement contraignante.
Le pilier I s’instancie autour des standards de reporting (ESEF pour l’information financière, XBRL pour le reporting prudentiel), des protocoles de marché (FIX pour la transmission d’ordres), et des exigences de continuité opérationnelle DORA. La contractualisation des interfaces y est plus mature que dans la santé, mais reste sous-spécifiée pour les flux internes des systèmes d’IA, qui sont fréquemment laissés sous régime informel.
Le pilier S en FSI est porté par les pratiques de backtesting et de stress testing, encadrées par le model risk management dont les standards européens (TRIM pour la BCE, EBA Guidelines on internal models) reprennent et adaptent les principes de la guidance américaine SR 11-7. Ces standards sont opérationnellement matures pour les modèles classiques de risque (crédit, marché, liquidité) ; ils ne traitent pas, ou traitent insuffisamment, les modèles d’IA générative récemment introduits dans le scoring et l’analyse de portefeuille.
Le pilier E est le lieu propre de la tension. L’explicabilité réglementaire exigée pour défendre une décision automatisée devant l’autorité de tutelle ou devant un client, sous l’article 22 du RGPD et son considérant 71, entre en tension avec la protection de l’algorithme comme actif concurrentiel et avec les régimes de secret des affaires. La résolution de cette tension n’est ni technique ni juridique seule ; elle est architecturale.
Le scoring de crédit pour particuliers est l’exemple cas-limite de la Tension d’opacité concurrentielle. L’article 22 du RGPD donne à la personne concernée le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé, et le considérant 71 précise que cette personne a droit à une explication. La jurisprudence de la Cour de justice de l’Union européenne (arrêt SCHUFA, C-634/21, 2023) a confirmé que la décision automatisée s’entend largement, ce qui inclut le scoring même lorsqu’un agent humain valide formellement la décision sans pouvoir effectif d’arbitrage. Côté établissement, le modèle de scoring est protégé par le secret des affaires, et sa divulgation détaillée à chaque demandeur en exposerait la logique à des stratégies de contournement. Le pilier E du framework impose alors une explicabilité décisionnelle qualifiée par destinataire (le demandeur ne reçoit pas l’explication que reçoit le régulateur), dotée d’un protocole de génération qui préserve l’intégrité du modèle, et tracée pour permettre l’audit ex post. Aucune de ces trois conditions n’est satisfaite par l’installation d’un outil d’interprétation technique sur le modèle existant ; toutes les trois exigent une décision de conception en amont. C’est précisément ce que la Tension d’opacité concurrentielle, comme objet doctrinal, rend visible.
L’objection naturelle à la Tension d’opacité concurrentielle est qu’elle serait déjà traitée par l’article 22 du RGPD et par la jurisprudence subséquente, dont l’arrêt SCHUFA. Cette objection est partiellement juste et structurellement insuffisante. Le RGPD article 22 et SCHUFA fournissent le cadre juridique de la décision automatisée affectant la personne physique ; ils ne fournissent pas la grammaire architecturale qui permettrait de concilier l’exigence de justification décisionnelle avec la protection du modèle comme actif concurrentiel. La résolution proposée par la pratique consiste fréquemment à produire des explications dégradées qui ne renseignent ni le destinataire ni le régulateur ; cette résolution satisfait la lettre du droit sans satisfaire son esprit, et elle expose l’établissement à la critique successive du régulateur, du juge et du marché.
La Tension d’opacité concurrentielle, comme objet doctrinal, fait deux choses que le seul article 22 ne fait pas. Premièrement, elle reconnaît que l’opacité concurrentielle est un actif architectural à protéger, pas seulement une commodité à atténuer. Cette reconnaissance change l’ordre des contraintes de conception : l’opacité n’est plus traitée comme un défaut à compenser, mais comme une propriété à différencier par destinataire. Deuxièmement, elle propose le pilier E comme grammaire de différenciation des explications par destinataire (régulateur, client, juridiction interne, marché concurrent), avec des chaînes de désanonymisation contrôlées qui préservent l’asymétrie d’information sans la rendre opposable comme dissimulation. Le résultat n’est pas une atténuation de la tension ; c’est sa formalisation comme objet d’architecture, ce que ni le RGPD ni la jurisprudence n’opèrent.
La formalisation de la Tension d’opacité concurrentielle comme objet d’architecture appelle des patterns de conception identifiables. Trois architectures de résolution sont esquissées ici, sans prétention d’exhaustivité.
Architecture par chaîne d’explicabilité différenciée. L’explication produite par le système n’est pas un objet unique ; elle est instanciée différemment selon le destinataire, sous une chaîne contractualisée. Le demandeur reçoit une explication synthétique qui satisfait l’article 22 RGPD sans révéler la logique du modèle ; le régulateur, sur réquisition tracée, reçoit une explication structurée qui inclut les facteurs de décision et les conditions d’éligibilité ; la juridiction, en cas de litige, reçoit l’explication complète sous séquestre judiciaire avec procédure de désanonymisation contrôlée. Chaque destinataire reçoit ce dont il a besoin pour exercer son rôle, et rien de plus. La chaîne est elle-même un objet contractualisé entre l’établissement et le régulateur.
Architecture par modèle de surveillance distinct. Le modèle de décision opérationnelle, protégé par secret commercial, est doublé d’un modèle de surveillance dont la fonction est de détecter la dérive de décision par catégorie protégée (article 22 considérant 71 RGPD) et de produire les signaux d’alerte au régulateur. Le modèle de surveillance est conçu pour être interprétable, partage les données d’entrée du modèle de décision sans en partager l’architecture, et fonctionne sous gouvernance distincte. Cette architecture résout l’apparente contradiction entre opacité commerciale et transparence régulatoire en distinguant deux objets architecturaux complémentaires.
Architecture par registre de décisions opposable. Chaque décision automatisée du système est inscrite dans un registre signé, horodaté, et architecturé pour permettre la reconstruction ex post à différents niveaux de granularité selon le destinataire de la requête. Le registre lui-même est l’objet contractualisé ; le modèle de décision peut rester opaque, mais ses sorties sont rendues opposables par la trace. Cette architecture mobilise particulièrement le pilier I (contrats d’interface du registre) et le pilier A (responsabilité nommée du teneur de registre).
Ces trois architectures ne sont pas exclusives ; elles peuvent se combiner sur un même déploiement. Leur fonction commune est de transformer la Tension d’opacité concurrentielle en jeu de contraintes de conception explicites, plutôt qu’en compromis ad hoc négocié au cas par cas avec le régulateur.
Le traitement du secteur Défense ci-dessous est délibérément qualifié comme extension prédictive du framework, et non comme application sectorielle de même statut épistémique que les sections Healthcare et Finance. Les raisons de ce statut sont énoncées en §8.3.4. Le lecteur disposant d’une expertise opérationnelle en architectures classifiées est invité à lire cette section comme prédiction architecturale soumise à confrontation, plutôt que comme synthèse d’observations stabilisées.
Le secteur de la défense est exclu du champ d’application de l’AI Act par l’article 2(3), qui réserve les systèmes d’IA mis sur le marché ou mis en service exclusivement à des fins militaires, de défense ou de sécurité nationale. Cette exclusion ne signifie pas absence de cadre, mais cadre distinct, et plus contraignant sur certains piliers. Les systèmes d’IA à finalité militaire relèvent des cadres OTAN (STANAG), de la directive européenne sur les biens à double usage (règlement 2021/821), des cadres nationaux de classification (IGI 1300 en France, équivalents nationaux ailleurs), et des doctrines d’emploi spécifiques aux forces armées. La tension caractéristique du secteur est la suivante : l’auditabilité des systèmes d’IA, qui est une exigence opérationnelle pour la chaîne de commandement, requiert une traçabilité qui, par la nature classifiée des opérations, ne peut être ni produite ni conservée sous les formes que les piliers A et E supposent dans les autres secteurs. La Tension d’auditabilité classifiée est l’objet doctrinal qui nomme cette divergence.
Le pilier R combine l’exclusion AI Act, le règlement européen sur les biens à double usage, les cadres OTAN, les doctrines nationales de classification, et les directives ANSSI/PAMS pour les systèmes hébergeant des informations classifiées. La lecture active du corpus est ici plus exigeante que dans la santé ou la finance, parce que l’absence d’un cadre supranational unifié impose une lecture par juridiction d’emploi. [Renvoi Twingital, Apprendre ce qui ne peut pas varier, à formaliser].
Le pilier A est articulé autour de la chaîne de commandement militaire, dont la responsabilité opérationnelle appartient nominativement au chef d’unité ou au commandant tactique, et dont l’homologation des systèmes relève de l’autorité d’emploi (en France, le contrôle général des armées et la DGA pour les systèmes d’armement). Cette chaîne est plus claire qu’en santé ou en finance, parce qu’elle est codifiée par les règlements de service ; mais elle est aussi plus exigeante, parce qu’elle ne peut être déléguée à un comité ou à un dispositif collégial.
Le pilier I s’instancie sous les standards d’interopérabilité OTAN (STANAG pour les protocoles de transmission, AEDP pour les données géospatiales, MIL-STD pour les interfaces), sous la contrainte de la souveraineté numérique nationale, et sous les règles de cloisonnement par niveau de classification (Restreint, Confidentiel Défense, Secret Défense). Le cloisonnement transforme l’interopérabilité par contrat en interopérabilité par contrat segmenté : les contrats existent à chaque niveau, mais ne traversent pas les niveaux sans procédure d’autorisation explicite.
Le pilier S est porté par la qualification opérationnelle des systèmes d’armement, qui combine validation en conditions de combat simulé (MILDEP en France, équivalents OTAN ailleurs) et validation en conditions d’engagement réel à mesure des retours d’expérience opérationnelle. Cette validation présente une particularité : elle doit traiter le caractère adversarial du contexte d’usage, qui rend la robustesse écologique mentionnée au chapitre 4 indissociable de la robustesse adversariale.
Le pilier E est le lieu propre de la tension. L’explicabilité décisionnelle, au sens architectural du chapitre 4, exige que la décision automatisée puisse être reconstruite et défendue devant un tiers qualifié. En environnement classifié, la documentation qui rend cette reconstruction possible est elle-même un objet sensible, dont la production et la conservation ouvrent une surface d’exposition au renseignement adverse. La résolution n’est ni de renoncer à l’explicabilité, ni d’exposer la documentation ; elle est de concevoir des protocoles d’explicabilité différenciés par niveau d’auditeur, avec des chaînes de désanonymisation contrôlées.
Les systèmes d’aide à la décision de désignation de cible représentent le cas-limite de la Tension d’auditabilité classifiée. Un tel système traite des sources de renseignement multiples, applique des modèles de classification et de priorisation, et présente à l’opérateur un ensemble qualifié de cibles potentielles avec une indication de niveau de confiance et de risque collatéral. Le droit international humanitaire, à travers les protocoles additionnels aux conventions de Genève, exige que la décision finale soit prise par un humain disposant d’un contrôle significatif (le concept de meaningful human control), avec capacité d’évaluer la distinction entre objectifs militaires et personnes protégées et la proportionnalité de l’engagement. Le pilier A du framework, lu sous cette contrainte, exige que la chaîne de responsabilité de la décision soit documentée à un niveau de détail qui rendrait, si elle était traitée comme dans la santé ou la finance, le système entier exposable au renseignement adverse. Le pilier E exige une explicabilité de la recommandation qui soit utile à l’opérateur sans révéler les sources de renseignement qui l’ont produite. La Tension d’auditabilité classifiée, comme objet doctrinal, rend visible que la résolution n’est pas un compromis entre auditabilité et classification, mais une architecture dans laquelle la documentation est multi-niveau, son accès est traçable, et sa désanonymisation est conditionnée à des cadres juridiques externes (commission d’enquête parlementaire, juridiction internationale, contrôle général des armées). La conception de cette architecture est l’objet propre du déploiement RAISE en environnement Defense.
La Tension d’auditabilité classifiée est, parmi les trois tensions développées dans ce chapitre, celle dont la démonstration empirique est la plus contrainte. Les déploiements opérationnels en environnement classifié ne font pas, par construction, l’objet de publications académiques détaillées ; les retours d’expérience accessibles sont le plus souvent dépouillés des éléments qui permettraient l’analyse architecturale fine. Le présent traitement est donc plus conceptuel que démonstratif ; il s’appuie sur les cadres juridiques publiquement disponibles, sur les doctrines d’emploi documentées en sources ouvertes, et sur l’analyse de la cohérence interne du framework.
Cette limite épistémique est assumée. Elle n’invalide pas la tension comme objet doctrinal ; elle qualifie son statut comme prédiction architecturale plutôt que comme observation empirique stabilisée. Une réfutation de cette tension exigerait soit une démonstration que l’auditabilité et la classification sont effectivement compatibles dans les déploiements actuels par d’autres voies que celle proposée ici, soit une démonstration que la tension peut être résolue par des mécanismes que RAISE n’envisage pas. Aucune des deux n’est, à la date de ce document, publiquement disponible dans la littérature consultée. La section §8.3 doit donc être lue comme un cadre prédictif de gouvernabilité, à confronter aux pratiques effectives à mesure qu’elles deviennent publiquement instructibles.
Le développement détaillé de trois secteurs n’épuise pas la portée du framework. Trois secteurs supplémentaires, traités ici en synthèse, font apparaître chacun une tension caractéristique distincte de celles examinées au chapitre 8. Leur développement complet est laissé à des travaux ultérieurs ; leur mention ici signale que la grammaire architecturale de RAISE est instanciable bien au-delà des trois terrains principaux.
Le corpus normatif applicable combine le RGS v2 pour les systèmes d’information publics, le RGPD, les évolutions DORA pour les services financiers publics, les référentiels ANSSI pour la cybersécurité, et le PSNR pour les systèmes nationaux. La tension caractéristique est de nature R↔A : la lecture du corpus est conduite par les services techniques, tandis que la responsabilité politique est portée par l’élu ou l’autorité ministérielle, sans que les deux niveaux soient structurellement articulés. Le résultat typique est un déploiement où la lecture normative est active mais la chaîne de responsabilité diffuse, ou l’inverse. La Tension de disjonction politique est l’objet qui nomme cette configuration.
Le corpus combine IEC 62443 pour la cybersécurité industrielle, ISO 27001 pour les systèmes de management de l’information, la directive CER (Critical Entities Resilience) pour la résilience des entités critiques, l’AI Act pour les systèmes d’IA à haut risque qui supportent l’opération, et IEC 61508 pour la sécurité fonctionnelle. La tension caractéristique est de nature I↔S : l’interopérabilité, qui est une exigence d’efficacité opérationnelle, devient en environnement de criticité un vecteur de défaillance lorsque la qualification des sources entrantes est sous-instruite. La Tension d’interopérabilité critique est l’objet qui nomme cette configuration. C’est la tension caractéristique des grands incidents par cascade dans les infrastructures de transport, d’énergie, et de télécommunications.
Le corpus combine ICH E6 R3 pour les bonnes pratiques cliniques, le 21 CFR Part 11 pour les enregistrements et signatures électroniques sous régime FDA, l’AI Act pour les systèmes d’IA à haut risque, la MDR/IVDR pour les dispositifs médicaux et les dispositifs de diagnostic in vitro, et le RGPD. La tension caractéristique est de nature R↔S : la validation scientifique au sens de la recherche clinique, fondée sur le contrôle prospectif et l’analyse pré-spécifiée, entre en divergence avec la conformité réglementaire au sens de l’AI Act, qui exige une justification continue de la performance en condition d’usage. La Tension de validation dédoublée est l’objet qui nomme cette configuration. Elle se distingue de la Tension d’explicabilité contestée du secteur Healthcare en ce qu’elle porte non sur le destinataire de l’explication mais sur le statut épistémique de la preuve de performance.
Une doctrine qui n’énonce pas ses limites n’est pas une doctrine. Cette section liste cinq limites structurelles de RAISE, formulées par leur auteur dans les termes les plus défavorables au framework lui-même. Elles ne sont pas des invitations à la prudence rhétorique ; elles définissent les conditions sous lesquelles le framework cesse d’être utile.
Le framework fournit une grammaire d’architecture qui rend la conformité gouvernable par construction. Il ne fournit pas la métrique qui permettrait de calculer le degré de conformité atteint, ni le seuil au-delà duquel la conformité est acquise. Cette quantification reste sectorielle, et elle relève des grilles d’évaluation propres à chaque secteur (HAS pour la santé, EBA pour la finance, autorité d’emploi pour la défense). Une organisation qui chercherait dans RAISE le calcul d’un score de conformité ferait fausse route ; elle devrait chercher dans RAISE la grammaire qui rend ce score, lorsqu’il existe sectoriellement, calculable de manière non triviale.
L’application du framework, en particulier des piliers R et E, exige une équipe d’architecture capable de conduire la lecture active des textes normatifs applicables, et de dériver les contraintes de conception qui en découlent. Cette compétence existe, mais elle est rare, et elle est concentrée dans des fonctions qui ne sont pas, dans la plupart des organisations, structurellement intégrées à la conception des systèmes. Le framework ne crée pas cette compétence ; il en présuppose la disponibilité. Une organisation qui ne dispose pas de cette compétence ne peut pas appliquer RAISE par mimétisme documentaire ; elle doit d’abord constituer la compétence ou en externaliser la fonction sous un régime contractuel qui ne soit pas celui de l’outsourcing standard.
Le pilier S adresse la safety opérationnelle au sens de la fiabilité et de la robustesse du système. Il n’adresse pas, ou n’adresse qu’incidemment, la sécurité cyber au sens des cadres NIS2, IEC 62443, ISO 27001. Ces cadres sont orthogonaux par objet à RAISE : ils traitent des conditions de protection du système contre les menaces externes intentionnelles, là où RAISE traite des conditions de gouvernabilité de ses décisions automatisées.
Cette orthogonalité d’objet n’implique pas l’indépendance d’incident. Dès qu’une compromission cyber peut altérer une décision automatisée du système, l’orthogonalité par objet est doublée d’un couplage par incident. La compromission d’une source entrante (pilier I), d’une chaîne d’interprétation (pilier E), ou d’un protocole de validation (pilier S) transforme un cadre de protection externe en facteur d’altération de la gouvernabilité interne. RAISE et le cadre cyber applicable sont donc orthogonaux par objet et couplés par incident. Le couplage par incident exige que la gouvernance composite des cinq piliers intègre, dans son périmètre de surveillance, les incidents cyber comme déclencheurs d’un test de propagation au sens du §6.6.
Le framework ne propose pas l’articulation détaillée des deux cadres parce qu’elle relève d’un travail doctrinal distinct, à conduire dans une publication ultérieure ; il signale en revanche que cette articulation est, dans la pratique des déploiements en environnement régulé, non négociable.
La matrice du chapitre 5 énonce que les dix paires non-identité entre les cinq piliers admettent toutes une dépendance non-nulle. Cet énoncé est un modèle d’analyse, falsifiable par contre-exemple qualitatif sur un cas concret, mais il ne constitue pas une démonstration formelle au sens mathématique. La typologie ternaire des dépendances (possibilité, validité, légitimité) est elle-même une décision doctrinale qui pourrait être discutée. Le framework ne prétend pas à la robustesse logique d’un théorème ; il prétend à l’utilité diagnostique d’un cadre d’analyse. Cette prétention plus modeste est, dans le domaine des cadres de gouvernance, déjà ambitieuse.
Le framework est conçu pour opérer au niveau où le législateur européen a choisi d’opérer, c’est-à-dire au niveau de la conception du système. Son application dans des juridictions hors UE (FDA aux États-Unis, MHRA au Royaume-Uni, CFDA en Chine, autorités sectorielles dans d’autres juridictions) demande un travail de transposition que ce document n’effectue pas. La transposition n’est pas une simple traduction de termes ; elle exige de qualifier, juridiction par juridiction, ce que les autorités de tutelle considèrent comme conforme, et de réviser certains piliers à la lumière de ces qualifications. Le framework reste mobilisable hors UE ; sa pleine valeur opérationnelle y est conditionnée à un travail d’adaptation que les organisations multinationales devront conduire pour leur propre périmètre.
Le framework structure la gouvernabilité du système en environnement régulé. Il ne fournit pas, en l’état, l’instrumentation d’arbitrage entre coût, délai et risque qui détermine, dans la pratique industrielle, quel niveau de gouvernabilité est économiquement soutenable. Cette absence n’est pas un oubli ; elle est une décision méthodologique cohérente avec la délimitation du §2 et avec l’exclusion de la dimension économique de la typologie ternaire de la matrice §5. La gouvernabilité au sens de RAISE est une condition de possibilité du déploiement, pas une variable d’optimisation. Une organisation qui chercherait dans RAISE une fonction d’arbitrage portfolio entre conformité et coût marginal ne la trouverait pas.
Cette limite est la plus immédiatement visible dans la pratique COMEX. Tout arbitrage industriel réintroduit la dimension économique au moment de l’allocation des ressources, et le framework est silencieux sur cette réintroduction. La compatibilité entre RAISE et la rationalité économique du COMEX dépend donc d’une articulation externe, à conduire par l’organisation elle-même ou par un instrument doctrinal complémentaire. La construction de cet instrument est explicitement signalée comme l’une des conditions d’évolution du cadre dans son chapitre §11. Sans elle, RAISE reste intellectuellement supérieur dans le diagnostic mais opérationnellement contournable dans l’arbitrage.
L’absence de dimension économique dans le framework appelle un argument de positionnement qui dépasse la simple reconnaissance de la limite. Cet argument se formule comme modèle de seuil, à instruire au cas par cas par l’organisation, mais dont la forme générale est défendable ici.
Soit C la criticité d’un déploiement, mesurée par la combinaison de quatre facteurs : exposition réglementaire (classe AI Act, classe MDR, classe DORA, classe sectorielle pertinente) ; sévérité du dommage potentiel (corporel, financier, réputationnel) en cas de défaillance ; volume et fréquence des décisions automatisées prises par le système ; degré d’environnement adversarial (intentionnalité hostile possible). Le modèle énonce qu’il existe un seuil C* au-dessus duquel le coût attendu d’un déploiement non-RAISE-aligned, sur l’horizon de vie du système, dépasse le coût d’un déploiement RAISE-aligned, et au-dessous duquel l’inverse est vrai.
L’asymétrie qui détermine C* tient à trois mécanismes. Premier mécanisme : le coût marginal d’une régression réglementaire (au sens de §7.3) augmente plus que linéairement avec la criticité, parce qu’une régression sur un système à fort impact déclenche des chaînes d’investigations, des rappels, et des contestations contractuelles qu’un système à faible impact ne déclenche pas. Deuxième mécanisme : la valeur informationnelle de la traçabilité ontologique (Annexe A) croît avec la criticité, parce que la capacité à reconstruire ex post une décision contestée détermine l’opposabilité de la défense de l’organisation. Troisième mécanisme : les coûts de litige et de conformité réactive croissent eux-mêmes plus que linéairement avec la criticité, parce qu’ils attirent l’attention du régulateur et de la presse spécialisée.
Sous ces trois mécanismes, le coût total attendu d’un déploiement non-RAISE est dominé par le coût total attendu d’un déploiement RAISE au-delà de C*. C’est-à-dire qu’au-delà de ce seuil, RAISE n’est pas une amélioration optionnelle mais une stratégie économiquement rationnelle, comparée à l’alternative. Au-dessous de C*, l’inverse est vrai : la mise en œuvre de RAISE produit un coût marginal qu’aucun gain de gouvernabilité ne compense.
Le modèle est intentionnellement asymétrique : il ne prétend pas que RAISE est universellement applicable, mais que sa pertinence est conditionnée à la criticité du déploiement. Cette précision est essentielle pour le COMEX, qui ne peut pas adopter un cadre qui ignore ses contraintes d’arbitrage portfolio.
Le modèle de seuil C* tel qu’énoncé ci-dessus est conditionné. Trois conditions de validité doivent être nommées explicitement pour éviter qu’il ne soit interprété comme universel. Première condition : le système doit présenter un volume décisionnel suffisant pour que le coût marginal de la traçabilité, de l’explicabilité et de la validation soit absorbable par effet de masse. Pour un système traitant peu de décisions par unité de temps, l’investissement RAISE peut être économiquement non justifié indépendamment de la criticité unitaire. Deuxième condition : l’exécution doit être largement automatisée. Pour un système où la décision finale repose systématiquement sur un opérateur humain disposant d’un override effectif, le coût attendu de défaillance du système est borné par le coût du contrôle humain, ce qui décale le seuil C* vers le haut et peut le rendre inatteignable dans la pratique. Troisième condition : l’exposition litigieuse et réglementaire doit être significative. Pour un système opérant dans un secteur à faible exposition (par exemple recommandation produit non-régulée), les coûts de régression et de litige restent linéaires ou sublinéaires, et le seuil C* peut ne pas être atteint à la criticité observable.
Sous ces trois conditions conjointes, le modèle est défendable et RAISE devient économiquement dominant au-delà du seuil identifiable. Précision épistémique : le modèle énonce une asymétrie logique des coûts attendus, dérivée des trois mécanismes décrits qualitativement. Il ne fournit pas les données de coût réel par secteur ni la valeur calculée de C* dans un déploiement observé. La transformation de l’asymétrie logique en mesure empirique relève d’un travail économétrique distinct, à conduire par secteur et par classe de criticité. Hors de ces conditions, RAISE reste utile comme grille diagnostique sans être économiquement dominant. Cette précision n’affaiblit pas le framework ; elle en délimite le périmètre d’application optimal et explique pourquoi son adoption est sectoriellement asymétrique : forte en santé, en finance régulée et en défense, plus faible en commerce de détail, contenu généraliste et services à faible exposition réglementaire. Le seuil C* lui-même n’est pas calculé ici ; sa détermination relève de l’organisation, de son secteur et de la satisfaction des trois conditions de validité ci-dessus. La fonction de cette section est de revendiquer que l’arbitrage existe, qu’il est non trivial, qu’il est conditionné, et que RAISE devient économiquement dominant au-delà d’un seuil identifiable plutôt que d’être présenté comme universellement préférable. Cette concession stratégique renforce la défendabilité du framework au lieu de la diminuer.
Trois axes d’évolution du champ sont identifiables à la date de cette publication. Le framework est conçu pour les absorber sans changement structurel ; cette robustesse est, en soi, un test de la pertinence de sa conception.
Le premier axe est la diffusion opérationnelle progressive de la norme ISO/IEC 42005:2025 sur l’évaluation d’impact des systèmes d’IA. Cette norme, publiée en 2025 et complémentaire d’ISO/IEC 42001, fournit une méthodologie d’évaluation que RAISE peut intégrer comme outil dans le pilier R sans modifier sa structure de cinq piliers.
Le deuxième axe est l’évolution du Code of Practice de l’AI Act, qui précise par actes successifs les obligations applicables aux modèles d’IA à usage général. Chaque évolution du Code constitue une évolution du corpus normatif lu activement par le pilier R. Les organisations matures la traiteront comme un signal de régression contrôlée au sens du chapitre 7, plutôt que comme une perturbation à absorber sans relecture.
Le troisième axe est la montée en puissance de l’AI Office européen et des autorités nationales désignées. Ces autorités produiront, par leurs décisions, leurs guidelines et leur jurisprudence administrative, le matériau d’interprétation qui rendra le corpus AI Act effectivement opérationnel. Le pilier R intégrera ces productions comme part vivante du corpus normatif, sans que cela exige une révision du framework.
Les questions qui suivent sont celles que la pratique de présentation du framework a fait remonter avec une régularité suffisante pour mériter un traitement écrit. Elles sont posées dans leur forme la plus directe, et traitées sans esquive.
Parce que NIST AI RMF est un cadre de gestion du risque, dont la fonction est d’identifier, mesurer et gérer les risques liés au déploiement d’un système d’IA existant. RAISE est un cadre d’architecture, dont la fonction est de structurer la conception du système pour qu’il soit gouvernable par construction. Les deux cadres ne sont pas en concurrence. Une organisation peut, et souvent doit, utiliser les deux : RAISE en amont pour la conception, NIST RMF en aval pour la gestion du risque opérationnel.
Non. La certification présuppose un référentiel adopté par un organisme de normalisation reconnu, un schéma de certification, et un corps d’auditeurs qualifiés. RAISE est une doctrine produite par un acteur unique. Sa robustesse repose sur la défendabilité publique de ses énoncés, pas sur l’autorité d’un schéma de certification. Une organisation peut revendiquer un déploiement RAISE-aligned, mais cette revendication est doctrinale, pas certifiée. Pour la certification, ISO/IEC 42001 est l’instrument approprié, qui s’articule avec RAISE plutôt qu’il ne s’y substitue.
ISO 13485 manage la qualité d’une organisation qui fabrique des dispositifs médicaux. Elle structure les processus, les rôles, la documentation. RAISE structure la conception d’un système d’IA en environnement régulé. Les deux ne traitent pas le même objet. Un fabricant de dispositif médical à base d’IA mobilise typiquement les deux : ISO 13485 pour son système qualité, RAISE pour la conception architecturale du dispositif d’IA lui-même.
Oui, sans modification structurelle. Les cinq piliers s’instancient dans le cas des LLMs et des systèmes agentiques avec une saillance accrue de certains piliers (E pour l’explicabilité décisionnelle, A pour la responsabilité dans les chaînes d’action automatisées) et l’apparition d’objets architecturaux propres (politiques de prompt, mécanismes de mémoire persistante, contrats d’outil dans les architectures agentiques). Le framework absorbe ces spécificités comme instanciations de ses piliers, plutôt que comme exceptions.
Non. SHAP, comme LIME, comme attention maps, est un outil d’interprétation technique. Le pilier E exige une explicabilité décisionnelle qualifiée par destinataire, par cadre d’usage, et par protocole de production, conçue en amont de la conception du modèle plutôt qu’ajoutée en aval. SHAP peut être l’un des moyens techniques mobilisés dans cette explicabilité ; il n’en est ni la définition, ni la condition de suffisance.
Non. Le classement de l’AI Act qualifie un système au regard d’obligations légales. RAISE structure la conception du système au regard de ces obligations et d’autres exigences sectorielles. Le classement est un input du pilier R, pas un substitut au framework. Un système qualifié à haut risque par l’AI Act peut être plus ou moins gouvernable par construction selon que son architecture est ou n’est pas RAISE-aligned ; le classement, à lui seul, ne tranche rien sur cette gouvernabilité.
La question, posée dans ces termes, attend une réponse qu’aucun cadre d’architecture ne peut donner. Le coût dépend du périmètre, de la maturité de départ, de la disponibilité d’expertise transverse, et de la criticité du secteur. Une fourchette indicative, pour un déploiement complet allant du diagnostic à la maintenance opérationnelle (niveaux 1 à 4 du chapitre 7), s’étend typiquement de plusieurs centaines de milliers d’euros pour un périmètre limité dans un secteur mature, à plusieurs millions pour un périmètre complexe en secteur hautement régulé. Le coût de non-déploiement, lorsqu’il devient mesurable, est presque toujours supérieur ; cette asymétrie n’est pas un argument de vente, c’est une observation.
Partiellement. La rétro-application est conduite typiquement comme un diagnostic au sens du niveau 1 du chapitre 7, qui produit la cartographie des écarts. La fermeture de ces écarts demande, dans le cas le plus favorable, un travail de gouvernance et de documentation ; dans le cas le moins favorable, un retour à l’architecture qui équivaut à une refonte. La distinction entre les deux cas dépend de la profondeur des décisions de conception qui ont été prises sans contrainte de gouvernabilité. Un système conçu sous l’anti-pattern de la conformité par avenant n’est pas, en pratique, rendu RAISE-aligned par documentation ; il est rendu RAISE-aligned par re-conception partielle ou totale.
RAISE n’est pas un cadre de conformité. C’est un cadre d’architecture qui rend la conformité concevable, vérifiable et opposable. Il ne remplace ni NIST AI RMF, ni ISO/IEC 42001, ni l’AI Act, ni les grilles sectorielles. Il définit l’ordre dans lequel ces instruments doivent entrer dans la conception pour éviter qu’ils ne deviennent de la documentation décorative.
Les cinq piliers de RAISE, leur matrice d’interdépendances qualifiée par tests diagnostiques, leurs huit anti-patterns canoniques avec leurs corrections architecturales minimales, leur modèle de maturité avec dimension de régression contrôlée, leurs trois instanciations sectorielles principales sous tension caractéristique nommée, et les cinq refus qu’ils rendent défendables, forment l’architecture doctrinale du cadre. Le critère de réfutation introduit en note méthodologique en fixe les conditions d’application sérieuse.
Trois formules condensent ce que les cinq piliers, 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 d’IA n’est pas régulé parce qu’on l’a documenté. Il est régulé parce que sa conception rend la documentation possible.
Ces trois phrases ferment la boucle ouverte au préambule. Elles énoncent, dans leurs formes les plus dépouillées, le test que tout déploiement RAISE-aligned devra réussir.
Le tableau ci-dessous liste les sources réglementaires primaires mobilisées dans le présent document. Il ne se substitue pas à un dossier de conformité ; il sert d’index de citation.
| Secteur | Sources primaires |
|---|---|
| Transversal | Règlement UE 2024/1689 (AI Act), Règlement UE 2016/679 (RGPD), ISO/IEC 42001:2023, NIST AI RMF 1.0 (2023) |
| Healthcare et Life Sciences | Règlement UE 2017/745 (MDR), Règlement UE 2017/746 (IVDR), AI Act article 6 (classification haut risque) et article 86 (droit à explication), Annexe XIV MDR (évaluation clinique), ISO 14155 et ICH E6 R3 (bonnes pratiques cliniques), HL7 FHIR R5 (interopérabilité), HDS (référentiel français), Règlement UE 2025/327 (EHDS, Espace européen des données de santé, dont les délais d’application sectorielle s’échelonnent à compter de la publication ; à vérifier en relecture finale selon la date de mise sous presse) |
| Finance et Assurance | Règlement UE 2022/2554 (DORA), Directive 2014/65/UE (MiFID II), Directive 2009/138/CE (Solvency II), Comité de Bâle (Bâle III), EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02), RGPD article 22 et considérant 71, CJUE C-634/21 (SCHUFA, arrêt du 7 décembre 2023) |
| Défense et Sécurité nationale | AI Act article 2(3) (exclusion défense et sécurité nationale), Règlement UE 2021/821 (biens à double usage), STANAG OTAN, IGI 1300 (Instruction générale interministérielle, France), II 901 (Instruction interministérielle, France), référentiels ANSSI/PAMS, Protocoles additionnels I et II (1977) aux Conventions de Genève (1949) |
| Secteur public et administrations | RGS v2 (Référentiel Général de Sécurité), RGPD, référentiels ANSSI, PSNR (Politique de Sécurité des Systèmes d’Information de l’État), DORA pour services financiers publics |
| Infrastructures critiques | IEC 62443, ISO/IEC 27001:2022, Directive UE 2022/2557 (CER, Critical Entities Resilience), Directive UE 2022/2555 (NIS2), IEC 61508, AI Act |
| Recherche clinique et Biotech | ICH E6 R3 (bonnes pratiques cliniques), 21 CFR Part 11 (FDA, électronique), MDR/IVDR, AI Act, RGPD |
Note d’éditorial pour la finalisation. Cette annexe consolide les références primaires mobilisées dans le document. Avant publication finale, une vérification éditoriale est recommandée sur trois points : la version effective des règlements à la date de publication (notamment la consolidation du RGPD et les actes délégués AI Act publiés depuis 2024) ; la cohérence entre l’article 86 de l’AI Act et les régimes sectoriels (notamment la MDR et le RGPD article 22) ; la disponibilité des références jurisprudentielles plus récentes que SCHUFA (CJUE et Conseil d’État français notamment). Cette vérification ne porte pas sur l’exactitude des références listées, mais sur leur stabilité à la date de mise sous presse.
Le tableau ci-dessous propose le mapping entre les piliers de RAISE et les articles publiés ou en préparation du corpus doctrinal Twingital Institute. Les références marquées comme à formaliser correspondent à des articles dont la rédaction est engagée mais non encore publiée ; elles sont signalées comme telles pour transparence et seront mises à jour à chaque publication.
| Pilier | Articles Twingital de référence |
|---|---|
| R, Regulatory Architecture | Collision ontologique MDR/AI Act [à formaliser]. Apprendre ce qui ne peut pas varier [à formaliser]. |
| A, Accountability and Governance | Architecture hexagonale comme condition de gouvernabilité [à formaliser]. |
| I, Interoperability Standards | Contractualised promotion port [à formaliser]. |
| S, Safety and Operational Validation | Les benchmarks publics ont perdu le droit de décider seuls [à formaliser]. |
| E, Explainability and Ethics | Bayésien et crédibilité réglementaire [à formaliser]. Apprendre ce qui ne peut pas varier [à formaliser]. |
Référence interne. TI-2026-FRMK-RAISE-v1.0.
Auteur. Jérôme Vetillard, Twingital Institute.
Statut de propriété intellectuelle. Le présent document est protégé par réservation intégrale, et une enveloppe Soleau a été déposée à l’INPI en parallèle de la publication, pour datation certaine de l’antériorité de la formulation. Les objets doctrinaux nominalement identifiés dans le document (matrice 5×5 d’interdépendances, huit anti-patterns canoniques et leurs quatre extensions de second ordre, modèle de maturité à quatre niveaux avec dimension de régression, six tensions sectorielles caractéristiques, transformations irréductibles T1 à T5, modèle de seuil de criticité C*) sont datés par ce dépôt comme formulation et articulation originales propres au corpus Twingital Institute. Le dépôt protège la trace d’antériorité de cette formulation ; il n’est ni revendication d’appropriation des concepts généraux préexistants, ni opposition à leur usage par des tiers dans des cadres concurrents.
Conditions de citation. La citation du document est autorisée jusqu’à 200 mots cumulés par publication tierce, sous condition d’attribution complète comportant le titre, l’auteur, la référence interne et la date. La reproduction intégrale, partielle au-delà de 200 mots, ou la reformulation substantielle des objets doctrinaux nommés, est soumise à autorisation préalable écrite. L’usage commercial du document ou de ses objets doctrinaux nommés est soumis à licence.
Diffusion. Le présent document est délivré sur inscription nominative et logging. Chaque exemplaire porte un watermark nominatif (« Document remis à [Prénom Nom, Organisation] le [date] »). La page web RAISE associée, sous licence CC-BY-NC-ND, expose la genèse et l’énoncé des cinq piliers ; elle ne contient ni la matrice 5×5, ni les anti-patterns, ni les tensions sectorielles, qui sont exclusifs au présent PDF.
Historique des versions.
| Version | Date | Modification |
|---|---|---|
| v1.0 | 2026-05-XX | Version initiale, dépôt Soleau et publication conjoints. |
| v5.0 | 2026-05-05 | Brouillon assemblé après quatre cycles de relecture (CTO/académique x 4). Pas encore passé en pipeline reviewers automatiques. |
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