Pilotage par exception : arrêtez d'apprendre vos problèmes par vos clients

Le signal que vous ratez : c'est le client qui vous alerte, pas votre système

Une équipe back-office découvre souvent qu'un dossier est bloqué de deux façons, soit un collaborateur tombe dessus par hasard en cherchant autre chose, soit le client relance parce que ça traîne trop longtemps à son goût. Dans les deux cas, la découverte arrive après coup. Personne n'a vu le problème se former, tout le monde le constate une fois qu'il est déjà installé.

Ce fonctionnement paraît normal parce qu'il ne casse rien visiblement, la plupart des dossiers finissent par se débloquer, la facture finit par partir, le contrat finit par être signé. Le coût ne se voit pas dans un incident isolé, il se voit dans le nombre de dossiers qui traînent trois semaines de plus que nécessaire sans qu'aucune alarme ne se déclenche, et dans la crédibilité qui s'érode à chaque fois qu'un client doit demander où en est sa demande.

Cette érosion s'installe silencieusement, elle ne provoque pas de rupture visible après un seul incident. Elle façonne pourtant la relation dans la durée, un client qui a appris à relancer systématiquement ne fait plus vraiment confiance au silence, même quand ce silence signifie que tout se passe bien. Il continue à relancer par précaution, ce qui charge davantage l'équipe qui traite ces relances en plus du travail de fond, et referme la boucle, plus l'équipe est chargée, moins elle a de temps pour surveiller activement, plus le client relance tôt la prochaine fois.

Le mode réactif n'est pas un manque de rigueur, c'est une architecture sans alerte

La réaction naturelle face à ce constat consiste à demander plus de rigueur à l'équipe, un tableau de suivi mieux tenu, un point hebdomadaire supplémentaire, un rappel dans les rituels d'équipe. Ce diagnostic se trompe de cible. Le problème n'est pas que les collaborateurs oublient de vérifier, c'est qu'aucun mécanisme ne les avertit qu'il faut vérifier maintenant, sur ce dossier précis.

Le pattern « à la demande du client »

Sur un chantier de structuration back-office chez un fournisseur d'énergie ETI, l'équipe a identifié ce pattern sur le suivi des demandes de mise en service déposées auprès du gestionnaire de réseau. Une fois le dossier transmis, plus personne ne le regardait activement, jusqu'à ce que le client demande où en était sa facturation, ou qu'un collaborateur remarque que le délai commençait à sembler anormal. Un dossier est ainsi resté sans suivi actif pendant quatre mois avant que quelqu'un ne s'en étonne.

Ce délai n'a rien d'une négligence individuelle. Le processus fonctionnait exactement comme il avait été conçu, sans point de contrôle intermédiaire, sans seuil qui déclenche une vérification. L'équipe n'avait pas besoin de plus de discipline, elle avait besoin d'un mécanisme qui remarque à sa place.

Qui porte le pilotage, si ce n'est pas le client

Le même diagnostic s'observe côté relation client, pas seulement côté back-office interne. Sur un projet mené pour un client industriel de l'agroalimentaire, un prestataire technique structurait explicitement son rôle en amont plutôt que de laisser le client reconstituer lui-même l'avancement auprès de chaque intervenant, hardware, intégrateur, développement. Le message posé au client était direct, il n'aurait pas à faire de calls de coordination entre les parties prenantes, un rythme de reporting fixe s'en chargerait à sa place. Cette structuration explicite du pilotage évite un piège fréquent, celui où le client devient malgré lui le seul point de passage de l'information entre les équipes, sans l'avoir demandé et sans avoir le temps de le faire correctement. Un client qui reconstitue lui-même l'état d'avancement d'un projet est un signal aussi net qu'un dossier relancé, celui d'un pilotage qui n'a pas de propriétaire clair.

Le pilotage par exception : l'alerte porte sur ce qui compte, pas sur tout

Le pilotage par exception consiste à faire porter la surveillance active sur un nombre restreint de seuils identifiés à l'avance, plutôt que d'attendre qu'un humain remarque une anomalie en passant. Le principe exclut la tentation de tout instrumenter, une alerte sur chaque champ modifié produit un bruit que personne ne lit après deux semaines. Il exige au contraire de trancher, quels sont les deux ou trois points où un retard ou un écart signale un vrai risque, pas une variation normale.

Trouver le seuil avant de coder l'alerte

Le bon seuil se trouve rarement en réfléchissant à froid, il se trouve en écoutant la phrase que quelqu'un chez vous a déjà prononcée sur un dossier réel, « tiens, ça fait longtemps, c'est bizarre ». Cette phrase désigne un délai qui a fini par sembler anormal, mais seulement après coup. Le travail consiste à transformer ce constat rétrospectif en règle explicite, posée avant que le retard ne s'installe, pas après.

Sur ce cas, la question posée par le consultant a été directe, pourquoi ne pas poser une alerte à la date de mise en service prévue. La réponse de l'équipe a révélé la vraie difficulté, cette date peut être décalée par le gestionnaire de réseau sans notification préalable. Le seuil pertinent n'était donc pas une date fixe, mais une interrogation périodique du statut réel de la demande auprès du tiers, pour détecter un blocage sans attendre que le client s'impatiente.

« On va faire en sorte qu'au moins le pilotage des problèmes que vous rencontrez soit centralisé dans l'interface. »

Cette centralisation ne dit pas qu'il faut automatiser tout le traitement du dossier. Elle dit qu'il faut d'abord rendre visible, à un seul endroit, où se trouve chaque dossier par rapport au chemin attendu, pour que l'écart devienne détectable avant de devenir un motif de relance client. Pour aller plus loin sur la structuration de ce type de processus, l'article sur l'automatisation du back-office commercial sans refondre tout le SI détaille comment prioriser les premiers chantiers.

Ce que le pilotage par exception exclut, et où il s'arrête

Le principe ne justifie pas de multiplier les alertes pour se donner une impression de contrôle. Une alerte qui se déclenche trop souvent perd sa fonction, l'équipe apprend à l'ignorer exactement comme elle ignorait le silence avant. Le pilotage par exception fonctionne seulement si le nombre de signaux reste suffisamment bas pour que chacun garde de la valeur, ce qui suppose d'accepter de ne pas tout surveiller.

Cette acceptation demande un renoncement explicite, souvent le plus difficile à tenir dans la durée. Une fois qu'une équipe a vécu un incident sur un dossier non surveillé, le réflexe naturel consiste à vouloir couvrir ce cas précis et tous les cas voisins qui pourraient lui ressembler. Céder à ce réflexe à chaque incident fait grossir le nombre d'alertes plus vite que la capacité de l'équipe à les traiter sérieusement, jusqu'à recréer, sous une autre forme, le même silence qu'au départ, noyé cette fois sous des signaux trop nombreux pour être tous lus.

Il ne remplace pas non plus une conversation directe avec un client sur un dossier réellement complexe. L'alerte sert à détecter que quelque chose mérite une attention humaine, elle ne décide pas à la place de cette attention. Une alerte bien posée raccourcit le temps entre l'apparition d'un problème et le moment où quelqu'un s'en occupe, elle ne supprime pas le besoin de s'en occuper vraiment une fois que le signal arrive.

La difficulté la plus fréquente, une fois le principe accepté, tient dans la tentation de vouloir tout couvrir dès la première itération. Une équipe convaincue de la valeur du pilotage par exception pose parfois cinq ou six alertes en même temps, sur des seuils choisis rapidement, sans avoir vérifié qu'ils correspondent à un vrai coût du silence. Le résultat ressemble alors à un système de notifications généraliste, pas à un pilotage par exception, et la fatigue d'alerte revient au bout de quelques semaines. Mieux vaut poser un seul seuil, vérifier qu'il change effectivement un comportement, puis en ajouter un deuxième, que de tout instrumenter d'un coup sur la base d'une intuition collective. Sur ce point, le premier chantier SI à mener quand une nouvelle direction administrative et financière arrive en PME montre comment ce type de visibilité s'inscrit dans une structuration plus large du SI, pas comme un correctif isolé.

Avant votre prochain point d'équipe, demandez qui, la dernière fois, a découvert un dossier en retard parce qu'un client l'a signalé. Si la réponse vient facilement, vous venez d'identifier le premier seuil à transformer en alerte.