Salesforce
Connecter Sage X3 et Salesforce sans connecteur payant : la passerelle par fichiers plats
par Paul Mantez, Co-fondateur & Développeur
La situation est classique dans le négoce et l'industrie : toute la vie de l'entreprise est dans l'ERP, et les commerciaux travaillent dans un CRM qui n'en sait rien. Ils vendent sans connaître le stock, recopient les tarifs, ne voient pas les commandes passées par leurs clients. Quand l'ERP est Sage X3 et le CRM Salesforce, la première réponse qu'on trouve est un connecteur du marché, facturé à l'abonnement, avec son propre paramétrage et sa propre feuille de route.
Il y a une autre voie, plus sobre, qu'on a construite pour Deffrennes, grossiste en emballages depuis 1845, installé à Fretin près de Lille : une passerelle qui part des exports de Sage X3 et alimente Salesforce chaque nuit. Cet article détaille comment elle est faite, ce qu'elle coûte à maintenir, et dans quels cas elle ne suffit pas.
Pourquoi ne pas forcer l'API de Sage X3
Sage X3 expose des web services. Mais les mettre en œuvre demande un paramétrage côté ERP, souvent l'intervention du prestataire Sage, des comptes techniques, une exposition réseau à sécuriser. Pour une synchronisation qui n'a besoin d'être que quotidienne, c'est disproportionné.
Ce que Sage X3 fait très bien, en standard, et que l'administrateur de l'ERP maîtrise déjà, ce sont les exports planifiés : une requête sur une table, un format de fichier, une heure d'exécution, un dossier de dépôt. Rien à développer côté Sage, rien à ouvrir sur le réseau, et une fonction que le client sait faire évoluer seul.
C'est le principe qu'on retient à chaque intégration d'ERP : partir de ce que l'outil sait produire, et mettre l'intelligence dans la passerelle, à côté, là où on la maîtrise. Le même choix vaut pour d'autres ERP : on l'a retenu avec Infor sur une migration vers Salesforce dans l'industrie.
Ce qui sort de Sage chaque nuit
Quatre fichiers, un par famille de données, produits par Sage X3 à heure fixe et déposés sur un SFTP ainsi que dans un dossier du serveur Sage :
| Fichier | Contenu | Ce que Salesforce en fait |
|---|---|---|
| Articles | Référence, désignation, dimensions, matière, colisage, gamme, page catalogue, alimentarité | Le catalogue produit visible par les commerciaux |
| Stocks et tarifs | Quantité disponible, prix de base, prix remisable | Disponibilité et tarif à jour sur chaque fiche |
| En-têtes de commandes | Numéro Sage, client, date, montant | Le chiffre d'affaires par compte |
| Lignes de commandes | Article, quantité, prix | Ce que chaque client achète, quantités vendues N et N-1 |
La passerelle ne prend jamais « le fichier de la nuit » par son nom : elle récupère le plus récent de chaque famille. Si un export a échoué ou a été relancé à la main, elle travaille sur ce qui existe vraiment, et le journal le dit.
Tolérer les fichiers tels qu'ils sortent
C'est la partie que les tutoriels passent sous silence. Un export Sage X3 n'est pas un CSV propre. Selon la table et le poste, l'encodage change. Des guillemets s'ouvrent sans se fermer. Les désignations longues se retrouvent éclatées sur plusieurs colonnes. Demander à l'ERP de « sortir propre » revient à ouvrir un chantier côté Sage, exactement ce qu'on voulait éviter.
La passerelle absorbe donc. Détection de l'encodage fichier par fichier. Parsing tolérant : un guillemet orphelin ne fait pas échouer la ligne, il est neutralisé. Recollage des descriptions : les colonnes excédentaires sont réassemblées dans le champ de désignation avant le mapping. Puis le mapping proprement dit, vers une quarantaine de champs Salesforce : références, colisage, dimensions, gamme, page catalogue, prix remisable, quantités vendues.
Une ligne qui ne passe malgré tout n'est pas ignorée : elle est journalisée avec sa raison. C'est ce journal que l'on regarde le lundi matin, pas les fiches produit une par une.
Pousser dans Salesforce sans jamais créer de doublon
Chaque enregistrement est envoyé à l'API REST de Salesforce en upsert sur une clé externe : la référence article pour le catalogue, l'identifiant Sage de la commande pour les commandes. Salesforce cherche l'enregistrement par cette clé, le met à jour s'il existe, le crée sinon.
Les envois se font par lots de cent, ce qui limite le nombre d'appels et reste sous les quotas d'API de l'org. Chaque lot est journalisé : combien de créés, combien de mis à jour, combien d'erreurs et lesquelles.
La conséquence pratique, c'est qu'on peut rejouer un fichier autant de fois qu'on veut. Un export corrigé à la main, une nuit où le script n'a pas tourné, une reprise complète après un nettoyage du catalogue : on relance, et le résultat est identique. Cette propriété, l'idempotence, est ce qui rend une intégration tenable dans la durée. C'est la même qu'on exige d'une migration de CRM : l'import doit être ennuyeux à rejouer.
Où ça tourne et ce que ça coûte à maintenir
Le script tourne en tâche planifiée sur le serveur du client, en Node.js. Pas de plateforme intermédiaire, pas d'abonnement, pas de données qui transitent chez un tiers. Ce qu'il faut pour le faire vivre : un accès au SFTP, une clé d'API Salesforce sur un utilisateur d'intégration, et quelqu'un qui lit le journal.
Ce qui bouge dans le temps, c'est le mapping : Sage ajoute une colonne, Salesforce gagne un champ, une gamme change de nom. Ce sont des modifications de quelques lignes, faites dans la passerelle, sans toucher ni à l'ERP ni à l'org. Depuis la mise en production en novembre 2024, c'est le seul type d'intervention qu'il y a eu.
Et le modèle s'est révélé réutilisable : le même schéma, exports planifiés, dépôt SFTP, upsert par clé externe, sert à Decathlon Arena dans l'autre sens, pour exporter chaque jour les contacts de Salesforce vers un outil d'e-mailing.
Quand cette approche ne suffit pas
Trois situations demandent autre chose.
Le temps réel. Si un commercial doit voir un stock à la minute, parce qu'il est très tendu ou que plusieurs canaux vendent le même lot, une synchronisation nocturne ne suffit pas. On peut densifier les exports (un à midi, un le soir) sans rien changer à la passerelle, mais au-delà il faut un web service Sage.
L'écriture dans l'ERP. Envoyer une commande de Salesforce vers Sage X3 est un flux d'une autre nature : il écrit dans l'outil de gestion, avec ses contrôles (client existant, article actif, tarif valide, encours). Ça se fait, par un import Sage planifié depuis un fichier produit par Salesforce ou par web service, mais on le traite comme un second projet, une fois le flux de lecture digéré par les équipes.
Les volumes très élevés. Au-delà de quelques centaines de milliers de lignes par nuit, l'API REST par lots de cent montre ses limites ; on passe alors à l'API Bulk de Salesforce, ce qui reste dans la même architecture.
Dans tous les autres cas, catalogue, tarifs, stocks, commandes, pour un négoce ou un industriel qui veut que ses commerciaux vendent avec les bonnes informations, la passerelle par fichiers plats fait le travail, et elle le fait sans abonnement.
Questions fréquentes
Peut-on connecter Sage X3 et Salesforce sans acheter un connecteur ?
Oui. Sage X3 sait produire des exports planifiés de ses tables (articles, tarifs, stocks, commandes) et Salesforce expose une API REST qui accepte des mises à jour en masse. Entre les deux, un script qui lit les fichiers, les transforme et les envoie en upsert suffit pour une synchronisation quotidienne. C'est ce qu'on fait tourner chez un grossiste depuis fin 2024.
Pourquoi passer par des fichiers plats plutôt que par l'API de Sage X3 ?
Parce que les web services de Sage X3 demandent un paramétrage côté ERP, souvent un prestataire Sage, et que leur mise en place coûte plus que ce qu'ils apportent quand une synchronisation quotidienne suffit. Les exports planifiés sont une fonction standard, maîtrisée par l'administrateur Sage, et ils n'exposent rien de l'ERP sur le réseau.
Comment éviter les doublons quand on rejoue un fichier ?
Par un upsert sur une clé externe : la référence article pour le catalogue, l'identifiant Sage de la commande pour les commandes. Salesforce met à jour l'enregistrement s'il existe, le crée sinon. On peut relancer le même fichier dix fois, le résultat est identique.
Que faire des fichiers Sage mal formés : encodage, guillemets, descriptions sur plusieurs colonnes ?
On ne demande pas à Sage de les corriger, on les tolère. La passerelle détecte l'encodage de chaque fichier, accepte les guillemets orphelins et recolle les descriptions éclatées sur plusieurs colonnes avant le mapping. Chaque ligne rejetée est journalisée avec sa raison, jamais perdue en silence.
Quelle fréquence de synchronisation entre Sage X3 et Salesforce ?
Chaque nuit dans la plupart des cas : les commerciaux voient le stock et les tarifs de la veille au soir, ce qui suffit pour vendre. Si un besoin d'intra-journée apparaît (stock très tendu, tarifs promotionnels), on peut planifier un export supplémentaire à midi sans rien changer à la passerelle.
Et dans l'autre sens, envoyer les commandes de Salesforce vers Sage X3 ?
C'est un flux différent, en écriture dans l'ERP, qui demande soit un import Sage planifié depuis un fichier produit par Salesforce, soit un web service Sage. On le traite comme un second projet, avec ses contrôles (client existant, article actif, tarif valide), une fois que le flux de lecture est en place et digéré par les équipes.
Un ERP qui sait tout, un CRM qui ne sait rien : le problème ne se règle pas en achetant un connecteur, il se règle en décidant ce qui doit circuler, à quelle fréquence, et en construisant la passerelle la plus simple qui tient cette promesse dans le temps.
Votre catalogue et vos commandes sont dans Sage et vos commerciaux dans Salesforce ? On construit la passerelle, sans abonnement →