L'AI Act entre en vigueur : ce que l'ingénieur doit livrer

Le règlement (UE) 2024/1689 est entré en vigueur le 1er août 2024. La réaction la plus fréquente que j'ai entendue dans les semaines suivantes : « on a le temps, ça ne s'applique pas tout de suite ».

C'est exact sur le calendrier et faux sur la conséquence pratique. Les obligations s'échelonnent, mais les propriétés qu'elles exigent sont des propriétés d'architecture. On ne les ajoute pas à un système existant : on les y réinjecte, ce qui coûte plusieurs fois plus cher.

Le texte distingue celui qui met un système sur le marché de celui qui l'exploite. Les obligations ne sont pas les mêmes, et une même organisation est très souvent les deux à la fois selon le système considéré.

Utiliser un outil du commerce fait de vous un déployeur. Développer un agent en interne, même sans le vendre, vous rapproche du fournisseur dès lors que vous le mettez en service sous votre propre marque. Cette qualification se tranche système par système, et elle décide de la liste des livrables, d'où l'importance du registre, qui est le premier document à produire.

C'est le point sur lequel je vois le plus d'écart entre l'intention écrite et la réalité constatée.

Une supervision humaine effective suppose que la personne dispose de l'information et du temps. Si un opérateur doit valider deux cents propositions par jour, il valide en bloc, et le dispositif protège juridiquement sans protéger personne. Je dimensionne donc le débit du système sur la capacité de relecture réellement disponible, et je journalise le temps passé sur chaque validation. Ce chiffre est le seul qui permette de démontrer que la supervision existe.

Les interdictions et l'obligation de littératie se sont appliquées au 2 février 2025. Les obligations sur les modèles d'usage général, la gouvernance et le régime de sanctions au 2 août 2025.

Les systèmes à haut risque, eux, ont vu leur échéance déplacée par le règlement omnibus de juillet 2026, un report qui ne solde rien, et que je traite dans l'omnibus ne solde pas le sujet.

Une partie du dossier ne se rédige pas : elle se réclame au fournisseur du modèle, et elle se réclame au moment du contrat. C'est le point qui bloque le plus de dossiers arrivés à maturité.

Trois pièces conditionnent le vôtre : la documentation technique décrivant capacités et limites, le résumé des catégories de données d'entraînement, et la politique en matière de droits d'auteur.

Elles sont en général publiques ; encore faut-il les archiver, datées, le jour de la mise en service. Un document publié aujourd'hui peut avoir changé trois fois quand on en aura besoin. Le détail de cette chaîne figure dans ce qui doit descendre la chaîne.

La journalisation d'abord, toujours : c'est la seule pièce dont le report a un coût irréversible. Une politique se rédige à n'importe quel moment ; des traces ne se reconstituent pas.

Un système qui n'a rien journalisé pendant dix-huit mois ne peut pas produire ces traces, quelle que soit la bonne volonté de l'équipe. Et il ne faut en aucun cas en fabriquer : une fausse pièce coûte plus cher que le manquement qu'elle prétend couvrir.

Cinq champs suffisent, question, extraits fournis, réponse, décision humaine, horodatage, et ils servent autant au diagnostic quotidien qu'au contrôle. L'ordre complet des priorités est détaillé dans ce qui doit exister avant l'échéance.

Une personne par système, une fiche d'une page, un rendez-vous trimestriel : la lourdeur vient de l'organisation choisie, pas de l'obligation elle-même. Le schéma centralisé n'aboutit jamais.

Confier le dossier à un service unique qui doit interroger toutes les équipes et documenter des systèmes qu'il ne connaît pas produit un chantier sans fin.

Le schéma qui fonctionne répartit : chaque équipe rédige la fiche du système qu'elle a construit, en une heure, sur un modèle commun. Un rôle central consolide et relit, sans rédiger. Le format de la fiche est décrit dans écrire la fiche d'un système d'IA.