Pourquoi le Predetermined Change Control Plan (PCCP) est la forme aboutie d'un artefact que le MLOps généraliste confond encore avec le model registry
Le 14 janvier 2026, la FDA et l’EMA ont publié conjointement dix Guiding Principles of Good AI Practice in Drug Development. Le 2 février 2026, le Quality Management System Regulation américain, aligné sur l’ISO 13485, est entré en vigueur pour les dispositifs médicaux. Entre 2025 et 2027, le régime européen applicable aux modèles d’IA à usage général dans le cadre de l’AI Act entre progressivement dans sa phase d’application opérationnelle.
Ces trois jalons ne relèvent pas du même régime juridique. Les Guiding Principles FDA/EMA encadrent l’usage de l’IA dans le cycle de développement du médicament. Le QMSR encadre les systèmes qualité des dispositifs médicaux. L’AI Act introduit un régime propre aux systèmes d’IA et aux modèles à usage général. Les confondre reviendrait à produire exactement le genre d’homogénéisation réglementaire trompeuse qui sert à paraître conforme sans s’obliger à l’être. La convergence est fonctionnelle, pas juridique.
Cette convergence fonctionnelle est pourtant réelle, et c’est elle qui intéresse l’architecte. Trois régulateurs distincts déplacent la même question centrale : il ne suffit plus de savoir si un modèle fonctionne, ni même s’il a été validé. Il faut pouvoir dire à quelles conditions il peut entrer dans un régime d’usage régulé, selon quelle méthode il peut évoluer, avec quelle traçabilité, sous quelle responsabilité, et dans quelles conditions son admission peut être retirée.
Un des articles précédents avait posé l’architecture hexagonale comme cadre structurel d’un jumeau pharmacovigilance. Il a montré que la séparation entre le noyau métier et ses adaptateurs est la condition pour qu’un système reste auditable, testable, substituable sur ses périphéries. Il n’a pas tranché la question suivante : où, dans cette architecture, se tient l’artefact qui institue le passage en production régulée ? Cette question est l’objet du présent texte.
Ma thèse. Le Predetermined Change Control Plan exigé par la FDA pour les dispositifs médicaux IA est la forme aboutie de ce que je propose de nommer le port de promotion, c’est-à-dire un contrat institué ex ante qui distingue la frontière régulée de l’annuaire versionné. Tant que l’industrialisation IA confondra ce que la régulation des dispositifs médicaux a construit avec le simple model registry qu’elle a outillé, elle restera incapable de franchir durablement le seuil de production régulée.
Domaine de validité. La thèse vaut pour les systèmes IA déployés en production régulée ou candidate à la régulation (santé, finance, défense, automobile, industrie pharmaceutique, agroalimentaire, infrastructures critiques). Elle ne s’applique pas en l’état aux usages internes non-décisionnels (assistants de productivité, tâches documentaires non exposées) où le model registry peut suffire, l’instance de promotion étant alors dégradée. Mais dès qu’un système produit une inférence qui affecte une décision, une priorité, une classification, une investigation, une alerte, une allocation ou une trajectoire humaine, le registry ne suffit plus. Il faut un port.
Trois termes circulent dans la littérature MLOps : registry, port, promotion. Ils sont souvent utilisés comme s’ils appartenaient à une même famille d’opérations techniques. Ils ne le sont pas.
Le model registry est un annuaire versionné. Il enregistre ce qui existe : un modèle, sa version, son lineage d’entraînement, ses métriques de validation, son statut courant (none, staging, production, archived). Il est outillable : MLflow, DVC, Weights & Biases, SageMaker Model Registry, Vertex AI Model Registry en fournissent des implémentations industrielles. Il est dérivé de la discipline DevOps et hérite de ses conventions : une table, des versions, des transitions de statut consignées. Sa fonction est utile, parfois excellente. Le problème n’est pas son existence. Le problème est sa surestimation.
Le port de promotion, concept que je propose dans cet article comme objet doctrinal, est une interface qui contractualise à quelles conditions ce qui existe peut franchir une frontière. Il n’est pas un statut, il est une interface. Il n’enregistre pas le passage, il l’institue. Il répond à une question différente : non pas qu’est-ce qui est en production ? mais qu’est-ce qui a été admis, selon quel contrat, avec quelle clause de révocation ?. Il contient les critères d’entrée, les méthodes de validation, les limites de validité, les conditions de surveillance, les modalités d’évolution autorisée et les conditions de retrait.
La promotion est l’événement par lequel un artefact franchit le port. Ce n’est pas une opération CI/CD, car une opération CI/CD transporte le code et les poids, elle automatise le mouvement. C’est un acte d’institution, qui reconnaît qu’un modèle, à un instant donné et selon des conditions nommées, peut être tenu pour responsable des effets qu’il produira. L’opération est technique, la promotion est institutionnelle. Un modèle peut être déployé techniquement sans être promu institutionnellement, c’est d’ailleurs la situation la plus fréquente.
La distinction tient en une ligne. Le registre répond à ce qui existe, le port répond à ce qui peut franchir. Un annuaire ne fait pas la frontière ; une frontière sans contrat ne fait pas l’institution.
Cette distinction n’est pas terminologique. Elle conditionne la capacité à auditer un système IA en production régulée. Un auditeur qui arrive avec la question quel modèle tourne ? reçoit la réponse du registry. Un auditeur qui arrive avec la question pourquoi celui-ci, selon quelle méthode, dans quel domaine de validité, avec quelle latitude d’évolution, sous quelle condition de révocation ? a besoin du port. La seconde question est celle que le régulateur pose, pas la première, et c’est aussi celle que beaucoup d’organisations ne savent pas encore instruire.
La littérature MLOps généraliste, de 2018 à aujourd’hui, a institutionnalisé le model registry et laissé le port impensé. Quatre facteurs, que cet article regroupe en une taxonomie explicative, rendent compte de cette asymétrie.
Premier facteur : l’héritage DevOps. Le MLOps s’est construit sur la matrice DevOps et a transposé ses primitives : CI/CD, pipelines, environnements staging et production. Cette transposition était nécessaire : elle a permis de sortir l’IA du notebook artisanal, état antérieur où la gouvernance consistait souvent à retrouver le bon fichier final_model_v7_really_final.pkl. Mais elle a aussi importé une erreur catégorielle. Dans DevOps, le code franchit la frontière par un merge sur une branche et un deploy automatisé. Le contrat, s’il existe, est implicite. Transposer ce présupposé à l’IA revient à affirmer qu’un modèle ayant passé ses métriques de validation est prêt pour la production. C’est insuffisant, car un modèle n’est pas un service, il est un estimateur soumis à la distribution des données qu’il rencontrera. La validation croisée sur un jeu de test n’est pas un contrat de production, c’est une photographie d’un instant passé.
Deuxième facteur : l’outillabilité. Le model registry s’est imposé parce qu’il était immédiatement codable. Un registry est une table avec des lignes et des statuts. Les équipes plateforme l’ont livré en deux trimestres ; les équipes data science l’ont adopté parce qu’il remplaçait leurs tableurs Excel ; les dirigeants l’ont validé parce qu’ils pouvaient le comprendre. Le port n’est pas codable sans architecture qui le porte, car il suppose des frontières définies, un contrat d’admission, une clause de révocation, des responsabilités distribuées entre data science, métier, qualité, sécurité, conformité, opérations. Il n’est pas installable par paquet ; il est institué par une pratique. Ce qui s’installe se diffuse. Ce qui s’institue demande du pouvoir, du temps et du courage organisationnel.
Troisième facteur : la confusion staging/production. Dans la plupart des stacks observables en 2026, les modèles vivent en staging permanent, c’est-à-dire dans une zone intermédiaire où ils tournent en parallèle de la production sans être jamais vraiment admis, ni jamais vraiment retirés. Le LangChain State of Agent Engineering 2026 rapporte que 57 % des organisations déclarent des agents en production, mais 32 % citent la qualité comme premier frein à la généralisation. Ce qu’il faut comprendre : beaucoup de ces agents sont en production de nom, en staging de fait. Le Deloitte State of AI in the Enterprise 2026 formule la même observation sous une autre forme : sans hard gate à 2x productivity lift, les pilotes deviennent permanents. La zone grise est la forme dégradée du port qui n’a pas été institué : elle permet de bénéficier des effets du déploiement sans assumer pleinement les obligations de l’admission.
Quatrième facteur : le coût d’évaluation. Qualifier l’admission d’un modèle en production régulée suppose une évaluation qui n’est pas celle de la validation croisée. Elle mobilise des cohortes prospectives, des silent trials, des assessments d’impact, des protocoles inter-cohorte, parfois des revues éthiques. Ce coût est hors de portée du pipeline CI/CD. Il ne s’automatise que partiellement, il exige un investissement en temps expert qu’une équipe plateforme ne peut pas absorber sans l’institutionnaliser. La facilité avec laquelle un model registry gère la transition staging vers production masque précisément ce que l’institution du port coûterait. Tant que le port n’est pas un objet nommé, son coût ne peut pas être budgété ; tant qu’il n’est pas budgété, l’équipe plateforme continue de franchir sans contrat. Le registre est gratuit, le port est cher. Cette asymétrie économique explique l’autre asymétrie, celle de l’outillage.
La conséquence s’observe. Lorsque l’audit arrive, l’organisation produit un extrait de son model registry (tel modèle, telle version, telles métriques). Le régulateur demande ce qui lui a été opposé comme contrat d’admission. L’organisation n’a rien à produire. Le registry atteste de l’existence, pas de l’admission. La différence est exactement celle qui distingue un annuaire d’une institution.
Le Predetermined Change Control Plan, finalisé par la FDA en décembre 2024 dans sa guidance Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions (Docket FDA-2022-D-2628), constitue aujourd’hui l’un des exemples les plus aboutis de ce que devrait être un port de promotion contractualisé.
Il s’inscrit dans une convergence plus large : principes FDA/EMA sur l’IA dans le développement du médicament, entrée en vigueur du QMSR aligné ISO 13485, montée en charge du régime européen applicable aux modèles d’IA. Ces régimes ne le recadrent pas juridiquement et ne le rendent pas opposable par eux-mêmes. Ils signalent néanmoins une même exigence fonctionnelle : expliciter les conditions dans lesquelles un système IA peut évoluer sans rompre son régime de sécurité, de qualité ou de responsabilité.
Son objet est précis : permettre à un fabricant de dispositif médical intégrant des fonctions logicielles d’IA de décrire à l’avance certaines modifications futures du dispositif, ainsi que la méthode permettant de les développer, de les valider et de les implémenter, afin d’éviter que chaque changement prévu et borné ne requière une nouvelle soumission complète. Le PCCP ne dit pas simplement nous voulons pouvoir changer le modèle. Il dit voici les changements prévus, voici comment ils seront réalisés, voici comment leur impact sera évalué, voici pourquoi ils restent compatibles avec la sécurité et l’efficacité du dispositif. Il contractualise l’évolution avant qu’elle n’advienne.
Le PCCP se compose de trois éléments qu’un model registry peut au mieux conserver comme pièces attachées, mais qu’il ne produit ni n’institue par construction.
Le premier est la description des modifications planifiées. Le fabricant ne dépose pas un modèle figé. Il dépose un modèle et la trajectoire d’évolution qu’il se réserve le droit de suivre sans nouvelle soumission. Cette description est positive, bornée et intelligible : elle énumère ce qui pourra changer (paramètres, données d’entraînement, modalités de recalibration, périmètre fonctionnel, sous-populations, seuils) et exclut implicitement ce qui ne pourra pas. Cette logique transforme la version en régime de versions. La question change : non plus quelle version est approuvée ?, mais quelle famille d’évolutions reste admise sans rompre le contrat initial ?.
Le deuxième est la méthodologie de développement, de validation et d’implémentation des modifications annoncées. Ce n’est pas une intention, c’est un protocole. Le fabricant s’engage sur comment il produira les modifications, pas seulement sur lesquelles. Un changement implémenté hors du protocole déclaré n’est pas couvert, même s’il tombe dans la catégorie des changements autorisés. Deux modèles peuvent afficher la même performance globale tout en reposant sur des processus de constitution très différents. Le résultat métrique ne suffit pas à établir l’équivalence institutionnelle. La méthode fait partie du contrat.
Le troisième est l’assessment d’impact, l’évaluation anticipée des effets que les modifications produiront sur la sécurité et l’efficacité du dispositif. Le fabricant n’est pas seulement autorisé à changer ; il a documenté, ex ante, pourquoi le changement ne rompt pas le contrat de sécurité initial. Cet assessment est l’instrument qui distingue le PCCP d’un blanc-seing : il introduit une logique de responsabilité anticipée.
Ces trois éléments réalisent ensemble, de concert, quelque chose que le staging/production MLOps ne réalise pas : ils contractualisent l’évolution autorisée avant qu’elle n’advienne. Le régulateur ne reçoit pas une liste de modèles, il reçoit un contrat d’admission avec sa clause d’évolution. Le passage en production n’est plus un acte technique, il devient la signature d’un contrat d’ingénierie opposable.
L’artefact PCCP est exactement ce que le port de promotion doit être. Il n’est pas un statut dans un registre, il est une interface qui contractualise. Il n’enregistre pas une version, il institue un régime de versions admissibles. Il ne répond pas à qu’est-ce qui est en production ?, il répond à sous quel contrat cela y est-il tenu ?. Le PCCP n’est pas le port de promotion universel, il est une forme réglementaire située, propre au champ des dispositifs médicaux. Mais son type architectural est généralisable. Le PCCP n’est pas une procédure, c’est un artefact théorique que la FDA a construit avant que les architectes ne le nomment.
Un port suppose une frontière. Une frontière suppose une architecture qui la définit. On ne pose pas un port de promotion dans une architecture où le noyau métier, les règles d’orchestration et les dépendances externes sont entrelacés, car alors il n’y a aucune surface sur laquelle le port puisse s’appuyer.
L’architecture hexagonale, formulée par Alistair Cockburn en 2005 dans son essai Hexagonal Architecture (alistair.cockburn.us/hexagonal-architecture) et présentée de manière équivalente sous le nom de ports and adapters architecture, définit précisément cette surface. Le cœur applicatif (règles métier, cas d’usage) est séparé de l’extérieur (bases de données, services, UI, modèles ML) par des ports, chacun implémenté par des adaptateurs substituables. La formulation originelle de Cockburn pose la règle structurante : créer des composants faiblement couplés qui peuvent être connectés à leur environnement par des ports et des adaptateurs, de manière que les composants soient échangeables à tout niveau et que l’automatisation des tests soit facilitée. La littérature 2026 transpose ce pattern aux systèmes ML et aux plateformes de données. On trouve chez Thoughtworks, chez Dev3lop, dans les tutoriels Python consacrés aux pipelines ML, des implémentations où le modèle ML est un adaptateur derrière un port applicatif.
Le port de promotion s’installe dans la continuité directe de cette discipline. Il n’est pas un pattern de code. Il est la conséquence institutionnelle d’une architecture qui a défini ses frontières. Là où l’architecture hexagonale garantit que le modèle est substituable, le port de promotion garantit qu’il est admissible. L’un gère la technique, l’autre gère l’institution. Sans le premier, le second est du théâtre ; sans le second, le premier est un exercice d’ingénierie sans gouvernance.
Le silent trial complète le dispositif. Le champ clinique a mûri en une décennie une discipline émergente de validation prospective non-interventionnelle : déployer le modèle en production réelle, en mode passif, sans que ses sorties n’affectent la décision clinique, pendant une période définie, afin de capter son comportement sur les données de terrain sans en subir les conséquences. Le scoping review publié par Nature Health en 2025, qui a examiné 891 articles entre 2015 et 2025 et en a retenu 75, documente cette pratique en insistant sur son hétérogénéité persistante (les protocoles varient, les durées diffèrent, les critères de succès ne sont pas entièrement stabilisés, les guidelines formelles restent à consolider). Il faut donc éviter de présenter le silent trial comme un standard mature et universel. Il faut le qualifier correctement : une discipline émergente de qualification prospective, particulièrement adaptée aux systèmes d’IA médicale ou assimilables, lorsqu’un modèle doit être observé sur données réelles avant admission interventionnelle.
Sa valeur tient à sa position dans le port de promotion. Il n’est pas une expérimentation quelconque. Il constitue une fenêtre contractualisée où le modèle candidat est confronté au réel sans encore obtenir le droit d’agir. Il transforme l’environnement de production en banc de qualification non interventionnel. Il ne dit pas seulement le modèle a bien fonctionné sur un jeu historique, il dit le modèle conserve un comportement acceptable lorsqu’il rencontre le flux vivant du système qu’il prétend servir. Des cas cliniques récents (mesures de longueur de membre via AI, PubMed 40990984 ; systèmes de décision hospitaliers) documentent des séquences shadow trial suivies de clinical trial selon une cadence qui n’a pas d’équivalent formalisé dans le MLOps d’entreprise.
C’est précisément ce qu’un model registry ne peut pas exiger par construction. Un registry peut conserver le résultat d’un silent trial. Il ne peut pas, à lui seul, faire du silent trial une condition d’admission. Le port le peut.
Deux conditions pratiques émergent donc.
Première condition : une architecture qui matérialise la frontière entre cœur métier et adaptateurs d’IA.
Deuxième condition : une discipline prospective qui qualifie le franchissement avant admission.
La pharmacovigilance, la médecine et les dispositifs médicaux ont progressivement institutionnalisé ces deux dimensions, parce que les conséquences d’une mauvaise inférence y sont difficilement maquillables en retour d’expérience agile. Le MLOps généraliste les a majoritairement laissées hors de son outillage standard.
L’objection est sérieuse et mérite une réponse frontale. Le PCCP, dira-t-on, est un objet réglementaire situé. Il appartient au champ des dispositifs médicaux et tire une grande partie de sa force de l’existence d’une autorité externe (ici la FDA) qui peut recevoir, évaluer, accepter, contester, rejeter le plan. Hors de ce cadre, personne ne signe le contrat ex ante, personne ne le fait respecter, et le model registry reste la seule forme disponible de mémoire collective des passages. Généraliser la leçon PCCP hors santé produirait une analogie séduisante mais inopérante : sans autorité qui reçoit, pas d’institution possible, seulement du théâtre de gouvernance.
L’objection est saine. Elle évite le glissement habituel qui consiste à prendre un artefact réglementaire très situé, à le vider de son droit, puis à l’appliquer partout avec la subtilité d’un tampon administratif. Mais elle ne détruit pas la thèse. Elle oblige à la préciser. Il ne s’agit pas de copier le PCCP hors santé, il s’agit d’en transposer le type.
Trois réponses opposables.
Première réponse. L’institution ex ante ne requiert pas une autorité externe qui reçoit ; elle requiert un dispositif qui engage. La pharmacovigilance elle-même le démontre au-delà du strict PCCP. Le Pharmacovigilance System Master File (PSMF) est un document interne, non soumis à homologation externe préalable, qui engage l’organisation sur son système de pharmacovigilance. La Guideline on good pharmacovigilance practices (GVP) Module II, Pharmacovigilance system master file, dans sa révision 2 publiée par l’EMA, définit le PSMF comme un document unique tenu à jour en continu, structuré en sept modules (QPPV, structure organisationnelle du titulaire, sources de données de sécurité, systèmes informatiques, processus de pharmacovigilance, performance du système, plan qualité) dont la fonction explicite est de documenter la conformité aux obligations découlant du Règlement (CE) n° 726/2004 et de la Directive 2001/83/CE. La documentation ne vient pas d’une autorité ; elle est tenue par le titulaire de l’AMM et opposable à l’autorité lors d’une inspection. Les principes ALCOA++ (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available) définissent la qualité des traces internes exigibles. Ces dispositifs contractualisent sans qu’une agence externe les signe. L’autorité, quand elle arrive, constate si l’engagement a été tenu. L’institution précède l’autorité, elle n’en découle pas.
Deuxième réponse. L’AI Act applicable aux fournisseurs de modèles d’IA à usage général ne reproduit pas le PCCP, et il faut s’abstenir de le prétendre. Il impose plutôt une pression documentaire et méthodologique : documentation technique, transparence sur les contenus d’entraînement, politiques de conformité, et, pour les modèles à risque systémique, évaluation et mitigation des risques systémiques. L’AI Transparency Atlas publié en décembre 2025 (arXiv 2512.12443) a évalué cinquante modèles sur une grille pondérée où les disclosures de sécurité comptent pour 25 % et les risques critiques pour 20 % ; les laboratoires frontier plafonnent à 80 % de conformité, la majorité tombe sous 60 %. L’écart avec un régime de PCCP opposable est documentable. La montée en charge des obligations GPAI ne va pas inventer le port ; elle va révéler celles des organisations qui ont déjà institué le leur et celles qui n’ont que leur registry.
Troisième réponse. Le PCCP n’est pas à copier ; son type est à transposer. Ce qu’il enseigne, c’est la structure d’un artefact qui contractualise : description de ce qui peut changer, méthodologie pour le faire, assessment d’impact, surveillance, conditions de retrait. Cette structure est agnostique du champ d’application, même si ses critères sont sectoriels. Un modèle de scoring de crédit en production bancaire peut construire son propre artefact (description des ré-entraînements autorisés, variables admissibles, tests d’équité sur classes protégées, seuils de dérive, conditions de suspension). Un modèle de maintenance prédictive sur infrastructure critique décrira les capteurs couverts, plages de fonctionnement, conditions environnementales, limites d’extrapolation. Un modèle défensif décrira niveau d’autonomie, classes d’action interdites, garanties humaines, mécanismes de désactivation. Le type est commun. Le contenu est situé. L’organisation qui le construit ex ante, quand l’autorité arrivera, aura un artefact à produire. Celle qui ne l’a pas construit n’aura qu’un registry à produire, et l’extrait ne tiendra pas lieu d’admission.
L’objection retourne contre elle-même. Dire que le PCCP est intransposable revient à dire que l’institution ex ante est un privilège des champs régulés par le haut. C’est l’exact inverse. Les champs régulés par le haut ont construit l’institution parce qu’on la leur imposait. Les autres ont différé. Le différé arrive à échéance.
ToxTwin, en tant que jumeau numérique typé pharmacovigilance, est exposé à la convergence des trois régimes énumérés en introduction (Guiding Principles FDA/EMA du 14 janvier 2026, QMSR ISO 13485 entré en vigueur le 2 février 2026, montée en charge du régime européen applicable aux modèles d’IA entre 2025 et 2027). Il offre un terrain où la question du port de promotion se pose non pas abstraitement mais opérationnellement. Il se situe au croisement de plusieurs disciplines (pharmacovigilance, IA, données de santé, qualité logicielle, traçabilité, auditabilité), ce qui en fait précisément le type de système où l’absence de port devient visible.
L’architecture V2.4 de ToxTwin a posé le cadre hexagonal. Le noyau applicatif est la logique métier pharmacovigilance (signalement d’effet indésirable, causalité, classification MedDRA, interface aux cas individuels). Les adaptateurs couvrent l’ingestion des données sources, les services de décodage linguistique, les modèles de classification, les interfaces d’export vers les systèmes réglementaires nationaux (EudraVigilance, FAERS). Un modèle IA (par exemple un classifieur d’imputabilité ou un moteur de détection de signal) vient se brancher comme un adaptateur derrière un port applicatif. Cette discipline est essentielle : si le modèle devient le cœur, l’organisation finit par adapter le métier aux contraintes du modèle, ce qui inverse silencieusement la hiérarchie de gouvernance.
Le port de promotion, dans cette architecture, n’est pas une extension optionnelle ; il est la surface qui distingue un modèle candidat d’un modèle admis. Sa conception impose plusieurs contraintes, que l’on peut dérouler sur un premier sous-cas : le classifieur d’imputabilité.
Il impose la description explicite des ré-entraînements autorisés : quel périmètre de données, quelle fréquence, quelle fenêtre d’apprentissage, quelle méthode de révision des ground truths. Ce qui n’est pas dans la description n’est pas autorisé, même si le pipeline le rend techniquement possible. Le pipeline donne la capacité ; le port donne le droit.
Il impose la méthodologie de validation prospective : silent trial obligatoire d’une durée calibrée sur le volume de signaux par semaine, avec une exigence de stabilité inter-cohorte avant bascule live. Cette durée ne peut pas être décidée abstraitement, car elle dépend du volume de cas, de la variabilité des produits, de la criticité du contexte. Un silent trial de deux semaines peut être dérisoire ; un silent trial de six mois peut être disproportionné. Le port contractualise la durée par rapport au risque et au volume, pas par rapport à la patience du comité.
Il impose l’assessment d’impact sur la population cible : effet attendu sur le taux de détection de signaux vrais, sur le taux de faux positifs, sur la distribution des classes d’imputabilité. Un modèle qui améliore une métrique globale au prix d’une dégradation sur les populations sensibles (patients âgés, polymédiqués, effets rares) ne passe pas le port. L’assessment l’a dit ex ante.
Il impose enfin une clause de révocation (quatrième composant que je propose comme extension du cadre FDA à trois composants). Le PCCP contient la logique implicite d’un régime borné d’évolution ; le port de promotion doit expliciter le régime de retrait. Les conditions de révocation incluent la dérive statistique, la dégradation de calibration, la modification majeure du référentiel, l’événement de pharmacovigilance critique, le changement réglementaire affectant la validité du modèle. Un port sans révocation est une admission sans sortie, ce n’est pas une gouvernance, c’est une autorisation paresseuse.
Un second sous-cas illustre la généralité du traitement. Un moteur de détection de signal en pharmacovigilance (algorithme de disproportionnalité sur données EudraVigilance, estimateur bayésien de type Information Component (Bate, Lindquist, Edwards, Olsson et al., Uppsala Monitoring Centre, 1998), score de risque relatif pondéré) soulève des questions homothétiques mais distinctes. La description des évolutions autorisées porte ici sur la fenêtre de recalcul, le seuil de disproportionnalité retenu, la liste des termes MedDRA inclus dans la surveillance active, les règles de fusion de classes thérapeutiques. La méthodologie de validation prospective doit composer avec un phénomène propre à la détection de signal : les faux positifs ne sont observables qu’après investigation, et l’investigation consomme du temps expert. Le silent trial n’est donc pas ici un shadow passif, c’est, dans le protocole que je propose, une fenêtre de calibration où le moteur tourne en parallèle et où les investigations déclenchées sont menées mais non imputées au pipeline en place. L’assessment d’impact mesure le lift de détection précoce, la charge d’investigation supplémentaire, le taux de confirmation après clôture, la distribution des signaux nouveaux par classe thérapeutique. La clause de révocation couvre au minimum deux scénarios : la dérive de performance par rapport au baseline, et l’altération de la base EudraVigilance elle-même entre deux extractions (cas observé, non théorique). Croire que la donnée réglementaire est un sol stable parce qu’elle paraît institutionnelle est une naïveté coûteuse.
Ces deux sous-cas (classifieur d’imputabilité et moteur de détection de signal) ne sont pas redondants. Ils montrent que le port de promotion n’est pas un contrat générique, il est un contrat situé par l’usage qu’il qualifie. Un port ne se décrète pas à un niveau plateforme ; il se décline à chaque port applicatif qu’il garde. Ce qui renforce, plutôt qu’il n’affaiblit, la thèse : la surface hexagonale est le seul cadre où cette démultiplication reste gouvernable, parce qu’elle réserve à chaque port applicatif son contrat d’admission sans imposer un contrat générique au niveau du noyau.
Cette instance illustre ce que la thèse prétend. Elle ne la prouve pas universellement, elle n’est pas un argument, elle est un cas qui atteste que la construction est possible, ancrée, et opposable à un régulateur qui arriverait demain. D’autres instances, dans d’autres champs, produiraient d’autres matériaux. L’instance ne se substitue pas à l’argument.
Le port de promotion modifie la manière dont il faut penser l’industrialisation de l’IA. Cinq conséquences doctrinales en découlent.
Première conséquence : la production n’est plus un environnement, c’est un régime. Dans beaucoup d’organisations, production désigne encore un environnement technique (endpoint exposé, monitoring activé, disponibilité requise, logs collectés). Cette vision est insuffisante pour l’IA régulée. La production est un régime d’usage dans lequel un artefact produit des effets opposables. Il ne suffit donc pas d’y être déployé ; il faut y être admis.
Deuxième conséquence : la gouvernance ne peut pas être ajoutée après le déploiement. Une organisation qui découvre au moment de l’audit qu’elle doit justifier l’admission d’un modèle a déjà perdu une partie de la bataille. Elle peut reconstruire des justifications, agréger des preuves, produire des notes ; elle ne peut pas recréer proprement l’institution ex ante. La gouvernance tardive ressemble à de l’archéologie défensive. Le port de promotion oblige à documenter avant, non après. Il transforme l’admission en condition de déploiement, et non en commentaire rétrospectif.
Troisième conséquence : la performance n’est qu’une des clauses du contrat. Un modèle peut être performant et inadmissible. Il peut obtenir une meilleure AUC et ne pas être calibré. Il peut réduire une erreur moyenne et aggraver les queues de distribution. Il peut améliorer une métrique globale et produire une charge opérationnelle insoutenable. Il peut fonctionner sur une population majoritaire et échouer sur les cas critiques. Le port de promotion force à quitter la religion du score, car il demande un jugement situé sur l’usage.
Quatrième conséquence : la révocation devient aussi importante que l’admission. Une organisation sérieuse ne définit pas seulement comment un modèle entre en production. Elle définit comment il en sort. Le retrait ne doit pas être improvisé au moment de la crise ; il doit être prévu comme une clause normale du régime d’admission. Cette discipline est encore rare dans le MLOps généraliste. Le rollback technique existe ; la désadmission institutionnelle, beaucoup moins. Ce sont deux gestes différents : revenir à une version antérieure n’est pas retirer le droit d’agir à un modèle.
Cinquième conséquence : le port de promotion est un objet de management, pas seulement d’architecture. Il engage le CTO, le responsable qualité, le métier, la conformité, la sécurité, parfois le juridique, parfois le médical ou le réglementaire. Il force l’organisation à décider qui peut admettre, qui peut bloquer, qui peut révoquer. Il met fin à la fiction selon laquelle la production d’un modèle serait une affaire purement technique. Cette fiction a longtemps rendu service à beaucoup de monde, en permettant aux métiers de ne pas comprendre, aux data scientists de ne pas gouverner, aux plateformes de ne pas arbitrer, et aux dirigeants de demander où en est l’IA ? comme on demande où en est l’infrastructure réseau.
Le port de promotion est un objet doctrinal avant d’être un objet technique. Le confondre avec le model registry est une erreur catégorielle qui explique pourquoi tant d’organisations, en 2026, déclarent des modèles en production sans disposer du contrat qui en ferait une admission. La FDA a construit l’artefact avant que les architectes de plateformes ne le nomment ; elle l’a fait dans un champ régulé par le haut parce qu’on l’y obligeait, mais la structure qu’elle a produite n’est pas spécifique au dispositif médical : elle est la forme générique de l’institution d’un franchissement.
Deux implications pratiques.
Première implication. Les organisations qui industrialisent l’IA en environnement régulé ou candidat à la régulation gagnent à construire leur port de promotion ex ante, sans attendre l’arrivée de l’autorité. Le PCCP donne la structure (description des évolutions autorisées, méthodologie, assessment d’impact, clause de révocation). L’architecture hexagonale donne la surface. Le silent trial donne la discipline de qualification prospective. Les trois ensemble constituent ce que je propose de nommer l’appareil tripartite du port de promotion. Aucun des trois, isolé, ne suffit.
Seconde implication. La montée en charge des régimes IA entre 2025 et 2027 sera un révélateur. Les organisations qui auront institué leur port auront un artefact à produire. Celles qui n’auront qu’un registry sortiront un extrait de table et découvriront que l’auditeur demandait autre chose. La différence entre un annuaire et une institution n’est pas visible en temps de paix ; elle l’est au moment de l’audit.
Un pipeline s’inscrit dans un registre ; un jumeau se tient sur un port. La différence n’est pas d’outillage. Elle est de régime.