Recruter un développeur : guide du fondateur non-technique

J'ai audité le code d'une startup il y a quelques mois. Le fondateur avait recruté son premier développeur six mois plus tôt. CV impeccable : grande SSII, 8 ans d'expérience, stack parfaite pour le projet. Sauf qu'en ouvrant le repo, 80% du code était du copier-coller de ChatGPT. Pas compris, pas adapté, pas testé. Six mois de salaire — environ 30 000€ charges comprises — pour un code qu'il a fallu réécrire intégralement.

Ce fondateur n'est pas idiot. Il dirige une boîte qui fait 800K€ de CA. Mais il a recruté un développeur comme il aurait recruté un commercial : sur le CV et le feeling. Et ça ne marche pas comme ça.

Vous êtes dans cette situation ? Vous devez recruter quelqu'un dont vous êtes incapable de vérifier le travail ? Ce guide est pour vous. Des questions concrètes à poser, des signaux d'alerte à repérer, et un template d'entretien utilisable dès demain.

Pourquoi le CV d'un développeur ne sert presque à rien

C'est contre-intuitif quand on vient du business, mais le CV technique est probablement le pire indicateur de compétence d'un dev.

Un fondateur non-technique regarde un CV de développeur et compte les technologies qu'il reconnaît. React, Node.js, AWS, Docker, Kubernetes, Python, TypeScript… Plus il y en a, mieux c'est. Non ?

C'est l'inverse. Un dev qui liste 15 technos est souvent un dev qui en maîtrise 3 et qui a "touché" les 12 autres pendant un week-end. Les meilleurs développeurs que j'ai croisés en 15 ans ont des CV presque ennuyeux. Trois ou quatre technos, maîtrisées en profondeur. Pas de buzzwords.

Ce qui compte sur un CV technique, ce n'est pas la liste de technos. C'est la cohérence du parcours et la durée dans chaque poste — un dev qui change tous les 8 mois, c'est un signal. Mais surtout : ce qu'il a construit, pas avec quoi il l'a construit. Un projet personnel visible sur GitHub vaut plus que 5 ans chez Capgemini. Parce que chez Capgemini, le dev a peut-être passé 4 ans sur du support et 1 an sur du vrai développement. Impossible de le savoir en lisant le CV.

C'est d'ailleurs le même problème que rencontrent les investisseurs lors d'une due diligence technique : le vernis ne dit rien sur la réalité du code en dessous.

Trois questions qui valent mieux qu'un test technique

Quand je conseille des fondateurs sur leurs recrutements tech, je leur donne toujours ces trois questions. Aucune ne demande de compétence technique pour être évaluée.

"Explique-moi ton dernier projet comme si j'avais 10 ans."

C'est la question la plus révélatrice que j'ai trouvée. Un bon développeur sait vulgariser. Il parle du problème résolu, de comment l'application fonctionne pour l'utilisateur, de ce qui était compliqué et pourquoi. Un dev qui bluff tourne en rond avec du jargon, noie le poisson dans des termes techniques. S'il ne peut pas expliquer ce qu'il a fait de façon simple, soit il n'a pas compris ce qu'il faisait, soit il n'a pas fait grand-chose.

"Qu'est-ce que tu ferais différemment si tu devais le refaire ?"

Un dev qui a vraiment bossé sur un projet en connaît les faiblesses. Il vous dira "j'aurais dû mieux structurer la base de données dès le départ" ou "on a choisi telle techno et c'était une erreur, voilà pourquoi". Un dev qui répond "non, tout était parfait" ? Il manque de recul. Ou il vous ment.

"Qu'est-ce que tu ne sais pas faire ?"

Un bon développeur dit "je ne sais pas" sans problème. Il connaît ses limites. Un dev qui dit tout savoir est dangereux — personne ne maîtrise tout en développement. Celui qui prétend le contraire est soit junior et ne sait pas ce qu'il ignore, soit il vous dit ce que vous voulez entendre. Dans les deux cas, mauvais signe.

Le test technique : utile, mais pas celui que vous croyez

Un fondateur que j'accompagnais — lui-même data analyst, pas manchot en logique — avait trouvé un test technique sur internet. Un test de chez Google. Algorithmes avancés, structures de données complexes, le genre de truc qu'on fait en prépa informatique. Il l'a envoyé à 12 candidats pour un poste de développeur web.

Résultat : zéro réponse. Pas une seule. Le poste est resté vacant 4 mois.

Son erreur : le test n'avait aucun rapport avec le poste. Il cherchait quelqu'un pour construire une application de gestion client — pas pour optimiser des algorithmes de tri. C'est comme recruter un commercial en lui demandant de résoudre une équation différentielle.

Un bon test technique, c'est un exercice proche du travail réel. Si le dev va construire une API, demandez-lui de construire un petit bout d'API. Si c'est une interface utilisateur, donnez-lui une maquette et 2 heures. Le candidat doit sentir que l'exercice est pertinent — sinon les bons ne le feront pas. Ils ont le choix, eux.

Le vrai problème pour vous : vous ne pouvez pas corriger le test vous-même. Deux options. Soit vous connaissez un dev de confiance qui peut évaluer le rendu en 30 minutes. Soit vous faites appel à un CTO externe qui gère cette partie. C'est un investissement de quelques centaines d'euros qui vous évite 6 mois de salaire gaspillé.

Freelance, CDI ou accompagnement externe : par où commencer

Avant de recruter un développeur, posez-vous une question : avez-vous besoin d'un dev à plein temps ?

Le freelance convient pour un besoin ponctuel — construire un MVP, une fonctionnalité spécifique, un projet de moins de 6 mois. Un bon freelance senior coûte entre 400 et 700€/jour. C'est cher, mais flexible : pas d'engagement long terme, pas de charges patronales. Pour trouver un bon freelance, la cooptation reste le canal le plus fiable. Malt et LinkedIn fonctionnent aussi, mais vous devrez trier. Les meilleurs freelances sont rarement en recherche active. Si vous hésitez entre développer vous-même avec l'IA ou recruter, j'ai comparé les approches no-code, vibe coding et développeur dans un article dédié.

Le CDI s'impose quand le développement est au cœur de votre activité. Un dev junior en CDI coûte entre 35 000 et 42 000€ brut annuel (hors Paris), un confirmé (3-5 ans) entre 45 000 et 58 000€, un senior 55 000 à 75 000€. Ajoutez 40 à 45% de charges. Paris, c'est 15 à 20% de plus. Un détail qui change tout dans votre offre d'emploi : indiquez la fourchette de salaire. Les annonces sans salaire reçoivent 30 à 40% de candidatures en moins. Et décrivez le problème que votre produit résout, pas une liste de technos — les bons devs candidatent pour un projet, pas pour un mot-clé.

Le CTO externe est l'option que personne ne connaît. Pas un dev qui code, mais quelqu'un qui structure vos décisions techniques : quel profil recruter, comment évaluer les candidats, quelle architecture choisir. Utile quand vous n'avez pas les moyens d'un CTO salarié (90K-130K€/an) mais que vous avez besoin de quelqu'un pour vous empêcher de faire des erreurs à 30 000€. Si ça vous parle, c'est exactement ce que je propose.

Les signaux d'alerte en entretien

Au fil des recrutements que j'ai accompagnés, certains red flags reviennent systématiquement. Aucun ne demande de compétence technique pour être repéré.

Le "oui" automatique. "Tu connais React ?" — Oui. "Et Vue ?" — Oui aussi. "Tu as fait du DevOps ?" — Bien sûr. Un dev qui dit oui à tout ne dit rien. Les bons développeurs nuancent : "j'ai utilisé ça sur un projet mais je ne suis pas expert", "je connais le concept mais je n'ai jamais fait en production".

Zéro question sur votre produit. Si le candidat ne demande pas ce que fait votre application, qui sont vos utilisateurs, quel problème vous résolvez — il s'en fiche de votre projet. Il cherche un salaire, pas une mission.

J'ai vu l'inverse aussi, et c'est flagrant. Un freelance se présentait comme "full-stack React/Node/AWS". En entretien, il répondait à tout avec une assurance imperturbable. Le fondateur l'a recruté. Trois semaines plus tard : 400 lignes de code. Le type "découvrait" AWS en facturant 550€/jour. Le fondateur ne l'a su qu'après avoir fait auditer le code. 400 lignes en 3 semaines pour un dev senior, c'est 10 fois en dessous de la normale.

Les références floues. Demandez des références et appelez-les. Pas "il est bon ?", mais "sur quel projet avez-vous travaillé ensemble et quel était son rôle exact ?" Cette formulation change tout. Un dev qui refuse de donner des références ou qui repousse ("je t'envoie ça plus tard"), notez-le.

Dernier signal, plus subtil : le candidat qui critique systématiquement ses anciens employeurs. Tout le monde a eu des missions difficiles. Mais quelqu'un qui passe l'entretien à démolir ses anciennes équipes reproduira le même comportement chez vous.

Le recrutement que personne n'aurait fait

L'histoire qui m'a le plus marqué. Une fondatrice cherchait son premier dev. Elle reçoit une candidature atypique : une ancienne responsable marketing en reconversion, 8 ans de marketing, formation de 6 mois en développement, zéro expérience en entreprise comme dev.

Le CV ne passait aucun filtre classique. Pas de grande école, pas de SSII, pas de stack impressionnante.

En entretien, cette candidate a fait quelque chose que les 8 autres n'avaient pas fait. Elle a posé des questions sur le produit. "Pourquoi vos utilisateurs choisissent votre app plutôt que le concurrent X ?" "Quel est le parcours qui génère le plus de friction ?" Elle avait même codé un mini-projet en lien avec le secteur de la startup. Pas demandé, pas exigé — elle l'avait fait pour comprendre le métier.

Six mois plus tard, c'était la meilleure recrue de l'équipe. Sa compréhension du produit et des utilisateurs compensait son manque d'expérience technique. Son code ? Propre, testé, documenté — elle avait appris les bonnes pratiques dès le départ, sans les mauvaises habitudes de certains devs "seniors".

La curiosité pour votre produit est un meilleur prédicteur de succès que le nombre d'années d'expérience. Un dev qui comprend pourquoi il code est plus performant qu'un dev qui sait juste comment coder.

Template : 10 questions d'entretien pour recruter un développeur sans être technique

Voici les questions que je recommande à tout fondateur non-technique. Pour chaque question, je vous donne ce que vous cherchez et ce qui distingue une bonne d'une mauvaise réponse.

Ce template ne remplace pas une évaluation technique — mais il filtre 80% des mauvais profils. Pour les candidats qui passent ce filtre, faites évaluer le test technique par quelqu'un de compétent.

Recruter sans comprendre le code, c'est possible

Recruter un développeur sans être technique, ce n'est pas recruter à l'aveugle. C'est recruter sur d'autres critères. La capacité à vulgariser, la curiosité pour votre produit, l'honnêteté sur ses limites — vous n'avez besoin d'aucune compétence technique pour évaluer ça.

Les deux erreurs qui coûtent le plus cher : recruter sur le CV sans vérifier, et renoncer à évaluer parce qu'on "n'y connaît rien". Vous n'avez pas besoin de comprendre le code pour identifier un bon dev. Vous avez besoin de poser les bonnes questions — et de faire évaluer la technique par quelqu'un qui s'y connaît.

Si vous n'avez personne en interne pour ça, un CTO externe peut structurer votre recrutement, évaluer les candidats et vous éviter les erreurs à 30 000€. C'est souvent le meilleur investissement qu'un fondateur puisse faire avant son premier recrutement tech.