Intégration des outils
Chacun de vos logiciels a raison. Ensemble, ils ont tort.
Votre ERP fonctionne. Votre CRM fonctionne. Vos marketplaces fonctionnent. Et pourtant, personne dans l'entreprise ne peut dire avec certitude où vous en êtes. Voici pourquoi, et ce qui manque réellement.
Mis à jour le 8 août 20269 minutes de lecture
Le symptôme que tout le monde reconnaît
Vous demandez le chiffre d'affaires du mois. Vous recevez trois réponses, et aucune n'est fausse.
Le commerce compte les commandes signées. La finance compte les factures émises. La logistique compte les colis partis. Chacun applique une règle défendable, cohérente avec son métier et avec ce qu'on lui demande de piloter.
Le problème n'apparaît qu'au moment où il faut décider. La réunion sert alors à départager les chiffres, pas à trancher la question qui l'a motivée. Et comme personne ne peut prouver que sa version est la bonne, on tranche à l'ancienneté ou à l'intuition.
C'est le symptôme le plus visible. Ce n'en est pas la cause.
La cause : il n'existe aucun endroit où la règle est écrite
Un logiciel du marché arrive avec ses propres définitions. Un ERP sait ce qu'est une commande pour lui. Un CRM sait ce qu'est une opportunité pour lui. Ces définitions sont bonnes, et elles sont incompatibles entre elles. Non par défaut de conception, mais parce qu'elles répondent à des questions différentes.
Ce qui manque, ce n'est donc pas un outil de plus. C'est l'endroit où votre entreprise écrit sa définition : ce qui compte comme une vente, à quel moment, sous quelles conditions, et ce qu'on fait des cas qui n'entrent dans aucune case.
Tant que cette règle n'est écrite nulle part, elle vit dans la tête de trois personnes. Elles l'appliquent correctement, différemment, et personne ne s'en aperçoit jusqu'au jour où les écarts deviennent trop gros pour être ignorés.
Pourquoi les intégrations classiques ne suffisent pas
La réaction naturelle est de connecter les outils entre eux : un connecteur du CRM vers l'ERP, un export programmé de la marketplace, un automatisme qui recopie les lignes.
Cela résout le transport. Cela ne résout pas la traduction.
Un connecteur déplace une donnée d'un système à un autre. Il ne décide pas quelle définition s'applique quand les deux divergent, ni quoi faire quand une information manque. Confronté à un cas qu'il ne sait pas traiter, il fait l'une de trois choses : il échoue bruyamment, il échoue silencieusement, ou, le pire, il devine.
Les intégrations qui devinent sont celles qui coûtent le plus cher, parce que l'erreur ne se voit pas. Un rapprochement faux ne déclenche aucune alerte : il produit un chiffre plausible, qu'on utilise pour décider.
Les quatre questions à poser avant de connecter quoi que ce soit
Elles ne portent pas sur la technique. Elles portent sur les règles, et elles doivent être tranchées par des humains avant qu'un système les applique.
- Quel événement fait foi ? La signature, la facture, l'expédition : un seul doit être la référence, et les autres s'y rattachent.
- Où naît chaque donnée, et qui la saisit ? Une donnée a une source unique ; les copies sont des copies, pas des sources.
- Que fait le système quand une information manque ? La seule bonne réponse est : il s'arrête et le dit.
- Qui tranche les cas qui n'entrent dans aucune règle, et sous quel délai ?
Les entreprises qui répondent à ces quatre questions avant de choisir un outil obtiennent un système qui tient. Celles qui achètent d'abord obtiennent un outil qui marche en démonstration et qui s'effondre sur les vingt pour cent de cas particuliers, qui consomment, eux, la moitié du temps.
Ce qu'il faut construire : une couche, pas un remplacement
Il ne s'agit pas de remplacer votre ERP s'il fait correctement son travail, ni votre CRM, ni vos canaux de vente.
Ce qui manque est une couche au-dessus : un endroit unique où les règles de votre entreprise sont écrites, appliquées et vérifiables. Elle lit les systèmes existants, applique vos définitions, et présente un résultat que chacun peut remonter jusqu'à sa source.
Trois propriétés la distinguent d'un tableau de bord ordinaire.
Chaque chiffre a une définition, une source et une heure. Quand quelqu'un le conteste, on ouvre l'écran au lieu d'ouvrir un débat.
Le système sait dire non. Quand une source ne répond plus, l'indicateur s'affiche comme non calculable, avec sa cause. Jamais un zéro, jamais une estimation silencieuse, jamais la valeur de la veille reconduite.
Chaque rôle voit ce qui le concerne. Le commercial, la logistique, la finance et la direction n'ont pas besoin du même écran. Ils ont besoin de la même donnée.
À quoi ça ressemble en pratique
Nous avons construit ce type de système pour Color Pop Control, une activité de vente multicanale : plusieurs marketplaces d'un côté, un réseau de vendeurs terrain de l'autre.
Avant, la consolidation se faisait dans un tableur, une fois par semaine. L'écran de pilotage réunit désormais les ventes de toutes les sources, suit chaque vendeur par son nom, signale les remontées manquantes au lieu de les compter comme des zéros, et bloque le calcul de la marge tant qu'une source n'a pas répondu.
Une précision qui compte : Color Pop Control a été construit dans l'environnement économique du fondateur de Corsa. Ce n'est pas un client tiers indépendant, et nous ne le présentons pas comme tel. C'est une réalisation en production dont nous pouvons montrer le comportement, pas un résultat commercial dont nous pourrions tirer des chiffres.
Quand il ne faut PAS construire
Le diagnostic conclut régulièrement qu'il ne faut rien développer, et c'est une issue prévue.
Si un logiciel du marché couvre correctement l'essentiel de votre besoin, achetez-le. Si votre processus change encore toutes les semaines, attendez qu'il se stabilise : construire sur un processus mouvant produit un système obsolète à la livraison. Si personne en interne ne peut porter le projet, ne le lancez pas : il échouera quel que soit le prestataire.
Et si le problème n'a pas de conséquence identifiable, il n'a pas besoin d'être résolu.