Sage Operations · SaaS, pilotage et automatisation
Le SaaS déplace la charge technique, il ne supprime pas les questions de gouvernance : qui voit quoi, qui déclenche quoi, et quelles données circulent entre vos applications. Ce sont précisément celles sur lesquelles nous travaillons.
Le socle
La solution est née en SaaS — ce n'est pas un logiciel installé sur un serveur distant, ni la version hébergée d'un produit plus ancien. La différence se voit surtout dans le partage des tâches.
Chez l'éditeur
L'hébergement, l'évolution de la plateforme et les mises à jour de l'application sont pris en charge dans le modèle de service. Vous ne planifiez plus de montée de version, vous ne dimensionnez plus de serveur.
Les engagements d'accès, de disponibilité et de reprise relèvent du contrat : ce sont des éléments à lire, pas à supposer.
Chez vous
Vos accès et vos droits, la qualité de vos données, vos paramétrages, et les tests de vos intégrations. Ce sont les quatre postes qui décident si l'outil est fiable au quotidien — et aucun des quatre ne dépend de l'infrastructure.
C'est la part sur laquelle nous intervenons, et celle qui fait la différence entre deux entreprises équipées du même produit.
Nous ne le mettrions pas en avant si cela n'avait pas de conséquence pratique. Sage Operations est écrit avec les outils courants du logiciel en ligne d'aujourd'hui, et cela se voit à deux endroits : la rapidité avec laquelle le produit évolue, et la facilité avec laquelle on s'y raccorde.
TypeScript
Le langage de programmation, créé par Microsoft
React
La bibliothèque JavaScript qui compose les écrans
GraphQL
Le langage de requêtes des API, créé par Facebook
PostgreSQL
Le système de gestion de base de données
Chromium
Le générateur d'états et de documents, issu de Google
Tableaux de bord
C'est la différence entre un écran qu'on regarde le lundi matin et un écran depuis lequel on travaille.
Les tableaux de bord se composent à partir de widgets standards, ou de widgets personnalisés dont vous choisissez la source de données, les filtres, le tri et la présentation. Un chiffre, une liste et un graphique ne répondent pas à la même question : le premier alerte, la deuxième donne à faire, le troisième explique.
Le point qui change tout, ce sont les liens. Depuis un widget, on consulte l'enregistrement concerné, voire on en crée un. Le tableau de bord cesse d'être un rapport : il devient le point d'entrée dans le travail de la journée.
Automatisation
Le concepteur visuel les assemble. La difficulté n'est jamais l'outil : c'est de décider ce qui mérite d'être automatisé, et ce qui doit rester une décision humaine.
Quand
Un événement
La création ou la modification d'un enregistrement — une commande, une réception, une fiche.
Si
Une condition
Vos critères, écrits explicitement : un montant, un client, un dépôt, un délai. C'est elle qui délimite les cas concernés.
Alors
Une action
Une notification à la bonne personne, l'impression d'un document, ou certaines étapes d'une commande.
Deux choses à remarquer sur cet écran. Les conditions y sont des losanges explicites — « allocation complète ? » — et non une règle enfouie dans un paramètre. Et chaque branche mène à une action nommée : créer l'expédition, ou prévenir le client que sa commande n'est que partiellement allouée. Un workflow lisible par quelqu'un qui ne l'a pas écrit est la seule sorte qui survive au départ de son auteur.
L'option de service Workflow doit être activée, et chaque scénario doit être testé avant d'être mis en service. Ce n'est pas une formalité : un workflow qui se déclenche trop souvent est abandonné en deux semaines, et un workflow qui se déclenche trop rarement n'est jamais détecté comme défaillant.
Nous commençons toujours par une règle, une seule, sur un cas fréquent et sans conséquence si elle se trompe. C'est ce qui donne aux équipes l'envie d'en demander une deuxième.
Intégrations
Les deux moitiés de cette phrase comptent autant l'une que l'autre.
Le produit est entièrement bâti sur ses API. L'interface ne dispose d'aucun accès privilégié : ce qu'un utilisateur fait à l'écran, un traitement automatique peut le faire par le même chemin. C'est une différence de nature avec un logiciel auquel on aurait ajouté des API après coup — là, tout n'est jamais couvert.
De quoi échanger avec le commerce en ligne, l'EDI, les transporteurs ou vos outils métier ; une intégration avec Sage Intacct est également documentée. Mais l'existence d'une API ne signifie pas qu'un connecteur prêt à l'emploi existe pour votre application.
Chaque liaison demande cinq décisions : quelles données circulent, dans quel sens, à quelle fréquence, comment on rapproche les enregistrements des deux côtés, et que fait-on quand un échange échoue. C'est la cinquième qu'on oublie, et c'est celle qui coûte.
Pourquoi cela nous va bien
Faire circuler des données entre un ERP et le reste du système d'information est notre métier quotidien. Nous intégrons près de 500 000 flux EDI par an dans Sage 100, nous écrivons nos propres connecteurs, et nous savons ce qu'un flux mal surveillé coûte le jour où il s'arrête.
Serveur MCP natif
MCP est le standard par lequel une intelligence artificielle se branche sur une application pour l'interroger. Sage Operations dispose d'un serveur MCP natif : il n'y a pas de passerelle à écrire, pas d'export à programmer. Vous connectez Claude ou Mistral, et vous posez la question.
La réponse porte sur vos données réelles, à l'instant où vous la demandez — pas sur une copie de la base de la semaine dernière.
« Quelles commandes clients sont bloquées par une rupture, et sur quelles références ? »
« Quels ordres de fabrication soldés ce trimestre ont dépassé leur coût standard ? »
Les moteurs que nous maîtrisons
Mistral
Claude
CopilotInterroger sa gestion en langage naturel n'est pas réservé à Sage Operations : nous développons un serveur MCP pour Sage 100, et c'est l'un de nos sujets les plus avancés. Quel que soit votre socle, la question se pose de la même manière et la réponse vient de vos données.
Notre serveur MCP pour Sage 100
Une règle de prudence vaut dans tous les cas, et c'est la première chose que nous réglons : l'intelligence artificielle n'a jamais plus de droits que la personne qui l'interroge. Un commercial ne voit pas les marges par cette voie s'il ne les voit pas dans l'application.
Deux sujets à qualifier
Les nouveautés documentées mettent en avant des points d'attention opérationnels : commandes, expéditions ou approvisionnements en retard. L'intérêt est là — aider à repérer ce qui mérite un regard, pas produire une analyse à votre place.
Les assistants réellement disponibles, leur périmètre et leurs conditions d'accès se vérifient dans votre environnement, au moment du projet.
Le sujet se traite sur le périmètre effectivement disponible pour votre dossier : réception, émission, statuts, plateforme agréée et paramétrage. Une feuille de route produit ne dit pas ce qui est livré aujourd'hui.
Notre page facturation électroniqueCe qu'on nous demande
Non. L'éditeur prend en charge le service et ses mises à jour. Restent chez vous les accès, les données, les paramétrages et les tests des intégrations. C'est moins de travail technique, mais ce n'est pas zéro travail — et prétendre le contraire ne rend service à personne.
Non. Ce qui est garanti, c'est l'existence d'API. Une étude confirme ensuite ce qui est réellement échangeable, et ce qu'il faut développer. Nous chiffrons cette étude séparément du projet, parce qu'elle peut en changer le périmètre.
C'est la seule manière raisonnable. Une règle, un cas, une équipe, et on regarde ce qui se passe pendant un mois. Les automatisations livrées en lot le jour du démarrage se désactivent presque toutes dans le trimestre : personne n'a eu le temps de vérifier qu'elles faisaient ce qu'on croyait.
Nous contacter
Les échanges qui vous coûtent le plus de ressaisies, et les tâches répétitives que personne ne devrait plus faire à la main. Identifions-les, et commençons par la première.
