Connecter une application métier à Sage 100c : les deux approches

Toute entreprise qui exploite Sage 100c finit par se poser la même question : comment brancher dessus une application qui fera ce que Sage ne fait pas — une prise de commande mobile, un portail client, un outil de recouvrement, un assistant d’analyse.

Il existe deux façons de le faire. Elles ne s’opposent pas : bien conçue, une intégration utilise les deux, chacune pour ce qu’elle sait faire.

Approche 1 — l’accès direct à la base

Sage 100c stocke ses données dans SQL Server. Une application peut s’y connecter et lire directement les tables.

Ce que ça permet. La lecture, et elle est excellente. Vous accédez à l’intégralité du modèle de données, sans limite de volume et sans intermédiaire. Une synthèse client sur trois ans d’historique se construit en une requête.

Ce que ça interdit. L’écriture. Ou plus exactement : techniquement rien ne l’interdit, et c’est précisément le problème.

Le modèle de données de Sage porte des règles de gestion qui ne sont pas toutes inscrites dans le schéma de la base. Des compteurs, des cohérences entre en-tête et lignes, des reports analytiques, des chaînages de documents. Une écriture directe qui ignore l’une de ces règles produit une base cohérente du point de vue de SQL Server et incohérente du point de vue de Sage. Le symptôme apparaît des semaines plus tard, souvent à la clôture.

La règle à retenir : on lit directement, on n’écrit jamais directement.

Approche 2 — le web-service dédié

La seconde approche consiste à passer par un service qui parle à Sage à travers ses propres composants, et non à travers sa base.

Ce que ça permet. L’écriture, en respectant les règles de gestion de Sage. Le document créé par ce chemin est identique à un document saisi dans l’interface Sage : mêmes contrôles, mêmes compteurs, mêmes reports.

Ce que ça coûte. Une brique supplémentaire à installer et à maintenir, et des performances moindres en lecture de masse. Ce n’est pas le bon outil pour ressortir trois ans d’historique.

Pourquoi les deux plutôt qu’une

La répartition qui fonctionne en production est simple :

Opération	Canal
Consultation, recherche, états, tableaux de bord	Accès direct à la base
Création et modification de documents, écritures comptables	Web-service

C’est l’architecture que nous utilisons dans OptiFlowPro. La lecture passe par un accès direct, ce qui rend les écrans instantanés même sur des bases volumineuses. Toute écriture passe par le web-service, ce qui garantit qu’un document créé depuis un téléphone en tournée est un document Sage à part entière.

Trois points à vérifier avant de se lancer

La version de Sage. Les composants disponibles et le modèle de données varient d’une version à l’autre. Ce qui fonctionne sur une installation ne fonctionne pas nécessairement sur une autre.

Les personnalisations. Champs libres, scripts, développements spécifiques : ils font partie du modèle de données réel et une intégration qui les ignore les casse.

Le multi-société. Une installation à plusieurs sociétés, c’est plusieurs bases. Toute requête doit être qualifiée par la société concernée, sans exception. Une requête non qualifiée finit par lire ou écrire dans la mauvaise base — et ce type d’erreur est très coûteux à détecter.

En résumé

Lire directement, écrire par le service. C’est la seule répartition qui donne à la fois des écrans rapides et des données sur lesquelles votre comptabilité peut s’appuyer.

Si vous envisagez une intégration sur votre installation, l’audit préalable sert exactement à répondre à ces trois questions avant d’écrire la première ligne de code.