Par Tanguy Duthion
·
6 juin 2026
Si je dois résumer l’article en une phrase : sans 9 rapports SaaS, je n’ai pas de preuves solides en audit.
En clair, je dois suivre trois blocs :
Je retiens aussi 3 repères simples :
Autre point fort : l’article ne parle pas de théorie. Il liste les preuves à sortir, les champs à garder, les fréquences de revue, et les cas à surveiller en priorité, comme les comptes orphelins, le MFA désactivé ou une app non validée avec 15 utilisateurs actifs ou plus.
En bref : si je veux éviter de reconstruire mes dossiers au dernier moment, je dois garder un cycle simple, daté et traçable sur 9 rapports.
Comparaison rapide :
| Cadre | Ce que je dois prouver | Rapports à sortir en priorité |
|---|---|---|
| RGPD | accès aux données personnelles, retrait, demandes de droits | inventaire des comptes, revue d’accès, journaux + demandes |
| NIS2 | authentifications, changements, incidents | logs d’accès, historique de configuration, registre d’incidents |
| DORA | dépendances SaaS, niveau de criticité, continuité | registre fournisseurs, Shadow IT, licences + continuité |
La suite de l’article sert donc de checklist terrain : quoi exporter, quoi revoir, et quoi archiver pour être prêt le jour du contrôle.
Voici les trois rapports RGPD à sortir en premier pour prouver l'accès, la revue et la suppression des droits. Ils s'inscrivent dans la logique d'obligation de responsabilité du RGPD : avoir une bonne politique ne suffit pas. Il faut aussi pouvoir montrer, à tout moment, une preuve technique claire.
Ce rapport répond à une question très directe : qui a accès à quoi, et cet accès a-t-il encore une raison d'être ? Il doit couvrir l'ensemble des outils SaaS qui traitent des données personnelles et inclure au minimum les champs ci-dessous.
| Champ | Détail attendu |
|---|---|
| Identité | Nom, identifiant unique, e-mail professionnel |
| Organisation | Équipe, département, manager |
| Contexte juridique | Entité juridique |
| Application | Nom, catégorie (CRM, RH, documentation…) |
| Accès | Rôle, niveau de privilège (administrateur, utilisateur, administrateur de facturation), type de licence, méthode d'authentification |
| Cycle de vie | Date de création, date de désactivation, dernier login |
| Statut | Actif, inactif, désactivé, en cours de départ |
En pratique, il faut regarder d'abord les comptes dormants, orphelins et partagés. Il faut aussi faire le lien entre les départs RH et les comptes SaaS sous 24 à 48 h. D'après les données disponibles, 60 % des entreprises ratent leurs audits à cause d'une gouvernance SaaS trop faible [1].
Cet inventaire sert de point de départ à chaque recertification.
Une revue d'accès ne sert pas à grand-chose si elle ne laisse pas une preuve de retrait horodatée. À chaque cycle de recertification, il faut enregistrer l'accès examiné, la décision du réviseur - validation ou retrait - , l'action de remédiation menée, la référence du ticket lié et la date de clôture.
La différence entre un rapport utile en audit et un simple tableau de suivi tient dans la traçabilité de la remédiation. Si un accès est réduit au lieu d'être supprimé, le rapport doit indiquer le nouveau rôle attribué et confirmer que les permissions restantes ont bien été approuvées.
Les preuves de retrait peuvent prendre plusieurs formes :
Ces éléments doivent être gardés pendant une durée fixée par la politique interne. Une cible fréquente tourne autour de 2 ans pour couvrir les contrôles et audits. Il faut aussi conserver ces preuves dans un format protégé contre toute modification par les personnes concernées.
Le troisième rapport fait le lien entre les preuves techniques et les demandes d'exercice des droits.
Ce rapport rassemble deux flux qui vont ensemble : les journaux d'activité et le suivi des demandes d'exercice des droits.
Journaux d'activité - champs à tracer :
| Champ | Détail attendu |
|---|---|
| Horodatage | Date et heure de l'événement |
| Auteur | Identifiant de l'utilisateur |
| Nature de l'opération | Consultation, export, modification, suppression |
| Référence des données | Données personnelles concernées |
| Résultat | Succès ou échec |
La CNIL recommande de journaliser au minimum les actions de création, consultation, partage, modification et suppression, avec une durée de conservation comprise entre 6 mois et 1 an, qui peut aller jusqu'à 3 ans si la finalité le justifie et si cette prolongation est documentée [2].
Suivi des demandes d'exercice des droits - champs à tracer :
| Champ | Détail attendu |
|---|---|
| Date de réception | Date d'entrée de la demande |
| Date de traitement | Date de prise en charge |
| Date de clôture | Date de fermeture confirmée |
| Responsable | Responsable du traitement |
| Résultat | Action réalisée dans le SaaS : suppression, anonymisation ou désactivation du compte |
Chaque demande d'effacement doit pouvoir être reliée à l'action menée dans chaque application concernée. C'est ce chaînage qui rend le rapport exploitable lors d'un contrôle.
Avanoo peut centraliser ces preuves et garder l'inventaire à jour.
Ces trois rapports servent à suivre les accès, les changements de configuration et les incidents exigés par NIS2. Ensemble, ils couvrent la preuve, l'analyse et la réponse.
Tous les horodatages doivent suivre le format JJ/MM/AAAA HH:MM:SS, avec le fuseau Europe/Paris.
Ce rapport regroupe, pour chaque SaaS critique, tous les événements liés à l'identité et aux accès à privilèges. On parle ici des connexions réussies ou échouées, du MFA, des changements de rôles et de privilèges, des créations ou suppressions de comptes, ainsi que des actions sensibles menées par des administrateurs.
Chaque événement doit contenir :
Les logs doivent être stockés en lecture seule, avec une durée de conservation alignée sur la politique interne et les recommandations du secteur.
La revue suit un rythme clair : alertes automatisées chaque jour sur les anomalies, revue humaine hebdomadaire des activités administrateur, puis analyse mensuelle des tendances. Les cas à surveiller en priorité sont assez parlants : une connexion en dehors des horaires habituels, la désactivation du MFA sur un SaaS critique, ou la création d'un compte administrateur sans ticket IT associé.
Avanoo peut centraliser ces événements issus de plusieurs fournisseurs SaaS et IdP dans une vue unifiée, ce qui simplifie le travail des équipes sécurité.
Ces logs servent aussi à expliquer les écarts de configuration.
Ce rapport trace toutes les modifications qui touchent la posture de sécurité d'un SaaS : désactivation du MFA, changement de fournisseur SSO, assouplissement des règles de partage, modification des paramètres de rétention, ou mise à jour des modèles de rôles.
| Champ | Détail attendu |
|---|---|
| Application | Nom et catégorie du SaaS |
| Élément modifié | MFA, SSO, partage, rétention, rôles… |
| Ancienne / nouvelle valeur | Valeur avant et après le changement |
| Horodatage | Format JJ/MM/AAAA HH:MM:SS, Europe/Paris |
| Auteur | Identifiant admin, automatisation ou mise à jour de l'éditeur |
| Justification | Référence ticket, approbation, évaluation des risques |
Le but est simple : comparer chaque configuration à une référence approuvée par l'équipe sécurité. Si un écart apparaît, il doit rester non conforme tant qu'il n'a pas reçu une validation formelle. Il faut aussi suivre les changements silencieux appliqués par l'éditeur SaaS. C'est souvent là que les ennuis commencent : rien ne saute aux yeux, mais la posture de sécurité a déjà bougé.
Quand un incident survient, le registre permet de poser les faits et de tracer les notifications.
C'est le rapport qui alimente directement les obligations de notification NIS2 : alerte précoce sous 24 heures, notification détaillée sous 72 heures, rapport final sous un mois. Pour tenir ces délais, le registre doit être rempli dès la détection, pas une fois l'incident terminé.
La structure minimale doit inclure l'identifiant unique de l'incident, son type - indisponibilité, compromission de compte, fuite de données, erreur de configuration, panne fournisseur - , le ou les SaaS concernés, les dates et heures de début et de fin, le temps de détection, le niveau de sévérité, le nombre d'utilisateurs ou de services touchés, ainsi que toute exposition suspectée ou confirmée de données personnelles. Il faut aussi tracer les notifications internes, externes et réglementaires avec horodatage et référence.
Le registre doit être alimenté dès la détection et relié à l'outil de gestion des tickets pour automatiser l'escalade. Un indicateur simple à suivre lors de la revue mensuelle est le taux d'incidents contenus. C'est un bon moyen de voir si la réponse fonctionne sur le terrain, pas seulement sur le papier.
Après les accès, les changements et les incidents, il faut encore suivre les fournisseurs, les apps non validées et les licences. Cette partie porte sur les tiers, le Shadow IT et la gestion des licences.
DORA impose un registre des prestataires SaaS tiers, structuré selon les champs EBA. C’est la base pour qualifier les fournisseurs critiques.
Pour chaque fournisseur SaaS, le registre doit indiquer le nom légal, ainsi que le SIREN ou le SIRET si c’est applicable. Il doit aussi préciser la fonction métier couverte, les catégories de données traitées - personnelles, sensibles ou financières - , la localisation de l’hébergement, en France, dans l’UE/EEE ou hors UE, ainsi que les sous-traitants et sous-processeurs.
Ajoutez aussi les certifications de sécurité, comme ISO 27001, SOC 2 ou HDS, et les clauses contractuelles clés. En pratique, cela comprend le RTO/RPO, les délais de notification d’incident, le droit d’audit et les conditions de sortie.
Le point central du dispositif, c’est la classification de criticité. Dans la plupart des cas, une grille à trois niveaux suffit :
| Niveau | Critères principaux | Implications |
|---|---|---|
| Critique | Supporte une activité critique ; une panne prolongée impacte clients ou régulateurs | Due diligence approfondie, clauses contractuelles renforcées, stratégie de sortie documentée |
| Important | Supporte des processus clés avec repli manuel possible | Revue périodique, SLA contractuels, suivi des incidents |
| Non critique | Outils support à faible impact | Inventaire minimal, revue annuelle |
La justification du niveau de criticité doit être validée par les fonctions Risques, Sécurité et Conformité. Elle doit aussi être documentée pour chaque SaaS, noir sur blanc. Revoyez les fournisseurs à chaque événement majeur, puis selon un rythme simple : tous les trimestres pour les fournisseurs critiques, une fois par an pour les autres.
Une bonne gouvernance des tiers aide aussi à freiner l’arrivée d’applications non approuvées.
Les contrôles manuels - enquêtes, audits ponctuels, logs de pare-feu - passent souvent à côté des SaaS web, des outils gratuits et des services d’IA grand public. Résultat : des données partent hors du cadre prévu.
Le rapport doit lister chaque application détectée avec, au minimum, son responsable métier, son statut, le nombre d’utilisateurs actifs, la catégorie de données en jeu, le canal d’accès, la région d’hébergement et le niveau de risque.
Le statut peut prendre plusieurs formes :
La priorité de remédiation se calcule en croisant le risque et le volume. Toute application non approuvée avec 15 utilisateurs actifs ou plus doit passer en priorité P1. À l’inverse, un outil non approuvé peut être clôturé dès qu’il retombe à zéro utilisateur actif.
Avanoo automatise cette découverte en se connectant aux fournisseurs d’identité et aux systèmes de dépenses, détectant les nouveaux outils dès qu’un collaborateur s’inscrit avec une identité professionnelle, calculant un score de risque et cartographiant les doublons avec les outils déjà approuvés [1].
Une fois ces usages recensés, le même suivi aide à couper les licences qui dorment.
Ce rapport relie deux sujets qu’on sépare souvent à tort : les coûts et la continuité. Il faut suivre quelques métriques simples : le nombre de licences achetées par rapport au nombre de licences utilisées, le taux d’utilisation en %, les comptes inactifs depuis 90 jours, et les comptes orphelins liés à des licences payantes, c’est-à-dire sans responsable identifié ou rattachés à un collaborateur parti.
L’impact financier doit être présenté en euros, avec les usages français. Affichez le coût par utilisateur et par direction. Dit autrement, il faut relier la gestion technique des licences aux choix budgétaires, sinon le rapport reste théorique.
Pour les fournisseurs critiques, ajoutez aussi trois points dans la lecture de continuité : la réserve de licences, la géo-redondance et le support premium.
Après cette checklist, gardez une règle simple en tête : chaque trimestre, les preuves doivent couvrir trois sujets précis - les accès, les changements et les tiers. Au total, neuf rapports permettent de couvrir ces trois axes.
| Axe | Rapports |
|---|---|
| Accès | Inventaire, revues, retrait |
| Configuration | Logs, changements, incidents |
| Tiers | Fournisseurs, Shadow IT, licences |
En audit, ce qui compte, ce n’est pas d’empiler des fichiers. La valeur vient de la régularité. Un rapport trimestriel daté, avec un responsable clairement identifié, des décisions tracées et une clôture prouvée, correspond à ce que les auditeurs attendent : un cycle de contrôle récurrent, pas une collecte ponctuelle de données.
Pour sortir ces rapports sans ressaisie manuelle, une plateforme comme Avanoo centralise ces preuves et rend la revue trimestrielle plus simple.
Le point clé ne change pas : il faut prouver, chaque trimestre, qui accède à quoi, ce qui change, ce qui est retiré et quels tiers exposent le risque.
::: faq
Priorisez d’abord les rapports qui montrent les risques immédiats et l’état de gouvernance de votre écosystème SaaS.
Commencez par les rapports sur les menaces actives et les découvertes à haut risque, en visant surtout les applications qui ont le plus d’utilisateurs actifs. C’est souvent là que l’exposition est la plus forte.
Ensuite, passez aux rapports de gouvernance en attente pour repérer les applications non approuvées ou non inventoriées. L’objectif est simple : reprendre la main sur le Shadow IT avant qu’il ne s’installe davantage. :::
::: faq
Pour les incidents de sécurité, les délais sont stricts.
On ne parle donc pas d’un simple exercice administratif. En cas d’incident, le compte à rebours démarre presque tout de suite. Et sur les systèmes critiques, il faut aussi vérifier le terrain en continu, pas juste sur le papier. :::
::: faq
Gardez un historique complet des actions liées à vos applications SaaS. Avanoo suit le cycle de vie de chaque accès, depuis son adoption jusqu’à sa désactivation.
En cas d’audit ou de contrôle, vous pouvez générer des rapports PDF ou CSV prêts à l’emploi. Ils servent de preuve du retrait des accès et de l’application de vos politiques, afin de répondre aux exigences RGPD, NIS2 et DORA. :::
Co-fondateur & CEO
Tanguy Duthion est co-fondateur et CEO d'Avanoo. Ancien de Google et d'Asana, il a fondé Avanoo pour aider les organisations à reprendre la main sur leurs usages SaaS et IA.
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é.
