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.
#ÉPISODE 1 : LE DEVOPS
Pour ce premier article, j’ai choisi de parler de DevOps.
Il fait partie des profils les plus demandés par les entreprises ces dernières années. Et c’est aussi l’un des termes qui créent le plus d’incompréhensions entre recruteurs et candidats. D’ailleurs, très souvent en formation, les recruteurs me disent « j’ai jamais vraiment compris ce que c’était« .
Alors aujourd’hui, je reviens sur les 3 malentendus les plus fréquents sur le DevOps dans le recrutement IT.
1/ Malentendu n° 1 : « DevOps c’est un métier »
Pourquoi c’est un malentendu
Pour rappel : DevOps est la contraction de Developement et Operations*.
A l’origine, ça n’a jamais désigné un métier ou un poste. C’est un mouvement hérité de l’Agilité.
L’Agilité émerge en 2001, avec la volonté de transformer la manière de développer des logiciels, en rapprochant les développeurs des utilisateurs. La qualité produite et la satisfaction des utilisateurs doivent être au cœur des préoccupations.
Utilisé à partir de 2007, le terme DevOps prolonge cette logique. DevOps cherche à rapprocher ceux qui créent les logiciels (les Dev) et ceux qui les font tourner au quotidien (les Ops). Le but : livrer plus vite, plus souvent et avec moins d’erreurs.
Comme l’Agilité, ce n’est pas une méthode unique, un métier, une personne : c’est un mouvement, presque une philosophie.
*A noter : operations est un terme anglais qu’on peut traduire en français par exploitation. Ops en France désigne les personnes côté infra/ système.
Pourquoi ça perdure
Parce que côté tech, on observe 2 grandes tendances :
- les tech qui se présentent comme « DevOps » sur leur CV ou leur profil LinkedIn
- les tech pour qui « DevOps » ne peut en aucun cas être un intitulé de poste
Et les deux visions sont valables. DevOps est devenu un raccourci pour désigner des ingénieurs qui travaillent dans un environnement DevOps, avec des pratiques et des outils spécifiques.
Aujourd’hui, le mot peut désigner à la fois une culture et une fonction. Et c’est ce qui entretient la confusion.
Comment réagir
Pour les recruteurs, l’enjeu est de comprendre ce que DevOps signifie dans chaque contexte. Chaque entreprise a sa propre vision de ce qu’est DevOps. Et c’est pareil pour les candidats.
Vous devez donc rester ouvert(e) :
- pendant le brief avec le client ou le manager pour comprendre sa définition
- dès les premiers échanges avec les candidats pour valider que la vision est la même que celle de l’entreprise
Et pensez-y aussi pour vos annonces et vos messages d’approche. Si vous écrivez « je cherche un DevOps », vous savez que certains profils très attachés à la vision d’origine ne se sentiront pas concernés. Mais au moins, vous comprendrez pourquoi 😉
2/ Malentendu n°2 : « DevOps c’est juste de l’automatisation »
Pourquoi c’est un malentendu
L’automatisation fait partie intégrante du DevOps : elle permet de déployer plus vite et de réduire les erreurs humaines.
Mais le DevOps ne se résume pas à ça.
C’est avant tout une manière de travailler, basée sur trois piliers :
- la collaboration entre les équipes (Dev, Ops, QA, sécurité, etc.),
- la mesure continue de la performance et de la qualité,
- et la responsabilisation collective sur le bon fonctionnement des produits.
L’automatisation n’est donc qu’un moyen pour atteindre ces objectifs et pas une fin en soi.
Pourquoi ça perdure
Parce que les outils sont plus visibles que la culture.
Quand on parle de DevOps, on pense tout de suite aux outils qui permettent l’automatisation comme Kubernetes, Docker ou Terraform. C’est concret, techniques et tangibles.
Alors que la dimension culturelle (coopération, feedback, amélioration continue) est plus difficile à mesurer.
Et comme certaines entreprises ont confié le DevOps à des équipes ou des personnes techniques chargées d’automatiser les déploiements, cela a peu à peu renforcé l’idée que le DevOps était avant tout une question d’outils.
Comment y remédier
Creusez avec le client ou le manager pour savoir quelle place réelle occupe l’automatisation dans le poste.
Si c’est la mission principale, alors ce sera cohérent d’être très orientés « outils » dans vos recherches. Mais pas uniquement des outils pour automatiser.
Par exemple :
- Pour concevoir des pipelines CI/CD 👉 GitLab CI, Jenkins, GitHub Actions ;
- Pour gérer les déploiements 👉 Ansible, Terraform, ou Helm pour Kubernetes ;
- Pour maintenir des scripts d’infrastructure 👉 Bash, Python ou PowerShell.
Mais même dans ces cas-là, gardez en tête la logique du DevOps : l’automatisation n’a de sens que si elle sert la collaboration et la fiabilité des livraisons.
3/ Malentendu n° 3 : « un bon profil DevOps, c’est 50% Dev et 50% Ops »
Pourquoi c’est un malentendu
Beaucoup de recruteur imaginent qu’un profil DevOps est un hybride parfait : moitié Dev et moitié Admin Système par exemple.
On l’a vu dans le point 1, DevOps cherche à rapprocher les Dev et les Ops, avec des pratiques et des outils communs. Mais DevOps n’a jamais eu pour objectif de fusionner 2 métiers.
Et comme vu dans le point 2, DevOps ne se résume pas à « mixer » des pratiques issues du développement avec des pratiques côté exploitation et systèmes.
Pourquoi ça dure
C’est le terme lui-même qui entretient la confusion.
Comme c’est la contraction entre Developement et Operations, on imagine que ça désigne quelqu’un d’aussi compétent dans un domaine que dans l’autre.
Et dans les faits, beaucoup d’entreprises se sont mises à chercher des profils qui gèrent à la fois le code et l’infrastructure.
Mais la réalité du marché, surtout en France, est différente.
Aujourd’hui, la majorité des profils DevOps vient surtout du monde de l’infrastructure et de la production.
Ils ont ensuite acquis des compétences en automatisation, en cloud ou en pipelines de déploiement, mais sans forcément développer au quotidien.
Comment y remédier
Là encore, c’est une question de contexte puisque le terme DevOps peut désigner des profils finalement assez différents.
Quand c’est possible (je sais que ce n’est pas toujours le cas) :
- Identifiez la dominante du poste dès le brief : est-ce un poste plus orienté automatisation, développement ou exploitation ? Il y a souvent une compétence plus « centrale » que les autres.
- Ajustez votre recherche : un profil orienté système peut très bien convenir à un environnement DevOps, même s’il ne code pas. Et même s’il n’a pas « DevOps » dans son titre de profil.
- Évitez de mélanger tous les outils dans votre annonce : « maîtrise de Python, Docker, Kubernetes, Ansible, GitLab, AWS, protocoles réseaux, sécurité », ça n’existe pas. Ça ce sont les compétences d’un département informatique entier 😉
4/ Conlusion
Le DevOps illustre parfaitement ce qui rend le recrutement IT si particulier : un même mot qui peut cacher plusieurs définitions en fonction du contexte.
Comprendre d’où viennent ces malentendus, c’est déjà améliorer le dialogue entre recruteurs et pros de la tech.
Derrière le terme “DevOps”, il n’y a pas qu’une stack d’outils : il y a surtout une façon de travailler, de communiquer et d’améliorer ensemble la qualité des livraisons.
Pour les recruteurs, la clé n’est donc pas de tout savoir, mais avant tout de poser les bonnes questions.
Pour comprendre le besoin réel, le contexte, et la vision que chacun a du terme « DevOps ».
Si vous cherchez des questions à poser en entretien à un profil DevOps : allez jeter un oeil à cet article.
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 😉
