Les entreprises identifient souvent un problème d’intégration alors que le vrai sujet est le modèle de données. Il y a des commandes en double, des clients nommés différemment selon les systèmes, des statuts qui ne correspondent pas entre l’ERP et l’ecommerce, ou encore des rapports qu’il faut nettoyer manuellement avant de pouvoir leur faire confiance. La réaction habituelle consiste à ajouter une intégration supplémentaire ou à créer un export de plus. Mais si chaque système définit les données à sa manière, on déplace le problème au lieu de le résoudre.
Si chaque système interprète la même donnée différemment, l’entreprise n’a pas une intégration : elle a des versions incompatibles de la réalité.
Un modèle de données partagé ne signifie pas centraliser tout dans une base unique ni imposer une architecture monolithique. Il s’agit de convenir des entités communes, de leur signification et de la personne responsable de chaque changement. Pour une PME, cela peut être aussi concret que définir ce qu’est un client, une commande, un retour, un produit ou une facture. Sans cette définition, chaque nouveau projet finit par créer sa propre couche de traduction entre les systèmes.
Pourquoi les intégrations ne suffisent pas lorsque l’activité grandit
Les intégrations résolvent le transport de l’information. Le modèle de données résout son sens. Cette différence paraît théorique, mais dans les opérations quotidiennes elle se voit très vite. Un ERP peut considérer qu’une commande est confirmée dès que le stock est réservé. Une plateforme ecommerce peut la considérer vendue au moment du paiement. Le support client peut vouloir la voir comme en attente jusqu’à l’expédition. Tous les systèmes sont connectés, mais aucun ne parle exactement la même langue.
Quand l’activité grandit, les exceptions grandissent aussi. De nouveaux canaux apparaissent, les règles de prix se complexifient, les lots sont introduits, les abonnements se développent, les retours partiels se multiplient, les commandes internationales arrivent, ou bien des étapes manuelles s’ajoutent pour certains cas particuliers. Si l’entreprise ne pense qu’en intégrations point à point, chaque nouveau cas ajoute une exception. Le coût ne se limite pas au développement ; il faut surtout maintenir la cohérence lorsque les processus, les catalogues ou les responsabilités changent.
Un symptôme très fréquent est le problème des “données de référence disputées”. Le même client existe dans le CRM, l’ERP et l’ecommerce, mais pas avec la même structure ni le même identifiant. Il en va de même pour les produits, les entrepôts ou les grilles tarifaires. Les équipes cessent alors de faire confiance au système et reviennent aux tableurs, aux emails ou aux contrôles manuels. À court terme, cela semble pragmatique ; à moyen terme, cela produit une opération lente et fragile.
Ce qu’un modèle de données partagé doit contenir
L’erreur la plus fréquente consiste à vouloir modéliser absolument tout dès le départ. Cela retarde souvent le projet et augmente la résistance interne. Il vaut mieux commencer par les entités qui impactent le plus l’opérationnel et le reporting. Dans beaucoup d’entreprises, il s’agit du client, du produit, de la commande, de la facture, de l’expédition, du stock et du retour.
Pour chaque entité, il convient de définir quatre éléments :
- Nom métier et signification : par exemple, ce qui distingue une commande confirmée d’une commande créée ou préparée.
- Identifiant unique : quel champ ou quelle combinaison de champs permet de reconnaître la même entité dans tous les systèmes.
- Système de référence : quelle source l’emporte en cas de conflit.
- Événements ou états autorisés : quelles transitions sont valides et lesquelles doivent être bloquées ou revues.
Il est également utile de documenter les données qui ne doivent pas être dupliquées. Un exemple classique est l’adresse de facturation du client, souvent copiée dans plusieurs systèmes puis mise à jour dans certains et pas dans d’autres. Autre cas fréquent : le catalogue produit. Si le commerce, les ventes et les opérations modifient les descriptions, les unités ou les attributs sans règle commune, le résultat devient incohérent.
Un modèle partagé n’a pas besoin d’être rigide. Il peut coexister avec des extensions locales par canal ou par unité métier. L’essentiel est que ces extensions ne cassent pas le noyau commun. Si un canal a besoin de champs spécifiques, on peut les ajouter comme attributs complémentaires, sans redéfinir l’entité de base.
Comment passer de systèmes isolés à une base commune sans arrêter l’activité
La transition doit se faire par étapes. Vouloir redessiner tous les systèmes en même temps crée généralement du risque opérationnel et de la fatigue pour les équipes. Une approche plus réaliste commence par cartographier où apparaissent les écarts les plus coûteux : commandes, clients, stock, facturation ou reporting.
Une bonne première étape consiste à construire un inventaire des sources de données. Il n’a pas besoin d’être complexe : il suffit de lister quel système crée chaque donnée, lequel la modifie, où elle est consommée et ce qui se passe si elle manque ou arrive trop tard. Cette cartographie révèle souvent que certaines données sont créées à trop d’endroits et que d’autres n’ont pas de propriétaire clair.
Ensuite, il est recommandé de définir un flux maître par entité. Par exemple, l’ERP peut être la référence pour les factures et le stock ; l’ecommerce pour les statuts de checkout ; le CRM pour les segments ou les relations commerciales. L’important n’est pas que toutes les données naissent dans un même système, mais que l’entreprise sache où se trouve la vérité opérationnelle de chaque donnée.
À partir de là, les intégrations doivent être conçues pour synchroniser, et non pour réinterpréter. Cela implique de valider les formats, les statuts et les règles avant d’envoyer les données vers d’autres systèmes. Cela exige aussi un enregistrement des erreurs exploitable : il ne suffit pas qu’une intégration “échoue” ; il faut savoir quel enregistrement a échoué, pourquoi et qui doit le corriger.
À ce stade, une couche de normalisation est souvent utile, via des API, des files d’attente ou un service intermédiaire de données. Son rôle n’est pas d’ajouter de la complexité, mais d’isoler les changements. Si la structure de l’ecommerce évolue demain, l’entreprise ne devrait pas devoir refaire toutes les connexions en aval.
Les signes qu’il est temps d’investir dans un modèle partagé
Certains indicateurs sont très clairs. Le premier est le temps que l’équipe passe à rapprocher les données entre systèmes. Si chaque clôture mensuelle, chaque campagne ou chaque revue commerciale nécessite des heures de vérification manuelle, le coût est déjà structurel.
Le deuxième indicateur est l’incohérence dans les décisions. Quand les ventes, les opérations et l’administration travaillent avec des chiffres différents, le problème ne concerne pas seulement les rapports ; il s’agit de gouvernance des données. Dans ce cas, chaque service défend sa propre version et la discussion devient politique au lieu d’être opérationnelle.
Le troisième indicateur est la dépendance à quelques personnes. Si une ou deux personnes seulement savent vraiment comment les données s’articulent entre les systèmes, l’entreprise est exposée. La connaissance critique ne devrait pas vivre dans un fichier personnel ni dans la mémoire d’un technicien.
Il faut aussi regarder le coût des petits changements. Si ajouter un nouveau canal, une nouvelle règle tarifaire ou une nouvelle règle métier oblige à toucher cinq systèmes et à revoir dix exceptions, le modèle actuel pénalise déjà la croissance.
Un modèle de données partagé n’est ni un projet à la mode ni une couche abstraite de conseil. C’est une manière de réduire la friction opérationnelle et de rendre les intégrations durables. Pour beaucoup de PME, le bon moment pour s’y attaquer arrive plus tôt qu’on ne le pense : quand les systèmes fonctionnent déjà, mais que l’entreprise commence à avancer plus lentement qu’elle ne le devrait. À ce stade, Codefuente aide souvent les équipes à structurer les données avant d’ajouter de nouvelles connexions.