Lorsque l’AI Act a été publié en 2024, beaucoup ont réagi de la même manière :
encore un texte long, dense, complexe — et encore une nouvelle couche réglementaire à absorber.
J’ai fait exactement ce que font la plupart des responsables produit, réglementaires ou innovation : j’ai ouvert le règlement, café à la main, stylo prêt… et j’ai commencé à lire.

Très vite, une chose saute aux yeux : ce texte ne ressemble pas aux autres.
Ce n’est ni un règlement purement technique, ni un texte sectoriel classique. L’AI Act est l’un des premiers cadres réglementaires de portée internationale à tenter d’encadrer l’intelligence artificielle de manière transversale, tous secteurs confondus. Santé, finance, industrie, ressources humaines, services publics : tout le monde est concerné, avec une ambition claire — poser un cadre commun avant que les usages ne deviennent incontrôlables.

Cette ambition a un prix : la complexité.
Écrire un règlement capable de s’appliquer à des réalités aussi différentes impose des compromis. Le texte devient plus abstrait, plus conceptuel, parfois déroutant à la première lecture. On cherche rapidement où sont les obligations, ce qu’il faut produire, par quoi commencer — et on se perd souvent avant même d’avoir compris la logique d’ensemble.

Dans le monde des dispositifs médicaux numériques, pourtant, cette lecture mérite d’être nuancée.
En avançant dans le texte, une impression familière émerge. Qualification préalable, approche par les risques, démonstration de conformité avant mise sur le marché, responsabilité des acteurs, capacité à produire des preuves dans le temps… La structure de l’AI Act diffère finalement assez peu de celle que nous connaissons déjà avec le MDR.
Pour certains secteurs, l’AI Act introduit une logique entièrement nouvelle. Pour la santé, il s’inscrit davantage comme une extension du cadre existant, avec de nouveaux objets à maîtriser : données, modèles, comportements des systèmes d’IA.

C’est avec ce regard que cet article a été écrit.
Plutôt que de commenter article par article, ou de lister des obligations, j’ai choisi une autre approche : lire le texte comme on mène une enquête. Chercher l’intention du législateur, comprendre la structure du règlement, identifier les décisions structurantes qu’une organisation doit prendre avant même de parler de mise en œuvre.

Même si l’AI Act couvre de nombreux domaines, l’analyse proposée ici est volontairement centrée sur le monde de la santé et des dispositifs médicaux numériques. C’est dans ce contexte que les parallèles, les continuités — et parfois les écarts — prennent tout leur sens.

La question qui va guider cette enquête est simple :
Comment lire l’AI Act pour comprendre ce qu’il attend réellement d’une organisation de santé — et savoir quoi structurer, et dans quel ordre, avant d’agir ?

« Je vous propose de plonger dans ma tête et dans mes recherches. Pour cet article, j’ai chaussé pour vous mes chaussures — et ma casquette — de grand reporter réglementaire. » Floryan Fantaccino

1. Pourquoi l’AI Act existe (et pourquoi il ne ressemble pas aux autres règlements)

Quand on ouvre l’AI Act pour la première fois, une question finit toujours par arriver.
Pas tout de suite. Elle arrive après quelques pages, souvent entre deux considérants, quand on commence à se demander si on est en train de lire un règlement, un manifeste politique ou un roman administratif un peu trop ambitieux.

La question, c’est : pourquoi ce texte existe-t-il vraiment ?

Pas “pourquoi l’UE régule l’IA” — ça, on l’a tous compris.
Mais pourquoi ce texte-là, avec cette structure, cette approche, et cette impression étrange qu’il ne ressemble à rien de vraiment connu.

J’ai donc fait ce que ferait n’importe quel grand reporter réglementaire digne de ce nom : j’ai remonté le fil. Et très vite, une première évidence s’impose.

👉 L’AI Act n’est pas né d’un problème technique.
👉 Il est né d’un problème de gouvernance.

Un texte né d’un vide… qui devenait franchement gênant

L’IA n’a pas attendu l’AI Act pour s’inviter partout.
Dans la santé, évidemment. Mais aussi dans le recrutement, le crédit, l’éducation, la surveillance, les services publics. Les usages se sont installés vite. Très vite.

Côté réglementation, en revanche, le décor était beaucoup moins clair.
Un peu de RGPD par-ci, quelques règles sectorielles par-là, beaucoup de “bonnes pratiques”, et surtout une grande zone grise dès qu’une question simple était posée :

👉 Qui est responsable quand une décision automatisée a un impact réel sur une personne ?

En avançant dans les considérants et les travaux préparatoires, on comprend que c’est précisément cette question qui a mis tout le monde d’accord. Le risque identifié n’était pas “une IA qui bugge”, mais quelque chose de bien plus diffus :

• des décisions de plus en plus automatisées,

• des chaînes d’acteurs de plus en plus longues,

• des systèmes capables d’évoluer après leur mise sur le marché,

• et des impacts bien réels… sans responsable clairement identifié.

Bref : beaucoup de puissance, beaucoup d’autonomie… et pas toujours beaucoup de gouvernance.
À un moment, il fallait bien mettre un cadre.

Pourquoi un texte pour tout le monde (et pourquoi ça complique tout)

Deuxième découverte en poursuivant l’enquête :
l’AI Act n’a pas été écrit pour un secteur en particulier.

Ce n’est pas “le règlement IA pour la santé”.
Ni “le règlement IA pour la finance”.
C’est un texte horizontal, pensé pour couvrir tous les domaines concernés par l’IA.

Et là, soyons honnêtes : écrire un cadre commun pour des réalités aussi différentes, ce n’est pas exactement l’exercice le plus simple du monde.

Résultat :

• un texte long,

• parfois abstrait,

• souvent déroutant à la première lecture,

• et cette impression persistante que “tout le monde est concerné, mais personne ne se reconnaît complètement”.

Mais ce flou n’est pas un accident. Il est voulu.

En creusant un peu, le raisonnement du législateur apparaît assez clairement :
ce n’est pas la technologie qui pose problème, c’est l’usage qu’on en fait. Une même IA peut être parfaitement anodine dans un contexte, et extrêmement sensible dans un autre. D’où cette idée centrale qui traverse tout le règlement :

👉 regarder l’usage, puis le risque, avant de décider du reste.

Un texte qui parle moins d’IA… que de responsabilités

Plus je progressais dans la lecture, plus un autre constat s’imposait.
L’AI Act ne cherche pas vraiment à expliquer comment développer une “bonne IA”. Il s’intéresse à des questions beaucoup plus concrètes — et beaucoup plus politiques, au fond :

• qui est responsable ?

• à quel moment ?

• et comment cette responsabilité peut-elle être démontrée ?

On y parle finalement assez peu d’algorithmes, et beaucoup de rôles, de processus, de démonstration de maîtrise, de capacité à expliquer ce que fait le système — avant, pendant et après sa mise sur le marché.

Dit autrement :
l’AI Act ne dit pas “faites comme ci ou comme ça”.
Il dit plutôt : “soyez capables d’expliquer, de justifier et d’assumer vos systèmes d’IA”.
Et ça change beaucoup de choses.

Dans la santé, un air de déjà-vu… plutôt rassurant

En lisant tout cela avec un regard “santé” ou “dispositif médical numérique”, une sensation familière finit par apparaître.

Qualification préalable, approche par les risques, démonstration de conformité avant mise sur le marché, responsabilité des acteurs, traçabilité des décisions… tout cela rappelle fortement ce que nous connaissons déjà avec le MDR et les systèmes qualité.

La vraie différence ne se situe pas tant dans la méthode que dans l’objet analysé.

Là où le MDR se concentre sur le dispositif médical dans son ensemble, l’AI Act déplace la focale vers des éléments longtemps restés en arrière-plan : les données, les modèles, le comportement des systèmes d’IA et leur évolution dans le temps.

À ce stade de l’enquête, une conclusion commence à s’imposer assez naturellement :

pour les dispositifs médicaux numériques, l’AI Act ne crée pas une nouvelle manière de penser la conformité. Il étend une logique existante à de nouveaux objets, avec toutes les conséquences que cela implique.

Et forcément, une fois ce cadre posé, la prochaine question devient presque évidente :

👉 Avant de savoir ce que je dois faire… où est-ce que je me situe dans ce règlement ?

➡️ C’est exactement là que commence la section 2 : classer avant d’agir.

2. La logique centrale de l’AI Act : classer avant d’agir

Après avoir compris pourquoi ce texte existe, un réflexe revient presque systématiquement.
On cherche les obligations. Les interdictions. Les fameuses lignes qui diraient clairement « voilà ce que vous devez faire ». Je l’ai fait moi aussi. Et soyons honnêtes : ce n’est pas exactement la bonne porte d’entrée.

En continuant à lire, puis à relire (oui, certaines parties méritent clairement une deuxième lecture), un constat s’impose : l’AI Act ne commence pas par des obligations, il commence par une question. Une question simple en apparence, mais redoutablement structurante :

👉 De quel type de système d’IA parle-t-on exactement ?

Autrement dit, avant d’agir, il faut classer.

Classer, ce n’est pas cocher une case (malheureusement)

Dans l’AI Act, la classification n’est pas un exercice administratif qu’on expédie entre deux réunions.
C’est une décision de gouvernance qui conditionne tout le reste : le niveau d’exigence, la profondeur de la démonstration attendue, les responsabilités à assumer… et parfois même la possibilité de mettre le système sur le marché.

En avançant dans le texte, on comprend que cette classification repose sur une idée très simple : tous les systèmes d’IA ne présentent pas le même niveau de risque. Certains usages sont jugés inacceptables, d’autres fortement encadrés, d’autres encore soumis à des obligations plus légères, voire à aucune obligation spécifique.

Dit autrement, le règlement met rapidement de l’ordre :

• ce qui est interdit,

• ce qui est autorisé sous conditions strictes,

• ce qui est autorisé avec des obligations de transparence,

• et ce qui reste libre d’usage.

Ce n’est pas spectaculaire. Mais c’est redoutablement efficace pour structurer la suite.

Le piège classique : croire que la classification est technique

C’est là que les choses se compliquent — et que beaucoup d’organisations trébuchent.
Le problème, c’est que la classification de l’AI Act n’est pas qu’une affaire de modèle ou d’algorithme. Elle repose sur des éléments beaucoup plus concrets, et parfois beaucoup plus flous :

• l’usage prévu,

• le contexte d’utilisation,

• les utilisateurs concernés,

• et les impacts potentiels sur les personnes.

Autrement dit, deux systèmes techniquement très proches peuvent tomber dans des catégories radicalement différentes… simplement parce qu’ils ne servent pas le même objectif.

À ce stade, je vous vois venir.
« Très bien, Floryan. J’ai compris le principe. Mais concrètement, je fais comment ? »
Question légitime.

Quand le grand reporter continue à chercher (et tombe sur une pépite)

J’aurais pu m’arrêter là, refermer le texte et vous laisser avec cette grande vérité réglementaire sous le bras.
Mais ce n’est pas vraiment ce qu’on attend d’un grand reporter. Et surtout, ce n’est probablement pas ce que vous, lecteur, attendez de moi.

Alors j’ai continué à chercher.

Bonne nouvelle : je n’ai pas eu besoin d’aller très loin.
Sophie m’a mis sur une piste intéressante — une vraie pépite, impossible à ignorer dans une enquête sérieuse : l’EU AI Act Compliance Checker, mis à disposition par la Commission européenne.

Heureusement qu’ils ont eu cette idée.
Sans cet outil, je serais probablement encore en train de relire les annexes en me demandant si mon IA relève du bon périmètre… ou si c’est juste moi qui avais besoin d’un autre café.

Ce Compliance Checker ne “fait pas la conformité à votre place”.
Mais il joue parfaitement son rôle de boussole initiale : il aide à se situer dans le règlement, à comprendre quels blocs vous concernent réellement, et à éviter de partir dans la mauvaise direction dès le départ.
Sophie a d’ailleurs pris le temps d’en décrypter le fonctionnement dans un article dédié, si vous êtes précisément à cette étape de questionnement.

Une fois classé, le texte change de visage

Ce qui est frappant, une fois cette étape franchie, c’est que l’AI Act devient soudainement plus lisible.
Certains articles prennent de l’importance, d’autres passent au second plan, et certains cessent tout simplement de s’appliquer.

La conformité IA ne commence donc ni par un document, ni par un outil, ni par un processus complexe.
Elle commence par une décision claire et argumentée : savoir où se situe son système dans le cadre du règlement.

Et une fois cette décision prise, une autre évidence apparaît :
le règlement n’est pas un bloc uniforme. Il est structuré en ensembles cohérents, pensés pour des rôles et des situations différentes.

➡️ C’est exactement ce que nous allons explorer dans la section 3 : comment le règlement est structuré — et comment une entreprise le traverse.

3. Comment le règlement est structuré (et comment une entreprise le traverse)

Je préfère être honnête dès le début : cette section m’a coûté une quantité indécente de café.
Pas un espresso de confort. Non. Du café de survie. Celui qu’on boit quand on s’attaque à un texte long, dense, et suffisamment subtil pour que chaque relecture donne l’impression de découvrir un nouveau détail.

J’ai bien sûr fait ce que beaucoup feraient aujourd’hui : j’ai utilisé l’IA comme outil d’analyse, pour m’aider à poser les bonnes questions, repérer des motifs récurrents, structurer les idées. Et elle fait ça très bien. Vraiment très bien.

Mais soyons clairs : l’IA ne lit pas le règlement à ta place.
Elle aide à réfléchir. Elle n’assume pas la responsabilité de l’interprétation. Et surtout, elle ne t’empêche pas de raconter des bêtises si tu ne retournes pas au texte.

Résultat : j’ai lu l’AI Act. Puis je l’ai relu. Puis relu encore.
Cinq fois au total. Pas par masochisme réglementaire (enfin… pas seulement), mais pour être sûr d’une chose : ne pas trahir la logique du texte, et ne pas simplifier au point de la déformer.

Et c’est là que quelque chose devient intéressant.

Le règlement n’est pas un bloc : il est construit comme un parcours

À force de lectures, une évidence finit par émerger :
l’AI Act n’a pas été écrit comme un code qu’on consulte article par article. Il a été pensé comme un parcours logique, que les entreprises sont censées traverser.

Ce n’est pas un texte qui dit “voici toutes les règles”.
C’est un texte qui dit plutôt : “selon qui vous êtes, ce que vous faites et ce que vous mettez sur le marché, voici les blocs qui vous concernent”.

Autrement dit, la structure du règlement raconte déjà une histoire.

Des rôles avant des obligations

Un autre point saute aux yeux quand on prend un peu de recul :
l’AI Act parle très tôt de rôles. Fournisseur, déployeur, importateur, distributeur… ce n’est pas un hasard.

Le règlement ne part pas du principe qu’il existe “un responsable unique de l’IA”. Il part du principe inverse : les systèmes d’IA circulent, changent de mains, évoluent, sont intégrés dans d’autres produits.
Chaque rôle correspond donc à :

• des responsabilités spécifiques,

• des obligations adaptées,

• et un niveau de maîtrise attendu différent.

C’est aussi pour cela que beaucoup d’entreprises se trompent de lecture :
elles cherchent leurs obligations sans avoir clarifié quel rôle elles jouent réellement dans la chaîne de valeur.

Des exigences structurantes… et d’autres plus opérationnelles

En avançant dans le texte, on distingue assez nettement deux types d’exigences.
D’un côté, des exigences structurantes :

• qualification du système,

• gestion des risques,

• gouvernance des données,

• capacité à documenter et expliquer le fonctionnement du système.

De l’autre, des exigences plus opérationnelles :

• informations à fournir aux utilisateurs,

• modalités de surveillance,

• obligations de transparence spécifiques.

Le piège classique consiste à traiter ces deux niveaux au même moment.
Or, le règlement suggère exactement l’inverse : les exigences structurantes conditionnent tout le reste. Sans elles, les obligations opérationnelles deviennent vite incohérentes ou impossibles à tenir dans la durée.

Comment une entreprise traverse réellement le texte

À ce stade, la lecture change encore de nature.

On ne lit plus le règlement comme une liste d’articles, mais comme une succession d’étapes :

1. Se situer dans le champ d’application et le niveau de risque

2. Clarifier son rôle dans la chaîne de valeur

3. Comprendre quelles capacités organisationnelles sont attendues

4. Puis seulement, décliner les obligations concrètes

C’est précisément ce cheminement que beaucoup d’organisations ratent, en commençant trop tôt par la fin.

Ce que cette section m’a appris — café aidant — c’est que l’AI Act n’est pas un mur juridique à escalader d’un coup.
C’est un texte construit pour être traversé, à condition de respecter l’ordre implicite qu’il propose.
Et une fois cette structure comprise, une autre question devient inévitable :
qu’est-ce que le règlement attend réellement des organisations, au-delà des articles et des obligations formelles ?

➡️ C’est exactement ce que nous allons explorer dans la section 4 : ce que l’AI Act attend réellement des organisations.

4. Ce que l’AI Act attend réellement des organisations

À ce stade de l’enquête, une tentation devient difficile à ignorer.

On a compris le pourquoi, le classement, la structure du texte… et forcément, une petite voix commence à murmurer :
« Ok, très bien. Mais concrètement, qu’est-ce qu’on attend de moi, là ? »

Spoiler :
si tu cherches une liste claire de documents à produire ou une checklist prête à l’emploi, tu risques d’être déçu. J’ai cherché. Longtemps. Café aidant. Et ce n’est pas là que le règlement veut t’emmener.

En réalité, plus on lit l’AI Act, plus une chose devient évidente :
le texte parle beaucoup moins de documents que de capacités.

Le règlement ne demande pas “ce que vous avez”, mais “ce que vous êtes capables de faire”

C’est probablement l’un des points les plus mal compris.
L’AI Act ne se demande pas si tu as un document, une procédure ou un fichier bien rangé quelque part. Il se demande si ton organisation est capable, dans la durée, de maîtriser ses systèmes d’IA.

Et cette capacité se décline de manière assez concrète.
D’abord, être capable de comprendre son propre système.
Pas au sens “on sait qu’il existe”, mais au sens :

• à quoi il sert exactement,

• dans quels contextes il est censé fonctionner,

• et surtout, dans quelles limites.

Ensuite, être capable de maîtriser les données.
D’où viennent-elles ? À quoi servent-elles ? Sont-elles adaptées à l’usage prévu ? Comment évoluent-elles dans le temps ? Ici, le règlement n’attend pas la perfection. Il attend de la lucidité et de la traçabilité.

Puis, être capable de tracer les décisions.
Pourquoi ce choix de conception ? Pourquoi ce modèle ? Pourquoi ce seuil ? Pourquoi cette règle métier ? Autant de “pourquoi” qui, jusque-là, restaient souvent implicites — et que l’AI Act force à rendre explicites.

Enfin, être capable de gérer les risques de manière cohérente.
Identifier ce qui peut mal se passer, prévoir des mesures de maîtrise, mettre en place des contrôles (y compris humains), et accepter que le risque zéro n’existe pas… mais que l’ignorance, elle, n’est plus acceptable.

Pourquoi le texte parle de systèmes (et pas de paperasse)

En continuant à décortiquer le règlement, un détail de vocabulaire devient révélateur.
L’AI Act parle sans cesse de systèmes : systèmes d’IA, systèmes de gestion des risques, systèmes de surveillance, systèmes de gouvernance.

Ce n’est pas un hasard.

Le législateur part d’un constat simple :
un document peut être produit une fois.
Un système, lui, fonctionne dans le temps.

Et comme les systèmes d’IA évoluent — modèles mis à jour, données enrichies, usages étendus — le cadre de conformité doit être capable d’évoluer lui aussi. Un PDF figé ne suffit plus.

Dit autrement :
le règlement ne cherche pas à vérifier que tu as bien fait ton devoir à un instant T. Il cherche à savoir si ton organisation saura tenir la route quand l’IA changera. Pour cela, il y a le dossier technique de l’IA. D’ailleurs, dans ma grande bonté, tu as un article qui vient le décrypter. Profites-en !

Une attente très claire… mais rarement formulée ainsi

Si je devais résumer ce que l’AI Act attend réellement des organisations en une phrase, ce serait celle-ci :
👉 être capables d’expliquer, de justifier et d’assumer leurs systèmes d’IA, avant et après leur mise sur le marché.

Tout le reste — articles, annexes, obligations — découle de cette attente centrale.

Ce qui explique pourquoi tant d’entreprises se sentent démunies :
elles cherchent des réponses opérationnelles à une question qui est, au fond, organisationnelle.

À ce stade de l’enquête, une chose devient claire.
Le problème n’est pas tant ce qu’il faut faire, que quand et sur quelles bases le faire. Et surtout, à quel moment du cycle de vie du produit ces capacités doivent exister.

Ce qui nous amène naturellement à la question suivante :
si ces capacités sont attendues, quand faut-il réellement les mettre en place ?

➡️ C’est exactement l’objet de la section 5 : pourquoi l’AI Act se joue dès la conception (et pas à la fin).

5. Pourquoi l’AI Act se joue dès la conception (et pas à la fin)

À ce stade de l’enquête, j’ai commencé à voir apparaître un réflexe très humain — et très répandu.
Un réflexe que j’ai croisé des dizaines de fois dans d’autres cadres réglementaires, et qui refait surface ici presque mécaniquement :
« Ok, on développe le produit.
Et quand il sera prêt, on fera la conformité. »

Sur le papier, ça paraît raisonnable.
Dans la réalité de l’AI Act, c’est souvent le meilleur moyen de se compliquer la vie.

Le fantasme du “on verra plus tard”

En lisant le règlement, on pourrait croire que la conformité IA est une étape finale.
Quelque chose qu’on déclenche quand le système est stabilisé, quand les choix techniques sont faits, quand le produit ressemble enfin à quelque chose de présentable.

Sauf que… le texte raconte une toute autre histoire.

À plusieurs reprises, l’AI Act insiste sur des éléments qui ne peuvent pas être inventés à la fin :

• l’usage prévu,

• les limites du système,

• la logique de conception,

• les choix de données,

• les hypothèses de départ.

Autant d’éléments qui, soyons honnêtes, se figent très tôt dans un projet.
Souvent bien avant que quelqu’un ne prononce le mot “conformité” dans une réunion.

Ce que le règlement ne dit pas explicitement… mais montre très bien

L’AI Act ne dit jamais noir sur blanc :
« vous devez intégrer la conformité dès la conception ».

Il fait quelque chose de plus subtil — et de plus redoutable :
il conditionne les exigences à des décisions prises très en amont.

En pratique, cela signifie une chose assez simple :
si certaines questions n’ont pas été posées au bon moment, il devient extrêmement difficile d’y répondre proprement plus tard.

Par exemple :

• comment justifier un usage prévu qui n’a jamais été formalisé ?

• comment expliquer un choix de données “historique” si personne ne sait vraiment pourquoi il a été fait ?

• comment documenter des limites qui n’ont jamais été explicitement discutées ?

À ce stade, la conformité devient un exercice de reconstruction.
Long. Fragile. Et rarement satisfaisant.

Un air de déjà-vu pour ceux qui connaissent le MDR

Si tout cela te rappelle quelque chose, c’est normal.
Dans le monde des dispositifs médicaux, on sait depuis longtemps que :

• la gestion des risques ne se rattrape pas à la fin,

• la définition de l’usage prévu structure tout le reste,

• et un dossier technique “reconstruit” est toujours plus faible qu’un dossier construit au fil de l’eau.

L’AI Act ne fait finalement que transposer cette logique au monde des systèmes d’IA.
La méthode est familière. Les objets changent.

Ce qui change aussi, c’est la vitesse.
Les systèmes d’IA évoluent plus vite que les dispositifs “classiques”. Et plus ça va vite, plus les décisions prises tôt ont de l’impact.

Ce que révèle vraiment une approche tardive

En creusant cette question, un constat un peu inconfortable apparaît.
Quand une organisation découvre “trop tard” les exigences de l’AI Act, le problème n’est souvent pas le règlement.

Le problème, c’est qu’aucun cadre n’avait été posé :

• ni sur les usages,

• ni sur les limites,

• ni sur la manière dont les décisions sont prises et conservées.

L’AI Act agit alors comme un révélateur.
Il ne crée pas le désordre, il le met en lumière.

Concevoir avec l’AI Act en tête, ce n’est pas brider l’innovation

C’est souvent l’objection qui arrive à ce moment-là :
« Si on pense conformité dès la conception, on va tuer l’innovation. »
À la lecture du texte, c’est exactement l’inverse qui apparaît.
Le règlement ne demande pas de figer les systèmes. Il demande de savoir expliquer comment et pourquoi ils évoluent.

Concevoir avec l’AI Act en tête, ce n’est pas ajouter des freins.
C’est :

• clarifier les hypothèses,

• expliciter les choix,

• et éviter les zones grises qui explosent plus tard.

À ce stade de l’enquête, une chose devient difficile à contester :
si l’AI Act se joue si tôt, alors la vraie question n’est plus “comment être conforme ?”, mais “quand commencer ?”.

Et pour y répondre, il faut accepter une dernière réalité :
le règlement ne s’applique pas d’un seul coup. Il arrive par étapes, avec un calendrier qui mérite d’être compris pour éviter les faux départs.

➡️ C’est exactement ce que nous allons explorer dans la section 6 : mise en œuvre progressive — comment se projeter jusqu’en 2027 sans subir.

6. Mise en œuvre progressive : comment se projeter jusqu’en 2027 sans subir

Arrivé à ce stade de l’enquête, une réaction revient souvent.

Elle se lit parfois dans les yeux, parfois dans les mails, parfois dans un soupir un peu résigné :
« Oui mais bon… 2027, on a encore le temps, non ? »

Alors oui.
Et non.
Oui, parce que l’AI Act ne s’applique pas d’un seul bloc.
Non, parce que le temps réglementaire et le temps des organisations ne jouent pas dans la même catégorie.

Un calendrier progressif… mais pas décoratif

En relisant attentivement les dispositions transitoires, on comprend vite que le législateur n’a pas cherché à piéger qui que ce soit. Le calendrier est progressif, étalé, lisible. Il laisse de la place pour s’adapter.

Mais cette progressivité n’est pas une invitation à l’attentisme.
Elle est plutôt un outil de priorisation.

Certaines interdictions arrivent tôt et sont déjà là.
Certaines obligations s’installent progressivement.
Et d’autres exigences supposent, de toute façon, que les fondations aient été posées bien avant leur date d’entrée en application.

Autrement dit :
le temps donné n’est pas du temps “vide”.
C’est du temps pour structurer intelligemment.

Pourquoi 2027 arrive plus vite qu’on ne le pense

Dans les discussions, 2027 paraît loin.
Dans les projets, c’est une autre histoire.

Quand on parle d’IA, on parle de :

• clarification des usages,

• structuration des données,

• alignement produit / réglementaire / technique,

• mise en place de modes de gouvernance,

• outillage,

• acculturation des équipes.

Rien de tout cela ne se fait en quelques semaines, surtout dans des organisations déjà bien chargées.
À ce stade, l’AI Act ne pose donc pas une question de délai réglementaire, mais une question très pragmatique :
👉 combien de temps me faut-il réellement pour faire évoluer mon organisation ?

Se projeter sans paniquer (et sans procrastiner)

La bonne lecture du calendrier n’est ni alarmiste, ni laxiste.

Elle consiste plutôt à se dire :

• maintenant : comprendre, qualifier, structurer les bases

• à moyen terme : consolider les capacités, aligner les pratiques, outiller

• plus tard : démontrer, maintenir, ajuster

C’est précisément pour cela que le texte insiste autant sur la logique, les rôles et les capacités, bien avant de parler de sanctions ou de contrôles.
L’AI Act ne cherche pas à surprendre.
Il cherche à transformer progressivement les pratiques.

À ce stade de l’enquête, une chose devient assez claire :
ceux qui subiront l’AI Act ne seront pas ceux qui manquent de temps, mais ceux qui auront mal lu le tempo.
Et une fois ce calendrier compris, il reste une dernière étape : prendre un peu de hauteur et comprendre comment tout cela s’articule.

Conclusion – Comprendre le texte pour structurer la suite

Après plusieurs lectures, beaucoup de café, quelques allers-retours entre articles et annexes, et pas mal de questions posées au texte (et à moi-même), une conviction s’est installée.

L’AI Act n’est ni un monstre réglementaire, ni un simple texte de conformité.
C’est un socle.
Un socle commun sur lequel vont venir se poser :

• des démonstrations,

• des documents,

• des outils,

• et, surtout, des décisions organisationnelles.

L’AI Act comme révélateur, pas comme contrainte isolée

Ce que montre cette lecture, c’est que l’AI Act agit rarement comme un problème nouveau.
Il agit plutôt comme un révélateur :

• de la maturité des organisations,

• de la clarté des usages,

• de la solidité des systèmes existants.

Pour les acteurs de la santé et des dispositifs médicaux numériques, ce révélateur est souvent moins brutal qu’on ne l’imagine. La logique est connue. Les principes sont familiers. Ce sont les objets qui changent.
Et comme souvent en réglementation, ceux qui s’en sortiront le mieux ne seront pas ceux qui auront produit le plus de documents, mais ceux qui auront construit les bons systèmes pour les produire et les maintenir.

Si je devais conclure cette enquête en une phrase, ce serait celle-ci :
👉 l’AI Act ne te demande pas d’aller plus vite, mais d’aller dans le bon ordre.
Et maintenant que le cadre est posé, la suite devient beaucoup plus lisible.

Article rédigé par Floryan Fantaccino & l’IA