Comment les modules d'un ERP s'intègrent réellement

Le mot « intégré » recouvre trois réalités différentes

Presque toutes les brochures d'ERP emploient le mot « intégré ». Derrière lui se cachent au moins trois dispositifs qui se comportent très différemment lorsque quelque chose tourne mal à la clôture mensuelle. Le premier est le transfert de fichiers ou par lots planifiés : un système exporte, un autre importe, en général pendant la nuit. Le deuxième est la synchronisation par API ou par middleware, où deux bases de données distinctes restent alignées en échangeant des messages. Le troisième est le partage réel des données, où les modules ne sont pas du tout des systèmes séparés mais des vues différentes sur un même ensemble de tables, un seul grand livre et un seul jeu de données de référence.

Aucun n'est universellement le bon. Le transfert par lots est peu coûteux, facile à comprendre, et résiste à une panne de l'un ou l'autre côté, puisque le fichier attend tout simplement. Il est aussi, par construction, toujours en retard, et un traitement en échec peut passer inaperçu jusqu'à ce que quelqu'un s'interroge sur un état. La synchronisation par API offre un comportement quasi temps réel et permet de conserver des systèmes que l'on a de bonnes raisons de garder, mais vous voilà responsable d'un système distribué : nouvelles tentatives, ordre des messages, échecs partiels, et deux versions de la vérité susceptibles de diverger. Le partage des données élimine la catégorie de problèmes où deux bases divergent, puisqu'il n'y en a qu'une, mais il impose aux modules de s'accorder sur un seul plan comptable, une seule définition d'article et un seul rythme de mise à jour, ce qui est une contrainte et non un avantage gratuit.

La vraie question n'est pas de savoir quel niveau est le meilleur, mais quel niveau mérite chaque flux. Le transfert nocturne d'un relevé bancaire convient. Le transfert nocturne des niveaux de stock derrière une caisse en activité, non. Skyline Nexus se situe au troisième niveau pour ses propres modules : comptabilité, point de vente et stocks, CRM, maintenance, RH, flotte et immobilisations écrivent dans un seul grand livre et un seul jeu de données de référence, et s'intègrent vers l'extérieur par API lorsqu'un client dispose déjà d'un système qui mérite d'être conservé.

Les données de référence, là où commence la dérive

On impute généralement les défaillances d'intégration aux interfaces, mais la première fissure est le plus souvent une donnée de référence qui existe en double, avec un contenu légèrement différent. Dès que deux systèmes tiennent chacun leur propre liste de clients, les listes divergent en quelques semaines, et chaque chiffre en aval hérite de cette divergence.

• Client : une identité unique pour les ventes, la facturation, les encaissements et le contrôle du crédit, faute de quoi la balance âgée clients ne concordera pas avec le rapport des ventes.
• Fournisseur : partagé entre achats, comptes fournisseurs et paiements, y compris les coordonnées bancaires, cible de fraude lorsqu'elles sont dupliquées.
• Article : un code, une unité de mesure, une méthode de valorisation. Deux référentiels articles, ce sont deux valorisations de stock.
• Plan comptable : une structure unique. Si un module tient sa propre liste de comptes et la fait correspondre à la vôtre, cette table de correspondance est une chose de plus à maintenir, et à mal faire.
• Codes de taxe : une seule définition du taux, du traitement et des dates d'effet, utilisée à la fois par la transaction et par la déclaration.
• Établissement et emplacement : partagés, car le stock comme la comptabilité sont ventilés selon cet axe.
• Salarié : une seule fiche derrière la paie, les présences, les ordres de travail de maintenance et l'affectation des véhicules.
• Actif : un seul registre derrière l'amortissement, l'historique de maintenance et la sortie.

Les grands livres auxiliaires et le compte collectif

Un grand livre général contient des soldes synthétiques. Le détail se trouve dans les grands livres auxiliaires, chacun rattaché à un compte collectif du grand livre. Le poste clients contient une ligne par facture et par encaissement client, dont la somme égale le compte collectif clients. Le poste fournisseurs fait de même pour les factures fournisseurs. Les mouvements de stock sont passés à un compte de contrôle des stocks, le coût des ventes étant constaté à la sortie des marchandises. La paie comptabilise les salaires bruts, les charges patronales, les retenues et les dettes nettes. Les immobilisations comptabilisent les acquisitions, les amortissements et les sorties en regard du coût des actifs et des amortissements cumulés. Le point de vente comptabilise les ventes, la taxe collectée, les modes de règlement et, en inventaire permanent, le volet coût de chaque vente.

La règle qui rend l'ensemble fiable est simple : l'auxiliaire doit toujours être rapproché de son compte collectif, à l'unité monétaire près. Si la balance âgée clients indique un montant et le compte collectif clients un autre, l'un des deux est faux, et l'on ne peut savoir lequel sans enquête. C'est pourquoi les écritures d'opérations diverses passées directement dans les comptes collectifs sont normalement bloquées. Une écriture manuelle sur le compte clients crée un solde qu'aucun client ne doit, et qui n'apparaîtra sur aucun relevé que vous enverrez.

Le rapprochement doit être un état que l'on peut lancer à la demande, et non un tableur que quelqu'un met à jour. Lorsque les modules partagent un seul grand livre, le rapprochement est presque une tautologie. Lorsqu'ils ne le partagent pas, c'est le contrôle le plus important que vous puissiez automatiser.

Les règles de comptabilisation et la piste d'audit

Chaque ligne du grand livre doit pouvoir être rattachée à une pièce d'origine : un numéro de facture, un bon de réception, un traitement de paie, un plan d'amortissement, une transaction de point de vente. Si une ligne existe sans pièce, quelqu'un a contourné le processus. L'identifiant de la pièce doit accompagner la ligne du grand livre, et non se trouver dans une table de correspondance séparée.

Les écritures comptabilisées ne doivent pas pouvoir être modifiées en silence. Les corrections passent par des écritures d'extourne ou des avoirs, qui laissent visibles l'original comme la correction, chacun avec sa propre date et son propre utilisateur. La clôture de période doit verrouiller la période au lieu de compter sur la mémoire de chacun pour ne pas antidater. Le test consiste à prendre n'importe quel solde, à l'ouvrir et à descendre jusqu'aux pièces qui l'ont produit sans quitter le système.

Là où les intégrations se rompent réellement

Les modes de défaillance sont bien connus, et ce sont presque toujours les mêmes.

• Décalage et séparation des exercices : une vente comptabilisée juste avant minuit le dernier jour de la période arrive dans l'autre système après la date de coupure, si bien que les deux périodes ne concordent jamais.
• Traitements en échec que personne ne surveille : un transfert planifié cesse de s'exécuter, et l'absence de données ressemble à une semaine calme.
• Écritures partielles : l'en-tête de facture est créé, les lignes échouent, et l'un des côtés détient désormais un document que l'autre ne reconnaît pas.
• Clés en double : un message renvoyé crée une seconde copie de la même facture, ou une numérotation entre en collision d'un établissement à l'autre.
• Dérive de change et d'arrondi : deux systèmes qui arrondissent à des étapes différentes, ou qui appliquent des cours différents pour la même journée, produisent de petits écarts qui s'accumulent.
• Taxe calculée deux fois : le système transactionnel et le système comptable calculent chacun la taxe, avec des règles légèrement différentes pour les remises, les prix TTC ou l'arrondi par ligne plutôt que par document. La facture remise au client et le montant de la déclaration ne concordent alors plus.

L'idempotence, et la preuve que les deux côtés concordent

Tout ce qui peut être relancé le sera : chaque opération de comptabilisation a donc besoin d'une clé stable dérivée de la pièce d'origine. Envoyer deux fois la même facture doit produire une seule écriture, pas deux. Le côté récepteur doit enregistrer les clés déjà traitées et renvoyer le résultat antérieur au lieu d'en créer un nouveau. Sans cela, le comportement ordinaire d'un réseau se transforme en chiffre d'affaires en double.

Il faut, en parallèle, faire du rapprochement une fonctionnalité à part entière : nombres et totaux par période et par type de document, comparés des deux côtés, avec la liste des écarts plutôt qu'un simple résumé. Une coche verte qui indique seulement que le dernier traitement a réussi ne prouve pas la concordance. L'état utile est celui qui nomme les sept documents présents d'un côté et absents de l'autre.

Établissements et devises

Fonctionner en multi-établissements signifie que chaque transaction porte son emplacement comme axe analytique dès sa création, et non attribué plus tard par la logique d'un état. Le stock, le chiffre d'affaires, les coûts et les effectifs relèvent tous d'un établissement, et les transferts entre établissements doivent être comptabilisés des deux côtés, faute de quoi la somme des stocks des deux établissements ne donnera pas celui de l'entreprise. La numérotation des documents doit être unique sur l'ensemble des établissements tout en restant parlante au sein de chacun.

Le multidevise exige que la devise de la transaction, le cours utilisé et le montant en monnaie de base soient tous conservés sur la ligne. Ne conserver que le montant converti revient à jeter la preuve. La réévaluation des soldes ouverts et le gain ou la perte de change réalisé au règlement ont alors un compte où être passés, et l'écart de change cesse d'être un mystère d'arrondi.

Note régionale : le dédouanement change le calendrier

Là où un régime de facturation électronique s'applique, le calendrier de l'intégration cesse d'être une préférence de conception. Plusieurs administrations fiscales exigent désormais que les factures soient validées par l'administration, ou lui soient déclarées, avant ou au moment où elles parviennent à l'acheteur. Le régime de la ZATCA en Arabie saoudite en est un exemple concret : les factures sont générées selon une structure définie, avec des éléments cryptographiques et des identifiants, et l'administration intervient dans le cycle de vie du document au lieu d'en recevoir un résumé après coup. La création de la facture devient donc un problème d'intégration en temps réel. Un traitement par lots nocturne ne peut pas produire un document que le client attend au comptoir.

La situation diffère ailleurs, et il vaut la peine d'être précis. Les États-Unis n'ont pas d'obligation fédérale de facturation électronique, et la taxe sur les ventes (sales tax) est administrée au niveau des États, avec des règles et des taux qui varient selon l'État et souvent selon la collectivité locale. Le Canada applique la TPS et la TVH au niveau fédéral avec des variations provinciales, dont des taxes de vente provinciales dans certaines provinces. Les autres marchés de la région MENA en sont à des stades différents. La leçon de conception est de réunir en un seul endroit la détermination de la taxe et l'émission des documents, de sorte qu'un marché qui passe de la déclaration au dédouanement change de paramétrage et non d'architecture. Skyline Nexus traite le dédouanement ZATCA à partir de la transaction même qui passe l'écriture au grand livre : la facture que reçoit le client et le montant de la déclaration proviennent d'un seul calcul.