IA pour intégrer : accélérer le Python, pas cacher la logique

En démo, le copilote iPaaS³ remplit un mapping en trente secondes. La salle applaudit. Trois mois plus tard, le flux touche commandes et facturation, et personne ne sait le relire hors de la console. Ce n'est pas un accident : c'est le format qui a gagné, pas l'équipe.

Portlane mise aussi sur l'IA. Pas sur le même pari. La question n'est pas « avec ou sans IA ». C'est où va la logique une fois générée : dans un format propriétaire que seul l'outil lit, ou dans du Python versionné que votre équipe possède.

Portlane est encore en développement. Ce texte pose une philosophie produit, pas une démo de fonctionnalités ni un plan de migration pour lundi matin.

Pourquoi Python

Ce n'est pas un choix esthétique. En ETI⁷, Python est le langage le plus pratique pour l'intégration de données : un collègue qui n'a pas écrit le flux peut le comprendre en une relecture ; clients HTTP, JSON, ORM et tests existent déjà, maintenus par la communauté ; le vivier de recrutement est plus large que toute compétence studio éditeur. Et les modèles génèrent du Python correct assez souvent pour accélérer le premier jet, à condition de relire.

C'est le pari de pourquoi nous construisons Portlane : le code a gagné ailleurs dans le SI, l'intégration ne devrait pas rester en marge.

IA dans un canvas vs IA vers du code

Deux modèles se présentent aujourd'hui. Le premier : l'IA écrit dans le canvas. Mapping, flux, règles, le tout dans un format que l'éditeur interprète. Difficile à auditer hors de l'outil, cher à exporter, dépendant des mises à jour produit. La promesse marketing : « plus besoin de coder ». Le second : l'IA écrit vers du code. Python dans votre dépôt, revue en pull request, tests et CI/CD⁶ comme le reste du SI. Vous possédez le source. Vous repartez avec la logique. La promesse, plus modeste : coder plus vite, avec relecture.

Portlane refuse le premier modèle. Voir aussi pourquoi pas de designer visuel : le refus du canevas et le pari IA vont ensemble.

Ce que l'IA peut faire (et ce qu'elle ne fait pas)

Sans hype, l'IA sert déjà à accélérer le premier jet : client API⁴, mapping de champs, squelette de transformation. Elle résume une spec OpenAPI⁵, propose des cas de test, explique une erreur, suggère un correctif à valider. Sur une migration, elle aide à traduire une logique métier documentée vers du Python. Elle n'importe pas magiquement un .car propriétaire.

Seule, elle ne comprend pas vos règles métier implicites, ne garantit pas la conformité réglementaire, et ne décide pas ce qui est critique. La relecture humaine reste non négociable pour les flux qui touchent commandes, stock et facturation.

Comment Portlane positionne l'IA

L'IA est un accélérateur, pas un remplacement : elle aide à écrire, l'équipe valide. Rien de généré n'est caché dans un runtime opaque. Le code IA passe par la même CI/CD⁶ que le code humain. Pas de lock-in¹³ IA : vous pouvez utiliser l'outil de votre choix en amont ; le livrable reste du Python standard. Le périmètre reste étroit : intégration de données, pas BPM⁸, pas MDM⁹, pas orchestration de processus.

Le runtime d'intégration (files d'attente¹⁰, supervision, rejeu) reste une brique que vous installez chez vous, sous licence à vie¹¹. L'IA n'est pas un prétexte pour repasser en SaaS¹².

Python vs jobs visuels à l'ère IA

L'argument « l'IA rend le low-code² obsolète » circule. Nous le formulons autrement : l'IA rend le code plus accessible, donc le full-code¹ devient compétitif là où le canvas gagnait par défaut.

Talaxie prolonge les jobs Talend ; Portlane part du code. Voir Portlane vs Talaxie pour le comparatif de modèles (un pont, pas une destination).

Quand ce modèle n'est pas pour vous

Ce n'est pas pour tout le monde, et autant le dire. Flux simples entre deux SaaS¹² standard, équipe sans compétence d'intégration et sans intention d'en construire, horizon court où le POC prime sur dix ans de maintenance : un iPaaS³ classique, éventuellement avec copilote, peut être rationnel. Voir par exemple Workato ou Boomi.

Portlane vise autre chose : les équipes IT et d'intégration qui refusent de louer leur logique critique dans un format qu'elles ne contrôlent pas. Propriété du code d'abord, vitesse de démo ensuite.

Pour aller plus loin

• Le refus du canvas : pourquoi pas de designer visuel
• Le pari fondateur : pourquoi nous construisons Portlane
• Talaxie et la suite : Portlane vs Talaxie
• Urgence Open Studio : fin de Talend Open Studio
• Comparatif Talend : alternative à Talend

Questions fréquentes

L'IA va-t-elle écrire tous les flux Portlane à ma place ?

Non. L'IA assiste l'écriture ; elle ne remplace pas la relecture, les tests ni la responsabilité de l'équipe. Le code généré reste du Python dans votre dépôt, soumis aux mêmes revues que le reste du SI.

En quoi c'est différent d'un iPaaS avec IA intégrée ?

Chez un iPaaS³, l'IA génère souvent du mapping ou des flux dans un format propriétaire, invisible hors de la console. Chez Portlane, l'IA produit du code lisible que vous possédez. Pas de logique cachée dans un canevas.

Faut-il être expert Python pour utiliser Portlane ?

Il faut une équipe capable de lire, revoir et maintenir du Python en production. Pas des experts du langage pour chaque ticket, mais au moins une compétence d'intégration qui sait ouvrir une pull request. Si personne dans l'organisation ne lit du code et que vous n'avez pas l'intention d'en recruter, Portlane n'est pas le bon modèle : un iPaaS³ avec canvas vous conviendra mieux. La différence, c'est que Python se recrute et se transmet ; une expertise studio éditeur, beaucoup moins.

Portlane fournit-il un copilote IA intégré ?

Le produit est en développement ; la philosophie est posée : l'IA accélère l'écriture, elle ne cache pas la logique. Les détails d'implémentation suivront, sans transformer Portlane en boîte noire. Vous pourrez aussi utiliser l'outil IA de votre choix en amont : le livrable reste du Python standard.

Portlane est-il disponible aujourd'hui ?

Non. Développement actif, sans date de sortie publique. Cet article décrit une orientation produit, pas une fonctionnalité livrée ce trimestre.

Glossaire

• ¹ Full-code : logique d'intégration écrite en code, versionnée et testable.
• ² Low-code : construction de flux via studio graphique, peu de code manuel.
• ³ iPaaS (Integration Platform as a Service) : plateforme cloud d'intégration, souvent sous abonnement.
• ⁴ API : interface d'échange entre logiciels.
• ⁵ OpenAPI : standard de description d'API REST.
• ⁶ CI/CD : intégration et déploiement continus.
• ⁷ ETI : entreprise de taille intermédiaire.
• ⁸ BPM (Business Process Management) : orchestration de processus métier.
• ⁹ MDM (Master Data Management) : référentiel de données maître.
• ¹⁰ File d'attente : stockage de messages en attente de traitement.
• ¹¹ Licence à vie : droit d'utiliser sans abonnement récurrent.
• ¹² SaaS (Software as a Service) : logiciel loué et hébergé par l'éditeur.
• ¹³ Lock-in : dépendance fournisseur qui rend la sortie coûteuse.