Les exigences applicables aux systèmes d’intelligence artificielle à haut risque. Gestion des risques, gouvernance des données, documentation, transparence et contrôle humain

1Les exigences de la section 2 du chapitre III sont la partie du règlement européen sur l’intelligence artificielle dont dépend tout le reste. La qualification de haut risque, examinée par ailleurs, ne fait que désigner les systèmes qui doivent y satisfaire ; les obligations des opérateurs organisent leur mise en œuvre ; l’évaluation de la conformité, le marquage et l’enregistrement en vérifient le respect ; la surveillance du marché et les sanctions en assurent l’exécution. Retirer la section 2, et il ne reste du chapitre III qu’une procédure sans objet.

2Ces exigences sont au nombre de sept : la gestion des risques, la gouvernance des données, la documentation technique, la journalisation, la transparence envers le déployeur, le contrôle humain, et le triptyque exactitude-robustesse-cybersécurité. Elles occupent les articles 8 à 15, auxquels s’ajoutent l’annexe IV, qui détaille le contenu de la documentation, et, depuis 2026, l’article 4 bis, qui commande la détection des biais.

1. L’économie générale d’une section sans destinataire

Une filiation éthique devenue contraignante

3Les sept exigences ne sont pas nées de la proposition de 2021. Elles figuraient, presque terme à terme, dans les lignes directrices en matière d’éthique pour une intelligence artificielle digne de confiance publiées le 8 avril 2019 par le groupe d’experts de haut niveau réuni par la Commission européenne. Ce document énonçait qu’une intelligence artificielle digne de confiance devait être licite, éthique et robuste, et il en déduisait sept exigences clés : le facteur humain et le contrôle humain, la robustesse technique et la sécurité, le respect de la vie privée et la gouvernance des données, la transparence, la diversité et la non-discrimination, le bien-être sociétal et environnemental, et la responsabilisation^[3].

4La correspondance avec la section 2 est frappante, et les écarts le sont davantage. Cinq des sept exigences éthiques se retrouvent dans le règlement, transformées en obligations juridiques : le contrôle humain à l’article 14, la robustesse à l’article 15, la gouvernance des données à l’article 10, la transparence à l’article 13, la non-discrimination par le jeu combiné de l’article 10, paragraphe 2, et de l’article 4 bis. Deux ne s’y retrouvent pas. Le bien-être sociétal et environnemental a disparu du corps des exigences ; il ne subsiste que dans les considérants et dans des dispositifs non contraignants. La responsabilisation n’est pas devenue une exigence du système, mais une obligation de l’opérateur, traitée à la section 3.

5Cette double soustraction n’est pas neutre. Elle marque le passage d’une éthique de l’intelligence artificielle, qui se prononce sur les fins, à une réglementation de produit, qui ne se prononce que sur les propriétés de l’objet mis sur le marché. Le règlement ne demande pas si un système à haut risque est souhaitable ; il demande s’il est sûr, documenté, contrôlable et exact. La question du bien commun, présente en 2019, a été laissée hors du champ contraignant.

Une section qui décrit un état, et n’oblige personne

6Une particularité de rédaction commande la lecture de toute la section et passe pourtant inaperçue : les articles 9 à 15 ne désignent aucun débiteur. Ils sont écrits au passif ou à la voix impersonnelle. « Un système de gestion des risques est établi » ; « les jeux de données d’entraînement, de validation et de test sont pertinents » ; « la documentation technique […] est établie » ; « les systèmes d’IA à haut risque résistent aux tentatives de tiers non autorisés »^[4]. La section 2 ne dit jamais qui doit faire : elle décrit l’état dans lequel le système doit se trouver.

7L’imputation vient d’ailleurs. C’est l’article 16, point a), premier article de la section suivante, qui dispose que les fournisseurs de systèmes d’IA à haut risque « veillent à ce que leurs systèmes d’IA à haut risque soient conformes aux exigences énoncées à la section 2 »^[5]. La section 2 énonce des propriétés ; la section 3 en fait une obligation, et la fait peser sur le fournisseur.

8Cette construction est celle de la législation d’harmonisation classique, où les exigences essentielles décrivent le produit et où l’obligation de conformité pèse sur le fabricant. Elle emporte deux conséquences. D’abord, les exigences sont opposables au système, non à une conduite : un fournisseur diligent dont le système ne satisfait pas aux exigences est en infraction, la faute étant sans incidence. Ensuite, le déployeur n’est pas tenu par la section 2. Il a ses propres obligations, examinées ailleurs, mais il ne doit pas rendre le système exact ou robuste : il doit l’utiliser conformément à la notice.

Le double étalon de l’article 8

9L’article 8, paragraphe 1, fixe la mesure commune à toutes les exigences. Elles s’appliquent « en tenant compte de leur destination ainsi que de l’état de la technique généralement reconnu en matière d’IA et de technologies liées à l’IA », et il est tenu compte, pour en garantir le respect, du système de gestion des risques prévu à l’article 9^[6]. Deux étalons, donc, dont aucun n’est fixe.

10Le premier étalon est la destination. Il relativise chaque exigence par l’usage auquel le fournisseur destine le système : un même niveau d’exactitude peut être suffisant pour un usage et insuffisant pour un autre. Le second est l’état de la technique généralement reconnu. Cette notion, empruntée au droit de la sécurité des produits, n’est définie nulle part dans le règlement — l’article 3, qui compte soixante-dix définitions depuis l’insertion des points 14 bis et 14 ter en 2026, l’ignore, et l’expression n’apparaît que six fois dans l’ensemble du texte^[7].

11L’indétermination est ici structurelle plutôt qu’accidentelle. Dans le nouveau cadre législatif, l’état de la technique se constate par les normes harmonisées : la norme dit ce que la technique sait faire, et le respect de la norme vaut présomption de conformité à l’exigence. C’est cette articulation qui devait donner un contenu opérationnel aux articles 9 à 15. Elle relève de l’article consacré à la démonstration de la conformité, auquel il est renvoyé ; il suffit ici d’observer que le double étalon de l’article 8 est, en l’état, un renvoi à un référentiel qui n’existe pas encore.

La proportionnalité assumée dans le préambule

12Le considérant 66 énumère les sept exigences et ajoute une phrase que l’on ne remarque pas assez : « Aucune autre mesure moins contraignante pour le commerce n’étant raisonnablement disponible, ces exigences ne constituent pas des restrictions injustifiées aux échanges. »^[8] Le législateur de l’Union n’y justifie pas les exigences par la protection des personnes ; il les justifie par leur compatibilité avec la liberté de circulation.

13La précaution s’explique par la base juridique. Le règlement repose principalement sur l’article 114 du traité sur le fonctionnement de l’Union européenne : il est un acte de marché intérieur, et sa validité se mesure à l’aune de l’objectif d’harmonisation. Le considérant 66 est ainsi une prémunition contentieuse : il inscrit dans le préambule le test de nécessité qu’une juridiction pourrait appliquer. Il est aussi un aveu de méthode : les exigences ont été calibrées au niveau le moins contraignant compatible avec l’objectif, et non au niveau le plus protecteur possible.

L’articulation avec la législation sectorielle

14L’article 8, paragraphe 2, règle le cumul. Lorsqu’un produit contient un système d’intelligence artificielle soumis à la fois au règlement et à l’une des législations d’harmonisation de la section A de l’annexe I, le fournisseur reste tenu de la conformité intégrale à l’une et à l’autre ; mais il lui est permis d’intégrer les essais, déclarations, informations et documents exigés par le règlement dans ceux qui existent déjà au titre de la législation sectorielle^[9]. La faculté porte sur la forme, non sur le fond.

15Le considérant 64 en donne la raison, et elle est plus intéressante que la règle : les dangers que couvre le règlement « concernent des aspects différents de ceux qui sont énoncés dans la législation d’harmonisation existante », de sorte que ses exigences complètent l’acquis au lieu de s’y substituer. L’exemple donné est celui des machines et des dispositifs médicaux, dont la législation propre ne traite pas des risques spécifiques aux systèmes d’intelligence artificielle^[10]. Autrement dit : le règlement postule que la sécurité des produits, telle qu’elle était conçue, ne savait pas voir ce que l’intelligence artificielle ajoute au produit.

2. La gestion des risques : la matrice des six autres exigences

Un processus, non un document

16L’article 9 impose que soit établi, mis en œuvre, documenté et tenu à jour un système de gestion des risques. Le paragraphe 2 en donne la nature : un « processus itératif continu qui est planifié et se déroule sur l’ensemble du cycle de vie » du système, faisant périodiquement l’objet d’un examen et d’une mise à jour méthodiques^[11]. La formule exclut l’analyse de risques effectuée une fois pour toutes avant la mise sur le marché : l’obligation est de tenir le processus vivant.

17Le processus comporte quatre étapes : identifier et analyser les risques connus et raisonnablement prévisibles pour la santé, la sécurité ou les droits fondamentaux lorsque le système est utilisé conformément à sa destination ; estimer et évaluer les risques susceptibles d’apparaître dans cet usage et dans des conditions de mauvaise utilisation raisonnablement prévisible ; évaluer les autres risques révélés par la surveillance après commercialisation ; adopter des mesures appropriées et ciblées^[12]. La troisième étape mérite attention : elle referme la boucle entre l’aval et l’amont, en faisant des données recueillies après la mise sur le marché une source d’obligations nouvelles pour la conception.

Ce que la gestion des risques n’a pas à traiter

18Le paragraphe 3 pose une limite dont la portée pratique est considérable : les risques visés « ne concernent que ceux qui peuvent être raisonnablement atténués ou éliminés dans le cadre du développement ou de la conception […] ou par la fourniture d’informations techniques appropriées »^[13]. Trois voies seulement sont donc ouvertes : la conception, le développement, l’information. Un risque qui ne peut être traité par aucune des trois — parce qu’il tient à l’organisation du déployeur, au contexte social d’emploi ou à la décision politique de recourir au système — sort du champ de l’article 9.

19La limite est cohérente avec la logique du produit : on ne peut exiger d’un fabricant qu’il corrige ce qui ne dépend pas de lui. Elle laisse cependant hors du dispositif une part des risques que le règlement invoque pour se justifier, notamment ceux qui procèdent de l’usage institutionnel d’un système exact. Ces risques sont traités, s’ils le sont, par l’analyse d’impact sur les droits fondamentaux qui incombe à certains déployeurs, examinée dans l’article consacré aux obligations des opérateurs.

Le risque résiduel et la disparition d’une garantie

20Le paragraphe 5 exige que le risque résiduel pertinent associé à chaque danger, ainsi que le risque résiduel global, soient « jugés acceptables ». Il ordonne pour cela une hiérarchie classique : éliminer ou réduire les risques par la conception « autant que la technologie le permet », puis atténuer et contrôler ce qui subsiste, puis informer et, éventuellement, former le déployeur^[14].

21Le texte ne dit pas qui juge de l’acceptabilité. La lecture qui s’impose est celle du système : c’est le fournisseur qui apprécie, sous le contrôle éventuel de l’organisme notifié lorsque celui-ci intervient, et sous celui, toujours possible, de l’autorité de surveillance du marché. Aucun seuil, aucune matrice, aucune méthode d’agrégation n’est imposée. L’appréciation du caractère acceptable d’un risque pour les droits fondamentaux est ainsi confiée, en première ligne, à l’opérateur économique qui met le système sur le marché.

22La comparaison avec la proposition de 2021 révèle ici une soustraction. Son article 9, paragraphe 4, disposait que le risque résiduel devait être acceptable « à condition que le système d’IA à haut risque soit utilisé conformément à sa destination ou dans des conditions de mauvaise utilisation raisonnablement prévisible », et surtout que « l’utilisateur est informé de ces risques résiduels »^[15]. Cette dernière phrase a disparu du texte adopté. Le déployeur reçoit désormais, au titre de l’article 13, les circonstances susceptibles d’engendrer des risques ; il ne reçoit plus l’énoncé des risques que le fournisseur a délibérément décidé d’accepter.

Les ajouts du texte adopté

23À l’inverse, le règlement adopté a enrichi l’article 9 sur trois points absents de la proposition. Les paragraphes 6 à 8 imposent des essais, précisent qu’ils peuvent comprendre des essais en conditions réelles et exigent qu’ils reposent sur « des indicateurs et des seuils probabilistes préalablement définis » — c’est l’un des rares endroits où le règlement impose une méthode quantifiée, encore que ce soit au fournisseur d’en fixer les valeurs^[16]. Le paragraphe 9 oblige à prendre en considération la probabilité d’une incidence négative sur les personnes de moins de dix-huit ans et, le cas échéant, sur d’autres groupes vulnérables. Le paragraphe 10 permet enfin d’intégrer le dispositif dans les procédures de gestion des risques déjà imposées par d’autres actes de l’Union.

24Le considérant 65 ajoute une précision qui limite la portée de l’exigence relative à la mauvaise utilisation : la détermination et la mise en œuvre de mesures d’atténuation « ne devraient pas nécessiter […] des mesures d’entraînement supplémentaires spécifiques », les fournisseurs étant seulement encouragés à les envisager^[17]. La mauvaise utilisation raisonnablement prévisible doit donc être anticipée, documentée et signalée ; elle n’a pas à être corrigée par un réentraînement du modèle.

3. Les données et leur gouvernance : l’exigence la plus disputée

Huit pratiques et un examen des biais

25L’article 10 est celui dont la rédaction a le plus varié, et celui que la révision de 2026 a le plus profondément remanié. Son paragraphe 2 soumet les jeux de données d’entraînement, de validation et de test à des pratiques de gouvernance et de gestion appropriées à la destination du système, et en énumère huit : les choix de conception ; les processus de collecte et l’origine des données, ainsi que, pour les données à caractère personnel, la finalité initiale de la collecte ; les opérations de préparation, telles que l’annotation, l’étiquetage, le nettoyage, la mise à jour, l’enrichissement et l’agrégation ; la formulation des hypothèses sur ce que les données sont censées mesurer et représenter ; l’évaluation de la disponibilité, de la quantité et de l’adéquation des jeux ; l’examen destiné à repérer les biais ; les mesures visant à les détecter, prévenir et atténuer ; enfin la détection des lacunes et des déficiences, et la manière d’y remédier^[18].

26Le quatrième point est le plus exigeant intellectuellement, et le moins commenté. Exiger la formulation explicite des hypothèses « en ce qui concerne les informations que les données sont censées mesurer et représenter », c’est imposer au fournisseur d’énoncer ce que son étiquette prétend capturer — ce que mesure, par exemple, une variable de « performance » dans un système de recrutement, ou de « risque » dans un système d’évaluation. C’est là que se jouent la plupart des biais dits de construction, et c’est une exigence de méthode scientifique inscrite dans un texte contraignant.

La relativisation opérée entre 2021 et 2024

27Le paragraphe 3 est célèbre pour avoir été, dans la proposition de 2021, d’une raideur inapplicable. Il disposait alors : « Les jeux de données d’entraînement, de validation et de test sont pertinents, représentatifs, exempts d’erreurs et complets. »^[19] Exiger d’un jeu de données réel qu’il soit exempt d’erreurs et complet revenait à exiger l’impossible, et la critique fut immédiate.

28Le texte adopté a relativisé la même phrase trois fois. Les jeux sont désormais « pertinents, suffisamment représentatifs et, dans toute la mesure possible, exempts d’erreurs et complets au regard de la destination »^[20]. Un adverbe pour la représentativité, une réserve de faisabilité pour l’absence d’erreurs et la complétude, et un étalon finaliste pour l’ensemble. La règle est passée d’une exigence absolue, donc jamais satisfaite, à une exigence de moyens indexée sur l’usage — c’est-à-dire à une exigence dont la violation ne peut plus être constatée sans discuter la destination déclarée.

29Le paragraphe 4 a subi un ajout discret et utile. Là où la proposition visait le cadre « géographique, comportemental ou fonctionnel », le texte adopté vise le cadre « géographique, contextuel, comportemental ou fonctionnel »^[21]. Le mot ajouté n’est pas un pléonasme : il permet d’opposer au fournisseur la spécificité d’un contexte institutionnel — un système d’aide à la décision entraîné sur les pratiques d’une administration ne peut être présumé valable pour une autre.

Le paradoxe du biais et sa solution

30Les points f) et g) du paragraphe 2 imposent de repérer les biais susceptibles de se traduire par une discrimination interdite et de prendre les mesures pour les atténuer. Or vérifier qu’un système ne discrimine pas selon l’origine, les convictions religieuses, la santé ou l’orientation sexuelle suppose de disposer de ces informations pour les mettre en regard des sorties du système. L’exigence de non-discrimination commande donc le traitement des données mêmes dont le droit de la protection des données interdit en principe le traitement.

31Le règlement a résolu ce paradoxe en 2024 par une base juridique dérogatoire, logée à l’article 10, paragraphe 5. Le considérant 70 en donne le fondement : la détection et la correction des biais constituent une raison d’intérêt public important au sens de l’article 9, paragraphe 2, point g), du règlement général sur la protection des données et de l’article 10, paragraphe 2, point g), du règlement (UE) 2018/1725^[22]. La dérogation était étroite : elle ne bénéficiait qu’aux fournisseurs de systèmes à haut risque.

Le déplacement de 2026 : l’article 4 bis

32Le règlement (UE) 2026/1744 a supprimé le paragraphe 5 de l’article 10 et transféré son contenu dans un article 4 bis nouveau, placé au chapitre premier, c’est-à-dire dans les dispositions générales^[23]. Le déplacement n’est pas de pure forme : en sortant du chapitre consacré aux systèmes à haut risque, la base juridique cesse d’être une pièce du régime du haut risque pour devenir une règle de portée générale.

33Le paragraphe 1 de l’article 4 bis reprend le dispositif antérieur pour les fournisseurs de systèmes à haut risque, en explicitant six conditions cumulatives : l’impossibilité d’atteindre le résultat en traitant d’autres données, y compris synthétiques ou anonymisées ; des limitations techniques à la réutilisation et les mesures les plus avancées de sécurité et de protection de la vie privée, y compris la pseudonymisation ; des contrôles stricts et documentés de l’accès ; l’interdiction de toute transmission ou consultation par des tiers ; la suppression des données une fois le biais corrigé ou la durée de conservation expirée ; enfin l’inscription au registre des activités de traitement des raisons pour lesquelles ce traitement était strictement nécessaire et n’aurait pu être remplacé^[24].

34C’est le paragraphe 2 qui opère l’extension, et elle est considérable. La faculté est ouverte aux déployeurs de systèmes à haut risque, ainsi qu’aux fournisseurs et aux déployeurs d’autres systèmes et modèles d’intelligence artificielle — c’est-à-dire, en pratique, à tout opérateur, y compris pour des systèmes qui ne sont pas à haut risque. Les mêmes conditions et garanties leur sont applicables. Le texte prend soin de préciser que ce paragraphe « ne crée aucune obligation de procéder à cette détection et à cette correction des biais »^[25].

35La dernière phrase est la clef de lecture de tout l’article 4 bis. Là où le dispositif de 2024 était le corollaire nécessaire d’une obligation — le fournisseur devait détecter les biais, il fallait donc lui en donner les moyens —, le dispositif de 2026 offre une permission sans contrepartie : un opérateur qui n’est astreint à aucune obligation de détecter les biais se voit néanmoins autorisé à traiter, à cette fin, des données sensibles. La symétrie entre l’obligation et la permission, qui justifiait la dérogation, est rompue.

36Le considérant 9 du règlement modificatif assume ce raisonnement : les biais « pourraient également résulter des actions des déployeurs » et « pourraient aussi survenir dans le cas d’autres systèmes ou modèles d’IA », d’où l’intérêt public important à étendre la base juridique ; celle-ci demeure « soumise aux mêmes limitations, conditions et garanties » que celles de l’ancien article 10, paragraphe 5^[26]. L’argument est sérieux : un biais discriminatoire ne se loge pas seulement dans les systèmes qualifiés à haut risque, et l’exemple donné — les outils d’éligibilité employés pour l’octroi de licences ou de permis publics — est convaincant.

37La prise de position conjointe publiée en juin 2026 par plusieurs organisations de défense des droits fondamentaux a néanmoins visé ce dispositif, en relevant que la pseudonymisation y est retenue comme garantie alors que la ré-identification demeure aisée^[27]. La critique porte moins sur le principe de l’extension que sur le niveau des garanties : celles-ci ont été conçues pour un nombre restreint de fournisseurs soumis à évaluation de la conformité ; elles s’appliquent désormais à un ensemble d’opérateurs beaucoup plus large, dont la plupart ne sont soumis à aucun contrôle de conformité au titre du règlement.

38Il faut ajouter que le Contrôleur européen de la protection des données et le Comité européen de la protection des données ont rendu, le 20 janvier 2026, un avis conjoint sur la proposition — le considérant 47 du règlement modificatif en atteste. Son contenu n’a pu être consulté dans le texte à la date de rédaction du présent article, le document n’étant pas servi ; il n’en est donc rien affirmé ici^[28].

Les systèmes qui n’apprennent pas

39Le paragraphe 6, réécrit en 2026, règle le sort des systèmes qui ne font pas appel à des techniques impliquant l’entraînement de modèles : pour eux, les paragraphes 2, 3 et 4 ainsi que l’article 4 bis, paragraphe 1, ne s’appliquent qu’aux jeux de données de test^[29]. La disposition rappelle une évidence que la conversation publique oublie : un système expert, un moteur de règles ou un système d’optimisation peuvent parfaitement relever du règlement sans avoir jamais été entraînés, et l’exigence de gouvernance des données leur est alors adaptée plutôt qu’écartée.

4. La documentation technique et la journalisation : administrer la preuve

La documentation comme instrument de contrôle

40L’article 11 impose que la documentation technique soit établie avant la mise sur le marché et tenue à jour. Sa fonction est double, et le texte issu de 2026 l’énonce désormais expressément : démontrer que le système satisfait aux exigences de la section 2, et fournir aux autorités nationales compétentes et aux organismes notifiés les informations nécessaires pour en évaluer la conformité, « sous une forme claire et intelligible »^[30]. Le contenu minimal est celui de l’annexe IV.

41L’annexe IV est le document le plus révélateur du règlement, parce qu’elle dit ce que le législateur estime qu’un fournisseur peut savoir de son propre système. Elle exige notamment la logique générale du système et des algorithmes, les principaux choix de conception « y compris le raisonnement et les hypothèses retenues », ce que le système « est conçu pour optimiser » ainsi que la pertinence des différents paramètres, et « les décisions relatives aux compromis éventuels » consentis pour se conformer aux exigences^[31].

42Cette dernière mention mérite d’être soulignée. Exiger la documentation des compromis, c’est reconnaître dans le texte que les sept exigences peuvent entrer en conflit — qu’un gain d’exactitude peut se payer en robustesse, qu’une architecture plus interprétable peut être moins performante, qu’une donnée plus représentative peut être plus intrusive. L’article 9, paragraphe 4, dit la même chose en creux, en imposant de tenir compte « des effets et de l’interaction possibles résultant de l’application combinée des exigences »^[32]. Le règlement n’ordonne pas de résoudre ces conflits d’une manière déterminée : il ordonne de les expliciter.

L’allègement de 2026 pour les petites entreprises

43Le règlement modificatif a ajouté à l’article 11, paragraphe 1, un mécanisme d’allègement : les petites et moyennes entreprises, y compris les jeunes pousses, et les petites entreprises à moyenne capitalisation peuvent fournir les éléments de l’annexe IV « d’une manière simplifiée », au moyen d’un formulaire que la Commission européenne doit établir et que les organismes notifiés sont tenus d’accepter^[33].

44La construction appelle deux remarques. D’une part, l’allègement porte sur la forme de la présentation, non sur les exigences de fond : le formulaire simplifié ne dispense d’aucune des sept exigences, et un système documenté sur formulaire simplifié doit être aussi exact, robuste et contrôlable qu’un autre. D’autre part, l’obligation faite aux organismes notifiés d’accepter le formulaire est une contrainte réelle sur l’évaluation de la conformité : l’organisme ne peut opposer l’insuffisance du format, quoiqu’il demeure libre de conclure à l’insuffisance du contenu.

45La catégorie des « petites entreprises à moyenne capitalisation », introduite en 2026 à l’article 3, point 14 ter, est celle par laquelle la taille de l’entreprise devient un critère de modulation du régime. La prise de position conjointe de juin 2026 déjà citée en fait l’un de ses griefs principaux, au motif que la taille de l’entreprise n’est pas un indicateur du risque que son système fait courir aux personnes^[34]. L’objection est fondée en logique ; elle se heurte à ce que le règlement n’a jamais prétendu être un pur instrument de protection, et le considérant 66 le disait déjà.

La journalisation, ou la traçabilité minimale

46L’article 12 exige que le système permette, techniquement, l’enregistrement automatique des événements tout au long de sa durée de vie. Les fonctionnalités de journalisation doivent être adaptées à la destination et permettre l’enregistrement des événements utiles à trois fins : repérer les situations dans lesquelles le système présente un risque au sens de l’article 79, paragraphe 1, ou subit une modification substantielle ; faciliter la surveillance après commercialisation ; permettre au déployeur de surveiller le fonctionnement du système^[35].

47L’exigence est de capacité, non de conservation : l’article 12 impose que le système permette la journalisation ; c’est l’article 19 qui impose au fournisseur d’assurer la tenue des journaux, et l’article 26 qui l’impose au déployeur. La distinction n’est pas académique : elle explique qu’un système parfaitement conforme à l’article 12 puisse être exploité sans qu’aucun journal ne soit effectivement conservé, si les obligations de la section 3 ne sont pas respectées.

48Le paragraphe 3 est le seul endroit de toute la section 2 où le règlement énumère un contenu minimal précis, et il ne le fait que pour une catégorie : les systèmes d’identification biométrique à distance du point 1, a), de l’annexe III. Pour eux, la journalisation doit comporter la période de chaque utilisation, la base de données de référence, les données d’entrée ayant produit une correspondance et l’identification des personnes physiques ayant vérifié les résultats^[36]. Le contraste avec le reste de la section est éclairant : là où le législateur a voulu être précis, il a su l’être.

5. La transparence : une information due au déployeur, non à la personne

Une transparence instrumentale

49L’article 13 est le plus mal nommé de la section. Intitulé « Transparence et fourniture d’informations aux déployeurs », il ne consacre aucun droit à la transparence : il impose une conception telle que le fonctionnement du système soit « suffisamment transparent pour permettre aux déployeurs d’interpréter les sorties […] et de les utiliser de manière appropriée », le niveau adéquat étant celui qui permet le respect des obligations incombant au fournisseur et au déployeur au titre de la section 3^[37].

50La transparence est donc doublement instrumentale. Elle est mesurée par sa suffisance au regard d’une fin — l’interprétation correcte des sorties — et calibrée par une autre — l’exécution des obligations de la section 3. Il en résulte qu’un système opaque n’est pas, par cela seul, non conforme : il l’est si son opacité empêche le déployeur d’interpréter ses sorties ou de remplir ses propres obligations. La question n’est pas « le système est-il explicable ? » mais « le déployeur en sait-il assez pour faire ce que le règlement lui demande ? ».

51Le créancier de cette information est le déployeur, c’est-à-dire un professionnel. La personne exposée au système n’est destinataire de rien au titre de l’article 13. Ce n’est pas un oubli : le règlement lui réserve deux dispositifs distincts, l’obligation d’information de l’article 50 et le droit à l’explication des décisions individuelles de l’article 86, lequel pèse sur le déployeur et non sur le fournisseur, ne couvre que certains systèmes de l’annexe III et suppose une décision produisant des effets juridiques ou affectant significativement l’intéressé^[38]. Ces dispositifs relèvent d’autres articles de la présente série.

Le contenu de la notice, et ce qu’il n’exige pas

52Le paragraphe 3 énumère le contenu minimal de la notice d’utilisation : l’identité du fournisseur ; les caractéristiques, capacités et limites de performance, au premier rang desquelles la destination et le niveau d’exactitude, de robustesse et de cybersécurité ayant servi de référence aux essais ; les circonstances susceptibles d’engendrer des risques ; les modifications prédéterminées ; les mesures de contrôle humain ; les ressources nécessaires, la durée de vie attendue et la maintenance ; enfin les mécanismes permettant au déployeur de collecter et d’interpréter les journaux^[39].

53Deux éléments de cette liste sont assortis d’une réserve qui en change la nature. Le point b), iv), n’exige les capacités techniques du système à « fournir des informations pertinentes pour expliquer ses sorties » que « le cas échéant » ; le point b), v), n’exige la performance du système à l’égard de groupes de personnes déterminés que dans les mêmes termes^[40]. L’explicabilité n’est donc pas une exigence du règlement : c’est une information due lorsqu’elle existe. Un fournisseur dont le système n’offre aucune capacité d’explication satisfait à l’article 13 en n’en mentionnant aucune.

54Il faut mesurer la portée de ce choix. La doctrine et le débat public ont longtemps présenté le règlement comme instaurant un droit à l’explication des systèmes algorithmiques. Le texte, sur ce point, est plus économe : il impose une transparence fonctionnelle vers un professionnel intermédiaire, et laisse l’explicabilité technique à l’état de la technique. Ce que le règlement exige réellement, c’est que le déployeur sache ce que le système sait faire, dans quelles limites, et à quelles conditions.

Une exigence pratique reléguée dans un considérant

55Le considérant 72 énonce que la notice d’utilisation « devrait être mise à disposition dans une langue aisément compréhensible par les déployeurs visés, déterminée par l’État membre concerné »^[41]. Or aucune disposition du règlement ne reprend cette exigence pour la notice. Le texte impose une langue compréhensible pour les documents destinés aux autorités nationales, pour le mandat du mandataire, pour les certificats des organismes notifiés et pour la déclaration UE de conformité ; il ne l’impose nulle part pour le document destiné à celui qui exploitera le système^[42].

56L’asymétrie est frappante et n’est pas sans conséquence. Un considérant éclaire l’interprétation d’une disposition ; il n’en crée pas. Faute d’un article support, l’exigence linguistique relative à la notice devra être rattachée, si elle l’est, au caractère « accessible et compréhensible pour les déployeurs » qu’impose le paragraphe 2 de l’article 13 — rattachement plausible, mais qui demeure une construction.

6. Le contrôle humain : une exigence de conception

Ce que le contrôle humain n’est pas

57L’article 14 impose que la conception et le développement du système permettent « un contrôle effectif par des personnes physiques pendant leur période d’utilisation », notamment au moyen d’interfaces homme-machine appropriées^[43]. L’exigence pèse donc sur le fournisseur et porte sur la conception : elle n’impose pas qu’un humain intervienne, elle impose que le système rende l’intervention possible et utile.

58Deux confusions doivent être écartées. La première est celle du contrôle humain et de la qualification : adjoindre une supervision humaine à un système ne le fait pas sortir du haut risque, ainsi qu’il est exposé dans l’article consacré à la qualification. La seconde est celle du contrôle humain et de l’interdiction de la décision entièrement automatisée : le règlement n’interdit pas qu’une décision soit prise sans intervention humaine — cette question relève du droit de la protection des données, singulièrement de l’article 22 du règlement général sur la protection des données. L’article 14 exige que le contrôle soit possible, non qu’il soit exercé.

Le biais d’automatisation nommé dans le texte

59Le paragraphe 4 énumère cinq capacités que le système doit conférer, dans la mesure appropriée et proportionnée, aux personnes chargées du contrôle : comprendre les capacités et limites du système et surveiller son fonctionnement ; avoir conscience du biais d’automatisation ; interpréter correctement les sorties ; décider de ne pas utiliser le système, ou d’ignorer, remplacer ou inverser sa sortie ; enfin intervenir ou interrompre le système au moyen d’un bouton d’arrêt ou d’une procédure similaire permettant un arrêt sécurisé^[44].

60L’inscription du biais d’automatisation dans un texte contraignant est un fait rare et notable. Ce phénomène, connu des sciences cognitives, veut que la présence d’une recommandation automatisée dégrade la vigilance de celui qui devrait la contrôler : la supervision humaine tend à devenir une ratification. En l’inscrivant au rang des capacités que le système doit conférer, le législateur admet que le contrôle humain est, par lui-même, une garantie fragile — et il impose au fournisseur de concevoir contre cette fragilité.

61Le considérant 73 précise ce que la conception doit assurer : des contraintes opérationnelles intégrées « qui ne peuvent pas être ignorées par le système lui-même », la réponse du système aux ordres de l’opérateur, et le fait que les personnes chargées du contrôle disposent des compétences, de la formation et de l’autorité nécessaires^[45]. Ce dernier point est significatif : l’autorité de celui qui contrôle est une condition organisationnelle, que le fournisseur ne maîtrise pas et que le déployeur doit assurer au titre de ses propres obligations.

La vérification par deux personnes, et son exception

62Le paragraphe 5 institue la seule règle chiffrée de toute la section : pour les systèmes d’identification biométrique à distance du point 1, a), de l’annexe III, aucune mesure ni décision ne peut être prise par le déployeur sur la base d’une identification qui n’a pas été vérifiée et confirmée séparément par au moins deux personnes physiques disposant des compétences, de la formation et de l’autorité nécessaires^[46]. Le considérant 73 en donne la raison — les conséquences d’une erreur de correspondance biométrique — et en atténue aussitôt la charge, en indiquant qu’il peut suffire que les vérifications séparées soient automatiquement enregistrées dans les journaux^[47].

63Le second alinéa écarte cette garantie pour les systèmes utilisés à des fins répressives ou dans les domaines de la migration, des contrôles aux frontières et de l’asile, lorsque le droit de l’Union ou le droit national considère que son application est disproportionnée. L’exception mérite d’être lue pour ce qu’elle est : la garantie la plus concrète de la section 2 est retirée dans les domaines où l’erreur d’identification produit les effets les plus graves sur les personnes, et son retrait est confié à l’appréciation du législateur national.

7. Exactitude, robustesse et cybersécurité : l’exigence sans mesure

Une exigence dont le règlement ne fixe pas le niveau

64L’article 15 exige que le système atteigne « un niveau approprié d’exactitude, de robustesse et de cybersécurité » et fonctionne « de façon constante à cet égard tout au long de [son] cycle de vie »^[48]. Aucun seuil n’est fixé, aucun indicateur n’est imposé, aucune méthode de mesure n’est prescrite. L’obligation du fournisseur se réduit, au paragraphe 3, à indiquer dans la notice les niveaux d’exactitude atteints et les indicateurs employés : il doit déclarer sa performance, non atteindre une performance déterminée.

65Le texte adopté a inséré, à cet endroit, un paragraphe absent de la proposition de 2021 et qui vaut aveu : la Commission européenne, en coopération avec les parties prenantes « telles que les autorités de métrologie et d’étalonnage des performances », encourage l’élaboration de critères de référence et de méthodes de mesure^[49]. Le considérant 74 rattache expressément cette démarche au droit de l’Union en matière de métrologie légale^[50].

66L’aveu est celui-ci : le règlement impose une exigence dont il reconnaît, dans le même article, que les instruments de mesure n’existent pas encore. Il n’y a rien là de scandaleux — c’est la situation ordinaire d’une réglementation technique qui précède sa normalisation —, mais il faut en tirer la conséquence pratique. Tant que les critères de référence font défaut, l’exactitude d’un système à haut risque se mesure par les indicateurs que son propre fournisseur a choisis, sur les jeux de test qu’il a lui-même constitués. C’est le point où la section 2 dépend le plus étroitement des normes harmonisées, examinées dans l’article consacré à la démonstration de la conformité.

La robustesse et les boucles de rétroaction

67Le paragraphe 4 exige des systèmes « autant de résilience que possible » face aux erreurs, défaillances et incohérences, et impose à cette fin des mesures techniques et organisationnelles ; les solutions redondantes, telles que les plans de sauvegarde ou les mesures de sécurité après défaillance, « peuvent permettre » d’y parvenir^[51]. La comparaison avec la proposition de 2021 montre ici encore un adoucissement : son article 15 disposait que les systèmes « font preuve de résilience », sans réserve de possibilité, et que les solutions techniques redondantes « permettent de garantir la robustesse », à l’indicatif^[52].

68Le même paragraphe traite d’un phénomène propre aux systèmes qui continuent d’apprendre après leur mise sur le marché : les boucles de rétroaction, par lesquelles des sorties biaisées influencent les entrées des opérations futures. Le système doit être développé de manière à éliminer ou réduire ce risque et à assurer un traitement adéquat de ces boucles^[53]. Le considérant 67 en décrit le mécanisme avec une netteté peu commune : les biais inhérents « ont tendance à se renforcer progressivement et ainsi à perpétuer et à amplifier les discriminations existantes », en particulier à l’égard des groupes vulnérables^[54].

La cybersécurité et les attaques nommées

69Le paragraphe 5 est, avec l’annexe IV, le passage le plus technique du règlement. Il exige que les systèmes résistent aux tentatives de tiers non autorisés visant à modifier leur utilisation, leurs sorties ou leur performance en exploitant leurs vulnérabilités, et il énumère les attaques propres à l’intelligence artificielle contre lesquelles des mesures doivent, au besoin, être prises : la manipulation du jeu de données d’entraînement, désignée par le terme d’empoisonnement des données ; l’empoisonnement des composants préentraînés, dit empoisonnement de modèle ; les entrées destinées à induire le modèle en erreur, qualifiées d’exemples contradictoires ou d’invasion de modèle ; enfin les attaques visant la confidentialité ou les défauts du modèle^[55].

70Que le législateur de l’Union ait inscrit dans un texte contraignant une taxinomie d’attaques issue de la littérature technique n’est pas anodin : cela fixe un socle de menaces que le fournisseur ne peut prétendre ignorer, et cela date le texte, puisque cette taxinomie évoluera plus vite que le règlement. Le considérant 76 ajoute la couche d’infrastructure, en rappelant que les attaques peuvent aussi viser les ressources numériques du système ou l’infrastructure de technologies de l’information sous-jacente^[56].

71L’articulation avec le droit de la cybersécurité a connu une évolution instructive. Le considérant 77 du règlement de 2024 annonçait qu’un système relevant du futur règlement sur les exigences horizontales de cybersécurité pour les produits comportant des éléments numériques pourrait démontrer sa conformité à l’article 15 en satisfaisant aux exigences essentielles de ce texte ; il ne pouvait le désigner que par sa description, faute d’un numéro alors publié^[57]. Le règlement modificatif de 2026 a comblé le renvoi : un paragraphe 3 nouveau de l’article 42 dispose que les systèmes relevant du règlement (UE) 2024/2847 et remplissant les conditions de son article 12, paragraphe 1, sont réputés conformes aux exigences de cybersécurité de l’article 15^[58]. Le mécanisme des présomptions relève de l’article consacré à la démonstration de la conformité ; il suffit ici d’observer que l’exigence de cybersécurité du règlement sur l’intelligence artificielle est la seule des sept dont le respect puisse être établi par la conformité à un autre acte de l’Union.

8. Ce que la section 2 ne peut pas produire seule

72Trois traits ressortent de l’examen qui précède, et ils commandent l’appréciation d’ensemble.

73Le premier est l’absence de seuil. Aucune des sept exigences ne fixe de valeur : les données doivent être suffisamment représentatives, le risque résiduel acceptable, le niveau d’exactitude approprié, la résilience aussi grande que possible. Chacun de ces adjectifs renvoie à une appréciation, et cette appréciation appartient d’abord au fournisseur. Ce n’est pas une faiblesse de rédaction : c’est le mode opératoire du nouveau cadre législatif, où l’exigence essentielle est délibérément abstraite et où la norme harmonisée en fournit la mesure. Le règlement a été écrit en supposant que cette mesure existerait.

74Le deuxième est le mouvement d’assouplissement continu. De la proposition de 2021 au texte de 2024, l’exigence absolue de jeux de données exempts d’erreurs est devenue une exigence de moyens, la résilience s’est faite « autant que possible », et l’information du déployeur sur les risques résiduels a disparu. Du texte de 2024 à celui de 2026, la documentation s’est simplifiée pour une catégorie d’entreprises définie par sa taille, et la base juridique du traitement des données sensibles s’est détachée de l’obligation qui la justifiait. Aucun de ces mouvements n’est allé en sens inverse.

75Le troisième est la dépendance. Les exigences des articles 8 à 15 ne sont pas auto-exécutoires : elles supposent des normes harmonisées pour être mesurées, une procédure d’évaluation pour être vérifiées, une surveillance du marché pour être sanctionnées. C’est le retard pris par la première de ces conditions qui a motivé, en 2026, le report de l’application du régime du haut risque. Cette dépendance et ce report sont examinés, respectivement, dans l’article consacré à la démonstration de la conformité et dans celui consacré à l’application dans le temps.

76Il resterait à mesurer ce que ces sept exigences produiront réellement sur la conception des systèmes. La réponse ne se lira pas dans le texte, mais dans les normes que le Comité européen de normalisation et le Comité européen de normalisation électrotechnique publieront, dans les documents que les organismes notifiés accepteront, et, à terme, dans les décisions par lesquelles la Cour de justice de l’Union européenne dira ce que signifie, en droit, qu’un jeu de données soit suffisamment représentatif.