Qu’est-ce que l’accord politique sur l’AI Act de décembre 2023 ?
L’accord politique annoncé en décembre 2023 fixe un compromis provisoire sur le futur règlement européen sur l’IA, mais il ne constitue pas encore un texte adopté et applicable.
Le Conseil annonce l’accord le 9 décembre 2023. La rédaction juridique et les votes formels restent à venir. L’approche par le risque, les interdictions envisagées et les exigences du haut risque donnent néanmoins des orientations suffisamment précises pour préparer l’architecture.
Je ne les présente pas comme une obligation déjà opposable à toute organisation. Je les traite comme des décisions de conception à anticiper, avec les autres règles déjà applicables, notamment la protection des données.
Pourquoi un ingénieur devrait-il lire un texte réglementaire ?
Un ingénieur doit examiner les exigences envisagées parce que leur mise en œuvre demande des propriétés techniques qui se construisent avec le système, et pas seulement des documents.
Attendre une relecture juridique en fin de projet laisse peu de marge pour revoir les accès, enregistrer une validation ou expliquer la provenance d’une réponse. Le juridique qualifie l’usage ; l’équipe technique apporte les moyens de tenir cette qualification.
Ce partage évite deux erreurs : croire que tout sera résolu par une charte, ou croire que la technique peut seule décider du régime applicable. Je commence par décrire la chaîne réelle et les décisions qu’elle sert.
Pourquoi la classification par le risque décide-t-elle de tout le reste ?
La classification par le risque décide de tout le reste parce que l’AI Act ne classe pas les technologies mais les usages : le même modèle peut être sans obligation particulière ou à haut risque.
Un résumé interne et un tri de candidatures ne présentent pas le même usage. Une fonction de recrutement peut relever du haut risque envisagé ; le résumé n’est pas automatiquement hors de toutes les règles, notamment de confidentialité.
Cette distinction a une conséquence pratique immédiate : deux systèmes techniquement identiques peuvent relever de régimes complètement différents. Ce n’est donc pas au fournisseur du modèle de répondre à la question, mais à celui qui décide de l’usage, c’est-à-dire, très souvent, l’organisation elle-même.
Le critère qui oriente le plus vite est de savoir si le système intervient dans une décision qui affecte les droits d’une personne. C’est la même ligne que celle tracée dans ce qu’on ne délègue jamais à un modèle, et ce n’est pas un hasard : la responsabilité guide le cadrage, sans remplacer l’examen des catégories prévues.
Quelles propriétés techniques faut-il anticiper pour le haut risque ?
Pour un usage susceptible de relever du haut risque, les propriétés à anticiper concernent les données, la documentation, la gestion des risques, les traces et la supervision.
- Documentation technique : ce que fait le système, sur quelles données, avec quelles limites connues. À écrire pendant, jamais après.
- Gestion des risques : identifier ce qui peut mal tourner, et ce qu’on a mis en face. Un tableau tenu, pas une intention.
- Gouvernance des données : provenance, qualité, représentativité. Savoir répondre à « d’où vient ce corpus ».
- Journalisation : conserver la trace de ce qui a été demandé, retrouvé et répondu. C’est une décision d’architecture, pas une option.
- Supervision humaine : un humain qui peut arrêter, corriger, reprendre : avec le temps et l’information pour le faire.
- Information des personnes : savoir qu’on interagit avec un système d’IA.
Quelle décision d’architecture correspond à chaque exigence ?
Chaque exigence annoncée par l’accord politique se traduit par une décision d’architecture précise, dont le coût est faible au départ et élevé une fois le système en exploitation.
| Exigence annoncée | Décision d’architecture | Si on l’ajoute après coup |
|---|---|---|
| Documentation technique | Fiche du système tenue dans le dépôt de code | Reconstitution par entretiens, souvent incomplète |
| Gestion des risques | Registre des risques ouvert au cadrage | Analyse rétrospective sans trace des choix faits |
| Gouvernance des données | Provenance enregistrée à l’ingestion de chaque document | Corpus dont plus personne ne connaît l’origine |
| Journalisation | Schéma de traces prévu dès le premier prototype | Reprise du modèle de données et de l’interface |
| Supervision humaine | Point de validation conçu dans le parcours | Ajout d’une étape que le débit ne permet pas de tenir |
| Information des personnes | Mention intégrée à l’interface | Modification de tous les points de contact |
La troisième ligne rejoint un constat déjà fait sur les projets documentaires : le corpus est le projet, et sa provenance se perd si elle n’est pas notée au moment où il est constitué.
Pourquoi la journalisation est-elle le point qu’on regrette le plus tard ?
La journalisation est l’obligation la plus coûteuse à ajouter après coup, parce qu’elle oblige à reprendre le schéma de données, la durée de conservation et parfois l’interface d’un système déjà en exploitation.
Journaliser les entrées, les documents retrouvés, la réponse produite et l’action de l’humain qui a validé, c’est trivial quand on le prévoit dès le départ. C’est un chantier de plusieurs semaines quand le système est déjà en exploitation, parce qu’il faut reprendre le schéma de données, arbitrer la durée de conservation, traiter les données personnelles qui s’y trouvent, et parfois refaire l’interface pour capter la validation humaine qui n’était nulle part enregistrée.
Dans une architecture de récupération documentaire, comme celle décrite dans le RAG, la seule architecture qui tienne, la trace utile comprend aussi les passages retrouvés : sans eux, on ne peut pas expliquer pourquoi le système a répondu ce qu’il a répondu.
Pourquoi prévoir les contrôles dès l’architecture ?
Prévoir les contrôles dès l’architecture évite de découvrir après le prototype que les données, les interfaces ou les traces ne permettent pas de tenir les exigences envisagées.
Concevoir conforme coûte une fraction de ce que coûte la mise en conformité rétroactive. Ce n’est pas un argument moral, c’est un argument de charge : les propriétés exigées par le texte sont des propriétés d’architecture, et une architecture se change mal une fois qu’elle porte des usages.
Que faut-il faire dès maintenant, sans attendre le texte final ?
Sans attendre le texte définitif, une équipe technique peut déjà faire cinq gestes peu coûteux qui seront utiles quel que soit le détail final du règlement.
- Lister les systèmes qui appellent un modèle. Y compris les prototypes et les outils montés par une équipe métier.
- Qualifier l’usage de chacun. Intervient-il dans une décision qui affecte une personne ? Si oui, il faut le traiter comme candidat au haut risque.
- Activer la journalisation. Entrées, sources retrouvées, réponse, validation humaine. Définir les événements utiles, les accès et la conservation ; les événements anciens ne se reconstruisent pas à l’identique.
- Écrire une fiche d’une page par système. Finalité, données, limites connues, personne responsable.
- Repérer les usages proches d’une interdiction. La liste est courte et se vérifie en une réunion.
Les équipes peuvent collecter ces informations ; une qualification discutée doit être examinée avec les fonctions compétentes. Ils évitent l’erreur décrite dans l’anatomie d’un PoC qui ne passe jamais : découvrir en fin de prototype une exigence qui aurait dû orienter le début. Un audit IA permet de faire ce premier tri avec un regard extérieur.
Quelles erreurs les équipes techniques commettent-elles face au texte ?
Les erreurs les plus courantes des équipes techniques face à l’AI Act consistent à attendre le texte final, à déléguer la question au juridique et à croire que le fournisseur du modèle portera la conformité.
- Attendre la version définitive. Les choix structurants sont connus ; les ajustements de détail ne changeront pas la nécessité de tracer et de documenter.
- Renvoyer le sujet au service juridique. Le juriste qualifie l’usage ; il ne peut pas ajouter une journalisation à un système qui n’en a pas.
- Compter sur le fournisseur. Le fournisseur répond de son modèle, pas de l’usage qu’en fait l’organisation.
- Tout classer à haut risque par prudence. La finalité doit être examinée avant de classer un assistant documentaire ; son nom ne suffit pas à le qualifier.
Comment distinguer les émotions des salariés et celles des clients ?
L’analyse des émotions des salariés et celle des clients doivent être distinguées, car l’accord prévoit une interdiction liée au travail et à l’enseignement, sans couvrir tout centre d’appels.
Un exemple générique permet de poser la frontière. Déduire l’agacement des conseillers à partir de leur voix vise des personnes au travail. L’accord annoncé inclut cette catégorie dans les pratiques qui seraient interdites.
Analyser la voix de clients n’entre pas automatiquement dans cette même interdiction. Le communiqué annonce aussi une information des personnes exposées à la reconnaissance des émotions. Il faut donc examiner la personne concernée, la finalité et le traitement, sans déduire une autorisation générale de la seule absence d’interdiction.
À cette date, je reste au niveau de l’accord provisoire. Je ne cite pas les numéros d’articles du règlement qui sera adopté ultérieurement. Les dispositions précises et leurs exceptions devront être contrôlées dans le texte final.
Que préparer au début d’un chantier réglementaire ?
Au début d’une mission, l’inventaire des systèmes et une description de chaque usage donnent les informations nécessaires pour identifier les points techniques et juridiques à examiner.
Il faut inclure les fonctions intégrées aux logiciels, les prototypes et les automatisations métier. Pour chaque système : finalité, entrées, sorties, destinataires et personne responsable.
La durée dépend du périmètre. Une première fiche peut révéler une question de droits d’accès ou de décision automatisée qui exige un travail complémentaire. Ce point de départ ne suffit pas à conclure à la conformité.
Les équipes peuvent déjà organiser les traces utiles, définir leur accès et leur conservation, puis préparer des situations de supervision. Je préfère un inventaire incomplet dont les lacunes sont identifiées à une déclaration rassurante qui efface les inconnues.
Quelles questions fréquentes se poser sur l’accord politique ?
Pourquoi un ingénieur devrait-il lire ce texte ?
Parce que ses exigences se traduisent en décisions d’architecture, journalisation, traçabilité des sources, points de validation humaine, qui coûtent peu si elles sont prises au départ et beaucoup après. Le juridique qualifie l’usage, mais seule l’équipe technique peut construire ces propriétés.
L’accord de décembre 2023 est-il le texte définitif ?
Non; C’est un accord politique entre le Parlement et le Conseil, qui doit encore être mis en forme juridique et voté formellement. Les choix structurants, classification par le risque, interdictions, obligations du haut risque, sont toutefois arrêtés.
Quel chantier fallait-il lancer en premier ?
La journalisation; Une politique se rédige à n’importe quel moment ; des journaux ne se reconstituent pas, et ce qui n’a pas été tracé est perdu pour le contrôle comme pour le diagnostic.
L’accord interdit-il toute analyse d’émotions en centre d’appels ?
L’accord vise la reconnaissance d’émotions au travail et dans l’enseignement ; l’analyse de clients ne relève pas automatiquement de cette catégorie, mais appelle un examen des règles pertinentes. Le texte est encore provisoire.
La classification par le risque est-elle difficile à établir ?
La qualification dépend de la finalité, du contexte et des catégories envisagées, et ne peut pas être déduite du seul nom d’un assistant ou d’un modèle. Les cas discutés doivent être instruits.
Le fournisseur du modèle est-il responsable de la conformité ?
Il répond de son modèle, pas de l’usage que l’organisation en fait; Le niveau de risque dépend de cet usage, et c’est donc l’organisation qui le qualifie et en tire les conséquences techniques.