Compétence : Communication
Ma définition
Dans un projet logiciel, une bonne partie des problèmes vient simplement d’une information qui circule mal. Une demande floue, un bug décrit trop vite ou une décision technique mal comprise peuvent faire perdre beaucoup de temps.
Aujourd’hui, les équipes logicielles travaillent beaucoup par écrit : tickets, pull requests, documentation, messages. C’est encore plus vrai avec le travail asynchrone ou à distance. Le handbook GitLab sur la communication asynchrone insiste par exemple sur le lien entre travail asynchrone et documentation claire. Dans ce contexte, bien formuler un problème ou une décision fait directement partie du travail de développeur.
Pour moi, bien communiquer ne veut pas dire tout expliquer ou imposer sa vision. Il faut surtout comprendre ce que l’autre personne essaie de faire, puis lui donner ce qui est utile pour avancer.
Mes éléments de preuve
Rendre compréhensible un dispositif administratif
Lors de l’intégration de l’avance immédiate de crédit d’impôt, l’URSSAF demandait à Pedagome de prouver l’existence d’un support pédagogique destiné aux familles. Il fallait expliquer le rôle de l’URSSAF, le reste à charge client et les étapes d’inscription sans décourager les familles.
J’ai collaboré avec la graphiste de l’entreprise pour produire une plaquette que les familles pouvaient lire sans connaître le fonctionnement de l’URSSAF. Mon rôle était de transformer le parcours fonctionnel en explications simples, sans approximation sur un sujet réglementé. Ce support faisait partie des éléments demandés avant l’accès à la production.
Lien vers la réalisation : API Tiers de prestations
Faire accepter une correction dans un projet open source
Dans mes contributions open source, proposer du code ne suffit pas. Il ne serait pas compris par les maintainers, pas considéré fiable, et jamais intégré au projet. Pour éviter un rejet, il faut décrire le bug en anglais, montrer comment le reproduire, isoler le cas concerné et justifier le comportement attendu. J’ai donc rédigé des issues, préparé des exemples reproductibles et échangé avec des mainteneurs qui ne connaissaient pas mon contexte.
Mes contributions ont pu être discutées puis acceptées parce que le problème était lisible pour des personnes extérieures à mon contexte.
Lien vers la réalisation : Contributions open source
Accompagner un profil moins expérimenté
J’ai développé cette compétence en accompagnant un profil moins expérimenté sur une base de code existante. Je devais lui expliquer comment le projet était organisé, pourquoi certaines conventions existaient, et comment éviter des erreurs d’intégration. Cela m’a obligé à rendre plus explicites des raisonnements que je gardais parfois pour moi. L’accompagnement est devenu plus fluide et moins dépendant d’aller-retours permanents. Outre le gain de temps, ça m'a permis de faire évoluer ma posture managériale.
Lien vers la réalisation : Portail tuteur mobile-first
Mon autocritique
J’estime avoir un niveau solide en communication, surtout dans les échanges de travail, la rédaction de supports et la documentation. Je suis à l’aise quand il faut expliquer un sujet technique sans le rendre inutilement compliqué.
Mon point de vigilance concerne plutôt la manière de solliciter les interlocuteurs. Quand un sujet est flou, il peut être tentant de chercher tout de suite une réponse complète. Mais les personnes concernées n’ont pas toujours le temps, le recul ou les éléments nécessaires pour trancher immédiatement.
Avec le recul, je pense qu’il vaut souvent mieux préparer quelques options viables, avec leurs avantages et leurs limites, puis aider à choisir. Cela évite de forcer une réponse trop rapide ou de multiplier les échanges jusqu’à épuiser les interlocuteurs. Ainsi, je préserve leur concentration et la pertinence des échanges.
Mon évolution dans cette compétence
À moyen terme, je souhaite progresser sur les prises de parole plus formelles. Je suis plus à l’aise dans les échanges en petit groupe, les démonstrations ou les discussions techniques que devant un public plus large.
Je veux donc travailler mon rythme oral, la structure de mes interventions et la fluidité du discours. Je peux progresser par la pratique, en préparant mieux mes présentations et en m’inspirant de conférences techniques bien construites.