Par Olivia Dubois
·
18 juillet 2026
Un seul lien SaaS compromis peut ouvrir l’accès à plusieurs outils à la fois. Pour moi, le point à retenir est simple : le risque ne vient plus d’une application seule, mais des liens de confiance entre applications, navigateurs, API, extensions, sessions et fournisseurs.
En clair, je vois 3 problèmes :
Je retiens aussi 3 signaux à suivre tout de suite :
Les chiffres donnent le ton :
Pour moi, la réponse tient en peu de mots : voir, limiter, surveiller.
| Axe | Ce que je regarde | Ce que je fais |
|---|---|---|
| Accès | OAuth, API, sessions, extensions | Je réduis les droits |
| Visibilité | Shadow IT, Shadow AI, dépendances tierces | Je tiens un inventaire à jour |
| Détection | Jetons, webhooks, exports, activité navigateur | Je surveille et je coupe si besoin |
Si je devais résumer l’article en une phrase : plus les outils SaaS sont reliés, plus un accès normal peut devenir un point d’entrée discret si personne ne surveille les liens entre eux.
Dans une chaîne SaaS interconnectée, un simple consentement OAuth peut ouvrir un accès durable à plusieurs outils. Le vrai piège, c'est que cet accès continue souvent bien après l'autorisation de départ et passe sous le radar au quotidien.
Les attaquants s'appuient sur ce point aveugle en poussant des applications qui ont l'air légitimes. Une fois l'accès accordé, leurs actions passent par des plateformes connues et ressemblent à des appels API classiques ou à des exports autorisés. 83 % des applications SaaS sont utilisées sans validation formelle de l'IT [4]. Résultat : une grande part des accès reste hors du champ de contrôle des équipes sécurité. Ensuite, trois chemins reviennent le plus souvent : OAuth, le navigateur et les automatisations.
Le navigateur est un point d'entrée majeur. Une extension trop permissive peut lire le contenu des pages, accéder aux cookies et détourner des sessions. 56 extensions malveillantes ont récemment été identifiées sur le registre OpenVSX [1].
Le problème ne s'arrête pas là. Quand on ajoute des identités partagées et des sessions persistantes, le risque grimpe vite. Si un compte est compromis, l'attaquant peut souvent rebondir vers d'autres applications connectées. Et si une session reste valide, il peut continuer à agir sans nouvelle authentification, en particulier via des jetons de rafraîchissement encore actifs.
C'est justement ce qui rend la détection si délicate. L'activité ressemble à celle d'un utilisateur déjà connecté sur un outil autorisé. À première vue, rien ne saute aux yeux. La même relation de confiance s'étend aussi aux automatisations et aux échanges machine à machine.
Les API et les webhooks font circuler des données en continu entre outils. Sur le papier, c'est pratique. En pratique, une automatisation mal configurée entre deux services SaaS peut vite devenir un canal d'exfiltration. 63 % des fuites de données SaaS sont causées par des erreurs de configuration [4], et non par des attaques très avancées.
Le risque peut aussi venir du fournisseur lui-même, ou de ses sous-traitants. Un éditeur SaaS s'appuie parfois sur d'autres acteurs - par exemple des fournisseurs de modèles IA, des prestataires d'hébergement ou des partenaires d'intégration - que l'entreprise cliente n'a jamais évalués directement. Si l'un de ces maillons tombe, la relation de confiance déjà en place peut se transformer en porte d'entrée vers des données internes.
C'est là tout le problème : ces compromissions passent par des canaux légitimes, avec des identifiants valides et des flux de données attendus. Autrement dit, elles se fondent dans le décor. Mais elles ne sont pas invisibles pour autant. Elles laissent des traces nettes dans les permissions, les jetons et les journaux d'activité. On peut aussi repérer des signaux utiles dans les grants, les sessions et les dépendances fournisseurs.
Ces attaques ne passent pas en douce. Elles laissent des marques dans les autorisations, les journaux et les accès. Le but, ici, est simple : repérer les signaux qui méritent une vérification immédiate. Les points ci-dessous servent aussi de base aux contrôles présentés dans la section suivante.
Quand une autorisation OAuth donne bien plus d'accès que ce dont l'application a besoin, il faut se méfier. C'est souvent le signe de privilèges trop larges. Même logique du côté des jetons : si un jeton de rafraîchissement est utilisé à 03 h 00, heure de Paris, loin des horaires habituels, le signal est fort. On peut être face à une session compromise ou à une exfiltration automatisée.
Le problème, c'est que beaucoup d'entreprises ne voient même pas passer ce type d'indice. En France, seulement 21,6 % des entreprises utilisent une détection automatisée des secrets pour repérer les clés API ou les jetons exposés [1]. Dit autrement, une grande part de ces alertes reste sans traitement.
Une extension de navigateur ou d'IDE qui demande un accès large sans raison claire doit faire réagir tout de suite. Ce n'est pas un détail. C'est un point d'entrée à haut risque, et 18 % des organisations ne contrôlent pas ces vecteurs à forts privilèges [1].
Du côté des identités, certains comportements sortent du lot. Par exemple :
Ces cas doivent être analysés, surtout en lien avec le modèle de confiance de session évoqué plus haut. Et il y a un vieux problème qui continue de faire des dégâts : la réutilisation de mots de passe entre comptes personnels et comptes pro. On la banalise souvent, à tort.
Un webhook non documenté qui envoie des volumes de données anormaux vers un point de terminaison externe est un signal classique d'exfiltration possible. De la même façon, une automatisation qui manipule des données sensibles sans propriétaire métier identifié crée une exposition directe. Personne n'en répond, donc personne ne la surveille de près.
Côté fournisseur, certains manques doivent alerter sans attendre :
Ce genre de faiblesse montre qu'un maillon tiers peut céder et transmettre le problème au reste de la chaîne. En 2025, plus de 48 000 nouvelles CVE ont été publiées [3][1]. Ces signaux servent directement à alimenter les contrôles de gouvernance décrits dans la section suivante.
Réduire l'exposition SaaS tient à trois actions simples : cartographier en temps réel, limiter les accès et surveiller sans arrêt. Ces contrôles servent à traiter les abus OAuth, les extensions à risque et les automatisations peu lisibles.
Sans inventaire vivant, il n'y a pas de gouvernance solide. Cet inventaire doit couvrir les applications approuvées, le Shadow IT, le Shadow AI, les autorisations OAuth actives, les extensions, les API, les automatisations et les dépendances fournisseurs.
Chaque connexion devrait avoir un propriétaire identifié et un usage métier clair. Sinon, on se retrouve vite avec des accès qui traînent, des intégrations oubliées et personne pour répondre quand un problème arrive.
L'inventaire doit aussi inclure les dépendances indirectes du fournisseur : cloud, IA et sous-traitants. C'est ce niveau de cartographie qui permet d'évaluer le risque géopolitique réel d'une dépendance tierce [3][2].
Quand les connexions deviennent visibles, on peut enfin réduire les droits au strict minimum. Dit simplement : on arrête de donner un passe-partout quand une simple clé suffit.
Une fois l'inventaire en place, les politiques reposent sur des faits, pas sur des suppositions. Le principe est simple :
Cela vaut aussi pour la limitation des sessions persistantes et la révocation des grants trop permissifs sur les comptes sensibles.
Les autorisations doivent ensuite être revues à chaque dérive d'usage ou à chaque changement côté fournisseur. Un accès acceptable au départ peut devenir un point faible quelques semaines plus tard.
La gouvernance ne s'arrête pas au feu vert initial. Il faut surtout suivre les dérives de comportement, les changements dans la posture de sécurité du fournisseur et les dépendances critiques.
Quand un signal sort de l'ordinaire, l'équipe peut agir sans attendre : restreindre, corriger ou révoquer. C'est là que la surveillance continue prend tout son sens. Elle évite de découvrir un souci trop tard, une fois les dégâts déjà faits.
Ces contrôles posent la base d'une gouvernance automatisée, claire et utilisable au quotidien.
Passer de l'idée à l'action demande une plateforme capable de relier inventaire, politiques et détection. Pris séparément, ces contrôles aident. Mis ensemble, ils deviennent bien plus utiles. Leur intérêt dépend surtout d'un point simple : couvrir l'ensemble de l'écosystème SaaS. Avanoo réunit ces briques dans un seul cadre.
Avanoo croise les authentifications, l'activité du navigateur et les journaux proxy pour produire une cartographie en temps réel de l'usage SaaS et IA [8]. Et ce n'est pas limité aux applications déjà visibles dans l'inventaire.
La plateforme cartographie aussi les dépendances indirectes - sous-traitants, fournisseurs cloud et fournisseurs d'IA utilisés par chaque outil tiers - puis attribue un score de souveraineté en deux niveaux : niveau 1 pour le logiciel utilisé, niveau 2 pour les sous-traitants et l'infrastructure IA [7][2].
Pour les organisations françaises soumises au RGPD, à NIS2, à DORA ou à l'AI Act, cette documentation aide lors des audits et met plus vite en lumière les dépendances critiques.
La même approche s'étend ensuite à l'usage concret des données et du navigateur.
Avanoo détecte des comportements à risque que les outils de périmètre ne voient pas : envois et téléchargements de fichiers, activité du presse-papiers, glisser-déposer vers des applications non approuvées, ainsi que réutilisation de mots de passe entre applications [9][10].
Côté extensions de navigateur, Avanoo analyse les permissions demandées, la réputation de l'éditeur et les vulnérabilités connues sur Chrome, Edge et Firefox. La plateforme attribue ensuite une note de sécurité à chaque extension [5][6].
La chaîne d'approvisionnement SaaS ouvre des vecteurs d'attaque bien concrets. Pour réduire cette exposition, trois points comptent plus que le reste : un inventaire précis, le principe du moindre privilège et une surveillance continue.
Sur le terrain, cela se traduit par des contrôles appliqués aux principaux risques SaaS.
| Type de risque | Indicateur observable | Réponse de gouvernance | Support Avanoo |
|---|---|---|---|
| Extensions de navigateur à risque | Permissions excessives | Revue, approbation ou blocage | Inventaire multi-navigateur et note de sécurité par extension [5][6] |
| Dépendance fournisseur cachée | Sous-traitants ou IA tierces non documentés | Évaluation du risque tiers et des flux de données | Cartographie de la chaîne fournisseur et score de souveraineté [7] |
| Exfiltration utilisateur | Envois, téléchargements ou glisser-déposer vers des applications non gérées | Contrôles d'usage, sensibilisation, investigation | Surveillance comportementale et visibilité sur les flux de données [10] |
| Réutilisation d'identifiants | Réutilisation de mots de passe entre applications | Hygiène des identités et application de politiques | Détection des comportements à risque via l'extension de navigateur [9] |
| Shadow IT / Shadow AI | Applications ou connexions IA non référencées | Inventaire et approbation basée sur le risque | Cartographie en temps réel, corrélation des authentifications et des journaux proxy [8] |
::: faq
Pour prioriser les risques liés au SaaS et à l’IA, il faut partir du terrain: la criticité des processus métier d’un côté, et la carte complète des usages réels de l’autre.
L’idée est simple. Un outil n’est pas risqué seulement parce qu’il est nouveau ou peu connu. Il devient risqué quand il touche un processus clé, manipule des données sensibles, dépend d’autres briques, ou sort du cadre prévu. C’est là que le Shadow IT et la Shadow IA peuvent poser problème: ils s’installent vite, puis finissent par peser sur des activités qui comptent.
Commencez par repérer les fonctions critiques. En clair, celles dont l’arrêt, le mauvais fonctionnement ou la fuite de données aurait un impact direct sur l’activité.
Ensuite, dressez une cartographie nette de l’existant. Elle doit couvrir:
Puis évaluez chaque outil avec des critères concrets: sa criticité, les données traitées, le mode d’hébergement, les dépendances et la conformité. Ce croisement aide à voir, noir sur blanc, quels usages demandent une action immédiate et lesquels peuvent attendre.
Le bon réflexe consiste alors à traiter d’abord les risques élevés sur les processus critiques. Après ça, suivez les écarts dans un tableau de bord pour garder une vue nette sur les points à corriger, les zones sous contrôle et celles qui dérivent. :::
::: faq
En priorité, revoyez les accès aux applications SaaS sensibles, ainsi que ceux qui reposent sur des protocoles d’authentification faibles, dans une logique de Zero Trust.
Passez aussi en revue :
::: faq
Adoptez une surveillance continue et centralisée de votre écosystème SaaS pour repérer les comportements anormaux, les accès non autorisés et les erreurs de configuration.
Servez-vous d’outils de gouvernance SaaS pour recenser les applications et leurs intégrations, passer au crible les permissions accordées aux applications tierces, suivre en temps réel les indicateurs de compromission et contrôler à intervalles réguliers le score de risque des fournisseurs ainsi que leurs certifications. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois est Shadow AI Expert et Chief AI Officer chez Avanoo. Diplômée d'HEC Paris et ancienne consultante chez BCG, elle accompagne les entreprises dans la détection et la gouvernance du Shadow AI et du Shadow IT.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
