Ce que le CV ne montre pas — et ce que ça coûte vraiment à vos équipes.
Les soft skills sont devenus le sujet dont tout le monde parle en recrutement IT. Et pourtant, la plupart des entretiens continuent de les ignorer complètement.
Imaginez la scène. Vous venez de recruter un développeur senior. CV solide, test technique réussi haut la main, stack parfaitement alignée avec vos besoins. Trois mois plus tard, le tech lead vous remonte un problème : l’équipe ne fonctionne plus aussi bien depuis son arrivée. Les réunions sont tendues. Les code reviews traînent. Deux développeurs ont demandé à changer de projet.
Le profil que vous avez recruté n’est pas mauvais techniquement. Il est juste incapable de travailler avec les autres.
Ce scénario, les équipes RH et les managers IT le vivent bien plus souvent qu’ils ne l’admettent. Et pourtant, le process de recrutement n’a pas changé. On continue d’évaluer ce qu’on sait mesurer — les compétences techniques — et d’ignorer ce qu’on ne sait pas trop comment aborder : les soft skills.
Pourquoi l’IT sous-estime systématiquement les soft skills
Il y a une culture dans le monde du développement qui dit, en substance : le code parle pour lui. Un bon développeur produit du bon code. Point.
Cette logique a une cohérence interne. Elle a aussi une faille majeure.
Ce qui fait qu’un développeur performe seul sur un projet personnel n’a presque rien à voir avec ce qui fait qu’il performe dans une équipe produit, en environnement agile, avec des specs qui changent toutes les deux semaines et un PO qui arbitre en permanence.
Le problème, c’est que les entretiens IT sont structurés autour du premier cas. Test technique, live coding, questions sur la stack, éventuellement un cas pratique. C’est rigoureux. C’est mesurable. Et ça ne dit presque rien sur la façon dont le candidat va se comporter quand il reçoit un feedback difficile, quand il doit débloquer un collègue qui ne comprend pas son implémentation, ou quand il doit travailler sur une base de code qu’il n’aurait pas écrite comme ça.
Les soft skills sont perçus comme subjectifs, donc difficiles à évaluer, donc souvent écartés. On se dit qu’on verra à l’usage. Qu’on sentira pendant la période d’essai.
C’est exactement là que le coût commence.
Ce que ça coûte vraiment — et personne n’en parle franchement
Un recrutement raté en IT, ce n’est pas seulement un poste à repourvoir. C’est une série de coûts qui s’accumulent en silence, souvent sans qu’on fasse le lien avec la décision initiale.
La vélocité de l’équipe chute:
Un profil qui communique mal crée des silos. Les informations ne circulent pas, les dépendances bloquent, les sprints dérivent. Le reste de l’équipe compense sans le dire.
Les bons profils partent:
C’est peut-être le coût le plus sous-estimé. Les développeurs expérimentés n’élèvent pas la voix. Ils regardent LinkedIn et répondent aux messages de recruteurs. Ils quittent les équipes dysfonctionnelles en silence, souvent sans que le manager comprenne vraiment pourquoi.
Le manager devient un tampon:
Le tech lead ou le manager passe un temps considérable à “gérer” la situation — à reformuler les feedbacks, à désamorcer les tensions, à réexpliquer ce qui aurait dû être compris dès le départ. C’est du temps soustrait à ce pour quoi il est là.
L’onboarding ne prend pas:
Un profil rigide, peu à l’aise avec l’ambiguïté ou le feedback, ne progresse pas dans ses pratiques internes. Il applique ce qu’il sait, résiste à ce qu’il ne connaît pas, et stagne là où vous attendiez de la progression.
Ramenez ça à un coût de recrutement moyen, une période d’essai de trois mois, et l’impact indirect sur l’équipe. Le chiffre est rarement agréable à calculer.
Les soft skills IT qui comptent vraiment
Évitons la liste générique. Esprit d’équipe, bonne communication, adaptabilité — tout le monde écrit ça, et ça ne veut rien dire dans un contexte opérationnel.
Les soft skills qui font la différence en IT sont spécifiques. En voici quatre qui méritent d’être évalués sérieusement :
La gestion de l’ambiguïté:
Les specs sont rarement complètes. Les priorités changent. Un développeur qui a besoin de tout comprendre avant de commencer, ou qui se bloque dès qu’un périmètre n’est pas défini, va souffrir dans la plupart des environnements de production actuels. Ce n’est pas une question de niveau technique, c’est une question de rapport à l’incertitude.
La capacité à donner et recevoir du feedback:
La code review est un moment clé. Elle peut être un outil de progression collective ou une source de tensions permanentes selon la façon dont elle est vécue. Un développeur qui prend chaque commentaire comme une attaque personnelle, ou qui ne sait pas formuler une critique constructive, fragilise la culture technique de toute l’équipe.
La communication asynchrone:
Avec le travail hybride et les équipes distribuées, savoir écrire clairement, documenter ses choix techniques, synthétiser un problème sans réunion — c’est devenu une compétence critique. Pas optionnelle.
La résilience face à la dette technique:
Presque toutes les bases de code existantes ont de la dette. Un développeur qui vit ça comme une agression personnelle, qui refuse de travailler sur du legacy ou qui le mentionne à chaque occasion, va générer de la friction là où vous avez besoin de pragmatisme.
Comment les évaluer concrètement en entretien
C’est la question que tout le monde pose et à laquelle peu donnent une réponse opérationnelle. Voici ce qui fonctionne.
Remplacez les questions abstraites par des mises en situation comportementales:
Pas “Êtes-vous à l’aise avec le feedback ?” — la réponse sera toujours oui. Mais plutôt : “Décrivez-moi une code review difficile que vous avez reçue. Qu’est-ce qui l’a rendue difficile ? Comment vous l’avez gérée ?”
La façon dont le candidat raconte cette histoire dit beaucoup plus que n’importe quelle réponse préparée.
Observez le comportement pendant l’entretien lui-même:
Comment le candidat reformule une question qu’il n’a pas comprise ? Est-ce qu’il assume ne pas savoir, ou est-ce qu’il noie le vague dans du jargon ? Est-ce qu’il écoute vraiment, ou est-ce qu’il attend son tour de parler ? Ces micro-comportements sont des signaux.
Intégrez un membre de l’équipe dans le process:
Pas seulement le RH ou le manager. Un développeur qui travaillera directement avec le candidat perçoit des choses que la hiérarchie ne voit pas. Son ressenti sur la dynamique d’échange mérite d’être pris en compte.
Testez la réaction à l’inconfort:
Posez une question ouverte sans bonne réponse. Soumettez un choix technique discutable et demandez ce qu’il en pense. L’objectif n’est pas de piéger, c’est de voir comment il gère une situation sans filet.
Ce que ça change quand on recrute autrement
Recruter un bon développeur, c’est relativement accessible aujourd’hui. Le marché IT a beau être tendu, les process pour évaluer les compétences techniques sont bien rodés.
Recruter un développeur qui fait monter son équipe, qui fluidifie la communication, qui absorbera les tensions plutôt que de les amplifier — c’est un autre niveau d’exigence. Et c’est exactement ce niveau qui fait la différence entre une équipe qui délivre et une équipe qui subit.
Chez WeGestU, on travaille justement à rendre cette exigence concrète. Les profils IT de la plateforme passent un test de compétences comportementales conçu pour révéler ce que le CV ne montre pas — la façon dont un candidat gère l’ambiguïté, réagit au feedback, collabore sous pression. Pas un questionnaire de personnalité générique. Un outil calibré pour les réalités du terrain IT.
Résultat : quand vous consultez un profil sur WeGestU, vous ne lisez pas seulement une stack technique. Vous avez déjà une lecture sur les soft skills — avant même le premier entretien.
Parce qu’un bon recrutement, ça commence avant la première question.
Vous voulez voir ce que vos entretiens ne voient pas ? Testez la plateforme 48h gratuitement — profils IT + évaluation comportementale incluse.”
