Un SDK facilite l’usage d’une interface ; il ne détermine pas ce que le produit Sage autorise. Avant de choisir une bibliothèque PHP, identifiez le mécanisme d’accès à l’ERP et les dépendances nécessaires sur son environnement.
Pour Sage 100, un service compatible avec les Objets Métiers ou une passerelle REST partenaire peut servir d’intermédiaire. Pour X3, Active et Intacct, les interfaces et leurs modalités d’accès sont différentes. Le backend web ne doit pas masquer ces différences derrière une promesse universelle.
Nous proposons ici une séparation entre le contrat de l’application, l’adaptateur d’intégration et les ressources du fournisseur. Les exemples sont pédagogiques, non exécutés contre un ERP et indépendants du partenaire historique Pixminds.
Cette architecture fait partie de notre offre d’intégration de Sage à votre SI. Elle se prépare avec la DSI et le partenaire ERP, qui valident les composants, les habilitations et les règles du dossier. La fabrication de cet adaptateur relève de notre prestation d’intégration API et middleware.
Distinguer trois responsabilités techniques
Le SDK est une bibliothèque qui aide un programme à dialoguer avec une interface. La passerelle expose des opérations accessibles à distance. L’adaptateur traduit les besoins de votre application vers cette interface, avec vos correspondances et vos règles de reprise.
Ces rôles peuvent être portés par plusieurs logiciels et fournisseurs. Vérifiez qui maintient chacun d’eux, qui certifie la version Sage et qui intervient si une commande est reçue mais jamais créée. Une bibliothèque open source ne constitue pas un engagement de support ERP.
Choisir où exécuter la dépendance ERP
Ne supposez pas qu’un composant Sage 100 peut fonctionner directement dans le conteneur Linux du backend Symfony. Les Objets Métiers et leurs prérequis doivent être examinés dans l’environnement compatible. Un service intermédiaire peut isoler cette dépendance et communiquer avec le backend selon un contrat restreint.
Une passerelle REST existante peut éviter de développer ce service. Il reste à qualifier ses ressources, sa stabilité et ses garanties. Le guide Sage 100 explique les choix d’accès ; le comparatif des interfaces Sage évite de transposer cette architecture à tous les produits.
Définir un port métier indépendant du transport
Le backend demande une création de commande et reçoit un résultat explicite. L’interface PHP ci-dessous représente votre code applicatif. Les types utilisés sont des classes à définir dans le projet ; ce fragment n’est pas un SDK officiel Sage et ne fournit aucun endpoint.
interface SalesOrderGateway
{
public function create(SalesOrderCommand $command): CreationResult;
public function findByExternalReference(string $reference): LookupResult;
}Une implémentation appelle la passerelle retenue. Une autre peut servir de doublure pour les tests. La recherche par référence externe doit être confirmée chez le fournisseur : si elle n’existe pas, votre conception doit prévoir un rapprochement alternatif ou un contrôle humain.
Modéliser les résultats sans transformer l’incertitude en succès
Une création peut être confirmée, refusée pour une raison métier ou rester incertaine après rupture réseau. Ces trois situations doivent produire des décisions différentes. « HTTP 200 » peut désigner une réception dans une file et non une pièce validée.
Stockez l’identifiant source, la société cible, la version des correspondances, l’identifiant fournisseur et le résultat confirmé. Ne déduisez pas qu’un code 409 signifie « commande déjà créée » : cette signification dépend du contrat de l’interface.
Éprouver le contrat avec des doublures puis en recette Sage
Les tests locaux peuvent simuler une réception, un rejet de tiers, un timeout avant création et un timeout après création. Ils vérifient vos décisions, pas la compatibilité ERP. Ils doivent démontrer qu’un résultat incertain déclenche une recherche ou un blocage plutôt qu’une nouvelle création aveugle.
La recette Sage vient ensuite avec un dossier et des droits dédiés. Comparez la pièce, les lignes et les montants dans l’ERP. La démonstration doit être rejouée après une évolution sensible de la passerelle ou des correspondances.
Livrer un contrat de maintenance utilisable
La DSI doit pouvoir retrouver une opération et son état sans reconstruire un historique dans plusieurs fichiers. Affichez les références métier et un motif de correction compréhensible. Réservez les traces détaillées aux personnes autorisées et évitez de journaliser les secrets ou les données client inutiles.
Précisez les versions supportées, les prérequis, les contrôles avant mise à jour et le responsable de chaque couche. Une procédure de retour peut suspendre les nouveaux messages et conserver les opérations en attente ; elle ne doit pas prétendre annuler automatiquement des pièces déjà validées.
Ce que NetMinds démontre, et ce que l’exemple propose
NetMinds pour Pixminds reposait sur une API REST partenaire sur Sage 100c et une application métier sur mesure. La architecture API de NetMinds pour Pixminds illustre la répartition entre interface ERP et orchestration des échanges.
L’interface PHP présentée ici est une proposition contemporaine d’organisation du code. Elle ne reproduit ni les endpoints historiques ni le SDK du partenaire. Cette distinction permet de transmettre une méthode utile tout en respectant la réalité du projet.
Conclusion : Un adaptateur maintenable commence par des limites explicites
La bibliothèque cliente ne remplace ni les droits ERP ni les garanties de la passerelle. Le mécanisme réellement disponible détermine l’architecture.
Séparer le port métier de son implémentation permet de tester la décision applicative avant de disposer d’une instance Sage. Ces tests doivent ensuite être complétés par une recette sur le produit concerné.
La maintenance exige des propriétaires pour les composants, les correspondances et les incidents. Un document incertain doit rester visible jusqu’à son rapprochement.
Dawap conçoit ces adaptateurs et les applications qui les utilisent dans son offre d’intégration API. Le premier livrable est un contrat vérifiable, accompagné de ses scénarios d’échec.
