Blog

Quand client et équipe voient deux réalités

Repérer la friction cachée entre expérience client et travail interne avant de lancer un grand programme de transformation.

Petite équipe décidant autour de notes et d’échantillons dans une salle simple

Une entreprise peut avoir des commandes à l’heure, un tableau de bord au vert et perdre malgré tout de l’argent en silence. Le symptôme n’est presque jamais une erreur spectaculaire. C’est plutôt une série de petites frictions : un appel pour confirmer quelque chose qui était soi-disant “déjà fait”, un e-mail interne pour corriger une adresse, une exception traitée de mémoire au lieu d’être gérée par une règle commune.

Quand le tableau de bord dit que tout va bien, il faut se demander qui fait le travail invisible pour que cela paraisse vrai.

La thèse est simple : beaucoup d’opérations ne se cassent pas par manque de technologie, mais parce que la réalité du client et la réalité interne de l’entreprise se désalignent. Le problème n’est pas l’existence d’exceptions. Le problème, c’est que chaque équipe mesure autre chose, récompense autre chose et finit par masquer le coût des raccourcis.

La commande qui semblait correcte et a quand même mal tourné

Imaginez une entreprise de taille moyenne qui vend un produit physique avec un service associé. La commande est saisie, préparée, expédiée et livrée. Dans l’ERP, elle paraît terminée. Dans la vue de direction, aucun incident. Pourtant, le service client continue de recevoir des messages parce que le client attendait une autre date d’installation, qu’un accessoire manquait ou que la facture ne correspondait pas à l’accord.

Ce schéma est courant. La friction apparaît souvent dans les espaces vides entre services : la vente promet, les opérations interprètent, l’entrepôt emballe, la logistique livre et l’après-vente explique. Chaque équipe peut faire sa part correctement. Le client, lui, vit un seul parcours.

Ce que le tableau de bord cache, c’est l’accumulation de micro-décisions. Une commande est-elle “livrée” quand elle sort de l’entrepôt ou quand le client peut l’utiliser ? Un incident compte-t-il seulement s’il entre dans un outil de ticketing, ou aussi s’il est réglé par WhatsApp ? Quel travail reste invisible parce que l’équipe a appris qu’enregistrer prend plus de temps que corriger ?

Les incitations qui poussent aux contournements

La plupart des contournements ne viennent pas d’une mauvaise intention. Ils viennent d’incitations mal alignées.

Si la vente est jugée sur la signature, elle aura tendance à promettre trop. Si les opérations sont jugées sur la vitesse, elles pousseront la commande même quand il manque des informations. Si le service client est mesuré sur les dossiers clos, il cherchera une résolution rapide même si la cause racine demeure.

Voici la tension inconfortable : les entreprises récompensent souvent le progrès local et punissent la friction globale. On célèbre le fait que la commande “avance”, mais personne ne demande combien de corrections ont été nécessaires pour qu’elle avance. On récompense la vitesse visible et on sous-estime le travail de coordination, moins spectaculaire mais bien plus coûteux en cas d’échec.

Un signal utile n’est pas seulement le nombre de commandes expédiées. C’est le nombre d’interventions manuelles entre équipes. Un autre est le délai entre le moment où quelqu’un repère une exception et celui où il devient clair qui la prend en charge. Si cette prise en charge dépend d’appels, de faveurs ou de mémoire, le processus vit encore dans les personnes, pas dans les accords.

Petit cas: moins d’automatisation, plus de clarté

Un distributeur de taille moyenne, sous pression saisonnière, a repéré un motif étrange. Les tickets n’augmentaient pas à cause du volume brut, mais à cause de commandes “presque bonnes” : une référence manquante, une adresse incomplète ou une date de livraison promise sans trace dans le flux interne. L’équipe avait normalisé le fait de corriger par téléphone avant de déclarer l’incident.

Le premier réflexe aurait pu être d’automatiser davantage de contrôles. Mais le vrai problème n’était pas seulement la saisie de données. C’était le contrat opérationnel.

Pendant deux semaines, l’équipe a mené un test réversible : chaque exception pertinente était notée manuellement dans un document commun avec trois champs très simples — ce qui manquait, qui l’avait détectée et qui l’avait résolue. Aucun chantier ERP, aucun grand projet. Juste de la visibilité sur le coût de la friction.

Le résultat n’a rien eu de spectaculaire, mais il a été utile. Trois causes dominantes sont apparues : des promesses commerciales faites sans contexte, des champs obligatoires que personne ne comprenait et des changements de dernière minute arrivant par des canaux informels. À partir de là, l’entreprise a ajusté une règle de validation, recadré une attente commerciale et supprimé plusieurs corrections répétitives.

La leçon n’était pas “tout digitaliser”. C’était “comprendre d’abord ce que le système cachait”.

La décision inconfortable: accepter un peu de lenteur

Voici la partie la moins populaire. Réduire la friction exige parfois une pause volontaire.

Cela peut vouloir dire qu’une commande ne part pas tant qu’une information critique n’est pas confirmée. Cela peut signifier que la vente ne peut plus promettre une date précise sans fourchette réaliste. Cela peut même faire que le client reçoive une réponse un peu moins rapide au début. Personne n’applaudit cette lenteur au premier regard.

Mais ralentir l’opération n’est pas la même chose qu’empêcher sa dégradation future. La question n’est pas de savoir si quelque chose paraît plus fluide aujourd’hui, mais si le flux reste soutenable quand le volume monte, qu’une personne manque ou qu’une exception sort du scénario.

Les entreprises mûres n’éliminent pas toute friction. Elles choisissent celle qui mérite d’exister pour protéger l’expérience globale. Ce choix a presque toujours un coût politique interne, parce qu’il oblige à dire non à des habitudes bien installées.

Un test réversible avant un grand programme

Si votre client et votre équipe décrivent des réalités différentes, ne commencez pas par refondre toute l’architecture. Commencez par un test court :

  • Choisissez un seul type d’exception fréquent.
  • Suivez-le pendant deux semaines sans le cacher.
  • Mesurez trois choses : fréquence, délai de résolution et point exact où l’information s’est perdue.
  • Vérifiez si le problème se situe dans une promesse, un passage de relais ou un contournement normalisé.
  • Ajustez une seule règle et observez si la friction baisse.

Cette approche ne rejette pas la technologie. Elle la remet à sa place. Dans bien des cas, la bonne solution viendra plus tard, une fois qu’il sera clair quelle décision doit être soutenue, quelle donnée manque et quelle équipe absorbe le coût.

Si votre entreprise revoit ses intégrations, ses processus ou son automatisation, chez Codefuente nous commençons souvent par cette question inconfortable : quelle friction le système cache-t-il aujourd’hui pour que le tableau de bord paraisse meilleur que la réalité ?