AI Act : un plan concret pour votre conformité.

L’AI Act, aussi appelé règlement IA, ne vise pas seulement les éditeurs de grands modèles. Il concerne notamment les organisations qui mettent un système d’IA sur le marché de l’Union, le mettent en service ou l’utilisent dans l’Union lorsque les résultats sont utilisés dans l’Union. Une entreprise qui achète un logiciel n’endosse donc pas automatiquement le rôle de son fabricant. En revanche, elle doit pouvoir expliquer ce qu’elle déploie, dans quel but et avec quelles limites.

Le premier travail consiste à nommer le rôle de chacun. Le fournisseur développe le système, ou le fait développer, puis le commercialise ou le met en service sous son nom. Le déployeur l’utilise dans son activité. Un importateur introduit dans l’Union un système provenant d’un pays tiers ; un distributeur le rend disponible dans la chaîne de fourniture. Une entreprise peut cumuler ces rôles selon les produits et les projets. Si elle place son nom sur une solution conçue par un prestataire, modifie substantiellement un système ou change sa finalité, la qualification doit être examinée avec soin.

• Recensez les assistants acquis par les équipes, les automatisations et les outils en cours d’essai.
• Pour chaque cas, notez l’éditeur, le propriétaire métier, les données lues, les personnes concernées et l’action produite.
• Identifiez ce qui est simplement suggéré, ce qui est validé par un humain et ce qui déclenche une action.
• Gardez le contrat, les instructions d’utilisation et la version du service effectivement utilisée.

Ce registre évite de confondre un assistant qui prépare une note avec un outil qui sélectionne des candidatures ou calcule une priorité. Il donne aussi un point d’entrée aux équipes achats, sécurité, données et métier. Un audit IA permet de consolider cet état des lieux lorsqu’aucune vue transversale n’existe. Pour décider qui arbitre les usages et les exceptions, le conseil IA peut ensuite formaliser une gouvernance adaptée à votre organisation.

La conformité AI Act ne se déduit ni de la marque d’un modèle ni de l’étiquette « IA générative ». Elle dépend de la finalité effective du système et de son contexte d’emploi. Le même composant peut aider à résumer une réunion, classer des demandes internes ou contribuer à une décision qui affecte une personne. Ces trois usages n’appellent ni la même analyse ni les mêmes garde-fous.

Commencez par rechercher les pratiques interdites. L’article 5 prohibe des usages précis, notamment certaines techniques de manipulation ou d’exploitation des vulnérabilités, la notation sociale et certaines pratiques biométriques. Depuis la modification entrée en vigueur en 2026, l’interdiction vise aussi, à compter du 2 décembre 2026, les systèmes générant ou manipulant des contenus intimes non consentis ou des contenus d’abus sexuels sur mineurs. Une équipe ne doit pas chercher à compenser un usage interdit par une validation humaine : elle doit l’écarter.

Vérifiez ensuite si le système appartient à la catégorie du haut risque. L’annexe III couvre notamment certains usages liés à la biométrie, aux infrastructures critiques, à l’éducation, à l’emploi, à l’accès à des services essentiels et au contrôle des frontières. L’annexe I vise des systèmes de sécurité intégrés à certains produits réglementés. Les obligations ne reposent pas sur une intuition : reliez le processus réel, les sorties du système et la disposition concernée. Une analyse juridique est indiquée lorsqu’un usage participe à une décision d’embauche, d’accès à un service ou de sécurité.

• Décrivez la décision influencée, plutôt que de décrire seulement la fonction technique.
• Indiquez les personnes touchées, leur possibilité de comprendre le résultat et de le contester.
• Testez les erreurs plausibles : mauvaise donnée d’entrée, absence de source, homonymie ou instruction ambiguë.
• Prévoyez un arrêt du flux et une reprise manuelle avant la mise en production.

Enfin, même lorsqu’un usage n’est ni interdit ni à haut risque, des règles de transparence, de protection des données et de sécurité peuvent s’appliquer. Un agent IA qui consulte une base interne doit être limité aux droits nécessaires. La page sécurité et souveraineté détaille les choix d’hébergement, de journalisation et de contrôle à instruire avec vos équipes.

Dans une conformité AI Act solide, les obligations ne sont pas reprises mécaniquement d’une checklist trouvée en ligne. Elles sont réparties entre les acteurs qui peuvent réellement agir. Pour un système à haut risque, le fournisseur porte notamment un système de gestion des risques, une gouvernance des données, une documentation technique, des capacités de journalisation, des informations destinées au déployeur, une supervision humaine, ainsi que des exigences d’exactitude, de robustesse et de cybersécurité. Il réalise l’évaluation de conformité appropriée avant la mise sur le marché ou la mise en service.

Le déployeur n’est pas un simple utilisateur passif. Il doit employer le système conformément aux instructions, confier la supervision à des personnes compétentes et, lorsqu’il contrôle les données d’entrée, veiller à leur pertinence pour la finalité. Pour les systèmes à haut risque, il lui revient aussi de suivre le fonctionnement, de conserver les journaux lorsqu’il y est tenu, de remonter certains incidents graves et de réaliser, dans les cas prévus, une analyse d’impact sur les droits fondamentaux avant le déploiement. Le contrat ne transfère pas à lui seul une obligation qui découle du rôle tenu.

• Un propriétaire métier accepte les cas d’usage, les seuils de revue et les situations qui exigent une escalade.
• Un responsable technique connaît le modèle, les connecteurs, les versions et la procédure de retour arrière.
• Un référent données ou juridique relit les finalités, les informations aux personnes et les clauses de sous-traitance.
• Les utilisateurs savent quand ne pas suivre une sortie et comment signaler une anomalie.

Un projet sur mesure doit séparer ce que fournit le socle technique, ce que votre organisation configure et ce qu’elle exploite au quotidien. Demandez par exemple la documentation du fournisseur, les limites connues, la politique de mise à jour, les conditions d’assistance lors d’un incident et le format d’export des journaux. Ces questions ont leur place dès le cadrage d’une intégration IA. Elles complètent les mesures prévues pour une revue de vos usages IA, sans se substituer à un avis juridique pour les situations sensibles.

L’AI Act européen est entré en vigueur le 1er août 2024. Son application est échelonnée. Les interdictions de l’article 5 et l’obligation de prendre des mesures pour assurer un niveau suffisant de culture IA des personnes qui exploitent ou utilisent les systèmes sont applicables depuis le 2 février 2025. Les règles de gouvernance et les obligations des fournisseurs de modèles d’IA à usage général s’appliquent depuis le 2 août 2025.

Depuis le 2 août 2026, le règlement est généralement applicable, notamment ses exigences de transparence pour certains systèmes. En pratique, un chatbot doit informer la personne qu’elle interagit avec une IA lorsque l’absence d’évidence le justifie. Les contenus générés ou manipulés peuvent aussi exiger un marquage ou une information selon le cas. Pour les fournisseurs de systèmes placés sur le marché avant cette date, l’échéance de conformité à certaines obligations de marquage et de détection prévues à l’article 50, paragraphe 2, est le 2 décembre 2026.

Le « Digital Omnibus » sur l’IA n’est plus une simple proposition : le texte est entré en vigueur le 27 juillet 2026. Il a reporté les règles de haut risque. Les systèmes autonomes classés à haut risque au titre de l’annexe III relèvent du 2 décembre 2027. Les systèmes à haut risque intégrés à des produits réglementés de l’annexe I relèvent du 2 août 2028. Il faut donc distinguer ces dates adoptées des documents d’orientation ou normes encore en préparation.

• Maintenant : éliminez les pratiques interdites, formez les personnes concernées et qualifiez les usages.
• Avant décembre 2026 : vérifiez les marquages applicables aux systèmes concernés déjà placés sur le marché.
• Avant décembre 2027 : préparez les preuves, contrôles et processus des cas relevant de l’annexe III.
• Avant août 2028 : coordonnez les exigences avec la réglementation du produit lorsque l’IA en est un composant de sécurité.

Attendre le dernier trimestre est rarement rationnel : les documents, tests et responsabilités se construisent plus facilement pendant un projet pilote. Une démarche d’agent IA supervisé permet de limiter les actions initiales. La sécurité et souveraineté doit être revue en même temps, car une preuve de conformité perd de sa valeur si les accès et les traces ne sont pas maîtrisés.

Un modèle d’IA à usage général peut servir de base à de nombreuses applications : assistant rédactionnel, moteur de recherche documentaire, agent relié à un CRM ou fonction de résumé. Les obligations propres au modèle pèsent d’abord sur son fournisseur. L’entreprise qui construit ou déploie une application sur ce modèle reste toutefois responsable de la finalité de son système, de ses utilisateurs, de ses données et de l’interface dans laquelle il est proposé.

La transparence est une décision de conception. Si un visiteur échange avec un assistant, l’information doit apparaître là où l’échange commence, pas dans une condition générale inaccessible. Si un contenu synthétique est diffusé, le projet doit déterminer si un marquage lisible par machine, une mention visible ou les deux sont requis dans le cas considéré. Gardez aussi la possibilité de savoir quel modèle, quelle version, quelle instruction et quelle source ont conduit à une réponse litigieuse.

• Affichez le rôle de l’assistant, ce qu’il peut faire et le moyen de joindre une personne lorsque cela est nécessaire.
• Évitez de présenter une réponse probabiliste comme une décision certaine ou comme un avis professionnel.
• Versionnez les instructions système, les règles métier et les jeux de tests avant chaque changement important.
• Restreignez les outils qu’un agent peut appeler ; une action externe doit être explicite, autorisée et réversible lorsque c’est possible.

La documentation du fournisseur de modèle est utile, mais elle ne remplace pas vos propres essais. Testez des documents incomplets, des demandes hors périmètre, des droits insuffisants et des tentatives de contourner les consignes. Une automatisation IA peut commencer par produire une proposition, puis passer à une action seulement après observation des exceptions. Lorsque le système consulte une base interne ou exécute des opérations, les pratiques d’un agent IA encadré — sources citées, permissions minimales et validation humaine — réduisent le risque d’une autonomie mal calibrée.

Le meilleur registre n’est pas celui qui contient le plus de colonnes : c’est celui qui permet de retrouver pourquoi une décision a été prise. Pour chaque système, rassemblez la finalité approuvée, le rôle de votre organisation, le niveau de risque envisagé, les données et fournisseurs impliqués, les personnes responsables, les limites d’usage et la date de revue suivante. Associez chaque règle à une preuve concrète : procès-verbal de test, capture de l’interface, procédure d’incident, contrat ou journal d’exécution.

La journalisation doit servir l’enquête et l’amélioration sans devenir une collecte indifférenciée. Définissez les événements utiles : appel à une source, action proposée, validation, refus, changement de modèle, erreur d’accès ou escalade vers une personne. Fixez qui peut consulter les traces, combien de temps elles sont conservées et comment elles sont protégées. Les journaux peuvent contenir des données personnelles ; leur gestion doit donc être cohérente avec vos règles RGPD et vos obligations contractuelles.

• Conservez les critères d’acceptation qui ont autorisé la mise en production après le pilote.
• Documentez les limites connues, même lorsqu’elles ne sont pas encore corrigées, afin que les utilisateurs sachent les reconnaître.
• Préparez un canal de signalement, une procédure de triage et une décision claire sur l’arrêt du système.
• Réexaminez la qualification après un changement de finalité, de données, de modèle ou de niveau d’autonomie.

Nous déconseillons d’automatiser une décision difficile à expliquer, à contrôler ou à interrompre. Commencez alors par une aide à la préparation, avec un échantillon relu par le métier. Un logiciel sur mesure peut intégrer dès le départ les écrans de validation, les rôles et la piste d’audit nécessaires. Les exigences d’accès, de chiffrement et de localisation des données se travaillent avec la page sécurité et souveraineté, avant d’ouvrir les connecteurs de production.

La conformité n’est pas une étape finale confiée à une seule équipe. Elle accompagne le cycle de vie : idée, cadrage, prototype, mise en service, surveillance puis retrait. À chaque étape, une question simple évite les angles morts : qu’est-ce qui a changé et qui doit l’approuver ? Une nouvelle source de données, une permission d’écriture ou une mise à jour de modèle peut modifier l’analyse initiale.

Au cadrage, décrivez le processus existant et le résultat acceptable. Pendant le prototype, confrontez le système à des exemples réels mais représentatifs, y compris les exceptions. Avant la mise en service, vérifiez les accès, l’information des utilisateurs, la procédure de reprise manuelle et le propriétaire de chaque alerte. En production, observez les erreurs, les refus, les coûts d’usage et les demandes qui sortent du périmètre. Ces éléments permettent de décider d’élargir, corriger ou arrêter.

• Diagnostic : inventorier le flux, les personnes, les données et les risques avant de choisir une solution.
• Prototype : fixer un critère de validation mesurable, un périmètre d’essai et les validations attendues.
• Développement : connecter progressivement, tester les droits et ouvrir d’abord les cas les plus maîtrisés.
• Suivi : relire les incidents, les journaux et les décisions pour maintenir le dispositif utile.

Un comité court, réuni lorsqu’un changement important est proposé, vaut mieux qu’une validation théorique annuelle. Il réunit le métier qui porte l’usage, la personne qui peut modifier le système et les fonctions compétentes sur les données ou le droit. Si vos équipes partent de demandes dispersées, un cadrage de stratégie IA aide à ordonner les priorités. Si le besoin est déjà clair, l’audit IA sert à vérifier les dépendances, les contrôles et les documents avant de construire.