Réponse courte. Un client entre par cinq portes, caisse, WhatsApp, boutique en ligne, application, commercial terrain, et chaque porte garde sa fiche brute datée. Le téléphone, normalisé au format international dès la saisie, est la clé qu'on cherche en premier, parce qu'il se compare, quand un nom en arabe et en français ne se compare pas. Le rapprochement cherche d'abord l'exact, puis l'approché, nom et wilaya, et donne un score ; au-dessus d'un seuil écrit la fusion est automatique, entre deux seuils c'est une suggestion qu'un humain revoit le matin, en dessous ce sont deux fiches. La fiche unique est calculée à partir des sources, jamais tapée, avec une règle de survie par champ : le téléphone vérifié l'emporte, le nom le plus complet garde l'autre écriture, les points s'additionnent, les consentements prennent le plus restrictif. Chaque fusion est journalisée et se défait en un geste, parce que les sources ne sont jamais modifiées. Six semaines, dont la première sans code.
Ce guide s'adresse au gérant d'une chaîne de magasins qui ne sait plus combien de clients il a, au fondateur installé en France dont la boutique en ligne et la caisse d'Alger se parlent mal, et au responsable qui doit réconcilier un programme de fidélité avec des fiches en double. Il ne redit pas comment on dédoublonne un ancien fichier au moment d'une migration, décrit dans le guide sur la reprise de données, ni comment les points se calculent, décrit dans le guide sur la fidélité ; il décrit ce qui se construit pour qu'un client reste unique au quotidien, porte après porte, et il prolonge notre page sur l'ingénierie logicielle.
Ce que les référentiels disent
Le téléphone est la seule clé qui se normalise, et sa forme est publique. Le plan de numérotation algérien donne au pays l'indicatif +213 et le préfixe de sortie 0 ; un numéro mobile compte « neuf chiffres » après ce 0, sous la forme « 0yxx xx xx xx » où « y est le code de l'opérateur, 5 pour Ooredoo, 6 pour Mobilis, 7 pour Djezzy » ; un numéro fixe en compte huit, avec un indicatif de zone, 021 ou 023 pour Alger, 036 pour Sétif. La norme internationale des numéros limite un numéro complet à quinze chiffres. Ce que cela impose : « 0661 23 45 67 », « +213661234567 » et « 00213 661 23 45 67 » sont le même numéro, et une fonction de normalisation qui connaît ces règles les ramène tous à +213661234567 avant toute recherche ; un numéro qui ne se normalise pas est refusé à la saisie, pas stocké tel quel.
Le nom, lui, ne se normalise pas, et c'est pour cela qu'il n'est pas la clé. Un client algérien est « Benali Karim » à la caisse quand l'employé tape en latin, « بن علي كريم » quand il tape en arabe, « Karim B. » sur WhatsApp, et la translittération d'un même nom arabe en lettres latines admet plusieurs formes ; aucun moteur ne les voit égales sans règles, et les règles se trompent. Ce que cela impose : le nom est stocké dans les deux écritures, selon le guide sur l'application bilingue, il sert à confirmer un rapprochement proposé par le téléphone ou l'e-mail, et il ne sert jamais seul à fusionner automatiquement.
Ce que nous n'avons pas trouvé : une mesure publique du taux de doublons dans les fichiers clients des entreprises en Algérie. Ce que nous voyons sur les fichiers que nous reprenons, c'est entre une fiche sur dix et une fiche sur six en double quand plusieurs portes existent depuis plus d'un an sans règle commune, et nous le disons comme une observation, pas comme une statistique. Un fichier sans doublon n'existe pas ; un fichier dont le taux de doublons est mesuré chaque mois et revu chaque matin, oui.
Un client, cinq portes d’entrée, une seule fiche
Le fichier client unique ne se comprend pas sur un schéma de base de données mais sur un client réel qui entre par cinq portes en huit mois.
En mars, Karim achète au comptoir ; Amel tape son nom en arabe et son numéro, 0661 23 45 67. En mai, il écrit sur WhatsApp depuis +213661234567 et accepte les promotions ; son prénom et une initiale. En septembre, il commande sur la boutique en ligne avec son e-mail et un numéro écrit 00213 661 23 45 67. En octobre, il installe l'application et vérifie son numéro par un code, selon le guide sur la connexion par téléphone. En novembre, le commercial terrain passe à sa supérette et l'enregistre comme « Supérette El Hidhab, Karim », avec le même numéro écrit encore autrement. Cinq fiches brutes, cinq dates, cinq façons d'écrire la même personne.
La résolution fait quatre choses, dans l'ordre : elle normalise le téléphone, le nom et l'e-mail ; elle rapproche, d'abord sur le téléphone exact, puis sur le nom et la wilaya ; elle note la confiance ; et elle décide, fusion automatique quand le téléphone normalisé est identique, suggestion quand seuls le nom et la wilaya concordent, rien en dessous. La fiche unique qui en sort porte le téléphone vérifié par le code de l'application, le nom dans les deux écritures, l'e-mail de la boutique, la wilaya et le point de vente du commercial, et les consentements donnés sur WhatsApp ; et chaque champ dit d'où il vient. Les données sont un exemple ; la règle ne l'est pas : la fiche unique est calculée, jamais tapée.
«La fiche unique est calculée à partir des sources, jamais tapée ; on corrige une source, et la fiche se recalcule.»
Six situations réelles, et ce que l'application fait
Six situations qui reviennent sur presque tous les fichiers clients, et ce que l'application fait pour chacune.
Le même numéro, trois écritures : la normalisation au format international dès la saisie les fait se retrouver ; c'est la situation la plus fréquente et la plus simple. Deux numéros, une personne : le client a changé d'opérateur ; le rapprochement par nom et wilaya est proposé à l'employé et confirmé par un code sur le nouveau numéro ; l'ancien reste en historique. Un numéro, plusieurs personnes : le téléphone du magasin ou de la famille est donné par trois acheteurs ; un numéro peut porter plusieurs personnes, la fusion automatique est refusée si les noms diffèrent, et c'est la raison pour laquelle le téléphone seul ne fusionne pas sans vérifier le nom.
Le nom en arabe et en français : les deux écritures sont stockées et cherchées, selon le guide sur la recherche, mais le rapprochement passe par le téléphone, et le nom ne sert qu'à confirmer. Le client B2B à plusieurs acheteurs : une fiche entreprise et des fiches personnes rattachées, la fidélité et le crédit sur l'entreprise, les consentements sur les personnes ; c'est la structure du portail B2B. Le client qui demande la suppression : la fiche et ses sources sont anonymisées, les factures gardées avec le seul numéro de client, l'opération journalisée et irréversible ; c'est le cas où conserver les sources ne veut pas dire les garder nominatives.
Une fusion, champ par champ, et son retour arrière
La fusion est l'opération qu'on craint le plus, et c'est pour cela qu'elle est la plus encadrée.
Deux fiches : A, créée à la caisse en mars avec quatorze achats ; B, créée sur la boutique en septembre avec trois commandes ; le téléphone normalisé est identique, le score est de 0,96, la fusion est proposée et Amel la confirme depuis la caisse. Une règle par champ : le téléphone vérifié par code l'emporte ; le nom le plus complet l'emporte et l'autre écriture est gardée ; l'e-mail présent l'emporte ; l'adresse la plus récente l'emporte et l'autre est gardée ; les points de fidélité s'additionnent ; les consentements prennent le plus restrictif par canal, parce qu'un client qui a refusé les SMS sur une fiche les a refusés tout court.
Rien n'est écrasé : la fiche fusionnée pointe vers ses deux sources, conservées telles quelles avec leur historique, et la ligne de journal dit qui a fusionné, quand, avec quel score et par quelle règle, selon le guide sur le journal d'audit. La défusion se fait en un geste, parce que les sources n'ont jamais été modifiées : on retire le lien, et les deux fiches reprennent leur vie. C'est cette réversibilité qui autorise la fusion automatique au-dessus du seuil ; sans elle, chaque fusion serait une décision irréversible qu'aucun gérant ne déléguerait à une règle.
«Une fusion n'écrase rien : les sources sont conservées, le journal dit qui et pourquoi, et la défusion se fait en un geste.»
Un fichier client unique, en cinq couches
Derrière ces fusions, cinq couches, et celle qui décide combien de clients vous avez.
Les portes d'entrée : caisse, WhatsApp, boutique, application, commerciaux, import d'un ancien fichier ; chacune produit une fiche brute datée et signée, et rien n'est écrit directement dans la fiche unique. La normalisation : téléphone au format international, nom en deux écritures, e-mail en minuscules, wilaya depuis une liste, adresse structurée ; faite à la saisie et refaite à chaque import, et la règle vit dans le code, pas dans la tête d'un employé. Le rapprochement : clé exacte d'abord, approché ensuite, un score et trois décisions ; avec un seul seuil et une fusion toujours automatique, on fusionne des gens différents qui partagent un téléphone ; sans seuil, on garde trois fiches par client ; deux seuils écrits et une file de suggestions revue le matin tiennent entre les deux.
La fiche unique : calculée à partir des sources conservées avec une règle de survie par champ ; fusion et défusion journalisées ; une fiche entreprise pour le B2B ; on corrige une source, et la fiche se recalcule. Les usages : fidélité et crédit sur la bonne fiche, messages envoyés une fois avec le consentement du bon canal selon le guide sur les notifications, historique complet au comptoir et dans l'agent WhatsApp, segments pour les campagnes ; c'est la raison de tout le reste, un client qui reçoit la promo une fois et dont le vendeur voit tout.
Quand un client se présente à une porte
Le fichier reste unique parce que chaque porte fait les mêmes six gestes, dans le même ordre.
Demander le téléphone d'abord, parce que c'est le seul champ qui identifie ; le nom vient après, et il ne sert qu'à confirmer. Normaliser au format international avant toute recherche. Chercher, exact sur le téléphone, puis approché sur le nom et la wilaya ; c'est l'étape que les applications à trois fiches par client sautent, parce qu'elles créent d'abord et cherchent jamais. Proposer la fiche trouvée, confirmée par l'employé qui voit le nom et le dernier achat, ou par un code envoyé sur le téléphone quand c'est le client lui-même qui se présente, sur la boutique ou l'application.
Créer seulement si rien : une fiche brute datée, signée par la porte et l'employé, qui entrera dans la résolution comme les autres. Journaliser la source : qui, quand, par quelle porte ; la fiche unique se recalcule. La caisse fait ces six gestes en trois secondes et sans réseau, selon le guide sur la caisse ; la boutique les fait à la création du compte ; le commercial terrain les fait sur sa tablette dans l'application de tournée, et la résolution rattrape au retour du réseau ce qui n'a pas pu être rapproché sur place.
Vu ailleurs : le plan de numérotation et la pratique des grands fichiers, et ce qui se transpose
Deux sources disent l'essentiel. Le plan de numérotation algérien dit la forme exacte d'un numéro, neuf chiffres mobiles après le 0, huit fixes avec un indicatif de zone, et la norme internationale dit sa longueur maximale ; ce qui se transpose, c'est une normalisation écrite dans le code qui ramène toutes les écritures à une seule et refuse ce qui ne s'y plie pas. La pratique des grands fichiers clients, chez les opérateurs et les banques, sépare toujours les enregistrements sources d'une fiche de référence calculée, avec des règles de survie par champ et un journal ; ce qui se transpose, c'est que la fiche n'est jamais tapée, et que la fusion se défait.
Ce que ces sources ne disent pas : vos seuils, vos règles de survie, et qui revoit les suggestions le matin ; la première semaine du projet y répond, et c'est le gérant qui signe la liste des portes et des règles.
Les règles d'un fichier client qui reste unique
Six règles, écrites la première semaine. Le téléphone normalisé est la clé, cherchée avant de créer. Chaque porte garde sa fiche brute datée ; rien n'est écrit directement dans la fiche unique. Deux seuils : fusion automatique au-dessus, suggestion entre, rien en dessous. Une règle de survie par champ, écrite, et les consentements prennent le plus restrictif. Toute fusion est journalisée et réversible, parce que les sources ne sont jamais modifiées. La file de suggestions est revue chaque matin, et le taux de doublons est mesuré chaque mois.
Une septième règle porte sur le devis : « gestion des clients et dédoublonnage » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « liste des portes d'entrée avec fiche brute datée et signée ; normalisation du téléphone au format international, du nom en deux écritures et de l'e-mail à la saisie et à l'import ; rapprochement exact puis approché avec score et deux seuils écrits ; fiche unique calculée avec règles de survie par champ ; fusion et défusion journalisées, sources conservées ; fiche entreprise pour le B2B ; consentements par canal ; anonymisation sur demande avec factures conservées ; file de suggestions et taux de doublons mensuel dans la supervision », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui écrit « détection des doublons » sans dire ce qui se passe quand on en trouve un a prévu une alerte, pas une fiche unique.
Six entreprises, et la porte qui créait les doublons
Six entreprises que nous équipons souvent, et pour chacune la porte qui créait le plus de doublons et ce qui l'a réglé.
- La chaîne de magasins, décrite dans le guide sur la caisse. Chaque caisse créait sa fiche ; le téléphone demandé d'abord et normalisé a réuni trois fiches par client fidèle en une.
- Le programme de fidélité, décrit dans le guide dédié. Les points étaient éparpillés sur des fiches en double ; l'addition à la fusion les a rendus au client, et la réclamation au comptoir a cessé.
- Le grossiste et son portail, décrit dans le guide dédié. Le gérant, son fils et l'employé de la supérette commandaient chacun avec leur téléphone ; la fiche entreprise a rattaché les trois.
- Le commerce piloté depuis la France, décrit dans le guide dédié. La boutique en ligne et la caisse d'Alger avaient chacune leur fichier ; le fondateur voit désormais un client, son historique en ligne et au comptoir, sur son tableau de bord.
- Les commerciaux terrain, décrits dans le guide dédié. Chaque tournée créait des fiches « Supérette X, Karim » ; la recherche avant création sur la tablette, et la résolution au retour du réseau, ont arrêté la fuite.
- La salle de sport, décrite dans le guide dédié. Un abonné réinscrit chaque année sous une nouvelle fiche ; le téléphone vérifié par code à l'inscription a rendu l'historique des abonnements.
Le calendrier 2027
Le calendrier est celui d'un fichier client rendu unique en six semaines, dont la première sans code.
La semaine 0 à 1 écrit les portes et les règles : la liste des portes d'entrée, le téléphone comme clé, les règles de normalisation, les deux seuils, les règles de survie par champ ; signées par le gérant, parce qu'une fusion faite avec les mauvaises règles se défait difficilement à grande échelle. La semaine 1 à 2 met la normalisation à la saisie sur toutes les portes et normalise l'ancien fichier, dont le taux de doublons est mesuré pour la première fois. La semaine 2 à 3 construit le rapprochement : exact puis approché, score, fusion automatique au-dessus du seuil, file de suggestions pour le reste.
La semaine 3 à 4 construit la fiche unique : règles de survie, sources conservées, fusion et défusion journalisées, fiche entreprise pour le B2B. La semaine 4 à 5 branche les usages : fidélité, consentements par canal, historique au comptoir et sur WhatsApp, segments, et les premières campagnes envoyées une fois. La semaine 5 à 6 installe la revue du matin, la file de suggestions revue par une personne, et le taux de doublons mesuré chaque mois ; elle ne s'arrête plus. Chaque lot est démontré comme le guide sur la livraison le décrit, et la reprise de l'ancien fichier suit le guide dédié.
Ce qui fait échouer un fichier client unique
Les fichiers que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Le nom comme clé. Deux écritures, trois translittérations, et aucun rapprochement ne tient.
- Créer avant de chercher. Chaque porte crée sa fiche ; personne ne cherche d'abord.
- Le téléphone stocké tel quel. 0661, +213 et 00213 sont trois clients.
- Une seule règle : fusionner. Le téléphone du magasin fusionne trois acheteurs en un.
- La fusion qui écrase. Les sources sont perdues ; une erreur de fusion est irréversible.
- Des consentements qui s'additionnent. Le client qui a refusé les SMS sur une fiche les reçoit par l'autre.
- Personne ne revoit les suggestions. La file grossit, puis on l'ignore, puis les doublons reviennent.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Pourquoi le même client existe-t-il plusieurs fois dans notre application ?
- Parce qu'il entre par plusieurs portes, caisse, WhatsApp, boutique en ligne, application, commerciaux, et qu'aucune règle ne dit qu'il s'agit de la même personne : le nom est écrit différemment, le téléphone aussi, et chaque porte crée sa fiche sans chercher d'abord. La solution est une architecture, pas une discipline de saisie : le téléphone normalisé comme clé, une recherche avant toute création, et une résolution qui rapproche les fiches brutes.
- Pourquoi le téléphone et pas le nom ?
- Parce que le téléphone se normalise et se compare : le plan de numérotation dit sa forme exacte, et 0661…, +213661… et 00213 661… deviennent le même numéro. Le nom ne se compare pas d'une écriture à l'autre, « بن علي كريم » et « Karim Benali » ne sont égaux pour aucun moteur sans règles qui se trompent. Le nom sert à confirmer un rapprochement, jamais à fusionner seul.
- Que se passe-t-il si deux personnes partagent le même numéro ?
- Un numéro peut porter plusieurs personnes, le téléphone du magasin ou de la famille par exemple. La fusion automatique est refusée si les noms diffèrent, et chaque personne garde sa fiche, rattachées au même numéro. C'est pour cela que le téléphone identique ne suffit pas seul à fusionner : la règle vérifie aussi le nom, et en cas de doute, propose au lieu de décider.
- Une fusion peut-elle être annulée ?
- Oui, en un geste, parce que les deux fiches sources ne sont jamais modifiées : la fiche fusionnée pointe vers elles, et la défusion retire le lien. Chaque fusion est journalisée avec qui, quand, le score et la règle. C'est cette réversibilité qui permet d'autoriser la fusion automatique au-dessus d'un seuil ; sans elle, aucune fusion ne pourrait être déléguée à une règle.
- Que deviennent les consentements et les points lors d’une fusion ?
- Chaque champ a sa règle de survie, écrite la première semaine : les points de fidélité s'additionnent ; les consentements prennent le plus restrictif par canal, un client qui a refusé les SMS sur une fiche les a refusés tout court ; le téléphone vérifié par code l'emporte ; le nom le plus complet l'emporte et l'autre écriture est gardée ; l'adresse la plus récente l'emporte et l'autre est conservée.
- Combien de temps pour rendre un fichier client unique ?
- Six semaines : une pour écrire les portes, la clé, les seuils et les règles de survie, une pour la normalisation et la mesure de l'ancien fichier, une pour le rapprochement et le score, une pour la fiche unique et la fusion, une pour les usages, une pour installer la revue du matin. La première semaine est sans code, et c'est elle qui évite les fusions qu'on regrette.