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

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 utilisateurs d'interpréter les résultats du système et de les utiliser de manière appropriée ». Ce n'est pas une simple recommandation : c'est une obligation exécutoire, assortie d'amendes pouvant atteindre 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 exige six catégories d'informations distinctes, chacune assortie d'exigences documentaires précises.

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 impose que les systèmes d'IA à haut risque fournissent aux utilisateurs des informations qui soient :

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

Le règlement énumère six catégories d'informations à fournir :

1. L'identité et les coordonnées du fournisseur
2. Les caractéristiques, capacités et limites de performance — y compris l'exactitude, la robustesse et les modes de défaillance connus
3. Les modifications du système et de sa performance — historique des versions et mises à jour
4. Le niveau d'exactitude, de robustesse et de cybersécurité — sous forme de mesures quantitatives
5. Les circonstances connues ou prévisibles susceptibles d'entraîner des risques — cas limites et modes de défaillance
6. Les mesures de contrôle humain — ce que l'opérateur humain est censé faire

Chacun de ces éléments doit être documenté et mis à la disposition des utilisateurs. Si vous déployez un système d'IA à haut risque sans ces informations, vous n'êtes pas conforme.

Les six catégories d'informations en détail

1. Identité et coordonnées du fournisseur

C'est l'exigence la plus simple : les utilisateurs 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 affichés dans l'interface ou la documentation
• Identification claire de l'entité juridique responsable de la conformité

Défaillance courante : déployer 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

Les utilisateurs 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, latence, débit
• 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 du système et de sa performance

Les utilisateurs doivent être informés lorsque le système est mis à jour et de la manière dont sa performance a évolué.

Ce que vérifient les auditeurs :

• Un historique des versions avec des notes de version
• Une comparaison des performances avant et après mise à jour
• Un mécanisme de notification des utilisateurs (courriel, alerte dans l'application, etc.)

Défaillance courante : mettre à jour les modèles en silence, sans informer les utilisateurs ni documenter les évolutions de performance.

4. Niveau d'exactitude, de robustesse et de cybersécurité

L'article 13 exige expressément des mesures quantitatives pour :

• 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

Les utilisateurs doivent être avertis des situations dans lesquelles le système est susceptible d'échouer ou de produire des résultats dangereux.

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 utilisateurs sont formés à ces limites

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

6. Mesures de contrôle humain

L'article 14 impose un contrôle humain pour les systèmes d'IA à haut risque. L'article 13 exige que les utilisateurs soient informés des actions de contrôle qu'ils sont censés accomplir.

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é.

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

Catégorie d'information	Documentation nécessaire	Lacune courante
Identité du fournisseur	Nom, adresse, adresse électronique de contact dans l'interface ou la documentation	Aucune identification du fournisseur
Caractéristiques, capacités, limites	Destination, références de performance, modes de défaillance	Arguments marketing sans données quantitatives
Modifications et mises à jour	Historique des versions, notes de version, notifications aux utilisateurs	Mises à jour silencieuses, sans notification
Exactitude, robustesse, cybersécurité	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	Liste des cas limites, consignes d'atténuation des risques	Aucune documentation des modes de défaillance
Mesures de contrôle humain	Rôle de l'opérateur, supports de formation, mécanismes de dérogation	Aucun rôle de contrôle documenté

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 utilisateurs 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 utilisateurs 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 :

1. Identité du fournisseur : l'interface du système affiche « 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 et mises à jour : lorsque vous mettez le modèle à jour, vous envoyez un courriel à tous les utilisateurs avec un lien vers 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.

Tout cela est réuni dans un document d'information des utilisateurs remis à 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 pouvant atteindre 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 utilisateur 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. Si vous déployez un système d'IA à haut risque dans l'UE, vous avez besoin dès maintenant d'une documentation de conformité à l'article 13.

Anti-modèles courants détectés par Vigilia

L'audit du règlement européen sur l'IA de Vigilia signale les anti-modèles suivants au titre de l'article 13 :

• Aucune documentation destinée aux utilisateurs — le système n'a ni interface ni documentation 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 utilisateurs 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 utilisateurs ne savent pas quelles actions de contrôle ils sont censés accomplir
• Mises à jour silencieuses — le système est mis à jour sans notification aux utilisateurs ni documentation des évolutions de performance
• Aucune identification du fournisseur — les utilisateurs ignorent qui a conçu le système et comment le contacter

Chaque anti-modèle est associé à une estimation de l'exposition aux amendes et à une feuille de route de remédiation.

Comment se mettre en conformité en 20 minutes

L'audit du règlement européen sur l'IA de Vigilia produit une analyse des écarts au titre de l'article 13 en 20 minutes. Vous répondez à des questions sur votre documentation de transparence, l'information des utilisateurs et vos mesures de contrôle. Vigilia met vos réponses en correspondance avec les exigences de l'article 13 et signale les écarts.

Le résultat est un PDF prêt pour l'audit, couvrant :

• un score de conformité à l'article 13 (0 à 100)
• les écarts précis (par exemple « aucun mode de défaillance documenté »)
• une feuille de route de remédiation assortie d'un effort estimé
• des estimations d'exposition aux amendes pour chaque écart

Les audits de conformité traditionnels coûtent de 5 000 à 40 000 € et prennent 1 à 3 mois. Vigilia coûte 499 € et prend 20 minutes.

Générez dès maintenant votre rapport de conformité à l'article 13 : www.aivigilia.com

---

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.