Votre application web et votre logiciel de gestion contiennent les mêmes informations, saisies deux fois. Les clients, les articles, parfois les commandes. Quelqu’un fait le pont à la main, et cette personne finit par devenir le point de fragilité de toute l’organisation.

Relier les deux est un projet de développement classique. Ce qui le fait dériver, ce sont cinq décisions que l’on croit accessoires et qui déterminent tout.

Première décision : le sens de circulation

C’est la question qui change le plus le coût du projet.

Une liaison en lecture affiche dans votre application des informations qui vivent dans votre logiciel de gestion. Rien n’est modifié du côté de l’ERP, le risque comptable est nul, et une bonne partie des irritants disparaît : plus de recopie de fiches clients, plus de tarifs périmés, plus de stock approximatif.

Une liaison en écriture crée ou modifie des données dans votre logiciel de gestion depuis l’application. Elle engage vos comptes, elle demande une validation de la personne qui les tient, et elle suppose de respecter toutes les règles internes de l’ERP.

Beaucoup d’entreprises demandent l’écriture et découvrent, une fois le périmètre écrit, que la lecture réglait déjà 80 % de leur problème. Commencer par là raccourcit le délai de mise en service et fait apparaître les écarts de données avant qu’ils ne coûtent cher.

Deuxième décision : qui fait autorité

Une adresse client existe des deux côtés. Un commercial la corrige dans l’application, une assistante la corrige dans l’ERP, chacune de son côté et le même jour. Laquelle gagne ?

Sans réponse écrite, la dernière écriture l’emporte, ce qui revient à dire que la correction de quelqu’un disparaît sans qu’il le sache. Le problème se manifeste des mois plus tard, sous la forme d’une facture partie à une ancienne adresse.

La réponse ne doit pas être uniforme. Le tarif fait autorité dans l’ERP, l’état d’avancement d’un chantier fait autorité dans l’application. Cette liste s’écrit champ par champ, et c’est un travail de métier plus que de technique.

Troisième décision : la règle d’appariement

Comment sait-on que le client de l’application et le client de l’ERP sont la même entreprise ?

Le nom ne suffit pas : il s’écrit de trois façons différentes. L’adresse de messagerie change. Le numéro d’immatriculation est fiable mais souvent absent d’un côté. La règle retenue détermine directement le nombre de doublons que vous découvrirez dans six mois.

Ce travail suppose de regarder vos données réelles, pas un échantillon théorique. Sur presque tous les projets, cette étape révèle des doublons préexistants que personne n’avait remarqués.

Quatrième décision : le rythme

Une donnée consultée en direct à chaque affichage suppose que votre logiciel de gestion réponde vite et reste disponible en permanence. Une synchronisation toutes les heures ou chaque nuit tolère un décalage et sollicite beaucoup moins vos serveurs.

La réponse dépend de l’usage. Un stock affiché à un client qui commande doit être frais. Un chiffre d’affaires cumulé affiché sur un tableau de bord interne supporte parfaitement un décalage d’une journée.

Ce choix pèse plus lourd sur le coût que le volume de données échangées, et il est réversible : on peut accélérer plus tard, rarement l’inverse.

Cinquième décision : le comportement en cas d’échec

C’est le point le plus souvent oublié, et celui qui fait la différence entre une liaison qui tient trois ans et une liaison qu’on abandonne au bout de six mois.

Le réseau tombe. L’ERP est en cours de sauvegarde. Un champ obligatoire manque. Une commande est refusée parce que le client est bloqué en compte.

Trois questions à trancher : est-ce qu’on réessaie, et combien de fois ? est-ce que quelqu’un est prévenu, et qui ? est-ce qu’on peut voir, de l’extérieur, la date du dernier échange réussi ?

Une liaison qui échoue en silence produit deux systèmes qui divergent lentement. Personne ne s’en aperçoit avant qu’un écart ne devienne visible sur un chiffre, et le rattrapage manuel coûte alors plus cher que la construction initiale.

Ce qui ne relève pas du développement

Deux points se règlent avant d’écrire la moindre ligne.

Les accès. Un compte technique dédié, avec des droits limités aux tables et aux opérations nécessaires, vaut mieux que le compte d’un utilisateur. Le principe vaut aussi pour les données transmises : ne faire circuler que ce dont l’application a besoin limite l’exposition, et la durée pendant laquelle ces données sont conservées de part et d’autre relève des mêmes règles. Cela se demande au cadrage, pas la veille de la mise en service.

Votre intégrateur en place. Il connaît votre paramétrage, il gère vos droits, il verra passer les flux dans les journaux. L’associer dès le début évite les blocages au moment le plus gênant.

Ce que révèle presque toujours le premier essai

Une liaison met en lumière l’état réel de vos données, et cette découverte fait partie du projet plutôt que de le contrarier.

Les doublons arrivent en tête. Le même client saisi deux fois avec une virgule de différence, une société changée de nom dont les deux fiches subsistent, un particulier enregistré sous son nom de jeune fille et son nom d’usage. Ces doublons existaient déjà, personne ne les voyait, et la confrontation à un second système les rend visibles d’un coup.

Viennent ensuite les enregistrements incomplets. Une fiche sans code postal passe inaperçue dans l’ERP, où personne ne s’en sert pour l’expédition, et bloque une commande dans l’application qui calcule des frais de port.

Enfin les conventions implicites. Le commercial qui note « URGENT » en majuscules au début du libellé, la référence article qui contient une année pour distinguer deux modèles, le champ commentaire utilisé comme second champ adresse. Ces usages fonctionnent tant qu’un humain lit ; un programme les ignore ou s’y casse.

Découvrir cela sur un flux en lecture coûte quelques heures de nettoyage. Le découvrir sur un flux d’écriture, une fois que des documents faux sont partis chez des clients, coûte beaucoup plus.

Ce que nous faisons

Nous écrivons ces cinq décisions en français, avec vous, avant de développer. Le document dit ce que la liaison fait, ce qu’elle ne fait pas, dans quel sens, à quel rythme, et ce qui se passe quand un envoi échoue.

Vous validez, vous recevez un devis à prix fixe, et la liaison arrive par lots que vous voyez fonctionner. Nous prévoyons systématiquement la reprise et la trace, parce qu’une liaison silencieuse coûte toujours plus cher que le développement lui-même.