Bien choisir son développeur : les premiers critères de recrutement

Ancien fondateur et dirigeant d’une société de service spécialisée dans le développement d’applications mobiles, et actuellement CTO de WeMoms, je suis amené à rencontrer et recruter de nombreux développeurs. Étant développeur moi-même, je m’appuie sur mon propre rapport à la programmation pour évaluer un candidat.

La Voie du Code

A l’université, j’ai eu un professeur qui comparaît souvent le métier de développeur avec celui d’écrivain. En littérature, il y a autant de façons d’écrire une histoire qu’il y a d’auteurs, voire plus si on se prête au jeu des exercices de style. De même en développement, il y a autant de façons d’écrire un code qu’il y a de développeurs, voire plus si on considère le refactoring.

Un développeur possède son propre style. Comme un écrivain, un développeur lit beaucoup les productions des autres, non pour plagier mais pour enrichir son propre style. Il réécrit parfois (souvent) tout ou partie de son propre code pour l’améliorer, à l’instar de l’écrivain qui travaille son texte.

Et comme un écrivain, le développeur réalise un acte créatif. Avant, il n’y a rien. Après, il y a un texte écrit pour rencontrer le lecteur. Après, il y a un logiciel, conçu pour rencontrer l’utilisateur.

Au commencement, à mon sens, il y a deux types de développeurs.

Tout d’abord, celui qui fait le job : car c’est intéressant intellectuellement, car ce n’est pas trop difficile, car les projets sont (souvent) sympa, car le salaire est élevé, car les conditions sont bonnes…

Ensuite il y a celui qui ressent le développement. Pour lui, coder est un mode de vie : il perçoit le monde sous l’angle du développement. Il se surprend à réfléchir en logique booléenne. Il mène des projets personnels en parallèle de son travail. Il démarre, seul ou à plusieurs, plus de projets qu’il ne peut en achever. Le développement lui permet de ressentir une sensation d’accomplissement. Le développement lui permet d’exister.

De même qu’un bon écrivain écrit parce qu’il le doit, le développeur ne peut pas s’empêcher de coder. Dans le cadre professionnel ou en dehors, développer est une nécessité.

Lorsque je fais passer des entretiens pour recruter un nouveau collaborateur, c’est d’abord ce critère que je cherche à jauger. S’agit-il de quelqu’un qui travaille dans le développement par commodité, ou de quelqu’un pour qui le développement est “la voie” ?

Cette distinction est parfois difficile à faire. Pour cela je m’appuie beaucoup sur les projets personnels pour jauger, extra professionnels ou extra scolaires dans le cas des juniors.

Mais l’indice le plus parlant est cette lueur dans le regard de mon interlocuteur lorsque j’explique ce que j’éprouve quand je code, la sensation d’accomplissement après une journée efficace ou le plaisir généré par un refactoring qui réduit par deux le nombre de lignes d’une classe. Cette lueur qui indique “je comprends ce que tu dis parce que c’est ce que je vis moi-même”.

Le Pragmatique et le Perfectionniste

Au delà de ce premier tri qui, fondamentalement, distingue l’exécutant du créatif, je classe les développeurs sur une échelle de valeur qui va du Pragmatique au Perfectionniste.

À une extrémité du spectre, le Pragmatique est celui qui, avant toute chose, veut livrer. Quelle que soit la dette générée, quels que soient les raccourcis empruntés, son leitmotiv est d’abattre du périmètre. Il est motivé par l’avancement des tâches sur un tableau. Sa devise : “on s’en fout, ça marche”.

Ce profil est potentiellement dangereux, surtout s’il n’est pas encadré par une équipe à même de révéler ses travers. Au premier abord, en début de projet, il semble excellent. Il va plus vite que n’importe quel développeur.

Au fur et à mesure que le projet avance, sa vélocité se réduit. À ce moment là il compense généralement par plus d’ardeur au travail : ses journées s’allongent, son humeur devient massacrante, il passe petit à petit d’un statut de membre clé à celui qu’il devient pénible de piloter. Il répond volontiers “ce n’est pas possible” aux demandes d’évolutions. Et en réalité c’est vrai : ce n’est pas possible à un coût raisonnable.

À l’autre extrémité du spectre se trouve le Perfectionniste. Généralement amoureux de la technologie qu’il manipule, il en est un incomparable expert. Il est au fait de toutes les nouveautés qui la concerne, qu’il a déjà expérimentées dans un contexte plus ou moins pertinent. À son avis, “il faut absolument faire ça”, parce que c’est l’état de l’art, parce que c’est ce que préconise tel gourou, parce que c’est ainsi qu’est conçue la technologie concernée.

Sa propension naturelle est de faire et refaire les mêmes choses, d’améliorer jusqu’à la perfection. De remplacer telle brique par telle autre “parce que c’est mieux” (et il a souvent raison, c’est mieux dans l’absolu, si on écarte le contexte). De refactorer des bouts de codes qui ne le nécessitent pas. Il est aussi dangereux que le Pragmatique, mais dans un sens opposé : il ne délivre pas.

Au sein d’une équipe, il devient rapidement un handicap. Incapable de comprendre les enjeux business et les besoins des utilisateurs, il les remplace par des enjeux techniques, voire esthétiques.

Et alors quoi ?

Bien entendu il s’agit d’extrêmes et j’ai rencontré peu de développeurs qui se situaient vraiment à l’une ou l’autre des extrémités du spectre. Généralement chacun a une tendance naturelle plutôt dans un sens ou plutôt dans l’autre. Voire dans les deux, dans le meilleur des cas !

En effet, si les bons candidats savent se situer spontanément sur cette échelle, les meilleurs candidats hésitent et répondent généralement “ça dépend”. Et c’est vrai : ça dépend du contexte.

Soit je suis en train de travailler sur un sujet fondamental, et dans ce cas j’ai intérêt à laisser mon côté perfectionniste s’exprimer afin de maîtriser la dette et de sécuriser l’avenir. Soit je suis en train de faire un test, par exemple pour valider ou invalider une hypothèse, et j’ai intérêt à être pragmatique pour délivrer le plus vite possible le code qui me permettra de remplir mon objectif. Parfois c’est le contexte qui ne me laisse pas le choix : je dois faire des choix pragmatiques mais je dois également avoir la rigueur pour revenir améliorer plus tard un tel bout de code réalisé trop rapidement.


Les bons développeurs, ceux avec qui j’ai envie de partager un projet, ont la maturité nécessaire pour déterminer en pleine conscience dans quelle situation ils se trouvent. Ils savent en outre tenir compte des autres facteurs du contexte : les enjeux business, le temps dont ils disposent, l’équipe, le niveau de criticité, la valeur ajoutée, l’environnement… Et faire les bons choix en conséquence.

De nombreux autres facteurs entrent en compte en matière de recrutement : les tests techniques, le tempérament, l’empathie, la pédagogie, la capacité à travailler en équipe, la compatibilité avec la culture de l’entreprise…

Toutefois, après avoir déterminé si, d’une part, le candidat suit la Voie du Code et, d’autre part, s’il dispose d’un niveau de maturité élevé, une seule question compte vraiment : est-ce que, chaque jour de ces prochaines années, j’aurai plaisir à travailler avec lui ?