Développeur de flux Stambia et Semarchy xDI à Lille : ce que change un freelance qui connaît le terrain

Quand une entreprise de la métropole lilloise me contacte pour ses flux d'intégration, la demande est rarement « écris-moi un mapping ». C'est plutôt : « le batch de la nuit a planté, personne ne sait pourquoi, et le prestataire qui l'avait construit est parti il y a deux ans ». Voilà le vrai métier d'un développeur de flux Stambia sur le terrain — autant diagnostiquer l'existant que produire du neuf. Et dans le Nord, entre les sièges retail de Lille, Roubaix et Villeneuve-d'Ascq, ces flux font tourner des catalogues produits, des stocks et des commandes qui ne peuvent pas s'arrêter.

Stambia est devenu Semarchy xDI après le rachat de 2020. Le moteur n'a pas changé de philosophie : on y travaille toujours par mappings, process et templates, avec une exécution sans serveur dédié lourd. Mais beaucoup de plateformes en production tournent encore sous les anciennes versions Stambia, et savoir naviguer entre les deux mondes fait une vraie différence au quotidien.

Pourquoi Stambia / Semarchy xDI plutôt qu'un autre ETL ?

L'argument que je donne le plus souvent aux équipes qui hésitent : l'approche E-LT. Là où un ETL classique transforme la donnée sur son propre moteur avant de la charger, xDI génère du code natif (SQL, scripts) exécuté directement sur la base cible. Concrètement, on ne déplace pas des millions de lignes vers un serveur d'intégration pour les ramener ensuite — on laisse la base faire le travail qu'elle sait faire. Sur un référentiel produit retail de plusieurs millions de SKU, l'écart de performance n'est pas anecdotique.

L'autre force, c'est le système de templates. Une logique de chargement écrite une fois (gestion des rejets, horodatage, comparaison incrémentale) se rejoue sur des dizaines de flux sans copier-coller. C'est aussi le piège : un template mal pensé au départ contamine tout le projet. J'ai repris des plateformes où chaque correctif devait être appliqué à la main sur quarante mappings parce que personne n'avait industrialisé la couche template. C'est exactement le genre de dette qu'on paie cher trois ans plus tard.

Le quotidien d'une mission : trois situations qui reviennent

1. Reprendre des flux hérités sans documentation

C'est la demande numéro un. Un projet a été livré, le consultant est parti, et il reste un répertoire de mappings dont personne ne connaît la logique métier. Mon premier réflexe n'est pas de réécrire — c'est de cartographier : quelles sources alimentent quoi, quels process s'enchaînent dans les sessions, où sont les points de rupture. Tant qu'on n'a pas cette carte, toute modification est un pari. Une fois qu'elle existe, on peut enfin corriger sereinement et, souvent, supprimer des flux morts qui consomment de la fenêtre batch pour rien.

2. Concevoir de nouveaux flux propres

Pour du neuf, je passe du temps en amont sur les conventions : nommage, gestion centralisée des rejets, traçabilité des exécutions. Ça paraît bureaucratique au début, mais c'est ce qui permet à l'équipe interne de reprendre la main sans moi. Un bon flux Semarchy xDI, c'est un flux qu'un autre développeur comprend en dix minutes — pas une boîte noire qui ne tourne que sur ma machine.

3. Migrer de Stambia vers Semarchy xDI

La migration arrive quand le support des vieilles versions devient un risque. Ce n'est pas un simple « clic et ça passe » : il faut auditer les composants utilisés, repérer ce qui a changé côté runtime et métadonnées, et tester flux par flux. Je traite ça comme une migration applicative à part entière, avec un environnement de recette et une bascule progressive — jamais un big bang un vendredi soir.

Pourquoi le « à Lille » compte vraiment

On pourrait croire que l'intégration de données se fait entièrement à distance, et une bonne partie l'est. Mais sur les sujets sensibles — un référentiel produit, une connexion à un ERP, une bascule de production — la proximité change la donne. Être à une heure de Lille, Roubaix ou Valenciennes, c'est pouvoir venir une journée en atelier avec les équipes métier quand le sujet coince, au lieu d'enchaîner les visios où personne n'ose dire que le besoin réel n'est pas celui écrit dans le ticket.

Les Hauts-de-France concentrent un tissu retail et e-commerce dense, avec des systèmes d'information qui ont grandi par couches successives. Ces environnements ont justement besoin de quelqu'un qui parle aussi bien aux DSI qu'aux opérationnels du flux. C'est tout l'intérêt d'un développeur freelance ancré dans la région plutôt que d'une ressource off-shore qui découvre le contexte à chaque ticket.

Stambia, xDI et le reste de l'écosystème d'intégration

Rares sont les missions où xDI vit seul. Il dialogue avec des bases SQL Server ou Oracle, des API REST, parfois un ESB côté temps réel, et de plus en plus avec des marketplaces via Mirakl. Un développeur de flux utile aujourd'hui ne se limite pas à son outil : il comprend la chaîne complète, depuis le système source jusqu'au catalogue exposé au client final. C'est ce que m'ont appris quinze ans passés en grande partie dans le retail et l'e-commerce, où la donnée n'a de valeur que quand elle arrive juste, au bon endroit, au bon moment.

Côté développement, mon ancrage .NET / C# aide souvent : quand un flux a besoin d'un connecteur sur mesure, d'un service Windows pour orchestrer, ou d'un petit outil pour rejouer des rejets, je le construis sans devoir sous-traiter. Vous trouverez le détail de cette partie sur ma page développement .NET sur mesure.

Les erreurs que je vois le plus souvent

• Pas de gestion de rejets centralisée : chaque flux gère ses erreurs à sa façon, et le jour où ça casse, on ne sait plus où chercher.
• Du tout-ou-rien sur les chargements : un flux qui plante au milieu laisse la cible dans un état incohérent, faute de logique transactionnelle ou de reprise.
• Aucune trace d'exécution : sans horodatage ni journal, impossible de prouver qu'un flux a bien tourné, ni de mesurer combien de temps il prend réellement.
• Des templates figés trop tôt : on industrialise une mauvaise idée et on la démultiplie sur tout le projet.

Aucune de ces erreurs n'est dramatique prise isolément. C'est leur accumulation qui transforme une plateforme d'intégration en zone que plus personne n'ose toucher. Mon travail consiste autant à éviter ce point qu'à en sortir les équipes qui y sont déjà.

En résumé

Un bon développeur de flux Stambia ou Semarchy xDI ne se juge pas au nombre de mappings produits, mais à la tranquillité qu'il laisse derrière lui : des flux lisibles, traçables, et une équipe capable de continuer sans lui. Si vous cherchez ce profil dans la métropole de Lille ou plus largement dans les Hauts-de-France, que ce soit pour reprendre un existant fragile, concevoir une nouvelle chaîne d'intégration ou piloter une migration, parlons-en.