Dimensionner un jeu de données d’IA médicale relève de l’arithmétique. Ce qui échoue, c’est de le garder prouvable, versionné et réutilisable pendant des années de développement, et c’est précisément ce que MAEA est conçu pour tenir.
By ModAstera
28 Aug 2026
Déterminer la quantité de données nécessaire à un modèle d’IA médicale relève, au fond, de l’arithmétique. Choisissez la revendication, choisissez le critère d’évaluation, décidez de l’incertitude statistique acceptable, et le nombre d’événements cibles requis découle d’une formule. Nous détaillons ce calcul dans l’article compagnon, quelle quantité de données faut-il pour entraîner un modèle d’IA médicale.
Ce n’est pas l’arithmétique qui échoue.
Ce qui échoue, c’est tout ce que l’arithmétique présuppose en silence : pouvoir dire d’où vient chaque échantillon, qui l’a annoté et sous quelle version de protocole, quelle version du modèle s’est entraînée dessus, s’il a jamais touché le jeu de test, et si vous pourrez encore répondre à toutes ces questions deux ans plus tard, lorsqu’une modification exigera de nouvelles preuves isolées.
C’est le problème du cycle de vie des données. C’est la raison pour laquelle des programmes d’IA médicale bien financés s’enlisent entre un prototype prometteur et un produit défendable, et c’est le problème autour duquel MAEA, le Medical AI Engineering Agent de ModAstera, est construit.
Un programme d’IA médicale doit maintenir huit propositions vraies simultanément, de la première réception des données jusqu’aux changements post-commercialisation :
Chacune prise isolément est facile. La difficulté est qu’elles doivent toutes tenir en même temps, sur des années, malgré le renouvellement des équipes, et à travers une chaîne d’outils qui n’a jamais été conçue pour les préserver.
La pile d’IA médicale habituelle est assemblée à partir de briques qui font chacune bien une chose et dont aucune ne transmet le contexte à la suivante : un export PACS ou SIL, un tableur d’identifiants de cas, un outil d’annotation, un stockage objet, des notebooks, un script d’entraînement et, à terme, une pile de service.
Chaque passage de relais perd un fait. L’export perd la requête qui l’a produit. Le tableur perd la base de consentement. L’outil d’annotation perd la version de ligne directrice active. Le notebook perd la version de jeu de données qu’il a lue. Au moment où un résultat arrive sur une diapositive, plus personne ne peut reconstituer la chaîne.
Ce n’est pas un surcoût marginal. Willemink et ses collègues estiment que le prétraitement et l’organisation des données en vue de leur ingestion représentent 80 % ou plus de l’effort d’un projet d’apprentissage automatique en imagerie médicale. C’est là que part l’essentiel d’un budget d’IA médicale, et c’est un travail qui ne produit aucune preuve si la structure obtenue n’est pas préservée.
Les modes de défaillance sont familiers :
MAEA traite le cycle de vie comme le produit, plutôt que de traiter l’entraînement du modèle comme le produit et le cycle de vie comme de la paperasse autour. Chaque étape ci-dessous est un endroit où naît un fait, et le rôle de MAEA est de faire en sorte que ce fait survive jusqu’à l’étape suivante.
Les échantillons entrent dans MAEA comme membres de jeux de données nommés, avec des étiquettes, l’extraction de coupes pour les entrées volumiques et multi-images, et un contrôle d’accès par jeu de données. Configuration du stockage, hôtes autorisés, clés d’API et rôles d’organisation font partie du même système plutôt que d’une préoccupation d’infrastructure séparée.
L’effet pratique est que « de quelles données s’agit-il ? » obtient une réponse qui ne dépend ni d’une convention de nommage ni de la personne qui a configuré l’export.
L’espace d’annotation de MAEA couvre l’annotation par polygones et boîtes englobantes, les contrôles vidéo et multi-images, le fenêtrage DICOM, la gestion de l’orientation, les jeux d’étiquettes par défaut et la relecture au clavier, aux côtés de l’annotation assistée par clic, de l’auto-annotation et du téléversement direct de masques produits ailleurs.
Deux choses comptent plus que les outils de dessin. D’abord, les annotations restent attachées à l’échantillon et au jeu de données plutôt que de vivre dans un système parallèle. Ensuite, l’annotation assistée est traitée comme un accélérateur du référentiel humain, non comme un substitut. C’est cette distinction qui rend les annotations obtenues utilisables comme preuves.
Dans MAEA, les jeux d’entraînement se construisent à partir de filtres, d’étiquettes et de requêtes sur un jeu de données qui existe déjà comme objet. La composition est une déclaration que l’on peut inspecter, réappliquer et discuter, au lieu d’une copie de fichiers ponctuelle dans un répertoire.
C’est là que l’intégrité de la séparation se gagne ou se perd. Une composition déclarée peut maintenir une frontière au niveau patient ou site à chaque réutilisation. Un dossier assemblé à la main la maintient une seule fois, jusqu’à ce que la personne suivante le reconstruise.
Les vues d’analyse de jeu de données et d’intelligence des échantillons permettent à une équipe de voir la distribution d’un jeu de données, valeurs cibles, étiquettes, sources et détail par échantillon, avant l’entraînement plutôt qu’après un résultat de sous-groupe décevant.
C’est la réponse opérationnelle au point qui compte le plus dans le dimensionnement : le N agrégé masque les strates clairsemées. Un jeu de 50 000 cas comportant 40 exemples d’un sous-groupe revendiqué soutient une revendication sur la population et rien sur le sous-groupe. Cet écart n’est actionnable que si quelqu’un peut le voir tant qu’il reste du temps pour collecter.
L’entraînement et l’évaluation s’exécutent comme des pipelines avec métriques configurables, affinage, visualisation des résultats et comparaison côte à côte. Au-dessus, la couche d’expérimentation de MAEA compose, compile, exécute et répare les configurations d’expérience, et conserve pour chaque exécution une chronologie d’artefacts, des configurations versionnées, des graphiques d’analyse et un enregistrement de configuration inspectable.
Le point n’est pas que la plateforme entraîne des modèles. Beaucoup d’outils entraînent des modèles. Le point est qu’une métrique sur un graphique se résout en la configuration et l’exécution qui l’ont produite, sans que personne ait à s’en souvenir.
Les instantanés de pipeline peuvent être exportés et importés. Un candidat gelé devient donc un objet transférable, relisible par un partenaire, reproductible sur une autre infrastructure, et récupérable plus tard lorsqu’un changement doit être comparé à la version réellement validée.
Dans la plupart des piles, le gel de conception est un événement documentaire. Ici, c’est un artefact.
Déploiements, usage, volume d’appels d’API et métriques de latence vivent dans le même système que les jeux de données et les expériences qui ont produit le modèle déployé. La surveillance devient une comparaison à une ligne de base connue plutôt qu’un tableau de bord isolé, distinction qui rend actionnables les signaux de dérive et de flux de travail. Nous développons le volet surveillance dans la surveillance des modèles d’IA en flux réglementés.
Parce que les compositions sont déclarées, les configurations versionnées et les instantanés portables, une modification peut être évaluée sur des données isolées dont l’indépendance est démontrable, plutôt que sur ce qui reste par hasard. C’est la condition pratique d’un processus de changement maîtrisé, et c’est la partie que les équipes découvrent le plus souvent ne pas avoir au moment précis où elles en ont besoin.
L’article sur le dimensionnement soutient que la vraie réponse à « de combien de données ai-je besoin ? » est un budget de données sur un calendrier : acheter par tranches, réajuster la courbe d’apprentissage après chacune, réserver la cohorte de test verrouillée avant le choix du modèle et du seuil, et comptabiliser la couverture par strate plutôt qu’en total.
Chacun de ces points dépend d’une infrastructure de cycle de vie :
Sans cette infrastructure, le budget est un tableur qui cesse de correspondre à la réalité dès le deuxième mois. C’est aussi pourquoi la traçabilité relève de la planification des données plutôt que de la documentation.
Être clair sur la frontière fait partie de l’utilité :
Si votre équipe se situe quelque part entre un prototype et un produit, le premier geste utile n’est pas une migration de plateforme. C’est un audit :
Cet exercice tranche généralement la question de savoir si le cycle de vie des données est un problème réel pour votre programme ou un problème théorique. Là où il est réel, MAEA est conçu pour refermer les ruptures précises qu’il révèle ; là où il ne l’est pas, l’audit reste peu coûteux.
Si vous en êtes à un stade plus amont, la préparation des données avant la construction du modèle est un meilleur point de départ, et ModAstera peut examiner la structure des données, la logique de séparation et l’état de préparation des preuves avant que les comparaisons de modèles ne deviennent coûteuses à reprendre.
Il n’existe pas de chiffre unique. Il existe un budget de données, un calendrier et un critère d’évaluation qui rendent enfin ce chiffre calculable. Rapport complet sur le dimensionnement des preuves en IA médicale réglementée.
Un guide pratique pour vérifier si un système d’IA médicale verrouillé reste transférable au-delà de ses données de développement, avec la conception de cohorte, les seuils, les sous-groupes, le flux de travail et l’analyse des échecs.
Un guide pratique de la recherche d’images en pathologie : représentations de lames entières, classement des candidats, revue par des experts, contexte des sources, décisions de cohorte et évaluation pertinente.
