Planifier les flux de données entre boutique, ERP et comptabilité : vérifier les interfaces

Lorsque la boutique grandit mais que les flux de données ne suivent pas

Les boutiques en ligne en croissance rencontrent les mêmes problèmes : les processus manuels dans la gestion des stocks, les achats et la facturation consomment du temps et sont sujets aux erreurs. La transparence en temps réel sur les stocks, les mouvements de marchandises et les marges fait défaut. La boutique, l'expédition, la comptabilité et le reporting coexistent sous forme d'outils isolés, sans flux de données stables.

Pour des volumes gérables, des listes Excel, des workflows manuels et des interfaces instables suffisent souvent. Avec l'augmentation du nombre de commandes, de produits et de canaux de vente supplémentaires, les exigences en matière de processus, de logistique et de comptabilité augmentent considérablement. Les systèmes aux possibilités d'extension limitées au niveau des processus, des intégrations ou des structures de données deviennent un goulot d'étranglement.

Ce qui est décisif, c'est de savoir si l'ERP automatise proactivement les processus ou se contente de gérer les commandes. Ce ne sont pas les listes de fonctionnalités qui apportent des réponses, mais vos propres flux de données : la direction, la fréquence et les déclencheurs de chaque échange.

La comparaison doit inclure, outre les fonctionnalités, l'automatisation et l'évolutivité, la logique de prix et la structure des coûts. Dans cette chaîne, la comptabilité n'est pas un sous-produit, mais un destinataire de données à part entière.

Parmi les systèmes ERP adaptés à ces configurations figurent notamment SAP, MS Business Central, ProMode et SelectLine. Billbee et Afterbuy sont souvent utilisés dans des configurations standardisées et prennent en charge les processus de base liés aux commandes et à l'expédition ; plentyONE se concentre sur la connexion à plusieurs places de marché et canaux de distribution.

Du côté destinataire, la comptabilité suit son propre régime de formatage : la facture QR est en circulation depuis juin 2020 et a définitivement remplacé les bulletins de versement suisses le 1er octobre 2022. Les pièces justificatives qui y parviennent suivent donc des règles différentes de celles des commandes dans la boutique.

Qui possède quelles données ? Clarifier les responsabilités avant la technique

Avant toute technologie d'interface, il y a la responsabilité : pour chaque type de données, il existe exactement une source unique. Les données maîtres produits résident dans l'ERP, tandis que les mises à jour du statut des commandes proviennent de la boutique.

Cela détermine les directions des flux. Les données produits, les prix et les niveaux de stock vont de l'ERP vers la boutique. Les commandes, les changements de statut et les inscriptions de nouveaux clients vont de la boutique vers l'ERP et parfois en retour.

Dans l'exemple de SIGVARIS, la boutique est basée sur Magento Commerce et conçue comme une boutique B2B : seul un utilisateur connecté peut passer des commandes. Les produits sont importés depuis SAP via XML et attribués à la boutique spécifique à chaque pays grâce à un attribut unique, avec une dimension temporelle « à partir de » et « jusqu'à » par pays.

L'inscription d'un nouveau client dans la boutique est transférée vers SAP, où il est affecté à un groupe de clients, puis les données clients sont mises à jour dans la boutique lors de la prochaine synchronisation. Dès lors, le client peut commander avec son identifiant et son mot de passe.

La double saisie survient lorsque le même type de données est maintenu dans deux systèmes – pour les prix, les stocks et les adresses. En l'absence de propriétaire défini, les corrections sont effectuées à deux endroits et les systèmes divergent. Si le propriétaire est clairement établi, il est évident quel côté d'une interface a le droit d'écrire et lequel ne fait que lire.

Cette règle s'applique concrètement aux intégrations Shopify : les données maîtres produits résident dans l'ERP, les mises à jour du statut des commandes proviennent de Shopify. Une source unique par type de données évite la double maintenance.

La souveraineté des données maîtres inclut également les règles de quantité : la quantité minimale de commande d'un produit est identique dans toutes les boutiques par pays de SIGVARIS. Ces valeurs relèvent de la source principale, l'ERP, sinon elles devraient être mises à jour individuellement pour chaque boutique par pays.

De la réception de la commande à la pièce comptable : enregistrer le flux de données

La première étape consiste en un état des lieux. L'architecture système actuelle et la configuration ERP existante sont examinées conjointement. Tous les flux de données sont cartographiés et les exigences d'intégration définies. Il est documenté quelles informations doivent être échangées, quand et entre quels systèmes.

Doivent être enregistrés au minimum : les commandes et leur statut, les données clients et d'adresse, les stocks et mouvements de stock, les prix, les mises à jour produits, la facturation ainsi que la transmission des pièces justificatives à la comptabilité.

Pour chaque flux de données, quatre indications sont consignées : la cause de démarrage (événement ou intervalle de temps), la direction, le rythme et le format. Pour les données produits, s'ajoute la question de savoir si elles s'appliquent spécifiquement à un pays ou à un canal, et si elles comportent une période de validité. Chez SIGVARIS, les produits sont attribués à la boutique par pays via un attribut unique et gérés avec « à partir de » et « jusqu'à » par pays.

La transmission à la comptabilité constitue un flux de données distinct. Elle est enregistrée avec la cause de démarrage, la direction, le rythme et le format, comme tout autre flux. Pour les boutiques axées sur la gestion des marchandises et la comptabilité, SelectLine est souvent choisi ; les processus e-commerce sont intégrés dans le cadre du système global.

Pour la transmission des pièces justificatives, la Suisse impose un format : la facture QR se compose d'une partie paiement et d'un récépissé ; le Swiss QR Code contient toutes les informations de paiement sous forme numérique. Les directives s'adressent aux émetteurs de factures, aux institutions financières et aux développeurs de logiciels d'émission et de réception de factures.

Le champ « Informations de facture » complète les informations de paiement habituelles et permet au logiciel métier du destinataire de la facture d'automatiser l'affectation et le contrôle de la facture. La définition de syntaxe (S1) est définie et maintenue par le groupe de travail ERP de Swico ; Swico met à disposition le validateur.

D'autres voies de paiement sont disponibles, telles qu'eBill – la spécification pour l'utilisation de la procédure alternative dans le Swiss QR Code, version 1.1 du 3 février 2020 – et les messages client-banque pour les virements (pain.001), version 2.9 du 20 novembre 2020.

Les versions doivent être prises en compte dans la planification : les Directives de mise en œuvre suisses Facture QR version 2.3 sont en vigueur depuis le 22 novembre 2025. La version 2.4 s'applique à partir du 14 novembre 2026 ; l'adresse structurée (type d'adresse « S ») est prévue pour novembre 2026.

Des données de pièces justificatives structurées augmentent le degré d'automatisation de la comptabilité fournisseurs, car de nombreuses données peuvent être extraites du Swiss QR Code. Run my Accounts lit la comptabilisation et le paiement, et charge le paiement dans l'E-Banking pour validation par le client.

Celui qui n'intègre la comptabilité qu'après l'intégration planifie un flux sans point final. C'est pourquoi la transmission des pièces justificatives figure dès le début de l'état des lieux dans la liste des flux de données.

Le résultat est un état des lieux documenté. Il sert ultérieurement de base de comparaison : c'est seulement avec lui qu'il est possible d'évaluer si une nouvelle intégration élimine réellement un goulot d'étranglement ou ne fait que le déplacer.

Vérifier les interfaces : API, échange de fichiers et rythme de synchronisation

Pour connecter une boutique à un ERP, il existe deux variantes de base. L'API native du système de boutique connecte directement la boutique à l'ERP ; elle est mise en œuvre via des solutions standard prédéfinies ou un connecteur développé individuellement. Alternativement, des formats de fichiers structurés – généralement XML – sont échangés périodiquement via FTP avec push et pull.

L'échange de fichiers connaît deux modes d'exploitation combinables. Au cours de la journée, un export incrémentiel a lieu à intervalles courts – par exemple toutes les heures – suivi la nuit d'un export complet. Cette méthode est considérée comme très robuste et tolérante aux erreurs.

Elle convient aux fichiers de taille moyenne, par exemple pour 5 à 10'000 clients et 10 à 30'000 produits. Les intervalles courts maintiennent les données à jour, l'export complet nocturne corrige les écarts accumulés durant la journée. L'inconvénient : ce n'est pas du temps réel, et une erreur lors d'une exécution a un impact jusqu'à la suivante.

Un autre modèle s'ajoute : la synchronisation basée sur des intervalles. Elle maintient le niveau de stock précis dans la boutique et met à jour les données de commande dans l'ERP sans délai.

La connexion peut être unidirectionnelle ou bidirectionnelle. Chez SIGVARIS AG, le processus de commande a été entièrement et bidirectionnellement connecté à SAP. Le traitement des commandes est ainsi automatisé à 100 % – pour plus de 17'000 articles dans la boutique.

Une règle empirique pour la sélection s'applique : les modifications granulaires proches des événements, comme les changements de statut de commandes individuelles, plaident en faveur de l'API. Les grands volumes de données maîtres plaident en faveur de l'échange périodique de fichiers.

Shopify met à disposition une API native à cet effet. what.digital intègre Shopify dans les systèmes ERP via cette API, soit avec des solutions standard prédéfinies, soit avec un connecteur développé individuellement.

Next AG utilise des formats de fichiers structurés, généralement XML, échangés périodiquement via FTP avec push et pull pour les interfaces SAP. Au cours de la journée, un export incrémentiel a lieu à intervalles courts, suivi la nuit d'un export complet.

DevQon GmbH construit des interfaces bidirectionnelles entre Magento et les systèmes centraux.

La vérification des interfaces comprend également le parcours des pièces justificatives : le Swiss QR Code en tant que format, le champ « Informations de facture » et la définition de syntaxe (S1), maintenue par le groupe de travail ERP de Swico. Elle fonctionne parallèlement à l'interface de commande et de produit et est acceptée séparément.

Trois modèles et leurs combinaisons doivent donc être vérifiés : l'API native, l'échange périodique de fichiers via FTP et la synchronisation basée sur des intervalles. Le volume et le type de modification déterminent quel modèle est approprié – pas la longueur d'une liste de fonctionnalités.

Avant le développement : analyser la documentation API et les structures de données des deux côtés

L'analyse des interfaces est une étape de travail distincte avant le développement. Le système ERP, la documentation API et les structures de données des deux côtés sont analysés. Le résultat est un plan d'architecture concret avec des flux de données clairs, que les responsables voient et acceptent avant tout développement.

Les correspondances de champs entre les structures de la boutique et de l'ERP, les champs obligatoires et les plages de valeurs autorisées, les réponses d'erreur de l'API ainsi que le moment de l'acceptation sont consignés. DevQon GmbH analyse le système ERP, la documentation API et les structures de données des deux côtés ; cette analyse d'interface est gratuite et sans engagement. Indépendamment de cela, cette étape est peu coûteuse par rapport au développement qui suit.

L'avantage réside dans les erreurs détectées ici qui coûteraient cher plus tard : un champ qui n'existe pas dans l'ERP, un changement de statut que la boutique ne renvoie pas, ou un type de données pour lequel deux systèmes ont été supposés simultanément dirigeants. Si le développement est effectué sans cette vérification, les hypothèses sur les structures de données deviennent la base du code. Les corrections deviennent proportionnellement plus coûteuses par la suite.

Du côté des pièces justificatives, la même analyse vérifie l'affectation des champs des informations de facture selon la définition de syntaxe (S1). Pour la migration de la facture QR, par exemple vers l'adresse structurée, SIX met à disposition des fiches d'information ; SIX gère également un portail de validation, Swico le validateur pour la définition de syntaxe (S1).

L'acceptation du plan d'architecture avant le développement fait partie intégrante de la procédure. Celui qui ne vérifie les structures de données que dans le code paiera la correction plus tard.

Définir l'architecture d'intégration et le plan de projet

L'analyse donne naissance à l'architecture d'intégration et à un plan de projet détaillé avec des jalons clairs et des délais fixes. Le code et la documentation sont stockés de manière centralisée et versionnée – par exemple dans un dépôt GitHub. Ainsi, chaque modification reste traçable et n'existe pas uniquement sur l'ordinateur d'une seule personne.

En Suisse, il s'agit principalement de petites et moyennes entreprises avec des architectures système ayant évolué organiquement. Les systèmes ERP courants sont connectés via des solutions standard prédéfinies ou des connecteurs individuels. L'éventail va des installations SAP dans les grandes entreprises aux solutions flexibles pour les PME.

Le mode d'exploitation de l'ERP fait partie de la décision architecturale. Si l'ERP est proposé exclusivement en tant que solution SaaS et utilisé via le navigateur, une installation locale n'est pas nécessaire ; les chemins d'accès aux fichiers et les services serveur sur le réseau interne ne sont alors pas disponibles pour l'échange. Si l'ERP fonctionne localement, l'échange périodique de fichiers peut être géré sur ses propres systèmes. Cette question influence la pertinence de l'API, de l'échange de fichiers ou d'une combinaison des deux.

Outre SAP, on trouve notamment MS Business Central, ProMode et SelectLine. ProMode est proposé exclusivement en tant que solution SaaS et est utilisable via le navigateur sans installation locale ; des clients sont notamment situés en Suisse. Les clients du commerce de détail exploitent des webshops connectés à ProMode via des interfaces.

SelectLine est souvent choisi lorsque l'accent est mis sur la gestion des marchandises et la comptabilité ; les processus e-commerce font partie du système global. Billbee et Afterbuy prennent en charge les processus de base liés aux commandes et à l'expédition dans des configurations standardisées ; plentyONE se concentre sur la connexion à plusieurs places de marché et canaux de distribution.

La facturation fait partie de la même décision architecturale : si la facturation a lieu dans l'ERP, le logiciel doit prendre en charge la version valide des Directives de mise en œuvre Facture QR. Depuis le 22 novembre 2025, la version 2.3 s'applique, et à partir du 14 novembre 2026, la version 2.4.

Systèmes ERP comparés : forces et domaines d'application

Tester, Go-live et exploitation : prévoir les cas d'erreur et la formation

Après le développement, des tests internes sont d'abord effectués selon un processus QA défini. Suit ensuite la phase de test au sein de l'entreprise elle-même, avec support pour la résolution des erreurs. Ce n'est que lorsque les tests confirment que tout fonctionne comme souhaité que l'intégration est déployée. Dès lors, les performances, la fiabilité et la sécurité sont surveillées.

Le Go-live comprend une documentation d'intégration complète et des formations pour l'équipe, afin que les flux de données restent vérifiables au quotidien.

Vérifiable signifie concrètement : en exploitation, une panne du système et un export interrompu doivent être détectés. Avant le Go-live, les cas d'erreur sont nommés : commande non reçue, appel API échoué, exécution FTP interrompue, stocks contradictoires entre la boutique et l'ERP. Il est défini qui les détecte, comment une exécution est relancée et comment la synchronisation est rétablie après une panne. L'export complet nocturne nettoie les écarts accumulés.

Du côté des pièces justificatives, des cas d'erreur spécifiques s'ajoutent : une facture dont les informations ne peuvent pas être affectées par le logiciel comptable, ou une validation qui échoue en raison de la version des directives. SIX met à disposition un portail de validation à cet effet, Swico un validateur pour la définition de syntaxe (S1).

what.digital effectue le développement et les tests en interne selon un processus QA, puis les transmet pour la phase de test et apporte son soutien à la résolution des erreurs. Après réussite des tests, l'intégration est déployée et les performances, la fiabilité et la sécurité sont surveillées.

Points de contrôle pour votre propre planification