Choisir un développeur freelance, c'est confier une partie de votre entreprise à une seule personne, souvent sur la foi d'un profil et d'un appel de trente minutes. Je suis de l'autre côté de la table depuis treize ans, et je vois bien ce que les clients demandent : le prix, le délai, la stack. Et ce qu'ils demandent rarement : où vivra le code, comment on saura que le projet dérape, et qui reprend si je ne suis plus là.
Cet article est écrit par une freelance, donc lisez-le avec ce biais en tête. J'ai essayé d'y mettre les questions que je voudrais qu'on me pose, y compris celles qui mettent le freelancing en difficulté. Si vous hésitez encore entre un freelance et une agence, commencez par mon comparatif freelance ou agence : ici, je pars du principe que vous avez tranché.
La règle que j'applique moi-même : une réponse précise et un peu inconfortable vaut mieux qu'une réponse rassurante et vague. Un bon développeur vous dit ce qu'il ne sait pas faire, ce qui l'inquiète dans votre projet et ce que vous n'aurez pas pour votre budget.
Le portfolio : ce qu'il faut vraiment regarder
Un portfolio rempli de maquettes Figma et de captures d'écran ne prouve qu'une chose : que quelqu'un sait faire de belles images. Ce que vous cherchez, ce sont des produits en production que vous pouvez ouvrir : une app sur les stores, un SaaS avec une page d'inscription, un site métier en ligne. Créez un compte, cliquez partout, regardez ce qui se passe sur mobile et quand vous vous trompez dans un formulaire.
- Demandez ce qu'il a fait lui-même sur chaque projet. « J'ai travaillé sur l'app de telle enseigne » peut vouloir dire « je l'ai conçue et livrée » ou « j'ai corrigé trois écrans pendant un mois ». Les deux sont honorables, mais ce n'est pas la même expérience.
- Cherchez des projets proches du vôtre par la nature (un back-office, une app grand public, une intégration d'IA), pas forcément par le secteur.
- Regardez si les produits vivent encore. Un produit maintenu depuis plusieurs années dit quelque chose de la solidité de ce qui a été livré.
Certains projets ne peuvent pas être montrés (outils internes, clauses de confidentialité). C'est normal, y compris chez moi pour une partie du travail mené avec de grands comptes. Dans ce cas, demandez une démo en visio ou un contact chez le client.
Questions 1 à 3 : expérience et références
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 1. Quel produit avez-vous mis en production récemment, et quel était votre rôle exact ? | Un produit nommé, un rôle précis, ce qui a bien marché et ce qui a coincé. | Une liste de technologies, aucun produit qu'on puisse ouvrir. |
| 2. Puis-je parler à deux anciens clients ? | Oui, avec des noms et un contexte pour chacun. | Des hésitations, ou uniquement des avis écrits impossibles à recouper. |
| 3. Quel type de projet refusez-vous ? | Une réponse claire, avec les raisons. | « Je fais tout. » Personne ne fait tout bien. |
Questions 4 à 6 : méthode et communication
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 4. Comment saurai-je chaque semaine où en est le projet ? | Une démo régulière du produit qui tourne et un environnement de test accessible en permanence. | « Je vous montre tout à la fin. » |
| 5. Qui sera mon interlocuteur, et qui écrit le code ? | La même personne que celle avec qui vous parlez, ou des intervenants nommés à l'avance. | Une sous-traitance non annoncée, découverte en cours de route. |
| 6. Que se passe-t-il quand vous prenez du retard ? | Il prévient dès qu'il le sait et propose un arbitrage : retirer, décaler ou ajouter. | « Je ne prends jamais de retard. » |
Le suivi au quotidien, une fois le contrat signé, je l'ai détaillé dans piloter un prestataire tech quand on n'est pas technique. Ici, l'enjeu est de vérifier avant de signer que ces rituels existent déjà dans sa façon de travailler.
Questions 7 et 8 : périmètre et prix
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 7. Comment avez-vous construit ce chiffrage ? | Un découpage par lots, des hypothèses écrites, une liste de ce qui est hors périmètre. | Un montant global donné après un seul appel, sans question sur votre besoin. |
| 8. Que se passe-t-il si je change d'avis en cours de route ? | Chaque demande nouvelle est chiffrée, et vous décidez ce qu'elle remplace ou ajoute. | « On s'adaptera », sans règle. Ça finit en dépassement ou en conflit. |
Pour lire et comparer plusieurs devis, voyez ma méthode d'estimation d'un devis tech. Je travaille moi-même au périmètre et au budget fixés avant de démarrer, mais ce n'est pas le seul modèle honnête : une régie bien suivie peut convenir à un projet très exploratoire. L'important est que le modèle soit clair et écrit.
Questions 9 et 10 : code, comptes et réversibilité
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 9. Sur quels comptes vivront le code, l'hébergement et le nom de domaine ? | Sur les vôtres, dès la première semaine. Il y est invité, vous restez propriétaire. | « Je gère tout sur mon compte, c'est plus simple. » |
| 10. Si on arrête demain, que récupérerai-je ? | Le code à jour, les accès, une documentation qui permet à un autre développeur de reprendre. | Une réponse floue, ou une « livraison du code » prévue seulement en fin de projet. |
C'est la question que je trouve la plus discriminante, et c'est pour ça que tout ce que je livre vit sur les comptes de mes clients. Le volet juridique (cession des droits, résiliation) est traité dans les clauses essentielles d'un contrat freelance, et la passation dans documentation et passation.
Questions 11 à 13 : qualité
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 11. Qu'est-ce que vous testez, et qu'est-ce que vous ne testez pas ? | Les parcours critiques (inscription, paiement, données) sont testés, et il assume ce qui ne l'est pas. | « Je teste tout » ou « les tests, c'est pour les gros projets ». |
| 12. Qui relit votre code quand vous travaillez seul ? | Une pratique concrète : relecture par un pair sur les parties sensibles, outils d'analyse automatique, ou au minimum une relecture différée de son propre travail. | Personne, et la question le surprend. |
| 13. Comment saurez-vous qu'il y a un problème en production avant mes utilisateurs ? | Un suivi d'erreurs et des alertes en place dès la mise en ligne. | « Vous me prévenez si quelque chose ne marche pas. » |
La question 12 est l'angle mort réel du freelancing : dans une équipe, la relecture est un réflexe, en solo il faut l'organiser. Sur la supervision, mon article sur l'observabilité d'un SaaS détaille le minimum utile.
Questions 14 et 15 : après la livraison
| Question | Bonne réponse | Signal d'alerte |
|---|---|---|
| 14. Que proposez-vous après la mise en ligne, et avec quels délais de réponse ? | Une période de garantie écrite, puis une formule de maintenance explicite, ou un refus clair que vous pouvez anticiper. | Rien de prévu, ou une disponibilité promise « quand vous voulez ». |
| 15. Si vous êtes malade ou indisponible plusieurs semaines, qui prend le relais ? | Un nom ou un réseau identifié, et un projet documenté pour que la reprise soit possible. | « Ça n'arrivera pas. » Ça arrive à tout le monde. |
Vérifier les références sans se contenter de politesses
Un ancien client appelé au téléphone dira presque toujours du bien du prestataire qui vous l'a recommandé. Pour obtenir une information utile, posez des questions qui appellent des faits :
- « Le projet a-t-il été livré dans le périmètre et le budget prévus ? Sinon, comment l'écart a-t-il été géré ? »
- « Comment a-t-il réagi à un problème ou à un désaccord ? »
- « Le produit est-il toujours en ligne, et qui le maintient aujourd'hui ? »
- « Le referiez-vous travailler sur un projet plus gros ? »
Écoutez les silences autant que les réponses. Un « oui, bien sûr » spontané à la dernière question vaut beaucoup. Une hésitation suivie de « sur ce type de projet, oui » vous dit exactement où sont ses limites.
Commencer par une phase courte et payée
Le meilleur test, ce n'est pas un entretien, c'est de travailler ensemble. Avant un engagement de plusieurs mois, proposez une phase courte, de quelques jours à deux semaines, avec un livrable concret :
- Un cadrage : périmètre écrit, découpage en lots, choix techniques justifiés, liste des risques. C'est ce que je décris dans cadrer un projet tech.
- Ou une première fonctionnalité réelle, livrée sur vos comptes, avec une démo à la fin.
Payez-la. Un test gratuit attire ceux qui ont du temps libre, pas forcément les meilleurs, et il ne vous donne aucun droit sur le résultat. Une phase payée vous laisse un livrable utilisable, même si vous choisissez quelqu'un d'autre ensuite. Et elle vous montre ce qu'aucun entretien ne montre : comment il pose des questions, comment il écrit, s'il tient ce qu'il a annoncé.
Junior ou senior
Un développeur junior peut être excellent sur des tâches bien définies, à condition que quelqu'un relise son travail et prenne les décisions d'architecture. Si vous n'avez pas d'équipe technique en interne, ce quelqu'un n'existe pas, et c'est vous qui portez le risque.
Ce qu'on paie chez un senior, ce n'est pas la vitesse de frappe. C'est la capacité à dire non à une fonctionnalité qui coûte trop pour ce qu'elle rapporte, à voir venir un problème de données ou de sécurité, à choisir une solution existante plutôt que de la réécrire. Le nombre d'années ne suffit pas à le garantir : demandez plutôt combien de produits il a menés du cadrage à la production, et ce qu'il ferait différemment aujourd'hui.
Freelance seul ou freelance avec un réseau
Soyons honnêtes sur les limites. Un freelance seul, c'est un seul cerveau, un seul agenda et une seule santé. Il ne peut pas être expert de tout, il part en vacances, et sa capacité ne double pas quand votre projet accélère. Aucune bonne volonté ne change ça.
Beaucoup de freelances seniors compensent avec un réseau : un designer, un expert mobile ou sécurité, un autre développeur capable de reprendre en cas d'absence. C'est mon cas : vous avez un seul contact senior, et une équipe derrière quand le projet le demande. Deux points à vérifier dans ce modèle :
- Les intervenants sont nommés avant de démarrer, et vous savez ce que chacun fait.
- La responsabilité reste unique : c'est votre interlocuteur qui répond du résultat, pas un sous-traitant que vous n'avez jamais rencontré.
Si votre projet demande d'emblée plusieurs personnes à temps plein pendant des mois, un freelance n'est probablement pas la bonne réponse, et un bon freelance vous le dira.
Le bon développeur freelance n'est pas celui qui répond oui à toutes vos questions. C'est celui dont les réponses vous permettraient de continuer sans lui.
Parlons de votre projet
Vous pouvez me poser ces quinze questions, c'est même ce que je vous recommande. En un appel de 30 minutes, on regarde votre projet, je réponds à tout ce qui vous préoccupe, et je vous dis franchement si je suis la bonne personne ou s'il vaut mieux chercher ailleurs. Réservez un créneau.
