Équipe distribuée : ce qui casse en premier, ce n'est pas la connexion, c'est la définition partagée de « terminé »
Nous avions trois sites : le bureau principal, un second bureau ouvert dans une autre ville pour réduire les coûts, et des prestataires en Chine. À cela s'ajoutait le travail de projet avec des clients qui avaient leurs propres équipes. La connexion, elle, fonctionnait normalement — c'est d'ailleurs rarement elle qui pose problème.
Ce qui se cassait était autre chose. Une personne considérait une tâche comme terminée, une autre en attendait quelque chose qui n'y figurait pas, et les deux étaient convaincues de s'être mises d'accord. L'écart apparaissait un à deux jours plus tard que dans une même pièce, et ce sont précisément ces jours-là qui constituaient le vrai coût de la distribution.
Une équipe distribuée ne perd pas la communication, elle perd le critère d'achèvement partagé : ce qui est considéré comme terminé, à qui le résultat est transmis et quand. Dans une même pièce, un écart se révèle en quelques minutes grâce à des signaux fortuits ; entre sites, il faut des jours. La solution n'est pas d'ajouter des réunions, mais de fixer par écrit une définition de « terminé » et un point de transfert explicite, rattaché au système plutôt qu'à une conversation.
Ce qui casse en premier dans une équipe distribuée
Il est utile de distinguer trois choses que l'on range habituellement sous un même mot : « communication ». Elles ne se cassent pas dans le même ordre et ne se réparent pas de la même façon.
Le canal de connexion. Se casse rarement et se répare avec des outils. C'est le seul élément dont on parle en général quand on évoque le travail distribué.
Le critère d'achèvement. Se casse en premier, et presque toujours de façon invisible. Dans une même pièce, il tient grâce à des signaux fortuits : vous voyez un collègue se lever et aller voir le testeur, vous captez un bout de conversation, vous remarquez un air contrarié. Entre sites, ces signaux n'existent pas, et il n'y a généralement pas non plus de critère écrit.
Le moment du transfert. Se casse en second. Dans une même pièce, le transfert se fait physiquement : on s'approche, on le dit, on obtient une confirmation. Dans une équipe distribuée, il devient un message qui peut rester non lu, et chaque partie pense que la balle est dans le camp de l'autre.
| Ce qui casse | Comment cela se manifeste | Ce qui répare |
|---|---|---|
| Le canal de connexion | « On n'arrivait pas à se joindre », « la connexion a lâché » | Des outils |
| Le critère d'achèvement | « Je pensais que c'était déjà fait » | Une définition de « terminé » écrite |
| Le moment du transfert | « Je l'ai pourtant écrit dans le chat » | Un événement dans le système, pas un message |
| La boucle de retour | « Personne ne m'a dit que ça ne se faisait pas » | Un retour d'expérience régulier sur des cas concrets |
La première ligne se règle par un achat, les trois autres par des décisions de processus. C'est précisément pour cela que les projets d'amélioration du travail distribué qui se résument au choix d'un outil ne donnent aucun résultat.
Ce que coûte réellement la coordination inter-sites
L'ampleur du retard a été mesurée dans une étude qui combinait à la fois les journaux des systèmes et des enquêtes auprès des participants.
Une tâche nécessitant une coordination inter-sites prenait 2,5 fois plus de temps qu'un travail équivalent au sein d'un même site : 12,7 jours contre 5 dans une division et 18 contre 7 dans une autre.
Ce sont des données de la fin des années 1990, antérieures aux outils de communication actuels, et il s'agit d'une étude observationnelle, pas d'une expérience ; deux divisions d'une même entreprise. Je nomme la limite directement : le facteur 2,5 ne peut pas être transposé tel quel à la pratique actuelle comme norme. Ce qui reste solide, c'est le mécanisme lui-même — la coordination inter-sites ajoute du retard, et elle l'ajoute non pas dans le canal de connexion, qui s'est radicalement amélioré depuis, mais dans l'accord sur ce qui est considéré comme terminé.
Ce que montre l'expérience sur le travail à distance
Dans une expérience randomisée, le télétravail a produit un gain de productivité de 13 % : environ 9 % grâce à un plus grand nombre de minutes travaillées par poste (moins de pauses et d'arrêts maladie) et environ 4 % grâce à un plus grand nombre d'appels traités par minute.
Une seule entreprise, un seul métier, et des participants volontaires — l'échantillon est donc biaisé en faveur de ceux à qui ce format convient déjà. Et un autre constat de la même étude : la vitesse de promotion des salariés en télétravail a diminué. C'est une réserve importante : l'expérience mesurait la productivité sur des tâches très cadrées, dont le critère d'achèvement est fixé de l'extérieur et ne nécessite aucune concertation.
Lors du passage au télétravail dans le centre d'appels d'une grande entreprise, la qualité a le plus reculé chez les salariés sans expérience, et la probabilité de promotion des salariés à distance a baissé. Environ un tiers de l'écart de productivité s'explique par l'effet de la distance lui-même, et non par la composition des effectifs.
La période étudiée est liée à une transition imposée, ce qui introduit un biais possible, et il s'agit là encore d'une seule entreprise et d'un seul secteur. Mais avec l'étude précédente, le tableau qui se dessine reste cohérent : le travail distribué n'est ni meilleur ni pire — il touche différemment les différents groupes. Un salarié expérimenté disposant d'un critère d'achèvement clair y gagne ; un débutant qui n'en a pas y perd.
Ce que nous avons mis en place
La première solution ressemble à de la bureaucratie jusqu'au premier désaccord. Le critère d'achèvement, ce sont trois ou quatre points par type de tâche, pas un document : ce qui est fait, ce qui a été vérifié, où se trouve le résultat, à qui il a été transmis.
La deuxième solution supprime toute une catégorie de différends du type « je l'ai pourtant écrit ». Un message dans un chat n'est pas un transfert : il peut rester non lu, être lu puis oublié, ou être lu par la mauvaise personne. Un événement dans le système enregistre le fait, l'heure et le destinataire — j'ai écrit séparément sur la différence entre un événement et un message.
La troisième solution est la plus coûteuse sur le plan organisationnel et la plus efficace. Tant qu'un processus a deux propriétaires sur deux sites, ils en maintiendront de bonne foi deux versions différentes.
Quatre étapes pour une équipe répartie sur plusieurs sites
Rédigez le critère d'achèvement
Trois à quatre points par type de tâche. Test : deux personnes, interrogées indépendamment, répondent de la même façon à la question de savoir si la tâche est terminée.
Transformez le transfert en événement
Pas un message, mais un changement d'état dans le système, avec un destinataire et un horodatage.
Désignez un seul propriétaire du processus
Un seul pour tous les sites. Deux propriétaires signifient deux versions du processus en un trimestre.
Traitez les écarts comme un défaut du critère
Chaque « je pensais que c'était déjà fait » est une raison d'ajouter un point, pas de discuter du manque d'attention de quelqu'un.
Si deux personnes de sites différents répondent différemment à la question « cette tâche est-elle terminée », le problème ne vient ni de la connexion ni des personnes — il n'existe tout simplement pas de critère d'achèvement.
Les questions les plus fréquentes
Qu'est-ce qui casse en premier dans une équipe distribuée ?
La compréhension partagée de ce qui est terminé. Dans une même pièce, elle tient grâce à des signaux fortuits — vous voyez et vous entendez à quel stade en est le travail d'un collègue. À distance, ces signaux n'existent pas, et il n'y a généralement pas non plus de critère écrit, si bien que l'écart n'apparaît que des jours plus tard. Le canal de connexion, dont on parle le plus souvent, casse en réalité le moins souvent et se répare avec des outils.
De combien de réunions une équipe distribuée a-t-elle besoin ?
Moins que ce qui est habituellement programmé s'il existe un critère d'achèvement écrit, et plus s'il n'existe pas. Les réunions compensent l'absence de critère d'une manière coûteuse — en mobilisant le temps synchrone de tous les participants. Un signe pratique d'excès : la réunion sert à discuter si une tâche est terminée, et non ce qu'il faut faire ensuite.
Une équipe distribuée travaille-t-elle moins bien ?
Cela dépend des groupes. Une expérience randomisée a montré un gain de productivité de 13 % sur des tâches très cadrées, dont le critère d'achèvement est fixé de l'extérieur. Une autre étude, dans un environnement comparable, a montré que ce sont les salariés sans expérience qui reculent le plus et que la probabilité de promotion des salariés à distance diminue. Autrement dit, le format accentue l'écart entre ceux qui disposent de critères clairs et ceux qui n'en ont pas.
Comment transférer le travail entre les sites ?
Par un changement d'état dans le système avec un destinataire explicite, et non par un message sur une messagerie. Un message peut rester non lu, être lu par la mauvaise personne, ou être lu puis oublié, alors même que les deux parties restent convaincues que le transfert a eu lieu. Un événement dans le système enregistre le fait, l'heure et le destinataire, et permet de voir combien de temps le travail est resté en attente de prise en charge.
La configuration à trois sites (bureau principal, second bureau ouvert dans une autre ville pour réduire les coûts, et prestataires en Chine) ainsi que la pratique de la coordination inter-sites d'équipes transverses proviennent de l'expérience d'Alego.Digital et des projets de l'auteur en Chine entre 2017 et 2019. Il s'agit d'informations internes aux entreprises de l'auteur ; elles n'ont pas été vérifiées par un tiers indépendant et sont présentées à titre d'illustration du mécanisme. Aucune mesure quantitative du retard inter-sites n'a été réalisée, si bien que cet article ne comporte aucune métrique interne chiffrée sur ce point ; tous les chiffres proviennent de sources externes dont la méthode est indiquée.
- Herbsleb J. D., Mockus A. An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE TSE, 29(6), 2003. uni-saarland.de
- Bloom N., Liang J., Roberts J., Ying Z. J. Does Working from Home Work? Evidence from a Chinese Experiment. QJE, 130(1), 2015. nber.org
- Emanuel N., Harrington E. Working Remotely? Selection, Treatment, and the Market for Remote Work. FRBNY Staff Report 1061, 2023. newyorkfed.org