AI Act : préparer la conformité sans réduire le projet à une étiquette

Le règlement européen sur l'intelligence artificielle adopte une approche fondée sur les risques. Une entreprise ne peut donc pas classer tout son portefeuille avec le seul nom du fournisseur ou la présence d'un modèle génératif. Elle doit décrire ce que fait le système, pour qui et avec quelles conséquences.

Le périmètre avant l'outil

Le rôle change les obligations : fournisseur, déployeur, importateur ou distributeur ne porte pas la même responsabilité. Un même service peut aussi prendre une portée différente selon qu'il aide à rédiger une note interne ou qu'il intervient dans une décision affectant une personne. La documentation doit suivre ces usages réels.

Commencez par une unité que l'équipe sait nommer : un service, un processus, une classe de données ou un chemin d'accès. Associez-lui un propriétaire, une dépendance métier et une conséquence observable. Cette discipline évite les programmes trop larges où chaque équipe attend qu'une autre commence.

Les contrôles qui changent la situation

Tenir un inventaire des systèmes et de leurs propriétaires. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Décrire chaque finalité et les personnes affectées. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Qualifier le rôle de l'entreprise dans la chaîne. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Identifier les obligations de transparence et de maîtrise. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Tracer les validations et changements importants. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.

Un contrôle n'est pas une intention. Il existe lorsque sa portée est connue, qu'une personne peut montrer sa configuration et qu'un test révèle son échec. Si l'une de ces conditions manque, classez-le comme chantier en cours avec une date de reprise.

Ce que disent les sources primaires

Le point de référence est Cadre réglementaire européen de l'intelligence artificielle . La Commission présente une approche fondée sur les risques, des obligations qui dépendent du rôle et de l'usage, ainsi que des exigences de transparence pour certaines interactions avec un système d'IA.

Pour vérifier le cadre, consultez Fiches pratiques sur l'intelligence artificielle . Les fiches pratiques détaillent la qualification des acteurs, la collecte des données, l'analyse d'impact, l'exercice des droits et la documentation attendue au fil du projet.

La méthode peut être rapprochée de AI Risk Management Framework . Le cadre propose quatre fonctions complémentaires, gouverner, cartographier, mesurer et gérer, afin de traiter les risques d'un système d'IA dans son contexte d'usage.

Ces références donnent un cadre commun, pas une réponse automatique au cas particulier. Reprenez les termes applicables à votre système et indiquez ce qui reste à confirmer. Une source peut soutenir plusieurs décisions sans être répétée à chaque phrase.

Un scénario pour éprouver la méthode

Un service de ressources humaines teste un assistant pour résumer des candidatures. Le projet est d'abord enregistré comme simple outil de productivité. La cartographie révèle que la sortie influence la présélection. L'équipe suspend l'automatisation, précise le rôle humain et demande une analyse juridique liée au cas d'usage réel.

Le scénario sert à tester l'enchaînement des décisions. Changez une hypothèse, comme l'absence d'un responsable ou l'indisponibilité d'un fournisseur, puis observez si le plan garde un chemin praticable. Un dispositif robuste ne dépend pas d'une seule personne ni d'une seule console.

Le plan de travail en cinq passages

Lister les systèmes déjà utilisés, y compris les essais locaux. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Séparer outil général et cas d'usage. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Documenter les données d'entrée et la sortie attendue. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Relier chaque risque à une mesure et une preuve. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Programmer une revue lors d'un changement de modèle. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.

Chaque passage doit rester assez petit pour être repris. La progression vient de la fermeture des écarts, pas du nombre de réunions. Lorsque le test contredit la documentation, corrigez d'abord l'état réel, puis la procédure qui devra le reproduire.

Les preuves à conserver

Fiche système et version
Finalité approuvée
Analyse du rôle
Notice utilisateur
Compte rendu de supervision

Une preuve utile est datée, liée à un périmètre et compréhensible par une personne qui n'a pas participé au projet. Évitez les captures isolées sans contexte. Préférez un rapport court qui nomme la commande, le résultat attendu, l'écart et l'action décidée.

Les pièges qui affaiblissent le programme

Classer un fournisseur au lieu d'un usage. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Confondre expérimentation et absence d'obligation. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Oublier un tableur qui consomme l'API. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Documenter après la mise en production. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Présenter une aide comme une décision sans intervention humaine. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.

Ces pièges viennent souvent d'une volonté d'aller vite. Leur antidote est un retour au service réel, à la personne qui en dépend et au test que l'on peut rejouer. Une décision prudente peut être temporaire, à condition que sa date de réexamen soit explicite.

La prochaine décision utile

Le dossier minimal relie une personne responsable, une finalité, un contexte et une version. Cette base permet de suivre les échéances réglementaires sans reconstruire l'historique du projet. Elle rend aussi visibles les usages qui méritent une expertise complémentaire.

Écrivez la décision avec son responsable, sa date et la condition qui permettra de la fermer. Le sujet devient alors pilotable : l'entreprise sait ce qu'elle protège, ce qu'elle ignore encore et comment vérifier la prochaine étape.