Cloud certifié : ce que votre SaaS doit encore démontrer

Décrire les services réellement utilisés

Listez les composants cloud de production et les fonctions qui en dépendent. Distinguez les machines gérées par votre équipe, les bases managées et les services applicatifs externalisés. Les responsabilités varient selon le service ; utilisez sa documentation et le contrat correspondant. Une même marque cloud peut proposer des offres de portée différente. Notez les régions, les options et les sous-services pertinents. Le document d’un fournisseur doit pouvoir être relié au service effectivement utilisé par votre SaaS.

Lire les documents fournisseur avec leurs limites

Demandez les certificats ou rapports pertinents et vérifiez leur portée, leur période et leur statut. Un rapport ancien ne décrit pas nécessairement un nouveau service. Les exclusions et les responsabilités des utilisateurs doivent être lues, pas seulement le logo de couverture. Conservez les conditions de partage des documents. Certains rapports ne sont pas destinés à une diffusion publique. Votre équipe doit comprendre ce qui peut être utilisé dans un questionnaire client et ce qui nécessite un échange limité.

Construire une matrice de responsabilité

Pour chaque sujet, distinguez la tâche du fournisseur, celle de votre équipe et les interfaces. Les sauvegardes illustrent cette différence : l’infrastructure peut offrir un mécanisme, tandis que votre organisation choisit sa configuration et vérifie la reprise. La gestion des accès, les journaux et les clés demandent la même lecture. Attribuez un propriétaire aux tâches conservées. Une matrice utile contient les preuves de votre mise en œuvre, pas seulement les engagements théoriques des fournisseurs.

Examiner les chaînes de dépendance

Votre SaaS peut dépendre d’un fournisseur d’identité, d’un service d’e-mail et d’un outil de déploiement en plus de l’hébergeur. Une panne de l’un peut affecter le support ou la reprise. Décrivez ces interfaces dans les risques et les exercices. N’extrapolez pas le résultat d’un cloud principal à tous les sous-traitants. Les accès des fournisseurs et les obligations de notification doivent aussi être compris. Le cadre juridique applicable reste un chantier distinct lorsque les traitements ou les transferts l’exigent.

Garder la matrice à jour

Un changement de service managé ou de région peut modifier vos responsabilités et les preuves disponibles. Organisez une revue lors des changements d’architecture. Conservez les documents du fournisseur avec leurs dates et versions. Si un connecteur de conformité fournit un résultat automatique, vérifiez le service qu’il couvre et les conditions de son test. Un état technique satisfaisant dans une console ne démontre pas seul que toutes les tâches organisationnelles ont été réalisées.

Examiner une dépendance de bout en bout

Choisissez un service managé et décrivez son rôle dans le produit. Retrouvez la documentation du fournisseur, vos paramètres et le responsable interne. Demandez ce que l’équipe ferait en cas d’indisponibilité ou d’erreur de configuration. Le scénario permet de repérer les interfaces qui ne figurent pas dans une simple liste d’achats cloud. Les limites de connaissance doivent rester visibles : n’inventez pas une chaîne complète de sous-traitants si les informations ne sont pas disponibles.

Comparez ensuite les preuves fournisseur et les preuves propres. Un rapport peut décrire les opérations du fournisseur, mais votre configuration doit être examinée dans vos outils. Une politique interne peut attribuer une tâche, sans démontrer qu’elle a été exécutée. Gardez les deux niveaux dans la matrice. Les contrôles hérités doivent avoir une source et une portée identifiées, tandis que les tâches conservées doivent avoir des propriétaires et des traces.

Enfin, examinez les effets d’un changement. Un remplacement de service peut modifier les droits, les mécanismes de sauvegarde ou les formats de journaux. Prévoyez la reprise des preuves et la mise à jour des documents avant de désactiver l’ancien outil. Le client doit recevoir une réponse cohérente avec le système actuel. Un document cloud reste un élément du dossier ; il ne doit pas être transformé en certification automatique de votre SaaS ou en garantie de respect de tous vos engagements contractuels.

Exemple de travail, fictif

Exemple fictif : un éditeur utilise une base managée avec sauvegardes automatiques. Le fournisseur fournit le mécanisme, mais personne dans l’équipe n’a testé une restauration compatible avec le fonctionnement du SaaS. La matrice sépare la capacité du service cloud de la responsabilité de choisir les paramètres et de vérifier la reprise. Le CTO programme un test selon les besoins du produit. Le document cloud reste utile, sans être présenté comme une preuve de restauration du SaaS.

Ce que votre dossier doit permettre de vérifier

• Un inventaire des services cloud, options et régions utilisés.
• Les documents fournisseur avec portée, période et restrictions.
• Une matrice séparant tâches héritées et responsabilités propres.
• Les preuves de configuration et d’exploitation de votre SaaS.
• Une revue lors des changements d’architecture ou de fournisseur.

Questions avant de décider

Préparer la suite du travail

• Préparation ISO 27001 et SOC 2 pour SaaS B2B
• Définir le périmètre du SMSI d’un SaaS
• Revues des accès SaaS : organiser des preuves exploitables
• Outil SaaS : choisir un parcours ISO 27001 ou SOC 2
• NIST 2025 : un guide de mise en œuvre Zero Trust utile aux SaaS
• Guide ENISA NIS2 2025 : réutiliser les preuves sans confondre les régimes

Sources et portée de lecture

Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.

• ISO : ISO/IEC 27001:2022
• AICPA : cadre des rapports SOC
• www.enisa.europa.eu : publication officielle
• CNIL : règles essentielles de sécurité