Automatiser la collecte de preuves de conformité ISO 27001 / SOC 2 avec n8n

Un questionnaire d'audit bien conçu, avec une piste horodatée dans Supabase, couvre la moitié du travail de conformité ISO 27001 ou SOC 2 : la partie déclarative, où quelqu'un répond « oui, le MFA est activé sur les comptes admin » ou « oui, les sauvegardes tournent chaque nuit ». L'autre moitié, celle qu'un auditeur externe réclame systématiquement, ce sont les preuves techniques : la capture de la configuration MFA dans la console d'administration, le journal des sauvegardes réussies des trente derniers jours, la liste des accès révoqués dans les 24 heures suivant un départ. Ce sont ces preuves-là qui prennent le plus de temps à rassembler à la main — et qui périment le plus vite entre deux cycles d'audit.

Preuve déclarative et preuve technique : deux choses différentes

Le bot de questionnaire guidé du Pack Conformité & Audit excelle sur la première catégorie : il fait dérouler un protocole d'audit à une personne, horodate chaque réponse et la range dans Supabase, avec relances automatiques sur les dossiers incomplets. C'est exactement ce qu'il faut pour documenter les intentions et les processus. Mais un auditeur ISO 27001 ne se contente pas d'une réponse « oui » à « les accès sont-ils revus régulièrement ? » : il veut voir l'export de la dernière revue, sa date, et les comptes effectivement désactivés.

Ce déficit entre déclaratif et technique n'est pas nouveau : l'idée de rapprocher la preuve d'audit de l'état réel des systèmes, en continu plutôt qu'à la date fixe du contrôle, remonte à l'article fondateur de Vasarhelyi et Halper, The Continuous Audit of Online Systems (1991), qui décrit l'un des premiers systèmes de contrôle continu déployé en production, sur les données de facturation d'AT&T. Plus de trois décennies plus tard, le problème qu'ils décrivaient — des contrôles vérifiés ponctuellement plutôt qu'en permanence — reste le principal reproche fait aux audits ISO 27001 et SOC 2 menés uniquement par questionnaire.

Construire un collecteur de preuves dans n8n

Le principe : un workflow n8n distinct, dédié aux preuves techniques, qui vient alimenter la même piste d'audit que le bot conversationnel plutôt que la remplacer.

1. Schedule Trigger — un déclenchement hebdomadaire par famille de contrôles (accès, sauvegardes, correctifs de sécurité, chiffrement). Notre guide du Schedule Trigger et des expressions cron couvre la syntaxe si vous voulez décaler chaque famille sur un jour différent.
2. Nœuds HTTP Request, un par source — interrogation en lecture seule des API concernées : API GitHub pour les règles de protection de branche et le 2FA imposé aux contributeurs, API du fournisseur cloud pour les rôles IAM et les logs de sauvegarde, API du fournisseur SSO pour le statut MFA des comptes. Chaque credential utilisé ici doit être un token scopé lecture seule — notre guide de sécurisation des credentials API dans n8n détaille comment restreindre les scopes au strict nécessaire.
3. Node Set (Edit Fields) — normalise chaque réponse d'API hétérogène vers un format commun : control_id, source, valeur_brute, collecte_le.
4. Node Supabase — insère la ligne normalisée dans une table preuves_conformite, sur le même principe que le webhook de piste d'audit horodatée déjà utilisé par le pack pour les réponses déclaratives : un seul point d'écriture, un format constant, un horodatage côté serveur non falsifiable.

Le résultat après quelques semaines : une table qui contient à la fois les réponses humaines du questionnaire et les preuves techniques collectées automatiquement, reliées par le même control_id.

Faire évaluer chaque preuve par un LLM contraint

Une réponse brute d'API (un JSON de configuration IAM, une liste de commits sur une branche protégée) n'est pas lisible pour un comité de direction, et encore moins directement exploitable dans un rapport d'audit. C'est là qu'un modèle de langage aide, à condition de le contraindre étroitement :

• Le prompt reçoit la description exacte du contrôle attendu (« le MFA doit être activé pour 100 % des comptes ayant un rôle admin ») et la preuve brute collectée.
• Un Structured Output Parser force une réponse au format { control_id, statut: "conforme" | "non_conforme" | "a_verifier", justification } — jamais du texte libre qu'il faudrait relire à la main.
• Le statut a_verifier est délibérément prévu pour les cas ambigus : mieux vaut un signal « je ne sais pas trancher » qu'une fausse certitude. Un modèle qui ne reçoit aucune option d'incertitude a tendance à trancher quand même, souvent à tort.

Avant de faire confiance à ce prompt sur de vrais contrôles, testez-le sur un jeu de preuves déjà qualifiées manuellement lors d'un audit précédent — la même logique d'évaluation que celle décrite dans notre article sur les évaluations n8n pour workflows IA, appliquée ici à la fiabilité du diagnostic plutôt qu'à la qualité d'une réponse de chatbot.

Router les non-conformités vers une validation humaine

Aucune preuve marquée non_conforme ou a_verifier ne doit fermer ou ignorer automatiquement une action de conformité — l'enjeu (une certification, la confiance d'un client B2B) est trop élevé pour un pilote automatique complet. Le node If route ces deux statuts vers une alerte Slack suivie d'un node Wait avec validation humaine : la personne responsable de la conformité confirme, corrige le statut ou déclenche une action corrective avant que le dossier n'avance. Les preuves conforme peuvent, elles, s'archiver directement — le gain de temps se concentre là où il compte, sur les vrais écarts.

Générer le rapport d'audit à partir des deux sources

Une fois les tables audit_responses (déclaratif) et preuves_conformite (technique) alimentées en continu, le workflow de rapport de synthèse par IA du pack n'a besoin que d'une extension : lire les deux tables au lieu d'une seule avant la synthèse. Le rapport final présente alors, contrôle par contrôle, la réponse déclarée et la preuve technique correspondante — exactement la structure qu'un auditeur ISO 27001 ou SOC 2 attend d'un dossier de preuves, avec des semaines de collecte manuelle en moins.

Une étude publiée en 2026 dans la revue Software (MDPI), Integrating Continuous Compliance into DevSecOps Pipelines: A Data Engineering Perspective, propose une architecture assez proche pour les environnements de développement continu : des preuves collectées automatiquement à chaque étape du pipeline, horodatées et interrogeables, plutôt que reconstituées à la dernière minute avant un audit. Le principe transposé ici à n8n est le même — remplacer l'instantané ponctuel par un flux continu de preuves déjà organisées.

Pièges fréquents

• Ne conserver que le verdict du LLM, pas la preuve brute : un auditeur veut voir la capture d'écran ou la réponse d'API originale, pas seulement « conforme » écrit par un modèle. Archivez toujours la preuve source à côté de son évaluation.
• Des tokens API trop larges : un credential avec droit d'écriture utilisé pour de la simple lecture est un risque de sécurité disproportionné par rapport au besoin — restez strictement en lecture seule.
• Un prompt sans exemples de ce qui compte comme preuve valide : sans quelques exemples annotés dans le message système, le modèle improvise sa propre définition de « conforme », rarement alignée avec celle de votre référentiel.
• Oublier de dater la fraîcheur d'une preuve : une preuve de sauvegarde vieille de trois mois n'a aucune valeur pour un contrôle censé être vérifié chaque semaine ; le champ collecte_le doit apparaître explicitement dans le rapport, pas seulement dans la base.

Pour aller plus loin

Ce collecteur de preuves techniques vient compléter, sans le remplacer, le Pack Conformité & Audit (149 €) : le bot conversationnel et les relances automatiques couvrent le volet déclaratif, ce workflow ajoute le volet technique sur les mêmes tables Supabase, pour un dossier d'audit complet généré en continu plutôt que reconstitué dans l'urgence à chaque échéance de certification.