AI Act : quatre idées reçues à corriger

L’AI Act ne se résume ni à une interdiction générale, ni à une simple formalité documentaire. Pour déterminer ce qu’une organisation doit faire, il faut qualifier l’usage, son rôle dans la chaîne et la catégorie du système. Une règle correcte appliquée au mauvais périmètre produit une mauvaise décision.

Cette lecture, actualisée le 25 septembre 2026, corrige quatre raccourcis fréquents : tous les usages seraient interdits, tout système demanderait un audit externe, seuls les fournisseurs de modèles seraient concernés et toutes les obligations auraient été reportées. Les réponses dépendent des dispositions applicables et de leurs conditions. Une synthèse ne remplace pas cette qualification.

L’article 5 énumère des pratiques interdites avec leurs conditions et, pour certaines, des exceptions précisément encadrées. Il ne pose pas une interdiction générale des assistants d’entreprise. Il faut toutefois éviter le raccourci inverse : appeler un outil « documentaire » ou « productivité » ne suffit pas à l’exclure de tout risque réglementaire.

Le contexte compte. Un outil qui résume un dossier peut participer à une décision concernant une personne. Il faut examiner sa finalité, ses entrées, la manière dont sa sortie est utilisée et les personnes affectées. La qualification ne découle pas uniquement de la technologie ou du nom commercial.

La bonne première étape consiste à décrire une tâche concrète, puis à vérifier les dispositions pertinentes. La fiche doit conserver le raisonnement et les points encore incertains. Les pratiques interdites et leur qualification constituent un sujet à traiter avant de concevoir des mesures de réduction du risque. Une protection technique ne rend pas licite un usage effectivement interdit.

Il faut distinguer un audit volontaire, une évaluation de conformité et l’intervention éventuelle d’un organisme notifié. Ces termes ne sont pas interchangeables. La procédure applicable dépend notamment de la catégorie du système et, le cas échéant, des règles sectorielles relatives au produit concerné.

Dire qu’un tiers est toujours obligatoire serait inexact. Affirmer qu’il ne l’est presque jamais serait également trop général pour guider un projet. Le travail consiste à identifier la procédure applicable au système précis, avec les dispositions et les normes pertinentes au moment de la décision.

Un audit volontaire peut rester utile même lorsqu’il n’est pas imposé. Il peut éprouver une architecture, un jeu de tests ou une organisation de supervision. Son rapport doit décrire ce qu’il couvre. Il ne faut pas le présenter comme une certification réglementaire s’il ne remplit pas les conditions d’une telle procédure.

Dans un audit IA, je propose de séparer la qualification réglementaire des constats techniques. Une erreur de droits d’accès mérite une correction opérationnelle. La question de savoir quelle obligation juridique elle engage demande une analyse distincte, adaptée au rôle et au système.

Le règlement distingue plusieurs rôles, notamment fournisseur et déployeur. Une entreprise qui intègre un modèle tiers ne devient pas automatiquement un simple déployeur. Développer ou faire développer un système et le mettre en service sous son propre nom peut engager le rôle de fournisseur. Certains changements du système ou de sa destination peuvent aussi modifier les responsabilités.

Il faut distinguer le modèle et le système qui l’utilise. Le premier peut être fourni par un acteur, tandis qu’un autre construit l’application, organise les accès et définit sa finalité. Les obligations de chacun doivent être examinées à leur niveau. Elles peuvent se cumuler au sein d’une même organisation.

Dessinez la chaîne : fournisseur du modèle, intégrateur, organisation qui met le système en service, utilisateurs et sous-traitants éventuels. Pour chaque acteur, notez les décisions qu’il prend réellement. Les contrats apportent des informations importantes, mais les responsabilités ne se déterminent pas uniquement par une étiquette commerciale.

La documentation qui doit descendre la chaîne des modèles à usage général aide à comprendre les dépendances. Elle ne dispense pas l’intégrateur d’examiner ce qu’il ajoute : outils, sources, mémoire, interface et possibilité d’exécuter des actions.

Le calendrier est échelonné. Le règlement modificatif 2026/1744 a notamment déplacé certaines échéances relatives aux systèmes à haut risque. Il n’autorise pas à conclure que tout le règlement serait suspendu. La Commission présente un calendrier par ensembles de dispositions, avec des transitions à vérifier.

La littératie illustre aussi pourquoi il faut lire les modifications de fond, pas seulement les dates. La FAQ actualisée de la Commission décrit une obligation de prendre des mesures soutenant son développement, sans imposer un niveau individuel spécifique. Présenter le sujet comme une formation standard obligatoire pour tous simplifie excessivement la règle actuelle.

Pour chaque obligation, relevez sa date d’application, les conditions qui vous concernent et les éventuelles dispositions transitoires. Le calendrier détaillé est repris dans ce que le report change et ce qui reste applicable. La date d’un projet ne suffit pas, à elle seule, à déterminer toutes les exigences.

Une note utile tient sur quelques pages, mais elle contient les références nécessaires. Décrivez le système, sa finalité, les acteurs et les hypothèses retenues. Associez chaque conclusion à une disposition ou à une source officielle datée. Conservez les incertitudes plutôt que de les masquer derrière un feu vert global.

Ajoutez une date de revue et les événements qui déclencheront une nouvelle analyse : changement de finalité, nouveau public, autonomie accrue ou modification importante d’un composant. Une qualification correcte aujourd’hui peut devenir insuffisante si le système commence à remplir une autre fonction.

Enfin, distinguez ce qui relève d’une obligation, d’une bonne pratique et d’un choix de l’entreprise. Cette séparation rend les arbitrages plus lisibles. Elle permet de discuter des coûts et des risques sans inventer une exigence juridique ni supprimer une protection utile sous prétexte qu’elle n’est pas expressément imposée.

Les exemples et la méthode de qualification proposés ici ne constituent pas une conclusion juridique individualisée.