Connecter une application de terrain à un Sage 100 installé sur serveur

Le contexte

Une PME française spécialisée dans la distribution de fournitures industrielles avait construit avec Lovable une application de terrain pour ses commerciaux : planning des visites, devis, suivi des ventes, des stocks et des paiements, prospects, frais de déplacement, catalogue produit.

L’application fonctionne et elle colle au métier des équipes qui l’utilisent. Mais elle vit en vase clos. Les articles, les clients et les documents de vente sont dans Sage 100, et rien ne circule entre les deux. Elle avait été conçue à partir d’exports Excel figés : pour la mettre à jour, il fallait refaire l’export, puis le réimporter dans le projet Lovable.

Le défi

Relier une application générée par IA à un ERP posé sur un serveur dans les locaux de l’entreprise. C’est précisément là que Lovable atteint sa limite, pour quatre raisons.

L’application n’a pas de serveur à elle

Ce que Lovable produit est une application dite « à page unique » : tout le code s’exécute dans le navigateur du commercial. Il n’y a aucun programme à nous, tournant sur un serveur, capable d’aller dialoguer avec un autre logiciel.

Or un ERP installé sur un serveur interne ne parle pas à un navigateur. Il faut un intermédiaire entre les deux, un programme qui va chercher la donnée d’un côté et la dépose de l’autre. Ce chaînon manque, et aucun outil de génération ne le produit.

L’ERP n’avait pas de porte d’entrée prévue

Sage 100 tournait sur un serveur Windows appartenant à l’entreprise, dans ses murs, et non chez un hébergeur. Les modules de services web, ceux qui permettent à un autre logiciel de l’interroger par la voie officielle, n’étaient pas installés.

Il restait une porte : une connexion directe en lecture sur la base de données, par ODBC. Elle n’a été possible que parce que les infogérants qui tiennent le serveur ont travaillé avec nous.

Écrire dans Sage n’est pas le symétrique de lire

Sage applique un schéma strict. Un champ manquant, et la pièce entière est rejetée. Écrire directement dans la base, sans passer par les accès prévus pour cela, contournerait ses propres contrôles de cohérence, avec des conséquences comptables graves.

Deux sujets sans commune mesure

Le client n’est pas technique et comparait la vitesse à laquelle une interface Lovable se monte au raccordement d’un ERP. La comparaison est naturelle : il avait obtenu son application en quelques semaines pour quelques dizaines d’euros. Il a fallu expliquer pourquoi le second sujet n’a rien à voir avec le premier, et le cadrer avant de s’engager.

Notre intervention

• Un cadrage serré avant tout engagement. Vu le contexte, la faisabilité devait être établie avant de chiffrer : version exacte de Sage, mode d’hébergement, accès serveur possible ou non, volumétrie. Ces réponses viennent de l’infogérant, pas du client. Le périmètre a été écrit et validé, et les prérequis qui dépendaient du client listés, avant la première ligne de code.
• Un agent de synchronisation installé sur le serveur du client. Un service léger qui lit la base Sage en local : articles, clients, lignes de documents de vente. Il filtre et prépare ces données, parce que Sage les stocke pour ses propres besoins et non pour être lues telles quelles. Puis il les pousse vers la base de l’application, la nuit et en milieu de journée. C’est le rythme demandé par le client ; une fréquence plus courte était possible.
• Des journaux consultables. L’agent écrit ce qu’il a fait. L’application connaît l’état de la dernière synchronisation et peut alerter quand un écart apparaît. Une synchronisation qui tombe ne doit pas passer inaperçue.
• La lecture seule comme principe. Les devis sont saisis dans l’application, puis ressaisis dans Sage. Nous nous interdisons d’écrire dans la base d’un ERP sans passer par les accès prévus à cet effet : le risque est disproportionné par rapport au temps gagné. Nous avons exposé la situation au client, qui l’a comprise et validée. Le sujet reste ouvert : une partie du code est déjà prête à porter l’envoi des devis le jour où le module de services web sera installé sur son instance Sage.
• Un signalement écrit sur ce qui sortait du périmètre. En inspectant le code, nous avons trouvé des problèmes qui n’entraient pas dans notre mission : identifiants et adresses de messagerie écrits en dur, listes figées, et surtout une application publiée sur le web sans aucune authentification. N’importe qui pouvait ouvrir l’interface et consulter des données internes, sans comptes, sans rôles et sans droits d’accès. Nous l’avons documenté et transmis par écrit, ce qui a permis au client de traiter le sujet.

Le résultat

L’application travaille désormais avec les données de l’ERP, sans import manuel. Le client garde son outil et son ERP, et la relation se poursuit : les nouvelles demandes sont traitées au fil de l’eau, avec un périmètre écrit à chaque fois.

Ce que ce cas illustre

• Un outil de génération monte vite une interface. Connecter le réel, un ERP, un serveur interne, un schéma métier, demande un travail d’ingénierie et de cadrage.
• Une application Lovable n’a pas de serveur à elle. Dès qu’il faut faire dialoguer deux logiciels entre eux, sans personne devant l’écran, l’intermédiaire est à construire.
• Le cadrage écrit protège le client autant que le prestataire.
• Construire un outil sans connaissances techniques peut exposer les données de l’entreprise. Faire vérifier ce que l’on produit n’est ni une option ni un luxe.