Pas de designer visuel : un refus produit, pas une lacune

Dans presque chaque démo d'iPaaS³ ou d'ETL⁴, quelqu'un fait glisser un bloc, relie deux flèches, et la salle applaudit. C'est spectaculaire. C'est exactement le format que nous refusons pour Portlane.

Un designer visuel, c'est un studio graphique où l'on construit des flux par blocs et flèches, souvent dans un format que seul l'outil sait interpréter. Ce n'est pas par snobisme technique que nous l'écartons. C'est parce que nous avons passé des années à reprendre des flux que personne ne savait plus relire hors du studio : tenus par une seule personne, impossibles à tester proprement, chers à sortir le jour où la question se pose. Un designer visuel propriétaire recrée ce plafond. Nous préférons un produit moins tape-à-l'œil en démo et plus tenable en production.

Portlane est encore en développement. Ce texte décrit un choix d'architecture, pas une brochure de disponibilité.

Ce que le designer visuel promet

Le pitch est séduisant et souvent vrai sur le court terme :

• Vitesse de mise en route : brancher deux systèmes sans écrire de code.
• Accessibilité : des profils moins techniques peuvent construire des flux simples.
• Documentation implicite : le schéma montre le chemin des données.
• Catalogue intégré : connecteurs⁶, mappings et transformations prêts à l'emploi.

Pour une synchronisation ponctuelle entre deux SaaS⁵, ou pour un POC⁷ de quinze jours, cela tient. Le problème commence quand le flux devient critique (commandes, stock, facturation) et que vous devez le faire évoluer pendant dix ans.

Ce que nous avons vu sur le terrain

Le schéma ci-dessous n'est pas une attaque contre un éditeur en particulier. C'est le pattern qui revient, année après année :

• Mois 1 à 6 : le flux est construit vite, la démo est convaincante, tout le monde est content.
• An 2 à 3 : la logique a grossi, le schéma ne tient plus sur un écran, les règles métier sont enfouies dans des sous-flux.
• An 5 et plus : une seule personne connaît le job, les tests sont manuels, la revue de code n'existe pas, et sortir coûte plus cher que rester.

Talend Open Studio, Blueway, les iPaaS³ avec canvas : le packaging change, la dette de format⁸ reste. Voir la fin de Talend Open Studio et pourquoi nous construisons Portlane pour le contexte.

Designer visuel vs code

Démo vs dix ans de maintenance : le designer gagne la première, le code gagne la seconde.

• Démo. Designer : impressionnant en cinq minutes. Code : moins spectaculaire, plus explicite.
• Revue. Designer : difficile à relire hors de l'outil. Code : pull request, diff, commentaires, comme le reste du SI.
• Tests. Designer : souvent manuels ou absents. Code : tests unitaires, CI/CD¹¹, rejeu automatisé.
• Recrutement. Designer : compétence liée à l'éditeur. Code : Python se recrute et se transmet.
• Sortie. Designer : export propriétaire, souvent illisible. Code : vous repartez avec votre logique.
• Évolution. Designer : le schéma devient une carte illisible. Code : refactorisation, modules, découpage, pratiques d'ingénierie classiques.

Ce que Portlane fait à la place

Du full-code² Python, versionné et testable, dans votre dépôt : relue en revue, testée en CI. L'IA peut aider à écrire plus vite, mais le résultat reste du code lisible, pas un artefact caché dans un canevas. Voir Python, intégration et IA.

• Supervision lisible : santé des flux, rejeu, journal, sans que la logique métier vive dans l'UI.
• Files d'attente¹² fiables entre les étapes : recevoir, transformer, livrer.
• Périmètre étroit : intégration de données, pas BPM⁹, pas MDM¹⁰, pas catalogue de connecteurs⁶ comme argument principal.
• Licence à vie¹³ : vous possédez le droit d'exécuter, chez vous.

Nous ne disons pas que le low-code¹ est inutile partout. Nous disons qu'il n'est pas le bon cœur pour une plateforme que vous devez posséder sur dix ans.

Quand un designer visuel reste le bon choix

• Flux simples, non critiques, entre applications SaaS⁵ standard.
• Équipe sans compétence d'intégration et sans ambition de la construire.
• Horizon court : le POC⁷ prime sur la maintenance.
• Vous acceptez le coût de sortie et la dépendance au format éditeur.

Dans ces cas, Workato, Boomi ou un iPaaS³ classique peut être rationnel. Portlane n'est pas fait pour gagner cette course. Il est fait pour les équipes qui refusent de louer leur logique critique dans un format qu'elles ne contrôlent pas.

Pour aller plus loin

• Le pari fondateur : pourquoi nous construisons Portlane
• Python et IA : Python, intégration et IA
• Le refus du catalogue : pourquoi pas de catalogue de connecteurs
• Définition iPaaS : qu'est-ce qu'un iPaaS

Questions fréquentes

Un designer visuel n'accélère-t-il pas la mise en production ?

Oui, sur les premières semaines. C'est précisément le piège : la vitesse de démo ne se paie pas au même endroit que la vitesse de maintenance. Nous avons vu trop de flux critiques devenir illisibles hors du studio, tenus par une seule personne. Un designer visuel propriétaire recrée ce plafond.

Portlane n'aura vraiment aucune interface graphique ?

La supervision, la santé des flux et le rejeu auront une console lisible, c'est indispensable pour l'exploitation. Ce que nous refusons, c'est le studio low-code¹ comme cœur du produit : la logique métier ne vit pas dans un canevas que seul l'outil sait interpréter.

L'IA ne remplace-t-elle pas le besoin d'un designer ?

L'IA aide à écrire du Python plus vite, pas à cacher la logique derrière un format opaque. Voir Python, intégration et IA. Le code généré reste du code : versionné, relu, testé.

Et les équipes métier qui ne savent pas coder ?

Elles existent, et elles ont souvent besoin d'outils de sync simples entre deux SaaS⁵. Ce n'est pas le cœur de cible de Portlane. Nous visons les équipes d'intégration et d'IT qui doivent posséder la logique critique sur dix ans, pas gagner une démo en cinq minutes.

Portlane est-il disponible aujourd'hui ?

Non. Développement actif, sans date de sortie publique. Cet article explique un refus produit, pas un plan d'achat pour ce trimestre.

Glossaire

• ¹ 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ée et relisible comme le reste du SI.
• ³ iPaaS (Integration Platform as a Service) : plateforme cloud qui connecte des applications et orchestre des flux, en général sous abonnement.
• ⁴ ETL : extraction, transformation et chargement de données, souvent par lots.
• ⁵ SaaS (Software as a Service) : logiciel loué en ligne, hébergé par l'éditeur.
• ⁶ Connecteur : module fourni par un éditeur pour brancher une application précise sur sa plateforme.
• ⁷ POC (Proof of Concept) : preuve de concept, démonstration limitée dans le temps pour valider une approche.
• ⁸ Dette de format : coût de maintenance et de sortie lié à un format propriétaire que seul l'outil éditeur sait interpréter.
• ⁹ BPM (Business Process Management) : orchestration de processus métier.
• ¹⁰ MDM (Master Data Management) : référentiel de données maître.
• ¹¹ CI/CD : intégration et déploiement continus (automatiser tests et mises en production).
• ¹² File d'attente : mécanisme qui stocke les messages en attendant leur traitement.
• ¹³ Licence à vie : droit d'utiliser le logiciel sans abonnement récurrent.