À quelle fréquence faire auditer son SaaS

« Une fois par an » est la réponse habituelle. Elle est commode, elle correspond au cycle budgétaire et aux attentes des questionnaires clients. Elle n’est pas fausse, mais elle décrit mal la réalité : la fréquence pertinente dépend moins du calendrier que du rythme auquel votre application change.

Le vrai critère : le rythme de changement du code sensible

Une plateforme dont le socle d’authentification et le modèle de permissions n’ont pas bougé depuis dix-huit mois ne présente pas le même profil qu’une application qui livre trois fois par semaine et refond son système de rôles tous les trimestres.

La question utile n’est donc pas « quand date le dernier audit ? » mais « qu’est-ce qui a changé depuis ? ». Un audit vérifie un état ; sa validité décroît proportionnellement à la vitesse à laquelle cet état se transforme.

Quatre facteurs augmentent le besoin de fréquence :

La fréquence de déploiement, en particulier sur les composants d’authentification, d’autorisation et de gestion des données clients.
La croissance de l’équipe. Une équipe qui double en un an voit ses conventions implicites se diluer.
La sensibilité des données traitées : données de santé, données financières, données personnelles à grande échelle.
L’exposition : inscription libre, API publique, place de marché d’extensions, intégrations tierces nombreuses.

Un cadre en trois niveaux

Plutôt qu’une fréquence unique, une approche à trois niveaux distingue ce qui doit être continu, périodique et déclenché.

Niveau 1 : continu, automatisé, intégré au pipeline

Ce niveau ne relève pas de la prestation d’audit mais du fonctionnement quotidien : analyse statique du code à chaque contribution, surveillance des vulnérabilités des dépendances, détection de secrets avant validation, tests automatisés de séparation entre organisations, scan des configurations d’infrastructure.

C’est le niveau le plus rentable. Il ne trouve pas les failles de logique métier, mais il élimine le bruit de fond et évite de payer des jours d’auditeur pour signaler une bibliothèque obsolète.

Niveau 2 : périodique, externe, manuel

C’est l’audit ou le pentest à proprement parler, mené par un tiers, avec une composante manuelle forte. Cadence de référence :

Tous les 12 mois pour une plateforme SaaS standard, avec un socle technique stable et des données professionnelles courantes.
Tous les 6 mois pour une plateforme traitant des données sensibles, ou dont le rythme de livraison est soutenu, ou en forte croissance d’équipe.
Tous les 3 mois pour les cas où le risque est le cœur du métier : plateforme de paiement, gestion d’identité, données de santé à grande échelle.

Ces intervalles supposent que le niveau 1 fonctionne. Sans lui, un audit annuel arrive systématiquement dans un contexte dégradé et consacre l’essentiel de son temps à des constats évitables.

Niveau 3 : déclenché par événement

Certains changements justifient un contrôle indépendamment du calendrier :

Refonte de l’authentification ou du modèle de permissions. C’est la modification la plus risquée qu’une équipe SaaS puisse faire.
Ouverture d’une API publique ou d’un mécanisme d’extensions tierces : la surface d’attaque change de nature.
Acquisition ou intégration d’un produit tiers dans la plateforme, avec un code que personne de l’équipe actuelle n’a écrit.
Migration d’infrastructure significative.
Incident de sécurité, y compris chez un fournisseur : la question devient « le même défaut existe-t-il chez nous ? ».
Entrée sur un marché plus exigeant : premier client bancaire, secteur public, marché nord-américain.

Ces audits déclenchés sont généralement plus courts et ciblés qu’un audit complet. Deux à trois jours sur un périmètre restreint suffisent souvent.

La contre-vérification, trop souvent oubliée

Un audit produit des constats ; leur correction produit du code nouveau, écrit parfois dans l’urgence, qui n’a été relu par personne d’extérieur.

Une contre-vérification, réalisée un à trois mois après la remise du rapport, vérifie que chaque constat a bien été traité et que le correctif ne contourne pas le problème sans le résoudre. Il n’est pas rare qu’un tiers des correctifs soit incomplet : filtre appliqué à l’interface mais pas à l’API, contrôle ajouté sur un endpoint et pas sur son équivalent, validation côté client uniquement.

Cette prestation est courte, une à deux journées, et fait partie des plus rentables du cycle. Elle est à négocier dès le contrat initial.

Ce qui compte davantage que la fréquence

Trois pratiques ont plus d’effet qu’un audit supplémentaire par an.

Varier les regards. Un même auditeur, sur la même application, année après année, développe des angles morts. Alterner les prestataires tous les deux ou trois cycles produit régulièrement des constats que le précédent n’avait pas relevés.

Faire varier le périmètre. Auditer trois fois de suite la même application web pendant que l’API mobile et le back-office n’ont jamais été examinés donne une fausse impression de couverture. Un plan pluriannuel qui fait tourner les périmètres vaut mieux qu’une répétition à l’identique.

Traiter les constats. Un audit tous les six mois dont les résultats ne sont pas corrigés produit moins de sécurité qu’un audit tous les dix-huit mois suivi d’un traitement complet. Le taux de correction est le meilleur indicateur de maturité, bien meilleur que le nombre d’audits réalisés.

En pratique

Pour la majorité des éditeurs SaaS B2B, une organisation raisonnable tient en quatre points : des contrôles automatisés dans le pipeline, un audit externe annuel avec un périmètre qui tourne, une contre-vérification systématique deux mois après, et un audit ciblé à chaque changement structurel de l’authentification ou du modèle de données.

Cette organisation est plus exigeante qu’une case à cocher annuelle, mais elle répond à la seule question qui compte réellement pour un client : à quel point la promesse de séparation de mes données tient-elle aujourd’hui, et pas l’an dernier ?