Il n’existe pas une API unique commune à tous les produits Sage. Un projet réussi commence par le nom exact du logiciel, ses modules et son mode d’hébergement. « Sage dans le cloud » ne suffit pas pour choisir une authentification, une ressource ou un format de commande.
Le besoin métier vient ensuite : partager une disponibilité vendable, intégrer une commande, alimenter un portail B2B ou rapprocher des règlements. Ces opérations n’ont ni les mêmes droits ni les mêmes conséquences. Une API de facturation électronique ne remplace pas une interface de gestion des stocks.
Ce guide distingue les principales familles d’accès et propose une méthode de qualification pour les DSI, les responsables commerce, la logistique et la finance. Les scénarios présentés sont des propositions d’architecture, sauf lorsque la référence client est explicitement nommée.
Notre rôle consiste à construire les échanges, les middlewares et les applications métiers autour de l’ERP. L’installation et le paramétrage du logiciel se coordonnent avec le spécialiste Sage du client. Notre offre d’intégration de Sage à votre SI précise cette répartition des responsabilités.
Identifier le produit avant de chercher un endpoint
Demandez une capture de la version, la liste des modules licenciés et l’environnement utilisé : Sage 100 Gestion Commerciale, Comptabilité, Sage X3, Sage Active ou Sage Intacct. Les données nécessaires peuvent être réparties entre plusieurs modules. Le nom d’une gamme commerciale ne constitue pas un contrat d’intégration.
Consignez également les sociétés, les dossiers, les sites et les dépôts concernés. Une commande techniquement valide dans un dossier de test peut être rejetée dans une autre société à cause d’une taxe, d’un article ou d’un client manquant. La recette doit reproduire cette organisation.
Sage 100 et 100c : Objets Métiers ou passerelle REST
Une recherche « API Sage 100 » doit commencer par l’identification de l’accès installé. Sage 100c est bien une appellation historique de Sage 100. Pour le raccordement technique, la documentation française présente les Objets Métiers et distingue les connexions sur site et Sage Partner Cloud. Une passerelle peut exposer une API REST au-dessus de ces mécanismes ; son contrat appartient alors au fournisseur de la passerelle.
La documentation Sage sur les connexions Objets Métiers donne les prérequis de connexion. L’hébergement SPC ne prouve pas, à lui seul, qu’une API REST publique prête à l’emploi couvre tous les objets demandés. Vérifiez l’édition des Objets Métiers, leur installation et les droits avec le partenaire ERP.
Questions à poser au fournisseur REST
Quels objets sont lisibles et modifiables ? Comment sont représentés les dépôts, les pièces et leurs lignes ? Les opérations sont-elles atomiques ? Quels mécanismes permettent de retrouver une commande après un timeout ? Demandez la documentation, une instance de recette et une politique de compatibilité avant de choisir le connecteur.
Un import/export supporté reste une solution possible pour un échange différé. Il faut alors tracer le lot, lire les comptes rendus et traiter les rejets. Écrire directement dans les tables métier ne remplace pas les règles de validation de l’ERP.
Sage X3 : distinguer les générations d’interfaces
Sage X3 documente plusieurs approches : REST et SOAP sur la plateforme, GraphQL dans les outils de développement concernés, ainsi que les imports/exports pour les lots. Le choix dépend des ressources publiées et de l’environnement, et non d’une préférence abstraite pour REST.
Le guide API X3 et le parcours de choix des intégrations X3 constituent les points de départ. Confirmez les services, représentations, habilitations et mécanismes de session effectivement activés. Une liste d’articles consultable ne garantit pas l’écriture d’un document commercial complet.
Pour un distributeur multisite, qualifiez la société, le site de vente, le site d’expédition et le dépôt au niveau de la commande. L’offre d’intégration SI Sage X3 traite ce périmètre spécifique ; la référence NetMinds décrite plus bas concerne Sage 100c.
Sage Active : une API GraphQL documentée
Sage Active dispose d’une API publique GraphQL. Le portail développeur Sage Active décrit les ressources et le parcours d’accès. Il faut utiliser le contrat correspondant au produit et au pays concernés, puis qualifier l’organisation et les autorisations de l’application.
Une façade REST construite par un tiers peut faciliter une intégration, mais elle ne transforme pas l’API native en REST. Pour un portail ou un outil financier, vérifiez d’abord les requêtes et mutations disponibles, les erreurs GraphQL et la portée des droits. Un code HTTP réussi ne suffit pas pour conclure que la mutation métier a été acceptée.
Sage Intacct : REST et interface XML à distinguer
Sage Intacct propose une API REST et conserve une documentation XML pour les intégrations existantes. Le portail développeur Intacct permet d’identifier ces deux familles. Les clés, permissions et ressources doivent être vérifiées dans l’environnement de l’entreprise.
Pour la finance multi-entités, l’enjeu consiste notamment à préserver la société, la dimension analytique et la période de chaque écriture. Une compétence sur Sage 100c ne constitue pas une référence client Intacct : nous qualifions les accès et construisons une démonstration adaptée avant de confirmer le périmètre.
API de plateforme agréée : un autre périmètre métier
Sage présente aussi une API de plateforme agréée pour la facturation électronique. Cette interface répond à des besoins d’échange de factures et de statuts. Elle ne doit pas être présentée comme un accès général aux stocks, aux achats ou aux commandes de tous les ERP Sage.
Dans une architecture complète, l’ERP produit les documents commerciaux, le service de facturation gère le circuit documentaire correspondant et le middleware conserve les liens entre identifiants. Le contenu des factures et les obligations applicables doivent être validés avec les responsables finance et leur prestataire spécialisé.
Passer du besoin à un contrat d’échange
Pour chaque opération, écrivez le système maître, l’identifiant stable, les données requises et la preuve de traitement. « Synchroniser les clients » est trop vague : créer un tiers depuis le CRM, actualiser son adresse et modifier ses conditions de paiement sont trois décisions différentes.
L’authentification doit suivre l’interface retenue. Un compte utilisateur, un mécanisme OAuth et une clé de fournisseur n’ont pas la même portée. Séparez les secrets par environnement et évitez de transmettre les habilitations administrateur à une application qui ne lit que les articles.
Lecture et écriture ne se valident pas ensemble
Commencez par une lecture limitée sur un dossier de recette. Testez ensuite un document représentatif, avec ses lignes, taxes, remises et références. Vérifiez le résultat dans Sage avec le métier. Conservez l’identifiant retourné avant d’autoriser toute tentative de reprise.
Après un timeout, recherchez l’opération par une référence externe ou un mécanisme de rapprochement validé. Si aucune recherche fiable n’est possible, placez la commande en contrôle manuel. Réessayer aveuglément une création peut produire un doublon même si le premier appel semblait avoir échoué.
Choisir un premier flux selon le secteur
Dans la distribution multicanale, le premier lot peut relier les commandes et la disponibilité aux boutiques et marketplaces. Dans une activité B2B, il peut porter sur un portail qui affiche les tarifs autorisés et transmet les commandes pour validation. Pour une société de services, la priorité peut être le rapprochement des clients, projets et pièces financières.
Ces scénarios exigent une validation des ressources accessibles. Le panorama des cas d’usage Sage aide à comparer les besoins ; les guides e-commerce et reporting détaillent des choix propres à chaque flux.
Un produit existant peut devenir préférable au développement sur mesure si le besoin est récurrent et correctement couvert. Ciama peut être étudié dans ce cadre, après vérification de l’adéquation fonctionnelle et de la compatibilité technique ; ce guide ne promet pas un connecteur Sage natif déjà disponible.
NetMinds pour Pixminds : une référence Sage 100c
Avant Ciama, nous avons développé NetMinds, une application interne sur mesure pour Pixminds. Le projet associait Sage 100c, des échanges API marketplace et des fonctions de pilotage multicanal. Un partenaire technique exposait une API REST sur l’ERP ; Dawap construisait les échanges et l’application métier.
La architecture API de NetMinds pour Pixminds explique le rôle de cette passerelle et les intégrations historiques Amazon MWS et Fnac. Le récit distingue les fonctions attestées des traitements exploratoires. Il illustre une organisation de projet avec la DSI, les équipes commerciales et la logistique, sans attribuer à Sage une API REST native universelle.
Préparer un atelier qui débouche sur une décision
Réunissez la DSI, le partenaire ERP et un responsable du flux métier. Apportez une commande réelle anonymisée, un échec déjà rencontré et la version du logiciel. L’atelier doit produire une liste de prérequis, un flux pilote et un partage des responsabilités. Notre accompagnement Sage permet de formaliser cette décision avec vos équipes.
Lancez le pilote lorsque la lecture, l’écriture et le rapprochement sont démontrés en recette. Différez une synchronisation bidirectionnelle si personne n’arbitre les conflits. Refusez une promesse de compatibilité fondée uniquement sur le mot « cloud » ou sur un nom de gamme.
Le coût complet inclut la passerelle éventuelle, les licences, les environnements, la supervision et la maintenance après évolution ERP. Ces postes doivent être visibles dans le devis. Un contrat fournisseur moins coûteux peut devenir plus cher si chaque incident exige une recherche manuelle dans plusieurs systèmes.
Conclusion : Choisir une interface adaptée au produit
Le premier choix Sage est celui du produit et des ressources réellement accessibles. Les mêmes mots commerciaux peuvent recouvrir des architectures et des droits différents.
La réussite se mesure sur les documents et les décisions métier : commande unique, disponibilité compréhensible, pièce rapprochable et reprise maîtrisée. Le protocole ne suffit pas à établir ces garanties.
Une passerelle REST et une application sur mesure peuvent constituer une architecture pertinente, comme dans NetMinds, à condition que leurs responsabilités et leurs limites soient explicites. Le cadrage d’une intégration Sage vérifie cette organisation sur votre environnement.
Dawap accompagne le cadrage, les échanges et les outils métiers grâce à son expertise en intégration API. Nous commençons par un flux démontrable et un périmètre de maintenance défini avec vos équipes.
