« Connecter HubSpot à notre ERP » recouvre des réalités techniques très différentes selon l'ERP en question. Un ERP cloud moderne et un ERP installé sur un serveur local il y a dix ans ne se connectent pas de la même façon. Voici les quatre architectures que nous rencontrons le plus souvent, et comment savoir laquelle s'applique à votre cas.
1. Connexion directe par API
Quand l'ERP expose une API REST ou SOAP accessible depuis Internet, c'est l'architecture la plus simple : le connecteur interroge l'ERP (ou HubSpot) à intervalles réguliers, ou en continu selon le volume, pour lire et écrire les données. C'est le cas des ERP cloud comme Divalto en mode SaaS, ou de nombreuses suites modernes.
Ce qu'il faut vérifier : la documentation de l'API, les quotas et limites de débit, et si l'authentification permet un accès applicatif stable (clé API, OAuth) plutôt qu'un compte utilisateur nominatif.
2. Notification par webhook
Si l'ERP peut notifier un système externe dès qu'un événement se produit (nouvelle commande, facture validée), un webhook évite d'interroger l'ERP en permanence : l'information arrive en quasi temps réel, sans charge inutile. C'est souvent combiné avec une API pour les lectures ponctuelles et un webhook pour les événements critiques.
Ce qu'il faut vérifier : quels événements sont réellement notifiés, et si l'ERP retente l'envoi en cas d'échec (sans quoi une notification manquée peut passer inaperçue).
Le détail de ces deux modes est expliqué dans notre page API, webhook ou fichier : comment choisir.
3. Échange par fichier
C'est l'architecture la plus fréquente avec les ERP installés en France — EBP, Sage, Cegid dans certaines configurations. Le logiciel n'est pas accessible depuis Internet ; l'échange passe par des fichiers (CSV le plus souvent) déposés sur un serveur intermédiaire (FTP, SFTP) que les deux systèmes peuvent atteindre. L'ERP exporte à intervalle régulier, le connecteur lit et transforme, puis dépose en retour ce que l'ERP doit importer.
Ce qu'il faut vérifier : le format exact attendu (encodage, séparateur, structure des colonnes) — un écart provoque souvent un rejet silencieux plutôt qu'une erreur exploitable. Voir notre fiche EBP installé pour un exemple détaillé de ce mécanisme.
4. Agent local ou passerelle
Quand l'ERP n'expose ni API ni accès fichier externe — totalement isolé sur le réseau interne, sans possibilité d'ouvrir un accès sortant — la dernière option est un agent installé sur le réseau du client, qui fait le pont entre l'ERP local et le cloud. L'agent lit les données localement et les transmet de façon sécurisée vers la plateforme d'intégration.
Ce qu'il faut vérifier : qui héberge et maintient cet agent (le client, son infrastructure interne, ou le prestataire), et quelle est la procédure en cas de panne réseau ou de mise à jour de l'ERP.
Notre page logiciels installés détaille ce qui change concrètement quand un logiciel n'est pas accessible depuis Internet.
Comment savoir laquelle s'applique à votre ERP
Trois questions suffisent à orienter le choix :
- Votre ERP est-il accessible depuis Internet ? Si non, c'est fichier ou agent local — pas d'API directe possible.
- Expose-t-il une documentation d'API ou de webhooks ? Si oui et que l'ERP est accessible, l'API (complétée par webhook si disponible) est la voie la plus robuste.
- Qui peut ouvrir un accès (FTP, VPN, agent) sur le réseau de l'ERP ? C'est souvent le point qui bloque un projet — cette répartition doit être tranchée au cadrage, avant le développement.
Les flux, une fois construits, sont hébergés et supervisés sur Moglo, notre plateforme de connecteurs — quelle que soit l'architecture retenue.
Vous ne savez pas quelle architecture s'applique à votre ERP ? Décrivez-nous votre contexte, nous vous répondons avec une première analyse sous 48h.