Article 13 du règlement européen sur l'IA : les obligations de transparence pour l'IA à haut risque

Mise à jour du 2 octobre 2026 — correction. Les versions précédentes citaient l'article 13 comme s'il s'adressait aux « utilisateurs » (le texte adopté dit déployeurs), donnaient une liste de six catégories d'informations qui ne correspond pas à l'article 13, paragraphe 3, interprétaient les « modifications » comme des notifications de mise à jour et nommaient des indicateurs d'exactitude que l'article ne nomme pas. Le guide suit désormais l'article 13, paragraphe 3, points a) à f), et ne fait plus référence à un audit payant.

Mise à jour du 31 juillet 2026 — échéance modifiée. Le Digital Omnibus (adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026) a reporté les obligations relatives aux systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027. Les obligations de transparence de l'article 50 n'ont pas été reportées et s'appliquent toujours à partir du 2 août 2026. Cet article a été corrigé en conséquence. Si votre système d'IA est classé à haut risque au titre du règlement européen sur l'IA, l'article 13 impose qu'il soit « suffisamment transparent pour permettre aux déployeurs d'interpréter les sorties d'un système et de les utiliser de manière appropriée » (règlement (UE) 2024/1689, article 13, paragraphe 1). Ce n'est pas une simple recommandation : c'est une obligation exécutoire, assortie d'un plafond légal de 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

La plupart des entreprises sous-estiment l'article 13. Elles supposent que la transparence se résume à « ajouter une clause de non-responsabilité » ou à « afficher des scores de confiance ». En réalité, l'article 13, paragraphe 3, énumère six points d'information que la notice d'utilisation doit contenir au minimum, chacun avec son propre travail de documentation.

Ce guide détaille ce qu'exige réellement l'article 13, les lacunes de conformité courantes et la manière d'intégrer la transparence dans votre système d'IA à haut risque avant l'échéance du 2 décembre 2027.

Ce qu'exige réellement l'article 13

L'article 13 s'impose au fournisseur. Il exige que les systèmes d'IA à haut risque soient accompagnés d'une notice d'utilisation qui fournisse aux déployeurs des informations qui soient :

1. Concises, complètes, exactes et claires — sans jargon ni ambiguïté
2. Pertinentes, accessibles et compréhensibles pour les déployeurs — adaptées à leur rôle et à leur niveau technique
3. Suffisantes pour permettre aux déployeurs d'interpréter les sorties — ils doivent comprendre ce que le système leur indique et pourquoi
4. Suffisantes pour permettre aux déployeurs d'utiliser le système de manière appropriée — ils doivent savoir quand se fier au résultat et quand le contredire

L'article 13, paragraphe 3, précise en six points ce que la notice d'utilisation doit contenir au minimum :

1. a) L'identité et les coordonnées du fournisseur — et de son mandataire, le cas échéant
2. b) Les caractéristiques, capacités et limites de performance — y compris la destination ; le niveau d'exactitude, y compris ses indicateurs, de robustesse et de cybersécurité ; les circonstances connues ou prévisibles susceptibles d'entraîner des risques ; et, le cas échéant, les informations permettant d'expliquer les sorties, la performance à l'égard de groupes de personnes spécifiques, ainsi que les données d'entrée et d'entraînement
3. c) Les modifications prédéterminées par le fournisseur — les modifications du système et de sa performance arrêtées lors de l'évaluation initiale de la conformité, le cas échéant
4. d) Les mesures de contrôle humain — celles visées à l'article 14, y compris les mesures techniques qui aident les déployeurs à interpréter les sorties
5. e) Les ressources informatiques et matérielles, la durée de vie attendue et la maintenance — y compris la fréquence des mesures de maintenance et de suivi et des mises à jour logicielles
6. f) Les mécanismes de journalisation — le cas échéant, la manière dont les déployeurs peuvent collecter, stocker et interpréter les journaux exigés par l'article 12

Le fournisseur doit fournir ces informations. Le déployeur doit ensuite utiliser le système conformément à la notice d'utilisation (article 26, paragraphe 1). Un système mis sur le marché sans cette notice ne semble pas satisfaire à l'article 13.

Les informations en détail

Les sections ci-dessous reprennent les points dans l'ordre où la plupart des équipes les abordent. L'exactitude et les risques prévisibles relèvent tous deux du point b), mais ils ont chacun leur section, car c'est là que se trouvent la plupart des lacunes.

1. Identité et coordonnées du fournisseur — point a)

C'est l'exigence la plus simple : les déployeurs doivent savoir qui a conçu le système et comment le contacter.

Ce que vérifient les auditeurs :

• Nom, adresse et adresse électronique de contact du fournisseur dans la notice d'utilisation
• Identification claire de l'entité juridique responsable de la conformité, et du mandataire le cas échéant

Défaillance courante : livrer un système sans identification du fournisseur, ou enfouir les coordonnées dans des conditions générales de 50 pages.

2. Caractéristiques, capacités et limites de performance — point b)

Les déployeurs doivent comprendre ce que le système peut et ne peut pas faire. Cela recouvre :

• La destination — ce pour quoi le système est conçu
• Les caractéristiques de performance — exactitude, robustesse et, le cas échéant, performance à l'égard des personnes ou groupes de personnes spécifiques sur lesquels le système est destiné à être utilisé
• Les limites connues — les tâches que le système ne peut pas accomplir de manière fiable

Ce que vérifient les auditeurs :

• Une spécification écrite de la destination et des cas d'usage hors périmètre
• Des références de performance (par exemple « 92 % d'exactitude sur le jeu de validation »)
• La documentation des modes de défaillance connus (par exemple « performances faibles sur le texte manuscrit »)

Défaillance courante : ne fournir que des arguments marketing (« exactitude à l'état de l'art ») sans données de performance quantitatives ni limites documentées.

3. Modifications prédéterminées — point c)

Le point c) porte sur les modifications du système et de sa performance que le fournisseur a arrêtées à l'avance, au moment de l'évaluation initiale de la conformité, le cas échéant. C'est surtout important pour les systèmes qui continuent d'apprendre : les modifications prédéterminées à ce stade et consignées dans la documentation technique ne constituent pas une modification substantielle, tandis que les autres modifications substantielles exigent une nouvelle évaluation de la conformité (article 43, paragraphe 4). Le point e) porte séparément sur les mesures de maintenance et de suivi, y compris les mises à jour logicielles.

L'article 13 n'exige ni courriels de mise à jour ni notes de version. Tenir les déployeurs informés lorsque le système change reste une bonne pratique, et rend les points c) et e) plus faciles à démontrer.

Ce que vérifient les auditeurs :

• Une description des modifications prédéterminées, cohérente avec la documentation technique
• Une comparaison des performances avant et après mise à jour
• Un calendrier de maintenance et de mises à jour à l'intention des déployeurs

Défaillance courante : modifier un modèle d'une manière que la notice d'utilisation n'a jamais décrite, sans vérifier si la modification est une modification substantielle.

4. Niveau d'exactitude, de robustesse et de cybersécurité — point b) ii)

L'article 13 exige que la notice indique le niveau d'exactitude, y compris ses indicateurs, de robustesse et de cybersécurité visé à l'article 15, au regard duquel le système a été testé et validé, ainsi que toute circonstance connue susceptible d'avoir une incidence sur ce niveau. Il ne nomme pas les indicateurs. Selon la tâche, il peut s'agir de :

• L'exactitude — précision, rappel, F1 ou mesures propres au domaine
• La robustesse — performance face à des entrées adverses ou à un décalage de distribution
• La cybersécurité — résistance à l'empoisonnement des données, à l'extraction de modèle ou aux attaques adverses

Ce que vérifient les auditeurs :

• Des rapports de performance sur le jeu de test avec intervalles de confiance
• Des références de robustesse (par exemple la performance sur des données hors distribution)
• Des rapports d'audit de cybersécurité ou des résultats de tests d'intrusion

Défaillance courante : ne communiquer qu'une exactitude globale, sans ventilation par groupe démographique, cas limite ou scénario adverse.

5. Circonstances connues ou prévisibles susceptibles d'entraîner des risques — point b) iii)

Les déployeurs doivent être avertis des situations, en cas d'utilisation conforme à la destination ou de mauvaise utilisation raisonnablement prévisible, susceptibles d'entraîner des risques pour la santé, la sécurité ou les droits fondamentaux.

Ce que vérifient les auditeurs :

• Une liste documentée des cas limites et des modes de défaillance
• Des consignes d'atténuation des risques (par exemple « Ne pas utiliser ce système à des fins de diagnostic médical »)
• La preuve que les personnes qui utilisent le système sont formées à ces limites

Défaillance courante : ne fournir aucune documentation des modes de défaillance, en supposant que les déployeurs « s'en apercevront ».

6. Mesures de contrôle humain — point d)

L'article 14 impose un contrôle humain pour les systèmes d'IA à haut risque. L'article 13 exige que la notice d'utilisation décrive ces mesures de contrôle, y compris les mesures techniques qui aident les déployeurs à interpréter les sorties.

Ce que vérifient les auditeurs :

• La documentation du rôle de l'opérateur humain (par exemple « Examiner tous les dossiers signalés avant la décision finale »)
• Les supports de formation destinés aux opérateurs humains
• La preuve que le système permet ce contrôle (fonctions d'explicabilité, mécanismes de dérogation, etc.)

Défaillance courante : déployer un système entièrement automatisé sans rôle de contrôle humain documenté.

7. Ressources, maintenance et journaux — points e) et f)

La notice doit aussi indiquer les ressources informatiques et matérielles dont le système a besoin, sa durée de vie attendue et les mesures de maintenance et de suivi qui assurent son bon fonctionnement, y compris les mises à jour logicielles et leur fréquence. Le cas échéant, elle doit décrire la manière dont les déployeurs peuvent collecter, stocker et interpréter les journaux que le système enregistre au titre de l'article 12.

Ce que vérifient les auditeurs :

• Une spécification du matériel et de l'infrastructure
• Une durée de vie attendue déclarée et un calendrier de maintenance
• Des instructions pour accéder aux journaux et les conserver

Défaillance courante : laisser les déployeurs découvrir après la mise en service les besoins du système en matière de journalisation et de maintenance.

Liste de contrôle de conformité à l'article 13

Information (article 13, paragraphe 3)	Documentation nécessaire	Lacune courante
Identité du fournisseur — a)	Nom, adresse, adresse électronique de contact dans la notice d'utilisation	Aucune identification du fournisseur
Caractéristiques, capacités, limites — b)	Destination, références de performance, modes de défaillance	Arguments marketing sans données quantitatives
Exactitude, robustesse, cybersécurité — b) ii)	Rapports sur le jeu de test, références de robustesse, audits de sécurité	Exactitude globale uniquement, sans ventilation par cas limite
Risques et modes de défaillance connus — b) iii)	Liste des cas limites, consignes d'atténuation des risques	Aucune documentation des modes de défaillance
Modifications prédéterminées — c)	Modifications arrêtées lors de l'évaluation initiale de la conformité	Modifications du modèle non décrites
Mesures de contrôle humain — d)	Rôle de l'opérateur, supports de formation, mécanismes de dérogation	Aucun rôle de contrôle documenté
Ressources, durée de vie, maintenance — e)	Besoins matériels, durée de vie attendue, calendrier des mises à jour	Aucune information de maintenance
Mécanismes de journalisation — f)	Comment collecter, stocker et interpréter les journaux	Les journaux existent mais les déployeurs n'y ont pas accès

Comment l'article 13 s'articule avec les autres exigences

L'article 13 n'existe pas isolément. Il croise :

• L'article 9 (gestion des risques) — les risques recensés au titre de l'article 9 doivent être communiqués aux déployeurs au titre de l'article 13
• L'article 10 (gouvernance des données) — les mesures de qualité des données documentées au titre de l'article 10 nourrissent les informations d'exactitude exigées par l'article 13
• L'article 14 (contrôle humain) — les mesures de contrôle conçues au titre de l'article 14 doivent être expliquées aux déployeurs au titre de l'article 13
• L'article 50 (transparence de certains systèmes d'IA) — si votre système relève aussi de l'article 50 (agents conversationnels, reconnaissance des émotions, etc.), vous êtes soumis à des obligations de transparence supplémentaires, applicables depuis le 2 août 2026

Une stratégie de conformité complète traite tous ces éléments ensemble, et non comme des listes de contrôle isolées.

Exemple concret : un système de notation de crédit

Supposons que vous ayez construit un système de notation de crédit assisté par IA. Au titre de l'annexe III, point 5 b), il s'agit d'un système à haut risque. Voici à quoi ressemble la conformité à l'article 13 (l'entreprise ci-dessous est fictive) :

1. Identité du fournisseur : la notice d'utilisation indique « Fourni par FinTech Corp, 123 Main St, Dublin, Irlande. Contact : compliance@fintechcorp.eu »
2. Caractéristiques, capacités, limites : vous documentez que le système est conçu pour des décisions de crédit à la consommation jusqu'à 50 000 €, atteint 89 % d'exactitude sur les données de validation et donne de mauvais résultats pour les demandeurs disposant d'un historique de crédit ténu (moins de 3 lignes de crédit).
3. Modifications prédéterminées et maintenance : vous indiquez quelles modifications du modèle et de sa performance ont été arrêtées lors de l'évaluation initiale de la conformité, ainsi que le calendrier des mises à jour. Lorsque vous mettez le modèle à jour, vous envoyez aussi aux déployeurs des notes de version indiquant la nouvelle exactitude (91 %) et l'évolution des taux de faux positifs et de faux négatifs.
4. Exactitude, robustesse, cybersécurité : vous fournissez un rapport de performance présentant la précision, le rappel et le F1 par groupe démographique, ainsi que des résultats de tests de robustesse mesurant la performance face à des entrées adverses (par exemple des demandeurs qui déclarent délibérément un revenu erroné).
5. Risques connus : vous documentez que le système peut sous-estimer le risque pour les travailleurs indépendants et le surestimer pour les personnes récemment immigrées. Vous fournissez la consigne suivante : « Examiner manuellement toutes les demandes émanant de travailleurs indépendants et de personnes récemment immigrées. »
6. Contrôle humain : vous documentez que les chargés de prêt doivent examiner toutes les demandes signalées comme « limites » (score de 600 à 650) et qu'ils ont le pouvoir d'écarter la recommandation du système.
7. Ressources et journaux : vous indiquez l'infrastructure dont le système a besoin, sa durée de vie attendue et la manière dont le prêteur peut récupérer et conserver les journaux de décision.

Tout cela est réuni dans la notice d'utilisation remise au prêteur, qui la transmet à chaque chargé de prêt qui utilise le système. Lorsqu'un auditeur demande des preuves au titre de l'article 13, vous lui remettez ce document ainsi que les registres de formation attestant que les chargés de prêt y ont été formés.

Ce qui se passe en cas de non-conformité

La non-conformité à l'article 13 peut entraîner :

• des amendes administratives — un plafond légal de 15 millions d'euros ou 3 % du chiffre d'affaires mondial au titre de l'article 99, paragraphe 4 — pour les PME, le montant le plus faible ;
• des mesures de surveillance du marché — les autorités nationales peuvent vous ordonner de retirer votre système du marché ou d'en suspendre l'utilisation ;
• une exposition en responsabilité — si un déployeur fait un mauvais usage de votre système parce que vous n'avez pas fourni d'informations adéquates, vous pouvez être tenu responsable des dommages en résultant.

La date opérante pour les systèmes à haut risque de l'annexe III est le 2 décembre 2027. Un fournisseur qui met un système d'IA à haut risque sur le marché de l'UE à partir de cette date devra disposer, à ce moment-là, d'une notice d'utilisation conforme à l'article 13.

Anti-modèles courants

Ces anti-modèles au titre de l'article 13 sont les plus fréquents :

• Aucune documentation destinée aux déployeurs — le système n'a pas de notice d'utilisation expliquant sa destination, ses limites ou sa performance
• Arguments marketing sans données quantitatives — le système revendique une « exactitude élevée » sans fournir de mesures sur le jeu de test
• Aucune documentation des modes de défaillance — les déployeurs ne sont pas avertis des cas limites ou des situations dans lesquelles le système est susceptible d'échouer
• Aucune consigne de contrôle humain — les déployeurs ne savent pas quelles mesures de contrôle ils sont censés appliquer
• Modifications non décrites — le système change d'une manière que la notice d'utilisation n'a jamais prédéterminée, sans information de maintenance ni de mise à jour
• Aucune identification du fournisseur — les déployeurs ignorent qui a conçu le système et comment le contacter

---

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil juridique. Consultez un avocat qualifié en droit du règlement européen sur l'IA pour obtenir des orientations adaptées à votre situation.