Guardrails et contrôles avant déploiement

Une femme de 55 ans se présente aux urgences avec des douleurs à la mâchoire et de la fatigue. L'algorithme de triage la classe en faible gravité. Elle fait un infarctus. La revue post-mortem révèle que le modèle avait été entraîné surtout sur des présentations masculines d'événements cardiaques, où la douleur thoracique domine. Ce n'est pas un cas d'école : les biais de sexe et d'origine dans les algorithmes cliniques sont documentés, l'exemple le plus célèbre étant une étude de *Science* en 2019 montrant qu'un algorithme de care management très utilisé aux États-Unis sous-estimait systématiquement les besoins des patients noirs (Obermeyer et al., 2019).

Les guardrailsguardrailsRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → font la différence entre un algorithme qui aide un clinicien et un algorithme qui nuit discrètement à un sous-groupe. Cette leçon parcourt la checklist concrète qu'une équipe medtech exécute avant de mettre en production un algorithme de triage.

Ce que l'on entend par « algorithme de triage »

Un algorithme de triage classe ou hiérarchise les patients par urgence pour guider les décisions de soin. Exemples : les scores d'alerte précoce du sepsis intégrés aux EHR hospitaliers (dossiers patients informatisés), les applications de vérification de symptômes qui orientent vers les urgences ou vers la téléconsultation, et les outils de « priorisation de worklist » en radiologie qui remontent les AVC suspectés en tête de file d'un radiologue.

Juridiquement, la plupart sont des dispositifs médicaux. Aux États-Unis, ils relèvent de la FDA (Food and Drug Administration), généralement comme SaMD (Software as a Medical Device). En Europe, ils sont encadrés par le MDR (règlement sur les dispositifs médicaux, UE 2017/745), et séparément comme IA à haut risque au titre de l'AI Act européen, entré en vigueur en 2024 avec des obligations qui s'échelonnent jusqu'en 2026 et 2027.

Ce statut réglementaire fixe le plancher. De bons guardrails vont au-delà.

La checklist avant déploiement

Exécutez ces gates dans l'ordre. Un échec à n'importe quel gate bloque la mise en production.

Gate 1 : validation clinique

Avant toute chose, prouvez que le modèle fonctionne sur la population qui l'utilisera réellement.

• Validation rétrospective : tester sur des données historiques mises de côté que le modèle n'a jamais vues à l'entraînement.
• Validation externe : tester sur les données d'un *autre* hôpital ou d'une autre région. Les modèles qui atteignent 0,92 d'AUROC en interne chutent souvent nettement ailleurs. (L'AUROC, aire sous la courbe ROC, est une mesure de performance courante où 1,0 est parfait et 0,5 équivaut à un tirage au sort.)
• Validation prospective : faire tourner le modèle en silence à côté de vrais cliniciens (déploiement en « shadow mode ») et comparer les prédictions aux résultats observés sans agir dessus.

Exemple de seuil concret : un outil de triage des AVC peut exiger une sensibilité au-dessus d'un plancher pré-enregistré (disons 0,90) parce qu'un AVC manqué est catastrophique, en acceptant davantage de faux positifs en contrepartie.

Gate 2 : audit des biais et des sous-groupes

La performance agrégée masque les préjudices. Décomposez la performance par sous-groupe et examinez les écarts.

Publiez les métriques par groupe : tranche d'âge, sexe, origine et ethnicité, statut d'assurance, langue principale. Regardez à la fois le taux de faux négatifs (cas urgents manqués) et le taux de faux positifs (escalade inutile) par groupe.

Voici un audit minimal en code :

import pandas as pd

def subgroup_report(df, group_col, y_true="label", y_pred="pred"):
    rows = []
    for g, sub in df.groupby(group_col):
        fn = ((sub[y_true]==1) & (sub[y_pred]==0)).sum()
        pos = (sub[y_true]==1).sum()
        fnr = fn / pos if pos else float("nan")
        rows.append({"group": g, "n": len(sub), "false_neg_rate": round(fnr,3)})
    return pd.DataFrame(rows)

# signaler tout sous-groupe dont le FNR dépasse celui du meilleur groupe de plus de 5 points

La règle compte plus que le code : définissez, avant de regarder, quel écart est inacceptable. Une approche courante consiste à exiger que le taux de faux négatifs d'aucun sous-groupe protégé ne dépasse celui du groupe le plus performant de plus d'une marge fixée. Si c'est le cas, vous réentraînez, vous repondérez ou vous restreignez la population d'usage prévu, et vous documentez pourquoi.

L'AI Act européen impose ce type de gouvernance des données et d'examen des biais pour les systèmes à haut risque. Les Good Machine Learning Practice principles de la FDA, publiés conjointement avec les régulateurs britannique et canadien, désignent la représentativité des données comme une attente centrale.

Gate 3 : seuils de human-in-the-loop

« Human-in-the-loop » signifie qu'une personne examine ou valide la sortie du modèle avant qu'elle n'affecte le soin. La question de design est *quand*.

Fixez les seuils selon le risque, pas selon la commodité :

• Automatiser : sorties à faible enjeu et haute confiance (orienter un orteil cogné vers une ligne infirmière).
• Recommander, l'humain décide : le réglage par défaut en triage. Le modèle suggère un niveau de gravité ; un clinicien confirme.
• Imposer une revue humaine : signalements de haute gravité, scores de faible confiance, et tout cas proche de la frontière de décision.

Le piège ici est le biais d'automatisation : les cliniciens valident mécaniquement le modèle parce qu'il a généralement raison. Contrez-le en affichant la confiance du modèle, en faisant ressortir les principaux facteurs du score, et en injectant périodiquement des cas où le modèle se trompe pour garder les relecteurs en alerte (pratique utilisée dans certains programmes de QA en radiologie).

Gate 4 : modes de repli

Demandez-vous : que se passe-t-il quand le modèle est indisponible, incertain, ou alimenté avec n'importe quoi ?

• Abstention sur incertitude : si la confiance est sous un plancher, le système renvoie « impossible de scorer » et oriente vers le triage humain standard plutôt que de deviner.
• Détection hors distribution : signaler les entrées qui ne ressemblent à rien de l'entraînement (un patient pédiatrique soumis à un modèle réservé aux adultes) et refuser de scorer.
• Dégradation progressive : si le service du modèle tombe, le workflow revient au protocole manuel existant, pas à un écran vide. Un clinicien ne doit jamais être bloqué dans sa prise en charge parce qu'une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → a expiré.

Inscrivez le repli dans le workflow clinique et *testez-le* en mettant délibérément le modèle hors ligne pendant un exercice.

Gate 5 : documentation et traçabilité

Les régulateurs et votre propre équipe risque ont besoin d'une trace écrite.

• Model card : un document court indiquant l'usage prévu, les données d'entraînement, la performance par sous-groupe et les limites connues.
• Déclaration d'usage prévu : exactement ce que le modèle est autorisé à faire, et ce qu'il n'est pas autorisé à faire (par exemple : « aide au triage aux urgences adultes ; pas pour un usage pédiatrique ou obstétrical »).
• Audit log : chaque prédiction, la version des entrées, la version du modèle et la décision humaine, conservés pour pouvoir reconstituer n'importe quel cas.

L'AI Act européen impose une documentation technique et une journalisation pour les systèmes à haut risque. Traitez cela comme une exigence de conception, pas comme de la paperasse ajoutée à la fin.

Des guardrails qui tiennent en production

Passer les gates avant déploiement est nécessaire mais pas suffisant. Les modèles se dégradent.

Surveiller le drift

Le data drift survient quand la population de patients entrante s'écarte des données d'entraînement (un nouveau variant, un nouveau schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → d'orientation, une fusion d'établissements). Le performance drift survient quand la performance se dégrade dans le temps. Suivez les deux.

Mise en place pratique : surveiller chaque semaine les distributions des features d'entrée et, là où les résultats sont disponibles (le patient signalé s'est-il effectivement dégradé ?), suivre le taux de faux négatifs sur une fenêtre glissante. Fixez un seuil d'alerte. Si le FNR glissant le franchit, le modèle repasse automatiquement en shadow mode et alerte le clinicien-owner responsable.

Désigner un owner

Chaque modèle déployé a besoin d'un owner nommé et responsable, généralement un clinicien plus un data scientist. Dans les cadres FDA comme européen, la surveillance après mise sur le marché n'est pas optionnelle. Quelqu'un doit surveiller les dashboards et avoir l'autorité de retirer le modèle.

Anticiper le changement

Les modèles sont réentraînés. La FDA soutient le Predetermined Change Control Plan (PCCP) : vous spécifiez à l'avance quels types de mises à jour vous pourrez faire (réentraînement sur de nouvelles données, ajustements de seuils) et comment vous les validerez, afin que les améliorations de routine ne nécessitent pas un nouveau dossier chaque fois. Définissez votre PCCP avant le lancement.

Un exemple chiffré simple

Supposons qu'un outil d'alerte sepsis soit déployé sur 20 000 passages aux urgences par an, avec un taux réel de sepsis de 2 %, soit 400 cas réels. À 0,90 de sensibilité, le modèle en détecte 360 et en manque 40. Si un audit de sous-groupe montre que la sensibilité pour les patients non anglophones n'est que de 0,75, alors dans ce sous-groupe le modèle manque un cas réel sur quatre. C'est cet écart, et non le 0,90 affiché, que votre guardrail doit détecter. (Chiffres illustratifs.)

Points clés

• Les algorithmes de triage sont généralement des dispositifs médicaux réglementés (FDA SaMD aux États-Unis, MDR plus AI Act en Europe). La réglementation est le plancher ; concevez des guardrails au-dessus.
• Ne faites jamais confiance à la performance agrégée. Auditez les taux de faux négatifs et de faux positifs par sous-groupe, fixez un seuil d'écart inacceptable avant de regarder, et bloquez la mise en production s'il est franchi.
• Concevez le human-in-the-loop par niveau de risque et luttez activement contre le biais d'automatisation. Construisez des modes de repli (abstention, détection hors distribution, dégradation progressive) et exercez-les.
• Livrez avec une model card, une déclaration d'usage prévu et un audit logging complet. Puis surveillez le data drift et le performance drift avec une alerte capable de faire revenir automatiquement le modèle en arrière.
• Nommez un owner responsable (clinicien plus data scientist) et définissez un Predetermined Change Control Plan avant le lancement, pour que les mises à jour restent sûres et traçables.

*Cette leçon est à visée pédagogique et ne constitue pas un conseil juridique, réglementaire ou médical.*