Entre recruteurs et pros de la tech, il y a souvent des malentendus et des incompréhensions, même quand on croit parler le même langage. Et la plupart du temps, cela vient d’idées reçues et de croyances, parfois difficiles à déconstruire.

Avec cette nouvelle série d’articles, je veux revenir sur tout ces « petits trucs » qui compliquent le dialogue entre le monde du recrutement et celui de la tech.

Mon objectif : vous aider à mieux vous comprendre pour travailler plus facilement ensemble.

Pour ça, je vais décortiquer les malentendus et idées reçues que je vois le plus souvent. Et surtout vous donner des pistes pour y remédier.

---

#EPISODE 2 : le développement

Le premier épisode de la série parlait de DevOps. Si vous l’avez manqué, rendez-vous ICI.

Pour ce deuxième article, j’ai choisi de parler du développement.
Un domaine très vaste, encore central et souvent confié à des recruteurs et recruteuses débutants. Comme si le développement était le domaine le plus simple à comprendre dans l’IT.

Evidemment, ce n’est pas le cas ! C’est un terme fourre-tout qui cache des métiers différents, un vocabulaire riche et pas mal de subtilités.

Alors aujourd’hui, je reviens sur 3 malentendus très fréquents dans le recrutement IT autour du développement.

1/ Malentendu n°1 : « le backend c’est plus difficile que le frontend »

Pourquoi c’est un malentendu

En formation, j’entends très souvent « le frontend, c’est juste du visuel » ou « c’est moins technique que le back ». Et quand on creuse, on comprend que cette idée ne sort pas de nulle part.

Dans les années 90 et 2000, le front se résumait surtout à de l’intégration HTML/CSS, avec un peu de JavaScript pour gérer quelques interactions. Il n’y avait pas de frameworks, pas d’outillage et pas d’architecture complexe. D’ailleurs à ce moment-là, on ne parlait pas de « développeur frontend », mais plutôt de webmaster ou intégrateur HTML.

C’est à partir des années 2010 que les choses évoluent, avec l’arrivée de frameworks comme AngularJS (2009), React (2013) ou Vue (2014). À partir de là, le frontend devient un véritable métier d’ingénierie : performance, accessibilité, gestion d’état, architecture, sécurité, compatibilité navigateurs, outils de build, tests, API…

Comme cette évolution est relativement récente, le frontend conserve encore cette image “moins technique” que le backend, qui lui existe depuis des décennies.

Pourquoi ça perdure

Parce que dans les fiches de postes et les fiches métiers, on met encore souvent en avant le front des années 2000.

Et aussi parce qu’on voit immédiatement ce qui se passe côté interface, alors que le backend (bases de données, logique métier, sécurité) est invisible pour les utilisateurs. On continue à entretenir l’idée que le front se résume uniquement à ça.

Alors notre cerveau fait un raccourci 👉 ce qui est visible est simple, ce qui est invisible est complexe.

Comment y remédier

Déjà, il faut bien comprendre que ce sont 2 métiers différents et complémentaires. Ce ne sont pas deux « niveaux » (le dev back n’est pas la suite logique du dev front).

Ensuite, pendant le brief, vérifiez avec le client/ le manager :

• quelles sont les responsabilités frontend concrètes ? performance ? accessibilité ? architecture ?
• quelles sont les technologies exactes ? (langages, frameworks, bibliothèques)
• quelles sont les interactions avec les équipes backend ?

Cherchez tout ce qui va « donner du corps » au poste et pas simplement dire « vous gérez le front ».

2/ Malentendu n°2 : « on peut utiliser n’importe quel framework quand on code »

Alors ça, c’est un vrai sujet en formation, parce que beaucoup de recruteurs/recruteuses pensent que les frameworks sont interchangeables.

Mais un framework est toujours associé à un langage. Ce n’est pas une simple « boîte à outils » comme je l’entends souvent. Un framework utilise tout ce qui fait fonctionner un langage : sa “façon de tourner”, ses outils et ses règles pour organiser le code. Il ne peut donc fonctionner qu’avec ce langage-là et pas avec un autre.

Par exemple :

JavasScript 👉 React ou Vue (techniquement, React est une bibliothèque, mais on parle souvent de “framework” par abus de langage, et ce n’est pas l’idée la plus importante ici)

Python 👉 Django

PHP 👉 Laravel

Java 👉 Spring

Vouloir utiliser Spring avec Python, ce serait comme vouloir utiliser un Lego dans un jeu Playmobile, ça va être compliqué !

Bref vous avez compris, on ne peut pas utiliser un framework avec n’importe quel langage.

Pourquoi ça perdure

Parce que de nouveaux frameworks apparaissent très souvent, et disparaissent presque aussi vite.
Pour un œil non technique (et même pour certains tech), c’est difficile de suivre le rythme. Tout se ressemble, tout a l’air interchangeable, et on peut facilement croire que « si tu maîtrises l’un, tu maîtrises les autres ».

Les intitulés de poste n’aident pas non plus : « développeur JavaScript », « développeur Node », « développeur Vue »… Tout ça donne l’impression que les technologies sont proches, alors qu’elles s’appuient souvent sur des logiques très différentes.

2 précisions importantes :

• maîtriser un langage ne garantit en aucun cas la maîtrise d’un framework associé
• les frameworks rattachés à un même langage ne repose pas tous sur la même philopshie, la même complexité et courbe d’apprentissage

Comment y remédier

Pendant le brief (je sais, c’est compliqué en ESN) :

• identifiez d’abord le langage, avant même de parler du framework
• clarifiez si le framework est indispensable ou si une expérience “proche” peut suffire
• demandez pourquoi l’équipe a choisi cet outil et si une montée en compétences est prévue (ça c’est du bonus, mais ça aide à comprendre l’historique)

Si vous publiez une annonce, relisez ou faites relire pour éviter de faire une liste de frameworks sans lien entre eux. Vérifiez que c’est bien cohérent, surtout pour les profils fullstack où on peut vite s’emmêler les pinceaux.

Et gardez en tête que les outils ne sont pas une fin en soi : ils servent un contexte, un produit, une manière de travailler.

3/ Malentendu n°3 : « le fullstack, c’est un expert de tous les langages »

Pourquoi c’est un malentendu

Penser qu’un profil fullstack devrait maîtriser tous les langages et tous les frameworks n’a aucun sens.
Déjà parce que c’est impossible : chaque langage répond à un besoin précis. On les apprend en fonction du contexte dans lequel on travaille, pas pour tout couvrir « au cas où ».

Et même si c’était faisable, ça ne servirait à rien puisque chaque entreprise a sa propre stack.
Chercher quelqu’un qui « maîtrise tout », c’est chercher quelqu’un qui ne correspond à aucun contexte réel. Ça revient à chercher un mouton à 5 pattes.

Un(e) dev fullstack, ce n’est pas quelqu’un qui sait tout faire. C’est quelqu’un qui navigue entre deux univers (back et front), souvent avec une dominante, et qui sait faire le lien entre les deux.

Pourquoi ça perdure

Parce que le terme « fullstack » laisse penser qu’il y a une personne qui gère tout.

Mais aussi parce que beaucoup d’entreprises ont longtemps vu le fullstack comme un « couteau suisse ». Dans les annonces fullstack, je vois souvent une liste qui cumule les compétences d’un dev back et les compétences d’un dev front. Mais un fullstack ne peut pas remplacer 2 personnes.

Et d’ailleurs parfois, ça va encore plus loin et l’annonce donne l’impression qu’on cherche les compétences de toute une équipe dans une seule personne. Et ça c’est très fréquent dans la tech 🤦‍♀️

Comment y remédier

Commencer paz vérifier s’il y a une dominante. Est-ce que le poste est plus orienté back ou front ?

Un bon moyen pour faire ça est de demander une répartition en pourcentage du poste (70/30, 50/50, 60/40, etc.). C’est simple, concret, et ça aide vraiment à comprendre le périmètre de la mission et à mieux informer les candidat(e)s.

Identifiez aussi les priorités sur le poste :
Est-ce qu’il faut surtout construire des écrans ? Optimiser des API ? Gérer la base de données ?
Plus la demande est précise, plus la recherche sera simple (et ça c’est vrai pour n’importe quel recrutement).

4/ A retenir

Vous n’avez pas besoin de comprendre toute la technique. Votre rôle n’est pas de connaître par coeur les langages ou les frameworks, mais de savoir poser les bonnes questions.

Donc si je résume:

✔️Un langage ≠ un framework.
Le langage est la base (Java, Python, JavaScript…).
Le framework est un outil construit dessus (Spring, Django, React…).
On ne les mélange pas.

✔️Frontend, backend, fullstack : ce sont trois métiers différents.
Ne les imaginez pas comme trois niveaux ou trois versions du même profil.

✔️Un fullstack n’est pas pas deux personnes en une: il ou elle va couvrir deux périmètres, mais avec moins de profondeur que des spécialistes. Et souvent avec une dominante back ou front.

✔️Une stack technique = un écosystème.
Chaque entreprise a son propre combo langage + framework + outils.
Cherchez les candidats qui se rapproche de cette stack (pas une stack identique).

Conclusion

Le développement c’est souvent un « gros morceau » quand on recrute dans l’IT. Et vous ne pourrez pas complètement éviter les malentendus sur le sujet. Parce qu’il y en a aussi entre les techs eux-mêmes.

En essayant de creuser et de comprendre vraiment ce qui se cache derrière le nom d’une techno, vous pourrez déjà dissiper pas mal de doutes. Et surtout, n’hésitez pas à poser des questions aux candidats, à leur dire quand vous ne comprenez pas. Dans la très grande majorité des cas, ils seront ravis de vous expliquer.

Et si vous avez besoin de renforcer votre culture tech pour limiter les malentendus, j’ai rédigé un guide complet que vous pouvez acheter ICI.

Rendez-vous dans quinze jours pour décortiquer un nouveau malentendu du recrutement IT 😉