Pas de catalogue de connecteurs : le connecteur n'est plus le goulot

« Nous avons 400 connecteurs certifiés. » C'est souvent la première slide d'un iPaaS¹². Portlane n'aura pas cette slide, et ce n'est pas parce que nous n'avons pas encore eu le temps de la dessiner.

Le catalogue de connecteurs¹ a été l'argument central des plateformes d'intégration pendant quinze ans : branchez Salesforce, SAP, votre ERP⁶ sans réinventer la roue. C'était vrai à une époque où chaque système parlait un dialecte différent. Ce n'est plus le goulot d'étranglement par défaut.

Portlane est encore en développement. Ce qui suit est un choix produit assumé, pas une feuille de route de connecteurs.

Ce que le catalogue promettait

• Couverture : un module prêt pour chaque application du marché.
• Maintenance éditeur : les mises à jour d'API² sont gérées par le fournisseur du connecteur¹.
• Support contractuel : en cas de panne, vous appelez l'éditeur, pas Stack Overflow.
• Vitesse de démo : glisser un connecteur¹ Salesforce, mapper deux champs, applaudissements.

Pour un paysage SI hétérogène des années 2005 à 2015, cela tenait. Pour une ETI⁹ qui synchronise un CRM⁷ cloud, un ERP⁶ et trois outils métier SaaS⁸ en 2026, le connecteur¹ exotique est devenu l'exception, pas la règle.

Ce qui a changé

Quatre déplacements rendent le catalogue moins central :

• Les API² sont la norme. REST⁴, GraphQL⁵, webhooks³ : les systèmes modernes exposent des interfaces documentées. Voir API vs webhook.
• Le connecteur¹ retarde parfois. Vous attendez que l'éditeur iPaaS¹² mette à jour le module quand l'API² source change, ou vous contournez avec du code custom de toute façon.
• La logique métier est le vrai coût. Brancher deux systèmes prend une journée. Faire évoluer les règles de transformation pendant dix ans, c'est là que l'argent part.
• La dépendance se déplace. Vous ne dépendez plus du protocole exotique : vous dépendez de la feuille de route connecteurs¹ de votre éditeur.

C'est le même constat que dans l'ESB est trop vieux : le problème structurel s'est résorbé, le packaging commercial n'a pas suivi.

Catalogue vs API + code

• Branchement. Catalogue : module certifié, mapping visuel. API + code : client HTTP, authentification, appels documentés.
• Évolution API². Catalogue : vous attendez la mise à jour éditeur. API + code : vous adaptez votre code, versionné et testé.
• Logique métier. Catalogue : souvent enfouie dans le mapping. API + code : transformations explicites en Python.
• Dépendance. Catalogue : feuille de route et tarification éditeur. API + code : votre dépôt, votre CI/CD¹⁵.
• Sortie. Catalogue : reconnecteurs¹ à réapprendre ailleurs. API + code : vous repartez avec la logique.
• Périmètre honnête. Catalogue : vendu comme couverture universelle, souvent utilisé à 10 %. API + code : vous codez ce que vous branchez, rien de plus.

Ce que Portlane assume à la place

Des intégrations en full-code¹⁴ Python qui parlent directement aux API² et webhooks³ de vos systèmes. Des patterns et de la documentation pour les cas courants, pas un catalogue brandi comme promesse principale.

• Vous possédez la logique : elle vit dans votre dépôt, pas dans un module propriétaire.
• Vous contrôlez le rythme : pas d'attente de certification éditeur quand l'API² évolue.
• Vous payez le périmètre réel : pas une suite entière pour trois connecteurs¹ utilisés.
• Licence à vie¹⁶ : la couche d'intégration n'est pas une location mensuelle.

Ce refus va de pair avec pourquoi pas de designer visuel : moins de packaging, plus de propriété.

Quand le catalogue reste le bon choix

• Systèmes legacy¹⁰ sans API² : fichiers plats, protocoles industriels, EDI¹¹ lourd.
• Contrainte contractuelle ou secteur public sur des connecteurs¹ certifiés.
• Équipe sans compétence d'intégration et sans volonté de la construire.
• Besoin de support éditeur sur chaque brique branchée, au-delà de l'intégration de données.

Dans ces cas, MuleSoft, Boomi, Blueway ou un iPaaS¹² classique peut être rationnel. Portlane ne prétend pas couvrir ce périmètre. Voir qu'est-ce qu'un iPaaS pour cadrer la catégorie.

Pour aller plus loin

• Le pari fondateur : pourquoi nous construisons Portlane
• Le refus du canvas : pourquoi pas de designer visuel
• Le modèle économique : pourquoi pas de pricing à l'usage
• ESB et connecteurs : l'ESB est trop vieux

Questions fréquentes

Sans catalogue de connecteurs, comment brancher un ERP ou un CRM ?

Via des API² documentées, des webhooks³ ou des appels planifiés, comme le font déjà la plupart des intégrations modernes. Le connecteur¹ certifié a cessé d'être le goulot d'étranglement par défaut quand les systèmes exposent des interfaces standardisées.

Les connecteurs certifiés ne garantissent-ils pas la fiabilité ?

Ils garantissent une couverture éditeur et un support contractuel, utile dans certains contextes. Ils ne garantissent pas que votre logique métier sera plus simple à maintenir. Et ils créent une dépendance à la feuille de route de l'éditeur iPaaS¹².

Portlane proposera-t-il des connecteurs un jour ?

Des helpers et des patterns pour les API² courantes, oui, pas un catalogue brandi comme argument principal. Le pari : vos intégrations vivent en code Python, pas en modules propriétaires que l'éditeur décide de maintenir ou d'abandonner.

Quand le catalogue de connecteurs reste-t-il indispensable ?

Quand vous branchez des systèmes legacy¹⁰ sans API², des protocoles industriels ou des formats exotiques que vous ne voulez pas réécrire. Dans ces cas, une suite avec catalogue certifié (ESB¹³, iPaaS¹² grand compte) reste souvent le bon choix.

Portlane est-il disponible aujourd'hui ?

Non. Développement actif, sans date de sortie publique. Cet article pose un refus produit, pas une offre commerciale.

Glossaire

• ¹ Connecteur : module fourni par un éditeur pour brancher une application précise (CRM, ERP…) sur sa plateforme.
• ² API : interface qui permet à deux logiciels d'échanger des données de façon standardisée.
• ³ Webhook : notification HTTP envoyée par un système quand un événement se produit.
• ⁴ REST : style d'architecture d'API largement utilisé, basé sur HTTP et des ressources identifiées par URL.
• ⁵ GraphQL : langage de requête pour API, alternative à REST pour certains cas.
• ⁶ ERP : progiciel de gestion intégré (commandes, stocks, facturation, comptabilité).
• ⁷ CRM : logiciel de gestion de la relation client.
• ⁸ SaaS (Software as a Service) : logiciel loué par abonnement et hébergé par l'éditeur.
• ⁹ ETI : entreprise de taille intermédiaire.
• ¹⁰ Legacy : système hérité, souvent sans API moderne.
• ¹¹ EDI (Electronic Data Interchange) : échange structuré de documents entre organisations.
• ¹² iPaaS (Integration Platform as a Service) : plateforme cloud d'intégration, souvent avec catalogue de connecteurs.
• ¹³ ESB (Enterprise Service Bus) : bus de services d'entreprise, souvent avec catalogue de connecteurs certifiés.
• ¹⁴ Full-code : logique d'intégration écrite en code, versionnée et testable.
• ¹⁵ CI/CD : intégration et déploiement continus.
• ¹⁶ Licence à vie : droit d'utiliser le logiciel sans abonnement récurrent.