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.
Le premier épisode de la série parlait de DevOps. Si vous l’avez manqué, rendez-vous ICI.
Le deuxième épisode traitait de développement et vous pouvez le retrouver ICI.
Et il y a 15 jours, j’ai proposé à Mehdi Hannaizi d’écrire un épisode hors-série sur le vibe-coding à retrouverICI.
Pour ce troisème article, j’ai choisi de parler d’agilité. Parce que c’est un mot qu’on lit et qu’on entend beaucoup. Souvent complètement vidé de sa substance.
On mélange souvent des rituels, des rôles, des méthodes et des intentions très différentes. Ce flou crée des décalages dès les premiers échanges : recruteurs, managers et candidats pensent parler de la même chose, alors que leurs références et leurs attentes ne sont pas alignées.
C’est précisément ce qui rend l’agilité si propice aux malentendus dans le recrutement IT.
Comme pour les précédents articles, je vais décortiquer les trois malentendus que je rencontre le plus souvent sur le terrain..
1/ Malentendu n°1 : « on cherche quelqu’un qui maîtrise LA méthode agile »
Pourquoi c’est un malentendu
L’agilité n’a jamais désigné une méthode unique.
Elle prend sa source dans le Manifeste Agile, qui pose les valeurs et les principes pour concevoir des logiciels de meilleure qualité : plus de collaboration, plus de feedback, plus d’adaptation aux besoins réels des utilisateurs.
À partir de ces principes, plusieurs cadres de travail ont vu le jour : Scrum, Kanban, XP, SAFe etc. Chacun propose ses propres rôles, ses rituels et sa manière d’organiser le travail.
Donc parler de « la méthode Agile » n’a pas vraiment de sens. On ne parle pas d’une recette universelle. C’est plutôt un socle commun qui a inspiré différentes pratiques.
Pourquoi ça perdure
Si vous demandez à 10 entreprises différentes ce qu’est l’agilité, elles vous donneront 10 définitions différentes. Et chacune pensera que sa définition est la bonne.
Beaucoup de gens n’ont pas compris que l’agilité est une approche, presque une philosophie. Ça se ressent dans les briefs de poste, dans les annonces, dans les messages d’approche.
On utilise des expressions creuses « vous avec travaillé dans un environnement agile » ou « vous maîtrisez l’agilité » ou le fameux « vous connaissez la méthode agile ». Alors qu’il faudrait davanatge parler d’organisation, de communication, des habitudes et pratiques des équipes…
Comment y remédier
Pendant le brief, creuser pour comprendre comment l’agilité est réellement appliquée dans l’équipe :
- Quel cadre est utilisé : Scrum, Kanban, autre (par exemple un modèle « maison ») ?
- Quels rituels sont en place, et à quoi servent-ils concrètement ?
- Quels rôles existent dans l’équipe (product owner, référent, scrum master etc) ?
Avec les candidats, posez les mêmes questions, en miroir : comment travaillaient-ils, dans quel cadre, avec quels rituels et quels rôles ?
L’objectif est vraiment de comprendre ce qui se cache derrière le mot « agile » pour identifier les pratiques réelles.
Ça limite les incompréhensions et les déceptions de chaque côté.
2/ Malentendu n°2 : « le product owner c’est un chef de projet »
Pourquoi c’est un malentendu
Avec l’arrivée de l’agilité, on ne parle plus seulement de mieux gérer des projets, mais de changer la manière de concevoir les produits.
L’idée n’est pas de suivre un plan du début à la fin, mais de faire évoluer un produit en continu, en fonction des besoins réels et des retours utilisateurs.
C’est pour ça qu’avec l’agilité, on parle de gestion de produit plutôt que de gestion de projet.
Le Product Owner est là pour prioriser ce qui apporte le plus de valeur, abritrer, et orienter les choix produit. Il n’est pas responsable du planning ou du budget au sens classique. Ça c’est plutôt le rôle du chef de projet justement (en tout cas « historiquement »).
Assimiler le Product Owner à un chef de projet revient donc à mélanger deux logiques différentes : la gestion de projet et la gestion de produit. L’un n’est pas mieux que l’autre, ce sont 2 rôles différents.
Pourquoi ça perdure
Parce que, dans beaucoup d’entreprise, le passage à l’agilité ne s’est pas accompagné d’un réel changement culturel. On a gardé des fonctionnements très orientés gestion de projet, en changeant surtout les intitulés de poste.
Les chefs de projet sont devenus des Product Owners, sans que leurs missions évoluent vraiment.
Ils continuent à gérer des plannings, des dépendances, du reporting mais avec un titre plus « tendance ».
Ce n’est pas forcément conscient ou volontaire. Cela vient surtout, encore une fois, d’une mauvaise compréhension de l’agilité.
Résultat : le terme Product Owner est utilisé pour des rôles très différents, ce qui entretient la confusion côté recruteurs comme côté candidats.
Comment y remédier
Creuser un maximum pour comprendre ce que recouvre réellement le rôle de Product Owner dans l’entreprise.
- le PO a-t-il la main sur la priorisation du backlog ?
- peut-il faire des arbitrages produit ?
- est-il responsable de la valeur délivrée ou du respect des délais ?
En entretien, allez chercher du concret.
Demandez aux candidats comment ils priorisent, sur quels critères ils prennent des décisions, et ce qu’ils faisaient réellement au quotidien.
Et surtout, n’hésitez pas à changer l’intitulé du poste dans vos annonces ou vos messages.
Un rôle très orienté planning, budget et coordination relève peut-être davantage de la gestion de projet. L’appeler « Product Owner » n’aide personne. Ni les recruteurs, ni les candidats et encore moins les équipes.
3/ Malentendu n°3 : « l’agilité ça marche pour toutes les entreprises »
Pourquoi c’est un malentendu
L’agilité n’est ni une obligation, ni une étape incontournable pour toutes les entreprises.
Elle n’est pas adaptée à tous les contextes, ni à tous les secteurs, ni à toutes les organisations.
Certaines entreprises font le choix de fonctionner avec des modèles plus classiques, parce que leur activité, leurs contraintes ou leur historique s’y prêtent mieux. Elles ne sont pas en retard et ce n’est pas un échec.
Et puis on ne devient pas agile en claquant des doigts.
L’agilité est avant tout une philosophie de travail, qui implique un changement culturel, une remise en question des habitudes, des rôles et des modes de décision.
Il ne suffit pas de dire ou d’écire « on est agile » pour l’être vraiment.
Pourquoi ça perdure
Parce que pour beaucoup d’entreprises, le terme « agile » est souvent perçu comme positif.
Il renvoie à une image moderne, dynamique, organisée, avec une vraie culture produit. Un peu comme lorsque les entreprises mettent en avant un « esprit start-up” » ou se présentent comme « innovantes »..
Dans un contexte de tension sur les profils tech, le terme est souvent utilisé pour rassurer et attirer. Elles veulent montrer qu’elles ont compris les enjeux actuels, qu’elles travaille de manière structurée et qu’elles suivent les tendances.
Et j’insiste encore une fois sur le fait que ce n’est pas toujours volontairement trompeur.
Comment y remédier
En prenant du recul sur l’utilisation du mot « agile » et sur la manière dont il est perçu côté candidats.
À force d’être utilisé à toutes les sauces, sans être relié à des pratiques concrètes, le terme peut perdre tout son sens.
Pour beaucoup de profils tech, « environnement agile » devient même un mauvais signal, au même titre que « esprit start-up » : ça sonne creux, et ça ne parle pas forcément de la réalité.
Pour éviter cet effet “bullshit”, mieux vaut décrire ce qui est réellement en place :
👉 comment les équipes travaillent
👉 comment les décisions sont prises
👉 ce qui a déjà évolué et ce qui est prévu
Assumer une agilité partielle ou en construction est souvent plus crédible que de se dire « agile » sans nuance.
Et en recrutement, cette honnêteté fait toute la différence.
Conclusion
L’agilité concentre à elle seule beaucoup de ce qui rend le recrutement IT complexe : des mots très utilisés, mais rarement définis de la même manière par tout le monde.
Entre LA méthode Agile, les rôles comme Product Owner, et l’idée que toutes les entreprises seraient devenues agiles, les malentendus sont nombreux. Et ils ne viennent pas forcément d’un manque de bonne volonté, mais plutôt d’un décalage entre les intentions, les discours et la réalité des pratiques.
Comprendre ces nuances, c’est un grand pas pour améliorer les échanges entre recruteurs et personnes de la tech. Vous n’avez pas besoin de maîtriser tous les tenants et aboutissants de l’agilité (ça me semble bien compliqué!)
Mais poser les bonnes questions, prendre du recul pour décrire honnêtement les contextes et les pratiques, c’est déjà très bien.
En recrutement, la clarté, la transparence et la cohérence sont plus importantes que les mots « à la mode ».
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 début janvier pour décortiquer un nouveau malentendu du recrutement IT 😉
