De l’intuition à l’argumentation : comment structurer votre pensée technique pour convaincre
Voici comment transformer votre intuition technique en arguments que personne ne peut balayer d'un revers de main.
Vous aviez raison. Vous le saviez.
La solution proposée par votre lead dev allait créer une usine à gaz dans la gestion de l’état global: trop de props à faire transiter, des composants couplés entre eux, un cauchemar pour la prochaine personne qui toucherait ce code.
Mais quand votre lead vous a demandé “Tu as une meilleure idée ?”, vous n’avez pas su quoi répondre. Pas parce que vous n’aviez pas d’alternative, mais parce que vous n’arriviez pas à la formuler clairement, à la défendre.
Alors vous vous êtes exécuté, sans conviction. Trois semaines plus tard, votre responsable a repris le ticket... et n’a même pas implémenté sa propre solution.
Vous avez déjà vécu ça, n’est-ce pas ? Ce moment où vous sentez que quelque chose ne colle pas, mais où les mots ne viennent pas ?
J’ai une bonne nouvelle pour vous : votre intuition n’est pas du hasard. C’est ce qu’on appelle de l’expertise compressée. Des dizaines de bugs corrigés, de refactorings douloureux, de patterns qui ont marché ou non : tout ça s’est accumulé avec les années et forme le “gut feeling”.
Le problème ? Cette expertise reste coincée dans votre tête tant que vous n’avez pas d’outil pour l’exprimer.
Cet outil, c’est la structure. Aujourd’hui, je vais vous montrer comment l’utiliser sur trois fronts : analyser une feature avant de coder, communiquer un problème technique sans perdre votre interlocuteur, et défendre vos positions sans passer pour un relou.
Dompter la complexité avant qu’elle ne vous dompte
Vous connaissez cette sensation : vous ouvrez un ticket, vous lisez le scope, vous vous dites “Ok, 2-3 jours max”. Vous commencez donc à coder et là, les questions surgissent.
Où je mets cet état ? Dans le composant ? Dans un store ? En props depuis le parent ?
Comment je gère ce cas limite que personne n’a mentionné dans les specs ?
Attends, si je fais ça ici, ça va casser le comportement là-bas...
Résultat : vous découvrez les problèmes en développant, soit le pire moment pour les découvrir.
Le Design Doc version légère
Chez Google, les ingénieurs écrivent ce qu’ils appellent des “Design Docs” avant de toucher au code. Ce sont des documents qui décrivent le contexte, les objectifs, l’architecture proposée et surtout les alternatives envisagées.
Et là vous devez sûrement vous dire
“Super, merci Philippe, mais moi je suis seul sur ma feature et j’ai pas 3 jours à perdre à écrire de la doc.”
Je vous rassure : vous n’avez pas besoin de 15 pages. Une version minimaliste tient sur une page. Parfois même un simple fichier markdown dans votre repo suffit. Et si vous préférez écrire dans un carnet, faites (j’ai toujours admiré les gens qui font ça).
L’idée n’est pas de créer des étapes inutiles, mais de forcer votre cerveau à réfléchir avant vos doigts.
Voici donc ce que vous pouvez mettre dans vos mini design docs :
Le problème en 2 phrases. Pas la solution, mais bien le problème. Si vous n’arrivez pas à l’écrire clairement, c’est que vous ne l’avez pas compris (du coup c’est bon signe malgré tout)
L’approche envisagée. Comment vous comptez résoudre ça. Pas besoin d’être exhaustif, les grandes lignes suffisent
Les alternatives que vous avez écartées. C’est là que la magie opère: en écrivant pourquoi vous n’avez pas choisi telle solution, vous clarifiez pourquoi vous avez choisi l’autre. Et si quelqu’un vous challenge plus tard, vous avez déjà la réponse.
Les questions en suspens. Ce que vous ne savez pas encore, les zones grises, les trucs qui pourraient mal tourner.
La technique du découpage
L’autre piège classique : vouloir tout résoudre d’un coup. La technique dont nous allons parler m’a été enseignée par mon lead front il y a de nombreuses années et elle est très efficace.
Vous avez une feature complexe ? Un refactoring de CSS qui touche la moitié de l’app ? Une migration de state management ?
Ne cherchez pas à visualiser l’ensemble, sinon vous allez aller dans tous les sens, voire vous décourager. Découpez.
Imaginez que vous deviez refactorer une application legacy avec 3198 !important . N’attaquez pas de front. Découpez par page. Puis par composant. Avancez feature par feature, en intégrant le refactoring dans votre travail quotidien.
Le découpage fait deux choses pour vous : premièrement, il rend le problème moins écrasant. “Refactorer tout le CSS” est paralysant. Mais “Remplacer les couleurs en dur par des variables dans le composant Header” est faisable en une heure.
Ensuite, il vous force à identifier les dépendances : quelle partie doit être faite en premier ? Qu’est-ce qui bloque quoi ? Vous découvrez les problèmes avant de coder.
Parler le langage des solutions
Vous avez fait votre analyse, c’est très bien. Vous savez où sont les problèmes, c’est encore mieux ! Maintenant il faut les expliquer à quelqu’un d’autre.
Et là, ça coince.
“J’ai essayé d’expliquer le problème au lead, mais il n’a pas compris. Du coup il m’a proposé une solution qui ne marchait pas.”
Peut-être que ça vous est déjà arrivé de vous dire ça. Et dans 90% des cas, le problème n’est pas que le lead est incompétent, c’est que le message n’est pas passé.
Arrêtez de décrire le symptôme
Quand quelque chose ne marche pas, notre réflexe c’est de décrire ce qu’on voit :
“L’état ne se met pas à jour correctement”
“Le composant rerender trop souvent”
“C’est compliqué de faire passer les données”
Ces phrases décrivent des symptômes, pas des problèmes. Et quand vous présentez un symptôme, votre interlocuteur doit deviner le problème et il va souvent se tromper.
La méthode Quoi-Pourquoi-Impact
Voici comment vous devriez structurer vos explications techniques désormais :
Le Quoi : qu’est-ce qui se passe exactement ? Soyez précis : pas de “ça bug”, mais plutôt “quand l’utilisateur clique sur Valider, le formulaire se soumet deux fois.”
Le Pourquoi : quelle est la cause technique ? “Le handler est attaché à la fois sur le bouton et sur le formulaire via un listener global qu’on avait mis en place pour le tracking.”
L’Impact : pourquoi c’est un problème ? Pas juste “c’est pas propre”. Quel est l’impact concret ? “Ça double les appels API, et on a eu 3 tickets de support ce mois-ci à cause de ça.”
Quand vous structurez comme ça, vous ne laissez plus votre interlocuteur deviner. Vous lui donnez tous les éléments pour comprendre et décider.
Parlez leur langue
Un autre piège : utiliser du jargon que votre interlocuteur ne maîtrise pas.
Bien votre lead soit un lead, s’il est plutôt orienté backend et que vous lui parlez de “prop drilling” ou de “faire remonter le state”, il va décrocher.
Ce n’est pas de la condescendance que de reformuler, c’est de la communication efficace, donc n’hésitez pas.
Au lieu de “On a un problème de prop drilling”, essayez “On doit faire transiter les données à travers 4 niveaux de composants pour les utiliser en bas, ce qui rend le code difficile à suivre et à modifier.”
C’est la même idée, mais la 2ème formulation est plus accessible à quelqu’un qui ne vit pas dans React toute la journée.
Devenir un participant égal
Vous avez analysé et vous savez expliquer, c’est un pas de géant. Mais il reste un dernier obstacle.
Oser défendre votre position.
Je ne parle pas de devenir arrogant ou de refuser tout compromis. Je parle de ce que Jeff Atwood appelle “être un participant égal dans la conversation”. Ni plus, ni moins.
L’assertivité n’est pas de l’agressivité
Beaucoup de développeurs confondent les deux. Ils pensent que défendre leurs idées, c’est être “difficile” ou “négatif”. Pas du tout.
L’assertivité, c’est simplement la capacité à exprimer votre position clairement, en respectant celle de l’autre.
“Je pense que cette approche va créer de la dette technique sur la gestion de l’état global. Voici pourquoi : on va devoir dupliquer cette logique dans 3 composants différents, et à chaque modification il faudra penser à mettre à jour les 3. J’ai une alternative qui centralise ça. Tu veux que je te montre ?”
C’est direct et argumenté et ça ouvre une discussion au lieu de la fermer.
Pourquoi c’est important pour le business
Voici un truc que les managers ne comprennent pas toujours : quand les développeurs n’osent pas pousser leurs arguments, c’est le business qui perd.
Les non-techniciens n’ont pas les outils pour évaluer la solidité d’une estimation ou d’une solution technique. Alors ils testent, ils poussent, ils demandent “tu es sûr ?” ou “on peut pas faire plus vite ?”.
Si vous cédez trop facilement, vous envoyez un signal : “ma première réponse n’était pas vraiment sérieuse.”
Et vous vous retrouvez à promettre des délais intenables, ou à implémenter des solutions que vous savez bancales. Et je pense qu’on est tous passés par là.
Le résultat ? Des bugs en production, du refactoring d’urgence, parfois des nuits blanches ou des équipes qui s’épuisent si le problème est global.
La technique du “je pense + parce que”
Quand vous avez une intuition forte, ne la gardez pas pour vous, mais ne la balancez pas non plus comme une opinion gratuite. Structurez-la :
“Je pense que cette solution va poser problème parce que [raison technique]. Concrètement, ça veut dire que [conséquence]. Une alternative serait de [proposition].”
Voici un exemple concret, avec un state sur du React :
“Je pense qu’on ne devrait pas mettre cet état dans un store global parce qu’il n’est utilisé que par ces 2 composants qui sont déjà dans le même arbre. Concrètement, ça va ajouter du code pour rien et compliquer le debugging. Une alternative serait de le garder local au composant parent et de le passer en props, comme le recommande la doc React.”
Vous voyez la différence ? Ce n’est plus une opinion, c’est un argument structuré et en plus appuyé de la version officielle. Beaucoup plus difficile à balayer d’un revers de main.
Vous savez plus que vous ne le croyez
Revenons donc au problème que vous aviez du début de l’article.
Votre problème n’était pas un manque de compétence technique : vous saviez que la solution proposée était bancale. Votre instinct était bon.
Ce qui vous manquait, c’était un cadre pour transformer cette intuition en argument recevable.
Un mini design doc comme abordé plus haut vous aurait forcé à poser ses idées sur papier, à identifier les alternatives, à anticiper les objections.
Une meilleure structure de communication vous aurait aidé à expliquer le problème et son impact, pas juste le symptôme.
Et un peu plus d’assertivité vous aurait permis de dire “j’ai une approche différente” sans avoir l’impression de manquer de respect à votre lead.
La structure n’est pas une contrainte, c’est une sorte d’amplificateur qui prend ce que vous savez déjà et lui donne une forme que les autres peuvent recevoir.
À vous de jouer
La prochaine fois que vous attaquez une feature un peu complexe, essayez donc ceci. Avant d’ouvrir votre éditeur, ouvrez un fichier texte ou votre carnet et écrivez :
Le problème (2 phrases max)
Mon approche (les grandes lignes)
Pourquoi pas [alternative] (1-2 alternatives écartées)
Ce que je ne sais pas encore
Ça vous prendra 15 minutes maximum. Et ces 15 minutes vont vous faire économiser des heures de code jeté, d’explications confuses et de solutions imposées alors que vous aviez mieux.
Votre expertise mérite d’être entendue. Donnez-lui la structure qu’il faut pour l’être.
Et vous, avez-vous déjà rencontré des questionnements similaires ? Dites-moi comment ça s’est passé, ça m’intéresse !