n8n 2.35 : audit trail natif et validation humaine des agents IA (HITL)

Un agent IA qui écrit seul dans une base de production, envoie un email à un client ou supprime un enregistrement inquiète à raison : personne ne veut découvrir l'action a posteriori, dans les logs, après coup. Jusqu'ici, prouver qu'un humain avait bien validé une étape sensible d'un workflow n8n demandait de le construire soi-même — un node Wait, un webhook de reprise, une table Supabase pour horodater la décision, comme le détaille notre guide sur l'approbation humaine avec le node Wait et Slack. La version 2.35 de n8n, sortie le 18 août 2026, ajoute deux mécanismes natifs qui changent la donne : un horodatage d'audit automatique sur les nodes Send and Wait, et une validation humaine obligatoire directement au niveau des outils d'un AI Agent. Voici ce que ça change concrètement, et où ça ne remplace pas ce que vous avez peut-être déjà construit.

respondedAt : un horodatage d'audit natif, sans rien configurer

Depuis la 2.35, tout node Send and Wait — Slack, Telegram, Discord, WhatsApp, Google Chat, Gmail, Outlook, Email/SMTP, Microsoft Teams, ainsi que le node Chat Trigger — inclut désormais un champ respondedAt au format ISO-8601 dans sa sortie, dès l'instant où n8n reçoit une réponse. Aucune configuration n'est nécessaire : le champ apparaît automatiquement à côté des champs existants (approved, text ou form selon le type de réponse attendu), et ne modifie pas la structure de sortie des workflows déjà en production.

Concrètement, ça veut dire qu'un simple bouton d'approbation Slack porte désormais nativement la preuve de l'instant exact où quelqu'un a cliqué — sans avoir à construire vous-même le mécanisme d'horodatage. Pour en faire une vraie piste d'audit persistante plutôt qu'une donnée éphémère de l'exécution, il suffit de brancher ce champ vers une table de journalisation, exactement comme le fait notre guide sur la piste d'audit RGPD avec Supabase — sauf que l'horodatage lui-même n'est plus à coder à la main.

HITL pour les appels d'outils d'un AI Agent : geler l'action, pas tout le workflow

La seconde nouveauté cible un problème différent, propre aux agents IA : un AI Agent décide lui-même, en cours de raisonnement, quel outil appeler et à quel moment. Impossible de placer un node Wait « avant » une action qu'on ne sait pas à l'avance si l'agent va déclencher. n8n 2.35 introduit donc un mécanisme de validation au niveau de l'outil lui-même : un outil marqué comme sensible (« gated ») ne s'exécute pas tant qu'un humain n'a pas explicitement approuvé l'action demandée par l'agent — suppression d'un enregistrement, écriture sur un système de production, envoi d'un email à fort impact.

Le point important : la revue s'appuie sur les intégrations standard de n8n (Slack, Teams, email…), donc la validation n'est pas enfermée dans une seule interface. La décision peut être routée vers la bonne personne, sur le canal qu'elle utilise déjà au quotidien — ce qui rapproche ce mécanisme des outils personnalisés qu'on peut déjà construire pour un AI Agent dans n8n, mais sans avoir à réimplémenter la logique de pause à chaque nouvel outil sensible. C'est aussi un garde-fou de plus contre les scénarios de prompt injection visant un agent IA : même si un contenu malveillant pousse l'agent à vouloir exécuter une action destructrice, l'outil gated s'interpose avant l'exécution réelle.

Subject et actor : qui a demandé, qui a validé

Autre détail qui compte pour une vraie piste d'audit : la trace conserve à la fois le subject (qui, ou quel processus, a demandé l'action — souvent l'agent IA lui-même, déclenché par un utilisateur) et l'actor (la personne humaine qui a effectivement approuvé). Cette distinction évite l'ambiguïté classique d'un log qui ne dirait que « action exécutée » sans préciser si c'est l'IA ou un humain qui en porte la responsabilité finale — une nuance qui devient centrale dès qu'un audit ou un régulateur pose la question.

Un audit trail n'est pas une garantie de vigilance humaine

Un horodatage fiable prouve qu'un humain a cliqué à un instant donné — il ne prouve pas qu'il a réellement lu et évalué ce qu'il approuvait. C'est un point documenté de longue date dans la recherche sur les systèmes automatisés : une étude de synthèse de Parasuraman et Manzey, publiée en 2010 dans Human Factors, montre que la « complaisance envers l'automatisation » (complacency) et le biais d'automatisation touchent aussi bien les novices que les experts, et ne disparaissent pas avec l'entraînement — un opérateur habitué à valider des demandes majoritairement légitimes finit par cliquer « approuver » sans réellement vérifier (Parasuraman & Manzey, 2010, Human Factors). Concrètement pour un circuit HITL n8n : un outil gated qui envoie des dizaines de demandes de validation par jour à la même personne perd vite son utilité si les demandes deviennent un réflexe plutôt qu'une vraie décision. Réservez le gating aux actions réellement à risque, pas à tout ce qu'un agent pourrait faire.

Où ça s'inscrit dans une démarche de conformité

Le principe qui sous-tend ces deux nouveautés — garder un humain identifiable en position de décision finale sur une action automatisée à enjeu — rejoint directement la notion de contrôle humain significatif développée par Santoni de Sio et van den Hoven dans un article de référence publié en 2018 dans Frontiers in Robotics and AI : un système automatisé reste sous contrôle humain acceptable seulement si les humains impliqués comprennent réellement ce qu'ils valident et en répondent (Santoni de Sio & van den Hoven, 2018). C'est exactement l'exigence de « supervision humaine » que pose le règlement européen sur l'IA pour les systèmes à risque — voir notre guide sur l'automatisation de la conformité AI Act avec n8n — et une brique utile pour documenter des preuves de conformité ISO 27001 ou SOC 2 : un horodatage natif, fiable, avec subject et actor distincts, est un élément de preuve qu'un auditeur reconnaît immédiatement, à condition qu'il vienne compléter un vrai processus de revue, pas le simuler.

Mettre à jour son instance

Sur n8n Cloud, la mise à jour est automatique : ces fonctionnalités arrivent sans action de votre part dès leur disponibilité générale. Sur une instance self-hosted, il faut être passé en version 2.35 ou plus récente — suivez la méthode de notre guide mettre à jour n8n sous Docker sans rien casser, et si votre instance accuse plusieurs versions de retard, notre rapport de migration avant la mise à jour 2.0 aide à repérer les changements cassants à traiter avant de sauter directement en 2.35.

En résumé

n8n 2.35 déplace une partie de ce qu'il fallait bricoler soi-même — horodatage d'une approbation, gel d'une action sensible d'un agent — directement dans le produit, sans configuration pour le premier point et avec un contrôle fin pour le second. Ça ne dispense pas de réfléchir à qui a le droit de valider quoi, ni de construire la couche de journalisation persistante et de reporting qui transforme un champ respondedAt en vraie piste d'audit exploitable en cas de contrôle. C'est précisément ce que package notre Pack Conformité & Audit (149 €) : questionnaire conversationnel, journalisation Supabase horodatée, relances automatiques et rapport de synthèse généré par IA — une base prête à brancher sur ces nouveaux mécanismes natifs plutôt qu'à réinventer depuis zéro.