Comment savoir si vos outils ont besoin d'être connectés ?
Le signe le plus sûr est un export suivi d'un import. Tous les lundis, quelqu'un exporte les commandes du site en CSV, retouche les colonnes dans un tableur, puis les importe dans la gestion commerciale. Le jour où la personne est absente, rien ne passe. Le jour où le site ajoute une colonne, l'import plante. Le symptôme métier, lui, est décrit sur notre page pour éliminer les doubles saisies ; cette page traite de la mécanique : comment les outils se parlent, et avec quoi.
Pour estimer l'enjeu, listez vos flux sur une feuille : quelle donnée part de quel outil, vers quel outil, à quelle fréquence, et qui la fait passer. Chaque flux manuel a un coût en temps, un délai (la donnée arrive en retard) et un risque d'erreur. Les flux qui touchent l'argent (commandes, factures, paiements) et le stock passent en premier.
API, webhook, export de fichiers : quelles différences ?
| Mécanisme | Principe | Délai | Point d'attention |
|---|---|---|---|
| API | Un programme interroge ou modifie les données d'un logiciel par des requêtes normalisées | Immédiat à la demande | Limites de requêtes, droits d'accès, versions de l'API |
| Webhook | Le logiciel prévient lui-même un autre programme quand un événement se produit (nouvelle commande, paiement reçu) | Quelques secondes | Messages perdus si le destinataire est indisponible : il faut une reprise |
| Interrogation périodique | Un programme demande toutes les X minutes « quoi de neuf ? » | Selon la fréquence | Charge inutile si rien ne change |
| Échange de fichiers | Dépôt programmé de CSV ou XML sur un serveur, lu par l'autre outil | Heures | Format fragile, mais parfois seule option avec un logiciel ancien |
| Accès à la base | Lecture directe dans la base d'un logiciel qui n'a pas d'API | Variable | À réserver à la lecture, et à valider avec l'éditeur |
Une bonne intégration combine souvent deux mécanismes : le webhook pour la rapidité, et une interrogation de rattrapage chaque nuit pour récupérer ce qui aurait été manqué.
Quelle architecture pour plus de deux logiciels ?
Avec deux outils, une liaison directe suffit. À partir de trois ou quatre, les liaisons en étoile se multiplient et deviennent impossibles à maintenir : chaque changement chez un éditeur casse plusieurs flux. Deux règles structurent le travail.
- Une source de vérité par donnée : le client est maître dans le CRM, l'article et le prix dans l'ERP, le paiement chez le prestataire de paiement, l'écriture en comptabilité. Cette décision est une décision de gestion, prise avec vous, avant toute ligne de code.
- Un point de passage central : un petit service d'intégration reçoit les événements, applique les correspondances (le code client de l'ERP et l'identifiant du CRM), journalise chaque échange et rejoue ce qui a échoué. Les outils ne se parlent plus directement : ils parlent au service, qui isole chaque éditeur.
Ce service tient en peu de code, écrit par exemple en Node.js, avec une base PostgreSQL pour la table de correspondance des identifiants et le journal. Il est hébergé chez vous ou sur votre compte, et il vous appartient.
Ce qu'on automatise et ce qu'on surveille
Une intégration fiable n'est pas celle qui ne tombe jamais en panne : c'est celle dont on sait tout de suite qu'elle est en panne, et qui reprend sans perte. Les garanties que nous mettons en place :
- Idempotence : un même événement reçu deux fois ne crée pas deux commandes.
- File d'attente et reprise : si l'ERP est indisponible, les messages attendent et repartent automatiquement.
- Journal consultable : pour chaque commande, on voit quand elle est partie, où elle est arrivée, avec quelle réponse.
- Alertes : un échec répété ou une file qui grossit déclenche un message à la bonne personne.
- Écran des anomalies : les cas que la machine ne sait pas trancher (client inconnu, article supprimé) attendent une décision humaine au lieu d'être ignorés.
Les secrets d'accès aux API sont stockés à part, avec des droits limités au strict nécessaire pour chaque flux. Pour les principes de sécurité, voir notre guide sécurité web pour PME.
Exemples de connexions fréquentes
- E-commerce vers ERP et transporteur : la commande payée descend dans la gestion, l'étiquette est générée, le numéro de suivi remonte au client. Sur le projet Pièces Peugeot Motocycles, les services web Chronopost sont intégrés de bout en bout : choix du point relais, étiquette en un clic, suivi envoyé automatiquement.
- Paiement vers comptabilité : les paiements et remboursements Stripe sont rapprochés des factures.
- CRM vers facturation : l'affaire gagnée crée le client et le devis accepté prépare la facture.
- Logiciel métier vers plateforme de facturation électronique : dépôt des factures et retour des statuts, voir notre page sur la facture électronique dans un logiciel métier.
- Outils internes vers tableau de bord : consolidation des indicateurs, détaillée dans notre page sur le tableau de bord de pilotage.
Le déroulé suit notre méthode : cadrage des flux et des sources de vérité, puis chiffrage ; conception des correspondances ; construction flux par flux avec un environnement de test ; mise en service avec une période de double contrôle ; évolution quand un éditeur change son API.
Quand un connecteur du marché suffit
Les plateformes d'intégration sans code, comme Zapier, Make ou n8n (qui peut aussi s'auto-héberger), relient des milliers d'applications (plus de 9 000 revendiquées par Zapier) par des scénarios configurables. Elles sont souvent la bonne réponse :
- les deux outils sont des logiciels en ligne connus, présents dans leur catalogue ;
- le flux est simple, dans un sens, sans règles de correspondance complexes ;
- le volume reste modéré, car la tarification de ces services croît avec le volume traité (paliers de tâches chez Zapier, nombre d'exécutions de workflows pour n8n Cloud) ;
- une interruption de quelques heures n'est pas grave.
Le développement sur mesure prend l'avantage quand le flux touche l'argent ou le stock et doit être rejoué sans perte, quand un des logiciels est ancien ou spécifique, quand la logique de correspondance est riche, ou quand les volumes rendent la facturation à l'opération coûteuse. Une voie intermédiaire existe aussi : garder le connecteur pour les flux simples et coder seulement le flux critique. Si l'un de vos logiciels est si fermé qu'aucune connexion n'est possible, la question devient celle de son remplacement, traitée dans notre page sur l'ERP inadapté à vos processus.
Questions fréquentes
- Qu'est-ce qu'une API, en termes simples ?
- Une API est une porte d'entrée normalisée qu'un logiciel ouvre aux autres programmes. Au lieu qu'une personne exporte un fichier et le réimporte ailleurs, un programme demande directement au logiciel « donne-moi les commandes du jour » ou « crée ce client », et reçoit une réponse structurée. C'est le moyen standard de connecter des logiciels entre eux.
- Que faire si notre logiciel n'a pas d'API ?
- Quand un logiciel n'a pas d'API, plusieurs voies restent possibles : échange de fichiers programmés s'il sait exporter et importer, lecture directe de sa base de données en accord avec l'éditeur, ou automatisation de son interface en dernier recours. Ces solutions sont plus fragiles qu'une API, et c'est souvent un argument pour envisager son remplacement.
- Zapier, Make ou développement sur mesure : comment choisir ?
- Zapier, Make et n8n conviennent aux flux simples entre logiciels en ligne connus, avec un volume modéré et une tolérance aux interruptions. Le développement sur mesure se justifie quand le flux est critique (argent, stock), qu'il doit être rejoué sans perte, qu'un logiciel est ancien ou spécifique, ou que le volume rend la facturation à l'opération trop coûteuse.
- Que se passe-t-il quand un éditeur modifie son API ?
- Quand un éditeur modifie son API, il l'annonce en principe et laisse un délai de transition, mais rien ne le garantit. Une intégration bien construite isole chaque éditeur dans un module dédié, ce qui limite la correction à un seul endroit. Le journal des échanges et les alertes signalent immédiatement un flux qui échoue après un changement non annoncé.
- Une synchronisation dans les deux sens entre CRM et ERP est-elle possible ?
- Oui, une synchronisation dans les deux sens entre CRM et ERP est possible, mais c'est la configuration la plus délicate. Il faut décider, champ par champ, quel logiciel fait autorité, gérer les modifications simultanées des deux côtés et éviter les boucles où chaque outil renvoie la modification à l'autre. Quand c'est possible, une circulation à sens unique par type de donnée reste plus simple et plus fiable.