SAGE 100 n'a pas d'API : voilà comment je connecte Dynamics 365 quand même

6 juin

"SAGE 100 a-t-il une API ?"

La question revient souvent.

La réponse est non.

Et c'est exactement là que commencent tous les projets qui partent mal en intégration CRM-ERP.

Tu veux brancher Dynamics 365 sur SAGE 100. Tu fais ta recherche. Tu tombes sur des connecteurs anglo-saxons qui parlent d'autres produits Sage sans rapport. Tu trouves des forums qui mentionnent les "Objets Métiers" en C#. Tu ouvres un onglet StackOverflow, tu reviens deux heures plus tard, tu n'as toujours pas avancé.

Je l'ai fait plusieurs fois. Voilà comment ça marche vraiment.

Le constat technique : SAGE 100 n'a pas d'API

Premier point à clarifier. SAGE 100, l'ERP édité par Sage pour les PME françaises, n'expose aucune API REST native.

Pas un endpoint. Pas un Swagger. Pas un OAuth2. Rien.

Tu peux chercher dans la doc Sage, dans Community Hub, dans les forums partenaires : la conclusion est unanime. L'API REST que tout le monde attend depuis dix ans n'existe pas.

Ce que SAGE propose à la place : une bibliothèque .NET appelée "Objets Métiers" (OM). C'est une couche d'accès aux données encapsulée en C# qui s'installe en local sur la machine où tourne SAGE 100.

Pour intégrer quoi que ce soit avec SAGE 100, tu vas devoir parler à ces Objets Métiers.

Les Objets Métiers : la vraie porte d'entrée SAGE 100

Les Objets Métiers, c'est quoi exactement ?

Une DLL .NET fournie par Sage. Tu l'installes avec SAGE 100, tu y accèdes en C# (ou en VBA, ou via COM depuis un autre langage).

Ce qu'ils permettent de faire

Lire les tiers, articles, dépôts, taux de TVA, modes de règlement, tarifs, devis, commandes, factures
Créer un tiers, un devis, une commande, une facture
Appliquer les règles métier Sage (calcul de taxes, contrôles de cohérence, mise à jour des stocks)
Garantir l'intégrité de la base (ce que ne fait pas une écriture SQL directe)

Ce qu'ils ne permettent pas de faire

Être appelés directement depuis le cloud (ils tournent en local sur Windows)
Être interrogés via HTTP/REST nativement (c'est du .NET en process)
Être utilisés depuis un OS autre que Windows ou un environnement non .NET

C'est précisément pour ça que Sage les a faits comme ça. Les OM appliquent les règles métier propres à SAGE 100. Tu écris une commande via OM, t'es sûr qu'elle est cohérente avec le reste du système. Tu écris en SQL direct, tu peux casser ta base sans le savoir.

Les Objets Métiers sont la voie officielle Sage.

Deux options pour connecter Dynamics 365

Pour faire dialoguer Dynamics 365 (cloud Microsoft) avec SAGE 100 (on-premise), deux méthodes dominent.

Je les ai mis en place dans des projets réels. Ils répondent à des besoins différents.

Méthode 1

Lecture directe de la base SQL on-premise

L'idée est simple. SAGE 100 stocke ses données dans une base SQL Server, dans la grande majorité des cas hébergée chez le client (on-premise).

Tu accèdes directement à cette base ou tu mets en place une copie ou un miroir de cette base dans Azure SQL via Azure Data Factory ou autre chose. Dynamics 365 consomme ensuite les données en lecture depuis Azure SQL via Power BI, Power Automate ou un custom connector.

Avantages :

Mise en place plus rapide qu'un connecteur API
Pas d'agent applicatif à maintenir (juste un job de copie/réplication)
Compatible avec tous les outils du stack Microsoft (Power BI surtout)

Limites :

Lecture seule. Tu ne peux pas écrire dans SAGE comme ça (à moins de casser ta base)
Tu lis au format technique Sage (tables, jointures complexes), pas au format métier
Aucune règle métier Sage n'est appliquée à la lecture
Tu prends le risque de casser à chaque montée de version Sage si le schéma change

Quand l'utiliser : tes besoins sont en lecture seule. Tu veux afficher des encours, des historiques de factures, des stocks dans Dynamics 365 ou dans un Power BI. Tu ne crées pas de devis ni de commandes depuis Dynamics.

Méthode 2

Connecteur API REST maison sur les Objets Métiers

L'idée est plus exigeante mais beaucoup plus puissante. Tu développes (ou tu achètes) une couche middleware qui :

Tourne sur le serveur SAGE 100 (ou y accède via réseau interne)
Charge les Objets Métiers Sage en C#
Expose des endpoints REST modernes à partir de ces OM
Authentifie les appels (token, OAuth2, etc.)
Est exposée à Dynamics 365 via Azure (Application Gateway, API Management, tunnel sécurisé)

Dynamics 365 dialogue alors avec SAGE 100 comme avec n'importe quelle API REST classique. Un appel GET /tiers/{code}, un POST /devis, etc.

Avantages :

Lecture ET écriture (créer un tiers, un devis, une commande depuis Dynamics)
Les règles métier Sage sont respectées par construction (on passe par les OM)
Survit aux montées de version Sage (seul l'agent est à mettre à jour, le contrat d'API reste stable)
Périmètre extensible : un nouvel endpoint = un nouveau flux

Limites :

Développement initial plus long que la lecture directe
Maintenance d'un agent local sur le serveur Sage
Sécurité réseau à designer correctement (le tunnel cloud vers on-premise doit être propre)

Quand l'utiliser : tu veux écrire dans SAGE depuis Dynamics 365. Créer un devis depuis une opportunité. Créer une commande depuis une application Power Apps de prise de commande terrain. Mettre à jour un tiers Sage depuis un formulaire Dynamics.

Comparatif synthétique

Critère	Pattern 1 : Lecture directe DB	Pattern 2 : API REST maison
Lecture des données Sage	Oui	Oui
Écriture dans Sage	Non (déconseillé)	Oui
Règles métier Sage appliquées	Non	Oui
Effort de mise en place	Faible à moyen	Moyen à élevé
Maintenance MAJ Sage	Risque élevé	Maîtrisé
Évolutivité du périmètre	Limitée	Forte

Mon avis et ce qu'on fait chez PARTNR.365

Mon parti pris sur les projets PME et ETI : tôt ou tard, l'utilisateur de Dynamics 365 veut écrire dans Sage. Créer un devis. Mettre à jour un contact. Générer une commande depuis une application terrain.

Si tu pars sur la Méthode 1 et que tes besoins évoluent en cours de projet vers de l'écriture, tu reviens à la case départ du projet. Et là c'est plus du tout le même chantier. Tu n'as pas itéré, tu as rebâti.

Donc on réfléchit ensemble à vos processus. Ce que vous souhaitez accomplir à 6, 12 et 18 mois.

Pour cette méthode je travaille en partenariat avec Univers Software

Univers Software est un intégrateur SAGE 100 qui édite ce type de connecteur API REST sur les Objets Métiers. Ils s'occupent du côté Sage (l'agent, l'exposition des OM en REST, la maintenance des montées de version). Je m'occupe du côté Dynamics 365, du middleware Azure et de l'architecture globale.

C'est la combinaison qui marche pour les PME :

Une expertise SAGE 100 côté Univers Software, qui maîtrise les Objets Métiers depuis des années
Une expertise Dynamics 365 côté PARTNR.365, qui sait designer les flux, les model-driven apps et les automatisations

💡 Cette combinaison "intégrateur Sage + intégrateur Dynamics" est rare en France. La plupart des intégrateurs Sage ne maîtrisent pas Dynamics 365. La plupart des intégrateurs Dynamics 365 ne connaissent rien à SAGE 100.

Pour voir cela en production, j'ai mis en place une application de prise de commande digitalisée pour le grossiste Ondyna, qui passait de l'email vers SAGE 100 sans ressaisie : étude de cas Ondyna.

Pour la méthodologie projet complète, les flux courants et les approches, voir notre page service : Intégration Dynamics 365 et SAGE 100.

Ce qu'il faut retenir

SAGE 100 n'a pas d'API REST native. Les Objets Métiers sont la voie officielle.
Pour intégrer Dynamics 365 : Pattern 1 (lecture directe DB, lecture seule, simple) ou Pattern 2 (connecteur API REST sur les OM, lecture et écriture, plus exigeant).
Le bon choix dépend de tes flux. Si tu veux écrire dans SAGE depuis Dynamics, la lecture directe ne suffira pas.
Dans la majorité des projets PME et ETI, je propose le Pattern 2 d'entrée pour ne pas refaire le projet 18 mois plus tard.

FAQ - SAGE 100 et intégration Dynamics 365

SAGE 100 a-t-il une API REST native ?

Non. SAGE 100, l'ERP édité par Sage pour les PME françaises, n'expose aucune API REST native. La voie d'intégration officielle passe par les Objets Métiers, une bibliothèque .NET fournie par Sage qui s'installe en local sur la machine SAGE et qui s'appelle en C# ou via COM.

Qu'est-ce que les Objets Métiers SAGE 100 ?

Les Objets Métiers (OM) sont une bibliothèque .NET fournie par Sage qui encapsule les règles métier de SAGE 100. Ils permettent de lire et écrire dans SAGE (tiers, articles, devis, commandes, factures) en respectant la cohérence des données. Ils s'utilisent en C# ou via COM, en local sur la machine SAGE 100.

Peut-on lire la base SQL de SAGE 100 directement depuis Azure ou Dynamics 365 ?

Techniquement oui, en mode lecture seule via une copie ou un miroir vers Azure SQL (Data Factory, Synapse Link, agent custom). L'écriture directe en SQL est fortement déconseillée car elle contourne les règles métier Sage et peut corrompre la base. C'est le Pattern 1 décrit dans cet article.

Comment écrire dans SAGE 100 depuis Dynamics 365 ?

Via un connecteur API REST maison qui charge les Objets Métiers Sage et expose des endpoints REST modernes. Ce connecteur s'installe sur le serveur SAGE 100 et est exposé à Dynamics 365 via Azure (API Management, Application Gateway, tunnel sécurisé). C'est le Pattern 2 décrit dans cet article.

Faut-il un agent local pour intégrer SAGE 100 ?

Oui dans tous les cas. SAGE 100 tournant en local (on-premise ou sur Sage Partner Cloud), un agent installé sur le serveur Sage est nécessaire pour faire le pont entre les Objets Métiers (qui sont en local Windows) et le cloud Microsoft où vit Dynamics 365.

Tu as un projet Dynamics 365 et SAGE 100 ?

Je t'explique en 30 minutes quel pattern correspond à tes besoins, comment on construit l'archi, et ce que ça coûte. Sans engagement, sans devis bidon.

Voir le service intégration Dynamics 365 et SAGE 100 →

Frédérick Grobost