David Heath a publié en octobre 2024 un article très bien documenté sur l'avenir du MFT à l'horizon 2030. IA, cloud-native, edge computing, zero-trust, blockchain pour l'audit des transferts — la vision est cohérente, ambitieuse, et sur beaucoup de points, je la partage.
Mais elle est écrite depuis un angle stratégique et commercial. Moi j'écris depuis un datacenter, avec des tickets d'incident ouverts et des partenaires qui n'ont pas répondu depuis 400 jours.
Alors voilà ma version — celle d'un ingénieur qui vit avec ces systèmes au quotidien.
Référence : The Future of Managed File Transfer in 2030: Seamless, Secure, and Smarter — David Heath, octobre 2024.
Le Managed File Transfer, c'est l'infrastructure qui permet aux entreprises d'échanger des fichiers de manière sécurisée avec leurs partenaires, fournisseurs, clients et systèmes internes. Pas un simple FTP des années 90 — une plateforme avec chiffrement, authentification par clés SSH, protocoles normalisés (SFTP, FTPS, AS2, PESIT), journalisation complète, et gestion des erreurs.
Dans une banque comme Lazard, le MFT transporte des données financières critiques : relevés, rapports réglementaires, flux comptables, données de marché. Si ça tombe, ce n'est pas un inconvénient — c'est une interruption de service avec des conséquences réglementaires et opérationnelles immédiates.
Heath prédit que des systèmes IA vont surveiller les flux en temps réel et détecter les anomalies de manière autonome. C'est déjà partiellement vrai — mais aujourd'hui ça reste du monitoring passif avec des alertes. La vraie rupture viendra quand ces systèmes pourront agir : relancer un transfert échoué, notifier le bon interlocuteur, ouvrir le bon ticket, ajuster la configuration.
Je m'intéresse à cette question depuis quelques mois — les premiers tests sont encourageants. Ce qui prenait 2 heures de debugging manuel pourrait se résoudre en quelques minutes avec un agent qui sait lire les logs et corréler les erreurs.
Le modèle zero-trust est déjà une exigence dans les environnements financiers réglementés. Ce qui va changer d'ici 2030, c'est son implémentation systématique dans les échanges inter-entreprises — y compris avec des partenaires qui ont des maturités de sécurité très différentes.
Les plateformes MFT on-premise vieillissantes cèdent la place à des architectures hybrides. Axway lui-même a évolué dans ce sens avec B2Bi. La migration n'est pas simple — mais elle est inévitable. D'ici 2030, la majorité des nouvelles implémentations seront cloud-first par défaut.
Heath parle de NLP pour initier des transferts en langage naturel : "Envoie le rapport trimestriel à nos partenaires de Francfort." C'est séduisant. Mais dans la réalité d'un environnement MFT critique, chaque flux est le résultat de mois de configuration, de tests, et de validation sécurité. On ne va pas laisser une commande vocale déclencher un transfert vers un partenaire financier.
Ce que l'IA va vraiment apporter, c'est l'automatisation des processus autour du MFT, pas le MFT lui-même. La rotation des clés, la gestion des relances, le suivi des confirmations partenaires, la validation humaine avant activation. Tout ce qui est coordination et gouvernance, pas les transferts en eux-mêmes.
Rotation des clés, relances partenaires, escalades, validation humaine intégrée. Les flux restent supervisés par des ingénieurs, mais toute la coordination opérationnelle est prise en charge par des agents IA. C'est la direction que j'explore sur mon périmètre chez Lazard.
Les agents MFT ne se contentent plus d'exécuter — ils observent. Transferts anormaux, comportements suspects, clés à risque : le système détecte, corrèle et alerte avec du contexte. L'ingénieur reçoit un diagnostic, pas une alerte brute.
Les systèmes anticipent les incidents avant qu'ils surviennent. Ils prennent des actions correctives autonomes sur les cas connus et escaladent uniquement ce qui dépasse leur périmètre. L'humain supervise, il n'opère plus.
Les agents MFT commencent à interagir directement avec les systèmes partenaires — comparaison de schémas, proposition de formats optimisés, adaptation dynamique des configurations. L'onboarding d'un nouveau partenaire passe de plusieurs semaines à quelques jours.
Les plateformes MFT deviennent des services intelligents qui s'adaptent à leur contexte, génèrent automatiquement des rapports de conformité RGPD, DORA, NIS2, et s'auto-documentent. L'ingénieur MFT devient architecte de systèmes autonomes.
Peu importe les avancées technologiques, certaines réalités resteront constantes. Les partenaires auront toujours des niveaux de maturité technique très différents. Certains répondront en 24 heures, d'autres en 3 semaines. L'IA peut gérer les relances, mais elle ne peut pas forcer un DSI à prioriser votre demande de rotation de clé.
La réglementation va continuer à se complexifier. DORA, NIS2, RGPD — les équipes MFT devront composer avec des exigences de plus en plus granulaires. L'IA peut aider à s'y conformer, mais l'interprétation et la responsabilité restent humaines.
J'ai commencé par le cas le plus douloureux : la rotation des clés SFTP. Un processus manuel, répétitif, critique, et chronophage. Mon premier use case avec Claude AI cette année — un système multi-agents avec n8n conçu pour gérer tout ça de manière autonome, avec validation humaine intégrée à chaque étape clé. Le système est encore en construction, mais l'architecture est posée.
L'objectif : qu'une rotation qui mobilise aujourd'hui plusieurs heures d'attention ne nécessite plus que quelques minutes de validation humaine. Et surtout, que rien ne passe entre les mailles. Plus de clés expirées silencieusement. Plus de partenaires sans suivi.
Si vous êtes ingénieur MFT et que vous lisez ceci, mon conseil est simple : commencez par identifier votre tâche la plus répétitive et la moins valorisante. Pas la plus complexe — la plus répétitive. C'est là que l'IA fait la différence la plus immédiate, avec le moins de risque.
L'avenir du MFT n'est pas dans les salons ni dans les livres blancs. Il se construit maintenant, cas d'usage par cas d'usage, dans des équipes qui décident de ne plus subir leurs processus mais de les réinventer. C'est exactement ce que ce blog va documenter.

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. Ce blog documente ce que j'apprends en chemin.
MFT — Managed File Transfer — is the infrastructure that ensures files move securely between organizations. Not email attachments. Not FTP. Structured, auditable, encrypted flows that carry financial statements, regulatory data, supply chain information. The invisible backbone of inter-company exchanges.
At Lazard, we manage 65+ active MFT partners using protocols like SFTP, AS2, PESIT. These flows have a zero margin for error. A corrupted or delayed transfer can trigger regulatory consequences, financial penalties, broken SLAs.
In his October 2024 article, Heath identifies three major trends: AI-powered anomaly detection, zero-trust architecture applied to MFT, and the rise of cloud-native platforms. On these points, I largely agree.
AI anomaly detection is already technically feasible. A model trained on normal transfer behavior can flag deviations in real time — unusual volumes, suspicious IPs, off-hours transfers. It's the direction I'm working toward with n8n + Claude as my first use case.
Zero-trust applied to MFT is not optional anymore. DORA and NIS2 make it mandatory for financial and critical infrastructure. Every connection, every key, every certificate must be explicitly verified.
Heath mentions AI that could handle natural language configuration of transfers. Here I'm more cautious. On systems that move critical financial data, NLP-based configuration introduces ambiguity that I'm not ready to accept. In MFT, precision beats convenience.
What AI will really bring is automation of the processes around MFT, not MFT itself. Key rotation, follow-up management, partner confirmation tracking, human validation before activation. All the coordination and governance, not the transfers themselves.
Key rotation, partner follow-ups, escalations, human validation. Flows remain supervised by engineers, but coordination is handled by AI agents. This is the direction I'm exploring on my perimeter at Lazard.
MFT agents stop just executing — they observe. Abnormal transfers, suspicious behavior, at-risk keys: the system detects, correlates and alerts with context. Engineers receive a diagnosis, not a raw alert.
Systems anticipate incidents before they happen. They take autonomous corrective actions on known cases and escalate only what falls outside their scope. The human supervises — no longer operates.
MFT agents begin interacting directly with partner systems — comparing schemas, proposing optimized formats, dynamically adapting configurations. Partner onboarding goes from weeks to days.
MFT platforms become intelligent services that adapt to their context, automatically generate GDPR/DORA/NIS2 compliance reports, and self-document. The MFT engineer becomes an architect of autonomous systems.
Partner maturity will continue to vary enormously. Some send test keys from personal Gmail accounts. Others have IS security teams that are stricter than ours. AI cannot compensate for a partner with no internal processes.
Regulatory complexity will not simplify. DORA, NIS2, GDPR, PCI DSS — each has its specificities. An AI can help monitor and document, but the interpretation and responsibility remain human.
Start with your most repetitive task. For me it was key rotation. 100 hours per year, zero added intelligence, high error risk. Automate it first. Then build on that foundation.
Document your flows now. An AI agent can only be as good as the quality of the data it has access to. Clean logs, complete Airtable bases, structured schemas — this is the prerequisite for everything else.

ESIEA engineering graduate, 15 years on production MFT platforms — Axway B2Bi, Gateway, Integrator, CFT. Previously at AIFE, Groupama, Arval BNP Paribas and SFR Distribution.