Dette de conformité : quand votre IA change plus vite que vous ne pouvez l'expliquer

Pourquoi le report de certaines échéances de l'IA Act européen ne doit pas être interprété comme un répit

‍

Par Richard Mort

‍

Le 27 juillet 2026, l'Union européenne a modifié deux échéances importantes de l'IA Act. Les exigences relatives aux systèmes à haut risque visés par l'article 6, paragraphe 2, et l'annexe III, notamment pour certains usages dans l'emploi, l'éducation, les infrastructures critiques et l'application de la loi, s'appliquent désormais à partir du 2 décembre 2027. Pour l'IA à haut risque intégrée dans des produits réglementés en vertu de l'article 6, paragraphe 1, et de l'annexe I, la date est fixée au 2 août 2028.

‍

Six jours plus tard, une autre échéance a pris effet. Le 2 août 2026, les obligations de transparence prévues à l'article 50 sont devenues applicables. Celles-ci couvrent notamment l'obligation d'informer les utilisateurs lorsqu'ils interagissent avec certains systèmes d'IA, le marquage lisible par machine des contenus synthétiques et la divulgation des deepfakes dans des circonstances précises. Une courte période de transition court jusqu'au 2 décembre 2026 pour les systèmes mis sur le marché avant le 2 août 2026, mais uniquement pour l'exigence de marquage lisible par machine. L'obligation modifiée en matière de culture numérique liée à l'IA reste en vigueur. Le Bureau de l'IA a également commencé à faire appliquer les règles déjà en vigueur pour les fournisseurs de modèles d'IA à usage général concernés.

‍

Affirmer que « l'IA Act a été retardé » est donc une simplification dangereuse. Certaines parties du régime relatif aux systèmes à haut risque ont été décalées, mais d'autres obligations étaient déjà en vigueur ou le sont devenues en août.

‍

‍

La justification honnête d'un délai supplémentaire

‍

Ce report repose sur une raison valable. La Commission européenne a reconnu que les normes étaient en retard et que l'infrastructure nationale de gouvernance et d'évaluation de la conformité ne s'était pas développée aussi rapidement que prévu. Ses propres lignes directrices sur la classification des systèmes à haut risque étaient encore à l'état de projet à la date de référence du 11 août 2026.

‍

Une entreprise qui finaliserait tous ses contrôles, modèles et procédures d'évaluation sur la base d'éléments inachevés risquerait de dépenser inutilement et de devoir refaire le travail. Attendre permet de limiter le gaspillage. Choisir un organisme notifié avant même de savoir s'il est nécessaire n'a guère de sens. Il en va de même pour considérer un certificat de système de gestion comme une preuve de conformité à l'IA Act alors que la voie juridique applicable et les normes techniques sont encore en cours de définition.

‍

Cette concession est importante, car l'argument pertinent n'est pas de « tout commencer maintenant », mais d'agir avec plus de précision.

‍

Les normes peuvent clarifier la manière dont une organisation démontre qu'un contrôle est adéquat. Elles ne peuvent pas recréer l'état d'un système d'IA qui n'a jamais été conservé.

‍

‍

Les preuves que l'extension ne peut pas préserver

‍

J'utilise ici le terme « dette de conformité » comme une étiquette analytique, et non comme un terme issu de l'IA Act.

‍

La dette de conformité représente le coût, le risque et la perte de marge de manœuvre croissants qui surviennent lorsqu'une organisation modifie ou utilise un système d'IA plus rapidement qu'elle ne préserve les preuves, la clarté des rôles et les contrôles du cycle de vie nécessaires pour démontrer ce qu'est le système, comment il a évolué et si son utilisation réelle répond aux exigences applicables.

‍

Elle est plus restreinte que la dette de conformité générale. La dette d'exécution interroge la capacité des opérations à soutenir ce qu'un achat d'IA exige en pratique. La dette de souveraineté interroge ce qu'une organisation contrôle réellement à travers les modèles, l'infrastructure et les juridictions. La dette de conformité pose une question plus médico-légale : l'organisation est-elle encore en mesure de démontrer ce que le système opérationnel est devenu ?

‍

Pour les systèmes à haut risque concernés, l'annexe IV de l'Acte donne à cette question un poids réel. Lorsque les dispositions pertinentes s'appliquent, la documentation technique doit pouvoir couvrir la finalité prévue, la version actuelle et sa relation avec les versions précédentes, les logiciels ou micrologiciels pertinents, les outils tiers et la manière dont ils ont été intégrés ou modifiés, la provenance des données, les données de validation et de test, les mesures de performance, les rapports de test datés, les changements prédéterminés et les changements effectués tout au long du cycle de vie.

‍

Il ne s'agit pas d'exiger une politique rédigée dans l'abstrait. Il s'agit d'exiger une mémoire.

‍

Prenons une progression d'entreprise hypothétique mais tout à fait ordinaire. Un assistant IA est introduit pour aider à rédiger des offres d'emploi. Une équipe le connecte ensuite aux données des candidats et commence à l'utiliser pour classer ces derniers. Le fournisseur modifie le modèle sous-jacent. L'index de recherche est actualisé. Un prompt est ajusté après des plaintes. Le seuil d'acceptation est modifié parce que les responsables estiment que les résultats sont trop conservateurs.

‍

Dix-huit mois plus tard, l'entreprise peut montrer le système tel qu'il fonctionne aujourd'hui. Elle ne peut pas reproduire le système qui a influencé les premières listes de candidats. L'ancien prompt se trouve dans le compte d'un ancien employé. L'index de recherche précédent a été écrasé. Le jeu de test a changé. Les interventions humaines ont été discutées lors de réunions, mais n'ont jamais été liées à une version.

‍

Aucun échec de conformité spectaculaire ne s'est produit un mardi en particulier. L'historique probant s'est simplement fragmenté alors que le système continuait d'évoluer.

‍

C'est pourquoi la dette de conformité peut s'accumuler. Un résultat de test sans le modèle, le prompt, la source de récupération et le seuil auxquels il s'applique constitue une preuve fragile. Une description du modèle sans les données opérationnelles et les garde-fous associés ne décrit pas le système déployé. Un document fournisseur actuel peut ne rien dire sur la version utilisée seize mois plus tôt.

‍

L'IA fantôme aggrave la situation. Lorsqu'un outil est utilisé avant d'être répertorié, l'exercice ultérieur ne se limite pas à une simple classification. Quelqu'un doit reconstituer qui l'a utilisé, dans quel but, avec quelles données, selon quelles conditions fournisseurs et à travers combien de changements. Souvent, les personnes impliquées pensaient adopter un outil de productivité, et non créer un futur problème de preuve.

‍

‍

Quand une intégration change la donne

‍

L'IA Act rend également la responsabilité juridique plus fluide que ne le supposent de nombreuses équipes achats.

‍

En vertu de l'article 25, un distributeur, importateur, déployeur ou tout autre tiers peut être considéré comme le fournisseur d'un système à haut risque s'il appose son propre nom ou sa marque sur le système, s'il le modifie substantiellement alors qu'il reste à haut risque, ou s'il change la finalité prévue d'un système initialement non classé à haut risque pour qu'il le devienne. Le fournisseur d'origine a alors des obligations de coopération spécifiques, incluant la documentation technique, les limitations connues et un accès technique ciblé pour les tests et la validation.

‍

Ces règles pour les opérateurs de systèmes à haut risque suivent le calendrier révisé de 2027 ou 2028. Le point de gestion aujourd'hui est plus simple : les faits qui détermineront la réponse ultérieure sont en train d'être créés maintenant.

‍

Un contrat qualifiant le client de « déployeur » ne peut trancher la question si le client a, en réalité, détourné le système de sa finalité ou l'a altéré de manière juridiquement significative. De même, toute mise à jour logicielle ne constitue pas une modification substantielle. C'est précisément pour cette raison qu'une base de référence et un historique des changements sont essentiels. Sans eux, l'organisation pourrait avoir du mal à démontrer si un changement était routinier, prévu et documenté, ou s'il a altéré la finalité ou la conformité du système.

‍

Le contrat fournisseur compte autant que le dossier interne. Lorsque les dispositions pertinentes sur les systèmes à haut risque s'appliquent, l'article 25(4) exige un accord écrit couvrant les informations, les capacités, l'accès technique et l'assistance nécessaires de la part des fournisseurs tiers de modèles, systèmes, services ou composants intégrés au système à haut risque.

‍

Cela transforme une future question réglementaire en une question d'achat immédiate. Quelles versions de modèles et de systèmes le fournisseur peut-il identifier ? Informera-t-il des changements matériels ? Quelle documentation restera disponible après une mise à jour ? Le client peut-il accéder aux journaux pertinents, aux limitations connues et au support de test ? Qui coopère lorsqu'un régulateur, un client ou un assureur demande des preuves ?

‍

Il est bien plus difficile de négocier ces droits une fois que l'organisation est devenue dépendante du système.

‍

Les conseils d'administration ne doivent pas non plus se laisser abuser par de fausses assurances. L'évaluation de la conformité n'est pas requise pour tous les systèmes d'IA et n'implique pas systématiquement un auditeur externe. Pour la plupart des catégories de l'annexe III, l'article 43 prévoit une procédure de contrôle interne sans organisme notifié. Les systèmes liés à des produits suivent la procédure sectorielle applicable. Le marquage CE est l'indication réglementaire de conformité du fournisseur, et non une approbation de l'UE ou un label de qualité général.

‍

Aucun certificat ne peut compenser un historique lacunaire.

‍

‍

Consacrez votre temps à ce qui ne se bonifie pas avec le temps.

‍

La préparation la plus judicieuse consiste dès à présent à effectuer le travail dont la valeur ne dépend pas de la formulation finale d'une norme.

‍

Commencez par un inventaire dynamique qui consigne l'usage prévu, le responsable métier, le fournisseur, la zone géographique de déploiement et le rôle juridique provisoire. Conservez les versions de l'application, du modèle, des invites (prompts), des sources de récupération, des seuils et des garde-fous. Rattachez les jeux de tests, les critères de performance, les échecs et les décisions de validation aux versions qu'ils ont permis d'approuver. Enregistrez les interventions humaines significatives, les incidents, les exceptions et les changements de fournisseurs tant que les personnes concernées sont en mesure de les expliquer.

‍

Mettez en place un point de contrôle. Avant toute mise à jour importante, quelqu'un doit se demander si l'usage prévu, la classification des risques, l'attribution des fournisseurs ou le rôle juridique ont pu évoluer. Il n'est pas nécessaire de transformer chaque mise à jour en séminaire juridique. Il suffit d'un responsable désigné et d'une procédure d'escalade en cas de doute.

‍

La FAQ publique de SAP sur l'IA Act européen illustre parfaitement cette approche. L'entreprise précise que les classifications de ses fonctionnalités d'IA sont « documentées et révisées à mesure que les fonctionnalités d'IA évoluent ». Cette déclaration ne prouve pas la conformité. Elle démontre pourquoi une classification et un historique de révision tenus à jour sont plus utiles qu'une déclaration de préparation rétrospective.

‍

Les obligations actuelles ne doivent pas non plus être mises en attente. Les organisations devraient déjà avoir traité les obligations de transparence de l'article 50 qui leur incombent. Elles devraient prendre des mesures proportionnées pour favoriser la culture de l'IA conformément à l'article 4 modifié. Les fournisseurs concernés de modèles d'IA à usage général ne peuvent considérer l'échéance de 2027 pour les systèmes existants comme s'appliquant aux modèles mis sur le marché après le 2 août 2025. Les obligations existantes en matière de RGPD, de droit du travail, de protection des consommateurs, de sécurité des produits et de cybersécurité restent pleinement en vigueur.

‍

Qu'est-ce qui peut attendre ? Les mises en correspondance finales avec des normes encore en cours d'élaboration. Les répétitions générales pour les procédures de conformité dont la classification ou le traitement sectoriel restent incertains. Le recours à un organisme notifié lorsque la loi autorise un contrôle interne. Tout exercice coûteux conçu principalement pour afficher un pourcentage rassurant sur une présentation destinée au conseil d'administration.

‍

Un test de conseil d'administration utile est bien plus difficile à simuler. Prenez un système d'IA matériel et demandez-vous combien de temps il faudrait pour produire un historique défendable de son objectif, de ses versions, de ses sources de données, de ses tests, de ses changements majeurs, de ses fournisseurs et des décisions prises par les responsables. Quelques heures ? Quelques jours ? Ou bien faut-il solliciter six départements et trois prestataires sans que personne ne sache vraiment à quelle version les preuves se rapportent ?

‍

Ce délai de récupération est un bien meilleur indicateur qu'un simple score de « conformité à l'IA Act ».

‍

Une certaine dette de conformité peut être acceptée en toute connaissance de cause. Une exception contrôlée possède un responsable désigné, un périmètre documenté, une justification, une estimation budgétaire ou en ressources, une date limite, un déclencheur pour une action anticipée et un plan de remédiation. Une exception sans responsable ni date de fin n'est qu'une inconnue qui vieillit.

‍

Pour un système existant fragile, la solution n'est peut-être pas d'ajouter de la documentation. La direction peut décider d'en restreindre l'usage, de le refondre pour permettre la journalisation et le contrôle de version, de remplacer un fournisseur incapable de fournir les preuves nécessaires, ou de mettre hors service un système à faible valeur ajoutée avant l'échéance à haut risque.

‍

C'est ici que la rigueur dans la livraison de logiciels devient concrète. Les preuves ne peuvent pas résider dans un dossier juridique assemblé à la fin. Elles doivent accompagner les versions, les tests d'acceptation, les changements de fournisseurs et les décisions opérationnelles. Pour une entreprise de livraison transfrontalière comme Dirox, la contribution utile n'est pas un badge de conformité. C'est un cycle de vie logiciel propice à la traçabilité, avec une propriété claire, des versions documentées, des critères d'acceptation testables et des transferts de responsabilités entre fournisseurs qui restent liés au système qu'ils ont modifié.

‍

Plus de temps peut réduire le gaspillage. Cela peut aussi masquer la dégradation.

‍

D'ici décembre 2027 ou août 2028, la solidité se mesurera moins à l'épaisseur d'un classeur de conformité qu'à la capacité d'expliquer, rapidement et de manière crédible, ce qu'est le système, comment il a été conçu et qui en est responsable. Lorsque le système évolue constamment et que les preuves ne suivent pas, le report de l'échéance ne fait qu'agrandir le fossé.

‍

‍