Après Talend et Talaxie : pourquoi construire une plateforme plutôt qu'un autre fork

Talend Open Studio n'est plus maintenu. Talaxie, le fork* communautaire, garde les jobs Studio en vie — utile, honnête, mais c'est un pont, pas une destination. En face, Workato, Boomi, Informatica et les suites cloud proposent la même chose sous un autre emballage : louez la plateforme, écrivez votre logique dedans, payez tous les mois. Nous avons passé des années à intégrer des données pour des ETI* avec ces outils, et à un moment la même question a fini par revenir dans presque chaque salle de réunion DSI : comment synchroniser nos systèmes en gardant la main sur la logique, sans dépendre d'une poignée de spécialistes d'un format que plus personne ne saura relire dans cinq ans ?

Aucune des options du marché ne répondait vraiment à cette question. C'est de là qu'est né Portlane : pas pour ajouter un logo de plus au rayon des iPaaS*, mais pour combler ce trou précis — intégrer des données en temps réel, en Python, sous licence perpétuelle*, exécuté dans votre infrastructure. Le reste de cet article explique le raisonnement, sans détour.

Une précision d'entrée de jeu, parce qu'elle change la lecture de tout ce qui suit : Portlane est encore en développement. Ce texte décrit un pari produit et une manière de penser l'architecture, pas une brochure de disponibilité ni une migration que vous pourriez lancer cette semaine.

Ce que nous avons vu tourner en rond

Avant d'écrire une ligne de code, il faut être honnête sur le paysage. Aucun des constats qui suivent n'est une attaque contre un produit en particulier — ce sont les observations qui reviennent, année après année, sur le terrain.

Les jobs visuels ont vieilli. Ils ont démocratisé l'ETL* à une époque où c'était un vrai service à rendre, puis ils ont enfermé la logique dans un format que peu de gens savent relire hors du studio. Les forks* comme Talaxie achètent du temps sur cet héritage, ce qui est précieux, mais un pont n'est pas une fondation pour la décennie. Les iPaaS* en SaaS*, eux, déplacent le problème sans le régler : vous louez la couche qui fait tourner vos commandes et votre facturation, dans un format propriétaire, et vous découvrez le coût de sortie le jour où vous voulez partir. Quant aux grandes suites — MDM*, catalogue, gouvernance —, elles sont calibrées pour un autre profil d'organisation ; en ETI*, on les paie souvent en entier pour n'en exploiter qu'une fraction.

Le point commun de tout cela, c'est que le code a gagné la partie ailleurs. Revue en pull request, tests, CI/CD*, recrutement large : les équipes ne veulent plus que leur logique la plus critique vive uniquement dans un éditeur que trois personnes maîtrisent. C'est ce déséquilibre-là que Portlane essaie de corriger, et rien d'autre.

Ce que nous avons choisi de ne pas faire

Un produit se définit autant par ses refus que par ses fonctionnalités. Nous avons écarté quatre tentations, en connaissance de cause. D'abord le studio low-code* comme cœur du produit : la vitesse gagnée à la démo ne compense jamais dix ans de dette de format. Ensuite l'abonnement indexé sur l'usage : la couche qui fait circuler vos données ne devrait pas être une location mensuelle qu'on renégocie chaque année. Puis la suite BPM* / MDM* / catalogue : si vous en avez réellement besoin, gardez une suite qui les fait pour de vrai — Portlane ne prétendra pas les couvrir. Enfin le catalogue de connecteurs* brandi comme argument principal : les systèmes modernes exposent des API*, et le connecteur* certifié a cessé d'être le goulot d'étranglement par défaut.

Ces refus ont un avantage : ils dessinent une frontière nette. Portlane ne cherche pas à être Informatica en moins cher, ni Workato en self-hosted*. C'est un autre objet.

Ce que nous assumons à la place

Ce qui reste, une fois ces refus posés, tient en quelques partis pris cohérents. Du full-code* Python, versionné et testable, assisté par l'IA là où cela fait gagner du temps mais jamais caché derrière un canevas opaque. Une licence perpétuelle* : vous possédez le droit d'exécuter, et vos flux sont en source dans votre dépôt. Du self-hosted*, on-premise* ou cloud privé, selon votre choix d'infrastructure et non le nôtre. Un périmètre volontairement étroit — recevoir, transformer, livrer, avec des files d'attente* fiables entre les étapes et une supervision lisible. Et une honnêteté de calendrier que nous assumons aussi : le produit se construit, nous ne promettons pas une migration pour lundi matin.

Pourquoi pas seulement du conseil

La question mérite d'être posée, parce que BastionLab est d'abord une agence. Le conseil aide à choisir et à migrer, mais il ne laisse pas derrière lui une plateforme que l'équipe peut exploiter dix ans sans rappeler le prochain intégrateur. Nous avons voulu que le savoir-faire d'intégration cesse d'être prisonnier d'un format éditeur ou d'une prestation — qu'il reste dans le dépôt, relisible par l'équipe qui vit avec.

BastionLab continue donc son métier — comprendre, concevoir, déployer — pendant que Portlane porte le produit né de ce constat. Les articles de fond restent sur bastionlab.tech, notamment pourquoi on construit un outil data en interne et Talaxie, Talend, et la suite ; les comparatifs produit, eux, vivent ici. Même sujet, deux rôles distincts.

Pour aller plus loin

• L'urgence Open Studio : la fin de Talend Open Studio
• Le comparatif frontal : alternative à Talend
• Le pont et la destination : alternative à Talaxie
• Le débat de modèle : l'ESB est trop vieux
• La thèse de fond : louer sa plateforme data

Nous ne construisons pas Portlane pour convaincre ceux qui ont réellement besoin d'une suite grand compte — pour eux, ce serait un mauvais conseil. Nous le construisons pour ceux dont le besoin est plus simple qu'il n'y paraît, et qui paient aujourd'hui comme s'il ne l'était pas.

Questions fréquentes

Pourquoi ne pas simplement forker Talend comme Talaxie ?

Parce qu'un fork* prolonge un paradigme, il ne le remplace pas. Talaxie fait très bien ce pour quoi il existe : garder les jobs Open Studio en vie le temps qu'il faut. Mais on reste dans le même format, avec le même plafond à terme. Portlane part d'ailleurs — Python full-code*, propriété du code, licence perpétuelle*. Ce n'est pas la suite de Studio par d'autres moyens.

Pourquoi Python plutôt qu'un nouveau studio visuel ?

Parce que nous avons vu, chez trop de clients, ce que devient une logique métier enfermée dans un éditeur : personne ne la relit hors de l'outil, une seule personne sait vraiment la maintenir, et la sortie coûte cher le jour où elle se pose. Un nouveau studio propriétaire recréerait exactement ce plafond. Python se relit dans une pull request, se teste, se recrute et se transmet. C'est moins spectaculaire à la démo, mais cela tient dix ans.

Portlane est-il open source ?

Non. Licence perpétuelle*, flux en source dans votre dépôt, exécution sur vos serveurs. Ce n'est pas un projet communautaire comme Talaxie : c'est un produit que vous possédez, contractuellement et opérationnellement. La nuance compte le jour où vous devez rendre des comptes sur qui maîtrise quoi.

Portlane est-il disponible aujourd'hui ?

Non, et nous préférons le dire clairement. Développement actif, sans date de sortie publique. Cet article explique un raisonnement produit — le pourquoi — pas un plan d'achat pour ce trimestre.

Qui construit Portlane ?

Portlane est un produit de BastionLab. L'agence continue de faire son métier : conseil et intégration (le récit côté agence). Le site portlane.io porte la promesse produit. Deux marques, deux rôles, et nous tenons à ne pas les confondre.

Glossaire

• iPaaS (Integration Platform as a Service) : plateforme cloud qui connecte des applications et orchestre des flux d'intégration, en général sous abonnement.
• SaaS (Software as a Service) : logiciel loué en ligne, facturé à l'usage ou au siège, hébergé et opéré par l'éditeur.
• ETL : extraction, transformation et chargement de données, souvent par lots, d'un système source vers un système cible.
• API : interface qui permet à deux logiciels d'échanger des données de façon standardisée.
• BPM (Business Process Management) : orchestration de processus métier — validations, workflows, enchaînements de tâches.
• MDM (Master Data Management) : référentiel de données maître, une vision unique des clients, produits, etc.
• ETI : entreprise de taille intermédiaire, typiquement quelques centaines à quelques milliers de salariés en France.
• Fork : copie d'un logiciel open source reprise et maintenue par une autre équipe, souvent pour prolonger un produit abandonné.
• Low-code : approche où l'on construit des flux surtout via un studio graphique, avec peu ou pas de code écrit à la main.
• Full-code : approche où la logique d'intégration est écrite en code (ici Python), versionné et relisible comme le reste du SI.
• Self-hosted : logiciel installé et exécuté dans votre infrastructure, et non consommé comme un service distant de l'éditeur.
• On-premise : déploiement dans vos propres locaux ou votre datacenter, par opposition au cloud public de l'éditeur.
• Licence perpétuelle : droit d'utiliser le logiciel sans abonnement récurrent ; vous payez une fois (ou sur devis), vous continuez d'exécuter.
• Connecteur : module fourni par un éditeur pour brancher une application précise (CRM, ERP…) sur sa plateforme.
• CI/CD : intégration et déploiement continus — automatiser tests et mises en production à chaque évolution du code.
• File d'attente : mécanisme qui stocke les messages en attendant leur traitement, pour qu'une panne ne les fasse pas disparaître.