Relier votre logiciel métier à Sage 100 ou Sage 50 : Objets Métiers, fichiers et API

Sage 100, Sage 50 ou Sage Active : quelle porte d'entrée ?

La porte d'entrée dépend du produit, car le nom Sage recouvre plusieurs logiciels qui ne s'ouvrent pas de la même façon. Avant tout chiffrage, notez le nom exact de votre logiciel, sa version et son mode d'installation.

Cette page détaille surtout Sage 100, dont l'intégration demande le plus de préparation.

Que permettent les Objets Métiers de Sage 100 ?

Les Objets Métiers permettent à un programme de lire et d'écrire dans les bases Sage 100 en passant par les règles de Sage plutôt que directement par les tables. Le manuel publié dans la base de connaissances de Sage les décrit comme une bibliothèque ActiveX destinée à simplifier le développement d'applications ; à l'écriture, Sage 100 Objets Métiers effectue des contrôles de cohérence et renseigne les valeurs par défaut d'un article, d'un tiers ou d'un document créé.

• Deux domaines. La comptabilité (classe BSCPTAApplication100c, fichier .mae) et la gestion commerciale (classe BSCIALApplication100c, fichier .gcm) ; le manuel précise qu'une base comptable est toujours liée à une base commerciale.
• Des objets métier. Tiers, clients et articles, ainsi que les enregistrements comptables et commerciaux, exposés par des fabriques d'objets.
• Des processus. Création de documents et transformation de documents, avec des contrôles avant toute écriture.
• Des limites écrites. Certains types de documents ne peuvent pas être créés, dont les factures comptabilisées, les archives, les dépréciations de stock et les tickets, et les tickets ne sont pas lisibles. Les prédicats, c'est-à-dire les collections filtrées et triées, demandent la version 10.05 ou plus.

Les exemples du manuel sont écrits en Visual Basic .NET et en C#. La bibliothèque est en 32 bits : sur un Windows 64 bits, le programme qui l'utilise doit être compilé pour x86.

Pourquoi une liaison Sage 100 passe par un service Windows

Une liaison Sage 100 passe en pratique par un service Windows, parce que l'accès programmé que documente Sage repose sur les Objets Métiers, une bibliothèque 32 bits utilisable sous Windows. Une annonce publiée il y a plus de quatre ans sur le forum officiel Sage 100 l'indiquait ainsi : « Sage ne propose pas d'API Web permettant d'accéder aux bases Sage 100 » ; elle orientait vers les Objets Métiers, sur lesquels chacun peut bâtir sa propre API web, ou vers des API web tierces. Ce message ancien ne dispense pas de faire confirmer par votre revendeur ce que propose aujourd'hui votre version.

L'architecture tient alors en trois pièces :

1. un service installé sur un serveur Windows qui voit la base Sage, avec la version des Objets Métiers alignée sur celle de Sage 100 ;
2. une API privée, exposée à vos applications (portail, application mobile), authentifiée et journalisée ;
3. une file d'attente, pour que les écritures patientent quand le serveur Sage est arrêté ou en maintenance.

Deux autres voies sont à écarter ou à vérifier. Le pilote ODBC de Sage 100 n'est plus commercialisé et sa maintenance est arrêtée, selon une réponse validée publiée il y a plus de deux ans sur le forum officiel, qui oriente vers les Objets Métiers. Sage met par ailleurs en avant ses API et son portail développeurs sur sa page Partenaires technologiques : demandez à votre revendeur si une API couvre votre version et votre offre Sage 100 avant d'en faire la base du projet.

Cinq flux réalistes autour de Sage 100

1. Intervention terminée, facture prête. Le technicien fait signer le bon sur sa tablette ; le service crée le bon de livraison ou la facture dans la gestion commerciale, avec les articles et le temps passé. Voir comment digitaliser les bons d'intervention.
2. Devis accepté en ligne. Le client valide son devis sur votre portail ; le service transforme le document en commande dans Sage 100, sans ressaisie par l'administration des ventes.
3. Catalogue à jour sur la route. Chaque nuit, le service lit articles, tarifs et clients pour alimenter l'application de prise de commande des commerciaux ; les commandes du jour remontent en sens inverse.
4. Recettes d'une activité annexe. Une billetterie ou une caisse de location produit des ventes chaque jour ; le service les passe en écritures dans la base comptable, sur un journal dédié, après contrôle des comptes utilisés.
5. Paiement en ligne sans développement. Selon l'aide en ligne de Sage 100, la gestion commerciale gère déjà Stripe et PayPal : la facture envoyée par e-mail porte un bouton « Paiement », et les règlements s'intègrent depuis la gestion des règlements. Ce flux ne se code pas ; la page Stripe traite les cas plus complexes.

Pour le cabinet comptable, la gestion commerciale exporte aussi la mise à jour comptable au format paramétrable, avec un fichier de transfert par défaut choisi dans les paramètres société.

Les pièges propres à Sage 100

• La montée de version. La base de connaissances Sage associe une version des Objets Métiers à chaque version de Sage 100, de la 1.0 à la 12.0, et ne diffuse plus que le « Redistribuable » depuis la 9.02. Chaque mise à jour de Sage se teste donc d'abord sur le service d'intégration.
• Le serveur qui s'arrête. Un service Windows arrêté bloque les flux : supervision, redémarrage automatique et alerte sont prévus dès le départ.
• Les documents impossibles. Si le besoin touche un type de document que les Objets Métiers ne créent pas, comme un ticket ou une facture comptabilisée, il faut le savoir au cadrage, pas en recette.
• Les doublons. Le service garde la correspondance entre ses identifiants et les numéros de pièces Sage, et vérifie avant de créer : un bon reçu deux fois ne donne pas deux factures. C'est la condition pour éliminer les doubles saisies sans en fabriquer d'autres.
• Les données personnelles. Les fiches tiers contiennent des contacts : seuls les champs utiles circulent, et le flux entre au registre des traitements.

Connecteur du marché, éditeur tiers ou développement ?

Cherchez d'abord sur Sage Marketplace une application qui relie déjà votre outil à Sage : Sage y invite les éditeurs à publier leurs intégrations. L'annonce du forum officiel Sage 100 citée plus haut évoque aussi des API web tierces, construites par d'autres éditeurs au-dessus de Sage 100 : elles évitent d'écrire la couche Windows, mais ajoutent un intermédiaire et un contrat de plus.

Le développement sur mesure se justifie quand le flux porte une règle propre à votre métier (tarif calculé, contrôle de stock particulier), quand plusieurs applications écrivent dans Sage, ou quand vous voulez maîtriser la reprise sur incident. Si l'intégration révèle que Sage 100 ne suit plus l'activité, la question change : voir les alternatives à Sage 100 et le comparatif Sage ou EBP.

Pour Sage 50, le chemin est plus étroit. En 2023, sur la communauté développeurs de Sage, une demande de documentation d'API pour Sage 50 et Sage 100 France a reçu pour seule réponse les contacts du support d'intégration du produit français. Posez donc la question à votre revendeur avant d'imaginer un flux automatique.

Ce que YMHB Web construit et vous remet

YMHB Web développe le service d'intégration et, si le projet le demande, l'application qui s'en sert. Le travail commence par un cadrage avec votre revendeur Sage (version exacte, modules, champs ajoutés) et se poursuit sur une copie de la base, jamais sur la production. Vous recevez ensuite :

• le code source du service, en technologies standard, déposé chez vous et documenté, qui vous appartient au paiement intégral ;
• la liste des objets et processus Sage utilisés, flux par flux, avec le sens de chaque échange ;
• le journal des échanges, les alertes et l'écran des anomalies à trancher à la main ;
• la procédure de test à dérouler à chaque mise à jour de Sage 100.

Le principe de ces liaisons est décrit sur la page connecter ses outils par API.