Comment connecter ses logiciels métier : export, connecteur ou API ?

Un devis saisi dans un outil, recopié dans le logiciel de facturation, puis reporté dans un tableau de suivi. Chaque ressaisie prend du temps et finit par produire une erreur. La plupart des structures qui me contactent n’ont pas besoin d’un nouveau logiciel : elles ont besoin que ceux qu’elles utilisent déjà se parlent.

Cet article explique les trois façons de faire communiquer des logiciels, comment choisir entre elles et ce qu’une intégration fiable doit prévoir. Il s’adresse aux PME, associations et collectivités, sans prérequis technique.

En bref

Il existe trois façons de connecter des logiciels métier : l’échange de fichiers (export puis import CSV ou Excel), le connecteur no-code (Zapier, Make, n8n) et l’API sur mesure. L’export suffit pour un échange ponctuel. Le connecteur convient à des flux simples entre outils grand public. L’API sur mesure s’impose quand les règles métier, les volumes ou la fiabilité deviennent critiques.

• Avant de choisir : vérifier que chaque logiciel propose une API documentée, et à quel niveau d’abonnement.
• La vraie question : quel outil fait foi pour chaque donnée, et que se passe-t-il quand un échange échoue.
• Le piège : une synchronisation qui échoue en silence est pire qu’une ressaisie manuelle.

Qu’est-ce qu’une API, concrètement, pour une PME ou une association ?

Une API est une porte d’entrée qu’un logiciel ouvre pour que d’autres programmes puissent lire ou modifier ses données sans passer par l’écran. Au lieu d’exporter un fichier puis de l’importer ailleurs, un programme demande directement « donne-moi les factures du jour » et reçoit une réponse structurée, le plus souvent au format JSON.

Pour une structure, cela veut dire qu’une information saisie une fois peut circuler automatiquement : un adhérent inscrit sur le site apparaît dans l’outil de gestion, une commande validée crée la facture, un dossier clôturé met à jour le tableau de bord. L’API ne fait rien seule : il faut un programme, un connecteur ou un développement pour l’utiliser.

Export de fichiers, connecteur no-code ou API sur mesure : que choisir ?

Le bon choix dépend de la fréquence des échanges, du volume, de la complexité des règles et du coût d’une erreur. Le tableau ci-dessous résume les situations où chaque option fonctionne bien.

Les options ne s’excluent pas. Un connecteur peut servir de prototype pour valider un flux pendant quelques semaines, avant de le reprendre en développement quand les règles se stabilisent. À l’inverse, développer une API sur mesure pour un export trimestriel est rarement justifié.

Comment savoir si un logiciel propose une API ?

Cherchez dans la documentation ou le pied de page du logiciel les mots « API », « développeurs », « intégrations » ou « webhooks ». Un éditeur sérieux publie une documentation, souvent au format OpenAPI, qui liste les données accessibles et les actions possibles. Si rien n’est public, posez la question au support.

Avant de vous engager, vérifiez quatre points :

• Le niveau d’abonnement : l’accès à l’API est parfois réservé aux offres supérieures.
• Le périmètre : l’API expose-t-elle les données dont vous avez besoin, en lecture et en écriture ?
• Les limites d’appels : un quota par minute ou par jour peut bloquer une synchronisation de gros volumes.
• Les webhooks : le logiciel peut-il prévenir les autres outils quand une donnée change, ou faut-il l’interroger régulièrement ?

Si un logiciel n’a pas d’API, il reste parfois l’export automatique planifié, l’accès à la base de données ou l’envoi d’emails structurés. Ces solutions fonctionnent, mais sont plus fragiles : elles cassent sans prévenir quand l’éditeur change son format.

Synchronisation en temps réel ou par lots ?

Le temps réel n’est utile que si quelqu’un attend l’information dans la minute. Pour la plupart des flux de gestion, une synchronisation par lots toutes les heures ou chaque nuit est plus simple, moins coûteuse et plus facile à surveiller.

• Temps réel (webhook) : le logiciel source prévient dès qu’une donnée change. Utile pour une inscription à confirmer, un paiement, une alerte terrain.
• Par lots (planifié) : un programme récupère à heure fixe tout ce qui a changé depuis le dernier passage. Adapté aux statistiques, à la comptabilité, aux tableaux de bord.

Dans les deux cas, il faut décider quel outil fait foi pour chaque donnée. Si le nom d’un client peut être modifié dans deux logiciels, lequel gagne en cas de conflit ? Sans cette règle écrite, les données divergent en quelques semaines.

Que se passe-t-il quand une synchronisation échoue ?

Elle doit le signaler, réessayer, puis laisser une trace exploitable. Un échange qui échoue en silence est le défaut le plus coûteux d’une intégration : on découvre des semaines plus tard que des factures ou des inscriptions manquent, sans savoir lesquelles.

Une intégration fiable prévoit :

• des nouvelles tentatives espacées quand le service distant est indisponible ;
• des échanges idempotents : rejouer deux fois le même envoi ne doit pas créer deux factures ;
• un journal qui indique quelles données ont été envoyées, quand, et avec quel résultat ;
• une alerte envoyée à une personne identifiée quand les erreurs s’accumulent ;
• une file d’échecs que l’on peut consulter et relancer après correction.

Avec Symfony, ces besoins sont couverts par des composants standard : HttpClient pour appeler les API, Messenger pour la file d’attente, les nouvelles tentatives et le transport des échecs, Scheduler pour les synchronisations planifiées. On ne réinvente pas l’infrastructure, on écrit les règles métier. La page développement d’API Symfony présente cette approche.

Quelles précautions pour la sécurité et les données personnelles ?

Chaque connexion entre deux logiciels ouvre un accès à vos données. Elle doit donc avoir des droits limités au strict nécessaire, des identifiants stockés hors du code et une liste claire des données personnelles qui circulent.

• créer un compte ou une clé d’API dédiée à chaque intégration, avec les seuls droits utiles ;
• stocker les clés dans un coffre de secrets, jamais dans le code ou un tableur partagé ;
• ne transférer que les champs nécessaires, en particulier pour les données personnelles ;
• vérifier où sont hébergés les services tiers et les mentionner dans votre registre des traitements ;
• prévoir comment révoquer un accès si un outil est abandonné.

Comment cadrer un projet d’intégration ?

En décrivant les flux avant de parler de technique. Un cadrage d’intégration tient souvent sur deux pages et répond à cinq questions : quelles données circulent, dans quel sens, à quelle fréquence, quel outil fait foi, et qui est prévenu en cas d’erreur.

1. Lister les outils et les ressaisies actuelles, avec le temps qu’elles prennent.
2. Pour chaque flux, noter la source, la destination, la fréquence et le volume.
3. Faire correspondre les champs : un « client » dans un outil est-il un « contact » ou une « organisation » dans l’autre ?
4. Décrire les cas d’erreur : doublon, champ manquant, service indisponible.
5. Désigner la personne qui surveille et tranche.

Ce travail ressemble beaucoup au cadrage d’une application métier. L’article sur les questions à se poser avant de remplacer Excel donne une méthode proche.

Exemple : relier plusieurs sources de données dans PictoRecette

PictoRecette est une application Symfony qui produit des fiches recettes illustrées de pictogrammes pour des ateliers cuisine. Elle s’appuie sur plusieurs sources externes : les pictogrammes ARASAAC, les données produits d’Open Food Facts et des sources de recettes.

Le parcours relie plusieurs opérations : récupérer une information, la normaliser, l’associer à un pictogramme, puis la faire valider par un professionnel avant l’export PDF. C’est un cas typique : l’automatisation fait le travail répétitif, et l’humain garde la main sur la validation. Une intégration réussie n’enlève pas le contrôle, elle enlève la ressaisie.

FAQ

Un connecteur no-code suffit-il pour une petite structure ?

Souvent, oui, pour des flux simples entre outils grand public. Il devient limitant quand les règles se multiplient, quand le coût au volume augmente ou quand personne ne sait plus relire les scénarios. C’est le signal pour passer à un développement.

Peut-on connecter un logiciel ancien qui n’a pas d’API ?

Parfois, par un export planifié, un accès à sa base de données ou une API intermédiaire développée autour de lui. C’est plus fragile qu’une API officielle et cela demande une surveillance plus attentive.

Qui maintient l’intégration quand un logiciel change ?

Il faut le décider dès le départ. Les éditeurs font évoluer leurs API et annoncent la fin des anciennes versions. Une intégration a besoin d’un responsable et d’un contrat de maintenance, même léger.

Faut-il développer sa propre API ?

Seulement si votre application doit être consultée ou alimentée par d’autres outils. Pour une application métier sur mesure, prévoir une API dès le départ facilite les connexions futures. L’article sur Symfony et API Platform pour une application métier détaille ce choix.

Conclusion

Connecter ses logiciels métier ne commence pas par le choix d’un outil, mais par la liste des ressaisies et des flux réels. L’export suffit pour l’occasionnel, le connecteur pour le simple, l’API sur mesure pour ce qui doit être fiable et suivre vos règles. Dans tous les cas, une intégration doit signaler ses erreurs.

Si vos équipes recopient les mêmes informations d’un outil à l’autre, décrivez-moi vos outils et vos flux : on peut identifier ensemble ce qui mérite d’être automatisé, et ce qui ne le mérite pas.