Directive UE 2024/2853: si tu vends un agent IA, tu deviens fabricant (Lyon)

Tu vends un agent IA? Mauvaise nouvelle: tu es “fabricant”

À Lyon, beaucoup d’éditeurs et d’ESN vendent aujourd’hui des “agents IA” sous forme de SaaS: copilotes métier, assistants support, agents de qualification commerciale, automatisations reliées à Microsoft 365, Salesforce, ERP, outils ITSM, etc. Jusqu’ici, beaucoup se disaient: “c’est du logiciel, c’est un service, la responsabilité produit c’est pour les machines”.

La directive (UE) 2024/2853 vient casser ce réflexe. Elle refond la responsabilité du fait des produits défectueux (PLD) et dit explicitement que le logiciel est un produit, y compris s’il est fourni via le cloud en SaaS, y compris s’il s’agit d’un système d’IA. Source: texte officiel sur EUR-Lex.

Traduction opérationnelle: si tu développes et mets sur le marché un agent IA (ou une brique logicielle intégrée à une solution), tu peux être traité comme un fabricant. Et “fabricant” veut dire: responsabilité sans faute si le produit est défectueux et cause un dommage. Tes clauses contractuelles ne suffisent plus à te mettre à l’abri.

Le texte, le calendrier, et la règle qui change tout

De quoi on parle

La directive (UE) 2024/2853 est la nouvelle directive européenne sur la responsabilité du fait des produits défectueux. Elle abroge la directive 85/374/CEE. Source: EUR-Lex.

Calendrier à retenir

• Transposition dans les droits nationaux au plus tard le 9 décembre 2026. Source: EUR-Lex (version consolidée).
• Champ temporel: elle ne s’applique pas aux produits mis sur le marché ou mis en service avant le 9 décembre 2026 (règles transitoires). Source: EUR-Lex.

Le switch mental

Le point le plus concret pour le tissu lyonnais (éditeurs B2B, intégrateurs, ESN, studios IA): le logiciel est un produit. Pas “par analogie”, pas “peut-être”. C’est écrit. Et ça vise aussi les systèmes d’IA. Source: EUR-Lex (travaux et texte).

“Fabricant” en 2024/2853: qui prend le rôle, vraiment?

La directive raisonne en chaîne d’opérateurs économiques pour éviter un trou dans la raquette: fabricant, importateur, représentant autorisé, distributeur, etc. Source: EUR-Lex.

Pour une boîte à Lyon, la question n’est pas “est-ce qu’on code tout nous-mêmes?”. La question est: qui met le produit sur le marché sous son nom, qui l’assemble, qui le modifie, qui contrôle les updates, qui pilote le service numérique lié.

Cas typiques à Lyon: quand tu deviens fabricant

• Éditeur SaaS qui vend un agent IA (même si le modèle vient d’une API tierce): tu mets un logiciel sur le marché. Tu es dans le radar “fabricant”.
• ESN qui “packaging” une solution agentique et la revend (marque blanche ou offre catalogue): tu peux être vu comme fabricant si tu te présentes comme fournisseur du produit.
• Intégrateur qui fait une modification substantielle (voir plus bas) ou qui pilote des updates et du run: tu remontes dans la chaîne de responsabilité.
• Acteur UE qui commercialise une solution d’un éditeur hors UE: la directive vise à éviter “pas de défendeur dans l’UE”, donc l’importateur peut être attrait. Source: EUR-Lex.

Et si tu es “provider” au sens AI Act

La directive indique aussi qu’un producteur/développeur de logiciel, y compris les “providers” au sens de l’AI Act, doit être traité comme fabricant. Source: EUR-Lex (documents liés au texte).

Donc si tu fournis un système IA en mode produit (même sous forme d’API ou de SaaS), tu dois raisonner comme un industriel: preuves, maîtrise du cycle de vie, traçabilité.

Responsabilité produit appliquée au SaaS: ce que ça change dans la vraie vie

Le SaaS a longtemps été raconté comme “un service”. La directive 2024/2853 verrouille l’inverse: le logiciel est un produit, quel que soit le mode de fourniture, y compris accès via cloud et SaaS. Source: EUR-Lex.

Conséquence: tu dois penser “défaut produit” pour des sujets qu’on rangeait avant dans “incident de service”:

• erreur de calcul ou de recommandation qui déclenche une action automatisée dommageable,
• mauvaise configuration par défaut qui autorise des actions trop larges,
• failles de sécurité non corrigées,
• mise à jour qui dégrade un comportement critique,
• agent qui agit hors périmètre attendu (permissions, escalade, tool calling).

Agents IA: le piège, c’est le “cycle de vie” (updates + apprentissage continu)

Un agent IA n’est pas un binaire figé. Et la directive l’a intégré: elle tient compte du fait que le fabricant garde du contrôle après la mise sur le marché via updates, upgrades et services numériques liés. Source: EUR-Lex.

Tu restes responsable après la mise sur le marché

Si un défaut apparaît après mise sur le marché à cause de logiciels ou services liés sous ton contrôle, ta responsabilité peut rester engagée. Ça inclut des comportements issus d’algorithmes de machine learning, selon le texte. Source: EUR-Lex.

La notion de “modification substantielle” va te forcer à cadrer ton déploiement continu

Point clé pour les équipes qui déploient en continu: quand une modification substantielle est faite via une mise à jour logicielle ou via l’apprentissage continu d’un système d’IA, le produit “substantiellement modifié” est réputé remis sur le marché ou mis en service au moment de la modification. Source: EUR-Lex.

En clair: ton agent qui “s’améliore tout seul” ou que tu fais évoluer chaque semaine, ce n’est pas neutre juridiquement. Il te faut une discipline de versioning et de preuve: quoi a changé, quand, pourquoi, avec quels tests, et quel impact risques.

Cybersécurité: ne pas patcher peut devenir un “défaut”

La directive souligne qu’un produit peut être défectueux à cause d’un défaut de fourniture de mises à jour de sécurité nécessaires face à l’évolution des risques cyber. Source: EUR-Lex.

Pour les agents IA, c’est direct: tu as une surface d’attaque énorme (prompt injection, exfiltration via tool, secrets dans les logs, actions non autorisées, dépendances supply chain, connecteurs). Si tu ne fournis pas les updates nécessaires, tu t’exposes.

Nuance importante: si l’installation d’une update est hors de ton contrôle (client qui ne patch pas), la situation peut être discutée. Mais ça ne te dispense pas de prouver que tu as fourni l’update, alerté, documenté, et que ton process est solide.

Sur la partie logs, accès et effacement de traces côté agents, tu peux aussi recouper avec deux contenus Lyon IA déjà publiés: Agents IA et cybersécurité: effacement de traces, audit des logs et accès et Sécuriser un agent IA qui a accès à vos outils.

Preuves: la directive aide la “victime”, donc toi tu dois bétonner la traçabilité

Le changement le plus violent, ce n’est pas que “tu es responsable”. C’est que la directive facilite l’accès à la preuve côté demandeur.

Divulgation de preuves: tes logs peuvent finir au tribunal

La directive introduit un mécanisme de divulgation de preuves: une juridiction peut ordonner la communication d’éléments détenus par le défendeur, sous conditions (proportionnalité, protection des secrets d’affaires). La littérature juridique l’analyse déjà, et le mécanisme est ancré dans la directive. Sources: EUR-Lex et analyse académique (Cambridge).

Opérationnellement: tu dois traiter tes logs, métriques, tickets, enregistrements de versions, comme une pièce potentielle. Donc conservation, intégrité, horodatage, contrôle d’accès, et capacité à extraire sans bricoler.

Présomptions en cas de complexité technique

La directive prévoit des présomptionscomplexité technique ou scientifique, typiquement des systèmes ML opaques. Source: EUR-Lex.

Message cash: plus ton agent est complexe, plus tu dois être capable d’expliquer et de démontrer. Sinon, tu subis.

Clauses contractuelles: ce qui devient fragile, voire inopposable

La responsabilité du fait des produits défectueux est une responsabilité “sans faute” dans l’esprit du régime: la victime n’a pas à prouver ta négligence, mais le défaut, le dommage, et le lien causal, avec des mécanismes qui se renforcent.

Dans ce cadre, certaines clauses classiques des contrats SaaS et des contrats d’intégration deviennent beaucoup moins protectrices:

• Exclusions générales de responsabilité sur les dommages causés par le produit: tu peux les écrire, mais tu ne peux pas compter dessus si on est dans un régime de responsabilité produit applicable.
• Clauses “as is” ou “best effort” sur des fonctions critiques: si ton agent est vendu pour agir, la promesse marketing et la doc peuvent se retourner contre toi (attentes légitimes de sécurité).
• Transfert total du risque sur le client (“c’est vous qui validez tout”): utile pour organiser l’usage, pas suffisant pour neutraliser un défaut produit.

À la place, l’enjeu est de réduire le risque à la source et de prouver ta maîtrise: cadrage des usages, limites, contrôles, journaux, correctifs, et process incident.

Pour la partie contractualisation, tu peux t’appuyer sur: Contrat avec un fournisseur d'IA: les clauses à lire deux fois.

Impacts concrets pour QA: il faut tester un agent comme un produit, pas comme une démo

Si tu vends un agent IA, ton dispositif QA ne peut plus se limiter à des tests “ça marche sur mon cas”. Tu dois pouvoir montrer une démarche stable: risques, tests, critères d’acceptation, régression, et suivi post-prod.

Ce que tu dois être capable de prouver

• Versioning du code, des prompts, des policies, des outils connectés, des modèles utilisés.
• Jeux de tests et résultats (y compris cas limites, attaques, données inattendues).
• Tests de non-régression à chaque update (surtout si “modification substantielle” potentielle).
• Garde-fous d’action: permissions minimales, double validation, limites de montants, sandbox, simulation.

Sur les tests de réponses et la construction d’un jeu de tests, tu as un guide utile: Comment évaluer la réponse d'une IA: construire son jeu de tests.

Logs et traçabilité: ce que tu dois journaliser pour survivre

Si un incident arrive, la question ne sera pas “ton agent était cool”. Ce sera “qu’est-ce qui s’est passé, exactement?”. Sans logs exploitables, tu es aveugle. Et avec la divulgation de preuve, tu dois être aussi capable d’extraire proprement.

Minimum de traçabilité pour un agent IA en production

• Qui a déclenché l’agent (user, service account, API key), et avec quelle authentification.
• Quoi: prompt système et instructions actives (ou leur hash), paramètres clés, outils autorisés.
• Contexte: sources RAG consultées, documents, connecteurs, versions de schémas.
• Actions: appels d’outils (tool calls), payloads, résultats, erreurs, retries.
• Décisions: pourquoi l’agent a choisi une action (au minimum des traces structurées).
• Sorties: réponse rendue, transformations, diffusion (email, ticket, CRM).

Pour cadrer la traçabilité côté entreprise, voir aussi: Tracer les décisions prises avec l'aide d'une IA.

Sécurité: l’agent IA est une surface d’attaque, donc un risque produit

Un agent, ce n’est pas “un chatbot plus malin”. C’est un système qui lit, décide et agit. Il faut donc traiter la sécurité comme un composant du produit: conception, tests, durcissement, patch.

• Contrôle d’accès strict (RBAC, scopes, séparation des tenants).
• Gestion des secrets (pas dans les prompts, pas dans les logs, rotation).
• Protection prompt injection et exfiltration (validation d’entrées, allowlist outils, policy d’action).
• Monitoring des comportements anormaux (volume d’actions, destinations, types de données).

Pour aller droit au but: Injection de prompt: la faille que les entreprises sous-estiment et Agents IA en production: les cinq garde-fous à poser.

Assurance: prépare la discussion dès maintenant

La directive ne parle pas d’assurance. Mais dans la vraie vie, c’est un sujet immédiat: si tu deviens “fabricant” d’un produit logiciel agentique, tu dois vérifier que tes contrats d’assurance collent à ton exposition.

• RC Pro: est-ce que les dommages liés à un “produit logiciel” et à des actions automatisées sont couverts?
• Cyber: est-ce que les incidents liés à l’agent (exfiltration, compromission) sont traités? quid des frais d’investigation?
• Plafonds et franchises: compatibles avec tes clients (industrie, santé, finance) et leurs niveaux de dommages potentiels?

Si tu attends 2026 pour ouvrir le dossier, tu vas le faire dans l’urgence, avec des deals déjà signés. Mauvais timing.

Checklist conformité (éditeurs et ESN à Lyon): ce que tu peux lancer ce trimestre

Objectif: arriver au 9 décembre 2026 avec une offre agentique qui ressemble à un produit maîtrisé, pas à un assemblage de démos.

1) Documentation produit et périmètre

• Décrire l’usage prévu et les usages interdits.
• Documenter les limites (données, langues, contextes, seuils).
• Cartographier les composants: modèle(s), fournisseurs API, connecteurs, outils d’action, RAG, vecteurs.
• Tenir un changelog public ou contractuel des évolutions significatives.

2) Évaluation des risques (cycle de vie)

• Faire une analyse “agent” orientée dommages: erreurs d’action, erreurs de recommandation, sécurité, confidentialité.
• Qualifier ce qui pourrait être une modification substantielle (et définir un process de validation).
• Définir une politique d’updates: fréquence, criticité, communication clients.

3) Qualité et tests (QA) industrialisés

• Mettre en place des jeux de tests représentatifs, versionnés.
• Tests de non-régression à chaque release (y compris prompts et policies).
• Tests sécurité dédiés agents: prompt injection, tool abuse, escalation, data leakage.

4) Traçabilité et conservation des preuves

• Journaliser: identités, entrées, sources, tool calls, actions, sorties, erreurs, versions.
• Définir une politique de conservation des logs cohérente (durée, finalités, accès).
• Assurer l’intégrité: horodatage, contrôles d’accès, séparation prod/dev.

Tu peux t’aider de: Écrire une politique de conservation des données pour ses outils IA.

5) Process incident et support

• Runbook incident: détection, triage, contournement, correctif, communication.
• Capacité de rollback et de désactivation d’actions risquées.
• Canal client clair: comment remonter un incident, SLAs, preuves attendues.

Sur la réponse en 24 h, tu as un kit concret: Fuite de données: kit de réponse en 24 h à Lyon.

6) Contractualisation client (sans fantasmer que ça te sauve)

• Définir responsabilités run: qui patch quoi, qui valide quoi, qui administre les accès.
• Clauses sur updates de sécurité: modalités, délais, obligations client d’installation quand applicable.
• Encadrer les usages: droits, limites, obligations de configuration, exigences de journaux côté client si déploiement hybride.
• Transparence sur les dépendances critiques (modèles, API, cloud) et leurs impacts.

7) Assurance et gouvernance

• Revue RC Pro et cyber: couverture “produit logiciel” et “actions automatisées”.
• Nommer un responsable interne “produit agentique”: QA, sécu, conformité, run.
• Mettre un comité de change pour les modifications substantielles.

Le move intelligent à Lyon: arrêter de vendre de “l’agent magique”

La directive UE 2024/2853 ne dit pas “n’innovez pas”. Elle dit: si tu mets sur le marché un logiciel, y compris un agent IA en SaaS, tu dois l’assumer comme un produit. Avec des preuves, un cycle de vie maîtrisé, de la sécurité patchée, et une traçabilité qui tient devant un juge.

Si tu es éditeur ou ESN à Lyon, tu as un avantage: tu peux t’y préparer maintenant, calmement. Le meilleur moment, c’est avant que tes agents IA ne soient partout chez tes clients, sans logs, sans garde-fous, et avec des clauses qui ne pèseront pas lourd quand ça casse.