Créer un workflow n8n de modification de code avec approbation humaine et vérification des tests

Vue d’ensemble du workflow

Utilisez n8n pour permettre à un agent IA de proposer une modification dans un dépôt, mais soumettez l’opération d’écriture à une approbation humaine. Après une écriture approuvée, exécutez des tests sur le commit exact obtenu et communiquez le résultat. La fusion ou le déploiement doit faire l’objet d’une décision distincte.

La distinction essentielle est celle entre approbation de l’outil et approbation du résultat. Dans n8n, une étape de validation humaine peut suspendre un AI Agent avant l’exécution d’un outil donné. La personne chargée de la revue voit l’outil proposé et ses paramètres ; l’approbation exécute cet appel, tandis qu’un refus l’annule et en informe l’agent. Ce comportement est décrit dans le guide n8n sur l’humain dans la boucle.

OneMux donne accès à des modèles d’IA via une API compatible avec OpenAI. C’est une possibilité pour accéder aux modèles dans cette architecture, et non une intégration n8n vérifiée. Vérifiez la documentation de l’API OneMux ainsi que la configuration de votre nœud n8n au regard du point de terminaison et des paramètres que vous comptez utiliser.

Prérequis

• Une instance n8n avec un AI Agent, une connexion adaptée à un modèle de chat et l’accès à un canal de validation humaine, par exemple Slack ou n8n Chat.
• Une intégration à un dépôt ou un service personnalisé capable de lire une révision donnée et d’appliquer un correctif sur une branche hors production. Limitez les droits d’écriture de ses identifiants au dépôt et à la branche nécessaires.
• Un exécuteur de tests isolé des systèmes et des identifiants de production. Il doit accepter un identifiant de commit exact et renvoyer un statut ainsi qu’un lien ou une référence vers les résultats.
• Un compte OneMux et un accès à l’API si vous choisissez OneMux pour les appels aux modèles. Consultez le guide de démarrage rapide pour connaître les modalités de connexion actuelles et le catalogue de modèles pour choisir un modèle disponible.
• Un dépôt doté d’une commande de test connue, d’une branche par défaut protégée et d’une personne habilitée à examiner les modifications proposées.

Il s’agit d’un modèle de mise en œuvre, et non d’un workflow importable. Les outils de dépôt, l’intégration de l’exécuteur, le choix du modèle et les champs n8n exacts dépendent de votre environnement. En particulier, la documentation fournie ne permet pas d’établir qu’un modèle OneMux donné prend en charge l’appel d’outils nécessaire à un AI Agent n8n. Vérifiez cette prise en charge avant de vous appuyer sur cette architecture.

Concevoir le workflow autour d’une révision précise

Voici une séquence pratique :

1. Recevoir une demande. Récupérez le dépôt, la description de la tâche, la branche de travail cible, le commit de base et la commande de test autorisée à partir de la configuration de confiance du workflow.
2. Lire et proposer. Laissez l’agent examiner les fichiers concernés au commit de base et préparer un correctif. L’accès en lecture ne doit pas permettre de modifier le dépôt.
3. Faire examiner l’écriture. Faites passer l’outil d’application du correctif par la validation humaine n8n. La personne chargée de la revue approuve ou refuse l’appel d’outil proposé.
4. Appliquer et identifier. En cas d’approbation, le service d’écriture vérifie que la branche pointe toujours vers le commit de base approuvé, applique le correctif approuvé et renvoie l’identifiant du nouveau commit. Si la base a changé, il doit refuser l’opération et demander une nouvelle proposition et une nouvelle approbation.
5. Vérifier. Exécutez les tests configurés sur ce nouveau commit précis dans un exécuteur isolé. Consignez la commande, le commit, le statut et la référence aux résultats.
6. Communiquer les résultats. Envoyez le commit et le résultat des tests à la personne chargée de la revue et à la personne à l’origine de la demande. Un test échoué, annulé ou sans résultat ne constitue pas une réussite.

Il s’agit de mesures de contrôle recommandées, et non de fonctionnalités garanties par l’étape de validation humaine de n8n. En particulier, votre service de dépôt doit vérifier le commit de base et garantir que le correctif appliqué est bien celui qui a été approuvé.

Configurer la connexion au modèle

Dans n8n, choisissez une configuration de modèle de chat qui prend en charge un point de terminaison compatible avec OpenAI configurable et les appels d’outils nécessaires à votre AI Agent. Utilisez le point de terminaison, la méthode d’authentification et l’identifiant de modèle indiqués dans la documentation OneMux actuelle. Stockez les identifiants dans le système d’identifiants de n8n plutôt que dans les prompts ou les messages du workflow.

Avant d’accorder l’accès au dépôt, effectuez une requête de test simple et vérifiez que la réponse respecte le format attendu par le nœud n8n. Testez ensuite un appel d’outil sans risque. La compatibilité avec OpenAI ne signifie pas que tous les points de terminaison, paramètres ou formats d’appel d’outils sont interchangeables : cette compatibilité dépend de la prise en charge, par les deux parties, des requêtes et réponses nécessaires. Cette configuration n’a pas été testée pour cet article.

Si la connexion au modèle disponible ne prend pas en charge les appels d’outils de l’agent, ne contournez pas l’approbation en donnant directement au modèle des identifiants d’écriture. Utilisez une configuration compatible ou créez un transfert distinct vers le service d’écriture, soumis à une revue explicite.

Ajouter une validation humaine avant l’écriture dans le dépôt

Dans le nœud AI Agent, ouvrez le connecteur Tools et repérez Human review dans le Tools Panel. Choisissez un canal d’approbation et configurez ses identifiants. Connectez l’outil d’écriture dans le dépôt au connecteur d’outil de l’étape de validation. Séparez les outils en lecture seule lorsque cela s’y prête et soumettez tout autre outil susceptible de modifier un état externe à sa propre validation ou à un contrôle équivalent.

La documentation n8n indique que la personne chargée de la revue peut recevoir le nom de l’outil et les paramètres fournis par l’IA. Par exemple, configurez le message de validation comme suit :

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Utilisez un outil d’écriture dont les paramètres soumis à la revue incluent le dépôt, la branche, le commit de base et le correctif complet, ou une référence immuable à un correctif accompagnée d’une empreinte. Si le correctif est trop volumineux pour le canal, fournissez un emplacement sécurisé et accessible pour l’examiner, puis vérifiez que le service d’écriture applique exactement le même contenu. Une consigne vague telle que « corriger les tests » ne suffit pas pour approuver une modification précise du dépôt.

Les valeurs documentées de $tool.parameters comprennent les champs configurés avec des expressions $fromAI() ; ne supposez pas que le message expose tous les identifiants fixes, les valeurs de configuration masquées ou les effets en aval. Limitez les paramètres fixes et donnez aux personnes chargées de la revue un moyen distinct de les examiner. Évitez de placer des secrets dans les paramètres des outils, car ils peuvent apparaître dans les messages de validation.

Ajoutez une instruction système qui nomme l’outil soumis à validation et indique à l’agent comment réagir en cas de refus. Par exemple :

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

Cette instruction aide l’agent à gérer la revue ; elle ne constitue pas une frontière de sécurité. Appliquez les permissions et les restrictions de branche en dehors du prompt.

Vérifier la modification approuvée

Ne déclenchez l’exécuteur de tests qu’après que le service d’écriture a renvoyé un identifiant de commit. Configurez l’exécuteur pour récupérer ce commit, et non la dernière tête de branche, puis lancer une commande autorisée définie par votre équipe. Pour un dépôt dont les responsables ont choisi de l’utiliser, un exemple de commande pourrait être :

npm test

Cette commande est donnée à titre d’exemple ; suivez les consignes de test réelles du projet. Considérez le code du dépôt, les scripts d’installation des dépendances et les résultats des tests comme non fiables. Exécutez-les avec un accès réseau et au système de fichiers restreint, sans secrets de production, et avec des limites de temps et de ressources. Une suite de tests réussie montre uniquement que les vérifications sélectionnées ont réussi dans cet environnement ; elle ne prouve pas que la modification est sûre ou correcte.

Renvoyez un résultat concis indiquant la base approuvée, le nouveau commit, la commande de test, le statut réussite/échec et un lien vers les journaux. Si les tests échouent, l’agent peut proposer un correctif révisé, mais toute nouvelle écriture doit faire l’objet de sa propre approbation. Ne lancez pas automatiquement une fusion parce qu’une personne a approuvé l’appel d’outil précédent.

Dépannage et limites d’exploitation

La demande d’approbation manque de contexte utile

Vérifiez quelles entrées sont fournies par l’IA et visibles dans $tool.parameters. Incluez l’identité du correctif, la branche et la révision de base dans les entrées de l’outil soumises à la revue, ou fournissez un artefact de revue sécurisé et immuable. Si la personne chargée de la revue ne peut pas identifier précisément l’écriture, elle doit la refuser.

L’agent ne parvient pas à appeler l’outil

Commencez par tester un outil sans risque, indépendamment des permissions du dépôt. Vérifiez le nœud n8n, le point de terminaison OneMux, le modèle sélectionné et les paramètres d’appel d’outils requis à l’aide de leur documentation actuelle. Les sources fournies ne vérifient aucune combinaison particulière de modèle et de nœud.

La branche a évolué ou les tests ne sont pas terminés

Refusez une écriture devenue obsolète au lieu d’appliquer un correctif à une autre base. En cas d’expiration du délai, d’erreur de l’exécuteur ou d’absence de journal, indiquez que la vérification est incomplète. Relancez les tests sur le même commit si nécessaire ; demandez une nouvelle approbation si l’écriture proposée change.

Conclusion

La séparation utile est précise : une personne approuve une écriture spécifique dans le dépôt, puis un exécuteur isolé vérifie le commit obtenu. n8n fournit le mécanisme documenté de suspension et d’approbation au niveau des outils ; votre service de dépôt, votre exécuteur, vos permissions et votre processus de revue apportent les autres mesures de protection. N’utilisez OneMux comme couche d’accès aux modèles qu’après avoir confirmé que le point de terminaison et les paramètres choisis fonctionnent avec votre configuration n8n.

Sources

• n8n : Human-in-the-loop for tools — comportement de l’approbation des outils, configuration, canaux de revue et variables des messages de revue.
• Documentation OneMux — à consulter pour connaître les modalités de connexion actuelles à l’API.