J'ai automatisé la rotation des clés SFTP
avec N8N & Claude AI — architecture complète.
Au moins 65 rotations par an — une par partenaire, parfois plus. 65 partenaires. Une politique RSSI qui ne transige pas. Et une équipe MFT qui faisait tout ça à la main depuis des années. J'ai construit un système multi-agents n8n + Claude AI avec validation humaine double canal. Voici l'architecture complète, les prompts système, les bugs réels, et ce que j'ai appris.
- Le problème à 100 heures par an
- Airtable — la source de vérité
- Architecture multi-agents
- Workflow 2 — Gmail Trigger & Email Router
- Workflow 1 — Main Orchestrator
- Les 7 bugs qui m'ont coûté du temps
- Le Classifier — simple ou complexe
- Règles absolues de l'orchestrateur
- Le HITL — validation double canal
- Ce que j'ai appris
Le problème à 100 heures par an
Chez Lazard Frères Gestion, nous opérons 65 partenaires MFT actifs en production. Une vingtaine utilisent SFTP avec authentification par clé SSH — le reste utilise FTPS avec certificats, ou des protocoles propriétaires. Notre politique RSSI impose la rotation annuelle obligatoire de toutes les clés SFTP. Sans exception. Sans dérogation possible.
Le processus tel qu'il existait avant : identifier les partenaires concernés dans un tableur, rédiger un email à chacun avec la nouvelle clé publique générée manuellement, attendre leur confirmation (et relancer si silence), mettre à jour manuellement dans Axway B2Bi, noter le statut dans le suivi. Simple sur le papier. En pratique : 4 heures par rotation en moyenne, des confirmations qui traînent, des relances oubliées, et des statuts jamais à jour au bon moment.
Pire : ce process dépend entièrement de la disponibilité d'une personne. Si cette personne est en congé pendant une rotation critique, tout s'arrête. Il n'y a pas de mémoire système. Tout est dans les têtes et dans les emails.
Architecture multi-agents — vue d'ensemble
J'ai fait le choix de n8n comme orchestrateur bas niveau pour une raison précise : la capacité à construire des sub-workflows autonomes connectés entre eux, avec une granularité de contrôle que les platforms as-a-service ne permettent pas facilement. Claude AI tourne dans chaque agent comme LLM backbone via @n8n/n8n-nodes-langchain.lmChatAnthropic.
L'architecture se compose de deux workflows principaux et quatre agents spécialisés qui s'appellent en tant que sub-workflows :
→ Set Trigger Auto
Text + Voice (Whisper)
Tokens HITL · Auto-reply
Règles absolues · Mémoire fenêtrée · Format réponse strict
Statuts · B2Bi sim
Logging Notes
Analyse réponses
Relances J+3/J+7
Email + Telegram
Token unique
Événements activation
Escalade J+7
Ce qui rend cette architecture solide : aucun agent n'agit seul. L'orchestrateur décide toujours. Les agents ne sont que des bras — ils exécutent des tâches discrètes et remontent leur résultat. C'est une distinction fondamentale avec une architecture "agent loop" classique où l'agent prendrait ses propres décisions.
Workflow 1 — Main Orchestrator
Le workflow principal a trois points d'entrée distincts qui convergent vers le même orchestrateur :
scheduleTrigger se déclenche chaque matin à 8h. Le nœud Set Trigger Auto construit automatiquement le message d'entrée : "Date : [jour] — Scan automatique quotidien — vérifie toutes les clés SFTP et déclenche les actions nécessaires." L'orchestrateur part en autonomie totale.
Le Classifier — simple ou complexe ?
C'est l'un des détails architecturaux les plus fins du projet. Avant d'engager le gros orchestrateur Claude Sonnet pour chaque message Telegram, un agent léger basé sur Claude Haiku 4.5 catégorise le message en une seule valeur : "simple" ou "complexe".
Si simple → réponse directe sans appels d'outils, latence nulle. Si complexe → passage à l'orchestrateur complet avec tous ses agents. Ce pattern Classifier → Routeur réduit drastiquement les coûts d'inférence et la latence pour les interactions quotidiennes banales ("C'est bon pour Acme Corp ?" → réponse en 1 seconde au lieu de 8).
Pattern à retenir : utiliser un modèle léger comme gate avant un modèle puissant est l'un des optimisations les plus efficaces dans un système multi-agents. Le coût d'un appel Haiku est ~20x inférieur à un appel Sonnet. Pour des dizaines d'interactions quotidiennes, ça compte.
Le HITL — validation humaine double canal
Le HITL (Human In The Loop) est la pièce maîtresse du système du point de vue sécurité. Aucune activation B2Bi ne peut se faire sans validation humaine préalable. Ce n'est pas une option — c'est hardcodé dans le system prompt de l'orchestrateur comme règle absolue.
J'ai choisi une validation double canal simultanée. La logique : maximiser la probabilité d'une réponse rapide, quel que soit le contexte où se trouve le validateur.
- Canal email : notification structurée complète avec résumé de la rotation, détails du partenaire, token unique au format
MFT-YYYYMMDD-HHMMSS(regex/MFT-\d{8}-\d{6}/i), et lien de validation direct. Le RSSI reçoit l'intégralité du contexte pour une décision éclairée. - Canal Telegram : alerte courte (max 100 caractères, sans accents pour éviter les erreurs byte offset) avec boutons inline Approuver / Refuser. Taillé pour une validation en mobilité, en quelques secondes.
- Règle de priorité : le premier canal à répondre déverrouille le webhook
resume. Le second est ignoré. Pas de double validation possible sur le même token. - Timeout : si aucune réponse sous 24h, le système escalade automatiquement avec notification RSSI par email.
Règle critique découverte en test : après validation HITL par email (token OUI), l'orchestrateur ne doit pas re-déclencher un HITL Telegram. C'est la seule et unique validation requise. J'ai dû l'écrire explicitement dans le system prompt après avoir eu des boucles de double-validation lors des premiers tests.
Airtable — la source de vérité unique
Toute la gouvernance repose sur une table Airtable SFTP_Partners. C'est la mémoire persistante du système — chaque agent lit et écrit dans cette table. Aucun état n'existe en dehors d'elle.
| # | Partenaire | Date expiration | Statut | Date email envoyé | Date confirmation | Date activation B2Bi | Nb relances | Notes échange |
|---|---|---|---|---|---|---|---|---|
| 1 | Acme Corp | 15/9/2026 | Nouveau | — | — | — | 0 | — |
| 2 | Beta Solutions | 20/8/2024 | En attente | 2/6/2024 | — | — | 1 | En attente de confirmation partenaire. |
| 3 | Gamma Industries | 10/7/2027 | Activé | 25/2/2026 | — | — | 0 | 2026-02-25 — Email de confirmation reçu |
| 4 | Delta Partners | 1/10/2024 | Actif | 4/6/2024 | 6/6/2024 | 7/6/2024 | 0 | Processus fluide. |
| 9 | Iota Consulting | 18/7/2024 | Escalade | 8/6/2024 | — | — | 3 | Troisième relance. [2026-02-24] Escalade RSSI. |
Les statuts forment un cycle d'états strict : Nouveau → Email envoyé → En attente → Confirmé partenaire → Activé. Un statut ne peut pas régresser (sauf correction manuelle). L'escalade est un état terminal qui requiert intervention humaine pour être résolu.
- Statut (Single Select) : c'est le champ qui a causé le Bug #1. Il retourne un objet
{name: "Activé"}— pas une string directe. Toutes les comparaisons doivent utiliser.name. - Notes échange (Long Text) : journal horodaté de chaque action. L'orchestrateur y appende systématiquement ses actions via Technical Agent. Aucune action sans trace.
- Nombre relances (Number) : incrémenté à chaque relance. Trigger d'escalade à 3.
- Date activation B2Bi (Date) : renseignée uniquement après validation HITL et simulation B2Bi réussie.
Workflow 2 — Gmail Trigger & Email Router
C'est le workflow le plus sophistiqué en termes de logique de filtrage. Chaque email reçu doit être catégorisé et routé vers le bon traitement — sans jamais déclencher d'action parasite sur un email interne, un auto-reply, ou un email sans lien avec le système.
Le workflow traite les emails entrants via un pipeline de filtres en cascade avant de les passer à l'orchestrateur :
Ce pipeline de filtrage est essentiel. Sans lui, l'orchestrateur recevrait des emails d'absence de bureau comme des confirmations partenaires, des tokens de validation interne comme des questions techniques. J'ai appris ça à la dure lors des premiers tests.
La détection du token HITL mérite une attention particulière. Le filter utilise deux conditions en OR : le token peut être dans le sujet ou dans le corps de l'email (regex /MFT-\d{8}-\d{6}/i). Certains clients email reformatent le sujet lors du reply — il faut couvrir les deux.
Le system prompt de l'Email Orchestrateur
Une fois filtré, chaque email arrivant d'un partenaire connu passe à l'orchestrateur email, qui détermine la nature de la réponse et déclenche l'action appropriée :
Les 7 bugs qui m'ont coûté du temps
La partie que j'aurais voulu lire avant de commencer. Chaque bug ici représente entre 30 minutes et une demi-journée de débogage.
Le champ Single Select d'Airtable retourne {name: "Confirmé", color: "..."} et non la string "Confirmé" directement. Toute comparaison === "Confirmé" échoue silencieusement — aucune erreur, juste des conditions qui ne se déclenchent jamais.
Ce bug a affecté 3 nœuds de condition différents dans le workflow. Tous les champs Single Select Airtable sont concernés.
Les messages Telegram contenant des caractères spéciaux français (é, è, ç, à, ù) provoquaient des erreurs de parsing Telegram API avec des messages d'erreur du type "Can't parse message: byte offset N". Telegram attend du UTF-8 pur mais certains encodages en n8n ajoutent des caractères de contrôle.
Le nœud Merge qui attendait la réponse des deux canaux HITL (email + Telegram) se déclenchait dès qu'un seul canal répondait, sans attendre l'autre. Résultat : le workflow continuait avec des données incomplètes ou traitait deux fois la même validation.
Le Gmail Trigger capturait les emails envoyés par le workflow lui-même — notamment les emails "Re: Rotation clés SFTP" en réponse aux partenaires. L'orchestrateur se retrouvait à analyser ses propres messages comme si c'était des réponses partenaires, créant des boucles infinies.
Après réception d'un email de validation avec token OUI, l'Email Orchestrateur re-déclenchait parfois le HITL Agent "pour confirmer sur Telegram aussi". Ce comportement n'était pas inscrit dans le code mais dans le raisonnement LLM — l'orchestrateur pensait que deux validations valaient mieux qu'une.
Moral de l'histoire : ce qui semble évident pour un humain doit être écrit explicitement pour un LLM qui prend des décisions autonomes.
J'ai ajouté des champs Airtable au fil des besoins pendant le développement. Certaines formules calculées référençaient des noms de champs qui avaient été renommés entre-temps. Les erreurs de formule Airtable ne se propagent pas comme exceptions dans n8n — elles retournent simplement des valeurs nulles.
Les messages vocaux Telegram ne peuvent pas être transcrits directement depuis l'URL fournie par le trigger — l'URL expire très rapidement. Il faut d'abord télécharger le fichier audio avec un nœud Telegram dédié, puis passer le binaire à Whisper pour transcription.
Les règles absolues de l'orchestrateur
Le system prompt de l'orchestrateur principal contient une section de règles absolues qui ne peuvent jamais être overridées par les inputs utilisateur. C'est la zone de sécurité du système.
Ce que j'ai appris en construisant ça
1. Le schéma de données d'abord
J'aurais dû concevoir le schéma Airtable complet avant d'écrire la moindre ligne de workflow. Ajouter des champs au fil de l'eau a causé le Bug #6 et m'a coûté deux jours de refactoring. La règle : modéliser tous les états possibles d'un partenaire avant de coder la moindre transition.
2. Les LLMs prennent des décisions surprenantes
Le Bug #5 m'a appris quelque chose d'important : ce qu'on considère comme évident pour un humain ("une validation suffit") doit être écrit explicitement dans le system prompt. Un LLM raisonnant de manière autonome peut parfaitement décider que deux validations valent mieux qu'une — et ce n'est pas une erreur de raisonnement, c'est une inférence valide depuis son point de vue. La précision du system prompt est tout.
3. Tester avec de faux partenaires d'abord
Les premiers déclenchements réels ont révélé 3 bugs simultanément. Un environnement de test dédié avec des partenaires factices (ligne Airtable avec une adresse email de test) est indispensable. Tester les filtres Gmail avec des emails envoyés depuis différents clients pour couvrir les edge cases d'encodage.
4. La mémoire fenêtrée a ses limites
Le memoryBufferWindow en n8n conserve un nombre limité de messages en contexte. Sur des workflows longs avec beaucoup d'interactions, l'orchestrateur peut "oublier" des décisions prises en début de session. Pour les processus critiques, la source de vérité doit toujours être Airtable, pas la mémoire de conversation.
5. La latence perçue compte
Le pattern "Typing Action + Message Patience" (nœuds Telegram qui envoient un indicateur de frappe pendant que l'agent travaille) change fondamentalement l'expérience utilisateur. Sans ça, 8 secondes de silence sur Telegram semblent une éternité. Avec l'indicateur de frappe, ça semble naturel.
6. Documenter les invariants dans le code
Chaque règle absolue du system prompt devrait aussi exister comme commentaire dans le workflow n8n. Le system prompt peut changer ; les nœuds de filtrage représentent des invariants durs qui ne dépendent pas du LLM.
Ingénieur diplômé de l'ESIEA, 15 ans d'expérience sur des plateformes MFT en production — Axway B2Bi, Gateway, Integrator, CFT. Passé par l'AIFE, Groupama, Arval BNP Paribas et SFR Distribution. Actuellement en exploration de l'intersection entre middleware industriel et IA agentique.