Synchroniser un catalogue avec un ERP : formats et fréquences

Relier un logiciel de gestion à une boutique en ligne paraît être un problème technique et il s'agit d'abord d'un problème de découpage. L'erreur la plus fréquente consiste à concevoir une synchronisation unique, qui envoie tout le catalogue à intervalle régulier, et à découvrir ensuite que les stocks arrivent trop tard, que les fiches produits écrasent les descriptions travaillées par l'équipe marketing, et qu'une seule erreur bloque l'ensemble du traitement. Un dispositif qui tient dans la durée sépare les données selon leur urgence et leur sens de circulation, et il traite les erreurs sans interrompre le reste. Nous détaillons ici ce découpage, les formats d'échange à retenir et les fréquences adaptées à chaque flux.

Découper les données par nature

Les informations échangées entre les deux systèmes n'ont ni la même volatilité, ni la même source de vérité, ni les mêmes conséquences en cas de retard.

Les données de référence

La référence fabricant, le nom technique, les dimensions, le poids et la catégorie appartiennent au logiciel de gestion et changent rarement. Elles se synchronisent une fois par jour, voire à la demande lors de la création d'une référence. Leur retard n'a aucune conséquence commerciale. Ce sont les données qui posent le moins de difficultés et elles occupent pourtant l'essentiel des discussions initiales. La structure de ces attributs conditionne toutefois le reste du dispositif, comme le détaille notre article sur le catalogue, ses attributs variables et sa structure de données. La définir correctement au départ évite une reprise complète six mois plus tard.

Les prix

Le prix appartient généralement au logiciel de gestion et il ne doit jamais être modifiable dans la boutique, sous peine d'incohérences permanentes. Sa volatilité varie beaucoup selon les secteurs, de quelques changements par an à plusieurs par jour. Un décalage se traduit par une vente à un prix erroné, ce qui engage l'entreprise vis-à-vis du client. Une fréquence horaire couvre la plupart des situations, une fréquence de quelques minutes s'impose sur les marchés volatils. Les prix par client, fréquents en vente entre professionnels, ajoutent une complexité considérable. Ils demandent un traitement dédié plutôt qu'une extension du flux principal.

Les stocks

Le stock est la donnée la plus volatile et celle dont le retard coûte le plus cher, puisqu'il produit des commandes impossibles à honorer. Sa synchronisation doit être la plus rapide du dispositif, idéalement événementielle. Elle doit également être la plus légère, ne transportant qu'une référence et une quantité. Confondre ce flux avec celui des fiches produits conduit à envoyer des mégaoctets pour mettre à jour quelques nombres. Cette séparation constitue probablement la décision de conception la plus importante. Elle se prend en une minute et elle détermine tout le reste.

Les contenus éditoriaux

La description commerciale, les visuels et les textes optimisés pour la recherche appartiennent à la boutique et non au logiciel de gestion. Les écraser à chaque synchronisation détruit un travail coûteux, situation classique qui décourage durablement les équipes. La règle consiste à ne jamais faire circuler ces champs depuis la gestion vers la boutique. Lorsque la gestion contient une description à reprendre, elle ne doit alimenter la boutique qu'à la création de la référence, jamais lors des mises à jour. Cette distinction entre première écriture et mise à jour doit être explicite dans la conception. Son absence produit le grief le plus fréquent contre ce type de projet.

Les commandes

Ce flux circule dans l'autre sens, de la boutique vers la gestion, et il porte des enjeux différents. Une commande perdue est un incident majeur, ce qui impose un mécanisme d'accusé de réception et de reprise. La fréquence peut être de quelques minutes sans conséquence, à condition qu'aucune commande ne se perde. Le rapprochement entre les identifiants des deux systèmes doit être prévu dès le départ. Ce flux justifie à lui seul une file d'attente avec conservation des messages non traités. Il constitue la partie la plus critique du dispositif.

Les clients

Les données clients circulent dans les deux sens selon les organisations, ce qui pose la question de la source de vérité. Une règle claire, désignant un système maître par type d'information, évite les écrasements mutuels. Ces données sont personnelles et leur circulation relève de la réglementation, ce qui impose de limiter les champs échangés au strict nécessaire. Nous ne sommes pas juristes et une revue de ce flux par un conseil spécialisé se justifie lorsqu'il porte un volume important. Le principe de minimisation guide utilement la conception. Il simplifie également le développement.

Choisir les formats d'échange

Le format retenu détermine la robustesse et la facilité de diagnostic, davantage que la performance.

Le fichier tabulaire déposé

La méthode la plus ancienne consiste à déposer un fichier sur un serveur de transfert, que l'autre système vient récupérer. Elle fonctionne avec absolument tous les logiciels de gestion, y compris les plus anciens. Sa simplicité constitue sa force et ses limites : pas de retour d'erreur, pas de traitement partiel, latence liée à la fréquence de dépôt. Elle convient parfaitement aux données de référence et mal aux stocks. Elle reste la solution de démarrage la plus rapide à mettre en œuvre. Beaucoup de dispositifs commencent ainsi et évoluent ensuite par flux.

Le format structuré échangé par interface

Les échanges par interface de programmation, avec des messages structurés, permettent un traitement ligne par ligne et un retour d'erreur précis. Ils autorisent également les mises à jour partielles, ce qui allège considérablement les volumes. C'est le format à retenir dès que le catalogue dépasse quelques milliers de références. Il suppose que les deux systèmes exposent une interface, ce qui est le cas des logiciels récents. Sur un logiciel ancien, un module intermédiaire peut faire la traduction. Ce qu'un connecteur prend réellement en charge est détaillé dans notre article sur les connecteurs ERP e-commerce et ce qu'ils font vraiment.

La notification événementielle

Le système source prévient l'autre dès qu'une donnée change, ce qui supprime la latence et la charge inutile. Cette approche est la plus efficace et elle suppose que le logiciel de gestion sache émettre ces notifications. Elle exige un mécanisme de reprise, car un message perdu produit un écart permanent. Une réconciliation quotidienne, comparant les deux bases, complète indispensablement le dispositif. Sans elle, les écarts s'accumulent silencieusement pendant des mois. Cette combinaison de l'événementiel et de la réconciliation constitue l'architecture de référence.

Le format des identifiants

La correspondance entre les références des deux systèmes constitue le point le plus souvent bâclé et le plus coûteux à corriger. Un identifiant stable, unique et immuable doit être défini, et il ne doit jamais être le nom du produit ni sa position dans une liste. Les règles applicables sont détaillées dans notre article sur les identifiants produit stables et la cohérence des flux. Cette décision se prend avant tout développement et elle est irréversible en pratique. La reprendre après coup impose de rapprocher manuellement des milliers de lignes. C'est le premier sujet à traiter dans toute réunion de cadrage.

La gestion des unités et des formats

Les décimales, les séparateurs, les unités de mesure et les fuseaux horaires diffèrent régulièrement entre les deux systèmes. Un prix exprimé en centimes d'un côté et en euros de l'autre produit des erreurs d'un facteur cent, spectaculaires et heureusement visibles. Une différence de fuseau horaire sur les dates de disponibilité produit des erreurs d'un jour, bien plus discrètes. Documenter le format attendu de chaque champ, avec un exemple, évite ces situations. Ce document tient sur deux pages et il sert pendant toute la vie du dispositif. Il constitue le contrat entre les deux systèmes.

La compression et le volume

Un catalogue complet de cinquante mille références représente plusieurs dizaines de mégaoctets, ce qui rend l'envoi intégral coûteux. Ne transmettre que les lignes modifiées depuis le dernier échange divise ce volume par cent dans les cas courants. Cette approche suppose que le système source sache identifier les modifications, ce qui n'est pas toujours le cas. Un horodatage de dernière modification sur chaque enregistrement suffit généralement. Lorsqu'il n'existe pas, l'ajouter constitue le premier chantier. C'est un investissement modeste au regard du gain permanent.

Traiter les erreurs sans tout bloquer

Un dispositif de synchronisation passe la majeure partie de sa vie en fonctionnement dégradé, et sa qualité se mesure à sa façon de gérer ces situations.

Isoler la ligne fautive

Un traitement qui s'interrompt à la première erreur laisse le reste du catalogue non mis à jour, ce qui transforme un problème mineur en incident majeur. Chaque ligne doit être traitée indépendamment, les erreurs étant collectées et rapportées sans interrompre le flux. Cette conception paraît évidente et elle est absente de nombreux développements. Elle demande simplement d'entourer chaque traitement d'un mécanisme de capture. Le gain de robustesse est considérable pour un coût nul. C'est la première chose à vérifier sur un connecteur existant.

Rejouer sans dupliquer

Un traitement doit pouvoir être relancé sans produire de doublons ni d'effets indésirables. Cette propriété s'obtient en identifiant chaque message et en vérifiant qu'il n'a pas déjà été traité. Sans elle, une reprise après incident crée des commandes en double dans le logiciel de gestion. Ce cas se produit régulièrement et il génère un travail de correction manuel important. La vérification consiste à relancer volontairement un traitement et à observer le résultat. Ce test doit figurer dans la recette du connecteur.

Distinguer les erreurs temporaires

Une indisponibilité réseau ou un dépassement de délai doivent conduire à une nouvelle tentative, alors qu'une donnée invalide doit être rejetée définitivement. Confondre les deux produit soit des tentatives infinies sur une ligne incorrigible, soit un abandon sur un incident passager. Un mécanisme de nouvelle tentative avec délai croissant, limité à quelques essais, traite correctement le premier cas. Le second alimente un rapport d'erreurs à traiter humainement. Cette distinction structure toute la gestion des incidents. Elle se code en quelques lignes.

Alerter au bon niveau

Un rapport quotidien listant les lignes rejetées suffit pour les erreurs de données. Une alerte immédiate s'impose lorsque le flux s'arrête complètement ou lorsque le taux d'erreur dépasse un seuil. Envoyer une alerte par ligne rejetée produit un bruit qui conduit à ignorer toutes les alertes. Ce calibrage détermine si le dispositif sera réellement surveillé. Il mérite d'être ajusté après quelques semaines d'exploitation. Une boîte de réception saturée d'alertes équivaut à une absence de surveillance.

Prévoir la réconciliation

Un contrôle périodique comparant les deux bases détecte les écarts que la synchronisation a manqués. Il porte sur les nombres essentiels : nombre de références, somme des stocks, échantillon de prix. Un écart signale un dysfonctionnement qu'il faut investiguer avant qu'il ne s'aggrave. Ce contrôle se lance chaque nuit et il produit un rapport de quelques lignes. Il constitue le filet de sécurité de tout le dispositif. Son absence explique la plupart des dérives découvertes des mois trop tard.

Conserver une trace des échanges

Journaliser chaque message envoyé et reçu, avec son horodatage et son résultat, permet de reconstituer ce qui s'est passé. Cette trace est indispensable pour diagnostiquer un écart de stock ou une commande manquante. Sa conservation doit être limitée dans le temps et son volume surveillé, un catalogue important produisant des journaux considérables. Un stockage de trente jours suffit à la plupart des besoins. Cette journalisation se met en place dès le premier développement. L'ajouter après coup impose de reprendre tout le code.

Conduire le projet

Ce type de chantier échoue rarement pour des raisons techniques et souvent pour des raisons d'organisation.

Désigner la source de vérité par champ

Le tableau listant chaque champ avec son système maître constitue le document fondateur du projet. Sa rédaction révèle immédiatement les désaccords entre les équipes, qu'il vaut mieux traiter avant le développement. Il tient sur une page et il évite des mois de discussions. Il sert également de référence lors des évolutions. Chaque ligne doit être validée par la personne responsable de la donnée concernée. Cette validation formelle engage et elle évite les revirements.

Commencer par un flux

Mettre en production la synchronisation des stocks seule, la faire fonctionner pendant deux semaines, puis ajouter les prix constitue une progression saine. Développer les six flux simultanément produit une mise en service chaotique où rien n'est stable. Cette progressivité rassure également les équipes métier, qui voient un résultat rapidement. Elle permet de corriger les choix de conception avant de les répliquer. Le calendrier apparent s'allonge et le délai réel jusqu'à un fonctionnement stable se raccourcit. C'est un arbitrage qui mérite d'être expliqué au commanditaire.

Prévoir un environnement de test

Tester une synchronisation directement en production expose à des dégâts considérables, un flux mal configuré pouvant écraser des milliers de fiches. Un environnement de test, avec une copie du logiciel de gestion, est indispensable. Beaucoup d'éditeurs proposent un environnement de démonstration à cette fin. Lorsque cette copie n'existe pas, un mode simulation, qui affiche ce qui serait fait sans le faire, constitue le minimum. Ce mode doit être développé en même temps que le connecteur. Il sert ensuite pendant toute la vie du dispositif.

Chiffrer honnêtement

Un connecteur entre deux systèmes représente typiquement quinze à quarante jours de développement selon la complexité, auxquels s'ajoutent la recette et la période de stabilisation. Les estimations à cinq jours proviennent d'une sous-estimation du nombre de cas particuliers. Les ordres de grandeur varient surtout selon le nombre de flux retenus et la qualité de l'interface exposée par le logiciel de gestion. Annoncer un chiffre réaliste dès le départ évite les tensions ultérieures. Le chiffrage doit inclure la maintenance, souvent estimée à quelques jours par an. Cette ligne budgétaire est régulièrement oubliée.

Former les utilisateurs

Les personnes qui saisissent les données dans le logiciel de gestion doivent comprendre que leurs saisies alimentent désormais la boutique. Un champ laissé vide, une unité incorrecte ou une catégorie mal choisie produisent des conséquences visibles par les clients. Cette compréhension change les pratiques plus efficacement qu'une consigne écrite. Une session d'une heure, avec des exemples concrets, suffit généralement. Elle doit être renouvelée à chaque arrivée dans l'équipe. Elle constitue souvent le facteur déterminant de la qualité des données.

Documenter et transmettre

Le fonctionnement du connecteur, les correspondances de champs, les fréquences et les procédures de reprise doivent être consignés. Sans cette documentation, le départ de la personne qui l'a développé rend toute évolution risquée. Ce document doit vivre avec le projet et être mis à jour à chaque modification. Il tient généralement en une dizaine de pages. Sa rédaction représente deux jours et elle évite des semaines de rétro-ingénierie. C'est probablement le livrable dont la valeur est la plus sous-estimée.