Le code ne suffit plus : pourquoi vos soft skills sont votre meilleur atout
85 % du succès professionnel vient des soft skills, pas du code. Voici les compétences que j'ai développées et qui font la différence dans mon quotidien.
En un peu plus de 8 ans d’expérience, aussi bien en tant que salarié que freelance, j’ai rencontré des développeurs brillants : du code propre, des architectures élégantes, une maîtrise technique impressionnante. Et pourtant : pas de promotion, pas de leadership, pas de reconnaissance à la hauteur de leur talent, incapables de bien se vendre (valables aussi pour les entretiens).
Leur problème ? Ils pensaient que leur code et les cases vertes de GitHub parleraient pour eux.
Il existe une statistique qui devrait faire réfléchir tous les techs : selon une étude de Harvard, la Carnegie Foundation et Stanford, 85 % du succès professionnel vient des soft skills. Et la technique ? Seulement 15 %.
Et cette recherche ne date pas d’hier : elle remonte à 1918, dans une étude sur les ingénieurs. Un siècle plus tard, le constat n’a pas changé. Bien au contraire, on continue de l’ignorer.
Le mythe du “génie solitaire” qui code dans son coin et se fait remarquer par la seule force de son travail ? C’est un frein de carrière déguisé en romantisme tech.
Mais vous savez pourquoi c’est une bonne nouvelle ? Parce qu’aussi bien les bons développeurs que les moins bons (ça ne veut pas forcément dire “mauvais”) peuvent s’améliorer et se faire remarquer.
Les 4 compétences qui changent tout
1. La communication (et l’art de vulgariser)
Avez-vous déjà essayé d’expliquer un problème de performance à un Product Owner, ou de justifier une refonte technique à un CEO qui ne voit que les délais ?
Le piège classique : noyer l’interlocuteur dans le jargon. “On a un problème de N+1 queries qui impacte le TTI sur les pages avec beaucoup de composant lazy-loadés.”
Résultat : des yeux vitreux et un “OK, mais ça va prendre combien de temps ?”
La vraie compétence, c’est de réussir à traduire : “La page met 8 secondes à charger parce qu’on fait trop d’appels à la base de données. Je peux réduire ça à 2 secondes en une journée de travail.”
C’est concret, mesurable et surtout compréhensible.
Un bon communicateur ne simplifie pas pour “faire simple”, il adapte son message à son audience. C’est une compétence qui se travaille et elle vaut de l’or en réunion, en entretien, et dans chaque interaction avec des non-techs.
2. La résolution créative de problèmes
Fixer un bug, tout le monde peut le faire (plus ou moins vite). Mais comprendre pourquoi ce bug existe, quel impact business il a et comment éviter qu’il se reproduise ? Ça, c’est autre chose.
Le développeur moyen corrige le symptôme. Le bon développeur creuse jusqu’à la cause racine. L’excellent développeur relie ça aux objectifs de l’entreprise.
“Ce bug a fait perdre 3 commandes ce matin. J’ai identifié la cause, corrigé le problème, et proposé un test automatisé pour éviter que ça se reproduise.”
Vous voyez la différence ? Le premier fait du support. Le second apporte de la valeur. Il pense utilisateur, produit et technique.
3. La gestion du temps et du focus
Les développeurs (comme tous les autres employés finalement) sont constamment interrompus : Slack, réunions, “tu as 5 minutes ?”, code reviews urgentes... Une étude montre qu’il faut en moyenne 23 minutes pour retrouver sa concentration après une interruption.
Deux outils qui m’ont aidé à m’améliorer :
La méthode Pomodoro : 25 minutes de focus intense, 5 minutes de pause. Simple, mais redoutablement efficace pour avancer sur des tâches complexes sans se disperser. S’imposer de prendre l’air 5 minutes, de boire, de lever les yeux de l’écran fait une sacré différence.
La matrice d’Eisenhower : classer ses tâches en quatre quadrants (urgent/important, important/pas urgent, urgent/pas important, ni l’un ni l’autre). La majorité de votre temps devrait aller dans le quadrant “important mais pas urgent” : c’est là que se trouve le travail qui a un vrai impact.
Le temps est la ressource la plus rare. Les développeurs qui gèrent bien le leur ne sont pas “plus rapides”, ils sont plus intentionnels et savez gérer les priorités. J’ai longtemps arrêté ce que je faisais pour m’occuper de la demande impromptue d’un collègue : je gagnais une belle réputation de personne sympa et rapide, mais au final je perdais du temps dans mes tâches importante.
4. L’empathie technique
Ça peut sembler bizarre de parler d’empathie dans un métier technique. Mais pour qui écrivez-vous du code ?
Pour des utilisateurs. Des êtres humains qui vont cliquer, scroller, s’énerver ou se réjouir devant ce que vous construisez.
L’empathie technique, c’est se mettre à la place de l’utilisateur final. C’est comprendre ses frustrations, anticiper ses besoins, et écrire du code qui lui simplifie la vie : pas qui “prouve” votre intelligence ou votre maîtrise.
Un message d’erreur “Error 500” vs “Oups, quelque chose s’est mal passé. Voici ce que tu peux essayer.” C’est la même erreur, mais pas la même expérience.
Les développeurs empathiques écrivent un meilleur code. Donc même si votre ticket Jira, Linear ou autre ne le mentionne pas, allez plus loin que ce qui est demandé et faites-vous comprendre par l’utilisateur.
Le guide de survie pour les Pull Requests
Maintenant, parlons d’un terrain où les soft skills se jouent au quotidien malgré les apparences : la code review.
J’ai vu des PRs dans lesquelles les egos de chacun se rencontrent : des commentaires passifs-agressifs, des “pourquoi tu as fait ça ?” qui sonnent comme des accusations, des échanges interminables où plus personne ne sait ce qu’on cherche à accomplir.
Pourtant, une PR devrait être un dialogue, pas un jugement. Tout le monde doit oeuvrer pour le même but, c’est-à-dire proposer le meilleur code possible pour le produit (ET l’utilisateur !). Et chacun devrait y apprendre quelque chose.
Trois principes que j’applique systématiquement :
Utiliser des suggestions plutôt que des affirmations : au lieu de “Tu aurais dû utiliser une autre approche”, essaie “On pourrait peut-être simplifier ça avec...” et donnez un exemple si possible, ou une piste pour votre collègue. C’est subtil, mais ça change tout. Le code appartient à l’équipe, pas à un individu.
Faire sa propre auto-review avant de solliciter les autres : relire son code comme si vous ne l’aviez pas écrit. Vous allez forcément repérer des incohérences, des oublis, des trucs évidents que vous auriez corrigés de toute façon. Les autres ne sauront pas forcément que vous l’aurez fait, mais ça réduira probablement les retours que vous recevrez.
Pratiquer la gratitude (oui, oui) : quand quelqu’un fait une bonne suggestion, dis-le. “Bonne idée, je n’avais pas pensé à ça” ou simplement “Merci, c’est plus clair comme ça.” Ça crée une culture où les gens veulent contribuer, au lieu de redouter les reviews. Et vous inspirerez sûrement les autres.
Ouvrir une PR qui impressionnera le CTO
Personnellement, je déteste les PR qui ne sont pas complètes : pas d’auteur, pas de description donc pas contexte... ça fait perdre du temps à tout le monde et ça ne donne pas envie de faire la review. Selon moi, le reviewer devrait avoir les clés en main pour relire le code qu’il n’a pas écrit le plus rapidement possible.
En 2025, j’ai reçu chez l’un de mes clients les compliments du co-fondateur / CTO pour la structure de mes PR et la manière dont elles étaient créées. Voici comment je m’y prenais :
Assignation de la PR : s’il y a un champ auteur, ce n’est pas pour rien ! Attribuez-vous votre PR pour que chacun des membres de votre équipe sache que vous êtes derrière son code. D’anciens collègues m’ont déjà dit “oui mais tu vois qui a pushé dans les commentaires”. Oui, mais je n’ai pas envie de scroller parmi tous les détails pour le savoir. Et si je viens d’arriver, comment je sais qui est LeDiableShabilleEnPrada ? Alors qu’une petite photo sur la droite en dit plus et pas besoin de scroller.
La description : je la divise en plusieurs sections :
la description générale
le lien vers l’issue Linear
les changements techniques
les changements UI
ainsi qu’un screenshot ou une vidéo si applicables
Et c’est tout ! Ça m’a pris 5, 10 minutes de plus, mais le travail ne s’arrête pas au code. Tout le monde est content et peut-être allez-vous inspirer votre équipe qui en fera de même.
L’action de la semaine
Vous ne pourrez pas tout changer d’un coup. Mais vous pouvez choisir une seule soft skill et la développer pendant les 7 prochains jours.
Mon conseil : commencez par vos PR. C’est celle qui a l’impact le plus visible, le plus rapidement. Et enchaînez ensuite sur les autres, qui sont très importantes
La prochaine fois qu’on vous demande où en est un projet, résistez à l’envie de parler technique si ce n’est pas un développeur qui vous pose la question. Traduisez, simplifiez, donnez un chiffre, une date, un résultat concret.
Et n’oubliez pas que 85 % du succès, ce n’est pas votre code, ce sont vos interactions.
Quelles sont vos soft skills ?
Et vous alors ? Quelles sont vos soft skills ? Quelles sont celles que vous mettez en avant et qui vous ont permis de progresser ? Partagez-nous votre expérience dans les commentaires !