Comment trouver un bon développeur de logiciels?
Demandez à voir quelque chose qu’il a bâti et qui roule encore en production, et parlez à la personne qui écrira réellement votre code plutôt qu’à un chargé de compte. Le signal le plus fort, c’est s’il pose des questions sur votre processus avant de vous faire une soumission; quiconque chiffre sans poser de questions devine.
Des filtres pratiques qui fonctionnent : demandez ce qu’il refuserait de bâtir et pourquoi, demandez à qui appartiendront le code et les comptes à la fin du projet, et demandez ce qui arrive si une intégration tombe en panne six mois plus tard. Des réponses vagues à l’une de ces questions sont la réponse complète. Un développeur qui a une vraie expérience en production a déjà refusé du travail et peut vous raconter l’histoire; un développeur qui dit oui à tout n’a soit jamais livré quoi que ce soit qui a dû survivre au contact des utilisateurs, soit l’intention d’apprendre avec votre budget.
Les captures d’écran d’un portfolio prouvent le design, pas la durabilité. Un système qui a survécu à deux ans d’utilisation réelle vous en dit plus que dix maquettes léchées — alors posez directement les questions de survie : est-ce qu’il roule encore, qui l’entretient maintenant, puis-je parler à ce client, et qu’est-ce qui a flanché la première année. La dernière est la meilleure question d’entrevue du métier. Tout flanche la première année; un bâtisseur capable de nommer ce qui a lâché et ce qu’il a changé en conséquence a les cicatrices pour lesquelles vous l’engagez vraiment. « Rien de spécial », ce n’est pas l’expérience qui parle.
Les acheteurs non techniques peuvent quand même évaluer la relation de travail, ce qui prédit les résultats mieux que n’importe quelle évaluation technique qu’ils pourraient mener. Surveillez : des explications en langage clair plutôt qu’un jargon utilisé pour impressionner; de la résistance quand vous demandez quelque chose qu’il juge mauvais — être d’accord avec tout est une stratégie de facturation, pas un service; et un premier jalon proposé qui est petit, concret et peu coûteux pour le juger. Structurez ensuite le mandat en conséquence : une première étape payée — un plan, une maquette, une tranche fonctionnelle de la partie la plus risquée — plafonne votre exposition et vous en apprend plus que n’importe quel nombre d’appels de références.
L’ère de l’IA a changé ce qu’il faut vérifier. La production mécanique de code n’est plus la compétence rare — un bon développeur qui bâtit avec l’IA livre en quelques jours ce qui prenait des semaines, et si un candidat ne travaille pas de cette façon, vous payez des prix d’avant l’IA pour une vitesse d’avant l’IA. Ce qui reste rare, c’est le jugement : le modèle de données, la conception des permissions, ce qu’il ne faut pas bâtir, et les questions posées sur votre processus avant d’écrire quoi que ce soit. Ce qui nous ramène au premier signal — les questions de découverte ont toujours été l’indice, et l’IA n’a fait que le renforcer, parce que générer coûte peu maintenant et que décider quoi générer, c’est désormais le travail.
Dernière révision le 28 août 2026