Cette histoire résume probablement le mieux ma façon d'aborder la transformation IT.
Une intuition au départ, trois personnes pour la concrétiser, une direction à embarquer, une organisation à construire et un middleware qui, cinq ans plus tard, continue d'évoluer sans remettre en cause ses fondations.
C'est un peu long à raconter, mais c'est précisément dans le chemin parcouru que se trouve l'essentiel.
Chez Le Tanneur, l'un des projets les plus structurants que j'ai eu à initier et piloter est né d'un constat assez simple : la croissance du digital allait rendre les échanges entre les différentes applications du système d'information de plus en plus complexes.
E-commerce, ERP, CRM, outils logistiques et applications métiers devaient communiquer de manière fiable, rapide et évolutive.
Nous aurions pu continuer à développer des interfaces spécifiques entre chaque application.
Mais j'étais convaincu qu'il fallait prendre une autre direction.
Mon idée était de construire une couche d'orchestration centrale, maîtrisée en interne, capable non seulement de gérer les flux existants, mais aussi de devenir progressivement le socle de nouveaux processus métiers.
Autrement dit, il ne s'agissait pas simplement de répondre aux besoins du moment. Il fallait construire une capacité pour les besoins à venir.
C'est ainsi qu'a commencé l'histoire d'un tout nouveau middleware.
Lorsque j'ai proposé cette orientation, il n'y avait pas encore de CTO dans l'organisation.
Or, un projet de cette nature nécessitait une véritable vision d'architecture ainsi qu'un niveau d'expertise technique permettant de challenger les choix et d'accompagner leur industrialisation.
J'ai donc également porté le besoin de créer cette fonction.
La direction l'a validé. Nous avons recruté un CTO, puis un Lead Tech.
Le coeur du projet était né : trois personnes (dont 2 à temps partiel).
Le CTO, le Lead Tech et moi-même.
Nous nous sommes rapidement retrouvés alignés sur la même philosophie : construire une architecture pragmatique, ouverte, évolutive et suffisamment simple pour rester maîtrisable dans le temps.
Mon rôle couvrait l'ensemble du pilotage du projet : vision fonctionnelle, roadmap, planification, budget, gouvernance, coordination des parties prenantes et relation avec la direction.
Et parce que l'équipe était volontairement resserrée, la frontière entre pilotage et technologie pouvait parfois être fine. Notamment par le choix d'une forte autonomie sur l'infrastructure logicielle, permise notamment par Docker.
L'infra logicielle à l'équipe de développement et l'infra matérielle à l'équipe d'exploitation.
Cette organisation nous permettait de conserver un principe qui allait devenir central pour la suite : une petite équipe autonome, propriétaire de son produit, de son architecture et de sa capacité à la faire évoluer.
Nous n'avons pas commencé en décrétant que notre première idée serait nécessairement la bonne.
La première phase a été consacrée à la R&D et aux POC.
L'une des questions que nous souhaitions résoudre était simple : pouvions-nous construire une approche microservices suffisamment légère pour rester simple à exploiter et peu gourmande en ressources ?
Nous avons privilégié des technologies que nous maîtrisions déjà, tout en expérimentant plusieurs principes d'architecture.
Le choix de la base de données a notamment joué un rôle important, avec l'adoption d'une approche NoSQL, adaptée à la flexibilité que nous recherchions dans le traitement des flux et des données.
Mais le plus important n'était finalement pas le choix d'une technologie particulière.
C'était notre manière de décider.
Nous formulions une hypothèse, nous la testions, nous observions le résultat puis nous ajustions.
Cette logique de test & learn s'est ensuite étendue bien au-delà de l'architecture technique.
Elle est devenue une manière de conduire le projet.
Le POC devait démontrer que nous pouvions construire une plateforme modulaire et évolutive sans sacrifier la simplicité.
Une fois ce principe validé, nous pouvions passer à l'industrialisation.
Un middleware a cependant un défaut lorsqu'il faut obtenir l'adhésion d'une direction : il ne se voit presque pas.
Pas de nouvelle interface spectaculaire.
Pas de parcours utilisateur à présenter.
Pas de nouvelle homepage à faire tester.
Tout se passe en arrière-plan : échanges entre applications, transformation de données, orchestration, contrôle, automatisation, supervision et traitement des erreurs.
Une part importante de mon rôle a donc consisté à traduire cette vision technique en enjeux compréhensibles pour la direction.
Je n'avais aucun intérêt à expliquer en détail au comité de direction le fonctionnement d'une architecture microservices ou les subtilités de notre stack technique.
En revanche, il était indispensable d'expliquer ce que cette architecture apporterait à l'entreprise.
Davantage de maîtrise sur son SI.
Moins de dépendances.
Une capacité à intégrer plus rapidement de nouveaux outils.
Plus d'automatisation.
Une meilleure fiabilité.
Et surtout, une plateforme suffisamment souple pour répondre à des besoins que nous ne connaissions pas encore.
Nous portions également entièrement la construction du budget, du planning et de la roadmap, ainsi que leur suivi.
Convaincre la direction ne consistait donc pas uniquement à obtenir un accord initial.
Il fallait ensuite maintenir cette confiance dans la durée en montrant régulièrement où nous en étions, pourquoi certaines étapes étaient nécessaires et ce que chaque nouvel investissement rendait possible.
Pour moi, un projet IT structurant ne doit pas devenir une boîte noire réservée aux techniciens.
Le comité de direction devait pouvoir suivre nos avancées et comprendre les décisions importantes, sans pour autant être exposé à un niveau de détail inutile.
Nous avons donc mis en place une gouvernance volontairement lisible.
Cela supposait aussi de remettre en question une habitude particulièrement coûteuse : la réunion par défaut.
Avant cette transformation, certains sujets pouvaient réunir une dizaine de personnes sans réel leadership technique, avec peu de préparation et parfois sans décision claire en sortie.
J'ai cherché à inverser cette logique.
L'information devait pouvoir circuler de manière asynchrone.
La documentation devait être accessible.
Les responsabilités devaient être identifiées.
Et une réunion ne devait exister que lorsqu'elle permettait réellement de décider, arbitrer ou coordonner.
Nous sommes progressivement arrivés à une gouvernance beaucoup plus condensée.
Un COPIL mensuel d'une heure pouvait réunir jusqu'à quinze participants, avec une structure claire, des éléments de décision préparés en amont et un compte rendu synthétique rédigé en direct.
Ce fonctionnement permettait d'éviter la multiplication des réunions tout en maintenant un très bon niveau de visibilité pour la direction.
Il permettait aussi de replacer chaque personne là où elle apportait le plus de valeur.
Les équipes techniques pouvaient se concentrer sur la réalisation.
Les métiers intervenaient lorsque leur expertise était nécessaire.
La direction disposait des informations utiles pour décider et arbitrer.
En parallèle de l'architecture technique, j'ai progressivement structuré notre manière de piloter l'activité.
Nous nous sommes appuyés sur Jira pour la ticketisation et le suivi du travail, ainsi que sur Confluence pour documenter et partager la connaissance.
Nous avons adopté les principes de Scrum, tout en refusant d'en faire un cadre rigide.
La méthodologie devait servir le projet, et non l'inverse.
Notre fonctionnement a donc été adapté en permanence à la réalité du terrain, à la taille de l'équipe, aux contraintes techniques, aux urgences métiers et à la maturité croissante de notre organisation.
Backlog, priorisation, itérations, suivi des développements, burndown charts, weeklies opérationnelles et COPIL mensuels constituaient les principaux éléments du dispositif.
Mais nous ne considérions jamais l'organisation comme définitivement acquise.
Nous testions régulièrement de nouvelles manières de travailler.
Nous observions ce qui fonctionnait.
Nous ajustions ce qui devait l'être.
Nous abandonnions ce qui n'apportait pas suffisamment de valeur.
Finalement, nous appliquions à notre organisation le même principe qu'à notre produit : itérer plutôt que présumer.
Dès le départ, j'étais convaincu que le potentiel du middleware dépasserait largement le problème initial des flux e-commerce.
Une fois capable de connecter plusieurs systèmes, de transformer des données, de déclencher des actions, de contrôler des traitements et de gérer des règles métiers, il devenait possible d'imaginer des workflows beaucoup plus transverses.
Le middleware est progressivement devenu un véritable couteau suisse technologique.
Un nouveau besoin ne nécessitait plus systématiquement l'achat d'une nouvelle solution ou le développement d'une nouvelle intégration isolée.
Nous disposions désormais d'un socle sur lequel construire rapidement de nouveaux processus.
Cette différence est importante.
Nous n'avions pas seulement développé un outil capable de résoudre un ensemble de problèmes connus.
Nous avions créé une capacité d'adaptation.
Et c'est lorsqu'un besoin imprévu est apparu que cette capacité a démontré toute sa valeur.
L'un des meilleurs exemples est venu du marché américain.
En 2025, à la suite d'une évolution importante sur les règlementations douanières sur les colis expédiés aux US, il a fallu repenser tout le processus logistique sans impacter l'expérience de millions de clients américains.
A priori, tout le monde se souvient de cette séquence 🙂
Le sujet dépassait largement le périmètre IT.
Il concernait les équipes supply chain, logistique, e-commerce, mais également les partenaires logisticiens et les processus liés aux formalités douanières.
Les équipes internes ayant trouvé une solution, il fallait en mesurer la faisabilité.
Sans compter sur l'architecture que nous avions construite, qui nous avait permis proposer une réponse technique complète sous la forme d'un nouveau workflow automatisé.
Celui-ci prenait en charge plusieurs étapes du processus.
La transformation de données.
La génération automatique de documents nécessaires aux équipes douanières.
L'envoi automatique d'e-mails.
Les contrôles de cohérence.
La vérification de certaines erreurs et exceptions.
L'orchestration de l'ensemble des étapes entre les différents systèmes.
Une semaine de développement a suffi pour mettre en place ce workflow !
Cette adaptation a permis à la marque de continuer à expédier ses commandes vers les États-Unis malgré les nouvelles contraintes.
Pour moi, cet exemple résume parfaitement la valeur réelle du middleware.
Quelques années auparavant, une adaptation de cette ampleur aurait pu devenir un projet lourd, impliquant plusieurs systèmes, plusieurs intervenants, plusieurs prestataires et de nombreuses interfaces.
Nous avions désormais la capacité de transformer rapidement un processus métier transverse parce que nous avions investi auparavant dans une architecture maîtrisée.
C'est toute la différence entre répondre à un besoin ponctuel et construire une capacité durable.
Le projet a ensuite connu une autre évolution structurante.
En orchestrant les échanges entre de nombreuses applications, notre middleware se trouvait naturellement au centre d'une quantité importante de données provenant du système d'information.
ERP, CRM, e-commerce, tablet in store, caisses retail, logistique et différentes applications métiers produisaient chacun leur propre vision de l'activité.
Nous avons décidé d'exploiter cette position centrale.
Le middleware couplé à sa base de donnée non relationnelle, a vite servi comme véritable data lake, afin d'agréger les données issues des différents systèmes et de les rendre exploitables par une BI transverse.
Cette évolution changeait encore la nature de la plateforme.
Nous étions partis d'un problème d'intégration.
Nous avions ensuite créé une capacité d'orchestration.
Puis une capacité d'automatisation.
Nous pouvions désormais contribuer à centraliser, rapprocher et valoriser la donnée de l'entreprise.
Le système d'information devenait progressivement autre chose qu'une collection d'applications indépendantes.
Il devenait un écosystème capable de communiquer, d'automatiser ses processus et de consolider ses données.
Cette évolution a également renforcé notre conviction concernant l'internalisation des compétences.
Plus notre capacité technique augmentait, plus le champ des possibles s'élargissait.
Chaque nouveau développement n'était plus uniquement une réponse ponctuelle à une demande.
Il enrichissait un patrimoine technologique que nous pouvions réutiliser pour les projets suivants.
L'équipe connaissait de mieux en mieux les systèmes, les flux, les données et les contraintes propres à l'entreprise.
Cette connaissance cumulée nous permettait d'aller plus vite, mais aussi de proposer des solutions plus pertinentes.
Le développement interne ne représentait donc plus simplement une capacité de production.
Il devenait une capacité stratégique de transformation.
Cette logique me paraît encore plus importante aujourd'hui avec l'essor de l'intelligence artificielle.
Lorsqu'une entreprise maîtrise déjà ses données, ses flux, ses APIs, ses workflows et son architecture, l'IA ne vient pas remplacer cette maturité.
Elle peut au contraire la démultiplier.
Avec le recul, l'un des indicateurs dont je suis le plus satisfait est probablement le plus simple.
Cinq ans plus tard, les fondations du middleware sont toujours pertinentes.
Il n'a pas fallu jeter l'existant pour repartir sur une nouvelle architecture.
De nouveaux connecteurs ont été ajoutés.
De nouveaux workflows ont été créés.
De nouveaux usages sont apparus.
Le data lake et la BI sont venus élargir le périmètre initial.
Et pourtant, les principes fondateurs de la plateforme n'ont pas eu besoin d'être remis en cause.
Pour moi, c'est l'un des meilleurs indicateurs de qualité d'une architecture.
Une solution durable ne doit pas simplement fonctionner correctement au moment de sa mise en production.
Elle doit permettre à l'entreprise d'intégrer de nouveaux besoins quelques années plus tard sans transformer chaque évolution en projet de refonte.
Cette longévité tient à plusieurs choix réalisés dès le départ.
Une architecture modulaire.
Des technologies suffisamment maîtrisées.
L'internalisation de compétences clés.
Une forte connaissance des flux et des données.
Une équipe réellement propriétaire de son produit.
Et surtout, une volonté constante de penser au-delà du besoin immédiat.
Il ne s'agissait pas de prédire précisément ce que l'entreprise demanderait cinq ans plus tard.
Il s'agissait de construire une architecture suffisamment ouverte pour pouvoir y répondre le jour où ces besoins apparaîtraient.
Cette plateforme a accompagné plusieurs années de forte croissance de l'activité digitale.
Et c'est précisément ce que nous attendions d'elle.
Le système d'information ne devait pas devenir un facteur limitant à mesure que les volumes, les applications et les processus augmentaient.
Au contraire, l'architecture devait permettre au digital de continuer à évoluer tout en conservant un haut niveau de stabilité.
Sur cinq ans, le middleware a accompagné cette montée en puissance avec zéro interruption majeure du système.
Dans le même temps, le nombre de flux, de connecteurs, de processus automatisés et d'applications intégrées continuait à progresser.
La performance du projet ne se mesure donc pas uniquement au nombre de fonctionnalités développées.
Elle se mesure aussi à sa capacité à absorber le changement sans perdre en fiabilité.
Cette expérience a profondément façonné ma manière d'aborder les projets de transformation.
Pour moi, le rôle d'un chef de projet transformation ne consiste pas uniquement à recevoir un besoin, construire un planning et organiser sa livraison.
Il faut parfois être capable de voir une opportunité avant même qu'elle soit clairement formulée.
Construire le modèle permettant de la concrétiser.
Déterminer les compétences nécessaires.
Constituer l'équipe.
Expérimenter avant d'industrialiser.
Construire et défendre le budget.
Transformer une direction technique complexe en stratégie compréhensible.
Mettre en place la gouvernance.
Créer les conditions permettant à l'équipe d'avancer vite.
Et enfin, faire en sorte que le résultat continue à produire de la valeur plusieurs années plus tard.
La technologie n'est alors plus une finalité.
Elle devient un levier de transformation de l'organisation.
Cette expérience m'a aussi appris qu'une transformation IT ne se mesure pas uniquement le jour de sa mise en production.
Elle se mesure quelques années plus tard.
L'entreprise est-elle devenue plus autonome ?
Peut-elle intégrer plus rapidement de nouveaux besoins ?
Les équipes ont-elles gagné en maturité ?
L'architecture peut-elle évoluer sans devoir être reconstruite ?
Les données sont-elles plus facilement exploitables ?
Les nouveaux projets peuvent-ils s'appuyer sur ce qui existe déjà ?
Dans notre cas, cinq ans après les premiers POC, le middleware continue de remplir cette mission.
Nous n'avions pas simplement construit une solution à un problème donné.
Nous avions construit la capacité de répondre plus vite aux problèmes suivants.
Vous avez un enjeu de Transformation IT, Digitale ou IA, et vous cherchez à structurer une trajectoire concrète autour de vos systèmes, de vos données ou de vos futurs Agents IA ?
Échangeons sur la façon de transformer cette ambition en capacité durable pour votre entreprise.
N'hésitez pas à me contacter.
Un middleware est une couche logicielle qui permet à différentes applications de communiquer entre elles. Il peut notamment orchestrer les échanges entre un ERP, un CRM, un site e-commerce, des outils logistiques ou des applications métiers.
Au-delà du simple transfert de données, un middleware peut également transformer les données, automatiser des processus, gérer des règles métiers, contrôler les erreurs et déclencher des actions entre plusieurs systèmes.
Il n’existe pas de réponse universelle.
Une solution du marché peut être pertinente lorsqu’elle répond correctement aux besoins, aux contraintes techniques et aux ressources disponibles.
Un développement interne peut, lui, apporter davantage de maîtrise et de flexibilité lorsque les processus métiers sont spécifiques ou lorsque l’entreprise souhaite faire de cette capacité d’intégration un actif stratégique.
Le choix doit notamment prendre en compte le coût total, les compétences disponibles, la complexité du système d’information, les besoins futurs et le niveau d’autonomie recherché.
Un Proof of Concept permet de tester rapidement les hypothèses techniques les plus importantes avant d’engager une industrialisation plus coûteuse.
Il permet par exemple de valider un modèle d’architecture, d’évaluer certaines technologies, de mesurer les performances ou encore de vérifier que la solution reste suffisamment simple à exploiter.
Cette approche réduit le risque de figer trop tôt des choix techniques qui pourraient devenir difficiles à remettre en cause par la suite.
Un projet de middleware ou d’architecture produit rarement une interface spectaculaire à montrer à un comité de direction. Sa valeur doit donc être traduite en bénéfices compréhensibles pour l’entreprise.
Il peut s’agir de réduire certaines dépendances, d'accélérer l’intégration de nouveaux outils, d’automatiser davantage de processus, d'améliorer la fiabilité du système d’information ou encore de rendre l’entreprise plus réactive face à de nouveaux besoins.
Le sujet n’est alors plus seulement technique : il devient un sujet de capacité opérationnelle et de transformation.
Lorsque certaines compétences techniques sont conservées en interne, l’entreprise accumule progressivement une connaissance fine de ses systèmes, de ses flux, de ses données et de ses contraintes métiers.
Cette connaissance peut permettre d’aller plus vite sur les projets suivants et de capitaliser sur les développements déjà réalisés.
Le développement interne ne constitue alors plus uniquement une capacité de production : il devient une capacité d’adaptation et de transformation.