Ressources
Certification ISO 27001 pour un éditeur SaaS : étapes, délais et budget
Certification ISO 27001 pour un éditeur SaaS : périmètre cloud, étapes jusqu'au stage 2, preuves techniques, facteurs de délai et postes de budget sourcés.
L'équipe CTN Solutions · publié le · 18 min de lecture
Base d'expérience : Méthode et documentation officielle (ISO, IAF, COFRAC, AWS, GitHub) appliquées au cas type des éditeurs SaaS hébergés sur le cloud, sans référence client ni retour de mission. CTN Solutions n'est pas organisme de certification.
Faits vérifiés sur les sources primaires le
Un grand compte inscrit dans son contrat, son appel d'offres ou son questionnaire de sécurité l'exigence d'un certificat ISO/IEC 27001. Pour un éditeur SaaS dont le produit tourne chez un fournisseur cloud, sur Kubernetes et derrière une chaîne d'intégration continue, la question devient : sur quel périmètre, avec quelles preuves, selon quel calendrier et pour quels postes de coût.
Cet article déroule le parcours pour ce cas : ce que l'acheteur demande vraiment, le périmètre quand l'infrastructure est hébergée par un tiers, les étapes jusqu'à la décision de certification, les preuves techniques échantillonnées, puis ce qui fixe délai et budget. Il ne donne ni durée type ni prix : les seuls repères de calendrier et de coût viennent des normes qui encadrent les organismes de certification. Cette lecture est établie sur ISO/IEC 27001:2022 et son amendement 1:2024, ISO/IEC 17021-1:2015 et ISO/IEC 27006-1:2024 ; les faits cités ont été vérifiés sur les sources officielles le .
Certificat, déclaration d'applicabilité ou questionnaire : ce que le client demande vraiment
Avant de lancer un projet, relisez la clause du contrat, de l'appel d'offres ou du questionnaire mot à mot, avec quatre questions :
- Certificat ou conformité ? « Être certifié » ne se prouve que par un certificat ; « un niveau de sécurité conforme à ISO 27001 » peut se démontrer par des documents et des preuves, si l'acheteur l'accepte.
- Organisme accrédité ? Selon l'ISO, l'accréditation n'est pas obligatoire ; un acheteur peut l'exiger, parce qu'elle se vérifie.
- Périmètre couvrant le service ? Un certificat limité aux fonctions support ne répond pas à qui achète votre plateforme.
- À quelle date ? Signature, démarrage du service ou échéance contractuelle : la réponse dit si un plan daté suffit.
Si l'exigence vise un rapport SOC 2 plutôt qu'un certificat, l'arbitrage est traité dans SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2.
Certifier, vérifier, aider : trois rôles distincts
L'ISO ne certifie personne. La certification est l'assurance écrite, fournie par un organisme indépendant, qu'un système satisfait à des exigences spécifiées ; l'accréditation reconnaît que cet organisme travaille selon les normes internationales. En France, l'instance nationale d'accréditation est le Comité français d'accréditation (COFRAC), désigné par le décret n° 2008-1401 du 19 décembre 2008.
- L'organisme de certification audite et décide. ISO/IEC 17021-1 (clause 5.2.5) interdit à un organisme accrédité de fournir du conseil en système de management : qui vous aide à construire le système ne peut pas le certifier.
- L'auditeur interne réalise l'audit exigé par la clause 9.2 d'ISO/IEC 27001 ; salarié ou tiers, il ne délivre aucun certificat.
- Le conseil aide à concevoir, mettre en œuvre et préparer ; il ne délivre rien non plus.
Ce que l'acheteur peut exiger, c'est donc le certificat de votre organisation, émis par un organisme qu'il peut vérifier : l'accréditation de l'organisme se contrôle sur le moteur « Rechercher un organisme accrédité » du COFRAC, et un certificat accrédité peut se rechercher dans la base IAF CertSearch, vers laquelle renvoie l'ISO.
Certification
Ce que chaque pièce démontre
| Pièce | Ce qu'elle démontre | Ce qu'elle ne démontre pas | Émetteur |
|---|---|---|---|
| Certificat ISO/IEC 27001 | Qu'un organisme a audité le système de management de la sécurité de l'information (SMSI) sur le périmètre déclaré, pour un cycle daté | Ce qui est hors périmètre, ni le fonctionnement de chaque mesure entre deux audits | Organisme de certification |
| Déclaration d'applicabilité (DdA) | Les mesures retenues, leur justification, leur état de mise en œuvre et la justification des exclusions (clause 6.1.3 d) | Qu'un tiers l'a vérifiée | Votre organisation |
| Politiques et réponses au questionnaire | L'organisation et les engagements déclarés | Le fonctionnement effectif | Votre organisation |
| Rapport d'audit interne | Un examen du SMSI selon un programme d'audit (clause 9.2) | Une certification | Auditeur interne, salarié ou tiers |
| Rapports de conformité du fournisseur cloud | La sécurité de l'infrastructure du fournisseur | La sécurité de ce que vous déployez dessus | Le fournisseur, via ses auditeurs |
Une date de certification ne s'annonce jamais comme acquise : la décision appartient à l'organisme.
Le périmètre : produit, équipes et fournisseurs cloud
La clause 4.3 d'ISO/IEC 27001:2022 demande de fixer les limites du SMSI en tenant compte, notamment, des interfaces et dépendances entre vos activités et celles d'autres organisations, et de documenter le périmètre. Pour un éditeur SaaS, la description du périmètre répond au moins à ces questions :
- Entité et sites : quelle société, quels bureaux, quelle part de télétravail ?
- Produit et environnements : production, préproduction, et tout outil interne qui touche aux données des clients ?
- Équipes : ingénierie, exploitation, support, direction, gestion des arrivées et départs ?
- Fournisseurs : hébergeur cloud, fournisseur d'identité, hébergement du code et intégration continue, observabilité, support client ?
Réduire le périmètre pour aller plus vite peut se payer au moment où l'acheteur lit le certificat : s'il n'y voit pas le service qu'il achète, le certificat ne répond pas à sa clause.
Hériter n'est pas exclure
Le modèle de responsabilité partagée d'AWS sépare la sécurité « du » cloud, portée par AWS, de la sécurité « dans » le cloud, portée par le client. Il classe les mesures en héritées (par exemple physiques et environnementales), partagées (correctifs, configurations, sensibilisation, chacune à son niveau) et propres au client.
Pour la DdA, cela change la justification, pas le nombre de mesures applicables. L'annexe A d'ISO/IEC 27001:2022 compte 93 mesures, numérotées comme dans ISO/IEC 27002:2022 : 37 organisationnelles (5.1 à 5.37), 8 liées aux personnes (6.1 à 6.8), 14 physiques (7.1 à 7.14) et 34 technologiques (8.1 à 8.34). Une mesure physique héritée pour les centres de données reste applicable à vos bureaux et postes de travail. Une mesure héritée se documente par le rapport du fournisseur et votre revue de ce rapport (mesures 5.19 à 5.23 sur les fournisseurs et le nuage) : elle reste une inclusion, que la clause 6.1.3 d) demande de justifier comme toute exclusion. Chez AWS, ces rapports se téléchargent gratuitement dans AWS Artifact, dont ceux relatifs aux normes ISO ; chaque client reste responsable des documents qui démontrent sa propre conformité.
Les étapes, du diagnostic à la décision de certification
Le parcours de certification ISO/IEC 27001
Le schéma enchaîne les étapes menées par l'organisation, puis l'audit initial en deux étapes et le cycle de certification conduits par l'organisme.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- Diagnostic de départ, puis périmètre documenté (clause 4.3).
- Appréciation des risques (clause 6.1.2), puis traitement des risques et déclaration d'applicabilité (clause 6.1.3).
- Politiques et mise en œuvre des mesures ; le système fonctionne et produit des preuves datées.
- Audit interne (clause 9.2), puis revue de direction (clause 9.3).
- Stage 1 de l'audit initial, mené par l'organisme : documentation et préparation ; des points à lever renvoient à la mise en œuvre.
- Stage 2 : mise en œuvre et efficacité. Une non-conformité majeure impose des corrections vérifiées dans les six mois suivant le dernier jour du stage 2, sinon un nouveau stage 2.
- La décision de certification ouvre un cycle de trois ans : au moins un audit par année civile, puis renouvellement avant l'échéance du cycle.
Risques et déclaration d'applicabilité
La clause 6.1.2 demande d'identifier les risques liés à la perte de confidentialité, d'intégrité et de disponibilité. La clause 6.1.3 en tire les mesures, la DdA, le plan de traitement, puis l'approbation du plan et l'acceptation des risques résiduels par leurs propriétaires. Ceux-ci sont dans l'entreprise : un conseil outille l'analyse, il n'accepte pas vos risques à votre place.
Fonctionnement, vérifications internes et revue de direction
Les politiques ne suffisent pas : le SMSI doit tourner assez pour produire des enregistrements. Au stage 1, l'organisme évalue notamment si les audits internes et les revues de direction sont planifiés et réalisés, et si le niveau de mise en œuvre justifie le stage 2 (ISO/IEC 17021-1, clause 9.3.1.2). L'audit interne (clause 9.2) se confie de préférence à un salarié extérieur aux activités auditées, ou à un tiers ; notre offre d'audit interne ISO 27001 externalisé décrit comment nous l'organisons.
Indépendance
Stage 1, stage 2 et cycle
Selon ISO/IEC 17021-1, le stage 1 conclut par écrit sur le passage au stage 2 ; l'organisme peut en répéter tout ou partie. Le stage 2 couvre la conformité à toutes les exigences, la mesure de la performance, les exigences légales, réglementaires et contractuelles, la maîtrise opérationnelle, l'audit interne, la revue de direction et la responsabilité de la direction.
Le cycle de trois ans commence à la décision. La surveillance a lieu au moins une fois par année civile, sauf l'année du renouvellement, la première au plus tard douze mois après la décision ; la European co-operation for Accreditation (EA) le confirme : au moins un audit par année civile. Le renouvellement doit aboutir avant l'échéance du certificat.
La version exigée
Selon le document obligatoire IAF MD 26, la transition vers l'édition 2022 s'est achevée le 31 octobre 2025 : toutes les certifications accréditées fondées sur ISO/IEC 27001:2013 ont expiré ou ont été retirées à cette date. Un certificat accrédité qui vise encore l'édition 2013 n'est donc plus valide. L'amendement 1:2024, publié en février 2024, ajoute à la clause 4.1 l'obligation de déterminer si le changement climatique est un enjeu pertinent, et à la clause 4.2 une note selon laquelle les parties intéressées peuvent avoir des exigences liées au changement climatique (traduction libre du communiqué ISO et IAF). La réponse peut être négative ; elle relève de l'analyse du contexte (clause 4.1).
Les preuves techniques sur le cloud : ce qui est échantillonné au stage 2
Au stage 2, l'auditeur échantillonne des enregistrements sur une période. Une règle de protection de branche prouve une conception ; une série de fusions revues sur la période échantillonnée prouve un fonctionnement. Le tableau croise des mesures de l'annexe A avec la documentation des services cités ; il illustre des preuves possibles, sans constituer une liste exigée par la norme.
| Mesures (annexe A) | Preuve qui tient à l'audit | Piège à éviter |
|---|---|---|
| 5.15, 5.18, 8.2 : accès et accès privilégiés | Export daté des comptes et rôles ; trace de chaque revue : qui, quand, quelles décisions | Authentification unique en place, mais utilisateurs IAM ou clés d'accès anciennes jamais revus ; le rapport d'identifiants IAM les liste |
| 8.15 : journalisation | Trail CloudTrail actif, multi-région, validation d'intégrité activée, journaux hors de portée des administrateurs du compte audité | Se reposer sur l'historique des événements, limité aux 90 derniers jours et aux événements de gestion, sans les événements de données |
| 8.15, 8.16 : journalisation et surveillance sur Kubernetes | Journaux d'audit du plan de contrôle activés, conservés et consultés | Sur Amazon EKS, ces journaux ne partent pas vers CloudWatch Logs par défaut ; chaque type (api, audit, authenticator, controllerManager, scheduler) s'active séparément |
| 8.13 : sauvegarde | Politique et comptes rendus datés de tests de restauration | Des sauvegardes jamais restaurées |
| 8.25, 8.32 : développement sécurisé, changements | Règles de protection de la branche principale et échantillon de fusions revues | Des règles qui, par défaut sur GitHub, ne s'appliquent pas aux administrateurs du dépôt tant que le réglage « Do not allow bypassing the above settings » n'est pas activé |
| 8.8 : vulnérabilités techniques | Rapports d'analyse datés et tickets de correction suivis selon votre propre politique | Des rapports que personne ne traite |
| 5.24 à 5.27 : incidents | Registre, décisions de qualification, retours d'expérience | Un processus écrit jamais exercé |
| 5.19 à 5.23 : fournisseurs et nuage | Registre des fournisseurs, rapports de conformité téléchargés et revus | Un rapport AWS Artifact jamais rapproché de vos mesures |
Sur AWS, une partie de ces preuves se produit en quelques commandes, à dater et à ranger avec la mesure concernée ; les noms entre chevrons sont à remplacer.
# Journalisation : configuration des trails CloudTrail
aws cloudtrail describe-trails \
--query 'trailList[].{nom:Name,multiRegion:IsMultiRegionTrail,organisation:IsOrganizationTrail,integrite:LogFileValidationEnabled}'
# État d'un trail : journalisation active, dernières livraisons
aws cloudtrail get-trail-status --name <arn-du-trail> \
--query '{actif:IsLogging,derniereLivraison:LatestDeliveryTime,dernierDigest:LatestDigestDeliveryTime}'
# Intégrité des fichiers livrés sur la période auditée
# Dates en UTC au format ISO 8601, par exemple AAAA-MM-JJThh:mm:ssZ
aws cloudtrail validate-logs --trail-arn <arn-du-trail> \
--start-time <debut-periode> --end-time <fin-periode>
# Amazon EKS : types de journaux du plan de contrôle activés
aws eks describe-cluster --name <cluster> --query 'cluster.logging.clusterLogging'
# Accès : rapport d'identifiants IAM au format CSV
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > rapport-identifiants.csvDeux précisions évitent de mauvaises surprises. Activer la validation d'intégrité fait livrer des fichiers de condensat mais ne valide rien : c'est validate-logs qui détecte une modification ou une suppression. Le rapport d'identifiants se génère au plus une fois toutes les quatre heures ; un utilisateur IAM peut détenir au plus deux clés d'accès, que le rapport détaille chacune dans ses propres colonnes.
Pour la chaîne d'intégration continue (analyse, signature et promotion des images), voir DevSecOps en pratique : scanner, signer et promouvoir l'image qu'on déploie vraiment.
Délais et budget : ce qui les fixe, poste par poste
Ce que les normes fixent, et ce qu'elles ne fixent pas
Les seules contraintes de calendrier des sources primaires sont celles des étapes : audits internes et revues de direction planifiés et réalisés, ce que l'organisme évalue dès le stage 1, six mois pour faire vérifier les corrections d'une non-conformité majeure, première surveillance sous douze mois, puis un audit par année civile. Aucune source consultée ne fixe de durée minimale de projet ni de fonctionnement du SMSI avant l'audit ; les durées annoncées sans source ailleurs sont des estimations.
Les facteurs qui allongent ou raccourcissent le délai
- Le périmètre : nombre de produits, d'environnements, d'équipes et de fournisseurs.
- L'état de départ : ce qui existe déjà et produit des enregistrements datés raccourcit le chemin ; ce qui manque doit être mis en place, puis fonctionner assez longtemps pour laisser des preuves.
- Vos propres cadences : une revue trimestrielle ne se prouve qu'une fois un trimestre écoulé ; le calendrier des preuves découle des cadences écrites dans vos politiques.
- La disponibilité des responsables internes : propriétaires de risques, direction, ingénieurs.
- L'organisme de certification : ses disponibilités pour les deux étapes et son délai de décision.
- Les points relevés au stage 1 : ils peuvent repousser le stage 2.
Partez de la date exigée par l'acheteur et remontez ces facteurs. Si la date n'est pas tenable, un plan daté proposé tôt vaut mieux qu'un certificat promis.
Les postes de budget
| Poste | Ce qu'il couvre | Ce qui le fait varier |
|---|---|---|
| Temps interne | Pilotage du SMSI, travaux techniques, arbitrages et revue de direction, décisions des propriétaires de risques | Périmètre, état de départ, part déléguée |
| Appui externe | Diagnostic, conception, rédaction, mise en œuvre technique, préparation aux audits | Ce qui est confié et ce qui reste en interne |
| Outillage | Plateforme de gouvernance, risques et conformité (GRC), outils de sécurité manquants (journalisation centralisée, analyse de vulnérabilités, gestion des postes) | Existant, nombre d'utilisateurs, intégrations |
| Audit interne | Programme et réalisation de l'audit de la clause 9.2 | Taille du périmètre, exigence d'indépendance |
| Audit de certification | Stage 1 et stage 2, surveillance les deux années suivantes, renouvellement | Temps d'audit déterminé par l'organisme, frais de déplacement éventuels |
| Fonctionnement récurrent | Revues, collecte de preuves, mise à jour des risques, exercices, actions correctives | Nombre de mesures et cadences retenues |
Un budget établi sur le cycle de trois ans compte aussi les deux surveillances, le renouvellement et le fonctionnement récurrent, pas seulement la première année.
Le temps de l'organisme de certification : le principe
Pour une certification accréditée, le temps d'audit n'est pas une grille commerciale libre. ISO/IEC 27006-1:2024, publiée en mars 2024, complète ISO/IEC 17021-1 pour les organismes qui certifient des SMSI et remplace ISO/IEC 27006:2015. Son annexe C, normative, porte sur le temps d'audit ; son annexe D, informative, décrit des méthodes de calcul. Selon l'organisme d'accréditation américain ANAB, le calcul part d'un nombre effectif de personnes, qui tient compte des personnes exerçant certaines activités identiques, avec des règles pour les organisations multisites et les extensions de périmètre. En France, le document du COFRAC sur l'accréditation des organismes certifiant ISO/IEC 27001 (CERT CEPE REF 35, révision 08, applicable depuis le 7 juillet 2026) renvoie à cette norme pour déterminer ce temps.
La table entre effectif et jours d'audit n'est pas reproduite : le texte normatif est payant et n'a pas pu être lu sur une source primaire en accès libre. Le coût d'un audit se lit généralement en jours d'auditeur multipliés par un tarif journalier, plus les frais. Pour comparer des propositions, demandez à chaque organisme :
- le nombre de jours d'auditeur pour le stage 1, le stage 2, chaque surveillance et le renouvellement ;
- l'effectif retenu pour le calcul et les ajustements appliqués ;
- la part d'audit à distance prévue ;
- le tarif journalier et les frais de déplacement ;
- son accréditation, vérifiable auprès de son organisme d'accréditation (moteur de recherche du COFRAC pour un organisme accrédité en France).
Une proposition dont le nombre de jours s'écarte nettement des autres mérite une question sur la façon dont elle applique l'annexe C. Pour cadrer le périmètre, le diagnostic et le plan jusqu'à l'audit de certification, la page Accompagnement ISO 27001 : construire les preuves décrit notre intervention ; la certification reste l'acte de l'organisme.
Sources officielles et limites de lecture
Faits datés
Vérifié le
- Textes payants. ISO/IEC 17021-1 a été lue dans des extraits publiés par des organismes d'accréditation (IAS, EA) ; ISO/IEC 27001, 27002 et 27006-1 dans leurs extraits de prévisualisation. Les formulations françaises sont des traductions libres.
- Ni table de temps d'audit, ni durée, ni prix. Seule la proposition d'un organisme donne les jours applicables ; son règlement de certification fait foi pour ses modalités.
- Base d'expérience. Méthode et documentation officielle (ISO, IAF, COFRAC, AWS, GitHub), sans référence client ni retour de mission. CTN Solutions n'exerce aucune activité de certification.
Sources
- ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements, ISO, https://www.iso.org/standard/27001, consulté le 07/10/2026.
- ISO/IEC 27001:2022/Amd 1:2024, Amendment 1: Climate action changes, ISO, https://www.iso.org/standard/88435.html, consulté le 07/10/2026.
- IAF/ISO Joint Communiqué on the addition of Climate Change considerations to Management Systems Standards (février 2024), ISO, https://www.iso.org/files/live/sites/isoorg/files/standards/popular_standards/management_systems/ISO-IAF%20Joint%20Communique%20Feb%202024.pdf, consulté le 07/10/2026.
- ISO/IEC 27001:2022, extrait de prévisualisation (sommaire, articles 1 à 6), iTeh Standards, https://cdn.standards.iteh.ai/samples/82875/726bcf58250e43d9a666b4d929c8fbdb/ISO-IEC-27001-2022.pdf, consulté le 07/10/2026.
- ISO/IEC 27002:2022, extrait de prévisualisation en français (sommaire des mesures), iTeh Standards, https://cdn.standards.iteh.ai/samples/75652/9b0c626e1b1e4bda804fca1097e129db/ISO-IEC-27002-2022.pdf, consulté le 07/10/2026.
- IAF MD 26:2023, Transition requirements for ISO/IEC 27001:2022, International Accreditation Forum, https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf, consulté le 07/10/2026.
- ISO/IEC 17021-1:2015, section 9, exigences relatives aux processus (extrait publié par l'organisme d'accréditation IAS), https://www.iasonline.org/wp-content/uploads/2021/02/17021-1-2015-Section-9.pdf, consulté le 07/10/2026.
- Question 37.12, ISO 17021-1:2015 clause 9.1.3, European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-37-12-iso-17021-12015-clause-9-1-3/, consulté le 07/10/2026.
- Question 41.1, Impartiality, Cl. 5.2.5 of ISO/IEC 17021-1:2015, European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-41-1-impartiality-cl-5-2-5-of-iso-iec-17021-12015/, consulté le 07/10/2026.
- ISO/IEC 27006-1:2024, Requirements for bodies providing audit and certification of information security management systems, Part 1: General, ISO, https://www.iso.org/standard/82908.html, consulté le 07/10/2026.
- ISO/IEC 27006-1:2024, extrait de prévisualisation (sommaire, avant-propos, articles 1 à 7), iTeh Standards, https://cdn.standards.iteh.ai/samples/82908/130ca63751e44a2a89b464af8d30cb00/ISO-IEC-27006-1-2024.pdf, consulté le 07/10/2026.
- ISO/IEC 27006-1:2024 Transition, ANAB (ANSI National Accreditation Board), https://blog.ansi.org/anab/iso-iec-27006-1-2024-transition/, consulté le 07/10/2026.
- CERT CEPE REF 35, révision 08, Exigences spécifiques pour l'accréditation des organismes procédant à la certification de systèmes de management dans le domaine des technologies de l'information, COFRAC, https://tools.cofrac.fr/documentation/CERT-CEPE-REF-35, consulté le 07/10/2026.
- Certification, ISO, https://www.iso.org/certification.html, consulté le 07/10/2026.
- Cofrac, the only French accreditation body, COFRAC, https://www.cofrac.fr/en/about-cofrac/discover-cofrac/our-mission-inspiring-confidence, consulté le 07/10/2026.
- Décret n° 2008-1401 du 19 décembre 2008 relatif à l'accréditation et à l'évaluation de conformité, Légifrance, https://www.legifrance.gouv.fr/loda/id/JORFTEXT000019992087, consulté le 07/10/2026.
- Rechercher un organisme accrédité, COFRAC, https://tools.cofrac.fr/fr/easysearch, consulté le 07/10/2026.
- Certification of management systems, COFRAC, https://www.cofrac.fr/en/our-fields-of-application/digital-transition-and-cybersecurity/certification-of-management-systems, consulté le 07/10/2026.
- Quelle est la différence entre accréditation et certification ?, COFRAC, https://www.cofrac.fr/faq-contact/cofracfaq/detail/quelle-est-la-difference-entre-accreditation-et-certification, consulté le 07/10/2026.
- Shared Responsibility Model, AWS, https://aws.amazon.com/compliance/shared-responsibility-model/, consulté le 07/10/2026.
- What is AWS Artifact?, AWS, https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html, consulté le 07/10/2026.
- Working with CloudTrail event history, AWS, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html, consulté le 07/10/2026.
- Validating CloudTrail log file integrity, AWS, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html, consulté le 07/10/2026.
- AWS CLI Command Reference, cloudtrail describe-trails, get-trail-status et validate-logs, AWS, https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/describe-trails.html, https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/get-trail-status.html et https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/validate-logs.html, consultés le 07/10/2026.
- Send control plane logs to CloudWatch Logs, Amazon EKS User Guide, AWS, https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html, consulté le 07/10/2026.
- AWS CLI Command Reference, eks describe-cluster, AWS, https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html, consulté le 07/10/2026.
- Generate credential reports for your AWS account, IAM User Guide, AWS, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html, consulté le 07/10/2026.
- About protected branches, GitHub Docs, https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches, consulté le 07/10/2026.
- AWS CLI version 2, code et exemples officiels (commande validate-logs, exemples cloudtrail validate-logs et eks describe-cluster, modèle d'API CloudTrail pour l'opération LookupEvents), dépôt GitHub aws/aws-cli, https://github.com/aws/aws-cli/blob/v2/awscli/customizations/cloudtrail/validation.py, https://github.com/aws/aws-cli/blob/v2/awscli/examples/cloudtrail/validate-logs.rst, https://github.com/aws/aws-cli/blob/v2/awscli/examples/eks/describe-cluster.rst et https://github.com/aws/aws-cli/blob/v2/awscli/botocore/data/cloudtrail/2013-11-01/service-2.json, consultés le 07/10/2026.
- AWS SDK for Go v2, opérations CloudTrail CreateTrail et GetTrailStatus, opération IAM GetCredentialReport, dépôt GitHub aws/aws-sdk-go-v2, https://github.com/aws/aws-sdk-go-v2/blob/main/service/cloudtrail/api_op_CreateTrail.go, https://github.com/aws/aws-sdk-go-v2/blob/main/service/cloudtrail/api_op_GetTrailStatus.go et https://github.com/aws/aws-sdk-go-v2/blob/main/service/iam/api_op_GetCredentialReport.go, consultés le 07/10/2026.
- Send control plane logs to CloudWatch Logs, source de la page, dépôt GitHub awsdocs/amazon-eks-user-guide, https://github.com/awsdocs/amazon-eks-user-guide/blob/mainline/latest/ug/observability/control-plane-logs.adoc, consulté le 07/10/2026.
- About protected branches, source de la page, dépôt GitHub github/docs, https://github.com/github/docs/blob/main/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md, consulté le 07/10/2026.