Pourquoi l’IA agentique change la donne pour les SaaS

La semaine a mis en lumière un point que beaucoup d’éditeurs SaaS sous-estiment encore : l’IA agentique n’ajoute pas seulement une couche de productivité, elle crée un nouveau périmètre de risque juridique et de sécurité. Dans une note publiée en juillet 2026, le CIANum, rattaché à la CNIL, décrit les risques propres aux agents autonomes : mémoire persistante, autonomie décisionnelle, opacité sur les services tiers appelés et difficulté à identifier le responsable en cas d’erreur ou de fuite de données[7].

Pour un SaaS, le problème est concret. Dès qu’un agent peut lire, résumer, classer, déclencher une action ou enchaîner plusieurs outils, il manipule potentiellement des données personnelles sans que l’utilisateur voie précisément où elles transitent. La note insiste sur un point clé : chaque tâche doit permettre d’identifier les données mobilisées, les agents intervenus et les services tiers sollicités[7]. C’est précisément là que la promesse produit rencontre les exigences du RGPD.

Le sujet n’est pas théorique. Selon une veille récente, des travaux publiés en juillet 2026 recommandent de cloisonner la mémoire des agents, de limiter sa durée de conservation, d’utiliser du sandboxing et d’imposer une validation humaine pour les actions sensibles[7]. Autrement dit, l’IA agentique n’est pas seulement un sujet d’innovation ; c’est désormais un sujet d’architecture de conformité.

Ce que le RGPD exige vraiment quand un agent accède aux données

Le RGPD ne vise pas l’IA en tant que telle, mais il impose des règles difficiles à tenir dès qu’un SaaS donne un accès large à des données clients. Les principes de minimisation, de limitation de conservation et de finalité deviennent centraux dès qu’un agent accumule de l’information en mémoire pour améliorer ses réponses ou automatiser des tâches[7]. Si cette mémoire contient des éléments personnels au-delà du strict nécessaire, le risque de non-conformité augmente rapidement.

La question de l’article 22 est également sensible. La note relayée en juillet 2026 rappelle que plus l’IA agit seule, plus le risque de tomber dans le champ des décisions automatisées augmente[7]. Pour un SaaS B2B, cela peut concerner un moteur de scoring, un tri de tickets, une recommandation commerciale ou un blocage d’accès déclenché automatiquement. Il faut alors pouvoir démontrer où se situe la décision, qui la valide et si l’utilisateur dispose d’un contrôle réel.

La cybersécurité ajoute une contrainte de délai. En cas de violation de données personnelles, le RGPD impose une notification sous 72 heures[4]. Dans les cadres NIS2 et DORA, certaines obligations de signalement initial peuvent descendre à 24 heures[4]. Pour un SaaS qui branche un agent sur plusieurs connecteurs, ces délais imposent une traçabilité fine : logs, horodatage, inventaire des accès, preuve de confinement de l’incident.

L’angle faible des SaaS : la chaîne d’outils, pas le modèle

Le risque principal n’est pas seulement le modèle IA, mais la chaîne d’outils qu’on lui donne. Plus un agent peut écrire dans une base, interroger un CRM, ouvrir un ticket, envoyer un message ou appeler une API tierce, plus la surface d’attaque s’élargit. La note de juillet 2026 recommande précisément de réduire les accès au strict nécessaire, d’isoler les environnements et de classer les actions selon leur niveau de risque[7].

Cette approche rejoint les constats des autorités de cybersécurité : plusieurs avis CERT-FR publiés début juillet 2026 rappellent que des vulnérabilités touchent régulièrement des briques courantes comme GitLab, Traefik, Edge, Azure Linux ou des produits réseau majeurs[14]. Pour un SaaS, cela signifie que la sécurité ne dépend pas d’un seul composant, mais d’un empilement de dépendances, de permissions et de mises à jour.

L’actualité internationale va dans le même sens. Un rapport relayé cette semaine sur des applications dites « orientées militaire » montre que 64 % contenaient des composants tiers et que 40 % collectaient ou partageaient plus de données que déclaré[12]. Même si le contexte est différent, la leçon est directement transposable aux SaaS : plus la pile technique se complexifie, plus le risque de sur-collecte et de fuite augmente.

Enfin, le marché bouge vite. Une publication récente recensait 1 280 applications SaaS embarquant de l’IA, contre seulement 282 avec un usage déjà déployé dans l’étude citée[1]. Le chiffre illustre une accélération claire : l’IA s’invite partout, mais les garde-fous ne suivent pas au même rythme. C’est exactement le décalage que les équipes produit, sécurité et legal doivent combler.

Ce que les équipes produit et sécurité doivent faire maintenant

Le bon réflexe n’est pas de geler l’IA, mais de la rendre auditable, contenue et réversible. La note du CIANum cite explicitement un besoin de cloisonnement, de sandboxing, de validation humaine sur les actions sensibles et de bouton d’arrêt d’urgence[7]. Pour un SaaS, cela se traduit par une gouvernance simple : quels agents ont accès à quelles données, pendant combien de temps, et avec quel niveau d’autonomie.

Il faut aussi revoir la documentation RGPD. Dès qu’un agent utilise des données personnelles, le registre des traitements, l’analyse d’impact si nécessaire, les clauses de sous-traitance et les mécanismes d’information des utilisateurs doivent refléter la réalité technique. Un SaaS qui expose un assistant IA sans préciser la nature des données traitées, les tiers utilisés et les durées de conservation prend un risque inutile.

Le point le plus important est peut-être celui-ci : la conformité ne se joue pas seulement au moment de la collecte, mais au moment de l’action. Un agent qui résume un dossier n’a pas le même niveau de risque qu’un agent qui efface un enregistrement ou envoie une donnée vers un outil externe. C’est cette différence que le produit doit rendre visible, et que la sécurité doit pouvoir bloquer.

En pratique

  • Limiter l’autonomie par défaut : réserver les actions sensibles à une validation humaine, et n’autoriser qu’un périmètre d’outils strictement nécessaire[7].
  • Tracer chaque interaction : conserver des logs exploitables sur les données consultées, les appels aux services tiers et les actions déclenchées, pour tenir les obligations RGPD et les délais d’incident[4][7].
  • Isoler l’IA du cœur métier : utiliser des environnements cloisonnés, une mémoire à durée de vie courte et des permissions minimales pour réduire l’impact d’une fuite ou d’un comportement imprévu[7].