Adapter sa communication: public technique ou non-technique

Introduction

Dans la leçon précédente, nous avons conclu notre exploration des fondations de l'entreprise en analysant comment les différentes structures organisationnelles (fonctionnelle, matricielle, agile) influencent le travail d'une équipe technique. Un point commun est ressorti : la communication, surtout entre les équipes techniques et les autres départements, est un défi permanent et un facteur clé de succès.

Cette leçon marque notre entrée dans le module "Communication Interpersonnelle et d'Influence". L'objectif aujourd'hui est d'attaquer ce défi de front en apprenant à adapter votre discours et votre niveau de détail à un interlocuteur technique ou non-technique.

Pour vous qui visez des rôles comme Tech Lead ou Chef de Projet Technique, cette compétence n'est pas une option, c'est le cœur de votre future fonction. Vous serez l'interface, le traducteur, le pont entre le monde du code et le monde du "business". Savoir naviguer entre ces deux univers déterminera votre capacité à défendre votre équipe, à obtenir des ressources et à garantir que le produit développé répond à un besoin réel.

1. Le fossé de la communication : Pourquoi est-ce si difficile ?

En tant que développeur, vous avez l'habitude de discuter avec vos pairs. Vous partagez un vocabulaire, des références et une compréhension commune de ce qui est "bien fait" techniquement. Mais lorsque votre interlocuteur est un commercial, un responsable marketing ou un directeur financier, ce socle commun disparaît.

Le problème fondamental n'est pas une question d'intelligence, mais de priorités et de "langage" :

• L'équipe technique se concentre sur le "comment" : la qualité du code, l'architecture, la scalabilité, la dette technique.
• L'interlocuteur non-technique se concentre sur le "quoi" et le "pourquoi" : la fonctionnalité pour l'utilisateur, le délai de livraison, le budget, le retour sur investissement, l'avantage concurrentiel.

Parler de détails d'implémentation à un public non-technique est le moyen le plus sûr de perdre son attention et de créer de la frustration.

Pour illustrer ce point de vue du côté développeur, regardons un court extrait vidéo.

Comme le souligne la vidéo, plonger dans les détails d'une boucle if ou d'une requête réseau en réunion de projet est contre-productif. La clé est de changer de perspective. Voyons comment.

2. La règle d'or : Parler le langage de votre interlocuteur

La compétence la plus importante n'est pas de "simplifier" ou de "vulgariser" à l'extrême, mais de recadrer votre message en fonction de ce qui est important pour votre audience. Vous devez répondre à leur question implicite : "Qu'est-ce que cela signifie pour moi et mes objectifs ?"

Pour cela, il faut d'abord comprendre votre audience.

Cet article nous donne une base solide : pour être compris, il faut penser à l'autre. Une vidéo de David Laroche, bien que plus générale, développe ce principe de manière très puissante en expliquant que pour obtenir l'adhésion, il faut formuler la proposition en fonction des valeurs et des intérêts de l'autre.

Ce que cette vidéo démontre est fondamental. Si vous voulez convaincre un manager de vous allouer du temps pour réduire la dette technique, ne parlez pas de "refactoring" ou de "clean code". Parlez son langage :

• Mauvais (votre intérêt) : "Nous devons refactoriser le module de paiement, le code est devenu trop complexe."
• Bon (son intérêt) : "En investissant deux semaines pour stabiliser le module de paiement, nous allons réduire de 50% le nombre de bugs remontés par le support client et nous serons capables de livrer les prochaines fonctionnalités deux fois plus vite."

3. Identifier son interlocuteur pour mieux communiquer

Pour parler le langage de l'autre, il faut savoir qui il est. Dans un projet informatique, vous interagirez principalement avec deux grandes familles de rôles, souvent appelées MOA et MOE.

• MOE (Maîtrise d'Œuvre) : C'est le monde technique. L'équipe de développement, l'architecte, l'admin sys... C'est vous. Le chef de projet MOE est le responsable technique.
• MOA (Maîtrise d'Ouvrage) : C'est le commanditaire du projet, celui qui représente le besoin "métier" ou client. Ce rôle est souvent incarné par un Chef de Projet MOA, un Product Manager ou un Product Owner.

Comprendre cette distinction est crucial pour adapter votre discours.

Lorsque vous parlez à votre équipe (MOE), vous pouvez et devez être précis techniquement. Mais dès que vous vous adressez à la MOA (votre Product Owner, par exemple), vous devez changer de registre et parler en termes de fonctionnalités, de besoins utilisateurs, de valeur et d'impact.

4. Stratégies pratiques pour adapter votre discours

Maintenant, comment appliquer concrètement ces principes ?

Stratégie 1 : Le cadre "Bénéfice - Objectif - Contexte"

Plutôt que de commencer par les détails techniques, inversez la pyramide de l'information.

1. Le Bénéfice (le "Pourquoi") : Commencez par l'impact positif, le gain pour l'entreprise ou l'utilisateur.
   • Exemple : "Pour que nos utilisateurs puissent se connecter avec leur compte Google, ce qui augmentera le taux d'inscription de 20%..."
2. L'Objectif (le "Quoi") : Décrivez ce que vous allez faire en termes fonctionnels.
   • Exemple : "...nous devons implémenter un système d'authentification unique (SSO)."
3. Le Contexte (le "Comment", si nécessaire) : Ne donnez des détails techniques que si on vous les demande, ou s'ils ont une implication directe sur le budget ou le délai.
   • Exemple : "Cela impliquera d'utiliser la librairie OAuth2 et de modifier notre base de données. Nous estimons le travail à 5 jours."

Stratégie 2 : L'utilisation d'analogies

Les analogies sont un outil puissant pour expliquer un concept technique complexe en le rattachant à une idée que tout le monde peut comprendre.

• Pour expliquer la dette technique : "Pensez à la dette technique comme à un crédit. Ça nous a permis d'aller vite pour sortir la première version, mais maintenant, nous payons des 'intérêts' sous forme de bugs et de lenteur de développement. Il est temps de 'rembourser' une partie du 'capital' pour pouvoir repartir sur des bases saines."
• Pour expliquer un test A/B : "C'est comme un opticien qui vous demande 'Préférez-vous le verre 1 ou le verre 2 ?'. Nous allons montrer la version A de la page à la moitié des visiteurs et la version B à l'autre moitié, et nous regarderons simplement laquelle convertit le plus."

Stratégie 3 : Le support visuel

Comme le dit l'adage, "un bon croquis vaut mieux qu'un long discours". L'article de blog-gestion-de-projet.com que nous avons lu le mentionnait également. N'hésitez pas à utiliser :

• Des schémas simples sur un tableau blanc pour illustrer une architecture ou un flux de données.
• Des maquettes ou wireframes pour montrer à quoi ressemblera l'interface.
• Des graphiques pour montrer l'évolution d'une performance (ex: temps de chargement avant/après).

Conclusion

Aujourd'hui, nous avons posé la première pierre de vos compétences en communication d'influence.

Points clés à retenir :

• La communication efficace entre profils techniques et non-techniques ne consiste pas à simplifier, mais à recadrer le message autour des objectifs et des valeurs de votre interlocuteur.
• Avant de parler, demandez-vous toujours : "Qui est mon public ? Qu'est-ce qui est important pour lui ? Quel est le langage qu'il comprend ?" (ex: MOA vs MOE).
• Utilisez des cadres comme Bénéfice-Objectif-Contexte pour structurer vos idées, et n'ayez pas peur des analogies et des visuels pour clarifier des concepts complexes.
• Votre rôle de futur leader technique est d'être un traducteur de valeur, capable de transformer une discussion sur le code en une conversation sur l'impact business.

Et après ?

Maintenant que vous savez comment adapter le fond de votre message, nous allons nous intéresser à la forme. Comment s'assurer que ce message, une fois adapté, est transmis de manière claire, concise et professionnelle, notamment à l'écrit ? C'est précisément l'objet de notre prochaine leçon : "Structurer un message clair et concis à l'écrit (e-mail, rapport d'avancement, documentation)".

À très bientôt