Le fichier clients à jour avec l'IA : une tâche à étapes

Un client annonce par email que les prochaines factures doivent partir à une nouvelle adresse. Quelqu’un corrige le tableur. Le logiciel de facturation garde l’ancienne valeur. Au prochain envoi, il faut retrouver le message et recommencer.

L’IA peut aider à tenir le fichier clients à jour en préparant les changements depuis les messages reçus. Le passage au tableur puis à la facturation demande toutefois des règles précises : retrouver le bon client, montrer ce qui va changer, faire valider, écrire dans le bon outil et relire le résultat. Une connexion entre logiciels ne remplace aucune de ces étapes.

Voici un circuit à examiner avant de donner à un agent le droit de modifier vos fiches.

Choisir où se trouve la bonne version

Commencez par une décision très terre à terre : quel outil fait foi pour chaque information ? Si votre logiciel de facturation porte l’adresse de facturation, le tableur ne devrait pas devenir une seconde référence que chacun corrige de son côté.

Dans ce circuit, le tableur sert plutôt de liste des changements en attente. Il rassemble les propositions et leur état. La fiche validée reste dans l’outil désigné. Si vous utilisez déjà un CRM, vérifiez si cette liste peut y vivre : ajouter un fichier n’est pas une obligation.

Distinguez aussi les champs. Une adresse de chantier n’est pas une adresse de facturation. La personne qui suit la commande n’est pas forcément celle qui reçoit les factures. « Nous avons déménagé » ne précise pas toujours lequel de ces éléments doit changer.

Le traitement des demandes clients dispersées répond à une autre question : que faut-il prendre en charge ? Ici, il s’agit de modifier une donnée durable, qui pourra servir à de nombreuses opérations futures.

Extraire une proposition, sans compléter au jugé

L’agent peut être conçu pour lire un dossier de messagerie réservé aux changements de coordonnées, plutôt que toute la boîte. Il repère les informations explicitement annoncées et prépare une ligne de contrôle.

Cette ligne devrait contenir :

• l’identifiant de la fiche pressentie et le nom du client ;
• le champ concerné, sa valeur actuelle et la valeur proposée ;
• la référence du message source, sa date et la date d’effet demandée ;
• les points incertains et le nom de la personne chargée de valider ;
• l’état du traitement : à vérifier, approuvé, appliqué ou en erreur.

Une information absente reste absente. L’IA ne doit pas déduire un numéro de téléphone d’une signature ancienne, inventer un code postal ou transformer une adresse de livraison en adresse de facturation. Elle doit pouvoir produire « à confirmer » plutôt qu’une fiche apparemment complète.

Le message reçu reste une donnée à examiner. Une phrase lui demandant d’ignorer les contrôles, d’exporter les contacts ou de modifier d’autres fiches ne doit pas devenir une instruction pour l’agent. Les opérations autorisées se définissent hors de la messagerie.

Retrouver le client sans fusionner les homonymes

Un nom ressemblant ou un domaine email commun suffit à suggérer une fiche, pas à prouver qu’il s’agit de la bonne. Une entreprise peut avoir plusieurs établissements. Une adresse générique peut être partagée. Et l’adresse que l’on cherche à remplacer n’est pas un identifiant stable.

Prévoyez une correspondance avec le numéro client du logiciel, vérifiée lors de la mise en place. S’il reste plusieurs fiches possibles, l’agent s’arrête sur une proposition à examiner. Il ne crée pas un nouveau client pour contourner l’incertitude.

Pour les doublons exacts d’un tableur, une fonction ordinaire peut suffire. Microsoft distingue clairement le filtrage, qui masque les doublons, de leur suppression, qui les retire, et recommande de vérifier les résultats avant de supprimer. L’IA n’est pas nécessaire pour chaque étape du nettoyage.

Fusionner deux fiches métier est plus délicat : elles peuvent porter des commandes, des factures ou des interlocuteurs différents. Gardez cette opération hors du premier périmètre d’automatisation.

Faire valider le changement, pas tout le fichier

Prenons un exemple fictif. Une PME reçoit ce message : « Dès le mois prochain, merci d’envoyer les factures à notre nouvelle adresse email. L’adresse postale ne change pas. »

La proposition de l’agent doit montrer une modification du destinataire email des factures, avec sa date d’effet. Elle ne doit ni remplacer le contact commercial ni retoucher l’adresse postale. La personne qui valide voit l’ancienne valeur, la nouvelle et le message d’origine, côte à côte.

L’identité de l’expéditeur demande un contrôle adapté au risque. Pour un changement sensible, utilisez un canal déjà connu du client, pas uniquement les nouvelles coordonnées fournies dans le message. Dans un premier circuit, excluez notamment les coordonnées bancaires, les changements d’entité facturée et les fusions de comptes : ils méritent une procédure distincte.

Au moment d’appliquer une proposition approuvée, relisez aussi la valeur actuelle. Si un collègue l’a modifiée entre-temps, la proposition doit revenir en contrôle. Sinon, l’agent risque d’écraser une correction plus récente avec une validation devenue obsolète.

Écrire dans la facturation et relire le résultat

Le passage du tableur au logiciel dépend des possibilités réelles de ce dernier : import contrôlé, interface de programmation ou saisie manuelle. Avant de promettre une synchronisation, vérifiez les champs accessibles, les droits nécessaires et le comportement d’une mise à jour sur une fiche existante.

Pour un import, préparez uniquement les lignes approuvées et les colonnes autorisées. Un export complet envoyé à chaque passage augmente le risque d’écraser des valeurs sans rapport avec la demande. Testez d’abord sur des données fictives dans un environnement prévu pour cela.

Après l’écriture, le système doit relire la fiche destinataire et comparer le champ modifié à la valeur approuvée. Une requête acceptée ou un fichier importé ne prouve pas, à lui seul, que le bon client a été corrigé.

Le journal conserve alors l’identifiant du changement, sa source, la validation, les valeurs avant et après, ainsi que le résultat de la relecture. Limitez son contenu aux données utiles et son accès aux personnes concernées. Ce journal est lui aussi un fichier à protéger.

Enfin, vérifiez séparément ce que le logiciel fait des documents déjà créés. Mettre à jour une fiche ne signifie pas corriger une facture émise. Le circuit décrit ici ne doit ni réécrire ces pièces ni envoyer de facture. Ces actions relèvent d’un processus de facturation distinct.

Prévoir la panne au milieu du parcours

Le cas gênant n’est pas seulement « rien ne fonctionne ». C’est « la fiche a peut-être changé, mais la confirmation s’est perdue ».

Chaque demande doit avoir un identifiant conservé pendant tout le traitement. Si le même message est relu ou si la connexion coupe après l’écriture, la reprise commence par vérifier cet identifiant et la fiche destinataire. Elle ne relance pas aveuglément une création ou un import.

Demandez une démonstration sur ces situations :

• le même message est traité une seconde fois ;
• le logiciel est indisponible au moment d’écrire ;
• deux messages donnent des coordonnées contradictoires ;
• une personne corrige la fiche pendant que la proposition attend ;
• une modification approuvée s’avère finalement erronée.

Dans le dernier cas, il faut pouvoir retrouver l’ancienne valeur et proposer une correction contrôlée. Restaurer tout le fichier clients depuis une sauvegarde pourrait effacer d’autres mises à jour légitimes. Le retour en arrière doit porter sur le changement concerné, en tenant compte de ce qui s’est passé depuis.

Commencer avec peu de données et des droits limités

En Suisse, le PFPDT rappelle que la LPD s’applique aussi aux traitements utilisant l’IA. Il précise également que la responsabilité reste à l’entreprise lorsqu’elle confie le traitement à un sous-traitant.

Avant de connecter une messagerie ou un fichier clients, clarifiez donc quelles données sont transmises au fournisseur, à quelles fins, où elles sont traitées, combien de temps elles sont conservées et qui peut y accéder. Vérifiez le cadre contractuel et les éventuelles communications à l’étranger. Un abonnement professionnel ne répond pas automatiquement à ces questions.

Pour un premier essai, choisissez un seul type de changement, sur des données fictives. Passez ensuite à un lot limité et autorisé, avec validation humaine de chaque proposition. Mesurez les erreurs d’association, les champs mal interprétés, les reprises nécessaires et le temps de contrôle. Tant que ces résultats ne sont pas acceptables, n’élargissez pas les droits de l’agent.

Si vous voulez examiner ce parcours dans vos outils, vous pouvez décrire la tâche lors d’un appel de quinze minutes, sans transmettre de fichier clients.

Le résultat attendu est simple à vérifier : pour chaque modification, quelqu’un doit pouvoir dire de quel message elle vient, qui l’a approuvée et ce qui figure réellement dans le logiciel de facturation.