Pour se conformer à l’AI Act sans paralyser ses équipes, il faut des priorités claires. La cartographie des risques n’est pas un exercice bureaucratique ; c’est un outil de triage. Elle consiste à lister vos systèmes d’IA, à comprendre les données qu’ils manipulent et les décisions qu’ils influencent, pour ensuite estimer leur niveau de risque. Cette cartographie guide ensuite l’effort de documentation : là où le risque est élevé, la documentation doit être irréprochable, mais elle doit toujours rester utile, c’est-à-dire courte, à jour et reliée au code.
prérequis
- Un inventaire initial des applications, workflows et de leurs propriétaires.
- Une vue claire des données utilisées : sources, catégories, présence de PII, politiques de rétention.
- Un format de fiche unique et simple pour documenter chaque système.
cartographier en 4 colonnes
L’exercice de cartographie peut être résumé par un tableau simple à quatre colonnes. C’est un processus itératif qui doit impliquer les équipes produit, technique et légale.
- quoi: Le nom du système et son objectif métier en une phrase.
- données: Les catégories de données utilisées (ex: “texte ticket client”), leurs sources, et leur sensibilité (contient des PII ?).
- décision: La décision humaine ou automatisée que la sortie du système influence.
- risques: Le niveau de risque estimé (minimal, limité, élevé) et les mesures de mitigation déjà en place.
la documentation vivante
La documentation n’est utile que si elle est lue et maintenue. Pour cela, elle doit vivre avec le code.
- Co-localisée avec le repo: La documentation principale d’un système d’IA doit être un
README.mdou unemodel-card.mdà la racine de son projet Git. - Champs obligatoires: La fiche doit contenir des sections standardisées : données d’entraînement, limites connues du modèle, résultats des tests de performance, et contacts des propriétaires.
- Changelog obligatoire: Chaque changement significatif (prompt, version du modèle, données) doit être tracé dans un
CHANGELOG.md.
le cycle de vie d’une documentation utile
vérification rapide et continue
- Échantillonnage hebdomadaire: Une personne désignée passe en revue un petit échantillon de réponses pour vérifier la qualité et la conformité.
- Test des limites: Vérifier que le système refuse bien de répondre aux questions qui sortent de son périmètre défini.
- Liens vers les traces: L’interface utilisateur doit permettre, pour chaque réponse, d’accéder à un identifiant de trace unique pour faciliter les investigations.
erreurs courantes
-
Symptôme: La cartographie a été faite une fois, mais elle est déjà obsolète trois mois plus tard.
- Cause: C’est un “one shot” et non un processus.
- Correctif: Ritualiser la mise à jour de la cartographie. Chaque lancement de nouveau projet IA doit inclure la création ou la mise à jour de sa fiche.
-
Symptôme: Personne ne lit la documentation car elle est trop longue.
- Cause: Fiches romanesques qui essaient de tout décrire.
- Correctif: Une page maximum par système. Pour les détails, mettez des liens vers le code, les tests et les dashboards de monitoring.
-
Symptôme: On découvre un système à risque dont personne ne se sent responsable.
- Cause: Pas d’owner clairement identifié.
- Correctif: Le nom et le contact de l’équipe propriétaire doivent être les premières informations visibles sur la fiche du système dans le catalogue.
faq
-
Comment décider si un système est à “haut risque” ? La règle de base est simple : si une erreur du système peut avoir un impact significatif et négatif sur la santé, la sécurité, les finances ou les droits fondamentaux d’une personne, il est probablement à haut risque. En cas de doute, consultez votre sponsor légal.
-
La documentation ne ralentit-elle pas le développement ? Une mauvaise documentation, oui. Une bonne documentation, courte et intégrée au workflow de développement via les pull requests, fait gagner du temps en évitant les ambiguïtés, en facilitant l’onboarding et en clarifiant les responsabilités.