Collecter des données paraît simple : une colonne de plus, une question de plus. Le problème arrive après. Corriger des données mal collectées coûte bien plus que corriger une règle mal écrite, car une règle réside à un endroit tandis que les données s'accumulent partout.
Cette leçon prend le sol sur lequel l'automatisation se construit : les données client. Dans la leçon précédente, vous avez vu qu'une grande part des pannes sort du côté de l'entrée. Ici, nous montons ce côté correctement dès le départ, c'est à dire quels champs sont collectés, comment ils s'écrivent et où ils vivent.
Quand les données sont mal collectées, le problème ne se voit pas tout de suite. Il sort des mois plus tard, en bloc, et réclame un nettoyage en arrière. Le but de cette leçon est que vous montiez l'ordre qui rend ce nettoyage inutile dès le départ.
Aucun prérequis, même si avoir sous la main la carte de processus de la première leçon aide à voir quel champ sert vraiment.
Une automatisation travaille avec les données qui lui parviennent. Aussi juste que soit la règle écrite, si la donnée entrante est cassée, le résultat sortant l'est aussi. C'est pourquoi la collecte de données n'est pas une partie de l'automatisation mais le sol sur lequel elle repose.
Le coût d'une donnée cassée grandit avec le temps. Si une fiche entre de travers la première semaine, la corriger prend un instant. Si la même faute dure un an, la corriger réclame de passer en revue toutes les fiches, et ce travail reste souvent en plan tandis que la confiance dans les données baisse.
Quand un champ entre de travers, tous les flux qui tournent sur ce champ sont touchés. Message, rapport, facture et relance puisent à la même source.
Quand un champ obligatoire arrive vide, le flux s'arrête ou saute cette étape en silence. Le second cas est le plus dangereux, parce que personne ne le remarque.
Si la même information se trouve à trois endroits sous trois formes, laquelle est juste reste discutable. Aucun rapport ne sort, et celui qui sort ne sera pas fiable.
Tout l'ordre des données repose sur trois règles. Là où ces trois tiennent, le reste du détail reste gérable ; là où elles ne tiennent pas, changer d'outil ne sauve rien.
Un client veut être une seule ligne dans le système. Quand la même personne est ouverte deux fois, l'historique se coupe, quelle fiche est à jour devient flou, et les messages partent deux fois.
La même information veut s'écrire pareil partout. Pour le téléphone, la date, le nom de ville et la monnaie, une seule écriture est choisie et appliquée à chaque point de saisie.
Chaque champ veut un seul endroit juste. Si la même information est tenue dans deux systèmes, on écrit lequel est mis à jour, et l'autre puise dedans.
Les trois règles se tiennent l'une l'autre. Sans une forme, le dédoublonnage ne marche pas, parce que la même personne ressemble à deux personnes sous deux écritures. Sans une source, une ligne ne se conserve pas non plus, parce que chaque système met à jour sa propre copie.
La mesure dans le choix des champs est l'usage, pas la curiosité. Avant de collecter un champ, demandez : dans quelle tâche, à quelle étape cette information servira t elle ? Les champs sans réponse ne sont pas collectés. Les champs collectés au cas où restent en général vides, et là où ils ne restent pas vides, ils deviennent peu fiables.
Chaque champ collecté apporte une charge : il faut le remplir, le valider, le tenir à jour, et le conserver crée une responsabilité. C'est pourquoi la liste des champs reste courte et s'allonge selon le besoin.
La dernière question compte. Des champs comme l'identité, la santé ou les finances ne se collectent que là où ils servent vraiment ; ailleurs, les laisser de côté peut alléger la responsabilité comme la charge d'entretien.
Le dictionnaire de champs est la liste où chaque champ collecté est défini en un seul endroit. Son but est d'empêcher qu'un même champ signifie deux choses pour deux personnes. Si les uns écrivent le nom complet et les autres seulement le prénom dans nom du client, ce champ ne mesure plus une seule chose.
Le dictionnaire n'est pas un document technique. Un tableau ou une page suffit. Ce qui compte, c'est que chaque champ soit défini sous six rubriques et que cette définition soit ouverte à tous ceux qui saisissent.
Pour les champs à liste de choix, écrivez aussi les choix. Là où du texte libre reste, la même chose s'écrit de dix façons et le champ devient impossible à exploiter.
La règle d'une forme ne s'applique qu'une fois la forme écrite. Pour que la même écriture serve à chaque point de saisie, on décide d'abord laquelle et on l'intègre au dictionnaire avec un exemple.
Les décisions de forme paraissent petites, pourtant la plupart des pannes silencieuses en sortent. Des détails comme le zéro initial d'un numéro, l'ordre du jour et du mois dans une date, ou une ville écrite en majuscules, cassent le rapprochement.
Laissez la forme au formulaire plutôt qu'à la personne. Une liste de choix, un sélecteur de date et un champ masqué peuvent bloquer l'écart dès la saisie ; cela revient moins cher que de nettoyer ensuite.
Pour appliquer la règle d'une ligne, il faut une clé qui réponde à la question : ces deux fiches sont elles la même personne ? La clé est un champ qui sépare la personne des autres et ne change pas avec le temps.
Une bonne clé se suffit. Si aucune ne se trouve, deux champs se combinent. Le nom et le prénom seuls ne font pas une clé, parce que le même nom peut appartenir à plusieurs personnes et que son écriture bouge.
Numéro de téléphone, adresse courriel, numéro client, numéro fiscal ou d'identité. Celui qui, dans votre entreprise, est rempli chez chaque client est le candidat.
Elle doit être remplie chez chaque client, être unique, ne pas changer avec le temps et s'écrire sous une seule forme. Le champ qui réunit ces quatre traits est la clé.
Quand une deuxième fiche arrive avec la même clé, le système met à jour la fiche existante au lieu d'en ouvrir une nouvelle et inscrit les champs touchés dans l'historique.
Décidez ici aussi de ce qui se passe quand le même client écrit par deux canaux. Si le canal est tenu dans un champ à part, le client reste une ligne et l'historique ne se coupe pas.
L'endroit le moins cher pour la propreté est le point de saisie. Corriger un champ après qu'il est entré de travers coûte plus cher que de le bloquer à la saisie. C'est pourquoi la validation passe dans le formulaire.
La validation travaille sur deux couches : validation de forme et validation de sens. La forme sonde que l'écriture suit la règle ; le sens, que la valeur est plausible. Avec les deux, le nombre de fiches à nettoyer ensuite baisse fortement.
Si la même information se trouve à plusieurs endroits, il faut écrire laquelle compte comme juste. Sans cette décision, chaque système met à jour sa propre copie et au bout d'un moment laquelle est à jour reste inconnu.
Une source unique ne veut pas dire que l'information se trouve à un seul endroit. Cela veut dire qu'elle est mise à jour à un seul endroit et coule de là vers les autres. Les copies se lisent, elles ne se mettent pas à jour.
Cette décision tient dans un tableau et se range à côté du dictionnaire de champs. Quand elle n'est pas écrite, la discussion se refait de zéro chaque fois.
Les données ne se nettoient pas une fois pour être laissées ensuite. Les gens déménagent, changent de numéro, les noms d'entreprise changent. C'est pourquoi le nettoyage n'est pas un projet mais un travail d'entretien petit et régulier.
L'entretien peut être confié à l'automatisation elle même. Un contrôle simple qui liste les champs obligatoires restés vides, avertit quand deux fiches s'ouvrent sous la même clé et marque les valeurs hors forme suffit dans la plupart des entreprises.
Collecter des données client n'est pas seulement une décision technique. Le client veut être informé de ce qui est collecté, de l'usage prévu et de la durée de conservation. Cette leçon ne donne pas de conseil juridique ; son but est de vous aider à placer le sujet dans le processus.
En pratique, trois choses facilitent le travail : la finalité de collecte écrite, la trace dans la fiche de l'endroit et de la manière dont le consentement a été recueilli, et la durée de conservation décidée d'avance. Les trois peuvent se ranger à côté du dictionnaire de champs.
Les détails peuvent varier selon le pays et le secteur. Limiter le nombre de champs collectés à ceux qui servent vraiment peut alléger aussi la charge de cette rubrique.
Déroulons la méthode sur un seul formulaire, d'un bout à l'autre. L'exemple passe par le formulaire de demande d'une entreprise de services.
Choix des champs : l'entreprise pense mettre sept champs dans le formulaire. Pour chaque champ, la question à quelle étape sera t il lu est posée. La date de naissance et la profession se révèlent lues dans aucun flux et sortent de la liste. Restent : nom, téléphone, courriel, quartier, objet de la demande et description.
Dictionnaire de champs : chaque champ est défini sous six rubriques. L'objet de la demande cesse d'être du texte libre et devient une liste de choix, parce qu'il faut en rendre compte.
Forme : une seule écriture est choisie pour le téléphone et un champ masqué entre dans le formulaire. Le quartier vient d'une liste de choix. Nom et prénom tiennent dans un champ et sont corrigés en initiales majuscules.
Clé : le numéro de téléphone est choisi comme clé, parce qu'il est rempli à chaque demande et tenu sous une seule forme. Quand une deuxième demande arrive du même numéro, aucune fiche nouvelle ne s'ouvre et la demande s'ajoute à la fiche existante.
Validation : le formulaire ne part pas tant que des champs obligatoires sont vides. Si le numéro est déjà enregistré, le client existant s'affiche à l'écran.
Source unique : un seul système est choisi comme source des informations client. Les autres écrans y lisent, et la mise à jour se fait uniquement à la source.
Entretien : un contrôle simple qui tourne une fois par semaine liste les fiches à champ obligatoire vide et les paires ouvertes sous la même clé.
Le rendement de cette leçon vient de la construction de votre propre dictionnaire de champs. C'est assez court pour tenir en une séance, et cela facilite ensuite chaque décision d'automatisation.
La liste du dernier point est la photographie de votre ordre de données aujourd'hui. Une fois l'entretien monté, vous pouvez retirer la même liste et comparer.
Télécharger l'inventaire des données (xlsx) · quel champ, ce qu'il signifie, qui le saisit, où il réside et combien de temps il est conservé ; les règles de forme et le dédoublonnage y sont aussi.
Un champ inutilisé n'est pas rempli, et là où il l'est, son exactitude n'est pas vérifiée. Il reste un champ à la fois vide et peu fiable, tandis que la responsabilité de le conserver continue.
Tout champ laissé en texte libre se disperse avec le temps en écritures différentes. Aucun rapport ne sort et le rapprochement ne marche pas.
Là où aucune clé de dédoublonnage n'est choisie, le même client s'ouvre plusieurs fois. L'historique se coupe, les messages se répètent, et le client le remarque.
Quand le nom d'un champ change, les flux qui y sont attachés se mettent à lire en silence une valeur vide. Le changement se fait d'abord au dictionnaire, ensuite les flux sont mis à jour.
Une mise à jour faite sur la copie plutôt qu'à la source disparaît au rafraîchissement suivant. La personne voit son changement s'évanouir et se fie moins au système.
Une donnée nettoyée une fois se disperse de nouveau avec le temps. Un entretien petit et régulier tourne mieux qu'un grand projet de nettoyage repoussé.
Avant d'ouvrir un nouveau formulaire ou un nouveau champ, il vaut mieux pouvoir dire oui aux points ci dessous.
Les termes qui reviennent dans les discussions sur les données. Dès que l'équipe partage cette langue, les débats sur les champs raccourcissent.
Dans cette leçon vous avez dressé le dictionnaire de champs et décidé où vivent les données. Ce que vous tenez maintenant est une tâche mesurable, un processus écrit et des champs définis. La leçon suivante traite de l'outil avec lequel on monte.
Dans la quatrième leçon, progiciel, no-code et sur mesure sont notés selon sept critères ; le dictionnaire de champs d'ici devient le socle du critère de propriété des données.
Noter progiciel, no-code et sur mesure selon sept critères. Avec une table de comparaison téléchargeable.
Limite, étapes, points de décision et exceptions. Les champs de cette leçon sont marqués sur cette carte.
La section formation dans son ensemble et les modules ajoutés depuis.
Nous pouvons revoir ensemble si les champs que vous collectez méritent leur place. Il suffit de nous écrire.
Demander un Devis sur WhatsApp