Le Framework RAISE

Genèse et nécessité

La plupart des cadres existants sur l'IA dans les environnements régulés traitent la conformité comme une contrainte externe, quelque chose qu'on ajoute après coup pour satisfaire un régulateur, obtenir une certification ou répondre à un audit. RAISE part d'un constat inverse.

La conformité qui arrive après la conception n'est pas de la conformité. C'est de la compensation. Et la compensation ne tient pas à l'échelle.

Les systèmes d'IA qui échouent dans les environnements critiques ne sont pas, pour la majorité, des échecs techniques. Ce sont des échecs d'architecture, des systèmes conçus hors contexte, déployés dans des organisations qui n'ont pas été préparées à les absorber, dans des cadres réglementaires qu'ils n'avaient pas anticipés.

RAISE est la réponse structurelle à ce problème. Un cadre qui ne se superpose pas à la conception du système, il en est constitutif.

RAISE et les cadres existants

Une objection prévisible doit être traitée d'emblée : le marché ne manque pas de cadres pour l'IA en environnement régulé. Le NIST AI Risk Management Framework, l'ISO/IEC 42001, le Responsible AI Maturity Model de Microsoft, le règlement européen sur l'IA et les grilles sectorielles spécifiques (HAS pour les dispositifs médicaux, référentiels ANSSI pour les systèmes critiques) couvrent chacun une part du sujet. Pourquoi en proposer un cinquième ?

La réponse tient en une distinction de nature, pas de portée. Ces cadres ne sont pas équivalents entre eux, et aucun n'est de nature architecturale.

Cadre	Nature	Ce qu'il prescrit	Ce qu'il ne capte pas
NIST AI RMF (1.0, 2023)	Cadre de gestion du risque (voluntary)	Quatre fonctions organisationnelles : Govern, Map, Measure, Manage. Catalogue de pratiques pour identifier et traiter les risques liés à un système d'IA.	N'impose aucune décision de conception. Ne traite pas la conformité réglementaire sectorielle. Ne dit rien des contrats d'interopérabilité technique entre systèmes.
ISO/IEC 42001 (2023)	Système de management certifiable (AIMS)	Cycle PDCA appliqué à l'IA. Politique, rôles, registres, revue de direction, amélioration continue.	Cadre de management qualité, pas d'ingénierie. Un système peut être certifié 42001 et structurellement non déployable. La certification atteste du processus, pas de l'objet conçu.
EU AI Act (Règlement (UE) 2024/1689)	Texte normatif	Classification par niveau de risque. Exigences techniques pour les systèmes à haut risque (Articles 9 à 15). Obligations de transparence, de surveillance humaine, de robustesse.	Texte législatif, non méthodologique. Décrit un état exigible, pas le chemin pour l'atteindre. Suppose que l'industriel sait traduire le texte en architecture, ce qui est précisément le point qui échoue.
RAI Maturity Model (Microsoft, 2023)	Modèle de maturité organisationnelle	Cinq niveaux (Latent → Leading) sur des dimensions de gouvernance, culture, outillage. Diagnostic d'état organisationnel.	Maturité organisationnelle ≠ architecture système. Une organisation au niveau Leading peut produire des systèmes structurellement défaillants. L'inverse est aussi possible.
HAS, Grille DM-IA (2024)	Grille d'évaluation sectorielle	Critères d'évaluation pour les dispositifs médicaux à base d'IA en vue d'admission au remboursement.	Sectorielle (santé, France), évaluative (post-conception). Non utilisable en phase d'architecture pour un produit en cours de spécification.
RAISE	Cadre d'architecture	Cinq piliers interdépendants intégrés dans les décisions de conception. Production de contraintes opposables aux choix techniques dès la phase de spécification.	N'est pas un standard de management. N'est pas certifiable en tant que tel. N'est pas un texte normatif. N'est pas une grille d'évaluation post-hoc.

RAISE ne se substitue à aucun de ces cadres. Il les précède. Un système conçu sous RAISE est mieux placé pour satisfaire ISO/IEC 42001, pour passer une évaluation HAS ou pour absorber l'EU AI Act sans réarchitecture, parce que ces cadres décrivent un état exigible que l'architecture RAISE produit comme conséquence, et non comme effort de conformité a posteriori.

Les cadres existants disent ce qu'il faut atteindre. RAISE structure la manière de le concevoir.

Structure du Framework

RAISE est un acronyme opérationnel : chaque lettre désigne un pilier non négociable du déploiement industriel de l'IA. Les cinq piliers sont interdépendants, la défaillance de l'un compromet structurellement les autres.

	Pilier	Description & questions opérationnelles
R	Pilier 1, Regulatory Architecture	Intégration des cadres réglementaires dès la conception du système, pas en phase de validation, pas en réponse à un audit. Lecture active des textes réglementaires applicables (EU AI Act, MDR/IVDR, RGPD, HDS, NIS2…) dès la phase d'architecture, et traduction en contraintes de conception concrètes.
A	Pilier 2, Accountability & Governance	Définition claire des responsabilités à chaque niveau du système, qui décide, qui contrôle, qui répond en cas de défaillance. Gouvernance algorithmique, auditabilité et contrôle institutionnel du risque.
I	Pilier 3, Interoperability Standards	Capacité du système à s'intégrer durablement dans les infrastructures existantes. Traçabilité des données, souveraineté numérique, standards d'interopérabilité (FHIR, HL7, API ouvertes) et continuité des flux d'information.
S	Pilier 4, Safety & Operational Validation	Validation du système dans des conditions opérationnelles réelles. Sécurité d'usage, supervision humaine effective, réversibilité des décisions et protocoles de défaillance.
E	Pilier 5, Explainability & Ethics	Capacité du système à justifier ses décisions de façon intelligible pour les opérateurs, les décideurs et les personnes concernées. Légitimité décisionnelle.

Matrice d'interdépendance

Les cinq piliers ne sont pas indépendants. Leur interdépendance n'est pas un effet secondaire du framework, elle est constitutive. C'est précisément ce qui distingue RAISE d'une checklist de conformité, où chaque ligne peut être validée séparément.

L'interdépendance se déploie sur trois registres : la chaîne constitutive qui ordonne les piliers selon leur priorité de conception, les boucles de rétroaction qui reformulent un pilier amont à la lumière d'un pilier aval, et la matrice complète qui qualifie les vingt dépendances directionnelles entre piliers.

Chaîne constitutive : R → A → I → S → E

L'ordre n'est pas alphabétique. Il est causal.

R → A : la régulation appelle la responsabilité

Un cadre réglementaire intégré dès la conception (R) est inopérant sans une structure de gouvernance qui en assure le respect dans la durée (A). La conformité réglementaire ne se maintient pas seule : elle nécessite des acteurs identifiés, des processus documentés, des responsabilités nommées.

A → I : la gouvernance requiert l'interopérabilité

L'auditabilité (A) n'est possible que si les données sont traçables et les systèmes interopérables (I). Un système opaque sur ses flux de données n'est pas gouverné, il est invoqué.

I → S : l'interopérabilité conditionne la validation

La validation opérationnelle (S) porte sur le système dans son contexte d'utilisation réel, ce qui suppose que les interfaces avec les systèmes adjacents soient stables et documentées (I). Un système validé en isolation n'a été validé que comme prototype.

S → E : la sécurité légitime l'explication

Un système ne peut prétendre à l'explicabilité (E) que s'il a été validé opérationnellement (S). L'explication d'une décision non validée n'est pas de la transparence, c'est de la rationalisation a posteriori.

Boucles de rétroaction

La chaîne constitutive est lisible. Elle est aussi insuffisante. Elle laisse penser que chaque pilier peut être stabilisé une fois pour toutes avant d'aborder le suivant. La pratique architecturale est inverse : trois boucles de rétroaction reformulent les piliers amont à mesure que les piliers aval sont opérés.

E → R : l'explicabilité reformule la lecture réglementaire

Un système qui doit être explicable rend visibles des exigences réglementaires que la lecture initiale du corpus n'avait pas isolées. Le besoin de justifier une décision oblige à requalifier ce qui, dans le texte réglementaire, est exigé d'être justifiable. La lecture du règlement est mise à jour par le travail d'explicabilité, non l'inverse.

S → A : la validation objective la responsabilité

Une responsabilité (A) qui n'est pas adossée à un protocole de validation (S) est déclarative. Tant que la validation opérationnelle n'a pas exposé les modes de défaillance réels du système, la chaîne de responsabilité repose sur des modes de défaillance supposés. La validation est l'opération qui donne corps à la gouvernance.

I → A : l'interopérabilité matérialise la gouvernance

Une gouvernance algorithmique (A) qui ne dispose pas des flux de traçabilité requis (I) ne contrôle pas, elle estime. La gouvernance n'a de prise effective sur le système qu'à proportion de ce que l'interopérabilité expose.

Matrice complète des dépendances

Les paires non couvertes par la chaîne constitutive et les boucles de rétroaction principales se lisent en matrice. Chaque cellule qualifie le sens de la dépendance directionnelle (lignes : pilier source, qui conditionne ; colonnes : pilier cible, qui est conditionné).

	R	A	I	S	E
R	,	condition de possibilité de la gouvernance	détermine les standards d'interopérabilité requis	délimite le périmètre validable	impose le seuil minimal d'explicabilité exigible
A	restitue les exigences contestables au régulateur	,	exige la traçabilité des données et des décisions	qualifie les modes de validation acceptables	atteste la légitimité institutionnelle des explications
I	révèle les lacunes du corpus normatif	rend la gouvernance opérante par flux exposés	,	conditionne le contexte de validation	rend l'explication traçable de bout-en-bout
S	révèle les zones grises du texte réglementaire	objective la chaîne de responsabilité	impose les contrats d'interface réels	,	précède toute prétention explicative
E	reformule la lecture du corpus normatif	matérialise la redevabilité institutionnelle	exige un format de trace lisible	qualifie ce qui est cliniquement ou opérationnellement acceptable	,

Vingt dépendances directionnelles, structurellement non substituables. Une défaillance localisée sur un pilier propage. Cette propagation est la signature opérationnelle de l'architecture : un système qui échoue sur un seul pilier de RAISE n'est pas un système partiellement conforme, c'est un système dont l'industrialisation est structurellement compromise.

Corpus normatifs par secteur

RAISE est un cadre générique, il s'applique à tout environnement critique et régulé. Chaque secteur mobilise un corpus normatif distinct, que RAISE intègre au niveau de chacun de ses piliers.

Anti-patterns

RAISE peut être suivi en façade et trahi en substance. Les huit anti-patterns qui suivent ne sont pas une liste d'erreurs débutantes. Ils sont la forme dégradée la plus fréquente de chaque pilier dans les organisations qui croient le respecter. Chacun a sa logique propre, ses partisans, ses justifications post-hoc. Tous produisent le même résultat : un système qui satisfait les apparences de RAISE sans en porter la fonction.

L'inventaire n'est pas exhaustif et ne le sera jamais : chaque organisation cultive ses propres dégradés. Le pattern commun est la substitution silencieuse d'un signe institutionnel à la fonction qu'il devrait porter. RAISE n'est pas trahi par ignorance. Il est trahi par mimétisme.

Modèle de maturité opérationnel

RAISE n'est pas une checklist de conformité. C'est un cadre d'architecture qui structure les décisions de conception, pas les cases à cocher. Sa mise en œuvre suit quatre niveaux progressifs, chacun défini par ses livrables, ses critères de transition vers le niveau suivant, et une durée typique observée.

Les niveaux ne sont pas séquentiels au sens strict. Le Niveau 3 (Gouvernance) chevauche typiquement le Niveau 2 (Architecture), parce que les structures de pilotage se construisent en parallèle des décisions de conception qu'elles auront à valider. Le Niveau 4 (Maintenance) ne ferme pas la trajectoire : il la rend permanente.

Niveau	Livrables attendus	Critères de transition	Durée typique
1, Diagnostic État du système au regard des cinq piliers	Matrice de couverture initiale (cinq piliers × statut). Cartographie des corpus normatifs applicables. Registre des lacunes structurelles priorisées par impact opérationnel et réglementaire.	Matrice signée par la direction. Lacunes priorisées avec impact estimé. Périmètre du système figé pour la phase suivante.	6 à 10 semaines pour un système de complexité moyenne.
2, Architecture Intégration des contraintes RAISE dans la conception	Architecture Decision Records (ADR) liés aux contraintes RAISE. Schémas d'architecture annotés par pilier. Ports d'admission documentés. Spécifications de traçabilité. Registre des choix technologiques opposés à RAISE et leur justification.	ADR validés en revue d'architecture. Prototypes des chemins critiques opérationnels. Contrats d'interface signés avec les systèmes adjacents.	3 à 9 mois selon l'ampleur du système.
3, Gouvernance Mise en place des structures de pilotage	Charte de gouvernance algorithmique. RACI complète sur les cinq piliers. Comité de validation constitué et opérant. Procédures d'audit interne. Protocoles de défaillance et de réversibilité documentés.	Premier cycle d'audit interne réalisé. Comité opérant en cadence trimestrielle minimum. Procédures de réversibilité testées en conditions de simulation.	4 à 8 mois, en chevauchement partiel du Niveau 2.
4, Maintenance Surveillance continue de la conformité RAISE	Tableau de bord de surveillance multi-piliers. Journal d'incidents et de dérives. Registre des révisions du framework. Rapports périodiques de conformité aux corpus normatifs sectoriels.	Continuité opérationnelle sur 12 mois. Capacité démontrée à absorber une révision réglementaire majeure sans réarchitecture du système. Indicateur de vélocité d'audit stable.	Permanente.

La conformité RAISE n'est pas un état atteint, c'est un régime maintenu. Une organisation qui a franchi le Niveau 4 n'a pas terminé. Elle a commencé à exister sous RAISE.

FAQ doctrinale

Sept questions reviennent fréquemment lorsque RAISE est présenté à des décideurs, architectes ou auditeurs. Elles sont traitées ici dans leur formulation canonique. Les réponses sont volontairement compactes ; les développements complets figurent dans le document de référence.

Pourquoi pas le NIST AI Risk Management Framework ?

Le NIST AI RMF est un cadre de gestion du risque, RAISE est un cadre d'architecture. Cette distinction n'est pas une querelle de mots. Le NIST décrit quatre fonctions organisationnelles, Govern, Map, Measure, Manage, qu'une organisation peut s'approprier sans modifier la conception du système qu'elle déploie. RAISE produit des contraintes opposables aux choix techniques dès la phase de spécification : architecture des données, contrats d'interface, journalisation, supervision humaine, domaines de validité. Une organisation peut être conforme NIST RMF et déployer un système structurellement non gouvernable. RAISE rend ce cas impossible par construction. Les deux cadres sont compatibles : un système conçu sous RAISE satisfait, sans effort additionnel, les fonctions Map, Measure et Manage du NIST. L'inverse n'est pas vrai.

RAISE est-il certifiable ?

Non, et c'est délibéré. Un cadre d'architecture n'est pas un standard de management qualité. La certification ISO 9001 atteste qu'une organisation suit des processus ; la certification ISO 13485 qu'elle gère le cycle de vie d'un dispositif médical ; la certification ISO/IEC 42001 qu'elle pilote ses systèmes d'IA via un Système de Management de l'IA. Aucune ne garantit la qualité architecturale du système produit. RAISE ne certifie pas une organisation, il qualifie un système. Sa preuve de conformité prend la forme d'Architecture Decision Records signés et opposables, pas d'un audit certifié par un organisme tiers. Cette absence de certification est elle-même une position doctrinale : un système qui satisfait RAISE le démontre par sa déployabilité, pas par son badge.

RAISE s'applique-t-il aux LLMs ?

Oui, avec une exigence renforcée sur deux piliers. Le pilier S (validation opérationnelle) devient plus difficile à instancier, parce que la non-déterminisme du modèle rompt la reproductibilité naïve : la validation par frozen holdout ne suffit plus, il faut compléter par des protocoles statistiques sur la stabilité de sortie en distribution. Le pilier E (explicabilité) devient plus impérieux, parce que les explications post-hoc disponibles pour les LLMs (SHAP, attention maps, raisonnement en chaîne) sont structurellement plus faibles que pour les modèles tabulaires : la pratique de contestation effective doit donc s'appuyer sur des dispositifs en amont (prompt versionné, contexte traçable, garde-fous de format) plutôt qu'en aval. Plus largement, le pilier R intègre désormais l'AI Act version 2024 qui qualifie spécifiquement les modèles à usage général et leur applique un régime distinct des systèmes haut risque classiques.

Comment se positionne RAISE par rapport à l'EU AI Act ?

L'EU AI Act est un texte normatif, RAISE est l'architecture qui rend ce texte opérationnellement applicable. L'AI Act décrit, dans ses Articles 9 à 15, les exigences techniques pour les systèmes haut risque : gestion du risque, qualité des données, journalisation, transparence, supervision humaine, robustesse, exactitude, cybersécurité. Il n'indique pas comment ces exigences se traduisent en décisions de conception. RAISE produit cette traduction : pilier S pour la robustesse et la validation, pilier I pour la qualité des données et la cybersécurité, pilier A pour la supervision et la responsabilité, pilier E pour la transparence et l'explicabilité, pilier R pour la lecture croisée elle-même. Une organisation qui déploie un système haut risque sans architecture explicite finit par traduire l'AI Act en checklist post-hoc, ce qui est précisément l'anti-pattern de la conformité par avenant.

L'explicabilité par SHAP suffit-elle au pilier E ?

Non, et c'est l'objet de l'anti-pattern explicabilité décorative documenté plus haut. SHAP, LIME et leurs équivalents produisent une explication technique, une attribution de poids aux features d'entrée. Cette attribution répond à la question « qu'est-ce qui a contribué à la sortie », elle ne répond pas à la question « peut-on contester cette sortie et la faire réviser ». Le pilier E exige une explicabilité située, calibrée sur les questions opérationnelles que l'utilisateur doit pouvoir poser au système. Un clinicien qui consulte une stratification de risque oncologique n'a pas besoin de la liste des SHAP values, il a besoin de pouvoir comparer deux patients similaires classés différemment et de demander une révision lorsque la différence ne lui paraît pas justifiable. SHAP peut faire partie de l'instanciation, il ne peut pas en constituer le tout.

Combien de temps faut-il pour atteindre la maturité RAISE niveau 4 ?

Deux à trois ans dans une organisation existante de taille moyenne, à condition que le sponsor exécutif soit identifié dès le Niveau 1 et que la phase Architecture (Niveau 2) ne soit pas tronquée. Deux paliers concentrent l'essentiel des risques de programme. Le palier Niveau 1 → 2 (Diagnostic → Architecture) échoue typiquement quand la matrice de couverture initiale est traitée comme un livrable de communication plutôt que comme une décision de priorisation : les lacunes sont identifiées sans être hiérarchisées, et l'architecture suivante essaie de tout traiter simultanément. Le palier Niveau 3 → 4 (Gouvernance → Maintenance) échoue quand le comité de validation est constitué mais ne dispose pas du pouvoir d'arrêt : il devient un anti-pattern de gouvernance déclarative. Les organisations qui franchissent ces deux paliers sans bricolage atteignent le Niveau 4 en environ 30 mois.

RAISE est-il français ?

Doctrinalement, RAISE est ancré dans le contexte juridique européen et dans le terrain Healthcare français, c'est sur ce terrain qu'il a été stabilisé, notamment via le programme PREDICARE et l'écosystème Qualees / Twingital Institute. Structurellement, il est transposable : ses cinq piliers opèrent sur des objets régulatoires universels (architecture réglementaire, redevabilité, interopérabilité, validation opérationnelle, explicabilité éthique) qui se rencontrent dans tous les environnements régulés au-delà de la France. Le corpus normatif applicable change selon le pays, FDA et HIPAA aux États-Unis, MHRA et UK GDPR au Royaume-Uni, PMDA au Japon, mais la grammaire des cinq piliers reste invariante. La transposition la moins triviale concerne le pilier R, parce que la lecture croisée des régimes nationaux et fédéraux n'est pas symétrique d'une juridiction à l'autre. Le pilier E pose, lui, des questions transversales que la jurisprudence européenne (arrêt SCHUFA) éclaire mieux que la common law nord-américaine, ce qui rend RAISE peut-être plus exigeant dans son terrain natif que dans ses transpositions.

Document de référence

Le Framework RAISE fait l'objet d'un document de référence complet, architecture détaillée des cinq piliers, grilles d'évaluation par secteur, matrices d'interdépendances et protocoles de mise en œuvre.

Ce document est accessible sur inscription. Il s'adresse aux décideurs, architectes système, responsables conformité et directions générales des organisations déployant de l'IA dans des environnements critiques.

← Retour à l'accueil · Explorer les domaines de travail