ERPIntégrationApplication métierDSIMéthode
Intégrer une nouvelle application à un ERP existant
8 min de lecture
Pour intégrer une nouvelle application à un ERP existant, désignez d'abord le système maître de chaque donnée, puis choisissez le mode d'échange que l'ERP permet : API documentée, fichiers d'échange planifiés ou base intermédiaire. Prévoyez ensuite la gestion des erreurs, un compte technique aux droits limités, un environnement de test, et une supervision une fois l'intégration en service.
L'ERP reste le socle de la gestion ; l'application apporte ce qu'il ne fait pas bien. Voici comment les faire travailler ensemble sans fragiliser l'un ni l'autre.
Pourquoi une application à côté de l'ERP
Un ERP excelle sur ce qu'il a été conçu pour faire : la comptabilité, les achats, les stocks, la facturation, avec des règles communes à des milliers d'entreprises. Il est moins à l'aise avec un processus propre à votre métier : une saisie terrain sur téléphone, un circuit de validation particulier, un calcul que personne d'autre ne fait.
Deux réflexes coûtent cher. Le premier consiste à tordre l'ERP par du développement spécifique, au risque de compliquer chaque mise à jour. Le second consiste à laisser le processus dans des tableurs, ressaisis ensuite dans l'ERP. La troisième voie, une application ciblée qui échange avec l'ERP, est souvent la plus raisonnable, comme nous le développons dans notre comparaison entre sur-mesure et progiciel.
Étape 1 : cartographier les flux
Avant toute question technique, dressez la liste des données qui doivent circuler. Un tableau suffit.
| Donnée | Système maître | Sens de l'échange | Fréquence utile |
|---|---|---|---|
| Clients et sites | ERP | ERP vers application | Chaque nuit |
| Catalogue et tarifs | ERP | ERP vers application | Chaque nuit, ou à la modification |
| Stock disponible | ERP | ERP vers application | Au moment de la saisie |
| Commandes ou interventions validées | Application | Application vers ERP | À la validation |
| Statut de facturation | ERP | ERP vers application | Toutes les heures |
Ce tableau, illustratif, est celui d'une application de prise de commande ou de suivi d'interventions. Le vôtre sera différent, mais il aura la même forme, et il dira déjà l'essentiel du travail d'intégration.
Étape 2 : un seul maître par donnée
C'est la règle qui évite la plupart des incidents : chaque donnée a un seul système de référence. Si un client peut être modifié dans l'ERP et dans l'application, les deux versions finiront par diverger, et personne ne saura laquelle fait foi.
Dans la pratique, l'ERP reste maître des données de gestion (clients, articles, prix, écritures), et l'application devient maître de ce qu'elle produit (saisies terrain, validations, pièces jointes). Quand une modification doit remonter, elle remonte par l'échange prévu, jamais par une double saisie.
Étape 3 : choisir le mode d'échange
| Mode | Principe | Quand le choisir | Point de vigilance |
|---|---|---|---|
| API de l'ERP | L'application appelle les services publiés par l'ERP | ERP récent avec une API documentée | Droits du compte technique, limites d'appels, versions de l'API |
| Fichiers d'échange planifiés | Exports et imports réguliers (CSV, XML) déposés à un emplacement convenu | ERP ancien, ou flux en lot | Contrôle des fichiers rejetés, horodatage, reprise |
| Base ou service intermédiaire | Une zone tampon reçoit les données des deux côtés | Plusieurs applications à relier, ou ERP peu ouvert | Un composant de plus à héberger et à superviser |
| Plateforme d'intégration | Un outil du marché orchestre les flux entre logiciels | Système d'information déjà équipé d'un tel outil | Coût de licence, dépendance à l'outil |
| Écriture directe dans la base de l'ERP | L'application écrit dans les tables de l'ERP | À éviter | Contourne les règles de l'ERP, casse au moindre changement de version |
La plupart des ERP récents publient une interface documentée : c'est le cas par exemple de l'API externe d'Odoo ou des API de Microsoft Dynamics 365 Business Central. Quand l'API existe, c'est presque toujours la meilleure voie. La lecture directe de la base peut se discuter pour des tableaux de bord ; l'écriture directe, non.
Temps réel ou différé
Le temps réel séduit, mais il a un coût : chaque indisponibilité de l'ERP devient une indisponibilité de l'application. Réservez-le aux données dont une décision dépend sur le moment, comme un stock consulté avant de confirmer une commande.
Pour le reste, une synchronisation planifiée est plus robuste. Si l'ERP est en maintenance la nuit, la synchronisation suivante rattrape le retard, et l'application continue de fonctionner avec la dernière version connue des données.
Ce qui fait vraiment le travail : les cas d'erreur
Le cas nominal d'une intégration se construit vite. Ce qui demande du soin, c'est tout le reste :
- l'ERP ne répond pas : l'application met l'envoi en file d'attente et le rejoue, au lieu de perdre la donnée ;
- la donnée est refusée : un article inconnu, un client bloqué, un champ trop long ; le rejet est tracé et signalé à quelqu'un qui peut agir ;
- la même donnée arrive deux fois : l'échange est conçu pour qu'un second envoi ne crée pas de doublon ;
- les formats divergent : dates, décimales, unités, codes articles ; chaque correspondance est écrite et testée.
C'est souvent le poste le plus sous-estimé d'un chiffrage, comme nous l'expliquons dans notre article sur le prix d'une application métier.
Sécurité et droits
- Un compte technique dédié pour l'intégration, jamais le compte d'un salarié, avec uniquement les droits nécessaires aux flux prévus.
- Des secrets stockés hors du code (clés d'API, mots de passe), et renouvelables sans redéployer l'application.
- Une trace de chaque échange : qui, quoi, quand, avec quel résultat.
- Le RGPD appliqué aux flux : ne faire circuler que les données personnelles nécessaires, et documenter où elles vont.
Tester sans toucher à la production
Une intégration se teste sur un environnement de recette de l'ERP, alimenté par des données représentatives. Si votre ERP n'en a pas, c'est la première question à poser à son éditeur ou à son intégrateur : tester un connecteur directement sur la production revient à créer de vraies commandes et de vraies écritures pour vérifier qu'il fonctionne.
Prévoyez aussi un démarrage progressif : quelques utilisateurs, ou un seul flux, pendant une période d'observation, avant d'ouvrir l'ensemble.
Après la mise en service
Une intégration n'est jamais terminée. L'ERP reçoit des mises à jour, ses paramétrages évoluent, de nouveaux cas apparaissent. Trois habitudes évitent les ruptures silencieuses :
- superviser les échanges, avec une alerte quand un flux échoue ou s'arrête ;
- retester l'intégration avant chaque montée de version importante de l'ERP ;
- inscrire l'intégration dans le contrat de maintenance de l'application, comme nous le détaillons dans notre article sur la maintenance.
Les questions à poser avant de chiffrer
À l'éditeur ou à l'intégrateur de l'ERP :
- Quelle version de l'ERP utilisons-nous, et quelle est la prochaine montée de version prévue ?
- L'ERP publie-t-il une API, et sa documentation est-elle accessible ?
- Existe-t-il un environnement de recette, et comment y accéder ?
- Quels droits peut-on accorder à un compte technique ?
- Nos paramétrages ou développements spécifiques modifient-ils les objets concernés ?
Au prestataire de la nouvelle application :
- Comment gérez-vous une indisponibilité de l'ERP ?
- Comment évitez-vous les doublons quand un envoi est rejoué ?
- Comment les rejets sont-ils signalés, et à qui ?
- Qui maintient le connecteur quand l'ERP évolue ?
Ces questions trouvent naturellement leur place dans le cahier des charges, dont nous proposons une trame dans notre article sur la rédaction d'un cahier des charges d'application interne.
Notre façon de faire
Chez LPR Studio, nous connectons vos ERP, outils comptables, CRM et bases existantes plutôt que de les remplacer : une application qui ignore le reste de votre système d'information ne sert personne. Le prototype visuel gratuit, présenté en visio sous 5 jours ouvrés, montre déjà où chaque donnée entre et d'où elle vient, avant toute ligne de code. Le détail des formules est sur la page des offres.