Le réseau hospitalier exploitait vingt-trois sites, quatre fournisseurs d'IA clinique, et onze listes de contrôle d'accès. Chaque nouveau modèle signifiait une nouvelle réunion d'intégration. Chaque revue réglementaire signifiait un nouveau tableur. Le Zone Builder a remplacé tout cela par un seul régime, évalué face à chaque acte.

Le Problème Opérationnel

La pile d'IA clinique du groupe hospitalier n'avait rien d'inhabituel pour une institution de cette taille. Des modèles de diagnostic tournaient en radiologie, du triage oncologique tournait en anatomopathologie, de l'inférence d'ordonnancement tournait en opérations, et un outil de documentation assisté par LLM tournait en soins primaires. Chaque modèle provenait d'un fournisseur différent, était hébergé sur une infrastructure différente, et était régi par une politique d'accès distincte — rédigée par une équipe différente, selon un calendrier différent.

Cela a produit les symptômes habituels :

  • → Les données inter-départements se comportaient comme un jeu de données unique, mais aucune règle unique ne s'y appliquait. L'accès d'inférence d'un radiologue ne se transférait pas en oncologie ; une règle de triage oncologique ne couvrait pas l'ordonnancement ; rien ne les reliait.
  • → La supervision des workflows d'IA retombait sur des tableurs. Chaque réunion de comité de revue s'ouvrait avec un support de slides qui dérivait à nouveau ce qui était déployé, où, et sous l'autorité de qui. La dérive n'était pas l'exception ; c'était l'état stable.
  • → La résidence des données par juridiction était appliquée par site via des runbooks par équipe. Un site pouvait exécuter un modèle dans le pays ; un autre router via un cloud qui n'avait pas été approuvé par le délégué à la protection des données.
  • → Le journal d'audit pour l'IA clinique était une préoccupation séparée du contrôle d'accès — et du règlement financier. Quand quelque chose tournait mal, l'institution ouvrait trois enquêtes : une pour les données, une pour le modèle, une pour qui avait payé qui.
  • → Les conversations de conformité multi-parties prenantes se répétaient chaque trimestre. Chaque contrat fournisseur, chaque revue IRB, chaque comité d'audit interne re-litigeait le même graphe d'autorité.

C'est la forme du problème pour lequel les Zone Builders existent : non pas un seul workflow, non pas un seul site, mais un régime qui couvre les acteurs institutionnels, les frontières juridictionnelles et les portes de revue clinique.

Là Où le Modèle Zone/Régime S'applique

Une Zone Axone est un régime normatif — un ensemble borné de faits et de règles, écrit en Prolog, qui décide quels actes deviennent opposables à l'intérieur. Un Régime Axone est le système de règles lui-même : rôles d'acteurs, exigences d'évidence, paiements, interdictions, portes de revue, et résolution de conflits.

Pour un opérateur de santé, cette distinction recoupe clairement le vocabulaire institutionnel existant :

  • → Une seule Zone englobant les workflows d'IA clinique multi-sites. Chaque acte — chaque invocation de modèle, chaque accès aux données, chaque règlement — est évalué face au même régime. Les sites et les fournisseurs ne dérivent pas ; ils sont membres d'un seul régime.
  • → Rôles opérateur / responsable de traitement / sous-traitant déclarés une seule fois. La structure tripartite du RGPD devient trois prédicats dans le régime. Les fournisseurs ne peuvent pas usurper l'opérateur ; les sites ne peuvent pas usurper le responsable de traitement.
  • → Routage d'inférence par juridiction encodé comme une règle, pas un runbook. Un appel de modèle depuis site_a routé vers une tour d'hébergement dans la mauvaise juridiction ne devient tout simplement pas opposable — c'est un acte non enregistré sous le régime.
  • → RBAC pour cliniciens exprimé sous forme de prédicats de rôle. Un radiologue peut appeler un modèle de diagnostic ; un planificateur ne le peut pas — non pas parce qu'un ACL le dit, mais parce que le régime le dit. La même règle voyage avec l'acte.
  • → Portes de revue de type IRB comme préconditions d'opposabilité. Un acte lié à un nouveau modèle n'est qualifié que si un acte de signature du comité de revue le précède. L'inférence ne peut pas dépasser l'approbation.
  • → Journalisation d'actes de qualité audit sur la Layer 1. Chaque acte engagé est un fait enregistré on-chain — horodaté, attribuable au rôle qui l'a qualifié, et révisable sans rejoindre le portail d'audit d'un fournisseur.

Le Zone Builder est la couche qui transforme cela en quelque chose qu'une équipe d'ingénierie clinique peut livrer : un artefact typé, versionné, paramétrable, reproductible.

Parcours d'un Régime Prolog

Ci-dessous une tranche anonymisée du régime qu'exécute le groupe hospitalier. Les rôles ne sont pas des substituts pour des institutions réelles — ce sont des identifiants anonymes, volontairement conçus pour montrer comment les types abstraits s'emboîtent. Aucune donnée de site, aucune donnée patient, aucune métadonnée de fournisseur.

prolog · Régime de Zone Santé — IA Clinique Multi-Sites 
% ============================================================
% RÉGIME DE ZONE SANTÉ — IA CLINIQUE MULTI-SITES (ANONYMISÉ)
% ============================================================

% ---------- RÔLES (opérateur / responsable / sous-traitant par site) ----------

actor(site_a,           controller).
actor(site_b,           processor).
actor(site_c,           processor).
actor(clinical_leadership, operator).
actor(review_board,     arbiter).

% ---------- RBAC : quel rôle peut appeler quel modèle ----------

role_eligible(controller,  diagnostic_inference).
role_eligible(operator,     triage_routing).
role_eligible(processor,   scheduling_inference).
role_blocked(processor,    diagnostic_inference).

% ---------- Juridictions : résidence des données par site ----------

jurisdiction_of(site_a,  region_alpha).
jurisdiction_of(site_b,  region_beta).
jurisdiction_of(site_c,  region_alpha).

jurisdiction_approved(region_alpha, tower_eu_1).
jurisdiction_approved(region_beta,  tower_eu_2).

% ---------- Quotas : borner le volume d'inférence de chaque site ----------

quota(site_a, diagnostic_inference, 40).
quota(site_b, scheduling_inference, 120).
quota(site_c, scheduling_inference, 80).

% ---------- Quorum de ratification par le comité de revue ----------

quorum_required(new_model_signoff, 3).

% ============================================================
% ---------- RÈGLES — ce qui rend un acte opposable ----------
% ============================================================

% Règle 1 : une inférence clinique est qualifiée si l'acteur est éligible,
%          autorisé par la juridiction, et sous quota.

qualified(Site, infer(Model), Tower) :-
    actor(Site, Role),
    role_eligible(Role, Model),
    jurisdiction_of(Site, Reg),
    jurisdiction_approved(Reg, Tower),
    quota(Site, Model, Q),
    Q > 0.

% Règle 2 : un nouveau modèle devient appelable seulement après une
%          ratification du comité.

model_cleared(Model) :-
    act_committed(_, ratify(Model), _),
    ratification_count(new_model_signoff, N),
    N >= 3.

% Règle 3 : opposabilité — chaque appel d'inférence qualifié est opposable
%          (contestable, audit-able, avec effet).

opposable(infer(Model), Site, Tower) :-
    qualified(Site, infer(Model), Tower),
    model_cleared(Model).

% ---------- EFFET — ce que produit un acte opposable ----------

effect(infer(Model), Site, logged(Site, Model, Tower)) :-
    opposable(infer(Model), Site, Tower).

% ---------- REQUÊTES (inférence) ----------

% ?- opposable(infer(diagnostic_inference), site_a, Tower).
% Tower = tower_eu_1     -- seule la tour dans la juridiction qualifie.

% ?- opposable(infer(diagnostic_inference), site_b, Tower).
% false                  -- site_b est sous-traitant, bloqué sur le diagnostic.

% ?- effect(infer(diagnostic_inference), site_a, E).
% E = logged(site_a, diagnostic_inference, tower_eu_1).

Le régime est le protocole. Il n'y a pas de « couche de contrôle d'accès » séparée à garder synchronisée avec l'inventaire des modèles ; il n'y a pas de « journal d'audit » séparé à recroiser avec le système de facturation. La même logique qui qualifie un acte qualifie aussi son effet, et c'est cette même logique que la direction de l'hôpital, le comité IRB, le DPD et le comité d'audit lisent tous.

Résultat : Une Zone, Un Régime, Un Journal d'Audit

Le déploiement du groupe hospitalier a consolidé quatorze surfaces de gouvernance fragmentées en une seule Zone Axone. Le résultat, présenté en termes agrégés plutôt que sous forme de témoignage nommé :

  • → Un seul régime remplace la gouvernance par site. De nouveaux sites rejoignent la même Zone ; de nouveaux modèles passent la même règle ; de nouvelles juridictions ajoutent des prédicats plutôt que de nouveaux tableurs.
  • → Actes opposables. Chaque inférence clinique qualifiée est contestable et audit-able. Un clinicien ou un régulateur peut soumettre un acte-contre face à une inférence journalisée, et le régime détermine le chemin de résolution — sans ouvrir de ticket fournisseur.
  • → Règlement de type Pactum quand un SLA spécifique à une région est violé : un site manque un seuil de quota, un sous-traitant dépasse une juridiction, un fournisseur est en retard sur une ratification — tout cela devient un événement payable dont le règlement s'exécute face au régime, avec conséquences réputationnelles et financières, en quelques secondes.
  • → Surface de risque réduite. La journalisation de qualité audit est une propriété du type d'acte, pas une plateforme séparée. Les cycles de revue qui s'étendaient entre départements se clôturent désormais sur un seul commit Layer 1.
  • → Opérationnellement reproductible. Le Zone Builder transforme le régime en artefact typé et versionné que l'équipe d'ingénierie clinique peut relire, patcher et faire évoluer sans re-litiger le graphe d'autorité.

AxoneOS n'a pas promis à l'institution un miracle. Il a promis — et livré — que l'inférence qui tourne au bloc opératoire le mardi est régie par les mêmes règles que l'inférence qui tourne à la consultation externe le vendredi. C'est le seuil qu'une institution franchit quand ses opérations d'IA cessent d'être une constellation de pilotes et deviennent un service gouverné.

Ce Que les Zone Builders Signifient Pour la Suite

La santé est le secteur le plus chargé en régulateurs dans lequel une Zone Axone tournera plausiblement. Si un régime peut survivre à un IRB clinique, à une autorité de protection des données, et à un comité d'audit interne lisant le même fichier Prolog — chaque autre déploiement institutionnel en devient plus facile. Le Zone Builder est la couche qui rend cela possible à l'échelle : un artefact typé, versionné et paramétrable qu'une équipe d'ingénierie institutionnelle peut livrer et réviser. L'étude de cas ci-dessus est anonymisée pour une raison — le partenariat est encore en négociation. Mais la forme du résultat n'est pas une prévision. C'est ce qui a déjà été livré.