Cela peut sembler anodin, mais notre métier repose en grande partie sur notre capacité à dialoguer avec des machines. Ce dialogue s’exprime à travers le code que nous écrivons, la compréhension précise de ce code dans le contexte d’exécution de la machine, ou encore par le biais des architectures que nous concevons pour orchestrer les différents éléments. À première vue, il s’agit d’une relation froide, logique, mécanique, régie par des principes immuables et des contraintes bien définies.

Cependant, ce métier ne s’arrête pas là. Ce serait une vision incomplète, réductrice. En réalité, notre rôle ne se limite pas à interagir avec des machines : il consiste surtout à traduire des besoins humains dans un langage compréhensible pour elles. Et c’est là que tout devient infiniment plus complexe. Nous sommes des interprètes, pas de simples traducteurs. Un traducteur convertirait littéralement les mots et idées du demandeur en code, mais un interprète va plus loin : il capte l’intention, les nuances, les subtilités souvent implicites dans le besoin exprimé. Il reformule, clarifie, et adapte ces intentions en respectant à la fois les exigences du demandeur et les contraintes imposées par la machine.

C’est précisément ce rôle d’interprète qui met en lumière une différence fondamentale dans notre métier : dialoguer avec une machine est certes une tâche essentielle, mais tout commence bien avant, dans notre capacité à dialoguer avec les humains. Et c’est là que réside une faiblesse récurrente dans notre manière de travailler : nous sommes rarement formés, préparés ou même encouragés à développer les compétences nécessaires pour comprendre et collaborer avec autrui.

Cette lacune se manifeste dès que nous devons interagir avec un non-tech. Comment aider quelqu’un à exprimer clairement son besoin si nous ne faisons pas l’effort de nous mettre à son niveau, de voir le monde à travers ses yeux, de comprendre ses priorités et ses contraintes ? Rien de péjoratif ici, bien au contraire. Les non-tech ont leur propre expertise, qui ne repose pas sur la maîtrise de nos outils ou de nos paradigmes, et il serait absurde de leur en tenir rigueur. Mais c’est justement parce que leurs priorités sont différentes que la charge de compréhension repose sur nous.

Et pourtant, trop souvent, nous échouons à faire cet effort. Plutôt que de chercher à comprendre, nous nous réfugions derrière les fameuses “specs”. Ces documents, fondamentaux pour organiser et structurer le travail, deviennent parfois un prétexte, une manière subtile de mettre de la distance entre nous et le demandeur. Si un projet échoue ou dérape, on peut alors pointer du doigt les specs : « Ce n’était pas clair », « Ce n’est pas ce qu’ils ont demandé », « Ils n’ont pas précisé ce point ». Les specs deviennent un bouclier qui nous protège, mais qui nous isole aussi.

J’ai moi-même longtemps trouvé du réconfort dans la prédictibilité des machines. Après tout, elles ne jugent pas, ne remettent pas en question, et surtout, elles ne nécessitent ni subtilité ni art du langage implicite. Elles font ce qu’on leur demande, tant qu’on s’exprime correctement. Mais cette simplicité est trompeuse, car elle nous éloigne de la réalité humaine de notre métier. Ce que j’ai compris, parfois à mes dépens, c’est que ce n’est pas la machine que nous devons apprendre à comprendre et à convaincre, mais bien l’humain.

C’est ici que l’empathie entre en jeu. Et pas seulement dans la collaboration directe avec un non-tech ou un collègue, mais dans chaque aspect de notre communication, qu’il s’agisse d’un email, d’une documentation, d’un rapport ou d’une spécification. L’empathie n’est pas un luxe ou une qualité accessoire, c’est un pilier essentiel. Écrire n’est jamais un acte pour soi. Écrire, c’est avant tout un acte pour l’autre. Exclure l’autre de notre écriture, ne pas tenir compte de son point de vue, de ses besoins ou de ses contraintes, c’est se tromper dès la rédaction.

Prenons la documentation, par exemple. Trop souvent, nous la percevons comme une corvée, une tâche administrative à finir au plus vite pour passer à autre chose. Alors, nous nous contentons de poser sur le papier ce que nous savons, dans le langage qui nous est familier, sans jamais nous demander : « Celui qui lira ces lignes comprendra-t-il ce que j’ai voulu dire ? Aura-t-il les clés pour utiliser cette information efficacement ? Ai-je anticipé ses questions, ses besoins, ses difficultés potentielles ? » Écrire ainsi, c’est écrire pour soi, pas pour les autres.

Mais l’écriture, dans notre métier, n’est jamais un acte isolé. Elle s’inscrit toujours dans une dynamique de collaboration. Une documentation, une spécification, un compte rendu, tout cela est destiné à quelqu’un : un collègue, un client, un futur membre de l’équipe. Ignorer cet aspect, c’est ignorer l’essence même de notre travail. Et c’est là qu’intervient une autre dimension de l’empathie : celle de se projeter dans la position de l’autre, d’imaginer ce qu’il ressent, ce qu’il comprend, ce qui pourrait l’aider ou, au contraire, l’embrouiller.

Cette absence d’empathie dans nos écrits n’est pas seulement un défaut de forme. Elle peut avoir des conséquences profondes sur la qualité de nos projets. Une documentation mal pensée peut mener à des erreurs, des incompréhensions, ou des pertes de temps. Une spécification floue ou mal adaptée peut créer des tensions entre les équipes. Et tout cela aurait pu être évité avec un peu plus de réflexion, avec l’effort de se mettre à la place de l’autre, même pour quelques instants.

Il est donc temps de réhabiliter l’empathie dans notre manière de travailler. Non pas comme une qualité optionnelle, mais comme une compétence centrale, au même titre que nos compétences techniques. Être un bon développeur, un bon architecte, un bon chef de projet, ce n’est pas seulement maîtriser les outils et les technologies, c’est aussi être capable de comprendre les humains avec lesquels nous travaillons. Être capable de parler leur langage, d’anticiper leurs besoins, de répondre à leurs attentes, tout en respectant leurs contraintes.

Et cela commence par une prise de conscience simple mais essentielle : dans chaque ligne que nous écrivons, dans chaque mot que nous choisissons, nous avons une responsabilité envers l’autre. Écrire, c’est toujours pour l’autre. Se tromper d’interlocuteur, oublier son lecteur, c’est rater sa mission dès le départ. Et si nous voulons réellement exceller dans notre métier, si nous voulons que notre travail ait un impact durable et positif, il est temps de remettre l’autre au centre de nos actions.

Cultiver l’empathie : quelques axes essentiels

Pour devenir véritablement empathique dans nos échanges professionnels, il est nécessaire de reconnaître et de travailler sur plusieurs dimensions clés. Ces rappels peuvent sembler évidents, mais ils sont souvent oubliés dans la pratique quotidienne.

Accepter que l’autre ne réfléchit pas comme nous

L’un des premiers obstacles à l’empathie est de croire que les autres perçoivent et analysent le monde de la même manière que nous. En réalité, chaque individu possède sa propre logique, façonnée par ses expériences, son éducation et son rôle. Dans un échange, il est crucial d’accepter que l’autre peut avoir une vision totalement différente d’un même problème.

Cette diversité de perception n’est pas une faiblesse ou une difficulté à surmonter, mais une richesse à exploiter. Un non-tech, par exemple, abordera une problématique avec une perspective métier, centrée sur des impacts concrets ou opérationnels. À l’inverse, nous, en tant que professionnels de la tech, avons souvent une approche plus abstraite ou technique. Reconnaître cette différence est la première étape pour ajuster notre communication.

Reconnaître l’existence de perceptions multiples de la réalité

Ce point est une extension naturelle du précédent. Il est essentiel de comprendre que ce qui est “évident” pour nous peut être totalement obscur pour d’autres. Cela inclut non seulement les connaissances techniques, mais aussi des éléments culturels ou organisationnels.

Dans nos échanges, nous devons nous rappeler que la réalité n’est pas objective, mais relative à celui qui la perçoit. Lorsqu’un collègue ou un client semble “ne pas comprendre”, ce n’est pas un manque de compétence de leur part. C’est simplement que leur manière de percevoir la réalité ne correspond pas à la nôtre. Ce décalage nécessite un effort conscient pour adapter notre discours, poser des questions, reformuler et s’assurer que le message est clair.

Adapter son langage au public

Le jargon technique est l’une des barrières les plus courantes à une communication empathique. En tant que professionnels, nous utilisons des termes, des concepts et des abréviations qui sont naturels pour nous, mais qui peuvent être déconcertants pour d’autres. Pire encore, certains mots peuvent avoir des significations différentes selon les contextes.

Par exemple, un “build” pour nous peut signifier une compilation de code ou un processus de déploiement, tandis que pour un utilisateur métier, cela pourrait n’évoquer absolument rien. Être empathique, c’est toujours se demander : « Mon interlocuteur comprend-il les mots que j’utilise ? Ai-je vérifié que nous partageons le même vocabulaire ? » Si ce n’est pas le cas, il faut reformuler, expliciter ou, au besoin, proposer un parallèle avec des concepts familiers à l’interlocuteur.

Prendre en compte la diversité des types de consommateurs d’information

Lorsque nous produisons une documentation, un email ou une spécification, il est facile d’imaginer un “lecteur idéal”, quelqu’un qui comprendra parfaitement notre intention. Mais ce lecteur idéal n’existe pas. En réalité, nos écrits seront consommés par une multitude de profils, chacun avec ses propres attentes et contraintes.

  • Le consommateur rapide : celui qui veut un résumé, une réponse claire et concise. Pour lui, les longues explications sont un obstacle.
  • Le consommateur analytique : celui qui souhaite tout comprendre en détail, décortiquer les processus, les raisons derrière chaque choix.
  • Le consommateur novice : celui qui découvre le sujet et a besoin de bases pédagogiques pour suivre.
  • Le consommateur expert : celui qui connaît déjà le sujet, mais qui recherche des précisions ou des informations pointues.

Être empathique, c’est anticiper ces besoins variés et structurer son message pour qu’il puisse être utile à chacun. Par exemple, une documentation peut inclure un résumé en début de section pour les lecteurs pressés, mais aussi des explications détaillées pour les analystes.

Se mettre dans la peau de son lecteur avant d’écrire

Écrire pour soi et écrire pour l’autre sont deux actes fondamentalement différents. Avant de rédiger, il est utile de se poser quelques questions simples :

  • Qui va lire ce document ?
  • Quels sont ses objectifs ? Pourquoi cherche-t-il cette information ?
  • Quel est son niveau de connaissance du sujet ?
  • Quels obstacles pourrait-il rencontrer en lisant ce texte ?

Ces réflexions permettent de produire un contenu réellement utile. Par exemple, une spécification ne doit pas être une simple retranscription de ce que nous avons en tête, mais une véritable passerelle entre les besoins exprimés et la réalité technique.

Laisser de la place à l’erreur et au dialogue

Enfin, être empathique, c’est reconnaître que la communication est imparfaite par nature. Même avec les meilleurs efforts, il est possible que notre message soit mal compris. Plutôt que de rejeter la faute sur l’autre, il est essentiel d’ouvrir un espace de dialogue pour clarifier les points ambigus, reformuler, et corriger.

Accepter qu’un document ou une discussion n’est pas une fin en soi, mais le début d’un échange, est un acte profondément empathique. Cela montre que nous ne cherchons pas seulement à transmettre une information, mais à la rendre intelligible et utile.