.png)
Découvrir l'article
Le 2 août 2026, l’essentiel de l’AI Act devient opposable. Les systèmes d’IA classés à haut risque au sens de l’Annexe III (recrutement, scoring crédit, éducation, biométrie, infrastructures critiques) devront répondre à une liste d’obligations proche, dans son esprit, de ce que le RGPD a imposé aux traitements de données personnelles. En France, un amendement de février 2026 à la loi Informatique et Libertés a désigné la CNIL comme autorité nationale de supervision, aux côtés de la DGCCRF et de l’Arcom sur certains volets.
Échéance clé: le 2 août 2026, les obligations applicables aux systèmes d’IA à haut risque deviennent opposables dans toute l’Union européenne.
7 % du chiffre d’affaires mondial: c’est le montant maximal des sanctions pour l’utilisation d’une IA interdite.
La conformité est avant tout technique: cartographie des systèmes, gestion des risques, logs, supervision humaine et documentation sont les piliers d’une mise en conformité réussie.
La plupart des contenus disponibles sur le sujet sont juridiques — denses, exhaustifs, peu actionnables pour un DSI qui doit préparer sa direction en quinze jours. Cet article vise l’inverse : un guide opérationnel. Qu’est-ce qui s’applique, quand, à qui, et quoi faire concrètement.
Trois idées à retenir d’emblée. Un, la plupart des entreprises ne sont pas fournisseurs de systèmes d’IA — elles sont déployeurs, et les obligations sont différentes. Deux, le calendrier est progressif : certaines obligations sont déjà en vigueur depuis février 2025. Trois, la conformité ne se joue pas dans un document juridique ; elle se joue dans l’architecture des systèmes — gestion des risques, documentation, logs, supervision humaine. C’est là que le sujet devient technique.
L’AI Act est entré en vigueur le 1er août 2024. Son application s’étale jusqu’en août 2027, avec quatre jalons majeurs. Voici le calendrier officiel tel qu’il s’applique concrètement.
Deux échéances sont souvent sous-estimées. L’obligation d’AI literacy, applicable depuis février 2025, impose à toute entreprise utilisant des systèmes d’IA de former son personnel. La supervision et les sanctions associées entrent en vigueur en août 2026 — autrement dit, l’audit est pour bientôt. Et les obligations GPAI, en vigueur depuis août 2025, concernent les fournisseurs de modèles de fondation : documentation technique, résumé des données d’entraînement, respect du copyright. Elles affectent indirectement tout déployeur qui s’appuie sur un GPAI.
L’AI Act classe les systèmes d’IA en quatre catégories. La classification détermine le régime applicable.
La classification haut risque repose sur l’article 6. Un système est à haut risque soit parce qu’il est un composant de sécurité d’un produit déjà régulé (dispositifs médicaux, jouets, véhicules — Annexe I), soit parce qu’il figure dans l’un des huit domaines de l’Annexe III.
Point important : l’article 6(3) prévoit une exception. Un système listé à l’Annexe III peut ne pas être considéré comme haut risque s’il ne pose pas de risque significatif aux droits fondamentaux — par exemple s’il se contente d’une tâche procédurale limitée ou s’il ne fait qu’améliorer un résultat humain préexistant. Cette exception doit être documentée. C’est un arbitrage à faire produit par produit, pas un blanc-seing.
Pour les cas-limites, la Commission européenne a publié en février 2026 des lignes directrices avec des exemples pratiques. À lire si vous hésitez sur un cas d’usage.
C’est la question la plus mal traitée dans les contenus disponibles. Les obligations varient radicalement selon le rôle. Une entreprise peut cumuler plusieurs rôles pour différents systèmes.
Fournisseur (provider, article 16) — vous développez un système d’IA et le mettez sur le marché sous votre nom ou marque. Même si vous sous-traitez le développement, vous êtes fournisseur si vous en assumez la mise sur le marché. Les obligations fournisseur sont les plus lourdes : système de gestion des risques, documentation technique (Annexe IV), gouvernance des données, logs automatiques, supervision humaine, robustesse, cybersécurité, marquage CE, enregistrement dans la base de données européenne, évaluation d’impact sur les droits fondamentaux (FRIA) quand applicable.
Déployeur (deployer, article 26) — vous utilisez un système d’IA dans un cadre professionnel. C’est le rôle de la grande majorité des entreprises françaises. Les obligations déployeur sont plus légères mais bien réelles : utilisation conforme aux instructions du fournisseur, supervision humaine par des personnes compétentes, vérification de la pertinence des données d’entrée, monitoring et notification d’incidents, conservation des logs pendant au moins six mois, information des salariés affectés, DPIA et FRIA quand les droits fondamentaux sont en jeu.
Importateur / distributeur — vous mettez sur le marché européen un système développé hors UE, ou vous le distribuez. Obligations de vérification : marquage CE, documentation technique, identification du fournisseur, apposition de vos coordonnées.
Trois pièges classiques. Premier piège : un déployeur peut devenir fournisseur s’il modifie substantiellement un système haut risque ou s’il l’utilise sous sa propre marque. Fine-tuner un LLM sur vos données internes et l’intégrer à un produit commercial peut suffire à faire basculer le statut. Deuxième piège : même sans obligation de marquage CE côté déployeur, vous restez responsable de l’usage effectif — supervision humaine, logs, information des personnes concernées. Troisième piège : si le système d’IA traite des données personnelles, le RGPD s’ajoute à l’AI Act. Les deux régimes coexistent.
En France, la répartition des compétences s’est clarifiée début 2026. La CNIL joue le rôle pivot — supervision nationale, avec une primauté sur les systèmes traitant des données personnelles (ce qui en pratique couvre la majorité des systèmes haut risque).
Cette organisation “en puzzle” ressemble à celle qui prévaut pour le RGPD (CNIL + autorités sectorielles). Dans la pratique, attendez-vous à ce que la CNIL soit votre interlocuteur unique dans 80 % des cas.
Article 99 de l’AI Act : trois niveaux, avec un calcul en pourcentage du CA mondial pour maximiser la dissuasion sur les grands groupes.
Pour comparaison, le plafond RGPD est de 4% du CA mondial. L’AI Act va donc plus loin sur les infractions les plus graves. Les PME bénéficient d’un régime adapté : les sanctions doivent être proportionnées à leur taille.
Voici la séquence que nous recommandons à nos clients, calibrée pour être exécutable d’ici le 2 août 2026 si vous commencez maintenant. Elle s’inspire du guide en 6 étapes publié par Orrick, adapté au contexte français.
Étape 1 — Cartographier vos systèmes d’IA (2 à 4 semaines). Inventaire exhaustif : chaque système d’IA utilisé, développé ou intégré. Pour chacun : nom, fournisseur, cas d’usage, données traitées, personnes affectées. C’est l’étape la plus négligée. Sans cartographie, tout le reste est bancal. Incluez les outils “shadow AI” adoptés par les métiers.
Étape 2 — Classifier chaque système. Pour chaque entrée de la cartographie : niveau de risque (inacceptable, haut, limité, minimal) et rôle (fournisseur, déployeur, importateur). Pour les systèmes potentiellement haut risque, documentez l’analyse Annexe III + exception article 6(3). Cette analyse doit être écrite, datée, signée.
Étape 3 — Mettre en place la gouvernance. Nommer un responsable AI Act (souvent le DPO élargi, parfois un rôle dédié pour les structures avec beaucoup de systèmes haut risque). Créer un comité IA transverse (DSI, DPO, juridique, métiers concernés). Définir le processus de validation avant tout déploiement d’un nouveau système.
Étape 4 — Documentation technique et logs. Pour les systèmes haut risque : dossier technique conforme à l’Annexe IV si vous êtes fournisseur, ou archivage des documents reçus du fournisseur si vous êtes déployeur. Activer et conserver les logs automatiques — minimum six mois côté déployeur. C’est un sujet d’architecture logicielle autant que de conformité.
Étape 5 — AI literacy et information. Programme de formation adapté au niveau technique des équipes et au type de systèmes utilisés. Couverture minimale : compréhension générale de l’IA, spécificités des systèmes déployés, risques (biais, fuite de données), cadre AI Act. Trace écrite des formations — c’est votre preuve en cas d’audit. Informer les salariés affectés par des systèmes haut risque (recrutement, évaluation, monitoring).
Étape 6 — Monitoring et incidents. Procédure de supervision humaine opérationnelle (pas juste sur le papier). Process de détection et notification des incidents graves. Tests réguliers (red teaming, évaluation biais, tests de robustesse). Pour les systèmes impactant des droits fondamentaux, FRIA documentée avant mise en production.
Si vous utilisez Claude, GPT-5, Gemini, Mistral Large, Llama 3 — vous êtes utilisateur final d’un GPAI, pas fournisseur. Le fournisseur du modèle (Anthropic, OpenAI, Google, Mistral, Meta) porte les obligations GPAI : documentation technique, résumé des données d’entraînement, respect du copyright, notification à l’AI Office si risque systémique.
Le seuil de risque systémique est fixé à 10^25 FLOPs d’entraînement. Au-delà, le modèle est présumé à risque systémique et entraîne des obligations supplémentaires (évaluations, mesures de cybersécurité, tests adversariaux).
En tant que déployeur d’une application basée sur un GPAI, vous restez responsable de l’usage que vous en faites. Un chatbot RH basé sur GPT-5 peut basculer en système haut risque selon son cas d’usage. Le statut GPAI du modèle sous-jacent ne vous exonère pas de la classification applicative.
La conformité AI Act ne se traite pas comme un projet juridique isolé — elle se traite comme un projet d’architecture. Les obligations centrales (système de gestion des risques, documentation technique, logs, supervision humaine, robustesse, cybersécurité) sont exactement ce qu’on demande à une IA déployée sérieusement en production, AI Act ou pas. La différence, c’est que maintenant c’est opposable.
Trois convictions terrain. Un : la conformité se gagne dans la façon dont les systèmes sont architecturés, pas dans le PDF transmis au juridique. Systèmes auditables, interopérables, logs centralisés, supervision humaine intégrée dans le workflow — c’est la base. Deux : les déploiements sur infrastructure maîtrisée (cloud privé, on-premise, instance dédiée avec garanties contractuelles) facilitent nettement la conformité. Vous contrôlez les logs, les données d’entraînement, la traçabilité des décisions. C’est exactement la ligne de notre série sur la souveraineté IA. Trois : l’AI literacy se construit par la pratique. Des équipes qui manipulent, testent et déploient de l’IA comprennent les risques. Les formations théoriques seules ne passent pas l’épreuve d’un contrôle CNIL.
Chez Molia, les missions de conseil en IA intègrent systématiquement ces dimensions : cartographie des systèmes, architecture auditable, documentation technique, transfert de compétences. Chaque mission se termine en production — et cela inclut désormais la conformité AI Act comme attribut de qualité, pas comme option.
Le 2 août 2026, ce n’est pas une deadline lointaine — c’est dans quatre mois. Les entreprises qui commencent maintenant la cartographie et la classification ont le temps de faire les choses proprement. Celles qui attendront l’été le feront dans l’urgence.
Article suivant de la série : le Data Act, entré en application en septembre 2025, qui forme avec l’AI Act le duo réglementaire européen sur la gouvernance des données et de l’IA.
Cet article fait partie de la série Souveraineté IA par Molia.Une question sur la mise en conformité AI Act de vos systèmes ? Contactez-nous.
Tous droits réservés. © 2026 Molia.
.png)
.png)
.png)
