Faire communiquer deux logiciels: le guide du dirigeant

Le devis part d’un logiciel, la facture d’un autre, et entre les deux, quelqu’un recopie. La plupart des PME françaises vivent avec des outils qui s’ignorent, et compensent à la main sans même compter ce temps. Cet article explique, sans jargon, comment deux logiciels peuvent se parler, combien ça coûte réellement, et dans quels cas la connexion ne vaut pas son prix.

Pourquoi vos logiciels ne se parlent-ils pas tout seuls ?

Parce que chaque éditeur construit son logiciel comme un monde autonome, avec sa propre base de données, et n’a aucune obligation de le rendre compatible avec les autres. La communication entre deux outils n’existe que si quelqu’un la construit : l’éditeur via un connecteur officiel, ou vous via un interfaçage. Tant que personne ne l’a fait, c’est un humain qui joue le rôle du câble.

Cette ressaisie manuelle a trois coûts. Le temps d’abord : recopier commandes, contacts ou factures d’un écran vers un autre occupe des heures chaque semaine. Les erreurs ensuite : chaque recopie est une occasion de se tromper de montant, de référence ou de client, et l’erreur se découvre toujours en aval, quand elle a déjà produit ses effets. Le retard enfin : une donnée recopiée le vendredi décrit la réalité du lundi, et les décisions se prennent sur des chiffres périmés.

Le contexte réglementaire pousse dans la même direction : la réforme de la facturation électronique impose à toutes les entreprises assujetties à la TVA d’être capables de recevoir des factures électroniques dès septembre 2026, via une plateforme agréée par l’État (France Num, mise à jour juin 2026). Une chaîne devis, facturation, comptabilité qui repose sur des recopies manuelles prend cette réforme de plein fouet : l’échange automatique entre outils devient la norme, pas le confort.

Quelles sont les 4 façons de faire communiquer deux logiciels ?

Quatre voies existent, du plus simple au plus robuste : le connecteur natif fourni par l’éditeur, la plateforme d’automatisation, l’interfaçage sur mesure via API, et les solutions de repli quand aucune API n’existe. Trois définitions d’abord, parce que le vocabulaire fait la moitié de la confusion :

• Une API (interface de programmation) est une porte d’entrée standardisée qu’un logiciel expose pour que d’autres programmes lisent et écrivent ses données sans passer par l’écran, de façon sécurisée et documentée. Le principe est si central que l’État expose ses propres services ainsi : API Entreprise, API Particulier ou Sirene, cataloguées sur data.gouv.fr.
• Un connecteur est un module prêt à l’emploi qui relie deux logiciels précis, construit par l’un des deux éditeurs ou un tiers, activable sans développement.
• Une plateforme d’automatisation (Zapier, Make, n8n) est un service qui déclenche des actions entre logiciels selon des règles simples : « quand un formulaire est rempli ici, créer une ligne là ».

La règle de choix tient en deux questions. Le connecteur ou la plateforme d’automatisation existent et couvrent le besoin : prenez-les, un développement n’apporterait rien. Le flux est critique (argent, stock, données clients), volumineux ou spécifique : l’interfaçage dédié devient rationnel, précisément parce qu’il est conçu pour vos règles, vos volumes et vos cas d’erreur. Le détail de l’offre est sur notre page interfaçages et API.

Combien coûte un interfaçage entre deux logiciels ?

Entre 2 000 et 5 000 € HT pour une connexion simple : deux logiciels dotés d’API correctes, un flux de données dans un sens ou deux, la gestion des erreurs et la mise en production comprises. Comptez 5 000 à 15 000 € HT quand la réalité se complique : API absente ou mal documentée, logiciel ancien, transformations de données lourdes, ou éditeur qui répond en semaines. En jours de travail, un interfaçage simple représente 3 à 7 jours de développement d’un profil confirmé.

Face à ce coût unique, posez le coût récurrent de l’alternative : la ressaisie. Le cas classique que ce scénario recouvre : une PME reçoit ses commandes dans un outil (site e-commerce, CRM, formulaires) et facture dans un autre. Quatre heures de recopie par semaine, réparties sur deux personnes, représentent l’équivalent de 8 000 à 16 000 € de temps humain par an, sans compter les erreurs de saisie et les avoirs qu’elles génèrent. Un interfaçage à 4 000 € se rembourse en moins de six mois, puis économise le même montant chaque année. C’est l’investissement au meilleur rendement de tout le système d’information d’une PME, et c’est aussi la première brique d’une démarche plus large d’automatisation des processus.

Pour comparer des devis, vérifiez ce que le montant couvre réellement. Un interfaçage sérieux inclut quatre livrables que les devis low cost omettent : la reprise et le dédoublonnage des données existantes, la gestion des erreurs avec reprise automatique, la supervision avec alertes, et une documentation du flux que quelqu’un d’autre que son auteur peut maintenir. Un devis qui se limite à « connexion entre A et B » ne décrit que la moitié du travail.

Le budget dépend surtout du logiciel le moins coopératif des deux. Un outil moderne doté d’une API publique et documentée se connecte vite. Un logiciel métier vieillissant sans API impose des voies de repli (exports automatisés, lecture de base de données) qui fonctionnent mais se paient en robustesse. C’est un critère à intégrer dès le choix d’un nouvel outil : sur nos propres produits, l’API n’est pas une option ajoutée après coup, notre socle open source FastEdgy la génère dès le premier jour, précisément parce qu’un logiciel sans porte d’entrée programmable devient tôt ou tard un silo.

Comment préparer un projet d’interfaçage sans être technique ?

En cartographiant les flux avant de parler technique : un dirigeant peut faire seul 80 % du travail de cadrage en une heure, et ce document fera la précision du devis. La méthode en cinq étapes :

1. Listez les recopies. Qui ressaisit quoi, d’où vers où, à quelle fréquence. Chaque recopie régulière est un flux candidat.
2. Chiffrez chaque flux. Minutes par occurrence, occurrences par semaine, gravité d’une erreur. Ce tri fait émerger le flux prioritaire, celui qui paie le projet.
3. Définissez la source de vérité. Pour chaque donnée (client, prix, stock), un seul logiciel doit faire foi, l’autre s’aligne. La moitié des projets d’interfaçage qui déraillent butent sur cette question, jamais sur la technique.
4. Vérifiez les portes d’entrée. Cherchez « [nom du logiciel] API » dans sa documentation, ou posez la question à l’éditeur. La réponse conditionne la fourchette de budget.
5. Décrivez le comportement en cas d’échec. Que se passe-t-il si le logiciel en face ne répond pas ? Qui est alerté ? L’interfaçage sérieux se distingue du bricolage sur cette seule question.

Ce cadrage rejoint la logique que nous appliquons à tout développement : comprendre le process avant d’écrire du code, c’est le cœur de notre méthode. Et si votre cartographie révèle que le vrai problème n’est pas la connexion entre deux outils mais l’outil central lui-même, le sujet devient celui d’un logiciel adapté à vos processus, pas d’un câble entre deux logiciels inadaptés : le symptôme classique est le fichier Excel de consolidation qui fait le pont entre tous les autres, celui dont nous parlons dans notre guide du fichier Excel devenu ingérable.

Quels sont les pièges classiques d’un projet d’interfaçage ?

Le piège n’est presque jamais la connexion initiale, c’est ce qui se passe ensuite. Quatre patterns reviennent systématiquement sur les projets que nous reprenons :

• La synchronisation silencieuse qui casse. Un export nocturne tombe en panne, personne n’est alerté, et l’équipe travaille trois semaines sur des données figées avant de s’en apercevoir. Un interfaçage sans supervision ni alerte n’est pas terminé, il est juste livré.
• Le champ qui change de format. L’éditeur du logiciel en face modifie son API ou la structure de ses exports lors d’une mise à jour, et le flux s’arrête ou, pire, écrit des données fausses. La parade : des contrôles de cohérence à l’entrée, pas la confiance.
• La boucle infinie. Deux logiciels synchronisés dans les deux sens sans règle de priorité se réécrivent mutuellement : le contact modifié ici écrase la modification faite là. C’est la conséquence directe d’une source de vérité jamais définie.
• La reprise initiale bâclée. Avant que le flux tourne, les deux logiciels contiennent déjà des données : les mêmes clients saisis deux fois avec deux orthographes, des références divergentes, des historiques incomplets. Synchroniser sans dédoublonner d’abord, c’est propager les incohérences des deux côtés à vitesse automatique. La reprise de l’existant est un sous-projet à part entière, à chiffrer dès le devis.
• Le script du stagiaire. Un bricolage écrit vite, qui fonctionne, dont l’auteur part, et que plus personne n’ose toucher. Le flux critique de l’entreprise repose alors sur un fichier que personne ne comprend : le même mécanisme que le tableur ingérable, appliqué au code. Un interfaçage mérite d’être documenté, versionné et maintenu, c’est exactement le périmètre d’une tierce maintenance applicative.

Quand ne faut-il pas développer d’interfaçage ?

Dans trois cas, développer une connexion sur mesure serait une erreur, et un prestataire honnête doit vous le dire avant de chiffrer. Le premier : un connecteur natif couvre déjà le besoin. S’il existe, qu’il est maintenu par l’éditeur et qu’il transporte les bonnes données, il gagnera toujours contre un développement, en coût comme en pérennité. Le deuxième : le flux est rare et pauvre en enjeu. Ressaisir dix lignes par mois coûte moins cher que le plus simple des interfaçages ; l’automatisation se justifie par le volume ou par la criticité, jamais par principe. Le troisième : l’un des deux logiciels est en fin de vie. Connecter un outil que vous comptez remplacer dans l’année, c’est payer deux fois ; il vaut mieux traiter d’abord le choix de l’outil, la grille est dans logiciel sur mesure ou solution standard.

Contrairement à un logiciel, un interfaçage ne se voit pas : quand il fonctionne, personne n’y pense, et c’est exactement le but. Le test le plus simple pour savoir si vous en avez besoin tient en une question posée à vos équipes : « qu’est-ce que vous recopiez d’un écran vers un autre ? ». Si la réponse dure plus de dix secondes, envoyez-nous la liste : 30 minutes en visio avec un fondateur suffisent pour dire quels flux méritent une connexion, dans quel ordre, et pour quel budget. Parlons-en.