Entrevue technique RS&DE : quelles questions poser aux développeurs

Le piège classique de l'entrevue RS&DE : demander « Sur quoi avez-vous fait de la recherche et développement ? » Presque toujours, la réponse est « Rien de spécial, on a juste développé le produit. » Les développeurs banalisent les problèmes qu'ils ont fini par résoudre. Votre rôle est de contourner cette modestie en posant des questions concrètes qui font ressortir les incertitudes et les essais.

Avant l'entrevue : se mettre dans le bon état d'esprit

Vous ne cherchez pas à évaluer la qualité du logiciel ni la compétence de l'équipe. Vous cherchez les moments où personne ne savait d'avance comment faire, et ce qui a été tenté pour y arriver. Annoncez-le clairement : « Je veux comprendre où ça a coincé techniquement, pas juger votre travail. » Les équipes s'ouvrent beaucoup plus quand le cadre est posé ainsi.

Ouvrir sur le concret, pas sur la « R&D »

• Quelle partie du projet vous a donné le plus de fil à retordre ?
• Y a-t-il eu un problème sur lequel vous êtes restés bloqués plus longtemps que prévu ?
• Qu'est-ce qui vous a obligés à faire des essais avant de trouver une approche qui tenait ?
• Y a-t-il une fonctionnalité que vous n'étiez pas sûrs de pouvoir livrer ?

Le mot « bloqué » est précieux : il mène directement aux incertitudes sans jamais prononcer le mot « RS&DE ».

Creuser l'incertitude technologique

Une fois un problème identifié, il faut établir qu'il s'agissait d'une vraie incertitude, et pas seulement de travail à faire :

• Saviez-vous au départ comment vous alliez résoudre ça, ou fallait-il le découvrir ?
• Est-ce qu'une solution existante, une bibliothèque ou de la documentation répondait au besoin ? Pourquoi pas ?
• Un autre développeur expérimenté aurait-il su d'emblée comment procéder ?
• Qu'est-ce qui rendait le résultat incertain : la performance, la précision, la montée en charge, une intégration, le matériel ?

Faire émerger l'expérimentation

C'est ici que se trouve la matière la plus solide pour le rapport. Les essais, surtout ceux qui ont échoué, démontrent la démarche systématique :

• Quelles approches avez-vous essayées avant celle qui a fonctionné ?
• Pourquoi avez-vous abandonné les premières ?
• Avez-vous dû refaire ou réécrire une partie ? Qu'est-ce qui ne marchait pas ?
• Comment avez-vous su qu'une approche était meilleure qu'une autre : mesures, tests, comparaisons ?

La question la plus rentable de toute l'entrevue : « Racontez-moi quelque chose que vous avez essayé qui n'a pas marché. » Les échecs sont la preuve directe de l'expérimentation, et ce sont eux qu'on oublie de noter.

Verrouiller la preuve et le temps

Avant de clore, sécurisez ce qui rendra le dossier vérifiable :

• Où retrouve-t-on la trace de ces travaux : dépôts de code, tickets, demandes de tirage ?
• À quelle période ces problèmes ont-ils été abordés ?
• Qui y a travaillé, et environ quelle part de leur temps ?

Quelques pièges à éviter

• Les questions fermées. « Avez-vous fait de la R&D ? » appelle un oui ou un non peu utile. Préférez « Racontez-moi… ».
• Se contenter de la première réponse. Le vrai problème technique apparaît souvent à la deuxième ou troisième relance.
• Accepter le jargon sans le traduire. Faites reformuler jusqu'à comprendre où était réellement la difficulté.
• Oublier les impasses. Un récit où tout a bien été est un récit incomplet.

Quand l'entrevue dépasse le cadre du cabinet

Sur des projets pointus (IA, systèmes distribués, performance, matériel), il devient difficile de relancer correctement sans comprendre la technologie. C'est précisément le moment de me confier l'entrevue : je parle aux développeurs dans leur langage, j'identifie les incertitudes admissibles et je vous remets une matière prête à rédiger. Vous gardez le pilotage du dossier et la relation client ; j'apporte la profondeur technique.