Le règlement européen sur l'IA : guide de conformité pour dirigeants (édition 2026)

Pourquoi ce guide existe, et à qui il s'adresse

L'essentiel de ce qui s'écrit sur le règlement européen sur l'IA est écrit pour des juristes, par des juristes, et cela se sent. On y parcourt les considérants, on y dissèque les définitions, et l'on s'arrête exactement là où commencent les questions d'un dirigeant. Les questions qu'un cadre se pose réellement sont plus directes. Est-ce que cela s'applique au système que mon équipe livre le trimestre prochain ? Si oui, que dois-je construire avant la mise en production, et qui dans mon organigramme en est responsable ? Quelle est l'échéance, et combien coûte de la manquer ? Ce texte répond à ces quatre questions et à peu d'autres.

La question du coût est celle qui concentre l'attention, alors prenons-la en premier. Le règlement est le règlement (UE) 2024/1689, adopté le 13 juin 2024, et son cadre de sanctions à l'article 99 est gradué selon la gravité de l'infraction. Déployez une pratique interdite et l'exposition atteint 35 000 000 € ou 7 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Enfreignez la plupart des autres obligations opérationnelles — les exigences relatives au haut risque, les obligations de transparence, les obligations du déployeur — et le plafond est de 15 000 000 € ou 3 %. Même fournir des informations inexactes ou trompeuses à un régulateur ou à un organisme notifié coûte jusqu'à 7 500 000 € ou 1 %. Ce sont des montants de classe RGPD, calculés sur le chiffre d'affaires du groupe, appliqués à un corpus de droit que la plupart des conseils d'administration ne connaissaient pas il y a dix-huit mois. Voilà l'enjeu.

Le règlement ne mord pas seulement ceux qui construisent des modèles. Il est articulé autour de deux rôles, et le second attrape presque tout le monde. Un fournisseur développe un système d'IA et le met sur le marché sous son propre nom. Un déployeur utilise un système d'IA sous sa propre autorité dans un cadre professionnel. Si votre entreprise a acheté un outil de tri de CV, un service de scoring de fraude ou un agent conversationnel orienté client et l'a mis en service, vous êtes un déployeur, et le règlement vous assigne des obligations qu'aucune paperasse fournisseur ne transfère ailleurs. Ce guide s'adresse donc aux deux publics : le fournisseur qui construit ou affine un système, et — plus fréquemment — le dirigeant qui en a acheté un et qui assume désormais la conséquence de l'exploiter. Si vous vous trouvez de l'un ou l'autre côté de cette ligne et que vous opérez sur le marché européen, ou vendez vers lui, les sept sections suivantes sont votre référence de travail.

Un mot sur ce que ce guide n'est pas. Ce n'est pas un conseil juridique, et il ne remplace pas l'avis d'un avocat sur un système précis — le règlement dépend des faits, et c'est dans les faits que se loge le jugement. Ce qu'il vous donne, c'est la carte du dirigeant : la structure du régime, la logique de classification que vous pouvez exécuter vous-même, l'ensemble des obligations par niveau et le calendrier que vous devez piloter. Lisez-le comme vous liriez une note interne bien sourcée avant de briefer le conseil.

Note de méthode

La date d'arrêté de cette édition est le 1^er juin 2026. Les obligations du règlement s'activent par phases de 2025 à 2027, et le détail de mise en œuvre — normes harmonisées, orientations de la Commission, actes délégués ajustant les seuils — est encore en cours d'écriture. Tout ce qui suit reflète le texte juridique et la position publiquement connue à cette date. Les éditions suivantes conserveront la précédente à une URL datée afin que quiconque cite ce texte puisse figer la version qu'il a référencée.

La source primaire est le règlement lui-même. Chaque date, seuil, catégorie de risque, numéro d'article et montant de sanction de ce guide est tiré du règlement (UE) 2024/1689 tel que publié au Journal officiel de l'Union européenne, et non de résumés secondaires. Là où ce texte nomme un article — l'article 5 pour les pratiques interdites, l'article 6 et l'annexe III pour le haut risque, l'article 50 pour la transparence, l'article 51 pour les modèles GPAI à risque systémique, l'article 99 pour les sanctions, l'article 113 pour les dates d'application — le texte de l'article a été vérifié contre le Journal officiel. Nous ne paraphrasons pas une disposition que nous n'avons pas lue.

Là où le droit n'est pas stabilisé, ce texte le dit plutôt que d'inventer une précision. Les normes harmonisées sont encore en développement ; les orientations de la Commission sur plusieurs dispositions sont appelées à évoluer ; le seuil de calcul du risque systémique peut être modifié par acte délégué. Dans chacun de ces cas, le guide énonce le principe et signale que le détail opérationnel bouge. L'objectif est un document sur lequel un dirigeant peut agir sans être induit en erreur par une fausse certitude — les parties figées dans le texte juridique sont présentées comme figées, et celles qui restent à compléter sont étiquetées comme telles.

Cette édition est écrite et signée par Consulting Huber. Elle porte volontairement un biais de praticien : elle est organisée autour des décisions qu'un dirigeant doit prendre et des contrôles qu'une organisation doit mettre en place, et non autour de la structure doctrinale qu'un commentaire juridique suivrait. Pour la structure doctrinale, lisez le règlement. Pour la question de ce qu'il faut faire lundi, lisez la suite.

Le règlement en une page

Retirez les considérants et l'architecture est simple. Le règlement européen sur l'IA est une réglementation de sécurité des produits, fondée sur le risque, appliquée à l'IA. Il ne régule pas la technologie dans l'abstrait ; il trie les systèmes d'IA en niveaux de risque selon ce à quoi ils servent, et il attache un ensemble proportionné d'obligations à chaque niveau. Plus le risque pour la santé, la sécurité ou les droits fondamentaux est élevé, plus les obligations sont lourdes — jusqu'à l'interdiction pure et simple. La plupart des systèmes relèvent du niveau le plus bas et ne portent aucune nouvelle obligation. Le poids du régime se concentre sur une bande définie de cas d'usage à haut risque et sur une poignée de pratiques qu'il interdit catégoriquement.

La distinction fournisseur / déployeur est le pivot. L'article 3, point 3, définit un fournisseur comme une partie qui développe un système d'IA ou un modèle d'IA à usage général — ou en fait développer un — et le met sur le marché ou en service sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. L'article 3, point 4, définit un déployeur comme une partie qui utilise un système d'IA sous sa propre autorité, sauf dans le cadre d'une activité personnelle à caractère non professionnel. Les deux rôles portent des ensembles d'obligations différents, et les obligations les plus lourdes — évaluation de la conformité, documentation technique, ingénierie du système lui-même — reposent sur le fournisseur. Mais les déployeurs sont eux aussi clairement visés. Un déployeur d'un système à haut risque doit l'exploiter selon la notice, affecter un contrôle humain compétent, le surveiller, conserver les journaux qu'il génère et informer les personnes qu'il affecte. L'erreur classique au niveau du conseil est de supposer qu'acheter un système à un fournisseur exporte le risque avec la facture. Ce n'est pas le cas. Le contrat d'achat répartit la responsabilité commerciale entre les parties ; il ne dispense pas le déployeur des obligations que le règlement place directement sur les déployeurs.

La portée est extraterritoriale. Le règlement suit la sortie, pas le siège. Un fournisseur ou un déployeur établi hors de l'Union européenne entre dans le champ dès lors que la sortie produite par le système d'IA est utilisée dans l'Union. Une entreprise américaine qui note des candidats à l'emploi européens, ou un fournisseur de modèle dont le système est mis en service dans un État membre, ne peut pas se placer hors du régime en se plaçant hors de la géographie. Si votre IA touche le marché européen — par ses utilisateurs, ses clients ou l'usage de sa sortie dans l'Union — partez du principe que vous êtes dans le champ jusqu'à ce qu'un avocat vous dise le contraire. Cette unique hypothèse est le mode opératoire prudent par défaut, et c'est la prémisse sur laquelle tourne le reste de ce guide.

Les quatre niveaux de risque, avec exemples concrets

La taxonomie de la Commission trie chaque système d'IA dans l'un de quatre niveaux. Les ancrages juridiques de trois d'entre eux se trouvent aux articles 5, 6 et 50 ; le quatrième niveau est tout ce que les trois premiers n'attrapent pas. Les niveaux ne sont pas un spectre que l'on négocie — ce sont des catégories, et votre système se trouve dans exactement l'une d'elles par cas d'usage. Voici chaque niveau avec un exemple concret qu'un dirigeant reconnaîtra, ancré à son article ou à son annexe.

1. Risque inacceptable — interdit (article 5)

Une liste courte et fermée de pratiques que le règlement interdit catégoriquement. Il n'existe aucune voie de conformité pour celles-ci ; elles sont hors-jeu sur le marché européen, quelle que soit la performance du système ou le soin apporté à sa gouvernance. Comme c'est la première étape de la classification, il vaut la peine d'avoir toute la liste sous les yeux. L'article 5, paragraphe 1, interdit huit pratiques :

• Les techniques subliminales, manipulatrices ou trompeuses qui altèrent substantiellement le comportement et causent (ou sont susceptibles de causer) un préjudice important.
• L'exploitation des vulnérabilités liées à l'âge, au handicap ou à une situation sociale ou économique spécifique pour altérer substantiellement le comportement et causer un préjudice important.
• La notation sociale — l'évaluation ou le classement de personnes dans la durée sur la base de leur comportement ou de caractéristiques personnelles, conduisant à un traitement préjudiciable ou disproportionné.
• La prédiction du risque qu'une personne commette une infraction pénale en se fondant uniquement sur le profilage ou des traits de personnalité.
• La constitution ou l'extension de bases de reconnaissance faciale par moissonnage non ciblé d'images faciales depuis internet ou la vidéosurveillance.
• L'inférence des émotions sur le lieu de travail ou dans les établissements d'enseignement (sauf pour des raisons médicales ou de sécurité).
• La catégorisation biométrique qui infère des attributs sensibles — origine raciale, opinions politiques, appartenance syndicale, convictions religieuses ou philosophiques, vie sexuelle ou orientation sexuelle.
• L'identification biométrique à distance « en temps réel » dans des espaces accessibles au public à des fins répressives — interdite sauf dans des cas limitativement énumérés, avec des garanties.

Exemple concret. Une start-up de vision par ordinateur constitue une base de reconnaissance faciale en moissonnant des visages de manière indiscriminée sur l'internet ouvert et des flux publics de vidéosurveillance. C'est la pratique interdite par l'article 5, paragraphe 1, point e) — le moissonnage non ciblé d'images faciales pour constituer ou étendre des bases de reconnaissance faciale. Peu importe que le modèle soit précis ou que les données aient été « publiques ». La pratique elle-même est interdite, l'exposition au titre de l'article 99 relève de la bande supérieure à 35 M€ / 7 %, et les interdictions sont en vigueur depuis le 2 février 2025. C'est le niveau où la seule décision d'ingénierie correcte est de ne pas construire la chose.

2. Haut risque (article 6, annexe I et annexe III)

Autorisé, mais uniquement derrière l'ensemble d'obligations le plus lourd du règlement. Un système est à haut risque par l'une de deux voies : l'article 6, paragraphe 1, où l'IA est un composant de sécurité d'un produit déjà réglementé par la législation d'harmonisation de l'UE listée à l'annexe I ; ou l'article 6, paragraphe 2, où le cas d'usage relève de l'un des huit domaines énumérés à l'annexe III. Les systèmes à haut risque doivent satisfaire à un régime défini — gestion des risques, gouvernance des données, documentation technique, journalisation, contrôle humain, transparence envers les déployeurs et évaluation de la conformité avant la mise sur le marché. C'est le niveau dans lequel atterrit la plupart du travail IA en entreprise, et celui auquel ce guide consacre le plus de temps.

Exemple concret. Une entreprise déploie un outil d'IA qui trie et classe les CV pour présélectionner les candidats à un entretien. Le recrutement et la sélection se trouvent en plein dans l'annexe III, point 4 — emploi, gestion de la main-d'œuvre et accès à l'emploi indépendant. Cela rend l'outil à haut risque. Le fournisseur qui l'a construit doit l'intégralité du régime de l'article 6, paragraphe 2 ; l'employeur qui l'exploite doit les obligations du déployeur, dont un contrôle humain compétent et l'information des travailleurs concernés. Le fait que ce ne soit « qu'une aide au tri » ne le fait pas descendre d'un niveau — c'est le cas d'usage qui le classe.

3. Risque limité / transparence (article 50)

Les systèmes qui interagissent avec des personnes ou génèrent du contenu portent des obligations d'information plutôt que le régime complet du haut risque. L'article 50 exige que les personnes soient informées lorsqu'elles interagissent avec un système d'IA plutôt qu'avec un humain, que l'audio, l'image, la vidéo ou le texte synthétiques soient marqués comme générés ou manipulés artificiellement, et que les hypertrucages (deepfakes) et le contenu généré par IA informant le public sur des questions d'intérêt général soient étiquetés. Ces obligations sont légères, mais elles sont obligatoires, et elles s'appliquent en plus de toute classification de niveau supérieur.

Exemple concret. Un distributeur met un agent conversationnel génératif de service client sur son site web. L'agent ne prend pas de décisions à haut risque, il n'est donc pas dans l'annexe III — mais au titre de l'article 50, le distributeur doit indiquer clairement aux clients qu'ils parlent à une IA, et non à une personne. Le correctif est une information d'une ligne, conçue dès le départ. Le mode d'échec, c'est de découvrir lors d'un audit que l'information n'a jamais été construite, sur un système en production depuis un an.

4. Risque minimal / nul (aucune obligation)

La grande majorité des systèmes d'IA. Les filtres anti-spam, l'IA dans les jeux vidéo, les fonctions de recommandation qui sortent des niveaux supérieurs, les modèles d'optimisation des stocks — ceux-là ne portent aucune nouvelle obligation au titre du règlement. L'intérêt de nommer ce niveau est de stopper la sur-réaction qui suit chaque nouvelle réglementation, où des équipes gèlent un logiciel ordinaire parce qu'il contient un modèle. Si un système n'est pas interdit, pas à haut risque au titre de l'annexe I ou III, et pas soumis à une obligation de transparence de l'article 50, le règlement ne lui impose rien. Classez honnêtement, et la majeure partie de votre portefeuille atterrira ici.

Exemple concret. Une plateforme de messagerie utilise un classifieur d'apprentissage automatique pour acheminer le spam vers un dossier indésirable. Il ne relève d'aucune catégorie de l'annexe III, il ne prend aucune décision sur les droits d'une personne ou son accès à des services, et il n'usurpe pas l'identité d'un humain. Il est à risque minimal. Pas d'évaluation de la conformité, pas d'obligation de journalisation, pas de personnel de contrôle — la bonne action de conformité est de consigner le raisonnement de la classification et de passer à autre chose.

Une obligation qui ignore les niveaux. L'obligation de maîtrise de l'IA prévue à l'article 4 n'est pas liée au niveau de risque. Depuis le 2 février 2025, tout fournisseur ou déployeur doit garantir un niveau suffisant de maîtrise de l'IA chez les membres du personnel qui exploitent ses systèmes d'IA — quel que soit le niveau dans lequel ces systèmes se situent. Ainsi, « risque minimal » signifie aucune obligation au niveau du système, et non « rien à faire » : les personnes qui utilisent même un outil à risque minimal doivent encore comprendre ce qu'il fait et où il peut déraper.

« Dans quel niveau suis-je ? » — un déroulé de classification

La classification est une décision que vous pouvez exécuter vous-même avant même de faire appel à un avocat, et la mener vous-même d'abord rend la conversation juridique plus rapide et moins coûteuse. La logique est une courte cascade, et vous l'exécutez par cas d'usage, pas par système — un même modèle sous-jacent peut être à risque minimal dans une application et à haut risque dans une autre. Descendez la cascade dans l'ordre et arrêtez-vous au premier niveau qui vous attrape.

1. La pratique est-elle interdite ? Vérifiez d'abord l'usage contre la liste fermée de l'article 5, car rien d'autre ne compte si c'est interdit. Si le système fait l'une des choses interdites — manipulation causant un préjudice important, exploitation de vulnérabilités, notation sociale, prédiction d'infraction fondée sur le seul profilage, moissonnage facial non ciblé, inférence d'émotions au travail ou en éducation, catégorisation biométrique d'attributs sensibles, ou identification biométrique publique en temps réel illicite — vous vous arrêtez ici. La réponse est : ne pas déployer.
2. Est-il à haut risque ? S'il n'est pas interdit, testez les deux voies du haut risque. Voie une, article 6, paragraphe 1 : l'IA est-elle un composant de sécurité d'un produit couvert par la législation d'harmonisation de l'annexe I ? Voie deux, article 6, paragraphe 2 : le cas d'usage relève-t-il de l'un des huit domaines de l'annexe III ci-dessous ? Un oui sur l'une ou l'autre voie vous place dans le niveau haut risque et son ensemble complet d'obligations.
3. Une obligation de transparence s'applique-t-elle ? Qu'il soit ou non à haut risque, demandez-vous si le système interagit avec des personnes ou génère du contenu synthétique. Si oui, les obligations d'information et de marquage de l'article 50 s'attachent à lui.
4. Sinon, il est à risque minimal. Si rien de ce qui précède n'attrape l'usage, le règlement n'impose aucune nouvelle obligation. Consignez pourquoi, et gardez la trace.

Le pivot de toute la cascade est l'étape deux, et plus précisément les huit domaines de l'annexe III. Si votre cas d'usage relève de l'un d'eux, traitez-le comme à haut risque jusqu'à ce qu'un avocat dise le contraire :

1. Biométrie — identification biométrique à distance, catégorisation biométrique par attributs sensibles, et reconnaissance des émotions là où elle est permise.
2. Infrastructures critiques — IA utilisée comme composant de sécurité dans les infrastructures numériques critiques, le trafic routier, et la fourniture d'eau, de gaz, de chauffage et d'électricité.
3. Éducation et formation professionnelle — décisions d'admission, évaluation des acquis d'apprentissage, évaluation du niveau qu'une personne atteindra, et surveillance de la fraude aux examens.
4. Emploi et gestion de la main-d'œuvre — recrutement et sélection, décisions de promotion et de licenciement, répartition des tâches, et surveillance de la performance des travailleurs.
5. Accès aux services et prestations essentiels — éligibilité à l'aide publique, solvabilité et scoring de crédit, évaluation des risques et tarification en assurance vie et santé, et l'envoi ou la priorisation des appels d'urgence.
6. Répression — évaluation du risque qu'une personne soit victime, polygraphes, évaluation de la fiabilité des preuves, évaluation du risque de délinquance ou de récidive, et profilage.
7. Migration, asile et contrôle aux frontières — polygraphes, évaluation des risques, examen des demandes de visa, d'asile et de titre de séjour, et détection ou identification de personnes (autre que la vérification des documents de voyage).
8. Administration de la justice et processus démocratiques — assistance à une autorité judiciaire dans la recherche et l'interprétation des faits et du droit, et systèmes destinés à influencer des élections, des référendums ou des comportements de vote.

La voie GPAI est distincte. Si vous développez, entraînez ou affinez substantiellement un modèle d'IA à usage général (GPAI) — un modèle de fondation adaptable à de nombreuses tâches en aval — vous êtes sur une voie de classification différente qui court en parallèle des quatre niveaux ci-dessus, au titre du chapitre V du règlement. Tout fournisseur de GPAI porte un socle d'obligations quel que soit le risque. Au-dessus de cela, un modèle GPAI est classé comme présentant un risque systémique au titre de l'article 51 s'il a des « capacités à fort impact » — condition présumée lorsque le calcul cumulé utilisé pour entraîner le modèle dépasse 10²⁵ opérations en virgule flottante (FLOP). Ce seuil de présomption peut être modifié par la Commission via des actes délégués, alors traitez le chiffre exact comme une valeur mouvante et le principe — les modèles les plus grands et les plus capables attirent les obligations les plus lourdes — comme la partie figée. Les modèles au-dessus de la ligne doivent les obligations de risque systémique en plus du socle GPAI. Les obligations elles-mêmes sont dans la section suivante.

Obligations par niveau

La classification vous dit dans quel niveau vous êtes. Cette section vous dit ce que chaque niveau exige réellement que vous construisiez et exploitiez. Les obligations s'échelonnent avec le niveau, et le gros du travail d'ingénierie et de processus se trouve dans la bande haut risque.

Interdit — rien à construire, tout à arrêter

Il n'y a pas d'ensemble d'obligations pour les pratiques interdites, car il n'existe aucune façon conforme d'en exploiter une. La tâche du dirigeant ici est purement défensive : confirmer que rien dans le portefeuille actuel ou prévu ne relève de l'article 5, et poser une porte dans le processus produit pour qu'un usage interdit ne puisse pas être construit par accident. Les interdictions s'appliquent depuis le 2 février 2025, ce n'est donc pas un problème futur à planifier — c'est une vérification au présent.

Haut risque — le régime lourd

C'est là que se trouve le vrai travail. Un système à haut risque doit satisfaire un ensemble connecté d'obligations tout au long de son cycle de vie, et la plupart sont autant des disciplines organisationnelles que des fonctionnalités d'ingénierie. Les domaines d'obligations que le règlement exige des systèmes à haut risque sont :

• Gestion des risques — un processus continu et documenté qui identifie et atténue les risques pour la santé, la sécurité et les droits fondamentaux tout au long du cycle de vie du système, et non une évaluation ponctuelle au lancement.
• Gouvernance des données — des données d'entraînement, de validation et de test gérées pour leur qualité, leur pertinence et leur représentativité, avec une documentation des pratiques de traitement des données.
• Documentation technique — un dossier complet de la façon dont le système a été construit, de ce qu'il fait et de la façon dont il satisfait les exigences, tenu à jour et disponible pour les autorités.
• Journalisation et tenue de registres — l'enregistrement automatique des événements au fil de l'exploitation du système pour que son fonctionnement puisse être tracé et surveillé.
• Contrôle humain — des personnes désignées et compétentes, capables de comprendre les sorties du système, de reconnaître le biais d'automatisation, d'outrepasser les décisions et d'arrêter le système si nécessaire.
• Transparence envers les déployeurs — une notice d'utilisation claire afin qu'un déployeur puisse exploiter le système correctement et satisfaire ses propres obligations.
• Évaluation de la conformité — le système doit être évalué au regard des exigences avant d'être mis sur le marché ou en service.

La répartition des obligations compte sur le plan opérationnel. Le fournisseur possède les exigences côté ingénierie — intégrer le processus de gestion des risques dans le système, la gouvernance des données, la documentation, l'évaluation de la conformité. Le déployeur possède les exigences côté exploitation — exploiter le système selon la notice, doter le contrôle humain, conserver les journaux que le système génère, le surveiller en production et informer les personnes qu'il affecte. Aucune des deux parties ne peut s'acquitter des obligations de l'autre, ce qui explique pourquoi une répartition contractuelle propre entre fournisseur et déployeur fait partie de la mise en production d'un système à haut risque, et non d'une réflexion après coup.

Risque limité / transparence — informer et marquer

Les obligations de l'article 50 sont étroites et concrètes. Les personnes qui interagissent avec un système d'IA doivent être informées qu'elles ont affaire à une IA. L'audio, l'image, la vidéo et le texte générés ou manipulés par IA doivent être marqués comme tels de manière lisible par machine. Les hypertrucages et le contenu généré par IA qui informe le public sur des questions d'intérêt général doivent être étiquetés. Le travail ici est limité mais facile à oublier : il doit être conçu dans la surface produit et le pipeline de contenu, et non rajouté sous la pression d'un audit.

GPAI — les obligations du chapitre V

Les fournisseurs de modèles d'IA à usage général portent des obligations distinctes du système à quatre niveaux. Tout fournisseur de GPAI doit tenir une documentation technique du modèle, fournir des informations et une documentation aux fournisseurs en aval qui intègrent le modèle dans leurs propres systèmes, mettre en place une politique de respect du droit d'auteur de l'UE, et publier un résumé suffisamment détaillé du contenu utilisé pour entraîner le modèle. Les fournisseurs de GPAI dont le modèle présente un risque systémique (la classification de l'article 51 de la section précédente) portent des obligations additionnelles : évaluation du modèle, évaluation et atténuation des risques systémiques, suivi et signalement des incidents graves, et un niveau adéquat de cybersécurité pour le modèle et son infrastructure physique. L'ensemble « risque systémique » est délibérément plus lourd parce qu'il s'attache aux modèles dont le rayon d'impact en aval est le plus large.

Le calendrier

Le règlement ne s'active pas d'un seul coup. L'article 113 échelonne les obligations sur trois ans à compter de l'entrée en vigueur, et l'étalement est délibéré : les pratiques jugées les plus nuisibles sont interdites en premier, la machinerie de niveau modèle et de gouvernance vient ensuite, et le gros du régime haut risque atterrit au milieu du calendrier. Les dates ci-dessous sont celles à piloter — chaque ligne est un jalon que vous avez soit déjà dépassé, soit en cours de préparation.

Deux lectures pratiques de ce tableau. D'abord, les obligations haut risque qui attrapent la plupart des logiciels d'entreprise — les cas d'usage de l'annexe III — atterrissent le 2 août 2026, ce qui, depuis la date d'arrêté de cette édition, est proche. Un système à haut risque qui n'a pas encore franchi la gestion des risques, la gouvernance des données, la documentation et l'évaluation de la conformité court contre la montre. Ensuite, les jalons interdiction et GPAI sont déjà derrière nous ; si votre portefeuille n'a pas été vérifié contre l'article 5 et votre travail sur les modèles de fondation contre le chapitre V, ce ne sont pas des échéances futures que vous préparez — ce sont des obligations présentes que vous manquez peut-être déjà.

La conformité comme capacité de livraison, pas comme case juridique à cocher

Voici la partie que la plupart des commentaires juridiques manquent, et celle qui décide si la conformité au règlement IA vous coûte une fortune en honoraires de conseil récurrents ou devient une propriété durable de votre façon de livrer. Le règlement, lu par un juriste, est un ensemble d'obligations. Le règlement, lu par un dirigeant qui a réellement dirigé des organisations d'ingénierie, est une spécification de capacités à intégrer dans la couche de livraison sous votre IA — et dès que vous le lisez ainsi, la majeure partie du régime haut risque cesse de ressembler à de la paperasse et commence à ressembler à de l'ingénierie que vous devriez faire de toute façon.

Reparcourez l'ensemble des obligations haut risque, cette fois en personne de la livraison plutôt qu'en responsable conformité. Le texte des articles confirme la correspondance : la gestion des risques est l'article 9, la gouvernance des données l'article 10, la documentation technique l'article 11, la tenue de registres et la journalisation l'article 12, la transparence et l'information aux déployeurs l'article 13, le contrôle humain l'article 14, et l'exactitude, la robustesse et la cybersécurité l'article 15. Maintenant, cessez de traiter cela comme sept documents distincts qu'un juriste assemble après coup, et traitez-le comme sept propriétés qu'un pipeline de livraison bien géré produit déjà — ou que l'on peut amener à produire avec le travail d'un trimestre.

• Le registre des systèmes est votre documentation de l'article 11. Toute équipe qui livre de l'IA devrait tenir un registre de modèles et de systèmes : ce qu'est chaque système, ce qu'il fait, qui en est responsable, quelles données l'ont entraîné, quelle version est en production, et dans quel niveau il a été classé et pourquoi. Mettez ce registre en place correctement et ce n'est pas un artefact de conformité boulonné pour l'auditeur — c'est la documentation technique que le règlement exige, tenue à jour comme effet de bord des opérations normales plutôt que reconstruite sous la pression de l'échéance. La façon la plus coûteuse de satisfaire l'article 11 est de l'écrire de mémoire le mois précédant une évaluation. La moins coûteuse est de ne jamais laisser le registre se périmer.
• Les portes d'évaluation sont votre preuve de l'article 15. L'exactitude, la robustesse et la cybersécurité ne sont pas des affirmations que vous posez dans un paragraphe ; ce sont des allégations que vous devez étayer. Une organisation qui exécute des suites d'évaluation dans son pipeline — exactitude sur données réservées et adverses, comportement sous dérive de distribution, sondages de type red team — et qui bloque une livraison quand une métrique régresse, génère la preuve de l'article 15 à chaque livraison. Traitez l'évaluation de modèle comme l'intégration continue de l'IA : une porte que la build doit passer, avec le résultat journalisé. Le récit de conformité s'écrit alors de lui-même, car les tests ont eu lieu en route vers la production plutôt qu'en exercice spécial après coup.
• Les journaux d'audit satisfont l'article 12 par conception. L'obligation de journalisation est la plus facile à satisfaire si vous l'intégrez et la plus difficile à rajouter. Un système à haut risque doit enregistrer les événements au fil de son exploitation pour que son fonctionnement puisse être tracé. Si la journalisation est conçue dans le système dès le premier sprint — entrées, sorties, événements de neutralisation humaine, version du modèle ayant servi chaque décision — alors la tenue de registres est simplement active. Si c'est une réflexion après coup, vous ré-instrumentez un système en production sous audit, soit exactement la situation qu'aucun dirigeant ne veut connaître.
• Le contrôle humain est un contrôle produit, pas une politique. L'article 14 ne demande pas une phrase dans un manuel disant qu'un humain est dans la boucle ; il demande des personnes désignées et compétentes qui peuvent réellement comprendre la sortie, reconnaître le biais d'automatisation, outrepasser la décision et arrêter le système. C'est une interface et un flux de travail, pas une clause. Cela signifie des boutons de neutralisation qui fonctionnent, des chemins d'escalade qui mènent à quelqu'un doté d'autorité, et une UI qui fait remonter la confiance et la justification plutôt que de les masquer. Un contrôle câblé dans la surface produit est réel ; un contrôle écrit dans un document de politique et contredit par une UI qui n'offre aucune neutralisation est le genre d'écart qu'un évaluateur trouve en un après-midi.
• La gestion du changement déclenche une re-classification. La classification que vous avez exécutée à la section 5 est vraie le jour où vous l'avez exécutée. Un système qui reçoit un nouveau cas d'usage, un jeu d'entraînement matériellement différent ou une capacité qu'il n'avait pas auparavant peut franchir une frontière de niveau — un outil à risque minimal étendu à un cas d'usage de l'annexe III devient à haut risque, et personne n'a déposé les documents parce que personne n'a remarqué que la ligne avait bougé. Le contrôle est une étape légère de gestion du changement : tout changement matériel d'un système d'IA rouvre la question de la classification avant qu'il ne soit livré. C'est la discipline qui garde le registre honnête et qui empêche un changement de fonctionnalité discret de se transformer en violation de conformité non déclarée.

C'est le fil conducteur de notre façon de penser l'IA en général : les modèles font les gros titres, mais la valeur — et désormais l'exposition réglementaire — se réalise ou se perd dans la couche de livraison sous l'IA : les pipelines, les registres, les harnais d'évaluation, les contrôles de supervision, la discipline de livraison. Le règlement IA est, sous un certain angle, un régulateur qui vous dit de bien construire cette couche de livraison. Les organisations qui livrent déjà de l'IA avec de vraies portes d'évaluation, une vraie journalisation, un inventaire honnête et une gestion du changement disciplinée trouveront que la conformité revient surtout à pointer vers des contrôles qu'elles exploitent déjà. Les organisations qui livrent de l'IA sans cela vivront le règlement comme une taxe — car le règlement leur facture, en effet, la discipline d'ingénierie qu'elles ont sautée. Construisez la capacité une fois et elle sert la réglementation, l'auditeur et la qualité du produit en même temps. C'est tout l'argument : la conformité est une capacité de livraison, et les entreprises qui la traitent comme telle la paieront une fois au lieu de toujours.

Un plan d'action en 90 jours

La stratégie ci-dessus n'est utile que si elle survit au contact d'un calendrier. Voici le plan qu'un dirigeant peut réellement exécuter en un trimestre, par tranches de semaines, pour passer de « nous avons de l'IA quelque part dans le parc » à « nous savons exactement ce que nous avons, dans quel niveau se trouve chaque système, où sont les écarts et qui est responsable de les combler ». Il suppose un responsable redevable unique — un directeur de la transformation, un CTO ou un dirigeant de transition recruté pour cela — et un groupe de travail capable de mobiliser le juridique, la sécurité et les équipes produit concernées. Quatre-vingt-dix jours suffisent pour réussir l'inventaire et la classification et pour amorcer la remédiation ; ils ne suffisent pas pour terminer la remédiation d'un système à haut risque complexe, et le plan ne prétend pas le contraire.

Semaines 1–2 — Inventorier chaque système d'IA

Vous ne pouvez pas classer ce que vous n'avez pas recensé, et presque toutes les organisations sous-estiment la quantité d'IA qu'elles font déjà tourner — l'outil SaaS acheté avec un modèle dedans, la fonction d'analytics livrée l'an dernier par quelqu'un, l'agent conversationnel que le marketing a mis en place sans en parler à l'ingénierie. Construisez le registre maintenant. Pour chaque système d'IA, saisissez : ce qu'il fait, le responsable métier, le responsable technique, s'il a été construit en interne ou acheté, et — surtout — votre rôle par système. Pour chacun, décidez si vous êtes le fournisseur (vous l'avez construit ou mis sur le marché sous votre nom) ou le déployeur (vous l'avez acheté et l'exploitez sous votre propre autorité), car cela détermine quel ensemble d'obligations vous échoit. Beaucoup d'organisations sont les deux, sur des systèmes différents. Le livrable à la fin de la semaine 2 est un registre unique, possédé et tenu à jour, qui dit : voici chaque système d'IA que nous touchons, et voici notre rôle sur chacun.

Semaines 3–6 — Classer chaque système par niveau

Passez chaque système du registre dans la cascade de classification de la section 5, par cas d'usage. Vérifiez-le d'abord contre les interdictions de l'article 5 — tout ce qui y est attrapé est une escalade immédiate, pas un point de fin de trimestre. Testez ensuite les deux voies du haut risque : composant de sécurité de l'annexe I, ou l'un des huit domaines de l'annexe III. Puis les déclencheurs de transparence de l'article 50. Tout ce qui n'est pas attrapé est à risque minimal — et vous consignez pourquoi, car un « minimal » injustifié est la classification qu'un évaluateur contestera. Attendez-vous à ce que la majeure partie du portefeuille atterrisse en risque minimal, une minorité significative en transparence, et un ensemble plus restreint et à plus forts enjeux en haut risque. Le livrable est le registre avec un niveau défendable et une justification en une ligne pour chaque système, plus une liste signalée des systèmes haut risque et GPAI sur lesquels se concentre le reste du trimestre.

Semaines 7–10 — Évaluer les écarts des systèmes haut risque et GPAI

Prenez la liste signalée et évaluez chaque système au regard des domaines d'obligations applicables à son niveau. Pour un système à haut risque, parcourez les sept domaines des articles 9 à 15 — gestion des risques, gouvernance des données, documentation technique, journalisation, transparence envers les déployeurs, contrôle humain, exactitude/robustesse/cybersécurité — plus l'évaluation de la conformité, et marquez chacun comme en place, partiel ou absent. Pour un modèle GPAI que vous construisez ou affinez substantiellement, évaluez au regard du socle du chapitre V (documentation, information en aval, politique droits d'auteur, résumé du contenu d'entraînement) et, s'il franchit le seuil de risque systémique, des obligations additionnelles de l'article 51. Soyez honnête sur le « partiel » — un mécanisme de journalisation qui capture certains événements mais pas les décisions de neutralisation est partiel, pas en place. Le livrable est une matrice des écarts : les systèmes sur un axe, les obligations sur l'autre, chaque case notée.

Semaines 11–13 — Remédier, attribuer des responsables, mettre en place les contrôles

Transformez la matrice des écarts en backlog avec des responsables nommés et des dates. Priorisez par exposition — tout ce qui est proche d'une ligne de l'article 5 d'abord, puis les systèmes à haut risque les plus proches d'une échéance active. En parallèle, mettez en place les contrôles durables de la section 8 pour que les mêmes écarts ne se rouvrent pas : le registre tenu à jour, les portes d'évaluation dans le pipeline, la journalisation dès la conception, les contrôles de supervision humaine dans le produit, et l'étape de gestion du changement qui re-déclenche la classification quand un système change. L'intérêt de faire cela dans le même trimestre que l'évaluation est que les contrôles sont ce qui vous maintient conforme après le départ des consultants ; une remédiation sans les contrôles est un instantané qui se dégrade dès la livraison de la fonctionnalité suivante. Le livrable est un backlog de remédiation daté et attribué plus un ensemble de contrôles en place — le début de la conformité comme capacité permanente plutôt que comme projet.

Sanctions et application

Le cadre des sanctions se trouve à l'article 99, et il est gradué pour correspondre à la gravité de l'infraction. Il y a trois bandes.

• Jusqu'à 35 000 000 € ou 7 % du chiffre d'affaires annuel mondial total de l'exercice précédant la décision — pour violation des interdictions de l'article 5. C'est la bande supérieure, réservée aux pratiques que le règlement interdit catégoriquement.
• Jusqu'à 15 000 000 € ou 3 % du chiffre d'affaires annuel mondial total — pour violation de la plupart des autres obligations opérationnelles, dont les exigences haut risque sur les fournisseurs et déployeurs, les obligations de transparence et les obligations GPAI.
• Jusqu'à 7 500 000 € ou 1 % du chiffre d'affaires annuel mondial total — pour la fourniture d'informations inexactes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités nationales compétentes en réponse à une demande.

Le « ou » de chaque bande joue un vrai rôle, et il tranche en sens opposés selon qui vous êtes. Pour une entreprise — une société — le maximum applicable est le montant le plus élevé entre le chiffre en euros fixe et le pourcentage du chiffre d'affaires. Un grand groupe avec des milliards de chiffre d'affaires est donc exposé au pourcentage, qui peut courir bien au-dessus du plafond en euros affiché. Pour les PME et les start-up, la position est inversée : le maximum applicable est le plus faible des deux, de sorte qu'une petite entreprise n'est pas détruite par un pourcentage d'un chiffre d'affaires qu'elle n'a pas. La structure est délibérée — elle dimensionne la dissuasion à la taille de l'acteur plutôt que d'appliquer un nombre uniforme qui serait dérisoire pour une multinationale et fatal pour une start-up.

L'application n'est pas le fait d'un seul régulateur. Elle est répartie sur une structure qui s'est activée avec les dispositions de gouvernance le 2 août 2025. Chaque État membre désigne des autorités nationales compétentes et des autorités de surveillance du marché qui appliquent le règlement sur le terrain dans leur territoire — enquêtant, demandant des informations et imposant des sanctions. À l'échelle de l'Union, le Bureau européen de l'IA au sein de la Commission a la main sur les modèles d'IA à usage général, dont les obligations GPAI à risque systémique. Le Comité européen de l'intelligence artificielle coordonne entre les États membres pour garder une application cohérente plutôt que fragmentée en vingt-sept interprétations divergentes. Pour un dirigeant, la conséquence pratique est que votre premier contact d'application sera très probablement une autorité nationale dans un État membre où votre système opère, tandis que les questions GPAI remontent au Bureau de l'IA.

Un mot réaliste sur la posture, car l'alarmisme est aussi peu utile que la complaisance. À la date d'arrêté de cette édition, le régime est jeune : les interdictions et les organes de gouvernance sont en vigueur, le cadre des sanctions est opérationnel, mais le gros du régime haut risque ne s'applique pas avant le 2 août 2026, et la machinerie d'appui — normes harmonisées, organismes notifiés, détail de la pratique d'application — mûrit encore. L'attente raisonnable est que l'application précoce se concentre sur les pratiques interdites, sur la non-conformité flagrante ou délibérée et sur les plus grands acteurs, plutôt que sur des dirigeants de bonne foi visiblement en train d'avancer dans la classification et la remédiation. Ce n'est pas une raison d'attendre. C'est une raison d'être le genre de dirigeant qui, si un régulateur appelle, peut montrer un registre tenu à jour, une classification défendable et un plan de remédiation attribué — car une bonne foi démontrable et une trace écrite de diligence valent beaucoup quand la discrétion d'application s'exerce. Le risque n'est pas d'être sanctionné pour être en cours de remédiation de bonne foi. Le risque est de ne pas pouvoir montrer que vous avez jamais commencé.

Le rôle de Consulting Huber

Consulting Huber est un cabinet de praticiens, et la conformité au règlement IA est exactement le genre de problème pour lequel nous sommes faits : pour partie classification juridiquement avertie, pour partie discipline d'ingénierie, pour partie gestion du changement — et l'essentiel vivant dans la couche de livraison plutôt que dans un avis juridique. Nous ne remplaçons pas votre avocat sur un système précis, et nous le disons clairement ; le droit dépend des faits, et c'est dans les faits qu'un avocat gagne ses honoraires. Ce que nous faisons, c'est la moitié dirigeant du travail qui se trouve de part et d'autre de cet avis juridique.

Concrètement, ce sont trois choses. Nous menons l'inventaire et la classification — en mettant en place le registre, en faisant passer votre portefeuille dans la cascade, et en produisant le dossier défendable niveau-et-justification qui transforme « nous avons de l'IA quelque part » en une carte à partir de laquelle vous pouvez briefer un conseil. Nous intégrons la conformité dans la couche de livraison — les portes d'évaluation, la journalisation dès la conception, les contrôles de supervision humaine et la discipline de gestion du changement qui font des obligations une propriété de votre façon de livrer plutôt qu'une course à l'audit récurrente. Et nous le faisons sur une base de transition ou de conseil : intégrés comme responsable redevable pour le trimestre qui met la capacité en place, ou aux côtés de votre équipe comme la paire de mains seniors qui l'a déjà fait. Le modèle est le transfert de capacité — quand nous partons, le registre, les portes et les contrôles restent, possédés et exploités par vos équipes.

La réflexion compagnon se trouve sur tout le site : l'argument plus large en faveur de la couche d'ingénierie est dans La couche de livraison sous l'IA, le volet valeur est dans le playbook de création de valeur IA, et la page de service pour le travail stratégie-et-livraison est Stratégie Digitale & IA. Si vous avez un système précis et une échéance du 2 août 2026 à piloter, l'étape suivante la plus utile est une courte conversation sur l'endroit où vous en êtes réellement.