"La prochaine fois, je vous blackliste"
Ce mail, un mardi matin. Le lead technique d'un client grands comptes, pôle ingénierie système, qui cherchait un architecte Microsoft. J'avais envoyé un profil expert Azure et Office 365 — expert fonctionnel, pas technique. La nuance m'avait échappé. Elle n'avait pas échappé au client.
Cinq ans de Business Manager en ESN. Cinq ans à évaluer des profils tech sans être technique. Et cette situation, avec des variantes, je l'ai revécue des dizaines de fois.
Si tu es BM en ESN ou recruteur en cabinet IT, tu connais ce sentiment. Un CV arrive, le candidat a l'air solide, mais tu n'as aucun moyen de vérifier. Pas de dev en interne. Que des consultants en régie chez des clients, qui finissent à 18h et qui ont autre chose à faire que de qualifier tes profils.
Cet article, c'est ce que j'aurais voulu lire quand j'ai commencé. Les méthodes que j'ai développées au fil des qualifs ratées, des clients perdus, et des leçons apprises sur le terrain.
Le vrai problème : personne pour valider
En ESN de régie, le schéma est toujours le même.
Zéro développeur en interne. Zéro temps pour valider.
Tes consultants sont chez des clients, en mission, facturés. Les solliciter pour un entretien technique, c'est leur demander de bosser gratis sur leur temps perso.
J'ai essayé. "Tu peux voir un candidat ce soir, 30 minutes max ?" La réponse, quand elle vient : "J'ai ma vie, Ludovic." Et honnêtement, il a raison.
Alors tu te retrouves seul face au CV. Tu fais ce que font tous les BM : tu qualifies sur le parcours, l'élocution, le feeling. Tu vérifies que les dates sont cohérentes, que le candidat parle bien de ses projets. Mais est-ce que ce qu'il raconte est solide techniquement ? Ou c'est du vent bien formulé ? Impossible à savoir.
Le contrôle de référence aide un peu. L'ancien manager te dira si le consultant était fiable et agréable. Rarement s'il maîtrisait vraiment Spring Boot ou si son code passait les reviews du premier coup.
Les signaux de compétence — sans être technique
Après des centaines d'entretiens de qualif, j'ai identifié trois indicateurs qui ne nécessitent aucune compétence technique pour être évalués.
La clarté d'explication. Demande au candidat de t'expliquer son dernier projet comme si tu n'étais pas technique. Un bon dev te fait comprendre ce qu'il a construit, pourquoi, et comment, sans noyer le propos sous le jargon. Si au bout de cinq minutes tu ne comprends toujours pas ce qu'il faisait, c'est un signal. Soit il ne maîtrise pas son sujet, soit il ne sait pas communiquer — dans les deux cas, ton client aura le même problème.
La cohérence du parcours. Un développeur Java qui liste Angular, React, Vue.js, Svelte et Python dans ses compétences mais n'a que des missions Java depuis trois ans ? Incohérent. Quelqu'un qui a vraiment touché à une techno peut raconter un projet concret où il l'a utilisée. "Je l'ai vu en formation" n'a pas la même valeur qu'une mission de six mois en prod.
La capacité à parler de ses échecs. Un candidat qui te dit que tout s'est toujours bien passé ment ou manque de recul. Les bons développeurs savent décrire un problème qu'ils ont rencontré, comment ils l'ont identifié, et ce qu'ils ont fait pour le résoudre. C'est dans la description du problème que tu entends le niveau réel.
Les questions qui révèlent le niveau
Pas besoin de poser des questions techniques. Il te faut des questions qui forcent le candidat à être spécifique.
Sur les projets passés :
"Décris-moi un projet où tu as dû faire un choix technique important. Quel était le contexte, quelles options tu avais, et pourquoi tu as choisi celle-là ?"
Cette seule question donne énormément d'informations. Un développeur compétent va te parler de contraintes, de compromis, de contexte métier. Un profil fragile va rester vague : "On a utilisé React parce que c'est bien."
"Quel est le bug le plus compliqué que tu aies résolu récemment ?"
Même logique. Tu écoutes le processus de résolution, pas la techno impliquée. Est-ce qu'il a investigué méthodiquement ? Ou tapé des commandes au hasard en espérant que ça passe ?
Sur la collaboration :
"Quand un collègue propose une approche technique avec laquelle tu n'es pas d'accord, comment tu gères ?"
"Si tu intègres une équipe et que le code existant est mal structuré, qu'est-ce que tu fais ?"
Ces questions révèlent la maturité professionnelle. Un junior dit "je refais tout". Un senior parle de compromis, de dette technique, de priorités business.
Les red flags que j'ai appris à repérer
Cinq ans d'ESN, ça forge un instinct. Certains profils déclenchent une alerte immédiate.
Le name-dropping techno. Le CV liste 15 frameworks, le candidat parle de "stack moderne" et de "microservices", mais ne peut pas expliquer concrètement ce qu'il a implémenté avec. J'ai eu un candidat qui citait Kubernetes, Docker, Terraform et AWS dans la même phrase. Quand j'ai demandé ce qu'il avait déployé lui-même, silence.
L'incapacité à simplifier. "C'est compliqué à expliquer si t'es pas technique." Drapeau rouge. Un développeur qui maîtrise son sujet sait l'expliquer simplement. J'ai placé des architectes qui expliquaient des systèmes distribués avec des analogies du quotidien. Et j'ai écarté des "seniors" incapables d'expliquer leur dernier projet clairement.
L'absence de questions. Un bon développeur s'intéresse au projet, à l'équipe, à l'environnement technique. Un candidat qui ne pose aucune question est soit désintéressé, soit en mode "je prends n'importe quoi" — et repartira au prochain appel d'un chasseur de têtes.
Les réponses trop parfaites. Depuis ChatGPT, ce signal est plus fréquent. Des réponses trop structurées, trop complètes, trop lisses. En entretien téléphonique, tu entends parfois le léger décalage de quelqu'un qui lit un écran. En visio, c'est le regard qui part en bas à gauche à chaque question.
Déléguer le screening technique
Ces méthodes fonctionnent. Je les ai utilisées pendant cinq ans. Mais soyons honnêtes : elles prennent du temps, elles dépendent de ton expérience, et elles ont leurs limites. Tu repères les profils clairement mauvais et les profils clairement bons. Pour tout ce qui est entre les deux — la majorité — tu avances à l'instinct.
C'est pour ça que j'ai construit Reqa.
L'idée est simple. Au lieu de demander à un dev en mission de prendre 45 minutes le soir pour qualifier un profil, tu envoies un lien au candidat. Il passe un entretien technique de 25 minutes avec une IA qui s'adapte à ses réponses, creuse quand il faut, simplifie quand c'est nécessaire.
Tu récupères un rapport avec les scores par compétence, les points forts, les zones d'ombre, et des extraits concrets de l'échange. En cinq minutes de lecture, tu sais si le profil vaut un entretien avec l'équipe technique du client.
Ça ne remplace pas l'entretien humain final. Le face-à-face avec le client reste indispensable. Mais la différence entre "envoyer un profil en croisant les doigts" et "envoyer un profil avec un rapport technique structuré", elle se voit directement sur ton taux de placement.
Ce que j'aurais fait différemment
Si j'avais eu ces méthodes et cet outil dès ma première année en ESN, j'aurais gardé des clients que j'ai perdus par manque de crédibilité technique. J'aurais évité d'envoyer ce profil fonctionnel pour un poste d'architecte technique. J'aurais placé plus vite, et mieux.
Le recrutement tech sans être technique, c'est un vrai métier. Pas un handicap. À condition d'avoir les bonnes méthodes et les bons outils.