Connecter deux logiciels entre eux

Un CRM, un outil de comptabilité, un tableur partagé, un Drive : une entreprise qui utilise plusieurs logiciels ne les a pas forcément connectés entre eux. L’information passe alors de l’un à l’autre par un export, un fichier corrigé à la main, une saisie refaite ailleurs. Connecter deux logiciels entre eux commence par ce que chacun des deux accepte d’ouvrir, ce qui ramène le choix à quatre accès, souvent à deux. Vient ensuite la question du moyen : un connecteur déjà écrit par l’un des éditeurs, un abonnement à une plateforme d’automatisation, ou un connecteur développé pour vos deux logiciels. Ce qui suit décrit les quatre accès, dit ce que chaque moyen coûte une fois branché, dit à quelles conditions l’abonnement cesse d’être le moins cher, et finit sur les questions à trancher avant de lancer le chantier.

Ce que vos deux logiciels acceptent d’ouvrir décide de la méthode

Un logiciel s’ouvre par les entrées que son éditeur a prévues, et cette liste est courte. Elle se lit dans la documentation technique du produit, parfois publique, parfois réservée aux clients sous contrat. La première chose à établir est donc l’intersection : ce que le logiciel A sait donner, ce que le logiciel B sait recevoir, et ce qui reste une fois ces deux listes croisées.

Quatre accès existent en pratique. Trois sont prévus par l’éditeur, le quatrième se prend sans lui. Chacun demande une contrepartie, et c’est elle qui décide, plus que la technique elle-même.

L’API, l’accès prévu par l’éditeur

Une API est une interface par laquelle un programme extérieur demande des données à un logiciel ou lui en dépose, sans passer par son écran. Un connecteur y demande la liste des clients modifiés depuis hier, reçoit une réponse structurée, et la dépose dans l’autre logiciel par l’API de celui-ci.

C’est l’accès le plus large : il donne les opérations que l’éditeur a prévues pour l’extérieur, et sa documentation dit lesquelles. Il a deux contreparties. La première est un plafond d’appels par tranche de temps, qui fixe la fréquence à laquelle vos données peuvent circuler. La seconde est l’authentification, avec des identifiants qui expirent et se renouvellent. Ces deux sujets ont leur propre page, celle qui détaille ce que devient une intégration quand le quota se ferme ou qu’un accès expire.

Le webhook, quand c’est le logiciel qui prévient

Avec une API seule, votre connecteur demande. Il repasse toutes les cinq minutes, ou toutes les heures, pour savoir si quelque chose a bougé. Quand rien n’a bougé, l’appel a consommé du quota pour rien.

Un webhook inverse le sens : le logiciel prévient votre connecteur au moment où l’événement se produit. Une facture est réglée, et le logiciel envoie aussitôt un message à l’adresse que vous lui avez donnée. La donnée arrive en quelques secondes au lieu d’attendre le prochain passage, et le nombre d’appels tombe à celui des événements réels.

Ce qu’un webhook exige en échange, c’est une adresse joignable en permanence depuis l’extérieur. Si votre logiciel de destination tourne sur un serveur interne fermé, le message n’arrive pas. Un webhook livré une seule fois, sans reprise prévue, transforme chaque coupure de votre côté en trou dans les données. Quand un éditeur expose les deux accès, le webhook sert la réactivité et l’API rattrape ce qui a été manqué.

L’échange de fichiers, l’accès des logiciels qui n’exposent rien d’autre

Reste le cas d’un logiciel qui n’expose ni API ni webhook, et qui sait pourtant exporter un fichier et en importer un. La connexion consiste alors à déposer un fichier dans un dossier partagé à heure fixe, et à laisser l’autre logiciel le ramasser.

Cet échange de fichiers convient à ce qui n’a pas besoin d’être immédiat. Une balance comptable transmise chaque nuit ne gagne rien à circuler en temps réel. Il demande en revanche une discipline que les deux autres accès n’exigent pas : un nom de fichier qui ne change jamais, un ordre de passage écrit quand plusieurs fichiers dépendent l’un de l’autre, et une trace de ce qui a été traité. Sans cette trace, un fichier ramassé deux fois crée des doublons, et un fichier jamais ramassé passe inaperçu jusqu’à la clôture.

L’accès direct à la base de données, et ce qu’il coûte plus tard

Le quatrième accès ne demande rien à l’éditeur. Votre connecteur lit directement dans la base de données du logiciel, là où ses informations sont rangées. Rien n’est à demander à personne, ce qui en fait le chemin le plus rapide à ouvrir.

Il se paie à la première mise à jour du produit. L’éditeur ne s’est engagé sur rien à cet endroit, il réorganise ses tables quand il en a besoin, et votre connexion s’arrête sans avertissement. En lecture seule, sur un logiciel dont vous maîtrisez les mises à jour, le risque reste tenable. En écriture, vous déposez des lignes sans passer par les contrôles que le logiciel applique normalement, et vous pouvez créer des états que son interface refuserait. Un éditeur peut aussi considérer que cet accès sort de son contrat de support.

Connecteur natif, plateforme d’automatisation ou connecteur développé

Une fois l’accès identifié, reste à savoir qui écrit le programme qui l’utilise. Trois réponses existent, et la technique ne les départage pas. Ce qui les départage, c’est le nombre de règles que votre échange comporte et le volume que vous ferez passer chaque mois.

Le connecteur déjà écrit par l’un des deux éditeurs

Un éditeur publie parfois lui-même la liaison vers les logiciels que ses clients utilisent le plus. Ce connecteur natif est listé dans son catalogue, il s’active en donnant des identifiants, il se met à jour tout seul, et son fournisseur le répare quand une API change.

Sa limite tient à ce qu’il fait passer. Un connecteur natif transporte les champs que son auteur a jugés utiles au plus grand nombre, dans le sens qu’il a choisi. Vos champs ajoutés et vos codes internes n’y figurent pas, vos règles de gestion non plus. Vérifier la liste exacte des champs transportés avant de s’engager évite de découvrir le manque après la bascule. La même limite se pose sur le logiciel lui-même, et elle est traitée sur la page qui mesure ce qu’un paramétrage couvre encore et ce qu’il ne couvre plus.

La plateforme d’automatisation, et le compteur qui va avec

Quand aucun connecteur natif n’existe, une plateforme d’automatisation tient le rôle d’intermédiaire. Vous y décrivez la liaison dans une interface, sans écrire de code : quand telle chose arrive dans le logiciel A, créer telle fiche dans le logiciel B. Ces plateformes, aussi appelées iPaaS, tiennent un catalogue d’applications déjà raccordées, et Zapier en annonce plus de 9 000 disponibles sur son service.

Leur facturation se regarde avant tout le reste : elle suit le nombre d’actions exécutées chaque mois. Zapier facture à la tâche, c’est-à-dire à chaque action réussie, les déclencheurs et les filtres n’étant pas comptés. Son offre gratuite s’arrête à 100 tâches par mois, son offre professionnelle démarre à 750 tâches pour 19,99 dollars par mois en engagement annuel, et son offre d’équipe à 2 000 tâches pour 69 dollars par mois au même engagement. Make compte des crédits, chaque action d’un module en consommant un dans la plupart des cas, et propose 10 000 crédits mensuels à partir de 9 dollars par mois en facturation mensuelle. Les deux unités ne recouvrent pas la même chose, et les prix affichés ne se comparent pas d’un service à l’autre.

Le calcul se fait donc sur votre volume réel, pas sur le prix affiché. Une liaison qui traite trente commandes par jour avec quatre actions chacune consomme 3 600 tâches par mois, et sort déjà des premières tranches. Cette dépense se renouvelle chaque mois pendant toute la vie de la liaison, au rythme de votre activité.

Le connecteur développé pour vos deux logiciels

Le connecteur sur-mesure est un programme écrit pour votre cas précis. Il lit dans le logiciel A, applique vos règles, écrit dans le logiciel B, et enregistre ce qu’il a fait. Son coût est concentré au départ, puis se limite à l’hébergement et aux corrections quand une API évolue.

Deux situations le rendent moins cher que l’abonnement. La première est le volume, quand la facture de la plateforme dépasse chaque année ce qu’un développement aurait coûté une fois. La seconde est la règle métier : dès qu’un échange comporte des conditions imbriquées, des calculs, des rapprochements ou des cas particuliers par client, la même logique reconstruite dans une interface graphique devient plus longue à écrire, plus difficile à relire et plus difficile à tester. Une plateforme d’automatisation tient les liaisons simples et nombreuses, et cède sur les liaisons rares et chargées de conditions.

Tant que votre échange se résume à recopier une dizaine de champs dans un seul sens, l’abonnement coûte moins cher et s’installe plus vite. Le sur-mesure commence à se justifier quand vous vous surprenez à contourner la plateforme, avec une étape faite à la main derrière elle ou un tableur qui rattrape ce qu’elle ne sait pas décider.

Le nombre de liaisons grandit plus vite que le nombre de logiciels

Le coût d’une connexion ne se lit pas à l’unité : deux logiciels demandent une liaison, six logiciels reliés chacun à chacun en demandent quinze, et chacune a ses identifiants, ses correspondances de champs et sa panne possible. Le terme d’effet spaghetti désigne ce parc de liaisons directes.

Deux façons d’organiser les échanges limitent cette multiplication. La première fait transiter les échanges par un intermédiaire unique, parfois appelé middleware, où chaque logiciel se branche une fois. Les correspondances de champs, les journaux et les reprises après incident vivent à un seul endroit. La contrepartie est que cet intermédiaire devient un point de passage obligé, à héberger, à surveiller et à maintenir.

La seconde relève de votre organisation : pour chaque donnée partagée, un seul logiciel la crée et les autres la reçoivent. Cette désignation réduit le nombre de liaisons nécessaires avant même d’en écrire une, et elle se tranche de votre côté. Le tri des données qui réclament un endroit unique est développé sur la page qui sépare les chantiers que le mot centralisation recouvre.

Le choix entre les deux se fait sur le nombre de logiciels concernés. En dessous de trois ou quatre, une liaison directe reste plus simple à écrire, à comprendre et à réparer qu’un intermédiaire à installer. Au-delà, le point de passage unique se rentabilise. Le cas d’un logiciel commercial et d’un logiciel de gestion à faire dialoguer dans les deux sens a sa propre page, sur les échanges entre l’outil des commerciaux et celui de la gestion.

Les questions à trancher avant de lancer la connexion

Sept questions se posent avant de choisir un prestataire ou un abonnement, et trois d’entre elles se répondent en lisant la documentation des deux logiciels.

La documentation est-elle accessible sans contrat ? Un éditeur qui publie la sienne se contrôle sans démarche préalable. Un éditeur qui la réserve à ses partenaires impose une démarche commerciale avant même le chiffrage, et ce délai compte dans le planning.

Existe-t-il un environnement de test ? Sans ce double du logiciel réel, les premiers essais s’écrivent dans vos données de production, et une erreur de correspondance crée des fiches à supprimer une par une. Son absence ne bloque pas le projet, elle change la façon de le mener, avec des jeux d’essai restreints et une bascule progressive.

Quel est le quota d’appels ? Il se lit dans la documentation, et il ne progresse pas d’un bloc avec le prix de l’abonnement. HubSpot documente, pour une application privée installée sur un compte, 190 requêtes par tranche de 10 secondes et par application aux paliers Professional et Enterprise, tandis que la limite journalière passe de 625 000 à 1 million de requêtes par compte de l’un à l’autre. Le plafond du jour s’élève avec l’abonnement, le débit instantané reste identique. C’est ce débit qui décide si votre synchronisation tourne toutes les minutes ou toutes les heures.

Où transitent vos données une fois sorties de vos deux logiciels ? Un connecteur natif ou un connecteur sur-mesure les fait passer directement de l’un à l’autre. Une plateforme d’automatisation les fait passer par ses propres serveurs le temps d’exécuter la tâche, et en garde une trace dans ses journaux pour une durée qui lui appartient. Pour une adresse ou une date de commande, cela ne change rien. Pour une donnée financière ou médicale, ou toute information qu’un client vous a confiée à titre confidentiel, vérifier où ces serveurs sont installés et ce que la plateforme fait de ses journaux évite une mauvaise surprise une fois la liaison en service.

Quels champs se correspondent, et lequel gagne en cas d’écart ? C’est la correspondance des champs. Une règle simple couvre la plupart des cas : le logiciel où l’information est saisie en premier fait foi sur celui qui ne fait que la recevoir, et à défaut, c’est celui que l’équipe corrige le plus souvent qui gagne. Elle ne couvre pas tout : deux logiciels qui contiennent la même adresse sous deux valeurs différentes, sans qu’aucun des deux ne soit clairement la source, restent un cas que personne ne peut trancher à votre place. Le rapprochement des fiches d’un même client entre deux outils est détaillé sur la page qui explique comment reconnaître qu’une fiche des deux côtés désigne la même société.

Que se passe-t-il quand la liaison tombe ? Une connexion s’interrompt un jour ou l’autre, par une panne du fournisseur, un quota atteint ou un identifiant expiré. Ce qui se décide, c’est qui l’apprend et quand : une alerte à quelqu’un de nommé, une reprise automatique des échanges manqués, et une trace consultable de ce qui est passé. Tant que personne n’est prévenu, vos équipes continuent de faire confiance aux chiffres affichés, et la correction porte ensuite sur tout ce qui a été décidé entre-temps.

Qui garde le connecteur ? Un connecteur natif dépend de son éditeur, qui décide de ce qu’il transporte et du jour où il s’arrête. Un abonnement dépend de la plateforme, et la liaison s’arrête avec lui. Un connecteur développé dépend de qui détient son code source, question qui se règle au contrat plutôt qu’à la livraison.

Regarder vos deux logiciels avant de choisir

La réponse tient dans trois éléments que vous détenez déjà : la documentation de vos deux produits, le nombre d’échanges que vous ferez passer chaque mois, et la liste des règles qui doivent s’appliquer au passage. Réunis, ils suffisent à écarter les méthodes qui ne tiennent pas votre cas.

Nous commençons par là. Nous regardons ce que chacun de vos logiciels ouvre réellement, nous comptons ce qui doit circuler, et nous vous disons si un connecteur du marché suffit ou si votre échange comporte des règles qu’aucun catalogue ne portera. Quand un abonnement fait l’affaire, nous vous le disons, et le projet s’arrête à ce constat. Quand nous développons le connecteur, son code source vous appartient.

Ce travail fait partie d’un chantier plus large, celui de faire circuler l’information entre tous les logiciels que vous gardez. Le sens de chaque flux, le rythme des échanges et le traitement des erreurs sont traités sur la page consacrée à quelle donnée part la première et vers quel outil. La suppression des saisies faites deux fois a sa page sur ce que coûte une même donnée tapée deux fois.

Sources

Plans and Pricing, Zapier, consulté le 8 septembre 2026, https://zapier.com/pricing

Introduction to apps on Zapier, Zapier, consulté le 8 septembre 2026, https://help.zapier.com/hc/en-us/articles/21996626006541-Introduction-to-apps-on-Zapier

Pricing, Make, consulté le 8 septembre 2026, https://www.make.com/en/pricing

API usage guidelines and limits, HubSpot, consulté le 8 septembre 2026, https://developers.hubspot.com/docs/developer-tooling/platform/usage-guidelines