Comment savoir si un développeur est bon quand je ne m’y connais pas en technologie?
Vous ne pouvez pas évaluer son code, alors évaluez son raisonnement. Un bon développeur explique les compromis en mots simples, vous dit ce qu’il ne bâtira pas et vous propose un premier jalon plus modeste plutôt qu’un seul gros jalon. L’assurance sans aucune réserve, c’est le signal d’alarme.
Demandez une petite première étape payée — un plan, une maquette, une démo fonctionnelle de la partie la plus risquée. Ce que vous recevez vous en apprend plus que n’importe quelle entrevue, et votre exposition reste limitée si la collaboration ne convient pas. Un développeur qui résiste à un petit premier jalon et pousse pour un seul gros contrat vous demande d’assumer tout le risque avant que l’un ou l’autre ait vu comment l’autre travaille.
Écoutez ce qu’il refuse. Un bon développeur vous dira quelles parties de votre idée ne devraient pas être bâties du tout — la fonction qu’un outil moins cher couvre déjà, l’exigence qui double le coût pour un cas qui arrive deux fois par année. Quelqu’un qui dit oui à tout n’est pas accommodant; soit il n’y a pas réfléchi, soit il compte facturer la découverte plus tard. Même chose pour les estimations : quiconque donne un prix ferme sans demander comment votre processus fonctionne vraiment devine, et c’est vous qui paierez l’écart entre la supposition et la réalité.
Il y a trois questions auxquelles tout développeur sérieux répond clairement, par écrit : à qui appartiennent le code et les comptes à la fin du projet, ce qui se passe quand une intégration cesse de fonctionner dans six mois, et ce qu’il ferait autrement si le budget était réduit de moitié. Une réponse vague à l’une d’elles, c’est toute la réponse. La question de la propriété, en particulier, distingue les bâtisseurs des locateurs — un arrangement où le développeur détient l’hébergement, le dépôt de code et les clés d’API transforme un projet ponctuel en levier permanent sur vous.
L’autre indice fiable, c’est la documentation. Si personne d’autre que lui ne peut comprendre comment la chose fonctionne — aucune logique écrite, aucune explication de ce qui communique avec quoi, des identifiants éparpillés dans ses comptes personnels — vous avez embauché une dépendance, pas un développeur. Pas besoin de lire du code pour le vérifier : demandez-lui de vous expliquer comment une fiche circule dans le système, et voyez si l’explication résiste à vos questions de suivi.
Enfin, regardez ce qu’il a en production, pas ce qu’il a dessiné. Des captures d’écran de portfolio prouvent le goût; un système qui a survécu à deux ans d’utilisation réelle, de vraies données et de vrais utilisateurs prouve l’ingénierie. Demandez à parler à un client dont le système est toujours en production. La façon dont ce client décrit la passation — fluide et documentée, ou dépendante et anxieuse — vous dit à quoi ressemblera votre propre deuxième année.
Dernière révision le 28 août 2026