J'ai eu cette conversation 3 fois en T1 2026 avec des dirigeants de SaaS qui pensaient être totalement hors scope CRA. À chaque fois, l'ajout d'un agent IA dans leur produit avait potentiellement modifié leur statut sans qu'ils s'en rendent compte. Sans déclic, ils risquent de découvrir en mi-2027 qu'ils auraient dû faire un dossier qu'ils n'ont pas fait.
Le Cyber Resilience Act, entré en vigueur en 2024, applicable en décembre 2027, vise les "produits avec composants numériques mis sur le marché EU". Un SaaS pur n'est généralement pas concerné (il est considéré comme un service, pas un produit). Mais l'ajout d'un agent IA peut changer cette analyse. Voici comment.
Le périmètre CRA en 2 minutes
Le CRA couvre les produits avec composants numériques (PWCN) mis sur le marché de l'Union. La définition est large :
- Tout produit logiciel ou matériel mis sur le marché EU avec une composante numérique.
- Exclusions explicites : SaaS purs (sauf composantes embarquées), open source non commercialisé, équipements déjà couverts par d'autres réglementations sectorielles (médical, automobile, aviation).
La frontière entre SaaS et "produit avec composants numériques" est subtile. Trois critères de bascule, souvent ignorés.
Les 3 critères qui font basculer un SaaS dans le CRA
Critère 1 — Composantes installées chez le client
Si votre SaaS distribue une composante installée chez le client (CLI, agent on-prem, application desktop, plugin de navigateur, MCP server, application mobile sideloadable), cette composante est un produit avec composants numériques. CRA applicable sur cette composante.
L'agent IA déclencheur typique :
- Vous distribuez un MCP server que les clients installent dans leur environnement Claude / Cursor / Copilot.
- Vous distribuez un agent installable on-prem pour des questions de souveraineté ou de latence.
- Vous distribuez un plugin pour qu'un agent tiers se branche à votre service.
Tous ces cas font sortir du périmètre "service pur" et entrer dans le périmètre CRA.
Critère 2 — IA embarquée dans un produit hardware
Si vous éditez un logiciel embarqué dans un produit physique vendu en EU (objets connectés, équipements industriels, dispositifs grand public), CRA applicable. L'IA dans ce contexte ajoute des obligations spécifiques (logging, transparence) mais ne change pas la nature de l'obligation CRA.
Cas observé : startup HealthTech qui édite le firmware d'un dispositif de monitoring à domicile avec un agent IA local pour la classification d'événements. CRA applicable, sans ambiguïté.
Critère 3 — Composantes downloadable nécessaires au fonctionnement
Si votre SaaS distribue des artefacts téléchargeables nécessaires à son fonctionnement (modèles ONNX pour inference côté client, packages Python sur PyPI, images Docker pour self-host, agents conteneurisés), ces artefacts sont des PWCN.
Cas observé : SaaS DevOps qui distribue une image Docker contenant un agent IA pour les déploiements. L'image Docker est mise sur le marché EU dès qu'elle est téléchargée par un client EU. CRA applicable sur l'image.
Ce que ça change concrètement
Si votre produit bascule dans le CRA, vous devenez fabricant au sens du règlement. Obligations principales :
- Évaluation de conformité avant mise sur le marché.
- Marquage CE apposé.
- Déclaration UE de conformité signée.
- Documentation technique (annexe IV) maintenue.
- Gestion des vulnérabilités sur toute la durée de vie du produit (typiquement 5 ans minimum).
- PSIRT et coordinated vulnerability disclosure.
- Notification d'incident exploité activement à l'ENISA dans les 24h.
- Mise à jour de sécurité gratuite pendant la période de support attendue.
Coût d'une roadmap CRA pour une PME éditrice : 250-400 k€ sur 18 mois. Voir CRA coût non-conformité PME éditrice.
Les obligations spécifiques pour les composantes IA
Le CRA et l'AI Act se cumulent. Pour une composante IA dans un PWCN :
- Exigences essentielles de sécurité (annexe I du CRA) : confidentialité, intégrité, disponibilité, principe du moindre privilège, robustesse aux entrées malformées (= prompt injection inclus), journalisation des événements de sécurité, mises à jour de sécurité.
- Surveillance post-marché : suivre les vulnérabilités spécifiques IA (jailbreak, prompt injection, memory poisoning).
- Mises à jour de modèles : doivent être traitées comme des mises à jour de sécurité quand elles corrigent un comportement dangereux.
C'est sur les vulnérabilités IA-spécifiques que l'écart de maturité est le plus grand actuellement. Les processus PSIRT classiques ne savent pas traiter un jailbreak ou un prompt injection comme un CVE.
Comment détecter la bascule
Trois questions à se poser une fois par trimestre :
Q1 — Distribuons-nous des artefacts qu'un client EU peut télécharger et exécuter localement ?
Liste exhaustive : CLI, SDK distribué publiquement, package PyPI/npm, image Docker, plugin, extension navigateur, app mobile sideloadable, MCP server, agent installable.
Si oui sur au moins un : analyse CRA à faire.
Q2 — Ces artefacts contiennent-ils ou interagissent-ils avec un modèle IA ?
Que ce soit un modèle embarqué (ONNX, GGUF) ou un orchestrateur qui appelle un LLM tiers.
Q3 — Sommes-nous identifiables comme fabricant de cet artefact ?
Si oui (nom de l'éditeur, marque déposée, GitHub org), vous êtes fabricant au sens du CRA. Les pénalités s'appliquent à vous.
Le piège qu'on voit le plus
Distribuer un MCP server "open source" sans gouvernance
Beaucoup d'éditeurs SaaS publient un MCP server open source sur GitHub pour faciliter l'intégration avec leur API. Argument : "c'est open source, on n'est pas concerné par le CRA".
Faux. Le CRA exclut l'open source qui n'est pas commercialisé. Un MCP server open source maintenu par un éditeur qui le distribue activement (qui pousse ses clients à l'installer pour utiliser son service commercial) est commercialisé indirectement. La Commission a précisé cette interprétation en 2025.
Conséquence : votre MCP server tombe dans le CRA. Vous devez le marquer CE, maintenir un PSIRT, gérer les vulnérabilités.
Le contre-exemple instructif
Une scale-up SaaS B2B française, ~70 personnes, distribue depuis fin 2025 un MCP server open source qui permet à Cursor et Claude de se connecter à son API. ~3 800 téléchargements en 6 mois. Aucune analyse CRA faite parce que "on est SaaS, pas un produit".
En T1 2026, j'ai accompagné l'analyse. Conclusion : le MCP server est un PWCN au sens du CRA, l'éditeur en est le fabricant, l'application en décembre 2027 sera complète. Roadmap chiffrée : 130 k€ sur 18 mois pour la conformité (analyse, dossier technique, PSIRT, mises à jour, surveillance).
Alternative étudiée : retirer le MCP server et ne plus le distribuer. Évalué et écarté : il représente ~30% des nouveaux deals enterprise depuis 6 mois, donc valeur commerciale supérieure au coût de la conformité.
Décision : démarrer la roadmap CRA dès T2 2026 pour être prêt en T3 2027 avec marge. Sans cette analyse, ils auraient découvert le problème en T2 2027 et auraient eu 6 mois pour faire ce qui prend 18 mois.
Pour la roadmap CRA générale, voir CRA jalons 2026-2027. Pour le chiffrage budgétaire, voir CRA coût non-conformité. Pour les SBOM exigés, voir SBOM CRA-compliant.