AI Act : ce que le report change et ce qui reste applicable

Un report d’échéance ne répond pas à la question principale : quelles règles s’appliquent au système que votre organisation utilise ? Il faut relier le calendrier à la finalité, à la catégorie et au rôle de chaque acteur. Sans cette qualification, une date rassurante peut conduire à suspendre un travail qui reste nécessaire.

Cette version, révisée le 25 septembre 2026, remplace une présentation trop générale du calendrier. Elle ne prétend pas disposer d’un an de recul sur le Digital Omnibus de juillet 2026. Elle distingue les dates publiées, leurs conditions et les mesures opérationnelles qu’une équipe peut préparer dès maintenant.

La présentation officielle de la Commission rappelle l’application des interdictions et de la littératie depuis le 2 février 2025, puis des règles de gouvernance et relatives aux modèles à usage général depuis août 2025. La plupart des dispositions s’appliquent depuis le 2 août 2026, sous réserve des exceptions et transitions prévues.

Après le règlement modificatif 2026/1744, la Commission indique le 2 décembre 2027 pour les systèmes à haut risque de l’annexe III et le 2 août 2028 pour ceux liés aux produits réglementés de l’annexe I. Ces repères ne constituent pas une dispense générale jusque-là. Les conditions propres au système et aux dispositions concernées doivent être vérifiées.

Le bon livrable est donc une liste d’obligations qualifiées, chacune accompagnée de sa référence, de sa date et de son responsable. Un tableau limité à « AI Act : 2027 » serait trompeur. Il effacerait les exigences déjà applicables et les différences entre systèmes.

Un assistant documentaire peut seulement aider à retrouver une procédure. Il peut aussi contribuer à une décision touchant une personne. Le nom du produit et sa fonction technique ne suffisent pas à déterminer la qualification. Il faut examiner la finalité prévue et les conditions réelles d’utilisation.

Décrivez qui reçoit la sortie, ce qu’il en fait et quelle décision peut en découler. Précisez l’autonomie, la supervision et les personnes affectées. Si l’usage évolue, reprenez l’analyse. Un changement de processus peut compter autant qu’une modification du code.

Les quatre idées reçues sur l’AI Act montrent les erreurs produites par ces généralisations. L’une consiste à croire que tous les usages sont interdits. L’autre consiste à considérer une famille entière d’outils comme systématiquement hors du champ des obligations.

Le calendrier n’est pas le seul élément à lire. La FAQ actuelle sur la littératie explique que l’article 4 modifié demande des mesures soutenant son développement, sans imposer un niveau individuel spécifique. Répéter l’ancienne formulation sans signaler l’évolution peut conduire à présenter un programme de formation comme une obligation uniforme.

Pour chaque sujet, comparez la disposition applicable et les orientations officielles à jour. Séparez ce que le texte exige de ce que votre organisation choisit de faire pour mieux exploiter le système. Une mesure peut être utile même lorsqu’elle n’est pas imposée sous cette forme précise.

L’article sur la littératie IA adaptée aux usages propose une démarche pédagogique dans cette logique. Elle part des personnes et des tâches. Elle ne promet pas qu’une durée de cours ou une feuille de présence suffira à régler toutes les questions de conformité.

Un inventaire utile décrit les systèmes effectivement utilisés, y compris ceux intégrés à des logiciels existants. Notez le propriétaire, les données, les utilisateurs et les fournisseurs. La durée de ce travail dépend de la taille et de la complexité de l’organisation. Il serait imprudent de garantir qu’une demi-journée suffira partout.

Ajoutez une fiche par système avec la finalité, les composants, les droits, les contrôles et les incidents connus. La fiche d’un système d’IA constitue un point de départ documentaire. Elle doit être proportionnée au besoin et reliée aux pièces techniques disponibles.

Ces éléments servent déjà à l’exploitation. Ils permettent de trouver la bonne personne lorsqu’un accès pose problème ou qu’une réponse ne peut pas être justifiée. Leur intérêt ne dépend pas uniquement d’une échéance réglementaire. Ils réduisent aussi les zones d’incertitude dans la maintenance.

Des traces pertinentes aident à comprendre un incident. Il ne faut pas en déduire qu’il faudrait enregistrer toutes les conversations sans limite. Les journaux peuvent contenir des informations personnelles ou confidentielles. Leur contenu, leur accès et leur durée de conservation doivent être définis selon les besoins et les règles applicables.

Commencez par les événements nécessaires au diagnostic : version, outil appelé, décision d’autorisation et catégorie d’erreur. Déterminez quand le contenu complet est réellement nécessaire. Protégez les traces et prévoyez leur suppression selon la politique retenue. Une journalisation incontrôlée peut créer un problème supplémentaire.

Les événements non enregistrés ne peuvent généralement pas être reconstruits à l’identique. Cela justifie une réflexion précoce, pas une collecte maximale. Le choix doit être documenté avec l’équipe technique et les fonctions compétentes. Les contraintes peuvent différer fortement entre un assistant public et un système interne sensible.

Classez les actions selon trois critères : obligation déjà applicable, risque opérationnel et dépendance de mise en œuvre. Une correction de droits d’accès peut être urgente indépendamment du calendrier. Une documentation manquante peut bloquer une qualification. Un changement contractuel peut demander davantage de délai qu’un réglage technique.

Attribuez un responsable et une preuve de clôture à chaque action. « Sensibiliser les équipes » est trop vague si personne ne sait quel résultat attendre. « Faire relire trois scénarios d’erreur par les utilisateurs du pilote et intégrer leurs retours » décrit une action vérifiable.

Le plan doit aussi conserver les incertitudes. Si la qualification d’un usage reste discutée, identifiez la personne chargée de la résoudre et les informations nécessaires. Un audit IA du système peut produire les éléments techniques utiles à cette analyse. Il ne doit pas inventer une certitude juridique à partir d’un simple entretien.

Les échéances doivent être revérifiées au moment d’une décision. Cet article fournit une méthode de lecture et ne qualifie pas une situation individuelle.