Évaluer un développeur quand on n'est pas technique

Vous avez devant vous un candidat développeur. Son CV aligne des technologies dont vous n'avez jamais entendu parler, et il décrit avec aisance des projets que vous ne comprenez qu'à moitié. Au bout d'une heure, vous avez un avis, mais vous seriez bien en peine de dire sur quoi il repose. Cette situation pousse la plupart des fondateurs non techniques vers l'une de deux erreurs : tout confier à un test qu'ils ne savent pas lire, ou trancher au feeling.

Pour évaluer un développeur sans être technique, jugez ce qui se lit sans code : sa façon de questionner le besoin, de prioriser, d'expliquer et d'admettre ce qu'il ne sait pas. Le meilleur outil est un test « v1 », où il vous présente comment il construirait la première version de votre produit. La qualité du code, elle, se fait relire par un pair.

Cette évaluation est une étape du processus complet, décrit dans recruter son premier développeur sans être technique, qui s'inscrit lui-même dans le guide pour construire son équipe tech et produit. La conception de l'exercice de code, celui que relit un développeur, est traitée dans les tests techniques en recrutement. Ici, on s'intéresse à la part de l'évaluation que vous pouvez tenir seul, et à la manière de la rendre fiable.

Ce que vous pouvez juger, et ce que vous ne pouvez pas

Soyons honnêtes sur la frontière. Vous ne jugerez pas la qualité d'un code, la pertinence d'un choix de base de données ou la solidité d'une architecture. Inutile d'apprendre trois questions techniques par cœur pour faire illusion : un candidat sérieux le sentira, et vous ne saurez pas interpréter sa réponse.

En revanche, vous êtes le mieux placé pour juger tout ce qui touche au produit. Dans une petite équipe, un développeur passe autant de temps à comprendre quoi construire qu'à le construire : il discute avec vous, arbitre, découpe, explique pourquoi une fonctionnalité prendra trois semaines et non trois jours. C'est exactement ce que vous vivez chaque jour avec vos clients et vos associés. Le principe est celui que je propose pour les entretiens de direction technique dans les questions à poser en entretien CTO : faire parler de situations réelles, puis creuser, plutôt que de tester des connaissances.

La grille d'entretien : six critères lisibles sans code

Chaque critère se travaille avec une question ouverte et une relance. Notez à chaud, de 1 à 3, en écrivant la phrase du candidat qui justifie la note. Sans cette trace écrite, c'est le dernier candidat vu, ou le plus charismatique, qui l'emporte presque toujours.

Aucun de ces critères n'exige de savoir coder, et pourtant ils couvrent l'essentiel de ce qui fait réussir ou échouer un premier développeur dans une petite structure. Ils prolongent les quelques questions d'entretien que je proposais dans composer sa première équipe tech après le MVP, en les rendant notables et comparables d'un candidat à l'autre. La technique pure viendra compléter, pas remplacer.

Le test « v1 » : l'exercice que vous savez corriger

Pendant la restitution, cinq signaux se lisent sans aucune compétence technique. Le candidat commence-t-il par poser des questions sur les trous du dossier ? Sa première livraison est-elle quelque chose qu'un client pourrait réellement utiliser, ou une fondation invisible de plusieurs mois ? Dit-il clairement ce qu'il ne construira pas ? Donne-t-il des ordres de grandeur de délai assortis d'hypothèses, plutôt qu'une date ferme ou un refus d'estimer ? Et que se passe-t-il quand, à mi-parcours, vous annoncez que le délai est divisé par deux ? Le bon profil réajuste son plan et dit ce qu'il sacrifie. Le profil fragile défend son plan initial ou repart de zéro.

Un garde-fou : le cas doit porter sur une première version hypothétique ou déjà cadrée, jamais sur une fonctionnalité que vous comptez construire le mois suivant avec ses idées. Les bons candidats repèrent immédiatement le conseil gratuit déguisé, et ils ont raison de s'en méfier.

La variante pour les finalistes : une mini-mission payée

Quand deux candidats restent au coude à coude, une courte mission rémunérée, d'un ou deux jours, sur une petite fonctionnalité réelle et isolée, tranche souvent. Là encore, vous jugez ce qui se voit : la fonctionnalité marche-t-elle, a-t-elle été livrée au moment annoncé, le candidat a-t-il prévenu tôt quand il bloquait, explique-t-il ce qui reste à faire ? Le code, lui, est relu par votre pair technique. Ce format convient bien aux freelances et aux personnes disponibles, beaucoup moins à un salarié en poste : proposez-le, ne l'imposez pas.

Ce que la grille ne remplace pas

La grille et le test « v1 » vous rendent autonome sur une bonne moitié de la décision, pas sur toute. Un développeur peut raisonner juste et écrire un code impossible à maintenir : faites donc toujours relire un échantillon de son travail par quelqu'un dont c'est le métier. Prenez aussi deux références, dont une personne qui a travaillé à ses côtés au quotidien, et posez-lui une question précise plutôt qu'un « comment était-il ? ».

Gardez enfin en tête le biais inverse. Certains excellents développeurs sont peu à l'aise à l'oral face à un inconnu, surtout en début d'entretien. Si la grille est moyenne mais que le test « v1 » est solide, laissez-leur une seconde chance, par écrit ou dans un échange plus informel. Les signaux qui doivent vraiment vous arrêter sont d'une autre nature, et je les rassemble dans les red flags quand on recrute un développeur en startup. Pour replacer tout cela dans une trame d'étapes courtes, chacune avec sa décision, voyez structurer son process de recrutement.