L’interfaçage logiciel consiste à faire communiquer deux logiciels pour que les informations saisies dans l’un passent automatiquement dans l’autre, sans ressaisie. Il repose sur quatre techniques : l’API, le webhook, le fichier échangé à heure fixe et la base de données intermédiaire. Le bon choix dépend de ce que chaque logiciel sait faire, du rythme des échanges et du niveau de fiabilité attendu.
Le besoin naît presque toujours d’une ressaisie. Le devis est accepté dans l’outil commercial, puis quelqu’un recopie la commande dans la facturation. Les contacts arrivent par un formulaire, puis quelqu’un les reporte dans le CRM. Chaque logiciel fait bien son travail ; le problème se situe entre eux. Cet article décrit les façons techniques de les relier, ce qu’il faut faire quand un logiciel n’a pas d’API, et comment surveiller une interface pour qu’elle ne tombe pas en panne en silence.
Interfaçage logiciel : de quoi parle-t-on ?
Un interfaçage est une convention d’échange entre deux programmes. Elle fixe quelles données circulent, dans quel format, à quel moment et dans quel sens. Les deux logiciels continuent de fonctionner chacun de leur côté : l’interface fait seulement passer l’information de l’un à l’autre.
France Num, le service public consacré au numérique des TPE et PME, rappelle ce point à propos des ERP : si vous gardez un logiciel de comptabilité qui vous convient, il faut s’assurer que les deux outils puissent communiquer « via des interfaces de programmation (APIs), des connecteurs et autres services web » (dossier France Num sur la mise en place d’un ERP, mis à jour le 31 août 2026).
Avant toute technique, trois questions définissent un interfaçage :
- Quoi ? La liste précise des informations à transmettre : client, montant, référence, date, statut.
- Quand ? Immédiatement, toutes les heures ou une fois par jour.
- Qui fait foi ? Le logiciel de référence pour chaque information, celui qui gagne en cas de désaccord.
La troisième question est la plus souvent oubliée. Sans source de référence, deux logiciels synchronisés dans les deux sens finissent par s’écraser mutuellement. L’article sur la façon de centraliser ses données dans un outil métier détaille ce choix.
Les quatre façons de relier deux logiciels
Chaque technique d’interfaçage répond à une situation différente. Une même entreprise en combine souvent plusieurs, selon les logiciels en présence.
L’API : demander ou envoyer à la demande
Une API est une porte d’entrée prévue par l’éditeur d’un logiciel pour que d’autres programmes puissent lire ou écrire des données, selon des règles publiées dans une documentation. Votre interface envoie une requête, par exemple « crée cette facture » ou « donne-moi les commandes du jour », et le logiciel répond. C’est la méthode la plus propre quand elle existe, parce que l’éditeur s’engage sur son fonctionnement.
Le webhook : être prévenu dès qu’un événement se produit
Avec une API seule, votre interface doit demander régulièrement s’il y a du nouveau. Le webhook inverse le sens : c’est le logiciel source qui prévient une adresse que vous lui indiquez, dès qu’un événement survient, comme un paiement reçu ou un formulaire envoyé. L’information arrive en quelques secondes, sans interrogations inutiles.
Le fichier planifié : un export déposé à heure fixe
Le logiciel source produit un fichier, souvent un CSV, à heure fixe. Un programme le récupère, contrôle son contenu et l’importe dans l’autre logiciel. Cette méthode est moins rapide, mais elle fonctionne avec beaucoup de logiciels anciens et reste simple à vérifier : le fichier garde la trace de ce qui a été envoyé.
La base intermédiaire : un espace commun de synchronisation
Quand plusieurs logiciels doivent partager les mêmes informations, on peut placer entre eux une base de données dédiée. Chaque logiciel y dépose ses données et y lit celles des autres, avec des règles claires sur la source de référence. Cette architecture demande plus de travail au départ, mais elle évite de multiplier les liaisons de logiciel à logiciel.
| Technique | Rythme | Quand l’utiliser | Point faible |
|---|---|---|---|
| API | À la demande | Le logiciel publie une API documentée | Limites d’appels, changements de version |
| Webhook | Dès l’événement | Il faut réagir vite à un paiement, une commande, un formulaire | Un message perdu doit pouvoir être renvoyé |
| Fichier planifié | Heure fixe | Logiciel ancien, gros volumes, besoin non urgent | Décalage dans le temps, format du fichier qui change |
| Base intermédiaire | Continu ou planifié | Trois logiciels ou plus partagent les mêmes données | Conception plus lourde, règles de priorité à définir |
Mon logiciel n’a pas d’API : que faire ?
Un logiciel sans API n’est pas forcément impossible à relier. Il faut d’abord vérifier qu’il n’en a vraiment pas, puis choisir la solution la plus fiable parmi celles qui restent.
- Vérifier auprès de l’éditeur. L’API est parfois réservée à une formule supérieure de l’abonnement, ou documentée sur un site séparé destiné aux développeurs.
- Utiliser les exports et imports. La plupart des logiciels savent exporter et importer des fichiers. Si l’export peut être programmé, le fichier planifié devient une solution d’interfaçage solide.
- Exploiter les e-mails automatiques. Un logiciel qui envoie une notification à chaque commande transmet déjà une information. Un programme peut lire ces messages et en extraire les données, à condition que leur format soit stable.
- Lire la base de données, avec prudence. Pour un logiciel installé sur vos serveurs, une lecture directe de sa base est parfois possible. Elle se fait en lecture seule, avec l’accord de l’éditeur, car une mise à jour peut modifier la structure sans prévenir.
- Simuler un utilisateur, en dernier recours. Un robot peut remplir les écrans à la place d’une personne. C’est la solution la plus fragile : le moindre changement d’écran l’arrête.
Connecteur API prêt à l’emploi ou intégration API sur mesure ?
Un connecteur API prêt à l’emploi suffit quand les deux logiciels sont courants et que l’échange suit une règle simple ; une intégration API sur mesure devient utile dès que les règles, le volume ou les logiciels sortent de l’ordinaire.
Le connecteur API est fourni par l’éditeur lui-même ou par une plateforme d’automatisation comme Make, Zapier ou n8n. Il se met en place vite, sans développement, pour des échanges du type « quand un contact est créé ici, crée-le là ». Le comparatif automatisation no-code ou développement sur mesure aide à situer la frontière.
L’intégration API sur mesure est un petit programme écrit pour votre cas. Elle se justifie quand il faut transformer les données entre les deux logiciels, appliquer des contrôles, traiter des exceptions, relier un logiciel métier qui n’a aucun connecteur, ou garantir qu’aucun échange ne se perd. C’est le cœur de mon travail en automatisation des processus métier : partir du circuit réel de l’équipe, puis choisir la liaison la plus fiable plutôt que la plus impressionnante.
Ce qui casse une interface, et comment la surveiller
Un interfaçage ne casse presque jamais le jour de sa mise en service. Il casse des mois plus tard, quand l’un des deux logiciels change. Les causes sont connues :
- Une nouvelle version d’API. L’éditeur modifie ou retire une fonction, souvent avec un préavis qu’il faut surveiller.
- Les limites d’appels. La plupart des API plafonnent le nombre de requêtes par minute ou par jour. Un pic d’activité peut faire refuser des échanges.
- Un format qui change. Un champ renommé, une colonne ajoutée dans un export, et l’import échoue ou range la donnée au mauvais endroit.
- Des accès expirés. Un mot de passe changé ou une autorisation arrivée à échéance coupe la liaison.
- Les erreurs silencieuses. Le cas le plus coûteux : l’échange échoue, personne n’est prévenu, et l’écart se découvre chez le client.
La CNIL, dans sa recommandation technique sur le partage de données par API publiée le 7 juillet 2023, demande que la documentation d’une API indique ses limites, « en particulier le volume et la fréquence maximale des requêtes ». Elle recommande aussi une version jumelle de l’API, alimentée par des données fictives, pour tester sans risque (recommandation de la CNIL sur les API, PDF).
Côté surveillance, un interfaçage fiable tient un journal de chaque échange, signale toute erreur à une personne désignée, relance automatiquement les envois en échec et compare régulièrement les deux logiciels pour repérer les écarts. Ce n’est pas un supplément : sans ces garde-fous, l’interfaçage déplace le risque d’erreur au lieu de le supprimer.
Les questions à poser à l’éditeur avant de commencer
Quelques questions posées avant le premier développement évitent la plupart des mauvaises surprises :
- Le logiciel dispose-t-il d’une API, et dans quelle formule d’abonnement est-elle incluse ?
- La documentation est-elle publique, à jour et en accès libre ?
- Quelles sont les limites d’appels, et que se passe-t-il quand elles sont dépassées ?
- Le logiciel propose-t-il des webhooks pour les événements qui vous intéressent ?
- Existe-t-il un environnement de test, séparé de vos données réelles ?
- Comment l’éditeur annonce-t-il les changements de version, et avec quel préavis ?
- Où sont hébergées les données, et comment l’accès à l’API est-il sécurisé ?
Si les réponses sont floues, ce n’est pas forcément rédhibitoire. Cela signale qu’il faudra prévoir plus de surveillance, ou une méthode de repli comme le fichier planifié. Quand les contournements se multiplient autour d’un même outil, la question devient celle d’un logiciel métier inadapté plutôt que d’une simple interface.
Questions fréquentes
Qu’est-ce qu’une API, en une phrase ?
Une API est une porte d’entrée qu’un logiciel ouvre aux autres programmes, avec des règles publiées, pour qu’ils puissent lire ou modifier certaines de ses données sans passer par ses écrans. C’est la base de la plupart des interfaçages modernes.
Faut-il l’accord de l’éditeur du logiciel pour l’interfacer ?
Si l’éditeur publie une API, son usage est encadré par ses conditions d’utilisation, qu’il faut lire : usages permis, limites, coût éventuel. Sans API, le Code de la propriété intellectuelle (article L122-6-1 sur Légifrance) permet, sous des conditions strictes, de reproduire ou de traduire le code du logiciel (la décompilation) pour obtenir les informations nécessaires à l’interopérabilité : il faut avoir le droit d’utiliser le logiciel, ces informations ne doivent pas avoir déjà été rendues facilement et rapidement accessibles, et l’opération se limite aux parties du logiciel nécessaires. Ce terrain juridique se vérifie au cas par cas avec un conseil.
Que se passe-t-il quand un logiciel change son API ?
Si l’interfaçage n’est pas adapté à temps, les échanges concernés échouent. Les éditeurs sérieux annoncent les changements à l’avance et maintiennent l’ancienne version pendant une période de transition. Une interface surveillée signale l’erreur dès le premier échec, ce qui laisse le temps de corriger.
Les données sont-elles protégées pendant l’échange ?
Elles doivent l’être : échanges chiffrés, accès limités aux seules données utiles, journal des accès. La CNIL observe que le niveau de sécurité apporté par les API est généralement plus élevé que celui de l’envoi de fichiers par messagerie ou par plateforme de partage. C’est une raison de préférer une intégration API au fichier envoyé par e-mail quand le choix existe.
En 30 minutes, je vois comment le travail se passe chez vous, et je vous dis honnêtement ce qui vaut un développement et ce qui n’en vaut pas.