La communication n’est pas une compétence réservée aux commerciaux et aux managers, c’est un outil universel qui fait partie de notre travail. Une information qui n’arrive pas, qui arrive trop tard ou qui arrive déformée coûte souvent plus cher qu’un bug.
C’est aussi la raison pour laquelle cette page est publique : la façon dont nous communiquons entre nous est exactement celle dont nous communiquons avec nos clients et partenaires.
Une bonne communication apporte :
- la productivité : moins d’interruptions, moins d’allers-retours, moins de travail refait pour cause de consigne mal comprise
- l’ambiance : la plupart des tensions viennent d’un message mal formulé ou mal reçu, rarement d’un désaccord de fond
- l’image : ce que nos clients et nos collègues pensent de notre sérieux se joue en grande partie sur la façon dont nous nous exprimons : un compte rendu clair, une question posée au bon moment, une difficulté annoncée tôt.
Bien communiquer est une base, pas une performance exceptionnelle. Tout ce que décrit cette page est attendu de chacun, tous les jours, au même titre que livrer du code qui fonctionne ou respecter les horaires de travail.
Dans notre domaine du développement de logiciel, nous avons la notion de dette technique qui est bien comprise et prise en compte dans notre quotidien. Pour comprendre l’importance de cette section, il suffit de considérer le manque de compétence en communication comme de la dette humaine et de lui appliquer la même politique que ce qui nous semble évident pour la dette technique.
Deux responsabilités partagées : faire passer le message, vérifier qu’on l’a compris
La personne qui transmet un message est responsable de le transmettre le plus clairement possible, mais il ne faut pas oublier que celui qui réceptionne doit s’assurer d’avoir bien compris la demande.
Émettre un message
La personne qui transmet un message est responsable de le transmettre le plus clairement possible, en suivant quatre principes :
- la clarté : une idée par message, des mots précis et ce que vous attendez de la personne de manière limpide plutôt que sous-entendu
- le bon moment : une question qui demande de la réflexion se pose en avance, une mauvaise nouvelle s’annonce tôt, quand il reste des options pour la gérer
- le bon destinataire : ceux que le sujet concerne vraiment et personne d’autre
- la formulation positive : elle impacte directement la façon dont le message sera reçu, donc l’effet qu’il produit
Communiquer positivement, c’est donner une bonne image de soi, mettre l’autre dans de bonnes conditions pour échanger et partager sa vision des choses, mettre le groupe dans de bonnes conditions pour continuer à travailler ensemble, et se donner les moyens de réussir en équipe.
Positif ne veut pas dire complaisant. Dire un désaccord clairement, signaler une erreur, refuser un délai intenable : tout cela est positif, parce que cela permet d’agir. Laisser se dégrader une situation pour éviter un moment inconfortable ne l’est pas.
Réceptionner un message
Celui qui réceptionne doit s’assurer d’avoir bien compris la demande :
- en clarifiant les mots qui sont sujets à interprétation
- en posant des questions sur les points qui lui semblent importants et qui n’ont pas été mentionnés
- en reformulant pour s’assurer qu’il a bien compris
Écouter activement ne veut pas dire simplement attendre que l’autre ait fini et dire oui pour lui faire plaisir. C’est suivre attentivement, questionner ce qui n’est pas clair et reformuler pour apporter une plus-value à l’échange.
Lors de ces étapes, la personne devient elle-même émettrice d’un autre message et les remarques du point précédent s’appliquent donc naturellement, et inversement.
Le référentiel commun : s’assurer de parler de la même chose
Pour améliorer la compréhension, il est important de s’appuyer sur un référentiel commun. Des définitions de mots partagées par l’ensemble des collaborateurs. C’est pour cela que nous investissons autant dans nos outils, nos documentations (par exemple ce playbook) et nos méthodes de travail.
Mode de communication : synchrone et asynchrone
La communication synchrone attend une réponse immédiate et impose son moment aux deux personnes. La communication asynchrone permet de fournir des informations détaillées et laisse au destinataire le choix du moment où il traite le message.
Deux questions se posent donc avant de choisir son mode de communication :
- Ai-je besoin d’une réponse tout de suite ? Pas toujours, et c’est même rarement le cas. Une question qui peut attendre deux heures n’a aucune raison d’interrompre quelqu’un maintenant.
- Comment est-ce que je m’assure que l’information est bien passée ? Celle-là se pose dans les deux cas, synchrone comme asynchrone. Communiquer ne veut pas dire envoyer dans le vide et considérer le sujet comme traité. Un message a toujours un objectif et c’est à vous de valider que cet objectif est atteint.
Le coût d’une interruption
L’interruption est le premier ennemi de la concentration. Reprendre une tâche interrompue ne coûte pas les deux minutes de l’interruption : il faut reconstruire le contexte que l’on avait en tête, et ce contexte est d’autant plus long à retrouver que le sujet est technique. Un travail morcelé demande plus d’énergie et produit plus d’erreurs.
Interrompre quelqu’un est donc une décision, pas un réflexe. Elle se justifie quand le sujet bloque réellement, ou quand l’échange direct fera gagner à l’autre plus de temps qu’il ne lui en coûte.
Choisir le bon canal
Le canal de communication se choisit d’après la situation, jamais d’après une habitude ou la facilité du moment.
| Situation | Canal |
|---|---|
| Un blocage qui impacte l’activité maintenant | Synchrone : appel ou message signalé comme urgent |
| Une question courte dont la réponse est connue, un ajustement d’organisation | Asynchrone, sur l’outil de chat de l’équipe |
| Une question qui demande de la réflexion ou une recherche | Asynchrone, ticket ou email en laissant le temps de répondre |
| Une décision qui engage plusieurs personnes | Une réunion préparée |
| Une information qui concerne toute l’équipe | Un seul message, à tous, au même moment |
| Une trace qui devra être retrouvée dans six mois | Le ticket ou le compte rendu, jamais le chat seul |
Une information transmise de personne à personne se déforme et coûte le temps de tout le monde. Dès que plusieurs personnes sont concernées, elle part une fois, à tous, au même moment. Cinq minutes de réunion ou un message unique valent mieux que six conversations qui diront six choses différentes.
Choisir le bon moment
Une question qui demande de la réflexion se pose en avance
Poser une question complexe en synchrone, c’est demander une réponse non réfléchie. Les deux issues sont mauvaises : soit la personne répond quand même et sa réponse est fragile, soit elle répond qu’elle vous recontactera, et l’échange n’aura servi qu’à l’interrompre.
Une question qui demande de la réflexion s’envoie à l’avance et par écrit, avec ce qu’il faut pour y répondre : le contexte, ce qui a déjà été tenté, et le moment où vous avez besoin de la réponse. La personne y travaille quand elle est disponible, et l’échange qui suit part sur une bonne base.
C’est le principe qui commande deux pratiques déjà en place dans les réunions : les documents à lire avant un point projet s’envoient avec assez d’avance pour être lus, et un sujet qui demande du temps se signale au daily pour convenir du moment de le traiter, il ne s’y traite pas.
Prévoir pour avoir de la disponibilité
Si vous avez besoin de faire un atelier avec quelqu’un sur un sujet, cela suppose que les autres personnes soient disponibles, physiquement comme mentalement, pour travailler avec vous.
Cela suppose d’avoir défini un périmètre à travailler et un moment permettant à chacun de s’organiser.
Ce point est l’équivalent du point précédent pour une communication synchrone, il ajoute simplement la définition de l’horaire de cette réunion.
Un exemple de situation réelle
Cadrage d’une demande
Demande : « Tu n’as rien au planning de vendredi, tu pourrais faire la mise à jour Symfony 7.4, ça permettrait de la mettre en ligne début de semaine prochaine ? »
Réponse : « Euh… oui. »
Celui qui demande a en tête 3 ou 4 heures de travail. Celui qui répond voit plusieurs jours, sûrement plus d’une semaine. Les deux ont interprété les mêmes mots de manière très différente.
La correction est simple : nommer les choses précisément, et reformuler ce que l’on a compris avant de s’engager. Reformuler n’est pas une politesse, c’est le seul moyen de vérifier que le référentiel est partagé. Une estimation ne devient fiable qu’à cette condition, comme le décrit planning et suivi du temps.
Ce qui se passe réellement
Celui qui demande est en train de préparer le planning qu’il voit vide, pense à une tâche de fond a priori simple et la propose. Celui qui répond est celui qui va faire la tâche et qui a la vision la plus précise du sujet.
Le demandeur fait une demande qu’il pense a priori cohérente avec une disponibilité d’une journée. Celui qui lui répond ne lui remonte pas l’incohérence de la demande au niveau du délai : ça permettrait de la mettre en ligne début de semaine prochaine ?
Cette situation va entraîner du temps perdu, un chantier à moitié commencé dans la précipitation et de la frustration des deux côtés : le demandeur ne comprendra pas que la tâche soit à 10 % d’avancement le vendredi soir, et le développeur ne comprendra pas que l’on ne lui donne pas les dix jours restants pour finir le travail.
| Celui qui demande | Celui qui répond | |
|---|---|---|
| Le point de vue | Qu’est-ce que je peux trouver comme sujet simple pour vendredi ? | Whaou c’est une chantier important, il ne faut pas que je me plante ! |
| Ce qu’il y a à faire |
|
|
| Le temps qu’il faut | Moins d’une journée, plus une heure au déploiement | 7 à 15 jours en fonction des impacts |
Ce qui devrait se passer
Celui qui répond sait directement que la tâche ne tient pas en une journée et peut le dire tout de suite :
« Pour la mise à jour 7.4 nous avons plusieurs sujets complémentaires comme la migration Tailwind, les outils de développement et les scans de sécurité. Est-ce que tu te rends compte que ça va prendre bien plus qu’une journée ? »
Ce premier retour rapide ne nécessite pas un chiffrage complet et un plan d’action détaillé. Il est simple à faire directement et permet de s’ajuster ensemble. C’est exactement ce que veut dire positif sans être complaisant.
Suite à ce retour, les deux personnes ont maintenant plusieurs options :
- planifier une autre tâche qui rentre dans la journée du vendredi
- faire seulement une étape de la mise à jour qui permet d’avancer le sujet
- travailler sur un chiffrage et un plan d’action plus précis pour le mettre au planning dans de meilleures conditions
Le droit au stop pour limiter le gaspillage !
L’attention de chacun n’est pas infinie, et c’est justement pour cela qu’elle se protège.
Le droit au stop : Si un échange n’est pas constructif, s’il a dérivé de son objet ou si vous avez déjà l’information dont vous aviez besoin, vous avez le droit de dire stop. Ce droit appartient à tout le monde et pas seulement à celui qui anime : personne n’a rien à gagner en restant poliment dans une conversation qui ne produit plus rien.
Annexes
Les mots vides de sens
Vides, non parce qu’ils ne disent rien, mais parce que chacun les remplit avec son propre sens. Certains mots utilisés au quotidien sont une source d’incompréhension permanente parce qu’ils sont fondamentalement imprécis. Le premier réflexe est simplement de ne pas les utiliser du tout ou les utiliser en première demande pour donner un premier contexte et les remplacer lors de la qualification.
Exemples de mots imprécis :
| Mot imprécis | Ce qu’il faut définir |
|---|---|
| rapidement | Est-ce que l’on parle du délai ou du temps à passer ? |
| dès que possible | Quand : à la fin de ma tâche actuelle, maintenant, au prochain trou dans le planning, potentiellement dans deux semaines ? |
| bientôt, prochainement | Cette semaine, ce trimestre, cette année ? |
| un jour | Quand ? |
| urgent | Urgent par rapport à quoi ? Qu’est-ce qui se passe si c’est fait demain plutôt que maintenant ? |
| petit, simple, juste | Petit pour qui ? Celui qui le demande ou celui qui le fait ? |
| une mise à jour, une refonte, une optimisation | Quel périmètre exactement ? Ce sont des mots qui désignent une famille de chantiers, pas un chantier. |
| ça ne marche pas, j’ai un bug | Qu’est-ce qui ne fonctionne pas exactement ? Quel écran, quelle action, quel résultat attendu, quel résultat obtenu ? |
| ça ne fait pas ce que je veux | Vous voulez quoi ? |
| normalement, ça devrait | Est-ce que c’est vérifié ou supposé ? |
| peut-être | Ça veut dire oui, non, ou que manque-t-il pour savoir ? |
| je ne sais pas | Est-ce possible de savoir, et comment ? |
| quelqu’un, on, ils | Qui, précisément ? |
| toujours, jamais, tout le monde | Combien de fois en réalité, et qui exactement ? Ce sont des généralisations, elles ferment la discussion au lieu de l’ouvrir. |
| comme avant, comme d’habitude | Avant quoi ? Quelle habitude ? Les deux personnes n’ont pas forcément la même en tête. |