Un rapport de conformité se prépare presque toujours dans l'urgence. L'auditeur annonce sa date, et trois personnes passent la semaine à rassembler des exports, des captures d'écran et des tableurs que personne n'avait tenus à jour. Le document sort à temps, il décrit un état des lieux déjà périmé, et l'exercice recommence six mois plus tard.
Automatiser le reporting de conformité consiste à inverser l'ordre : la preuve se collecte au moment où l'événement se produit, et le rapport n'est plus qu'une mise en forme de ce qui est déjà en base. Ce guide décrit le montage — quelles sources brancher, quoi stocker, comment restituer — et où s'arrête ce qu'une machine peut produire à votre place.
Ce qu'un reporting de conformité contient vraiment
Un rapport de conformité n'est pas un livrable, c'est une série de réponses. Quels traitements de données faisons-nous. Où sont ces données. Qui peut y accéder, et qui y a réellement accédé. Sur quelle base légale. Combien de temps les gardons-nous. À quels sous-traitants les envoyons-nous. Que s'est-il passé le jour où ça a dérapé.
Ces réponses se rangent en trois familles, et elles n'ont pas la même mécanique.
Les registres décrivent un état à un instant donné : le registre des traitements, l'inventaire des systèmes, la liste des sous-traitants, la cartographie des données. Ils ne sont jamais finis — chaque nouveau connecteur, chaque nouvel outil marketing les périme un peu.
Les journaux enregistrent des événements horodatés : un accès, un export, une suppression, un consentement recueilli ou retiré, un incident. Ils ne se corrigent pas, ils s'empilent.
Les rapports sont la synthèse produite à date fixe ou à la demande, pour le comité de direction, le DPO, un client qui fait son audit fournisseur, ou une autorité de contrôle.
L'erreur qui coûte le plus cher est de traiter les trois comme des documents. Ce sont des requêtes sur une base. Le jour où c'est vrai, produire le rapport prend une minute et non une semaine.
Pourquoi ça déraille sans montage automatisé
La preuve se produit là où personne ne regarde. Un export de contacts fait depuis le CRM, un nouveau connecteur ajouté dans l'outil d'emailing, un tableur téléchargé sur un poste : chacun de ces gestes crée une information de conformité, et aucun ne prévient le DPO.
L'information se périme vite. Un workflow branché lundi sur un nouveau service traite des données personnelles dès mardi. S'il n'existe aucun mécanisme qui le remonte, le registre décrit une organisation qui n'existe plus.
Et la charge tombe toujours sur la même personne. Un DPO passe l'essentiel de son temps à réclamer des informations à des équipes qui ont autre chose à faire, au lieu de les analyser. C'est cette collecte qui s'automatise, pas le jugement.
Les quatre sources à brancher avant d'écrire le premier rapport
1. Les outils qui détiennent des données personnelles. CRM, emailing, SIRH, support, facturation, stockage de fichiers. On y cherche la liste des champs, les volumes, les dates de dernière activité et les exports effectués. La question à poser avant toute chose est celle qui décide de la faisabilité : que renvoie leur API en lecture ? Beaucoup d'outils SaaS exposent très bien leurs données métier et très mal leurs journaux d'accès. Réclamez la documentation avant de dessiner quoi que ce soit.
2. La couche d'orchestration. Si vos automatisations passent par n8n, par Make ou par du code maison, c'est le meilleur point d'observation du système d'information. Chaque exécution sait quelles données elle a lues et écrites. Un workflow qui journalise ce qu'il traite alimente votre registre sans effort supplémentaire — c'est la source la plus rentable à brancher, et presque personne ne le fait.
3. Les accès. L'annuaire d'entreprise, la gestion des droits, les journaux d'API. Deux questions distinctes doivent trouver leur réponse : qui pouvait lire ces données, et qui les a lues. La première relève de la revue de droits, la seconde du journal. Confondre les deux produit un rapport qui rassure sans rien prouver.
4. Les décisions humaines. La validation d'une analyse d'impact, le choix d'une durée de conservation, l'autorisation d'un nouveau sous-traitant, l'arbitrage sur une base légale. Aucune API ne les expose. Il faut un formulaire, il faut qu'il tienne en six champs, et il faut qu'il écrive dans la même base que le reste.
C'est la quatrième source qu'on oublie, et c'est elle qui sépare un rapport technique d'un rapport de conformité. Un journal d'accès prouve ce qui s'est passé. Seule la trace d'une décision explique pourquoi c'était prévu.
Le montage : collecter, horodater, stocker, restituer
Un événement, une ligne, immédiatement
Le cœur du système est une table d'événements alimentée en continu. Trois déclencheurs suffisent à la remplir : un webhook quand l'outil source sait en émettre un, une tâche planifiée qui interroge les API qui n'en émettent pas, et un nœud de journalisation ajouté à la fin de chaque workflow existant.
La ligne écrite reste volontairement pauvre : date et heure, type d'événement, système source, catégorie de données concernée, personne ou service à l'origine, référence de l'objet, et un champ libre. Sept colonnes couvrent l'essentiel des besoins d'un premier pipeline.
Un point n'est pas négociable : la table est en ajout seul. On ne modifie jamais une ligne, on en écrit une nouvelle qui corrige la précédente. Un journal réécrit ne prouve rien — si une ligne peut disparaître sans laisser de trace, elle ne vaut pas comme élément de preuve devant un auditeur. Retirez les droits de mise à jour et de suppression au compte technique qui écrit dedans, et vérifiez-le.
Postgres suffit pour commencer
Pas besoin d'une plateforme de gouvernance des risques pour un premier montage. Une base Postgres, un orchestrateur qui écrit dedans, un outil de restitution comme Metabase ou Grafana branché en lecture : l'ensemble tient en quelques jours de travail. Le coût réel n'est pas dans l'outil, il est dans le branchement des sources.
La plateforme dédiée se justifie plus tard, quand plusieurs référentiels coexistent, quand des engagements contractuels imposent un format précis, ou quand une équipe conformité est constituée. Achetée trop tôt, elle se remplit à la main : c'est le même travail qu'avant, avec un abonnement en plus.
Le stockage obéit aux mêmes règles que ce qu'il documente. Un journal de conformité contient des données personnelles — des identifiants, des adresses, parfois le motif d'une demande. Il a donc lui aussi une durée de conservation, une politique d'accès et une place au registre. Le cadre général est détaillé dans notre article sur l'automatisation et le RGPD, et les principes de tenue d'une base partagée dans celui sur la gouvernance des données quand on automatise tout.
Deux sorties, pas une
La première sortie est le rapport périodique : généré la nuit, envoyé le lundi matin, toujours au même endroit. La seconde est l'export à la demande — un auditeur, un client, une autorité réclame une période et un périmètre précis, et il faut pouvoir produire le fichier dans la journée. C'est la sortie qu'on oublie de construire, et c'est la seule qui compte le jour où on en a besoin.
Ajoutez-y le troisième canal : l'alerte. Un export au-delà d'un seuil, un accès hors horaires, un flux de données vers un service non déclaré. La logique de seuil et de destinataire est celle décrite dans notre guide sur les alertes automatiques à mettre en place pour piloter vos projets : une alerte qui part trop souvent finit en règle de filtrage dans la boîte mail de son destinataire.
Cinq rapports qui valent le premier chantier
1. Le registre des traitements qui se tient à jour
Le registre vit dans une table : une ligne par traitement, avec finalité, base légale, catégories de données, destinataires, durée de conservation. Ces champs se saisissent une fois, à la main, et c'est normal.
Ce qui s'automatise est le contrôle d'écart. Un job hebdomadaire compare les flux réellement actifs — les workflows qui tournent, les connecteurs autorisés, les tables qui reçoivent des écritures — à ce qui est déclaré. Tout flux actif non déclaré part en alerte au DPO. C'est la seule mécanique qui empêche un registre de dériver, parce qu'elle ne dépend pas de la bonne volonté de celui qui a branché le nouvel outil.
2. Le journal des accès et des exports
L'export est le moment de risque le plus banal et le moins surveillé. Un fichier de plusieurs milliers de contacts téléchargé sur un poste portable ne laisse souvent aucune trace exploitable. Chaque export doit produire une ligne : qui, quand, depuis quel outil, quel périmètre, combien d'enregistrements, pour quel motif déclaré. Le motif est saisi par la personne au moment de l'export — c'est une friction de dix secondes, et c'est ce qui rend le journal lisible six mois après.
3. Les preuves de consentement
Une preuve de consentement utile contient l'horodatage, le canal, l'identifiant de la personne et le texte exact affiché au moment de la collecte. Ce dernier point est celui qu'on rate : stocker un lien vers la version actuelle du formulaire ne prouve rien, puisque le formulaire a changé depuis. Versionnez le libellé, stockez la référence de version avec chaque consentement, et faites la même chose pour les retraits.
4. Le suivi des demandes d'exercice de droits
Accès, rectification, effacement, portabilité, opposition. Chaque demande ouvre un chronomètre et une liste de systèmes à traiter. Le workflow crée le dossier, notifie les responsables de chaque système, relance ceux qui n'ont pas répondu, et clôture en enregistrant la date de réponse. Le rapport qui en sort donne le délai moyen, le nombre de demandes en cours et celles qui approchent de l'échéance — les trois chiffres qu'un auditeur demande en premier.
5. L'inventaire des usages d'IA
Beaucoup d'organisations ne savent pas répondre à la question « où utilisez-vous des modèles d'IA, et sur quelles données ». La table est pourtant simple : usage, service concerné, modèle ou fournisseur appelé, catégories de données envoyées, existence d'une supervision humaine, personne responsable. Elle se remplit à la main au départ, puis se recoupe automatiquement avec les appels d'API réellement facturés — un usage qui consomme des tokens sans figurer à l'inventaire, c'est exactement ce qu'on cherche à voir.
Ce que l'IA fait bien ici, et ce qu'elle ne décide pas
Un modèle de langage est utile sur trois tâches de ce pipeline. Extraire des informations structurées d'un document non structuré — une politique de sécurité fournisseur, un contrat de sous-traitance, une réponse à questionnaire. Rédiger le premier jet d'une synthèse à partir des chiffres déjà en base. Et signaler, dans un journal de plusieurs milliers de lignes, ce qui mérite un œil humain.
Ce qu'il ne fait pas : dire si vous êtes conforme. Un modèle produit une réponse plausible, y compris quand il n'a pas l'information. La qualification juridique appartient au DPO, au conseil, à l'auditeur — et un rapport de conformité rédigé par une machine sans relecture est précisément le genre de document qui se retourne contre son auteur.
Un dernier réflexe, souvent oublié : l'appel au modèle est lui-même un traitement. Ce que votre workflow envoie dans un prompt sort de votre système d'information. Cet usage figure à l'inventaire du point précédent, au même titre que les autres.
RGPD, AI Act : le pipeline change la charge, pas la responsabilité
Le RGPD impose de tenir un registre des activités de traitement et de notifier une violation de données à l'autorité de contrôle dans un délai de 72 heures. Ces deux obligations expliquent à elles seules la majorité du travail décrit plus haut : un registre ne se tient pas de mémoire, et 72 heures ne suffisent pas quand il faut d'abord reconstituer ce qui s'est passé à partir de six outils différents. Un journal alimenté en continu transforme cette course en requête.
Le règlement européen sur l'intelligence artificielle ajoute une couche pour les organisations qui déploient des systèmes d'IA : selon l'usage, de la documentation, de l'information des personnes et une supervision humaine réelle sont attendues. Le détail des obligations par niveau de risque et le calendrier d'application ne sont pas listés ici volontairement — ils se vérifient avec votre conseil ou votre DPO, sur le texte, à la date où vous lisez cette page. Ce que cet article vous dit, c'est que l'inventaire des usages d'IA sera demandé, et qu'il est plus simple à tenir dès maintenant qu'à reconstituer plus tard.
Dans les deux cas, la mécanique est la même : l'automatisation déplace la charge de collecte. Elle ne déplace pas la responsabilité, qui reste au responsable de traitement.
Les erreurs qui rendent un reporting automatisé inutile
Le rapport que personne ne lit. Un PDF de quarante pages envoyé chaque mois disparaît au bout de trois envois. Une page de tableau de bord avec cinq indicateurs et une alerte quand l'un d'eux sort de sa plage, ça se regarde.
Tout brancher d'un coup. Six sources en parallèle, aucune vérifiée, et un pipeline dont plus personne ne sait s'il dit vrai. Une source, mise en production, recoupée à la main une fois, puis la suivante.
Confondre l'indicateur et la preuve. Un graphique montre une tendance. Un auditeur demande la ligne : la date, l'identifiant, l'opération. Gardez le détail, pas seulement l'agrégat.
Ne nommer personne. Un workflow qui détecte un écart et l'envoie dans un canal que personne ne lit produit du bruit et une fausse assurance. Chaque alerte a un destinataire nommé et un délai de traitement écrit.
Par où commencer cette semaine
Listez les systèmes qui détiennent des données personnelles, et pour chacun, ce que son API expose en lecture. Choisissez le journal le plus douloureux à produire aujourd'hui — dans la plupart des organisations, c'est celui des exports. Créez la table en ajout seul, branchez une seule source, laissez tourner quinze jours, puis recoupez à la main ce qu'elle contient avec ce que vous savez de la période.
Si le recoupement tient, ajoutez la source suivante. S'il ne tient pas, vous venez d'apprendre quelque chose sur votre système d'information, et c'était le but de la première itération.
Cadrer ce montage — les sources, la table d'événements, les rapports qui servent réellement — est le travail que fait notre agence d'automatisation avant d'écrire la première ligne de configuration.
