SaaS-mageddon : pourquoi vos fournisseurs deviennent votre

En huit mois, le même groupe a percé Instructure trois fois. Pendant ce temps, des centaines d'écoles signent des contrats SaaS sans même savoir qui héberge leurs données. On a déporté la valeur business dans le cloud sans déporter la responsabilité cyber. Le résultat est désormais sous nos yeux : la fuite n'est plus un événement, c'est un service récurrent.

Le problème n'est plus le périmètre, c'est l'agrégation

Pendant vingt ans, les RSSI ont durci des périmètres. Pare-feu, EDR, SIEM, ZTNA — tout ce qu'il faut pour contrôler ce qui entre et sort. Très bien. Sauf qu'aujourd'hui, 70 % de la valeur business d'une organisation moyenne ne réside plus derrière ce périmètre. Elle est chez Salesforce, chez Workday, chez Notion, chez Instructure, chez n'importe quel fournisseur SaaS dont le contrat tient sur une page et dont le SOC 2 Type II n'a jamais été lu en interne.

Le problème n'est même plus que ces fournisseurs soient mal sécurisés individuellement. Le problème, c'est qu'ils agrègent. Quand ShinyHunters compromet Instructure, ils ne touchent pas une école — ils touchent 9 000 écoles d'un coup. Quand un opérateur Salesforce se fait piéger via OAuth, ce ne sont pas dix entreprises qui sont exposées, c'est l'ensemble du portefeuille du fournisseur qui passe en ligne de fuite potentielle. L'économie SaaS a créé des points de concentration de risque dont l'ampleur n'avait pas d'équivalent dans le monde on-premise.

Le SOC 2 ne vous sauvera pas

Je vois passer des dizaines de questionnaires de tiers chaque mois en mission. La grande majorité demande la même chose : "Êtes-vous conforme à SOC 2 ? Avez-vous ISO 27001 ? Faites-vous des pentests annuels ?". Cases cochées, contrat signé, on passe à la suite. Personne ne vérifie ce que ces certifications couvrent réellement.

SOC 2 Type II atteste qu'un fournisseur a mis en place les contrôles qu'il a lui-même définis et qu'il les applique depuis quelques mois. Ça ne dit rien sur la qualité des contrôles, ni sur leur pertinence face à un attaquant motivé. Un fournisseur peut être SOC 2 et ne pas appliquer le MFA sur ses comptes admin. C'est légal, c'est conforme, c'est documenté. Et ça finit par 3,65 To de données sur un site de leak.

La même critique vaut pour ISO 27001. Le standard est utile pour structurer un SMSI, mais il ne mesure pas la robustesse face à un attaquant moderne. Combien de certifiés ISO 27001 ont été compromis ces deux dernières années ? Faites le compte. La liste est longue.

Le pattern OAuth, la nouvelle porte d'entrée préférée

Trois des plus grosses opérations cybercriminelles de ces derniers mois — celles attribuées à ShinyHunters — partagent un même vecteur : l'abus de l'écosystème Salesforce via des tokens OAuth volés ou détournés. Le mécanisme est connu, documenté, simple à comprendre. Et pourtant, dans 90 % des organisations que j'audite, la gouvernance des intégrations OAuth est inexistante.

Concrètement : combien de tokens OAuth actifs avez-vous dans votre tenant Microsoft 365, Google Workspace ou Salesforce ? À quels scopes donnent-ils accès ? Quand ont-ils été créés ? Par qui ? Sont-ils encore utilisés ? Une grande partie des fuites SaaS actuelles n'exploite pas une vulnérabilité technique mais une dette de gouvernance : un token créé en 2022 pour une intégration de POC oubliée, jamais révoqué, qui donne accès à l'intégralité des objets Salesforce d'une organisation.

C'est exactement le genre de chose que personne ne pense à auditer. Et c'est exactement le genre de chose qui apparaît dans les chronologies post-incident des grosses fuites SaaS de 2025-2026.

Ce qu'il faut commencer à faire maintenant

Cartographier. Avant tout. Combien d'applications SaaS utilisez-vous réellement ? Pas combien vous avez de contrats — combien d'applications. Dans une PME de 200 personnes que j'ai auditée récemment, la DSI déclarait 18 applications SaaS. Le scan effectif via les logs de proxy en a remonté 147. Le shadow SaaS est partout, et chaque application non gouvernée est un canal d'exfiltration potentiel.

Ensuite, gouverner les intégrations. Pas seulement les comptes utilisateurs : les tokens machine, les service accounts, les OAuth apps. Avec une vraie procédure de revue trimestrielle, et une révocation par défaut au bout de X mois sans usage. Microsoft 365 propose désormais des reports natifs sur les applications OAuth actives ; Salesforce aussi. Personne ne les lit.

Tester la résilience, pas la conformité

Sortez du cycle questionnaire-checklist-audit. Demandez à vos fournisseurs critiques : "Que se passe-t-il pour mes données si vous êtes ransomé demain ? Avez-vous un plan de continuité testé ? Combien de temps mes données seraient-elles indisponibles ? Sous quelle forme me les restitueriez-vous ?" Ces questions n'apparaissent jamais dans les RFP standardisés. Elles devraient.

Prévoir le pire

Vos meilleurs fournisseurs SaaS vont être compromis. Pas peut-être : sûrement. La question est de savoir comment vous, en tant qu'organisation cliente, allez réagir le jour où ça arrivera. Avez-vous une procédure de réponse à un incident chez un fournisseur ? Avez-vous identifié les communications à envoyer à vos propres parties prenantes ? Savez-vous quoi répondre à vos clients qui demanderont si leurs données étaient stockées chez ce fournisseur ?

La plupart des organisations découvrent ces questions le lundi matin, dans l'urgence, en lisant un communiqué de presse de leur fournisseur. C'est beaucoup trop tard.

Conclusion

Le SaaS-mageddon n'est pas un événement futur. Il est en cours, par vagues. Instructure trois fois, Snowflake, MOVEit, Okta, Cushman & Wakefield, des dizaines d'autres dans les douze derniers mois. Chaque vague emporte des centaines, parfois des milliers d'organisations clientes qui découvrent rétroactivement la dépendance qu'elles avaient construite.

L'industrie cyber n'a pas encore digéré ce changement de paradigme. Les RSSI sont mesurés sur des KPI hérités de l'ère on-premise : disponibilité du SIEM, taux de couverture EDR, MTTR sur les incidents internes. Personne n'est mesuré sur la capacité à anticiper, contenir et récupérer d'une compromission fournisseur — pourtant, c'est devenu le scénario de risque numéro un pour la plupart des organisations.

La bonne nouvelle, c'est qu'il y a encore de la marge pour faire mieux. La mauvaise, c'est que ça commence par accepter que la sécurité périmétrique classique ne suffit pas, et que cartographier ses fournisseurs SaaS est aussi important que cartographier son réseau interne. Beaucoup d'entreprises n'ont pas encore fait ce saut conceptuel. Elles le feront — dans l'ordre, ou dans la panique.

SaaS et chaîne de valeur : comment un fournisseur devient un vecteur d'attaque

Le modèle SaaS a transformé la gestion des risques cyber : vos données ne sont plus dans vos serveurs, elles sont chez une constellation de fournisseurs qui sont eux-mêmes clients d'autres fournisseurs. Quand un éditeur comme Instructure est compromis trois fois en huit mois, ce ne sont pas ses serveurs qui brûlent — ce sont les données de millions d'élèves et d'enseignants qui circulent sur les forums de revente de données.

Cartographie des risques SaaS : ce que les RSSI ne font pas encore

La majorité des organisations ont une visibilité médiocre sur leur portefeuille SaaS réel. La DSI connaît les solutions validées ; le RSSI connaît les contrats signés. Mais les métiers utilisent en moyenne 2 à 4 fois plus de solutions SaaS que ce que la DSI recense. Ce shadow IT SaaS est la principale lacune de la gestion des risques fournisseurs en 2026.

Construire une cartographie SaaS exhaustive requiert :

• Analyse des flux DNS et proxy : les requêtes DNS sortantes révèlent l'ensemble des domaines contactés par vos postes, y compris les SaaS non référencés. Un proxy HTTP avec journalisation complète est indispensable.
• Analyse des achats IT (cartes de crédit entreprise) : les abonnements SaaS sont souvent payés directement par les équipes métier avec des cartes de crédit dédiées. Un audit des dépenses IT révèle fréquemment des dizaines de services non référencés.
• Questionnaire auto-déclaratif par département : demandez à chaque département de lister ses outils numériques. La comparaison avec l'inventaire DSI révèle les écarts.
• CASB (Cloud Access Security Broker) : pour les organisations de taille moyenne et grande, un CASB permet la découverte automatique et la classification des services SaaS accédés depuis le réseau de l'entreprise.

Évaluation de la maturité sécurité des fournisseurs SaaS

Une fois votre inventaire SaaS établi, l'étape suivante est l'évaluation de la maturité sécurité de chaque fournisseur. Voici un framework pragmatique en 4 niveaux selon la criticité :

• Fournisseurs critiques (données sensibles, accès à vos systèmes) : exigez un questionnaire de sécurité détaillé (CAIQ, SIG), les résultats de leur dernier test de pénétration, leur certification ISO 27001 ou SOC 2 Type II valide, et leurs politiques de notification d'incidents. Revue annuelle minimum.
• Fournisseurs importants (données internes, mais pas de données clients ou personnelles) : vérifiez les certifications (ISO 27001, SOC 2), demandez leur politique de gestion des incidents et leur SLA de disponibilité. Revue tous les 2 ans.
• Fournisseurs standards (outils de productivité, aucune donnée sensible) : vérification des certifications en ligne, lecture des conditions générales et de la politique de confidentialité. Revue tous les 3 ans ou lors d'un incident public.
• Shadow IT identifié : décision de régularisation (validation et intégration au portefeuille officiel), de migration vers une alternative approuvée, ou d'interdiction formelle avec communication aux équipes.

Clauses contractuelles SaaS incontournables pour les RSSI

Le contrat SaaS est votre dernière ligne de défense juridique. Ces clauses doivent être présentes et négociées avant la signature :

• Notification d'incident de sécurité sous 72h : aligné sur les obligations RGPD. Certains éditeurs proposent 30 jours dans leurs CGV standard — inacceptable pour les données personnelles.
• Droit d'audit : vous devez pouvoir mandater un auditeur tiers pour évaluer les mesures de sécurité de l'éditeur, ou à défaut avoir accès aux rapports d'audit tiers (SOC 2 Type II, résultats de pentest).
• Localisation des données : spécifiez explicitement que vos données doivent être hébergées dans l'UE/EEE. Les transferts hors UE doivent être couverts par des mécanismes de protection adéquats (clauses contractuelles types de la Commission européenne).
• Portabilité et restitution des données : définissez le format de restitution de vos données en fin de contrat et le délai accordé pour les exporter. Certains éditeurs rendent la migration prohibitivement difficile sans clause contractuelle explicite.
• Garanties de continuité : que se passe-t-il si l'éditeur fait faillite, est racheté, ou cesse son activité ? Une clause d'escrow du code source ou un droit d'accès aux données pendant une période de transition est essentiel pour les fournisseurs critiques.

Foire aux questions — Risques SaaS et fournisseurs

Comment gérer un incident de sécurité chez un fournisseur SaaS critique ?

Dès la notification d'un incident (ou sa découverte dans la presse), activez votre procédure de gestion de crise fournisseur : évaluez l'exposition de vos données, contactez le fournisseur pour obtenir une communication officielle, documentez les informations reçues et leur délai, évaluez l'obligation de notification CNIL (si des données personnelles sont concernées), et renforcez temporairement la surveillance des accès à l'outil concerné. Si le contrat inclut une clause de notification sous 72h et que l'éditeur ne l'a pas respectée, documentez le manquement — il peut ouvrir droit à des pénalités contractuelles.

Le RGPD impose-t-il des exigences sur les fournisseurs SaaS ?

Oui. Tout fournisseur SaaS qui traite des données personnelles pour votre compte est un "sous-traitant" au sens du RGPD (article 28). Vous devez avoir conclu un contrat de traitement de données (Data Processing Agreement / DPA) avec ce fournisseur, précisant les finalités du traitement, les mesures de sécurité appliquées, les obligations en cas d'incident et les conditions de sous-traitance ultérieure. L'absence de DPA avec un fournisseur SaaS traitant des données personnelles est une non-conformité RGPD exposant votre organisation à des sanctions de la CNIL.