Comment connecter deux logiciels qui ne communiquent pas entre eux ?

Le problème commence rarement par la technologie

Prenons une situation simple, présentée ici comme un exemple générique. Une entreprise reçoit des demandes de devis depuis son site et veut les faire arriver dans son CRM.

La demande initiale tient en une phrase : « connecter le formulaire au CRM ».

Le besoin réel est déjà plus précis :

• détecter si le contact existe déjà ;

• créer ou mettre à jour la fiche sans créer de doublon ;

• créer une opportunité ;

• enregistrer la source de la demande ;

• attribuer la demande à la bonne personne ;

• créer une tâche de rappel ;

• envoyer un accusé de réception ;

• signaler les demandes incomplètes ;

• savoir quoi faire si le CRM est indisponible.

Tant que ces règles ne sont pas définies, l’entreprise ne cherche pas encore une intégration. Elle cherche une promesse vague.

1. Décrire le flux avant de choisir la solution

Avant de comparer les outils, décrivez un seul flux avec six éléments :

1. L’événement déclencheur : que s’est-il passé ? Un formulaire a été envoyé, une facture a été validée, un paiement a été reçu, un ticket a changé de statut ?

2. La donnée concernée : quelles informations doivent circuler ?

3. Le sens du flux : de quel logiciel vers quel logiciel ?

4. Le délai attendu : immédiatement, en quelques minutes, une fois par heure ou une fois par jour ?

5. La règle de responsabilité : quel système fait foi si les informations divergent ?

6. Le traitement des exceptions : que fait-on si une donnée manque, si un doublon existe ou si le service distant ne répond pas ?

Un schéma simple suffit souvent à commencer :

Cette étape évite un piège courant : choisir une technologie parce qu’elle est connue, puis essayer de lui faire entrer un processus qu’elle ne sait pas gérer.

2. Les sept façons de connecter deux logiciels

Il n’existe pas une meilleure méthode dans l’absolu. Il existe une méthode adaptée à un flux, à un niveau de criticité et à une capacité de maintenance.

2.1. Le connecteur natif : le bon choix pour commencer simplement

Un connecteur natif est une intégration déjà prévue par l’éditeur d’un logiciel ou par une plateforme d’automatisation. Il permet par exemple de relier un formulaire à un CRM, un outil de projet à un agenda ou un logiciel de facturation à une solution de paiement.

Ses avantages :

• mise en place rapide ;

• peu de code, voire aucun ;

• coût initial souvent limité ;

• configuration accessible à une équipe opérationnelle ;

• maintenance partiellement assurée par l’éditeur.

Ses limites :

• champs et règles parfois trop simples ;

• gestion imparfaite des doublons ;

• traitement des erreurs limité ;

• dépendance aux changements de l’éditeur ;

• quotas, limites de volume ou fonctionnalités réservées à certaines offres.

Le connecteur natif convient bien lorsque le flux est peu critique, les règles sont simples et le volume reste raisonnable. Il devient moins adapté lorsque l’intégration porte sur une donnée sensible, un processus financier ou une logique métier qui demande plusieurs décisions intermédiaires.

2.2. L’API : plus de contrôle, plus de responsabilité

Une API est une interface qui permet à un logiciel de lire, créer, modifier ou rechercher des données dans un autre logiciel. Elle est utile lorsqu’il faut contrôler précisément les champs, les règles et le moment des échanges.

Une API peut permettre de :

• rechercher un contact avant de le créer ;

• créer une commande uniquement après validation ;

• mettre à jour certains champs, mais pas tous ;

• vérifier l’état d’un traitement ;

• récupérer les changements depuis la dernière synchronisation ;

• appliquer une règle différente selon le type de client.

L’API est souvent la bonne option lorsque le flux est important, que les données sont structurées et que le connecteur disponible ne couvre pas le besoin.

Elle demande toutefois davantage de travail : authentification, documentation, gestion des versions, limites de requêtes, reprise après erreur, supervision et maintenance. Une API ne supprime pas la complexité. Elle permet de la traiter explicitement.

Avant de retenir cette option, vérifiez notamment :

• sa disponibilité dans l’offre souscrite ;

• les opérations réellement autorisées ;

• les limites de volume et de fréquence ;

• la durée de vie des versions ;

• la documentation des erreurs ;

• les mécanismes d’authentification ;

• la possibilité de journaliser les échanges.

2.3. Le webhook : réagir à un événement

Un webhook permet à un logiciel d’envoyer une notification HTTP lorsqu’un événement se produit. Le système destinataire reçoit alors une information et peut déclencher la suite du processus.

Exemple : lorsqu’un paiement est confirmé, le logiciel de paiement envoie un événement. Le middleware ou le CRM peut alors mettre à jour la commande, créer une tâche ou prévenir l’équipe concernée.

Le webhook est adapté lorsque l’information doit circuler rapidement sans que le système destinataire interroge en permanence le système source. Il réduit le besoin de vérifier toutes les quelques minutes si quelque chose a changé.

Il ne règle pas tout pour autant. Il faut prévoir :

• l’authentification de l’appel ;

• la vérification de la signature ou du secret ;

• la réception en double d’un même événement ;

• un délai de réponse acceptable ;

• une file de reprise si le destinataire est temporairement indisponible ;

• la traçabilité de l’événement reçu et de son traitement.

Un webhook est donc un déclencheur, pas une stratégie complète d’intégration.

2.4. La synchronisation planifiée : efficace quand l’immédiateté n’est pas nécessaire

Une synchronisation planifiée récupère ou transmet les changements à intervalles réguliers : toutes les heures, chaque nuit ou une fois par semaine.

Cette méthode est pertinente lorsque :

• le processus n’a pas besoin d’être temps réel ;

• le volume peut être traité par lots ;

• les deux logiciels ne proposent pas de webhook ;

• les utilisateurs travaillent déjà avec un rythme de clôture ou de rapprochement ;

• l’objectif est d’alimenter un reporting ou une base secondaire.

Elle est généralement plus simple à faire fonctionner qu’un flux temps réel. Elle peut aussi réduire le nombre d’appels envoyés aux outils. En revanche, elle introduit un décalage et demande de savoir récupérer uniquement les données nouvelles ou modifiées.

Le point à vérifier est le mécanisme de reprise : que se passe-t-il si la synchronisation de 2 heures échoue ? Le prochain passage doit-il tout relire, reprendre à partir du dernier élément traité ou signaler une intervention ?

Les plateformes d’intégration ont leurs propres limites de fréquence, d’actions et de volume. Ces limites peuvent ralentir un flux, provoquer une mise en attente ou désactiver une automatisation lorsqu’elle échoue continuellement. La cadence doit donc être choisie avec le volume réel, et non avec une intuition.

2.5. Le fichier : encore utile lorsque l’échange est maîtrisé

Un fichier CSV, Excel ou XML peut servir d’interface entre deux logiciels. Ce choix paraît moins moderne qu’une API, mais il reste utile pour des échanges batch, des migrations, des rapprochements comptables ou des outils anciens.

Un échange par fichier peut être pertinent si :

• l’échange est quotidien ou hebdomadaire ;

• le volume est connu ;

• les personnes responsables sont identifiées ;

• le format est documenté ;

• les contrôles avant import sont possibles ;

• la présence d’un délai est acceptable.

Le risque est de créer un fichier qui devient une zone grise : plusieurs versions, noms de colonnes modifiés, envois par email, corrections manuelles invisibles et absence de responsable. Un fichier peut être une interface fiable. Il ne doit pas devenir un nouveau système de référence par accident.

2.6. Le middleware : orchestrer plusieurs règles et plusieurs outils

Un middleware se place entre les logiciels pour recevoir, transformer, router et surveiller les échanges. Il peut s’agir d’une plateforme d’intégration, d’un service cloud ou d’une couche développée pour le projet.

Le middleware devient utile lorsque le flux ne relie plus seulement A à B, mais doit :

• transformer les formats ;

• appliquer plusieurs règles ;

• appeler plusieurs services ;

• centraliser les logs ;

• gérer des reprises ;

• limiter le débit ;

• envoyer des alertes ;

• conserver une file d’événements ;

• connecter d’autres outils plus tard.

Il apporte de la structure, mais ajoute une dépendance et un composant à maintenir. Il faut donc éviter de le choisir uniquement parce qu’il est puissant. Pour deux champs et un événement quotidien, il peut être disproportionné. Pour un flux critique qui doit évoluer, il peut au contraire éviter de disperser la logique dans une série d’automatisations fragiles.

2.7. Le développement spécifique : quand la contrainte le justifie

Le développement spécifique est utile lorsqu’aucune solution existante ne permet de traiter correctement le flux, ou lorsque les règles métier sont trop particulières.

Il peut être nécessaire si :

• un logiciel ancien ne possède pas de connecteur exploitable ;

• plusieurs règles doivent être appliquées avant l’écriture ;

• la sécurité impose une architecture particulière ;

• les volumes ou les délais sortent des capacités des outils standards ;

• l’entreprise doit conserver une interface ou un contrôle spécifique ;

• le flux devient un élément critique de l’activité.

C’est aussi l’option qui engage le plus clairement la responsabilité de l’entreprise. Il faudra documenter le code, les dépendances, les secrets, les règles de reprise, les versions d’API et la personne qui interviendra en cas de panne.

Le développement spécifique ne doit pas être choisi pour donner une impression de robustesse. Il doit être choisi lorsque sa maîtrise supplémentaire justifie son coût de conception et de maintenance.

3. Comment choisir entre ces solutions ?

Une première grille de décision peut aider :

Cette grille ne remplace pas le cadrage. Elle sert à éviter deux erreurs symétriques : développer trop tôt ou empiler des automatisations sans architecture.

4. Définir le système de référence

Deux logiciels peuvent contenir le même contact, la même commande ou le même statut. Cela ne signifie pas qu’ils doivent avoir le même pouvoir de modification.

Pour chaque donnée importante, indiquez :

• le système qui crée l’information ;

• le système qui peut la modifier ;

• les systèmes qui la consultent ;

• le champ qui identifie l’enregistrement ;

• la règle appliquée en cas de divergence.

Exemple : le CRM peut être la référence pour le statut commercial, tandis que le logiciel de facturation est la référence pour le statut de paiement. Si le CRM affiche « gagné » mais que la facture n’est pas réglée, l’intégration ne doit pas choisir arbitrairement une version. Elle doit refléter deux informations différentes ou appliquer une règle explicitement décidée.

Sans système de référence, la synchronisation transforme un désaccord en va-et-vient permanent. Chaque outil écrase l’autre, et personne ne sait quelle information doit être corrigée.

5. Faire le mapping des données

Le mapping consiste à définir la correspondance entre les champs des deux logiciels.

Le mapping doit aussi traiter les différences de vocabulaire. Un logiciel peut utiliser « Gagné », un autre « Client », un troisième « Contrat signé ». Copier la valeur sans la traduire crée une apparence de cohérence, pas une cohérence réelle.

Documentez également les champs obligatoires, les valeurs par défaut, les formats de date, les unités, les fuseaux horaires et les règles de nettoyage. Le mapping est souvent la partie la moins visible du projet et l’une des plus importantes.

6. Prévenir les doublons et les mises à jour en boucle

Un flux qui crée un nouvel enregistrement à chaque événement finit par produire une base inutilisable.

Pour éviter les doublons, choisissez une clé de rapprochement fiable : identifiant externe, email contrôlé, numéro de commande ou combinaison de plusieurs champs. La clé doit être stable et documentée.

Prévoyez aussi le cas où :

• deux événements arrivent presque en même temps ;

• la même notification est reçue deux fois ;

• un utilisateur modifie manuellement la fiche entre deux synchronisations ;

• le rapprochement trouve plusieurs candidats ;

• un contact change d’adresse email ;

• un enregistrement est archivé dans un système mais encore actif dans l’autre.

Une intégration doit être idempotente : si elle reçoit deux fois le même événement, elle doit produire le même résultat qu’une seule réception, et non créer deux commandes ou deux tâches.

Surveillez aussi les boucles. Si une mise à jour dans A déclenche une mise à jour dans B, qui déclenche à son tour une nouvelle mise à jour dans A, le système peut s’emballer. Il faut distinguer une modification humaine d’une modification produite par l’intégration, ou enregistrer l’identifiant de l’événement déjà traité.

7. Prévoir les erreurs avant le premier test

Une intégration n’est pas réussie parce que le cas nominal fonctionne une fois. Elle est fiable lorsque l’entreprise sait quoi faire quand le flux dévie.

Traitez au minimum les situations suivantes :

• champ obligatoire manquant ;

• valeur inconnue ;

• format invalide ;

• doublon probable ;

• outil destinataire indisponible ;

• délai d’attente dépassé ;

• limite de requêtes atteinte ;

• identifiant supprimé ;

• token expiré ;

• erreur partielle après plusieurs actions.

Une erreur doit laisser une trace exploitable : date, événement, enregistrement concerné, étape qui a échoué, message reçu et action attendue. Une notification disant « l’automatisation a échoué » ne permet pas à une équipe de reprendre le travail.

Selon le flux, prévoyez une nouvelle tentative automatique, une file d’attente, un traitement manuel ou un retour vers le système source. Les tentatives doivent être limitées et espacées. Réessayer sans règle peut aggraver une panne ou créer des doublons.

8. Gérer les droits et la sécurité

La connexion entre deux logiciels donne des droits à un compte, une application ou un service. Ces droits doivent être limités à ce que le flux doit réellement faire.

Quelques règles de base :

• utiliser des comptes ou identités dédiés lorsque c’est possible ;

• accorder le principe du moindre privilège ;

• séparer les environnements de test et de production ;

• stocker les secrets dans un gestionnaire prévu à cet effet ;

• utiliser des connexions chiffrées et des mécanismes d’authentification adaptés ;

• limiter les données copiées à ce qui est nécessaire ;

• conserver une trace des accès et des traitements ;

• revoir les droits lorsque le processus ou l’équipe change ;

• vérifier les responsabilités du prestataire ou de la plateforme d’intégration.

La CNIL recommande notamment de limiter les accès aux seules personnes qui en ont besoin, de tracer les actions et de protéger les données sensibles par des mesures adaptées, dont le chiffrement lorsque cela est nécessaire.

La sécurité ne se résume pas au mot de passe de l’outil. Elle concerne aussi les fichiers intermédiaires, les logs, les exports de test, les comptes de maintenance et les prestataires qui peuvent voir les données.

9. Tester un flux complet, pas seulement une connexion

Avant d’étendre l’intégration à toute l’entreprise, testez un scénario limité mais représentatif.

Le plan de test doit couvrir :

1. le cas normal ;

2. le doublon ;

3. la donnée obligatoire manquante ;

4. la valeur inconnue ;

5. l’indisponibilité temporaire d’un logiciel ;

6. le dépassement de délai ;

7. la réception en double du même événement ;

8. l’absence de droits suffisants ;

9. un volume supérieur au volume habituel ;

10. la reprise après échec.

Testez également le résultat dans les deux systèmes. Une intégration peut afficher une exécution réussie tout en écrivant une valeur incorrecte, en tronquant un texte ou en créant un enregistrement au mauvais endroit.

Le meilleur premier périmètre n’est pas nécessairement le flux le plus facile. C’est un flux assez important pour révéler les vrais problèmes, mais assez limité pour être corrigé sans bloquer l’activité.

10. Prévoir la maintenance dès le départ

Une intégration peut fonctionner pendant des mois, puis s’arrêter après une modification de champ, une nouvelle version d’API, un changement de mot de passe ou une évolution de licence.

Pour éviter la panne silencieuse, documentez :

• le but du flux ;

• son propriétaire ;

• les systèmes concernés ;

• le système de référence ;

• le mapping ;

• les identifiants et secrets utilisés, sans exposer les secrets eux-mêmes ;

• les limites connues ;

• les alertes ;

• la procédure de reprise ;

• la date de dernière vérification.

Ajoutez un contrôle régulier des exécutions, des erreurs et des volumes. Une intégration sans supervision devient un employé invisible à qui personne ne parle jusqu’au jour où quelqu’un découvre que les données ne circulent plus depuis trois semaines.

La maintenance doit aussi inclure une veille sur les logiciels connectés. Un changement de statut, de champ obligatoire ou de version d’API peut modifier le comportement du flux sans que le processus métier ait changé.

11. La checklist de cadrage

Avant de demander un devis ou de choisir un outil, vérifiez que vous pouvez répondre à ces questions :

• Quel événement déclenche le flux ?

• Quelle donnée doit circuler ?

• Dans quel sens ?

• Avec quel délai maximum ?

• Quel système fait foi pour chaque donnée ?

• Comment reconnaître un enregistrement existant ?

• Que faire si la donnée est incomplète ?

• Que faire si l’échange est reçu deux fois ?

• Qui peut lire, créer ou modifier les données ?

• Quelles limites de volume et de fréquence s’appliquent ?

• Comment les erreurs sont-elles signalées ?

• Qui reprend un flux en échec ?

• Comment tester sans exposer de données sensibles ?

• Qui maintient l’intégration lorsque les outils évoluent ?

• Comment mesurer que le flux améliore réellement le processus ?

Si plusieurs réponses manquent, le sujet n’est pas encore un problème de connecteur. C’est un problème de cadrage.

Conclusion

Pour connecter deux logiciels qui ne communiquent pas, commencez par décrire le flux et non par choisir une technologie.

Un connecteur natif peut suffire. Une API donnera davantage de contrôle. Un webhook réagira à un événement. Une synchronisation planifiée ou un fichier conviendront lorsque l’immédiateté n’est pas nécessaire. Un middleware aidera à orchestrer plusieurs règles. Un développement spécifique sera justifié lorsque les contraintes métier ou techniques l’exigent.

Dans tous les cas, la fiabilité dépendra des mêmes décisions : système de référence, mapping, doublons, erreurs, droits, sécurité, tests et maintenance. Je veux connecter mes outils.

Le premier livrable d’une intégration n’est donc pas une connexion entre deux comptes. C’est une règle claire sur ce qui doit circuler, qui en est responsable et comment l’entreprise saura que le flux fonctionne encore.

FAQ

Peut-on connecter deux logiciels sans savoir coder ?

Oui, lorsque les logiciels proposent un connecteur natif ou qu’une plateforme d’automatisation couvre le besoin. Cela ne dispense pas de définir le flux, les données, les droits et les traitements d’erreur. Une configuration sans cadrage peut déplacer le problème au lieu de le résoudre.

API ou webhook : quelle est la différence ?

Une API permet généralement de demander ou de modifier une information. Un webhook permet à un logiciel d’envoyer une notification lorsqu’un événement se produit. Les deux mécanismes sont souvent complémentaires : le webhook déclenche le traitement, puis l’API récupère les détails nécessaires.

Quand utiliser une synchronisation planifiée ?

Utilisez-la lorsque le processus accepte un délai, que les données peuvent être traitées par lots ou que les logiciels ne proposent pas de déclenchement événementiel. Vérifiez la reprise après échec et la capacité à ne récupérer que les données nouvelles ou modifiées.

Faut-il toujours utiliser un middleware ?

Non. Un middleware est utile lorsque plusieurs règles, systèmes, transformations, reprises ou alertes doivent être orchestrés. Pour un flux simple, il peut ajouter une dépendance inutile. Pour un flux critique et évolutif, il peut éviter de disperser la logique dans plusieurs automatisations difficiles à surveiller.

Comment éviter les doublons lors d’une intégration ?

Définissez une clé de rapprochement stable, recherchez l’enregistrement avant de le créer et rendez le traitement idempotent. Testez aussi les événements reçus plusieurs fois et les mises à jour concurrentes.

Qui doit être le système de référence ?

Le système de référence dépend de la donnée et du processus. Le CRM peut faire foi pour l’étape commerciale, tandis que le logiciel de facturation fait foi pour le paiement. Il n’est pas nécessaire de désigner un seul outil pour toutes les informations.

Une intégration est-elle un projet ponctuel ?

Non. La mise en place est un projet, mais l’intégration devient ensuite un composant à surveiller et à maintenir. Les champs, les droits, les versions d’API, les quotas et les offres des éditeurs peuvent évoluer.

Comment sécuriser une connexion entre deux logiciels ?

Limitez les droits au strict nécessaire, utilisez des identités dédiées, protégez les secrets, séparez les tests de la production, chiffrez les échanges, limitez les données transférées et conservez des traces exploitables. Vérifiez aussi les responsabilités de la plateforme ou du prestataire qui traite les données.