Le SaaS – Software as a Service – a conquis toutes les strates de l’entreprise. En quelques années, il est devenu l’infrastructure invisible du quotidien : messagerie, stockage, bureautique, relation client, RH, facturation, support, sécurité. C’est une révolution discrète, douce, presque invisible. Et pourtant, cette dépendance massive à des services cloud tiers, souvent pilotés à distance et interconnectés entre eux, pose une série de risques que peu d’organisations prennent encore au sérieux.
“Le vrai risque SaaS, c’est ce qu’on ne contrôle plus”
La première vulnérabilité ne se trouve pas dans le code. Elle réside dans ce que l’on ne contrôle pas. L’essence même du SaaS repose sur la délégation : on ne gère plus un logiciel, on consomme un service. On accède, on utilise, on synchronise. Mais on ne maîtrise plus ni l’hébergement, ni les logs, ni parfois même la gestion des identités. Or, cette dilution du périmètre fait de chaque jeton d’accès, de chaque connecteur OAuth, un potentiel cheval de Troie.
Les attaquants l’ont compris. En 2024, plusieurs incidents majeurs ont révélé que des campagnes de compromission ne ciblaient plus directement les entreprises, mais les liens entre applications SaaS. Un attaquant n’a plus besoin de franchir les pare-feux ou de casser les mots de passe : il peut réutiliser un accès tiers, détourner un flux OAuth, ou injecter du code dans un connecteur mal sécurisé. Le tout en restant sous le radar des outils de sécurité classiques.
Ce mode d’attaque, silencieux et structurel, rend les détections plus difficiles. Peu d’entreprises auditent régulièrement leurs intégrations SaaS. Peu vérifient les jetons d’accès encore actifs, ou les connexions autorisées vers d’autres services. La plupart ignorent même combien d’applications SaaS sont réellement utilisées dans leur organisation.
C’est le phénomène du SaaS Sprawl – la prolifération incontrôlée de services cloud. Chaque département, chaque équipe, chaque projet ajoute un outil. Une plateforme de gestion de projet ici, une app marketing là, un connecteur RH, un tableau de bord partagé… et très vite, l’entreprise ne sait plus ce qu’elle expose, ni à qui.
Le problème n’est pas l’usage. Il est la perte de visibilité. Quand personne ne supervise l’ajout d’un nouvel outil, personne ne vérifie non plus les droits accordés, les données partagées, ni les flux sortants activés. Une synchronisation vers Google Sheets, un webhook sur Zapier, un partage Dropbox avec un ancien partenaire… autant de portes d’entrée, souvent actives, parfois oubliées.
“L’attaque ne vient plus de l’extérieur. Elle rebondit de l’intérieur.”
L’un des incidents marquants de 2025 concerne une entreprise technologique qui a vu ses données stratégiques exfiltrées via une app d’automatisation oubliée. L’application, connectée à un CRM cloud, déclenchait un export CSV quotidien vers un compte externe sur un autre SaaS. Ni le RSSI ni la DSI n’étaient informés. L’automatisation avait été créée trois ans plus tôt par un prestataire, jamais désactivée. Pendant près de six mois, les informations commerciales sensibles ont transité par ce canal non surveillé.
Ce n’est pas un cas isolé. Les intégrations entre SaaS sont rarement soumises à des cycles de revue. Une fois qu’un accès est accordé, il reste actif tant qu’on ne le révoque pas. Et bien souvent, personne n’a la responsabilité formelle de le faire. Le confort d’usage – “ça fonctionne” – prime sur la gouvernance. Mais ce confort crée une exposition massive, continue, et peu détectée.
Les applications SaaS ne sont pas toujours alignées avec les exigences réglementaires non plus. Dans certains cas, l’entreprise ignore où sont stockées ses données, combien de sous-traitants y ont accès, ou quel niveau de chiffrement est réellement appliqué. La chaîne de sous-traitance, pourtant au cœur du RGPD, reste floue. Et lorsqu’un incident survient, c’est vers l’entreprise cliente que se tournent les régulateurs.
Car la responsabilité juridique, elle, ne se délègue pas. Si un SaaS perd vos données, vous êtes responsable devant vos clients. Si une faille dans une API expose des données personnelles, c’est à vous qu’il revient de notifier la CNIL. Et si une application cesse brutalement de fonctionner, la clause de SLA ne restaurera pas votre image de marque.
La contractualisation avec un éditeur SaaS est souvent déséquilibrée. Les CGU évoluent sans concertation, les audits sont rarement permis, les mécanismes de sauvegarde sont flous. Certaines entreprises découvrent à leurs dépens qu’elles ne peuvent pas récupérer leurs données en cas de résiliation ou de litige. D’autres réalisent, trop tard, qu’elles ne peuvent pas restaurer un état antérieur de leur service.
“Le SaaS a déplacé le risque sans l’annuler. Et trop souvent, sans le documenter.”
Face à cela, plusieurs mouvements émergent. Le premier consiste à reprendre la main sur la cartographie. Il ne s’agit pas de tout interdire, mais de visualiser. Des outils comme les SaaS Security Posture Management (SSPM) permettent de détecter les services utilisés, d’identifier les comptes dormants, les connexions à risque, les données exposées. D’autres proposent une gestion centralisée des identités, pour harmoniser les droits entre SaaS.
Mais la technologie ne suffit pas. Il faut une stratégie. Impliquer les métiers. Créer une gouvernance transverse entre DSI, RSSI, DPO. Intégrer les SaaS dans les comités de sécurité, dans les audits, dans les plans de continuité d’activité. Former les équipes aux risques des intégrations mal maîtrisées. Et surtout, documenter chaque application critique : qui l’utilise, quelles données elle traite, comment elle est sécurisée, et quel plan de secours est prévu.
Une autre piste, moins abordée, touche à la diversification. Ne pas tout mettre sur un seul fournisseur. Ne pas relier tous les outils à une même identité unique. Ne pas tout synchroniser en temps réel. Accepter que certaines données sensibles ne doivent pas transiter par certains canaux. Penser en termes de cloisonnement, de limitation des droits, de journalisation.
Certains secteurs vont plus loin. Dans la santé, la finance, la défense, le recours à des SaaS est désormais encadré par des processus d’homologation. Les éditeurs doivent démontrer leur conformité à des référentiels exigeants. L’accès à des données sensibles passe par des audits de code, des tests d’intrusion, des certifications.
Ce modèle peut inspirer d’autres entreprises. Non pas pour tout verrouiller, mais pour mieux choisir. Adopter un SaaS, ce n’est pas seulement comparer les fonctions. C’est accepter une dépendance. Il faut en mesurer les impacts, prévoir des alternatives, penser la sortie de crise avant qu’elle ne survienne.
Le débat sur la souveraineté numérique se rejoue aussi ici. Peut-on se reposer sur des plateformes étrangères, peu transparentes, parfois soumises à des lois extraterritoriales ? Faut-il soutenir un écosystème de SaaS européens ? La question n’est pas idéologique. Elle est stratégique. Le contrôle des données, aujourd’hui, conditionne la résilience de demain.
Enfin, il y a la question humaine. Beaucoup d’attaques SaaS débutent par une erreur d’usage : lien mal partagé, jeton copié, mauvais paramétrage, absence de double authentification. Former les utilisateurs, leur donner les bons réflexes, les associer à la gestion du risque : c’est une priorité aussi urgente que l’achat d’un outil.
Le SaaS a changé la façon dont les entreprises travaillent. Il a aussi changé la façon dont elles sont exposées. La simplicité a un prix. L’accessibilité a un revers. Et la fluidité peut devenir une vulnérabilité.
À l’heure où la plupart des fonctions critiques reposent sur des services cloud externes, la sécurité ne peut plus se limiter au système d’information traditionnel. Elle doit intégrer, au cœur de sa stratégie, l’écosystème SaaS tout entier.
Ce n’est pas une menace abstraite. C’est une surface d’attaque réelle, active, mouvante. Et c’est aujourd’hui l’une des moins surveillées.
