Il reste moins de six semaines. Le 2 août 2026, les dispositions initiales de l’AI Act auraient dû prendre pleinement effet — et même si l’accord politique provisoire du 7 mai sur le Digital Omnibus a repoussé l’obligation de conformité pour les systèmes à haut risque au 2 décembre 2027, la formalisation législative, elle, doit être adoptée par le Parlement européen et le Conseil avant cette date butoir. Ce délai n’est pas une amnistie : c’est une course contre la montre administrative pour les entreprises qui n’ont pas encore engagé leur chantier de conformité. En France, la CNIL, la DGCCRF et l’Arcom — désignées comme autorités nationales compétentes — intensifient leurs communications. Traîner, c’est s’exposer.

Pour les décideurs tech, les DSI et les développeurs qui déploient des systèmes d’intelligence artificielle, ce guide répond à une seule question : que faire concrètement d’ici le 2 août ?

Qu’est-ce que l’AI Act et pourquoi le 2 août compte vraiment

L’AI Act (Règlement UE 2024/1689) est entré en vigueur le 1er août 2024. Il s’applique progressivement par couches : les systèmes d’IA interdits devaient être hors service depuis février 2025 ; les modèles à usage général (GPAI) et les modèles avec impact systémique depuis août 2025 ; les systèmes à haut risque doivent être conformes au plus tard août 2026 — ou désormais décembre 2027 si le Digital Omnibus est formalisé à temps.

Le nœud du problème : si le texte modificatif n’est pas adopté avant le 2 août 2026, les obligations originelles du règlement entrent en vigueur sans transition. Les entreprises qui ont parié sur le report pourraient se retrouver en infraction du jour au lendemain. Les sanctions prévues sont sévères : jusqu’à 30 millions d’euros ou 6 % du chiffre d’affaires mondial annuel pour les infractions les plus graves.

Autrement dit : compter sur le calendrier législatif européen sans préparer sa conformité, c’est jouer à la roulette réglementaire avec les finances de l’entreprise.

La classification par niveaux de risque : savoir où vous êtes

L’AI Act organise les systèmes d’IA en quatre catégories de risque. Identifier la vôtre est le premier réflexe obligatoire.

Risque inacceptable (interdit) : systèmes de score social généralisé, manipulation subliminale, exploitation des vulnérabilités psychologiques, identification biométrique en temps réel dans les espaces publics (sauf exceptions policières encadrées). Si votre produit tombe dans cette case, il doit déjà être hors production depuis dix-huit mois.

Haut risque : c’est là que la majorité des entreprises tech sont exposées. L’annexe III du règlement liste huit domaines : infrastructures critiques, éducation et formation, emploi et gestion des RH, accès aux services essentiels (crédit, assurance), répression pénale, gestion des migrations, administration de la justice, démocratisation électorale. Un système RH qui filtre des CV avec de l’IA ? Haut risque. Un chatbot bancaire qui évalue la solvabilité ? Haut risque.

Risque limité : les chatbots et agents conversationnels doivent être identifiés comme IA auprès des utilisateurs (obligation de transparence). Les deepfakes doivent être étiquetés.

Risque minimal : filtres spam, moteurs de recommandation de contenu, jeux vidéo — peu d’obligations spécifiques, mais les pratiques responsables restent recommandées.

# Arbre de décision simplifié pour classifier votre système IA
# NE PAS utiliser comme seul outil de conformité légale.

DOMAINES_HAUT_RISQUE = [
    "recrutement", "credit", "assurance", "sante",
    "justice", "migration", "education", "infrastructure_critique"
]

def classifier_systeme_ia(domaine, interaction_humaine, impact_droits):
    if domaine in DOMAINES_HAUT_RISQUE and impact_droits:
        return "HAUT_RISQUE", "Annexe III — obligations complètes"
    if interaction_humaine and not impact_droits:
        return "RISQUE_LIMITE", "Transparence obligatoire"
    return "RISQUE_MINIMAL", "Bonnes pratiques recommandées"

niveau, obligation = classifier_systeme_ia(
    domaine="recrutement",
    interaction_humaine=True,
    impact_droits=True
)
print(f"Niveau : {niveau} | Obligation : {obligation}")
# Niveau : HAUT_RISQUE | Obligation : Annexe III — obligations complètes

Les obligations concrètes pour les systèmes à haut risque

Si votre système est classé à haut risque, voici ce que le règlement exige. Chaque point correspond à un article précis et à des preuves documentaires à produire en cas de contrôle.

Système de gestion des risques (Article 9) : vous devez établir, documenter et maintenir un processus itératif d’identification, d’analyse et d’atténuation des risques pendant tout le cycle de vie du système. Ce n’est pas une analyse ponctuelle — c’est un processus vivant.

Gouvernance des données (Article 10) : les données d’entraînement, de validation et de test doivent répondre à des critères de qualité définis. Biais statistiques, représentativité des populations, documentation des sources — tout doit être tracé. Les équipes data ont intérêt à revoir leurs pratiques de labellisation et de curation dès maintenant.

Documentation technique (Article 11) : un dossier technique exhaustif doit accompagner chaque système à haut risque. Il inclut la description du système, ses performances attendues, les scénarios d’utilisation prévus et les mesures de sécurité. Ce document doit être accessible aux autorités de surveillance sur demande.

Journalisation et traçabilité (Article 12) : les systèmes à haut risque doivent conserver des logs permettant de reconstituer les décisions automatisées. Pour les développeurs, cela implique d’instrumenter les inférences avec des métadonnées (version du modèle, horodatage, identifiant de la requête, résultat). Un simple print() ne suffit pas — il faut une infrastructure de logging structuré.

Transparence (Article 13) : les utilisateurs doivent recevoir des informations claires sur les capacités et les limites du système. Les notices d’utilisation doivent mentionner explicitement que le système est une IA et décrire ses biais potentiels connus.

Supervision humaine (Article 14) : les systèmes à haut risque doivent être conçus pour permettre une intervention humaine effective. L’humain doit pouvoir comprendre les sorties, les interpréter, les ignorer ou arrêter le système. Un algorithme de scoring qui produit une décision sans possibilité de recours humain n’est pas conforme.

Exactitude, robustesse, cybersécurité (Article 15) : le système doit atteindre un niveau approprié d’exactitude, être résilient aux erreurs et résistant aux tentatives de manipulation adversariale. Pour les équipes MLOps, cela implique des tests de robustesse (adversarial examples) intégrés dans les pipelines CI/CD.

Le rôle des autorités françaises : CNIL, DGCCRF et Arcom

La France a désigné trois autorités compétentes pour superviser l’application de l’AI Act sur son territoire, chacune couvrant un périmètre sectoriel distinct.

La CNIL (Commission Nationale de l’Informatique et des Libertés) prend en charge les systèmes d’IA qui traitent des données personnelles — ce qui couvre la grande majorité des cas pratiques. Elle a déjà publié plusieurs guides d’accompagnement et mène des consultations auprès des entreprises depuis le début de l’année. Son approche déclarée est pédagogique pour 2026, mais ses pouvoirs de sanction sont réels (jusqu’à 20 millions d’euros au titre du RGPD, désormais articulés avec l’AI Act).

La DGCCRF (Direction générale de la Concurrence, de la Consommation et de la Répression des Fraudes) surveille les pratiques commerciales déloyales liées à l’IA : allégations trompeuses sur les capacités des systèmes, manipulation des consommateurs, clauses abusives dans les contrats SaaS IA. Les éditeurs de logiciels qui vantent des performances non vérifiées sont dans son radar.

L’Arcom (Autorité de régulation de la communication audiovisuelle et numérique) est compétente pour les systèmes d’IA utilisés dans les médias, la recommandation de contenu et la lutte contre la désinformation. Les plateformes qui utilisent l’IA pour la modération automatique de contenu ou la personnalisation éditoriale sont directement concernées.

Digital Omnibus : report réel ou illusion de confort ?

L’accord politique provisoire du 7 mai 2026 sur le Digital Omnibus a suscité un soulagement dans les couloirs des entreprises tech européennes. Ce texte — qui propose de reporter l’obligation de conformité pour les systèmes à haut risque au 2 décembre 2027 — doit encore franchir les étapes parlementaires et être publié au Journal officiel de l’UE avant le 2 août pour être juridiquement opposable.

Ce que beaucoup d’entreprises ignorent : le Digital Omnibus ne suspend pas toutes les obligations. Les exigences de transparence pour les chatbots (Article 50), les restrictions sur les systèmes biométriques et l’interdiction des pratiques inacceptables sont déjà en vigueur et ne font pas l’objet de report. De même, les obligations relatives aux modèles GPAI sont actives depuis août 2025.

Traiter le Digital Omnibus comme un blanc-seing pour repousser toute action à 2027 serait une erreur stratégique. La fenêtre de 18 mois supplémentaires (si elle est confirmée) doit servir à construire une conformité solide, pas à procrastiner.

Agents IA et LLM : les obligations spécifiques aux modèles à usage général

Le chapitre V de l’AI Act s’applique aux modèles d’IA à usage général (GPAI), c’est-à-dire aux grands modèles de langage entraînés sur de larges corpus et utilisables dans de multiples contextes. Cette catégorie englobe GPT-4o, Claude, Gemini, Mistral et leurs dérivés fine-tunés.

Pour les éditeurs qui déploient ces modèles (intégrateurs, développeurs d’applications), les obligations dépendent du niveau d’usage. Si vous fine-tunez un modèle, modifiez son comportement par du prompt engineering structurel ou construisez un agent IA autonome susceptible de prendre des décisions à impact, vous endossez des responsabilités d’intégrateur.

Les fournisseurs de modèles avec impact systémique (défini par un seuil de 10^25 FLOPs d’entraînement) sont soumis à des obligations supplémentaires : évaluation des risques systémiques, déclaration auprès de l’Office européen de l’IA, et publication d’un résumé des données d’entraînement. Anthropic, OpenAI et Google sont directement visés.

Si vous suivez l’évolution des classements LLM et des stratégies autour des modèles de langage en 2026, vous savez que la pression concurrentielle pousse à déployer vite. L’AI Act impose de déployer bien.

# Logger conforme AI Act (Article 12) — traçabilité sans stocker les données brutes
import json, hashlib
from datetime import datetime, timezone

class AIActLogger:
    def __init__(self, system_id, model_version):
        self.system_id = system_id
        self.model_version = model_version

    def log_inference(self, prompt_hash, output, use_case):
        entry = {
            "ts": datetime.now(timezone.utc).isoformat(),
            "system_id": self.system_id,
            "model": self.model_version,
            "prompt_hash": prompt_hash,
            "decision": output.get("decision"),
            "confidence": output.get("confidence"),
            "human_review": output.get("confidence", 1.0) < 0.85,
            "use_case": use_case,
        }
        print(json.dumps(entry, ensure_ascii=False))
        return entry

    @staticmethod
    def hash_prompt(prompt):
        # Anonymise sans stocker les données personnelles brutes (RGPD Art. 5)
        return hashlib.sha256(prompt.encode()).hexdigest()[:16]

logger = AIActLogger("hrbot-v2", "claude-sonnet-4-6")
logger.log_inference(
    prompt_hash=AIActLogger.hash_prompt("Candidat : Marie D., CV joint"),
    output={"decision": "entretien_recommande", "confidence": 0.91},
    use_case="recrutement"
)

La roadmap de conformité en 8 étapes pour agir maintenant

Voici la séquence pragmatique que les RSSI et DPO françaises recommandent pour les semaines à venir.

Étape 1 — Inventaire des systèmes IA : cartographier tous les systèmes d’IA en production, en développement ou en évaluation. Inclure les outils tiers intégrés via API. Cette étape révèle souvent des usages IA non documentés dans les équipes métier.

Étape 2 — Classification des risques : pour chaque système identifié, appliquer la grille de classification AI Act. En cas de doute, privilégier la catégorie supérieure — le principe de précaution protège mieux que l’optimisme réglementaire.

Étape 3 — Gap analysis : comparer l’état actuel de chaque système avec les exigences applicables. Prioriser les écarts les plus critiques (absence de supervision humaine, absence de logging, données d’entraînement non documentées).

Étape 4 — Documentation technique : commencer par les systèmes à haut risque. La documentation AI Act peut s’articuler avec le registre des traitements RGPD existant pour éviter les doublons.

Étape 5 — Implémentation des logs d’audit : instrumenter les systèmes en production avec un logging conforme (voir le pattern ci-dessus). Privilégier les solutions de logs immuables (WORM storage, services cloud avec audit trail certifié).

Étape 6 — Formation des équipes : les développeurs, product managers et managers métier qui travaillent avec des systèmes IA doivent comprendre les obligations qui les concernent. L’AI Act n’est pas seulement un sujet juridique — c’est une contrainte de conception.

Étape 7 — Désignation d’un référent AI Act : nommer une personne responsable du suivi de conformité, en lien avec le DPO existant. Dans les structures de taille intermédiaire, ce rôle peut être couplé avec la fonction RSSI.

Étape 8 — Dialogue avec les autorités : la CNIL propose des accompagnements et des bacs à sable réglementaires. Engager proactivement le dialogue est bien perçu par les régulateurs et réduit le risque de sanction en cas d’infraction non intentionnelle.

Ce que révèle VivaTech sur la maturité IA des entreprises françaises

Le récent salon VivaTech 2026, marqué par les interventions de Yann LeCun sur l’avenir des agents IA, a mis en lumière un paradoxe saisissant : la France abrite un écosystème IA de rang mondial, mais la majorité des PME et ETI françaises n’ont engagé aucune démarche de conformité AI Act concrète. La maturité des startups IA n’irrigue pas encore la masse des adoptants enterprise.

Cette asymétrie crée une opportunité pour les entreprises qui prennent l’avance : la conformité n’est pas seulement un coût, c’est un avantage concurrentiel dans les appels d’offres publics (qui intégreront des critères AI Act) et dans les contrats enterprise. Mistral AI, qui déploie auprès des administrations françaises, ne le fait pas malgré les contraintes réglementaires — il le fait en partie grâce à sa capacité à démontrer une conformité souveraine.

Conclusion : six semaines pour transformer une contrainte en avantage

Le 2 août 2026 n’est pas une date abstraite. C’est la ligne de départ d’une ère réglementaire qui va remodeler le marché de l’IA en Europe pour la décennie à venir. Les entreprises qui seront prêtes — même partiellement — auront transformé une contrainte légale en signal de confiance pour leurs clients, partenaires et investisseurs.

La conformité AI Act n’est pas un projet à six mois que l’on lance après les vacances d’été. C’est un chantier à démarrer maintenant, avec des premiers livrables documentés avant le 2 août : inventaire des systèmes, classification de risque, gap analysis. Le reste peut suivre dans les mois qui viennent — mais le premier geste, lui, ne peut pas attendre.

Sources :

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.