Idée principale

Une question produit n'arrive jamais quand on est disponible. Elle arrive parce qu'un client attend une réponse, parce qu'un commercial est en rendez-vous, parce que le support doit répondre avant la fin de la journée. Elle impose donc son moment, et ce moment est celui de l'émetteur.

Ce qui se paie alors n'est pas seulement la demi-heure d'environnement de test. C'est le fait de quitter un sujet dans lequel on était entré, d'en instruire un autre, puis d'essayer de revenir. Ce qu'on avait en tête au moment de partir — les liens qu'on tenait, l'hypothèse qu'on était en train d'éprouver, la structure qu'on commençait à voir — n'est pas rangé quelque part d'où on le ressortirait.

Les deux coûts ne se réduisent pas par les mêmes moyens. Raccourcir la recherche attaque le premier ; seul le fait de ne pas être sollicité, ou de pouvoir renvoyer la question ailleurs, attaque le second. Une réponse obtenue en deux minutes au lieu de trente laisse l'interruption intacte.

Pourquoi c'est important

Cela corrige une erreur d'évaluation courante quand on outille : on mesure le gain en temps de recherche, et l'on conclut que le problème est réglé alors que la part la plus coûteuse est restée là.

Cela dit aussi ce qu'il faut viser en priorité pour les rôles dont le travail est cumulatif : déplacer la question, plutôt que l'accélérer.

Nuances et limites

Toutes les interruptions ne détruisent pas la même chose. Une question qui tombe pendant une tâche mécanique coûte son temps et rien d'autre ; le coût de continuité est proportionnel à la profondeur du travail interrompu.

Et l'interruption apporte parfois ce qu'elle détruit : une question de terrain rappelle un usage réel, et il arrive qu'elle recadre le sujet qu'on était en train de traiter.

Questions ouvertes

• À quelles conditions une question urgente pour un client peut-elle attendre sans que son émetteur aille chercher quelqu'un d'autre ?