Du cadre réglementaire au projet

AI Act et IA en entreprise : quelles obligations pour votre projet ?

Les obligations dépendent de votre rôle, de la destination du système et de son calendrier d’application. Commencez par ces trois questions avant d’établir une liste de fonctions ou de documents à produire.

Par Jonathan Fidi · CTO et architecte logiciel · Publié et vérifié le

Ce guide aide à préparer un projet technique. Il ne constitue pas un avis juridique ni une attestation de conformité. Les sources officielles sont liées à chaque section ; la qualification de votre usage doit être validée selon votre situation.

1. Fournisseur ou déployeur : identifier votre rôle

Le fournisseur développe, ou fait développer, un système d’IA qu’il commercialise ou met en service sous son nom ou sa marque. Le déployeur utilise un système sous son autorité dans un cadre professionnel. Une entreprise qui fait construire son propre assistant peut donc avoir un rôle de fournisseur, même si un prestataire écrit le code et si le modèle vient d’un tiers.

Le modèle et l’application qui l’intègre sont deux niveaux distincts. Utiliser une API ne transfère pas automatiquement toutes vos responsabilités au fournisseur du modèle. Une même organisation peut cumuler plusieurs rôles. Pour un projet sur mesure, clarifiez qui met le système en service, sous quel nom, et pour quelle utilisation.

À préparer pour le cadrage : un schéma des intervenants, la destination du système et la répartition des tâches. Cette proposition de travail facilite l’analyse juridique ; les intitulés du contrat ne suffisent pas à déterminer les rôles réglementaires.

Article 3 — définitions des acteurs et de la destination du système

2. Classer l’usage, pas seulement la technologie

Les règles de qualification du haut risque figurent à l’article 6 et renvoient notamment aux annexes I et III. Un système peut relever du haut risque en raison de son rôle dans un produit réglementé ou de sa destination dans un domaine sensible. Le fait d’utiliser un grand modèle de langage ou du RAG ne suffit pas à déterminer cette qualification.

Certaines exceptions existent pour des systèmes de l’annexe III, sous conditions. Elles ne permettent pas d’exclure mécaniquement un outil au motif qu’un humain intervient à la fin. Le profilage de personnes dans le cadre des systèmes de cette annexe bénéficie d’un traitement particulier : ces systèmes restent considérés à haut risque.

Notre recommandation de cadrage : décrivez ce que la réponse de l’IA change réellement. Aide-t-elle à retrouver une notice ou influence-t-elle l’accès à un emploi ? Documentez cette différence avant de sélectionner une architecture. Les exemples ci-dessous orientent l’analyse et ne constituent pas une qualification juridique individuelle.

Article 6 — critères de classification à haut risque

3. Chatbots et contenus générés : les règles de transparence

L’article 50 impose au fournisseur d’un système destiné à interagir directement avec des personnes de prévoir leur information sur cette interaction avec une IA, sauf lorsque cela est évident dans le contexte et sous réserve des exceptions prévues. L’information concernée doit être claire, accessible et fournie au plus tard lors de la première interaction.

Le même article prévoit, pour les fournisseurs concernés, un marquage des contenus synthétiques lisible par machine. Il prévoit aussi des obligations de divulgation pour certains usages par les déployeurs, notamment les hypertrucages et certains textes publiés pour informer le public sur des sujets d’intérêt public. Des exceptions s’appliquent, notamment sous conditions de contrôle éditorial pour ces textes. Ce n’est pas une obligation générale d’ajouter une étiquette à chaque texte rédigé avec une IA.

Suggestion de conception pour un assistant client : afficher dès l’ouverture une mention compréhensible indiquant qu’il s’agit d’un assistant IA. Cette mesure ne remplace pas l’examen des autres obligations applicables à votre système et à ses sorties.

Article 50 — transparence, acteurs concernés et exceptions

4. Accompagner les équipes dans l’utilisation de l’IA

Dans sa version consolidée au 27 juillet 2026, l’article 4 demande aux fournisseurs et déployeurs de prendre des mesures pour soutenir le développement de la maîtrise de l’IA de leurs équipes et des personnes intervenant pour leur compte. Il faut tenir compte de leurs connaissances, de leur expérience et du contexte d’utilisation. Le texte précise qu’il ne s’agit pas de garantir un niveau individuel déterminé.

En pratique, je recommande une prise en main liée aux tâches réelles : reconnaître une réponse sans source, savoir quelles données saisir, comprendre quand vérifier un résultat et à qui signaler un problème. Pour un assistant documentaire, un exercice peut consister à poser une question absente du corpus et à examiner la réponse.

Gardez une trace des supports, des participants et des mises à jour. Cette organisation est une proposition de mise en œuvre, pas une certification ni un programme de formation unique imposé à toutes les entreprises par l’AI Act.

Article 4 consolidé — maîtrise de l’IA

5. Pour le haut risque, préparer des responsabilités supplémentaires

Lorsque le régime du haut risque s’applique à votre système et à votre échéance, les obligations du déployeur comprennent notamment l’usage selon les instructions, une supervision confiée à des personnes compétentes et disposant de l’autorité nécessaire, le suivi du fonctionnement et le traitement des risques ou incidents. L’article 26 prévoit aussi la conservation des journaux sous son contrôle, avec une durée minimale de six mois sauf disposition applicable différente.

Ces exigences ne doivent pas être présentées comme des obligations identiques pour tous les assistants IA. Les obligations du fournisseur sont distinctes et peuvent comprendre une documentation technique et une procédure d’évaluation de conformité. Une validation humaine symbolique ne constitue pas, à elle seule, un dispositif de supervision opérationnel.

Pour préparer le projet, précisez qui peut interrompre l’usage, qui examine une erreur et comment une correction est déployée. Faites valider le périmètre juridique par un conseil compétent ; l’équipe technique pourra ensuite traduire les exigences retenues en fonctions et en critères de recette.

Article 26 — obligations des déployeurs de systèmes à haut risque

Trois cas pour orienter l’analyse

Scénarios illustratifs : ils ne décrivent ni des clients ni des évaluations de conformité réalisées.

Assistant documentaire interne
Retrouver une procédure ne suffit pas à caractériser un haut risque. Examiner la destination précise, les utilisateurs et les décisions influencées.
Chatbot de service client
Examiner la transparence de l’interaction. Une simple interface conversationnelle ne détermine pas à elle seule le niveau de risque.
Outil de tri de candidatures
Le recrutement est un domaine sensible visé par l’annexe III. Faire qualifier l’usage et les éventuelles exceptions avant le déploiement.

Commission européenne — approche par les risques et exemples d’usages

Le calendrier vérifié au 7 octobre 2026

Les reports concernant le haut risque ne suspendent pas les règles déjà applicables. Ces repères ne couvrent pas toutes les situations transitoires, notamment les systèmes et modèles déjà mis sur le marché.

2 février 2025
Application initiale des interdictions de l’article 5 et des dispositions sur la maîtrise de l’IA.
2 août 2025
Application des règles de gouvernance et des obligations relatives aux modèles d’IA à usage général, avec des dispositions transitoires.
27 juillet 2026
Entrée en vigueur de l’AI Omnibus, qui modifie notamment le calendrier du haut risque.
2 août 2026
Application générale de l’AI Act, notamment des obligations de transparence, sous réserve des exceptions et transitions.
2 décembre 2027
Échéance des règles pour les systèmes à haut risque relevant des domaines de l’annexe III.
2 août 2028
Échéance des règles pour les systèmes à haut risque intégrés aux produits réglementés concernés par l’annexe I.

Calendrier de la Commission européenne · Entrée en vigueur de l’AI Omnibus

Ce que je recommande de préparer avant de développer

Cette liste est une méthode de cadrage technique proposée, pas un dossier réglementaire universel.

  1. Une fiche d’usage. Décrire les utilisateurs, les données, les réponses attendues, les décisions influencées et les usages exclus.
  2. Une répartition des rôles. Identifier l’entreprise utilisatrice, l’intégrateur, le fournisseur du système et celui du modèle, puis faire valider leur qualification.
  3. Une matrice des exigences. Pour chaque obligation retenue : source juridique, acteur responsable, date applicable et preuve attendue. Séparer les recommandations facultatives.
  4. Des essais et un responsable d’exploitation. Définir les critères de recette, la gestion des erreurs, les accès et les conditions d’arrêt ou de reprise du système.
  5. Une revue lors des changements. Réexaminer le périmètre si le système reçoit de nouvelles données, sert de nouveaux utilisateurs ou intervient dans une autre décision.

La confidentialité reste un chantier distinct de la qualification AI Act. Notre guide sur les documents confidentiels détaille les accès, les transmissions et la suppression des copies à prévoir dans un assistant documentaire.

Traduire les exigences de votre projet en architecture

Une fois le périmètre et les exigences applicables clarifiés avec vos interlocuteurs juridiques, je peux vous aider à cadrer les flux de données, les permissions, les tests et l’exploitation. Notre exemple d’assistant documentaire donne un premier aperçu d’un projet possible.

Discuter de votre projet IA