AI Act Article 13 : comment rédiger des instructions d'utilisation conformes
L'article 13 de l'AI Act impose aux fournisseurs de systèmes d'IA à haut risque de fournir aux déployeurs des instructions d'utilisation précises et structurées. Huit éléments obligatoires, erreurs courantes et modèle annoté section par section.
La plupart des fournisseurs d'IA rédigent leurs instructions d'utilisation en dernier, rapidement, comme une formalité. Sous l'AI Act, cette approche n'est pas simplement insuffisante — elle est non conforme. L'article 13 impose une structure de contenu spécifique et obligatoire aux instructions que les fournisseurs de systèmes d'IA à haut risque doivent fournir aux déployeurs. Cet article vous montre exactement ce qu'il faut inclure, ce qu'il faut éviter et comment structurer un document qui résistera à l'examen d'une autorité de surveillance du marché.
La base légale : l'article 13 en contexte
L'article 13 est intitulé « Transparence et fourniture d'informations aux déployeurs ». C'est l'une des obligations essentielles pour les systèmes d'IA à haut risque listés à l'Annexe III, aux côtés des exigences de documentation technique (article 11), de journalisation (article 12), de supervision humaine (article 14), d'exactitude et de robustesse (article 15) et du système de management de la qualité (article 9).
La logique sous-jacente est celle de la responsabilité par l'information : les déployeurs ne peuvent exercer une supervision humaine réelle — comme l'exige l'article 14 — que s'ils reçoivent les informations nécessaires pour comprendre le système, ses limites et comment intervenir. L'article 13(1) l'énonce explicitement : les instructions doivent permettre aux déployeurs de mettre en œuvre les mesures de supervision humaine spécifiées à l'article 14.
Les huit éléments de contenu obligatoires
L'article 13(3) énumère les informations spécifiques que les instructions d'utilisation doivent contenir. Ce n'est pas une liste non exhaustive de suggestions — c'est une checklist obligatoire :
| # | Élément | Ce que cela signifie en pratique |
|---|---|---|
| 1 | Identité et coordonnées du fournisseur | Dénomination sociale, adresse, interlocuteur Art. 22 pour l'UE |
| 2 | Caractéristiques, capacités et limites du système | Destination d'usage, métriques de performance, modes de défaillance connus |
| 3 | Modifications affectant la documentation de l'Annexe IV | Politique de versionnage, procédure de notification pour les changements substantiels |
| 4 | Mesures de supervision humaine | Interventions spécifiques disponibles pour le déployeur, procédures d'escalade |
| 5 | Exigences informatiques et matérielles | Spécifications minimales pour un fonctionnement fiable |
| 6 | Durée de vie prévue et mesures de maintenance | Calendrier de mise à jour, dates de fin de support, fréquence de réentraînement |
| 7 | Capacités de journalisation | Ce qui est enregistré, durée de conservation, modalités d'accès |
| 8 | Niveaux de performance en matière d'exactitude, robustesse et cybersécurité | Métriques, conditions de test, scénarios de dégradation connus |
Chacun de ces éléments comporte des sous-exigences. « Caractéristiques, capacités et limites », par exemple, doit décrire la destination spécifique pour laquelle le système a été testé et validé — il ne suffit pas de lister des cas d'usage génériques. Vous devez préciser les populations sur lesquelles le système a été validé, les conditions dans lesquelles les métriques de performance ont été mesurées et les scénarios dans lesquels les performances se dégradent.
Comment rédiger chaque section : guide pratique
Section 1 — Identification du fournisseur
Ce n'est pas un en-tête marketing. Incluez la dénomination sociale telle qu'elle figure dans la base de données UE (article 71), le numéro d'enregistrement et une adresse de contact conformité dédiée qui sera surveillée après la mise sur le marché du produit. De nombreux fournisseurs indiquent une adresse de support générique ; les ASM et les déployeurs ont besoin de joindre la personne responsable de la conformité, pas un service d'assistance.
Section 2 — Caractéristiques, capacités et limites
C'est la section qui échoue le plus fréquemment lors des audits. Les trois erreurs les plus courantes :
Trop vague : « Le système peut produire des erreurs dans certains cas. » Cela n'indique rien d'actionnable au déployeur. La formulation correcte précise quels cas, à quelle fréquence et ce que le déployeur doit faire lorsqu'ils surviennent.
Trop technique : Copier une model card rédigée pour des ingénieurs ML dans un document de conformité n'est pas conforme. Le déployeur peut être un service RH, une équipe d'achats hospitalière ou une autorité publique. Rédigez pour le public visé.
Absence de limites d'usage : L'article 13(3)(b) vous oblige à décrire non seulement ce que fait le système, mais ce à quoi il ne doit pas être utilisé. Si le système a été validé sur des adultes de 18 à 65 ans dans un contexte d'Europe occidentale, cela doit être explicitement indiqué. Déployer en dehors de ces paramètres relève du risque du déployeur — mais seulement si vous le lui avez dit.
Section 3 — Modifications et versionnage
Les fournisseurs mettent régulièrement à jour les modèles après le déploiement. L'article 13(3)(c) vous oblige à décrire les types de modifications qui affecteront la documentation figurant à l'Annexe IV. Pratiquement, cela signifie définir dans vos instructions ce qui constitue un « changement substantiel » (déclenchant une nouvelle évaluation de conformité) par opposition à une mise à jour de routine, et comment vous communiquerez l'une ou l'autre catégorie aux déployeurs.
Section 4 — Mesures de supervision humaine
Cette section relie directement l'article 13 à l'article 14. Vous devez décrire les mesures techniques et organisationnelles spécifiques permettant à un déployeur de :
- Surveiller le fonctionnement du système pendant l'utilisation
- Détecter les situations où le système peut être peu fiable
- Neutraliser ou interrompre le système
- Interpréter correctement les sorties du système
Les déclarations génériques (« les utilisateurs doivent vérifier toutes les sorties ») ne satisfont pas à l'exigence. Vous devez spécifier les éléments d'interface, les formats de journaux ou les indicateurs de seuil sur lesquels un déployeur compétent peut agir.
Sections 5-8 — Informations techniques et de performance
Ces sections sont souvent peuplées de déclarations de niveau marketing (« précision de niveau industrie ») plutôt que de spécifications vérifiables. La loi exige des niveaux de performance mesurés dans des conditions de test définies, des spécifications de cybersécurité alignées sur des normes harmonisées (lorsqu'elles sont disponibles) et une divulgation honnête des scénarios de dégradation — par exemple, les baisses de performance dans des environnements à faible bande passante ou avec des données en langue non native.
Article 13 vs. Article 50 : deux publics différents
Une distinction essentielle que les fournisseurs manquent fréquemment : l'article 13 régit l'information aux déployeurs — les organisations qui intègrent et exploitent votre système dans leurs propres produits ou processus. L'article 50 régit les obligations de transparence envers les utilisateurs finaux — les personnes physiques qui interagissent avec le résultat de l'IA.
Les deux documents servent des objectifs différents et s'adressent à des publics différents :
| Article 13 | Article 50 | |
|---|---|---|
| Public | Déployeur (entreprise/organisation) | Utilisateur final (personne physique) |
| Format | Document technique d'instructions | Divulgation au moment de l'interaction |
| Moment | Avant/lors de la fourniture | Au moment de l'interaction |
| Contenu clé | Spécifications techniques, mesures de supervision, limites | Fait de l'interaction IA, obligations spécifiques selon contexte |
| Ton | Professionnel/technique | Clair, accessible |
Fusionner ces deux documents est une erreur de conformité. Les instructions de l'article 13 font partie de la documentation technique ; elles doivent être formelles, complètes et versionnées. Les divulgations de l'article 50 sont opérationnelles ; elles doivent être brèves, contextuelles et lisibles par le grand public.
Structure de modèle annoté
Les intitulés de section suivants satisfont à la checklist de l'article 13(3). Chaque section est annotée avec l'exigence de contenu minimale :
INSTRUCTIONS D'UTILISATION
[Nom du système] — Version [X.X]
Fournisseur : [Dénomination sociale] | Enregistrement UE : [Numéro BD]
Date de révision : [date] | Remplace la version : [X.X]
1. IDENTIFICATION DU FOURNISSEUR
[Dénomination sociale, adresse, contact conformité UE, représentant autorisé le cas échéant]
2. DESCRIPTION DU SYSTÈME
2.1 Destination d'usage [catégorie Annexe III exacte et cas d'usage]
2.2 Capacités [ce que le système fait, en termes mesurables]
2.3 Limites [ce qu'il ne fait pas ; populations/contextes non validés]
2.4 Utilisations interdites [liste explicite des applications hors périmètre]
3. GESTION DES VERSIONS ET DES MODIFICATIONS
3.1 Périmètre de la version actuelle
3.2 Définition du changement substantiel et procédure de notification
3.3 Obligations du déployeur à réception d'une notification de modification
4. SUPERVISION HUMAINE
4.1 Mécanismes de supervision disponibles [liste avec références d'interface]
4.2 Procédure de neutralisation et d'interruption
4.3 Guide d'interprétation des sorties [signification et conduite à tenir]
4.4 Contacts d'escalade
5. EXIGENCES TECHNIQUES
5.1 Minimums matériels et d'infrastructure
5.2 Prérequis d'intégration
5.3 Spécifications et exigences de qualité des données d'entrée
6. DURÉE DE VIE ET MAINTENANCE
6.1 Durée de vie supportée et date de fin de support
6.2 Calendrier et procédure de mise à jour
6.3 Déclencheurs de réentraînement ou de recalibration
7. JOURNALISATION ET AUDIT
7.1 Événements journalisés [liste complète]
7.2 Durée de conservation et format des journaux
7.3 Procédure d'accès du déployeur
8. PERFORMANCE ET SÉCURITÉ
8.1 Métriques d'exactitude [avec conditions de test]
8.2 Spécifications de robustesse [scénarios de dégradation]
8.3 Conformité aux normes de cybersécurité
8.4 Vulnérabilités connues et mesures d'atténuation
Erreurs de rédaction courantes — synthèse
- Rédiger les instructions pour un cas d'usage idéalisé plutôt que pour le contexte réel de déploiement
- Omettre les modes de défaillance connus pour ne pas paraître faible — cela crée une responsabilité, pas une protection
- Utiliser des déclarations de performance qui ne peuvent être reproduites dans des conditions de test vérifiables
- Fournir un document unique lorsque le déployeur opère dans plusieurs contextes réglementaires (ex. : santé + activité générale) nécessitant des conseils différenciés
- Ne pas versionner le document — les ASM s'attendent à pouvoir faire correspondre les instructions à la version du système déployé au moment d'un incident
La plateforme de conformité DILAIG comprend un modèle structuré Article 13 avec des conseils intégrés pour chaque section obligatoire, et un vérificateur de conformité qui signale les contenus incomplets ou non spécifiques avant que vous ne finalisiez votre dossier de documentation technique. Commencez votre évaluation de conformité sur dilaig.com.