Middleware vs Mindware —
quand l'infrastructure commence à penser.
Et si la vraie révolution de l'IA dans les SI n'était pas dans les applications visibles, mais dans la couche qu'on a toujours considérée comme « juste un tuyau » ? De l'exécution statique à l'autonomie supervisée.
Pendant des années, le middleware a eu une réputation ingrate. Invisible quand ça marche, accusé en premier quand ça tombe. Une infrastructure de plomberie — nécessaire, critique, mais rarement glamour. On ne lui demandait pas de penser. On lui demandait de transporter.
Puis l'IA est arrivée dans les systèmes d'information. Et les regards se sont tournés vers les applications : les chatbots, les copilotes, les interfaces conversationnelles. On a habillé les façades.
Mais la transformation la plus profonde, elle se passe dans les tuyaux.
Ce qu'est le middleware — et ce qu'il était
Le middleware, c'est la couche logicielle qui fait communiquer des systèmes qui n'ont pas été conçus pour se parler. Un ERP SAP qui envoie des données à une plateforme partenaire via SFTP. Un flux EDI entre une banque et ses contreparties. Une API qui orchestre dix services distincts pour répondre à une seule requête.
Pendant trente ans, ce middleware a fonctionné selon un principe simple : des règles statiques, écrites par des humains, exécutées mécaniquement par des machines. Un fichier arrive dans ce format, il repart dans cet autre format, via ce protocole, avec cette transformation. Chaque règle, un ingénieur l'a écrite. Chaque cas limite, un développeur l'a anticipé — ou pas.
Un ensemble de règles statiques qui transportent de la donnée d'un point A à un point B. Il exécute. Il ne décide pas. Si la règle n'existe pas, il échoue. Si le format change, quelqu'un doit intervenir. Il est aussi intelligent que la dernière personne qui l'a configuré.
Une couche d'intégration qui observe, apprend, s'adapte et propose. Elle ne se contente pas d'exécuter des règles — elle comprend l'intention derrière ces règles. Quand quelque chose change, elle cherche une solution avant d'alerter. Elle augmente l'ingénieur au lieu de l'attendre.
Le Mindware — ce terme qui commence à circuler dans les cercles de l'architecture d'entreprise — n'est pas une rupture technologique. C'est une évolution de posture. Le middleware ne change pas de nature. Il change d'ambition.
Quand le tuyau commence à raisonner
Concrètement, qu'est-ce que ça change ? Prenons un exemple que je vis au quotidien : la gestion des flux SFTP avec des partenaires externes.
Dans un middleware classique, si un partenaire change son format de fichier sans prévenir, le flux échoue. Une alerte remonte. Un ingénieur intervient, analyse, corrige la règle de transformation, teste, redéploie. Temps moyen : quelques heures à quelques jours selon la criticité.
Dans un système augmenté par l'IA, la détection de l'anomalie déclenche une analyse automatique : le format a-t-il changé ? Y a-t-il un historique similaire ? Peut-on proposer une transformation alternative ? L'ingénieur reçoit non pas une alerte brute, mais un diagnostic avec une proposition de correction — qu'il valide ou ajuste. Il reste décisionnaire. Il n'est plus pompier.
Les niveaux d'autonomie — où en sommes-nous vraiment
Pour cadrer honnêtement cette évolution, j'aime utiliser une échelle d'autonomie — inspirée des niveaux de conduite autonome, adaptée à l'intégration.
Aujourd'hui, la majorité des systèmes d'entreprise oscillent entre le niveau 0 et le niveau 1. Les équipes les plus avancées atteignent le niveau 2. Le niveau 3 est accessible dès maintenant — c'est la direction vers laquelle je travaille dans mon périmètre.
L'humain augmenté — pas remplacé
La question qui revient toujours : « Et l'ingénieur dans tout ça ? »
Je vais être direct : l'ingénieur middleware qui refuse d'évoluer est effectivement en danger. Pas parce que l'IA va prendre son poste — mais parce que ses tâches les plus répétitives vont disparaître, et si c'est tout ce qu'il sait faire, il se retrouvera sans valeur ajoutée visible.
En revanche, l'ingénieur qui embrasse cette évolution devient quelque chose de différent et de beaucoup plus puissant : un architecte de systèmes autonomes. Il ne configure plus des règles — il définit des politiques. Il ne résout plus des incidents — il conçoit des systèmes qui se résorbent. Il ne surveille plus des flux — il pilote une infrastructure qui se surveille elle-même.
- Comprendre les enjeux métier derrière un flux technique
- Négocier avec un partenaire humain qui résiste au changement
- Prendre la responsabilité d'une décision en situation d'ambiguïté
- Concevoir une architecture qui anticipe des besoins encore inexistants
- Expliquer à un DSI pourquoi un choix technique engage toute une roadmap
Autonomie vs contrôle — la vraie question
Il y a un débat légitime que je ne veux pas esquiver : jusqu'où laisser un système décider seul ?
Dans des environnements financiers réglementés — et c'est mon quotidien chez Lazard — la réponse est claire et non négociable : l'autonomie s'arrête là où la responsabilité commence. Aucune activation de flux critique, aucune modification de configuration en production, aucun échange de données sensibles ne peut se faire sans une validation humaine tracée et auditée.
Ce n'est pas une limitation technologique. C'est un choix d'architecture. Et c'est le bon choix.
- Automatiser tout ce qui est répétitif et sans ambiguïté
- Assister l'humain sur tout ce qui est complexe mais analysable
- Escalader à l'humain tout ce qui engage une responsabilité
- Tracer et auditer chaque action automatique sans exception
- Ne jamais automatiser ce qu'on ne comprend pas encore complètement
Le middleware n'est pas en train de mourir.
Il est en train de grandir.
J'ai passé 15 ans à configurer, migrer, optimiser des plateformes que la plupart des gens dans une entreprise ne savent même pas nommer. Des systèmes qui brassent des téraoctets de données critiques dans l'ombre, sans UI, sans visibilité, sans reconnaissance.
Cette année, j'ai commencé à explorer concrètement l'IA dans ce périmètre. La motivation était simple : reprendre du temps sur des tâches qui n'auraient jamais dû m'appartenir. Les relances partenaires. Les alertes à 3h du matin pour des fichiers mal formatés. La rotation manuelle de 65 clés SSH par an.
Ce que j'ai découvert en chemin, c'est que le vrai potentiel de l'IA dans les SI n'est pas dans les applications visibles. Il est dans l'infrastructure invisible. Parce que c'est là que les décisions se prennent vraiment — à quelle vitesse les données circulent, dans quel format, avec quelle sécurité, sous quelle gouvernance.
Le Mindware n'est pas un produit qu'on achète. C'est une posture qu'on adopte. Et cette posture commence par une question simple : parmi toutes les tâches que je fais aujourd'hui, lesquelles méritent vraiment mon intelligence ?
Les autres, l'IA peut les prendre. Et elle le fera mieux que nous — plus vite, plus régulièrement, sans oublier, sans se fatiguer. Notre rôle est de concevoir les systèmes qui rendent ça possible — et de garder la main sur ce qui compte vraiment.
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, je travaille sur l'intégration de l'IA dans les processus opérationnels MFT.