Une méthode organisée autour de contrôles concrets.
Chaque étape rassemble les faits à établir avant de passer à la suivante.
Guide pratique — Le chantier qui se fait avant de choisir un outil
Format opérationnel · trames, fiche de donnée et check-list
Un vendredi après-midi, deux personnes devant le même écran. Le commercial affirme que le client est à jour et que la commande peut partir. La comptable affirme qu'il traîne deux factures et qu'il faut bloquer.
Ils ont raison tous les deux. Le client existe deux fois.
Une fiche porte la raison sociale complète, l'autre l'abrégé que quelqu'un a saisi un jour de rush. Les commandes se répartissent entre les deux. L'encours aussi. La remise négociée l'an dernier n'est renseignée que sur l'une — la moins utilisée.
Personne n'a fauté. Le système a fait ce qu'on lui demandait : enregistrer ce qu'on saisit.
Ce guide porte sur le travail qui précède tout projet informatique et qui lui survit. Il vaut pour un ERP, un CRM, une caisse, une boutique en ligne, une activité de négoce ou de services. Position assumée : ce chantier se mène avant de choisir un outil, et c'est le seul dont la valeur reste entière si le projet est annulé.
Un référentiel, c'est un endroit où l'on a le droit d'avoir raison
La définition n'est pas technique. Un référentiel qui fait foi, c'est une donnée dont on sait, sans discuter, où se trouve la version qui l'emporte sur les autres.
Deux symptômes signalent qu'il n'y en a pas chez vous. Une correction faite quelque part doit être refaite ailleurs, à la main, par quelqu'un qui pense à le faire. Et surtout : quelqu'un maintient un fichier personnel « parce que celui du système n'est pas à jour ».
Ce fichier personnel n'est pas le problème. C'est le diagnostic.
Un système d'information ne crée pas cette autorité. Il l'applique. S'il n'y en a pas, il applique le désordre plus vite et plus loin.
Le doublon client ne coûte pas ce que l'on croit
On présente le doublon comme un problème de propreté. C'est un problème d'argent.
La relance. Une créance suivie sur une fiche, une commande passée sur l'autre. La relance part sur la mauvaise, ou ne part pas. Le retard de paiement ne vient pas d'un client mauvais payeur, il vient d'un client mal identifié.
L'encours. Le plafond posé sur une fiche ne bloque rien tant que la commande passe par la seconde. C'est le mécanisme exact par lequel un dépassement se produit sans qu'aucune alerte ne se déclenche — l'alerte fonctionnait, elle regardait ailleurs.
La remise appliquée deux fois. Un accord saisi sur les deux fiches à des dates différentes, puis renégocié sur une seule. La nouvelle s'ajoute au lieu de remplacer. Personne ne le voit avant une revue de marge, s'il y en a une.
Et le reste. Le client qui pèse le plus dans votre activité, coupé en deux, n'apparaît dans aucun classement. Le chauffeur se présente à l'adresse de la fiche dormante, là où le client ne réceptionne plus depuis huit mois.
Les causes sont toujours les mêmes : aucune recherche imposée avant création, aucun champ d'identification obligatoire, trop de personnes autorisées à créer, et une raison sociale qui s'écrit de six façons — avec ou sans « société », « SARL » ou « S.A.R.L. AU », parfois avec le nom du gérant à la place de celui de l'entreprise.
Le remède tient en une phrase à faire écrire par la direction commerciale : on ne crée pas un client, on cherche d'abord.
Cinq questions à trancher avant de toucher au fichier clients
Elles n'ont pas de réponse universelle. Elles ont une réponse chez vous, et elle doit être écrite.
Qu'est-ce qu'un client ? L'entité qui commande, celle qui est facturée, ou celle qui reçoit ? Un même groupe peut être les trois. La règle courante — une fiche par entité facturable, des adresses de livraison rattachées — n'est pas la seule possible, mais c'est celle qui pose le moins de problèmes de recouvrement.
Comment traite-t-on un groupe ? Filiales séparées sous une entité mère porteuse des conditions, ou fiches indépendantes ? Cela se décide selon qui négocie et qui paie, pas selon l'organigramme.
Un prospect est-il dans le même fichier qu'un client ? Oui, avec un statut qui bascule — sinon vous créerez le client une deuxième fois le jour de la première commande.
Que fait-on d'un client de passage ? Une caisse en produit chaque jour. Il n'a pas à peupler le référentiel nominatif, mais il doit être rattaché à quelque chose.
Quelle clé reconnaît un client déjà existant ? L'ICE, quand il est renseigné et saisi sans espaces ni tirets, est la moins ambiguë dont on dispose ici. À défaut : téléphone normalisé, puis raison sociale réduite. Une clé jamais obligatoire ne sert à rien.
Trame de fiche client — champs minimaux à imposer
IDENTIFICATION Raison sociale exacte · ICE · forme juridique
Identifiant interne (non parlant, non modifiable)
Statut : prospect / actif / inactif / bloqué
CONTACT Téléphone normalisé · e-mail · interlocuteur commande
Interlocuteur facturation (souvent différent)
ADRESSES Siège · facturation · livraison(s), une par ligne
Contraintes de livraison : horaires, accès, jour fermé
COMMERCE Grille tarifaire applicable · remise contractuelle
Conditions de paiement · plafond d'encours
Commercial ou agence de rattachement
CLASSIFICATION Secteur · canal · taille — les axes de vos statistiques
CRÉÉE PAR ... LE ... DERNIÈRE VÉRIFICATION LE ...
Le champ « dernière vérification » sert plus que tous les autres. C'est lui qui distingue une donnée maintenue d'une donnée qui a seulement été juste, un jour.
La fiche article décrit, et surtout commande
Une fiche article contient deux natures d'informations, et les confondre est la cause la plus fréquente des paramétrages ratés.
Il y a ce qui décrit : libellé, marque, photo, texte commercial. Une erreur ici est visible et se corrige.
Et il y a ce qui commande : les attributs à partir desquels le système déclenche des règles. Une erreur ici ne se voit pas — elle produit un comportement. La liste est courte, elle mérite un soin particulier.
L'unité de stock et son rapport aux autres unités.
Le poids et les dimensions, sans lesquels aucun calcul de chargement, de frais de port ou d'implantation ne tient.
Le suivi par lot, par date ou par numéro de série. Il se décide article par article et devient presque impossible à changer dès qu'il y a du stock.
Les contraintes de conservation, température minimale et maximale quand elles s'appliquent.
Le statut : actif, en fin de vie, bloqué à la vente, bloqué à l'achat. Sans lui, un article ne sort du catalogue qu'en étant supprimé — et on ne supprime jamais un article qui porte de l'historique.
Le rattachement de gestion : famille, gamme, régime de taxe, compte comptable. C'est lui qui envoie une écriture au bon endroit.
Un article bien décrit et mal attribué passe la recette, puis échoue en exploitation trois semaines après le démarrage, quand plus personne ne fait le lien.
Les unités : le champ où se perdent les projets
Un article se vend à la pièce, se stocke au carton, s'achète à la palette. Trois unités, deux conversions. Si le rapport n'est pas renseigné, ou l'est dans le mauvais sens, tout ce qui en découle est faux d'un facteur entier : le stock, la valorisation, le réapprovisionnement, la commande d'achat.
Deux pièges méritent d'être nommés.
Le colisage qui change. Le fournisseur passe de douze à dix par carton et prévient rarement. La conversion enregistrée reste celle d'avant. Le stock dérive lentement, personne ne comprend pourquoi.
La conversion non fixe. Une caisse de frais se vend au kilo et se manipule à la caisse ; un rouleau se vend au mètre et se stocke à l'unité, avec des longueurs inégales. Cela se gère — à condition que le référentiel dise laquelle des deux unités fait foi pour le stock, article par article.
Trame à remplir, par famille d'articles
FAMILLE ..........................
Unité de stock (celle qui compte) ............
Unité d'achat ............ = ....... unité(s) de stock
Unité de vente ............ = ....... unité(s) de stock
Conversion fixe ? oui / non — si non, règle : ..........
Arrondi autorisé à la vente ? oui / non
Qui met à jour la conversion quand le fournisseur change : ..........
Le code parlant finit toujours par mentir
Nous recommandions autrefois des codifications parlantes : deux lettres pour la famille, deux pour la sous-famille, un chiffre pour le conditionnement. On lisait le code et on savait ce qu'on manipulait.
Nous ne le recommandons plus. Nous l'avons vu se retourner trop de fois.
Un code parlant repose sur une classification, et une classification vit : une famille est scindée, un produit change de conditionnement, deux gammes fusionnent. Le code, lui, ne peut plus bouger — il est imprimé sur des étiquettes, référencé chez des clients, présent dans dix ans d'historique. Vous vous retrouvez avec des codes qui affirment quelque chose de faux, et des équipes qui les lisent encore comme s'ils disaient vrai.
Ce qui fonctionne : un identifiant non parlant, court, jamais modifié, et l'information portée par des attributs qu'on peut faire évoluer. Le besoin de reconnaître un article au premier coup d'œil est réel, mais il se traite par la recherche et l'affichage, pas par la structure de l'identifiant.
Deux règles complètent celle-ci. On ne réutilise jamais un code libéré. Et l'ancien code se conserve dans un champ du référentiel, pas dans un tableau de correspondance à part — un tableau à part n'est jamais maintenu au-delà du sixième mois.
Tarifs et conditions : la donnée que personne ne veut posséder
Le prix n'est pas un attribut de l'article. C'est une relation entre un article, un client, une période, parfois une quantité et un canal.
Ce qu'il faut cesser : un tarif de base, plus des remises accordées au fil de l'eau et enregistrées nulle part sauf dans les commandes déjà passées. Le jour du changement d'outil, rien ne permet de reconstituer ce que chaque client est censé payer — le seul endroit où l'accord existe est la mémoire du commercial qui l'a négocié.
À écrire, par client ou par groupe : la grille de référence, la remise contractuelle et son assiette, les conditions de paiement, le plafond d'encours, la date de fin de validité. Cette dernière est celle qu'on oublie. Une condition sans date de fin devient perpétuelle par défaut.
Et une distinction à trancher, présente dans tous les outils : la remise s'applique-t-elle sur la ligne ou en pied de document ? Les deux se pratiquent, elles ne donnent pas les mêmes marges par produit ni les mêmes commissions.
Nettoyer avant, jamais après
Nous laissions autrefois le nettoyage se faire pendant le projet, en parallèle du paramétrage. C'était une erreur, et nous l'assumons.
Corriger dans l'ancien système est simple : on modifie, c'est fait. Corriger après une reprise oblige à répercuter en test puis en production, à re-tester les règles qui dépendaient de la donnée, et à recommencer si un second chargement est prévu.
L'ordre qui fonctionne :
Geler la création. Une seule personne autorisée à créer un client ou un article pendant le chantier. Cette mesure seule arrête la production de doublons.
Trier par activité réelle — mouvements et commandes sur vingt-quatre mois. La tête de liste passe en priorité absolue ; la queue peut attendre, voire ne jamais partir.
Dédoublonner sur une clé, pas à l'œil. Rapprochement automatique sur identifiant, puis téléphone, puis raison sociale réduite en minuscules sans espaces ni ponctuation. La machine propose, un humain tranche.
Désigner la fiche survivante avant de fusionner, et noter où va l'historique de l'autre.
Compléter les attributs qui commandent sur les seuls articles retenus.
Sortir les inactifs du périmètre repris plutôt que les supprimer. L'ancien système reste consultable.
Qui est propriétaire de quelle donnée
C'est la question qui fait tenir tout le reste, et elle n'est presque jamais posée.
Un propriétaire de donnée n'est pas celui qui la saisit. C'est la fonction qui a autorité pour dire ce qui est juste et qui répond quand c'est faux. Une fonction, jamais un nom : les personnes changent de poste.
Répartition qui tient dans la plupart des organisations : les achats possèdent la fiche article et ses attributs physiques ; le commerce, la fiche client, sa classification, les tarifs et les conditions ; la comptabilité, les rattachements comptables, les conditions de paiement et le plafond d'encours ; l'exploitation, les emplacements, les contraintes de livraison et les conditionnements logistiques.
Reste le cas qui pose problème partout : la donnée à double propriétaire. Le plafond d'encours en est l'exemple type — le commerce veut vendre, la comptabilité veut être payée. Il ne se partage pas. Il s'attribue, et l'autre partie obtient un droit de demande, pas un droit de modification.
Trame de fiche de donnée — une page par donnée structurante
DONNÉE ......................................................
SYSTÈME DE RÉFÉRENCE Où se trouve la version qui fait foi
Où elle est recopiée, et dans quel sens
PROPRIÉTAIRE Fonction (jamais un nom)
RÈGLE DE CRÉATION Qui a le droit de créer
Sur quelle pièce justificative
Champs obligatoires : ....................
Recherche préalable obligatoire : oui / non
RÈGLE DE MODIFICATION Qui modifie quoi
Champs jamais modifiables : ..............
Modification soumise à validation : ......
CONTRÔLE Quel test détecte l'anomalie
À quelle fréquence · qui le lit
Que fait-on quand il sort quelque chose
Rédigée par ... le ... — Revue le ...
Une dizaine de ces fiches couvre l'essentiel : client, article, unités, tarif, adresse de livraison, fournisseur, emplacement, mode de paiement, taxe, commercial. Elles se rédigent en deux séances et servent ensuite de matière de cadrage avec n'importe quel éditeur.
Le rythme : une donnée vivante ou une donnée morte
Un référentiel nettoyé une fois se dégrade dès la semaine suivante. Ce qui le maintient n'est pas la bonne volonté, c'est un calendrier court et des contrôles qui tournent tout seuls.
Chaque semaine — les fiches créées depuis sept jours, relues par le propriétaire. Cinq minutes, et le contrôle le plus rentable de tous : il attrape le doublon avant qu'il ne porte de l'historique.
Chaque mois — les articles sans poids, sans conversion ou sans famille ; les clients sans identification ; les conditions arrivées à échéance.
Chaque trimestre — tarifs et remises en vigueur, relus par la direction commerciale. Ce qui n'est pas reconduit explicitement s'éteint.
Chaque année — les statuts : qui est encore actif, quel article est en fin de vie.
Un contrôle qui ne sort rien pendant trois mois n'est pas rassurant. C'est le plus souvent que plus personne ne le lit.
Ce que nous n'allons pas vous vendre
Nous éditons des logiciels de gestion. Nous devrions donc écrire ici qu'un outil résout ces problèmes.
Il ne les résout pas. Il les rend visibles — c'est déjà beaucoup — mais il appliquera fidèlement une conversion d'unité fausse et facturera consciencieusement une remise en double. Les contrôles automatiques ne valent que par les règles que vous aurez écrites, et ces règles, aucun éditeur ne peut les décider à votre place : elles engagent votre politique commerciale et vos arbitrages financiers.
Il existe même des cas où le référentiel remis en ordre suffit pour un temps. Catalogue restreint, une trentaine de clients, un tableur tenu par quelqu'un de rigoureux : cette entreprise ne gagnera rien à s'informatiser cette année. Ce qu'elle gagnera, c'est de pouvoir le faire proprement le jour où elle en aura besoin.
Ce chantier n'est donc pas une étape de projet. Il rapporte tout de suite — moins de litiges, un recouvrement plus net, des statistiques exploitables — et ce qu'il rapporte reste acquis si vous reportez, si vous changez d'éditeur, ou si vous renoncez.
Check-list avant de consulter un éditeur
☐ La définition de « un client » est écrite et arbitrée (entité facturable, groupe, prospect, passage)
☐ Une clé d'identification obligatoire est retenue ; la recherche avant création est une règle écrite
☐ Le droit de créer un client ou un article est limité à des fonctions nommées
☐ Les doublons ont été rapprochés sur clé, tranchés par un humain, la fiche survivante désignée
☐ Les articles actifs sur vingt-quatre mois sont identifiés ; le sort des inactifs est décidé
☐ Unités de stock, d'achat et de vente renseignées, conversions vérifiées dans le bon sens
☐ Poids et dimensions présents partout où une règle en dépend
☐ Le suivi par lot, date ou numéro de série est tranché article par article
☐ Les statuts permettent de retirer un article sans le supprimer
☐ La codification est non parlante, non réutilisable ; l'ancien code vit dans le référentiel
☐ Grilles, remises, conditions de paiement et plafonds d'encours sont écrits, avec une date de fin
☐ La règle « remise sur ligne ou en pied » est tranchée
☐ Chaque donnée structurante a sa fiche et un propriétaire exprimé en fonction
☐ Les données à double propriétaire ont été attribuées, pas partagées
☐ Les quatre contrôles périodiques sont planifiés, avec un lecteur nommé
☐ L'état de départ est mesuré : nombre de fiches, complétude des attributs qui commandent
Le Solution Navigator situe l'état de votre référentiel parmi les facteurs qui pèsent sur un projet — périmètre concerné, niveau de préparation, décisions encore ouvertes. Il aide à savoir où vous en êtes avant de parler d'outil.
