À 30 jours de l'échéance du 2 août 2026, une majorité d'organisations dans le scope de l'EU AI Act ont produit leur documentation technique et désigné un responsable de conformité. Le tableau de bord légal avance. Mais entre la conformité documentaire et la gouvernance opérationnelle, l'écart est structurel — et prévisible. Voici les trois lacunes que les premières vérifications internes révèlent systématiquement, et comment les traiter avant que l'autorité compétente ne les identifie à votre place.
L'illusion de la conformité documentaire
L'EU AI Act impose aux fournisseurs et déployeurs de systèmes d'IA à risque élevé un corpus d'obligations précises : évaluation continue des risques, documentation technique détaillée, mécanismes de supervision humaine effectifs, tests de robustesse, et notification aux autorités nationales compétentes. Ces obligations sont claires, vérifiables — et désormais proches du contrôle.
Ce que la plupart des organisations n'ont pas encore traduit en pratique, c'est la distinction fondamentale entre avoir un document et avoir un dispositif opérationnel. L'ENISA, dans son rapport de mai 2026 sur la maturité AI Act des entités soumises à NIS2, observe que 71 % des organisations auditées disposent d'une documentation technique conforme — mais que seulement 29 % peuvent démontrer que leurs mécanismes de supervision humaine sont effectivement actifs en production.
Ce ratio n'est pas surprenant. Les délais de deux ans accordés depuis l'entrée en vigueur du règlement ont encouragé une logique de projet : produire la documentation, désigner les responsables, cocher les cases. Pendant ce temps, les déploiements d'IA ont continué d'évoluer — sans que la documentation les suive, sans que les processus de gouvernance soient mis à l'épreuve.
Lacune 1 : la dérive des systèmes après la certification initiale
Un système d'IA certifié conforme en janvier 2026 ne l'est pas nécessairement en juillet. C'est la logique que la majorité des équipes GRC n'ont pas encore traduite en processus continu.
Les systèmes d'IA à risque élevé évoluent : les modèles sont réentraînés sur de nouvelles données, les cas d'usage s'élargissent, les paramètres de décision changent. L'article 9 de l'EU AI Act exige que le système de gestion des risques soit "continu et itératif" — pas un audit annuel. Pourtant, 83 % des organisations auditées par le consortium CERRE en 2026 n'ont pas de processus de réévaluation automatique déclenché par un changement de modèle ou de périmètre d'usage.
L'erreur courante est de traiter la conformité AI Act comme un projet ISO 27001 avec une certification ponctuelle. Un exemple concret : une organisation déploie un outil de scoring RH en décembre 2025, le certifie conforme, puis étend son usage à l'évaluation des performances en mai 2026 sans réévaluation du niveau de risque. Le changement de cas d'usage modifie potentiellement la classification du système — et la documentation ne le reflète pas.
La réponse opérationnelle : définir un AI change management process. Toute modification du modèle, du jeu de données d'entraînement ou du périmètre d'usage déclenche automatiquement une réévaluation du niveau de risque et une mise à jour de la documentation technique. Ce processus doit être formalisé, testé et auditable avant le 2 août.
Lacune 2 : la supervision humaine sur le papier, absente en production
L'article 14 de l'EU AI Act exige que les déployeurs mettent en place des mesures permettant aux opérateurs humains de "surveiller, comprendre et, si nécessaire, arrêter ou remettre en question le système d'IA". C'est l'une des obligations les plus citées dans les documents de conformité. Et l'une des moins effectives.
Deux frictions structurelles expliquent cet écart. La première est cognitive : lorsqu'un système traite plusieurs milliers de décisions par heure — scoring de crédit, triage de candidatures, détection d'anomalies — la supervision humaine ne peut pas s'exercer sur chaque output. Elle se réduit en pratique à des revues d'échantillons ou à des alertes sur dépassement de seuil. Ce n'est pas ce que le texte envisage.
La seconde friction est organisationnelle. Dans beaucoup d'organisations, le responsable de la supervision humaine a été désigné dans le document de conformité mais n'a pas été équipé : il n'a pas accès aux logs en temps réel, n'a pas été formé aux caractéristiques spécifiques du système, et ne dispose pas d'une procédure claire pour exercer son droit d'arrêt.
Un exemple documenté : un établissement financier de taille intermédiaire désigne son responsable conformité comme superviseur humain d'un outil d'analyse comportementale clients. Dans les faits, ce responsable reçoit un rapport PDF mensuel agrégé — sans accès aux décisions individuelles, sans alerte en cas de dérive. La supervision est documentée. Elle n'est pas opérationnelle. Lors d'un contrôle, cette distinction sera immédiatement visible.
Lacune 3 : la chaîne de responsabilité fournisseur, encore incomplète
La chaîne de valeur d'un système d'IA à risque élevé est rarement monolithique. Un déployeur utilise un modèle développé par un fournisseur tiers, hébergé sur une infrastructure cloud, avec des données annotées par un prestataire externe. L'EU AI Act distribue les responsabilités entre ces acteurs via l'article 25 — mais les contrats en vigueur, eux, ne les distribuent pas encore.
Selon un cabinet de droit numérique parisien ayant analysé des contrats SaaS signés en 2025 et 2026, 76 % d'entre eux ne contiennent aucune clause relative aux obligations AI Act. Le déployeur suppose que le fournisseur a géré la conformité en amont. Le fournisseur considère que l'usage relève de la responsabilité du déployeur. En cas d'incident — biais avéré, discrimination systémique, défaillance d'un système de décision automatisée — ni la documentation de conformité ni le contrat ne permettent de désigner clairement le responsable.
Cette lacune est activement surveillée par les autorités nationales de supervision : les premières demandes de documentation contractuelle AI Act ont commencé à arriver dans des organisations françaises au second trimestre 2026. La correction est directe : ajouter dans tout contrat avec un fournisseur de système d'IA à risque élevé une clause définissant les obligations de transparence, de fourniture de documentation technique, de notification en cas de changement de modèle, et de partage de responsabilité au sens de l'article 25.
Évaluer votre exposition avant le 2 août
Ces trois lacunes sont vérifiables en deux semaines avec un gap analysis structuré : inventaire des systèmes à risque élevé avec date de dernière réévaluation, audit des mécanismes de supervision humaine en environnement de production, et revue des contrats fournisseurs actifs. Les organisations qui démarrent maintenant peuvent raisonnablement atteindre un niveau de conformité opérationnelle suffisant avant l'échéance.
Presidio intègre un module de gouvernance AI Act — cartographie des systèmes, suivi des révisions de documentation et alertes sur les dérives de déploiement. Pour qualifier votre niveau d'exposition et prioriser les actions correctrices, un entretien de 30 minutes suffit. Voir aussi notre analyse sur les 4 obligations non déployées à J-40 et le cadre de gouvernance des tiers sous NIS2.
Conclusion
La conformité documentaire à l'EU AI Act est nécessaire. Elle n'est pas suffisante. Les trois lacunes identifiées ici — dérive post-certification, supervision humaine formelle sans effectivité, chaîne de responsabilité contractuelle incomplète — sont structurelles mais traitables. Elles ont en commun avec la majorité des enjeux réglementaires une caractéristique critique : elles ne deviennent visibles que trop tard lorsqu'on attend que le régulateur les signale. À 30 jours de l'échéance du 2 août, la fenêtre pour agir avant le premier cycle d'inspection est encore ouverte — mais étroite. Dans votre organisation, laquelle de ces lacunes avez-vous déjà vérifiée en production ?