Un professionnel consacre en moyenne 28% de sa journée de travail à l’email. Dans un contexte projet, où la coordination entre parties prenantes (stakeholders) est permanente, ce chiffre devrait suffire à remettre en question le réflexe du “je t’envoie un mail”. Car le problème n’est pas que les gens envoient trop d’emails: c’est que l’email, par sa structure même, est inadapté à la coordination projet.
Un outil conçu pour la transmission, pas pour la coordination
L’email a été pensé comme un outil de transmission point à point: un expéditeur envoie un message à un ou plusieurs destinataires. Ce modèle fonctionne pour des échanges bilatéraux simples, une demande d’information, une confirmation, un envoi de document. Il devient dysfonctionnel dès qu’il est utilisé comme canal de coordination entre plusieurs acteurs travaillant sur des livrables interdépendants.
La raison est structurelle. L’email opère selon un modèle push: l’information est poussée vers le destinataire, qui n’a pas demandé à la recevoir à cet instant précis. Cal Newport, professeur à Georgetown University, décrit dans A World Without Email comment ce modèle transforme les travailleurs en “routeurs de réseau humains”, c’est-à-dire en intermédiaires dont l’activité principale devient de trier, rediriger et répondre à des flux d’information au lieu de produire un travail de fond.
Le phénomène dit d’attention residue (résidu attentionnel) aggrave le problème: chaque consultation de la boîte de réception laisse une trace cognitive qui dégrade la concentration sur la tâche en cours. Les professionnels consultent leur email en moyenne 15 fois par jour, alors que selon une étude publiée dans Harvard Business Review, seulement 8% de leurs collègues attendent une réponse dans l’heure. L’écart entre la fréquence de consultation et l’urgence réelle illustre un comportement collectivement irrationnel, entretenu par quelque 120 messages quotidiens dont la majorité ne nécessite aucune action immédiate.
Le CC comme révélateur d’un déficit de gouvernance
Si le modèle push est le défaut structurel de l’email, l’abus de CC en est le symptôme le plus visible en gestion de projet. Deux comportements pathologiques coexistent dans la plupart des équipes projet, et tous deux signalent un problème de gouvernance plus profond.
Le premier est le CC politique: mettre le sponsor ou le supérieur hiérarchique en copie pour exercer une pression implicite sur le destinataire. Le message sous-jacent est “ma demande est soutenue par l’autorité”, ce qui court-circuite les mécanismes normaux de priorisation au sein de l’équipe. Ce comportement constitue une forme de sabotage managérial, car il contourne les rôles et responsabilités établis dans la matrice RACI (Responsible, Accountable, Consulted, Informed) pour obtenir par la pression ce que le processus normal n’accorde pas. Quand un chef de projet constate un usage récurrent du CC hiérarchique, il ne fait pas face à un problème d’email mais à un problème de confiance dans les circuits de décision.
Le second est le CC défensif: copier systématiquement plusieurs personnes pour se prémunir contre d’éventuels reproches. La logique est celle du parapluie: “si quelque chose tourne mal, j’ai la preuve que j’avais informé tout le monde.” Ce comportement génère un volume considérable d’emails que personne ne lit et crée des zones de responsabilité diffuse, où chacun estime avoir été informé sans que personne ne se sente réellement responsable d’agir.
Le résultat est paradoxal: plus on met de gens en copie, moins quelqu’un se sent responsable. Sachant que 62% des emails reçus sont considérés comme non prioritaires par leurs destinataires, la multiplication des CC ne fait qu’alimenter le bruit au détriment du signal.
Ce que le modèle pull change concrètement
L’alternative au push n’est pas de mieux gérer ses emails, c’est de changer de paradigme. Le modèle pull centralise l’information et laisse chaque acteur la consulter quand il en a besoin, dans le contexte qui lui est pertinent.
Concrètement, cela signifie remplacer les échanges email par des espaces structurés: un tableau de bord projet pour le suivi des tâches et des jalons, un registre de décisions consultable par tous, un canal par sujet ou par lot de travail plutôt qu’un fil de discussion par email qui se fragmente au premier “répondre à tous”. Le choix de l’outil importe moins que le principe: toute information liée au projet est publiée une fois, dans un espace commun, et c’est au destinataire d’aller la chercher.
La différence fondamentale est que dans un modèle pull, la responsabilité de s’informer incombe à celui qui a besoin de l’information, pas à celui qui la détient. Cela élimine le CC défensif, puisque l’information est disponible à tous par défaut, et réduit le CC politique, puisque les demandes transitent par des canaux visibles où la traçabilité est native.
Pourquoi la transition est difficile
Migrer du push au pull suppose un changement culturel que la seule mise en place d’un outil ne suffit pas à provoquer. Beaucoup d’équipes adoptent une plateforme collaborative tout en continuant à doubler chaque publication d’un email “pour être sûr”, ce qui produit le pire des deux mondes: deux canaux à surveiller, aucun qui fait foi.
La transition nécessite une décision de gouvernance explicite, idéalement portée par le chef de projet ou le PMO (Project Management Office, bureau de gestion de projets): définir quel canal est utilisé pour quel type de communication, supprimer l’email des circuits de décision et de coordination, et assumer que l’information publiée sur l’espace partagé est considérée comme reçue. C’est inconfortable au début, car cela transfère la responsabilité de “j’ai envoyé” à “j’ai consulté”, mais c’est précisément cette bascule qui restaure l’efficacité.
L’email conserve un rôle légitime pour la communication formelle avec des parties prenantes externes, les notifications contractuelles ou les échanges confidentiels. L’erreur n’est pas d’utiliser l’email, c’est de l’utiliser comme outil de coordination interne d’un projet, fonction pour laquelle il n’a jamais été conçu.