Connecteur : raccourci commercial ou vraie nécessité technique ?

La démo iPaaS⁵ dure douze minutes. L'éditeur glisse un bloc « Salesforce », un bloc « SAP », une flèche entre les deux. Le comité est convaincu. Personne ne demande ce qui se passe quand le champ custom métier n'existe pas dans le connecteur¹, ou quand Salesforce change une API² que le connecteur¹ n'a pas encore absorbée.

Un connecteur¹ est un module qui encapsule l'accès à une application cible depuis une plateforme d'intégration : authentification, pagination, mapping des objets, gestion d'erreurs. C'est un raccourci pour ne pas réécrire l'appel API² à chaque projet. Ce n'est ni l'API² elle-même, ni une garantie de couverture métier.

Ici, on clarifie le mot. Le refus produit (pourquoi Portlane ne brandit pas un catalogue) est traité à part : pourquoi pas de catalogue de connecteurs.

Connecteur vs API native

• API² native : contrat documenté par l'éditeur de l'application (REST, GraphQL, etc.). Vous codez l'appel.
• Connecteur¹ : couche intermédiaire de la plateforme d'intégration qui parle à l'API² pour vous, avec une UI ou un format propriétaire.
• Connecteur¹ certifié : version validée par l'éditeur de l'application ou co-maintenue. Marketing et support, pas garantie absolue.

Physiquement, presque tout connecteur¹ finit par appeler une API². La différence qui compte en comité : où vit la logique (dans votre dépôt, ou dans le tenant de la plateforme), et qui la maintient le jour où l'API² bouge.

Ce que le catalogue fait bien

Il faut être juste. Les catalogues (Workato, Boomi, MuleSoft, Talend Cloud) aident quand :

• Vous branchez beaucoup d'applications SaaS⁴ rapidement.
• Les objets visés sont standards (contact, commande, facture générique).
• L'équipe maîtrise déjà le studio de la plateforme.
• Le time-to-market prime sur la portabilité à dix ans.

Pour une ETI⁹ qui synchronise quinze outils cloud de confort, le catalogue est un bon outil. Le problème commence quand on l'étend à la couche critique sans mesurer la dépendance.

Ce que le catalogue cache

• Couverture partielle : vos champs custom, vos règles, vos environnements exotiques ne sont pas dans la démo.
• Obsolescence : l'application cible évolue ; le connecteur¹ suit avec retard, ou plus du tout si l'éditeur iPaaS⁵ dépriorise.
• Coût : connecteurs¹ premium, paliers de volume, renégociation annuelle.
• Enfermement : la logique de branchement vit dans le format éditeur, pas dans votre Git.

Le chiffre « 400 connecteurs » sur une slide ne dit rien sur les deux dont vous avez besoin. Voir louer sa plateforme data pour le modèle économique qui accompagne souvent ces catalogues.

L'ère des API : le connecteur perd son excuse

En 2005, brancher un ERP⁸ demandait souvent un adaptateur propriétaire, un protocole obscur, un connecteur¹ certifié unique. En 2026, la plupart des logiciels que vous intégrez exposent des API², des webhooks³, parfois des événements. Le travail réel : authentifier, paginer, mapper, gérer les erreurs. Du code, qu'il soit dans un connecteur¹ ou dans votre repo.

L'ESB⁶ historique vendait des connecteurs¹ comme argument central. Le bus a vieilli ; les API² ont progressé. Qu'est-ce qu'un ESB fixe le mot ; l'ESB est trop vieux développe la thèse. Le connecteur¹ comme promesse produit suit la même courbe.

Quand coder le branchement soi-même

• Votre cas utilise des champs ou règles que le connecteur¹ ne mappe pas.
• Vous voulez tester et versionner le branchement comme le reste du SI.
• L'application cible est unique (outil métier interne, API² maison).
• Vous refusez de payer un premium pour un connecteur¹ que vous utiliserez une fois.

C'est le pari full-code¹⁰ : Python dans votre dépôt, pas une icône dans un studio. Définition : full-code vs low-code.

Où se place Portlane

Portlane ne vend pas un catalogue de connecteurs¹ comme cœur du produit. L'hypothèse : vos systèmes parlent API² ; vous (ou votre intégrateur) écrivez le branchement en Python, versionné, testable, dans votre infrastructure¹². Files d'attente¹¹, rejeu, supervision : le runtime, pas la bibliothèque d'icônes. Licence à vie¹³.

Ce n'est pas une idéologie anti-connecteur¹. C'est un périmètre assumé : intégration de données, pas marketplace de plugins. Portlane est encore en développement actif. Le raisonnement produit : pourquoi pas de catalogue. Comparatif studio : alternative Talend. Suite complète : alternative Blueway.

Comment trancher sur un flux

• Listez les champs et règles réellement synchronisés, pas la démo.
• Vérifiez si le connecteur¹ les couvre sans contournement dans le studio.
• Estimez le coût de sortie si vous devez quitter la plateforme.
• Si le connecteur¹ ne couvre que 70 % : les 30 % restants vivront où ? Souvent dans du code de toute façon.

Un connecteur¹ est un raccourci, pas une fin en soi. Sur la couche critique, le raccourci qui vous enferme coûte plus que celui que vous écrivez une fois.

Pour aller plus loin

• Le refus produit : pourquoi pas de catalogue de connecteurs
• Plateformes cloud : qu'est-ce qu'un iPaaS
• Le bus et le vocabulaire : qu'est-ce qu'un ESB
• Le code : full-code vs low-code
• Le récit : pourquoi nous construisons Portlane

Questions fréquentes

Un connecteur certifié est-il plus fiable qu'une intégration API maison ?

Pas automatiquement. Un connecteur¹ éditeur peut accélérer le branchement et absorber des changements de version, s'il est maintenu. Une intégration maison sur une API² documentée peut être plus stable si votre cas est exotique et que le connecteur¹ ne couvre pas vos champs. La fiabilité vient du code et de l'exploitation, pas du badge « certifié ».

Faut-il un connecteur pour chaque application ?

Non, dès que l'application expose une API² ou un webhook³ documenté. Le connecteur¹ est un raccourci commercial, pas une nécessité physique. Beaucoup d'ETI⁹ branchent CRM⁷ et ERP⁸ cloud sans catalogue, avec du Python ou un iPaaS⁵ qui appelle les API² directement.

Pourquoi les éditeurs vendent des catalogues de connecteurs ?

Parce que ça réduit la friction à l'achat : « 500 connecteurs » rassure en démo. Ça indexe aussi la facturation (connecteurs¹ premium, environnements). C'est un argument marketing et économique autant qu'une brique technique. Le refus produit : pourquoi pas de catalogue.

Portlane propose-t-il un catalogue de connecteurs ?

Non, et ce n'est pas l'argument central. Portlane part du principe que vos systèmes exposent des API² : vous écrivez (ou faites écrire) le branchement en Python dans votre dépôt. Portlane est encore en développement actif. Détail du choix : pourquoi pas de catalogue.

Quand un catalogue de connecteurs reste-t-il utile ?

Quand vous enchaînez beaucoup d'applications SaaS⁴ standard, que les flux sont simples, que l'équipe maîtrise l'outil, et que le coût des connecteurs¹ premium est accepté. Pour une couche critique étroite (commandes, stock, facturation), l'API² native + code tient souvent mieux.

Glossaire

• ¹ Connecteur : module qui encapsule l'accès à une application depuis une plateforme d'intégration.
• ² API : interface standardisée d'échange entre logiciels.
• ³ Webhook : notification HTTP envoyée par une application quand un événement se produit.
• ⁴ SaaS : logiciel loué en ligne.
• ⁵ iPaaS : plateforme cloud d'intégration, souvent vendue avec un catalogue de connecteurs.
• ⁶ ESB : bus de services d'entreprise.
• ⁷ CRM : logiciel de gestion de la relation client.
• ⁸ ERP : progiciel de gestion intégré.
• ⁹ ETI : entreprise de taille intermédiaire en France.
• ¹⁰ Full-code : logique d'intégration écrite en code versionné.
• ¹¹ File d'attente : stockage de messages en attente de traitement.
• ¹² Self-hosted / infrastructure : exécution sur vos serveurs, pas chez l'éditeur.
• ¹³ Licence à vie : droit d'usage sans abonnement récurrent.