Et si votre partenaire avait
aussi un agent IA ?
L'onboarding MFT aujourd'hui, c'est 6 semaines d'emails, de relances et d'allers-retours manuels. Imaginez ce processus dans un monde où les deux parties ont un agent IA. Ce n'est pas de la science-fiction. C'est là où on va — et ça change tout.
Un onboarding MFT, aujourd'hui, c'est une danse à sens unique. Mon équipe envoie les spécifications techniques. Le partenaire lit, répond, interprète parfois à sa façon. Des allers-retours. Des formats incompatibles. Des clés générées avec les mauvais algorithmes. Un test de transfert raté. Un deuxième. Une semaine de silence. Une relance. Six semaines plus tard — si tout se passe bien — le partenaire est actif.
J'ai automatisé mon côté de cette danse — ou plutôt, j'y travaille. Mon premier use case avec Claude AI cette année : un agent qui doit envoyer les emails, gérer les relances, valider les tokens, activer dans Axway. Pas encore en production, mais l'architecture est posée et les tests avancent. Mais le partenaire, lui, répond toujours à la main.
Alors j'ai commencé à me poser la vraie question : qu'est-ce qui se passe quand lui aussi a un agent ?
L'onboarding aujourd'hui — une chronologie honnête
Avant d'imaginer le futur, regardons le présent sans l'habiller. Voici ce qu'un onboarding MFT standard ressemble vraiment, depuis le terrain.
Six semaines en moyenne pour un onboarding "simple". Trois mois pour un partenaire avec une DSI lente. Et dans les deux cas, l'immense majorité du temps n'est pas du travail — c'est de l'attente.
Maintenant : imaginez les deux côtés avec un agent
Voici la question qui m'obsède depuis plusieurs semaines : si on pose un agent IA de chaque côté de la table, qu'est-ce qui se passe réellement ?
Ce n'est pas un fantasme. Dans 18 à 24 mois, les entreprises qui ont commencé à automatiser leurs processus aujourd'hui vont avoir des agents opérationnels. Les early adopters sont déjà en train de construire. Et à un moment, deux agents vont se retrouver en face à face.
Voici à quoi ça pourrait ressembler — un dialogue entre deux agents lors d'un onboarding MFT. Mon agent chez Lazard (Agent-A), celui du partenaire (Agent-B), avec validation humaine des deux côtés.
Lazard
Partenaire
Partenaire
Partenaire · humain
Partenaire
Lazard
Lazard · humain
Lazard
Ce dialogue m'a pris 3 heures à écrire en imaginant chaque étape. Dans la réalité, ce même échange prendrait moins de 2 heures — contre 6 semaines aujourd'hui. Pas parce que les vérifications sont sautées. Parce qu'elles sont faites instantanément, en parallèle, sans temps mort.
Ce qui change vraiment — et ce que ça implique
La réduction du temps est spectaculaire. Mais ce n'est pas le plus important. Ce qui change vraiment, c'est la nature même de l'interaction.
La négociation devient instantanée et documentée
Dans l'exemple ci-dessus, l'écart sur la plage horaire a été détecté, escaladé, validé et intégré en moins de 15 minutes. Aujourd'hui, ce type d'écart génère une semaine d'emails. L'agent ne "fait pas semblant" d'avoir compris — il analyse la contrainte, identifie le delta, propose une résolution, et attend la validation humaine uniquement si c'est nécessaire.
Et tout est tracé. Chaque échange, chaque décision, chaque exception accordée : un log structuré, horodaté, auditable. Le RSSI ne reconstruit plus l'historique après coup. Il l'a en temps réel.
Les erreurs de configuration disparaissent avant le test
Combien de fois ai-je reçu une clé RSA-2048 alors que je demandais ED25519 ? Combien d'onboardings ont pris deux semaines de plus parce que le format de fichier était UTF-16 au lieu d'UTF-8 ? Dans un monde agent-à-agent, l'Agent-B vérifie les spécifications avant de générer quoi que ce soit. Il lit, compare, valide, et génère conforme. Le test de connexion devient une formalité — pas un diagnostic.
Le rôle humain se déplace vers ce qui compte
Dans mon exemple, il y a deux interventions humaines : la RSSI du partenaire valide l'exception de plage horaire, la RSSI de Lazard valide l'activation en production. Deux décisions qui engagent une responsabilité. Tout le reste — la vérification technique, la génération de clé, les tests, la mise à jour des systèmes — est délégué aux agents.
Ce n'est pas "retirer l'humain du processus". C'est le repositionner exactement là où son jugement a de la valeur.
Le flux complet — agent-à-agent
Les questions que ça soulève — et qui sont légitimes
Cette vision est séduisante. Mais elle ne va pas sans poser des questions sérieuses que je veux adresser honnêtement.
- Si les deux agents sont configurés par des humains différents avec des conventions différentes, qui arbitre les ambiguïtés de spécification ?
- Un agent peut être mal configuré, compromis, ou simplement mal informé — et propager une erreur à vitesse machine
- La traçabilité est excellente — mais qui est responsable quand deux agents prennent une mauvaise décision ensemble ?
- L'interopérabilité entre agents de vendeurs différents n'est pas encore standardisée — chaque implémentation a ses propres conventions
- La vitesse accrue rend le contrôle humain plus difficile à exercer réellement — le risque de validation "en aveugle"
Ces risques ne invalident pas la vision. Ils définissent le travail à faire. Et ce travail commence maintenant — pendant qu'on a encore le temps de construire les bonnes fondations.
- Des spécifications techniques au format machine-readable — pas des PDFs, des JSON ou des schémas structurés
- Des protocoles de communication inter-agents standardisés — un "langage commun" pour l'onboarding B2B
- Des checkpoints humains bien définis — où s'arrête l'autonomie des agents, où commence la responsabilité
- Des logs d'audit structurés et exportables depuis le premier jour — pas rajoutés après coup
- Une gouvernance claire sur ce qu'un agent peut décider seul — et ce qu'il doit escalader sans exception
Ce que ça signifie pour l'ingénieur MFT
Il y a une question que j'entends souvent, à peine voilée : "Si les agents gèrent l'onboarding, qu'est-ce qu'on fait ?" La réponse courte : on fait enfin le travail pour lequel on est le mieux placé.
Personne ne peut configurer un agent pour qu'il négocie correctement si personne ne comprend ce qu'il négocie. Les spécifications techniques, les contraintes de sécurité, les implications réglementaires, les particularités de chaque partenaire — tout ça reste humain. L'agent exécute. L'ingénieur définit les règles du jeu.
Ce qui change, c'est la proportion du temps. Aujourd'hui, 80% du temps d'un onboarding est de la coordination, du suivi, de la relance. Demain, ces 80% seront gérés par des agents — et l'ingénieur pourra consacrer son énergie aux 20% restants : l'architecture, la sécurité, les cas exceptionnels, la gouvernance.
Le monde agent-à-agent n'est pas loin.
Mais il ne se construira pas tout seul.
Je construis mon premier use case cette année : un agent conçu pour gérer la rotation des clés, les relances partenaires, la validation HITL. C'est un côté de la table — le mien. Pas encore en production, mais la direction est claire.
L'autre côté sera prêt dans 2 à 3 ans pour les organisations qui commencent maintenant. Peut-être 5 ans pour celles qui attendent que ça devienne la norme. L'écart se creuse déjà.
La question que je me pose chaque semaine n'est plus "est-ce que l'IA va changer le MFT ?" Elle est : "Est-ce que je serai prêt quand mon partenaire arrivera avec son propre agent ?"
La bonne nouvelle : construire pour un monde agent-à-agent, ça commence exactement de la même façon que ce que je documente sur ce blog. Un cas d'usage. Une automatisation. Un agent bien gouverné. Brique par brique.
Et quand les deux côtés seront prêts, l'onboarding qui prenait 6 semaines prendra une matinée.
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. Aujourd'hui consultant chez Lazard, j'explore comment les agents IA peuvent transformer le MFT de l'intérieur.