Patrick vient d’arriver dans une entreprise MedTech.
Une belle opportunité, une équipe motivée, un produit prometteur.
Lors de sa première semaine, on lui confie une mission qui semble claire sur le papier : « s’occuper du dossier technique de notre IA ».

Très vite, les questions arrivent.

Quelle forme doit prendre ce dossier ?
Qu’est-ce qu’on doit réellement mettre dedans ?
Est-ce que c’est le même dossier technique que pour le MDR ?
À quel moment faut-il le constituer ?
Et surtout : est-ce que c’est quelque chose qu’on fait à la fin… ou dès maintenant ?

Depuis l’entrée en scène de l’AI Act, beaucoup d’acteurs de la MedTech se posent exactement les mêmes questions. Le règlement introduit en effet une nouvelle exigence : le dossier technique de l’IA, imposé par l’article 11 et détaillé dans l’annexe IV.

À première vue, cela ressemble à un document de plus.
Un dossier supplémentaire à produire avant la mise sur le marché.

En réalité, la lecture attentive du texte raconte une tout autre histoire.

Le dossier technique IA n’est pas un simple livrable administratif.
Il est exigé avant la mise sur le marché.
Et contrairement à ce que beaucoup imaginent, il ne se construit pas une fois le produit finalisé, mais tout au long de la conception du système d’IA.

Ce dossier ne se contente pas de décrire un produit fini.
Il reflète la maturité de la conception, la cohérence du système et la capacité de l’organisation à maîtriser son IA dans la durée.

C’est ce que Patrick va progressivement découvrir en ouvrant l’annexe IV de l’AI Act.

Dans cet article, nous allons décrypter le dossier technique de l’IA tel qu’exigé par l’AI Act : pourquoi il est requis, ce qu’il doit contenir concrètement, en quoi il s’inscrit dans une continuité logique pour les acteurs du dispositif médical, et surtout par où commencer pour ne pas le subir trop tard.

1. Mise sur le marché d’une IA : pourquoi un dossier technique est requis

Lorsque Patrick commence à se plonger dans l’AI Act, sa première surprise n’est pas le contenu du dossier technique.
C’est le moment où ce dossier devient obligatoire.

L’article 11 du règlement est explicite : le dossier technique est une condition préalable à la mise sur le marché des systèmes d’IA concernés. Il ne s’agit donc pas d’un document de justification a posteriori, mais d’un élément structurant de l’accès au marché.

Très vite, Patrick comprend un point essentiel : toutes les IA ne sont pas concernées.

L’obligation de constituer un dossier technique s’applique uniquement aux systèmes d’IA qualifiés à haut risque au sens de l’AI Act. Cette qualification est déterminante : elle conditionne l’ensemble des exigences applicables, dont l’obligation de documentation technique.
Pour les acteurs de la MedTech, cette nuance est particulièrement importante. Contrairement à une idée répandue, tous les dispositifs médicaux intégrant de l’IA ne sont pas automatiquement considérés comme des systèmes d’IA à haut risque. En pratique, les dispositifs médicaux de classe I ne sont, en principe, pas concernés par cette qualification et ne sont donc pas soumis à l’obligation de constituer un dossier technique IA au titre de l’article 11.

Cette distinction est loin d’être anodine. Elle implique de qualifier correctement son système d’IA, en tenant compte de son usage prévu, de son niveau de risque et de son positionnement réglementaire. Une étape souvent sous-estimée, mais absolument structurante.
Pour une lecture plus complète du cadre réglementaire et des critères de qualification, nous avons d’ailleurs consacré un article spécifique au décryptage de l’AI Act, qui permet de replacer cette exigence dans son contexte global.

Pour Patrick, ce premier filtre est à la fois rassurant… et engageant.
Car ne pas être classé « haut risque » ne dispense pas de réflexion. Au contraire, cela suppose d’être capable de documenter et défendre cette position.

Les vraies questions commencent alors à émerger :

• Mon système entre-t-il réellement dans le périmètre des systèmes d’IA à haut risque ?

• Sur quels critères repose cette qualification ?

• Suis-je capable de l’expliquer de manière claire et argumentée ?

Patrick tombe alors ce schéma qui lui permet d’avoir une première idée de comment classifier son IA.

Mais Patrick n’est pas encore convaincu et cherche à aller plus loin.
Pour aider les organisations à répondre à ces questions, la Commission européenne met à disposition un outil officiel : l’EU AI Act Compliance Checker, que nous avons également analysé dans un article dédié comme point d’entrée opérationnel.

À ce stade, Patrick reconnaît une logique qui lui est déjà familière.
Comme pour un dispositif médical au sens du MDR, la mise sur le marché d’un système d’IA repose sur une démonstration structurée : démonstration de conformité, maîtrise des risques, cohérence entre le produit, son usage et son environnement.

Le dossier technique IA s’inscrit pleinement dans cette continuité.
Il matérialise la capacité de l’organisation à comprendre son système, à en maîtriser les impacts et à en assumer la responsabilité avant toute commercialisation.

Pour Patrick, le message est désormais clair :
le dossier technique IA n’est pas une contrainte qui arrive à la fin du projet.
C’est une clé d’accès au marché, qui se prépare dès les premières décisions de conception.

2. Ce que l’AI Act attend réellement dans le dossier technique

Lecture guidée de l’annexe IV

Une fois la question de la mise sur le marché clarifiée, Patrick ouvre enfin l’annexe IV de l’AI Act.
C’est là que tout se joue.

Loin d’une simple checklist administrative, l’annexe IV décrit ce que doit contenir le dossier technique d’un système d’IA à haut risque. Elle donne surtout une indication essentielle : ce dossier n’est pas un document monolithique, mais un ensemble structuré d’informations, couvrant tout le cycle de vie du système.

Patrick comprend alors une chose fondamentale :
👉 le dossier technique IA ne se “remplit” pas, il se construit.

Et surtout, il ne se construit pas en vase clos.
Il repose sur la capacité de l’organisation à produire, structurer et maintenir les preuves attendues par le règlement.

2.1. Décrire le système : usage, finalité et contexte

L’annexe IV commence par la description générale du système d’IA.

Mais très vite, Patrick réalise que cette description va bien au-delà d’un simple résumé fonctionnel. Le règlement attend notamment :

• la finalité du système,

• les cas d’usage prévus,

• les utilisateurs ciblés,

• et l’environnement d’utilisation.

Autrement dit, il ne s’agit pas seulement de dire ce que fait l’IA, mais dans quelles conditions elle est censée fonctionner — et dans quelles limites.
👉 Sur le plan pratique, Patrick comprend que cette partie ne peut pas être improvisée.

Si l’usage prévu n’est pas clairement défini et partagé en amont (produit, clinique, réglementaire), le dossier technique deviendra rapidement incohérent.

2.2. Conception et architecture : le cœur du dossier

En poursuivant sa lecture, Patrick arrive au cœur du dossier technique : la conception du système.
L’annexe IV demande de documenter :

• la logique de conception,

• l’architecture du système,

• les composants logiciels,

• les interactions entre les modules,

• et les interfaces avec d’autres systèmes.

C’est ici que le dossier technique rejoint directement les choix d’ingénierie.
Chaque décision de conception doit pouvoir être expliquée, justifiée et tracée.

Sur le plan opérationnel, Patrick fait un constat simple :
👉 si ces choix ne sont pas déjà structurés dans le système qualité (spécifications, architecture, décisions de conception), le dossier technique ne sera qu’un exercice de reconstruction a posteriori — long, fragile et risqué.

2.3. Données : un objet réglementaire à part entière

Arrivé à la partie dédiée aux données, Patrick change de posture.
Il comprend que, dans l’AI Act, les données ne sont pas un simple “input technique”, mais un objet réglementaire central.

L’annexe IV attend notamment des informations sur :

• l’origine des données,

• les jeux de données d’entraînement, de validation et de test,

• leur qualité et leur représentativité,

• les mesures mises en place pour limiter les biais.

👉 Sur le terrain, cela signifie une chose très concrète :
les pratiques data doivent être documentées, tracées et reproductibles.

Patrick réalise que, là encore, le dossier technique ne crée pas de nouveaux objets.
Il s’appuie sur des éléments qui devraient déjà exister : gouvernance des données, critères de qualité, justification des choix.

2.4. Performance, robustesse et limites du système

Le dossier technique doit également démontrer que le système d’IA remplit sa fonction, dans des conditions maîtrisées.

L’annexe IV impose de documenter :

• les indicateurs de performance,

• les conditions de fonctionnement normales,

• les limites connues du système,

• et les scénarios de dégradation.

Patrick note un point clé :
👉 le règlement n’attend pas une IA parfaite, mais une IA comprise, testée et encadrée.

D’un point de vue pratique, cela implique que les critères de performance ne peuvent pas être définis uniquement en fin de projet. Ils doivent être pensés dès la conception, en lien avec l’usage prévu.

2.5. Gestion des risques et mesures de contrôle

À ce stade, Patrick se sent en terrain familier.
La logique de gestion des risques lui rappelle fortement le monde du dispositif médical.

Le dossier technique doit démontrer :

• que les risques ont été identifiés,

• que des mesures de mitigation ont été définies,

• que des mécanismes de contrôle, y compris humains, sont en place.

👉 Cette partie agit comme une colonne vertébrale :
elle relie la conception, les données, la performance et l’usage réel du système.

Sur le plan organisationnel, Patrick comprend que cette cohérence n’est possible que si les équipes travaillent sur un système commun, et non sur des documents isolés.

2.6. Informations fournies aux utilisateurs

Enfin, l’annexe IV insiste sur un point souvent traité trop tard : l’information à destination des utilisateurs.
Le dossier technique doit permettre de justifier :

• les instructions d’utilisation,

• les limites d’usage,

• les avertissements,

• et les informations nécessaires à une utilisation appropriée du système.

Patrick réalise que le dossier technique ne vit pas seul.
Il alimente directement les documents opérationnels, et notamment ceux remis aux utilisateurs.

Ce que Patrick retient de l’annexe IV

À la fin de sa lecture, Patrick tire une conclusion très concrète.
Le dossier technique IA n’est pas un projet isolé.

Il repose sur un système de conformité capable de produire automatiquement des preuves cohérentes, au fil du cycle de vie du produit.

Lorsque ce système existe déjà — notamment dans les organisations habituées au MDR — il ne s’agit pas de tout reconstruire, mais de le faire évoluer intelligemment pour répondre aux exigences de l’AI Act.

Et lorsqu’il n’existe pas encore, l’AI Act devient une opportunité rare : celle de structurer ses pratiques dès le départ, sur des bases solides et durables.

3. Dossier technique MDR et dossier technique AI Act : une même logique, des objets différents

Lorsqu’il met en regard les exigences du dossier technique MDR et celles prévues par l’AI Act, Patrick fait un constat qui surprend souvent les équipes lors des premiers échanges : sur le fond, les deux approches reposent sur une logique très proche.

Dans les deux cas, le dossier technique vise à démontrer, avant la mise sur le marché, que le produit est compris, maîtrisé et utilisé dans des conditions définies. Il s’agit de décrire un usage prévu, d’expliquer des choix de conception, d’identifier et de maîtriser les risques, de démontrer des performances, et de fournir aux utilisateurs les informations nécessaires à une utilisation appropriée.

Sous cet angle, le dossier technique exigé par l’AI Act n’introduit pas une nouvelle manière de documenter la conformité. Il s’inscrit dans la continuité des pratiques déjà en place pour le MDR.

La différence réside principalement dans l’objet de la démonstration.

Dans un dossier technique MDR, l’analyse porte sur le dispositif médical dans sa globalité : son fonctionnement, ses composants, ses interactions, ses performances cliniques et sa sécurité. Dans le cadre de l’AI Act, la focale se déplace vers le système d’IA lui-même, en particulier sur les données utilisées, les modèles, leur comportement, leurs limites et leur évolution dans le temps.

Autrement dit, la méthode reste la même, mais le contenu s’adapte.

Les questions posées par le règlement sont identiques : que fait le système, dans quel contexte, avec quels risques, et sous quelles conditions de maîtrise. Ce sont les éléments analysés qui diffèrent, non la logique de fond.

Cette continuité apparaît de manière particulièrement évidente lorsque le dispositif médical repose essentiellement sur une IA. Dans ce type de configuration, les éléments documentés pour répondre aux exigences du MDR et ceux attendus par l’AI Act sont, pour une large part, les mêmes. Ils sont simplement présentés et interprétés à travers deux cadres réglementaires distincts.

Il ne s’agit donc pas de constituer deux dossiers techniques indépendants décrivant deux réalités différentes, mais bien de démontrer, sous deux angles réglementaires, la maîtrise d’un même système. Le dossier technique devient alors un ensemble cohérent de preuves, mobilisées différemment selon le règlement applicable.

Pour Patrick, cette lecture permet de remettre les choses en perspective.

L’AI Act ne remet pas en cause les pratiques existantes des acteurs du dispositif médical. Il étend leur champ d’application à de nouveaux objets — les données, les modèles et le comportement des systèmes d’IA — tout en s’appuyant sur des principes déjà bien établis.

4. Qu’est-ce que je dois faire maintenant que j’ai lu tout ça ?

Arrivé au bout de sa lecture, Patrick a le sentiment d’y voir beaucoup plus clair.

Il comprend le cadre réglementaire, la logique du dossier technique, et la continuité avec ce qu’il connaît déjà du dispositif médical. Mais une étape reste indispensable avant de se lancer : transformer cette compréhension en un plan d’actions cohérent.

Plutôt que d’ouvrir un nouveau document ou de commencer à rédiger, il choisit de faire quelque chose de plus simple. Il prend une feuille et cherche à structurer, noir sur blanc, le raisonnement qu’il va devoir suivre. Non pas pour lister des tâches, mais pour ordonner les décisions à prendre.

Très vite, il réalise que tout ne peut pas être fait en même temps. Certaines questions conditionnent les suivantes. D’autres permettent d’éviter des détours inutiles. Ce qu’il construit progressivement n’est pas une checklist réglementaire, mais un chemin logique, allant de la qualification du produit jusqu’à la capacité réelle de l’organisation à produire des preuves dans le temps.

C’est cette structuration qu’il pose sur le papier.

Une fois sa feuille remplie, Patrick prend du recul et relit ce qu’il a sous les yeux.

Ce qui le frappe d’abord, c’est l’ordre des questions. En commençant par la nature réelle du produit et son cadre réglementaire, il s’assure de ne pas engager l’organisation dans un chantier inutile. En positionnant très tôt la question du dispositif médical et de l’AI Act, il évite également un piège fréquent : traiter l’IA comme un sujet isolé, sans lien avec le reste du produit.

Mais surtout, il réalise que le cœur du raisonnement ne se situe pas au niveau du dossier technique lui-même. Les questions les plus structurantes portent sur l’existence — ou non — d’un système capable de soutenir la conformité dans la durée. Tant que ce point n’est pas clarifié, parler de documentation reste prématuré.

Le chemin qu’il a tracé met aussi en évidence une chose essentielle : documenter une IA n’est pas un exercice ponctuel. Cela suppose que le produit soit correctement cadré, que les usages et les limites soient explicitement définis, que les jeux de données soient identifiés et structurés, et que l’organisation soit en mesure de maintenir ces éléments malgré l’évolution du produit et du cadre réglementaire.

En relisant cette progression, Patrick comprend que cette approche lui permet d’éviter deux écueils classiques. Le premier serait de se lancer trop vite dans la production d’un dossier technique, sans fondations solides. Le second serait de multiplier les initiatives parallèles, au risque de fragmenter le système de conformité existant.

À l’inverse, le raisonnement qu’il a posé lui donne une direction claire. Il ne lui dit pas encore comment faire, mais il lui indique dans quel ordre réfléchir et décider. C’est précisément ce dont il avait besoin pour démarrer les travaux sereinement, en sachant que le dossier technique IA sera le résultat d’un système bien structuré, et non l’objectif isolé d’un projet de conformité.

Conclusion – Le dossier technique IA comme révélateur

Au terme de cette lecture, une chose apparaît clairement : le dossier technique IA n’est ni un document isolé, ni une exigence purement administrative. Il agit plutôt comme un révélateur.

Un révélateur de la manière dont une organisation conçoit ses produits, structure ses décisions et maîtrise ses systèmes dans la durée. Là où certaines exigences peuvent encore être traitées ponctuellement, l’AI Act impose une logique différente : celle d’une démonstration continue, construite bien en amont de la mise sur le marché.

Pour les acteurs de la MedTech, cette exigence n’est pas une rupture. Elle s’inscrit dans la continuité des pratiques déjà connues du MDR, tout en les étendant à de nouveaux objets : les données, les modèles et le comportement des systèmes d’IA. C’est précisément cette continuité qui permet d’aborder l’AI Act sans repartir de zéro, à condition de disposer — ou de mettre en place — un système capable d’absorber ces nouvelles attentes.

À court terme, la tentation peut être de traiter le dossier technique IA comme un chantier supplémentaire. À plus long terme, cette approche montre rapidement ses limites. Les organisations qui tireront réellement parti de l’AI Act seront celles qui l’auront intégré comme un cadre structurant, au même titre que le MDR, et non comme une obligation ponctuelle.

Le dossier technique IA n’est donc pas une fin en soi.

Il est la conséquence naturelle d’un système de conformité mature, capable d’évoluer avec les produits, les usages et le cadre réglementaire. Et c’est sans doute là que se situe l’enjeu principal des prochaines années : non pas produire davantage de documents, mais construire des systèmes suffisamment robustes pour les générer et les maintenir dans le temps.

Article rédigé par Floryan Fantaccino