AI Act applicable depuis le 2 août 2026 : le plan d’action concret pour une entreprise française

Le règlement européen sur l’intelligence artificielle n’est plus un sujet à placer dans une veille lointaine. Depuis le 2 août 2026, l’application du texte franchit une étape majeure : les autorités européennes et nationales entrent dans une phase de mise en œuvre et de contrôle, tandis que plusieurs obligations de transparence deviennent applicables.

Pour une entreprise, la mauvaise réponse consiste à lancer une production massive de politiques génériques. La bonne démarche commence par quatre questions : quels systèmes d’IA sont réellement utilisés, à quelles fins, par quelles personnes et avec quel rôle juridique dans la chaîne de valeur ?

Le calendrier, les lignes directrices et les interprétations peuvent évoluer. Cet article fournit une méthode opérationnelle et ne constitue pas un avis juridique.

Ce qui change concrètement en août 2026

L’AI Act organise les obligations selon les usages, les risques et le rôle de chaque acteur. Une même technologie peut relever d’exigences très différentes selon qu’elle résume des documents internes, sélectionne des candidats, pilote un équipement ou génère une vidéo diffusée au public.

Les règles ont été appliquées progressivement. Les obligations visant certains modèles d’IA à usage général ont commencé à produire leurs effets en 2025. À partir du 2 août 2026, la gouvernance et l’enforcement se renforcent, et les obligations de transparence de l’article 50 s’appliquent notamment à certaines interactions et à certains contenus générés ou manipulés par IA.

Cela ne signifie pas que chaque usage d’IA devient un système à haut risque. Une grande partie des usages reste dans une catégorie de risque limité ou minimal. En revanche, l’entreprise doit être capable d’expliquer pourquoi elle a retenu une qualification et quelles mesures elle applique.

Commencer par un inventaire réel

Le registre ne doit pas se limiter aux projets validés par la DSI. Il doit couvrir :

• les fonctionnalités IA intégrées dans des logiciels existants ;
• les assistants achetés directement par une direction métier ;
• les API utilisées par les équipes de développement ;
• les modèles open weights auto-hébergés ;
• les automatisations no-code ;
• les POC encore connectés à des données réelles ;
• les outils gratuits employés sans contrat ;
• les systèmes développés pour des clients.

Pour chaque entrée, consigner la finalité, le propriétaire, les utilisateurs, la population concernée, les données, le modèle ou fournisseur, les décisions influencées, les outils connectés, les lieux d’hébergement et le statut de déploiement.

Un inventaire incomplet est souvent le premier risque : l’organisation ne peut ni classifier, ni informer, ni surveiller ce qu’elle ne connaît pas.

Identifier son rôle dans la chaîne de valeur

Le règlement distingue plusieurs rôles, notamment fournisseur et déployeur. Selon le contexte, d’autres positions de la chaîne de distribution ou du produit peuvent s’ajouter. Une entreprise qui achète un assistant pour ses salariés sera souvent déployeur. Celle qui intègre un modèle dans un service vendu sous son nom peut assumer des responsabilités supplémentaires. Une personnalisation profonde ou un changement de finalité peut également modifier l’analyse.

Il faut documenter, système par système :

• qui a conçu le système ;
• qui choisit la finalité ;
• qui le met sur le marché ou en service ;
• sous quel nom il est présenté ;
• qui contrôle les données, prompts, outils et seuils ;
• qui reçoit les incidents et demandes des personnes ;
• qui peut suspendre le service.

Cette analyse doit être rapprochée des contrats. Un fournisseur commercial peut décrire une fonctionnalité, mais il ne connaît pas nécessairement l’usage métier exact réalisé par son client.

Classer par usage, pas par nom de fournisseur

La classification ne doit pas reposer sur la marque du modèle ou sur l’étiquette « copilote ». Elle dépend de la finalité et du contexte. Les grandes familles de questions sont les suivantes.

L’usage est-il interdit ou très sensible ?

Certains usages sont prohibés ou fortement encadrés. Tout projet lié à la biométrie, la manipulation, l’exploitation de vulnérabilités, la notation de personnes ou la surveillance doit être examiné immédiatement avec un conseil compétent.

Le système intervient-il dans un domaine potentiellement à haut risque ?

Recrutement, éducation, accès à des services essentiels, infrastructures critiques, justice, sécurité ou certains produits réglementés exigent une analyse approfondie. Le fait d’assister un humain ne suffit pas toujours à écarter le risque si la recommandation influence réellement la décision.

Une obligation de transparence s’applique-t-elle ?

Il faut notamment vérifier si une personne interagit directement avec un système d’IA, si un contenu synthétique doit être marqué de façon lisible par machine, ou si un deepfake ou certains textes portant sur une question d’intérêt public doivent être signalés.

Un modèle à usage général est-il fourni ou seulement consommé ?

Les responsabilités du fournisseur du modèle et de l’intégrateur ne sont pas identiques. L’entreprise doit obtenir la documentation disponible et définir ce qu’elle doit compléter pour son propre système.

Traiter les obligations de transparence comme un parcours utilisateur

Une mention cachée dans des conditions générales ne constitue pas une expérience de transparence satisfaisante. L’information doit être placée au moment pertinent, comprise par le public et cohérente avec l’usage.

Pour un assistant conversationnel, préciser clairement qu’il s’agit d’un système automatisé, ses limites, la manière de joindre un humain et la façon dont les données sont traitées. Pour un contenu généré ou manipulé, distinguer le marquage technique destiné à la détection de la mention visible destinée au public.

Toutes les productions assistées par IA ne nécessitent pas la même étiquette. Les exceptions et conditions prévues par le texte doivent être vérifiées. L’organisation doit néanmoins conserver une politique éditoriale : niveau de revue humaine, responsabilité assumée, conservation des sources et traçabilité des transformations importantes.

Constituer des preuves plutôt qu’une documentation décorative

Un dossier crédible relie chaque exigence à une preuve vivante :

• fiche du système et versions ;
• finalité et limites approuvées ;
• analyse des risques et impacts ;
• origine et gouvernance des données ;
• protocole d’évaluation ;
• résultats, seuils et incidents ;
• notice utilisateur ;
• mécanismes de supervision humaine ;
• logs et politique de conservation ;
• sécurité, accès et continuité ;
• contrats et responsabilités ;
• historique des changements.

La documentation doit refléter le système déployé. Une évaluation réalisée sur une version ancienne ou un jeu de données sans rapport avec la production ne protège pas l’entreprise.

Organiser la supervision humaine

La présence d’un bouton « valider » ne suffit pas. Le contrôleur humain doit disposer du temps, des compétences, des informations et de l’autorité nécessaires pour contester la sortie.

Définir :

• les décisions que le système peut seulement préparer ;
• celles qui exigent une validation ;
• les critères de refus ;
• le niveau d’explication fourni ;
• la procédure de recours ;
• les conditions d’arrêt ;
• les tests de dépendance excessive à l’automatisation.

Plus l’impact sur les personnes est fort, plus la supervision doit être concrète et testée.

Revoir les contrats et la chaîne de sous-traitance

Les clauses doivent permettre d’obtenir les informations nécessaires : versions, localisation, sous-traitants, sécurité, incidents, droits sur les contenus, utilisation des données, conservation, réversibilité et notification des changements majeurs.

Vérifier également la capacité à :

• exporter les données et configurations ;
• désactiver une fonctionnalité ;
• imposer une région d’hébergement ;
• maîtriser l’entraînement sur les données ;
• auditer ou recevoir des rapports ;
• obtenir de l’aide lors d’un incident ;
• changer de modèle sans reconstruire le produit.

Un contrat standard d’outil bureautique peut être insuffisant pour un processus critique.

Construire un programme proportionné

Toutes les entrées du registre ne nécessitent pas le même effort. Prioriser selon l’impact sur les droits, le nombre de personnes, l’autonomie, la sensibilité des données, la maturité du fournisseur et l’absence de recours.

Une gouvernance efficace distingue :

1. les usages interdits ou à suspendre ;
2. les systèmes à qualifier immédiatement ;
3. les usages à transparence renforcée ;
4. les outils internes à encadrer ;
5. les expérimentations sans données réelles ;
6. les systèmes faibles risques à surveiller simplement.

La conformité devient alors un portefeuille de risques, pas un questionnaire identique pour tous.

Une feuille de route en 90 jours

Jours 0 à 30 : visibilité et mesures immédiates

• nommer un sponsor et un responsable opérationnel ;
• lancer l’inventaire ;
• repérer les usages sensibles ou non autorisés ;
• suspendre les flux manifestement dangereux ;
• identifier les obligations de transparence immédiates ;
• centraliser contrats et notices ;
• définir un canal de signalement.

Jours 31 à 60 : qualification et preuves

• analyser les rôles ;
• classer les cas prioritaires ;
• cartographier données et sous-traitants ;
• compléter les analyses RGPD et sécurité ;
• définir les évaluations et seuils ;
• corriger les parcours d’information ;
• formaliser la supervision humaine.

Jours 61 à 90 : industrialisation

• adopter une politique IA ;
• mettre en place le registre permanent ;
• intégrer les contrôles au cycle projet ;
• former les équipes selon leur rôle ;
• négocier les clauses manquantes ;
• organiser la surveillance et les revues ;
• préparer la gestion d’incident et la réversibilité.

Les erreurs à éviter

Attendre une liste parfaite

L’inventaire doit commencer même s’il est incomplet. Les entrées « fournisseur inconnu » ou « données à confirmer » permettent de piloter l’incertitude.

Confondre conformité fournisseur et conformité de l’usage

Une certification ou une déclaration du fournisseur ne couvre pas automatiquement la finalité, les données et le parcours mis en œuvre par le client.

Tout classer à haut risque

Cette stratégie surcharge la gouvernance et finit par banaliser les vrais risques. La proportionnalité doit être argumentée.

Traiter le sujet uniquement par le juridique

Les preuves se trouvent dans le produit : code, configuration, données, tests, logs, interfaces et procédures. Juristes, DPO, sécurité, métier et technique doivent travailler ensemble.

Transformer l’obligation en discipline produit

L’AI Act impose une meilleure connaissance des systèmes, mais cette discipline apporte aussi des bénéfices opérationnels : moins d’outils invisibles, des responsabilités claires, des tests reproductibles, des incidents mieux gérés et une architecture plus réversible.

Partitech peut intervenir sur l’inventaire technique, les cartographies de flux, les évaluations, la traçabilité, les contrôles humains et l’intégration des exigences dans le cycle de livraison. La qualification juridique finale reste conduite avec les conseils compétents de l’entreprise. L’objectif est de relier le règlement à un système réel, mesurable et maintenable.

Parlons de votre projet

Structurer un diagnostic AI Act et une feuille de route de conformité avec Partitech et vos conseils juridiques. Contactez Partitech.