Recruter un développeur freelance : comment évaluer son expérience avant de lui confier un projet ?

Un portfolio montre un résultat. Il ne dit pas toujours ce que le développeur a réalisé, dans quelles contraintes ni ce qui s’est passé après la livraison. À l’inverse, un excellent professionnel peut ne pas pouvoir publier ses travaux pour des raisons de confidentialité. Évaluer l’expérience demande donc autre chose qu’un classement de sites séduisants ou une liste de technologies.

Le bon objectif est de vérifier l’adéquation entre une personne et votre projet. Une expertise reconnue sur un outil ne garantit pas la capacité à reprendre votre application, traiter vos données ou travailler avec votre organisation. Le processus doit produire des preuves utiles sans demander gratuitement une partie du futur chantier.

Cela commence par un besoin suffisamment clair pour être discuté.

Décrire le problème avant de chercher un profil

Rédigez une courte présentation du contexte : utilisateurs, tâches, système existant et difficulté à résoudre. Indiquez ce qui est déjà décidé et ce qui reste ouvert. Un projet décrit uniquement comme « application moderne avec IA » ne permet pas de comparer les candidats.

Précisez la nature de l’intervention : création, reprise, correction, intégration, migration ou maintenance. Reprendre un logiciel mal documenté exige notamment une capacité d’analyse et de sécurisation des changements. Construire un prototype demande d’autres arbitrages. Le même professionnel peut pratiquer les deux, mais les preuves à examiner diffèrent.

Ajoutez les contraintes essentielles : délai, budget disponible ou mode de chiffrage, hébergement, sécurité, données sensibles et disponibilité des interlocuteurs. Il ne s’agit pas de rédiger une spécification exhaustive avant tout échange, mais de rendre les hypothèses visibles.

Un candidat ne peut pas deviner vos contraintes.

Désignez une personne capable de répondre aux questions métier. Si chaque décision dépend d’un comité indisponible, la vitesse du développeur ne suffira pas à tenir le calendrier.

Transformer un portfolio en discussion technique

Choisissez une ou deux références proches par leur difficulté, pas nécessairement par leur secteur. Demandez le rôle exact : conception, développement, tests, intégration, déploiement ou maintenance. Une intervention limitée peut être parfaitement pertinente si elle est présentée honnêtement. Faites expliquer le problème initial, les options envisagées et les raisons du choix. Un professionnel expérimenté devrait pouvoir décrire les compromis avec un vocabulaire adapté à son interlocuteur. Les principes d’un portfolio qui explique le rôle et les choix permettent de structurer cette lecture, même lorsque la référence provient d’un travail collectif. L’objectif n’est pas de réciter une architecture impressionnante, mais de montrer un raisonnement.

Interrogez aussi les limites : ce qui a dû être reporté, une difficulté rencontrée, un choix à revoir ou une dépendance coûteuse. Une réponse qui ne contient aucun arbitrage apporte peu d’informations sur la manière de gérer un projet réel. Respectez la confidentialité. Le candidat peut présenter un cas anonymisé ou une architecture simplifiée sans communiquer le code d’un client. Refuser de transmettre un dépôt privé n’est pas un signe d’incompétence. Demander ces éléments sans autorisation serait au contraire un mauvais signal dans la relation.

Si une référence client est proposée, vérifiez son contexte et obtenez un contact autorisé. Posez des questions opérationnelles : qualité des échanges, gestion d’un incident, fiabilité des livraisons et facilité de reprise. Un avis général positif ne répond pas à toutes ces questions.

Évaluer la manière de comprendre le besoin

Un développeur ne devrait pas seulement confirmer qu’il peut tout faire. Les questions qu’il pose renseignent sur son approche : qui utilise l’outil, quel résultat est attendu, quels volumes sont envisagés, que se passe-t-il en cas d’erreur ?

Donnez un exemple de parcours utilisateur et demandez comment il serait clarifié. Le candidat peut proposer de vérifier des hypothèses, identifier un cas limite ou demander une donnée manquante. Cette démarche vaut souvent davantage qu’une estimation immédiate très précise sans investigation.

Observez la distinction entre besoin et solution. Si vous demandez un bouton d’export, le besoin peut être une transmission comptable ou une analyse régulière. Comprendre ce contexte aide à proposer le bon format, les droits et la fréquence. Cela ne signifie pas que le développeur doit remettre en cause chaque demande ; il doit savoir quand une question change la solution.

Un bon échange doit également faire apparaître les exclusions. Une application fonctionnelle peut nécessiter une prestation distincte de design, de rédaction, d’administration ou de migration. Le candidat doit préciser ce qu’il prend en charge et ce qui dépend d’autres intervenants.

Faire examiner un cas court et représentatif

Une évaluation pratique peut être utile si elle ressemble au travail attendu. Pour une reprise, proposez un extrait autorisé, sans données sensibles, ou un petit scénario technique. Pour une intégration, demandez l’analyse d’une documentation et des risques de synchronisation.

Évitez les exercices de concours sans lien avec le projet. Résoudre rapidement une énigme algorithmique ne démontre pas à lui seul la capacité à maintenir une application métier. À l’inverse, une manipulation simple ne suffit pas à valider une expertise de performance ou de sécurité.

Annoncez la durée, les livrables et les critères. Si l’exercice produit une valeur exploitable ou demande un travail significatif, prévoyez une rémunération et un cadre clair. Un diagnostic payé et limité peut constituer une première mission utile, indépendante du chantier complet.

Le livrable peut être une note : compréhension du contexte, risques, questions, options et prochaine étape. Vous évaluez alors la qualité de l’analyse et la clarté, sans exiger une fonctionnalité finie avant d’avoir contractualisé.

N’utilisez pas une note automatique comme décision unique. Une réponse peut paraître élégante tout en reposant sur une hypothèse fausse. Faites relire les points techniques importants par une personne compétente et indépendante si vous ne disposez pas de cette expertise en interne.

Les preuves à chercher dans le code et les livraisons

Si un échantillon de code peut être partagé légalement, examinez sa lisibilité, sa structure et la façon dont il traite les erreurs. Le style de nommage ne suffit pas. Les questions importantes concernent la compréhension, le test et la modification sans effet imprévu.

Demandez comment sont gérées les versions. Un historique de changements clair et des étapes de validation facilitent la reprise. Le dépôt doit être organisé dans un espace et avec des droits convenus, plutôt que rester une boîte noire sur le compte personnel d’un intervenant.

Les tests doivent correspondre au risque. Une application peut nécessiter des contrôles automatiques sur les règles métier, des tests d’intégration et une recette utilisateur. La présence d’un pourcentage de couverture élevé ne prouve pas à elle seule que les scénarios critiques fonctionnent.

Vérifiez le déploiement et le retour en arrière. Comment une nouvelle version est-elle mise en service ? Qui valide ? Comment les données sont-elles sauvegardées ? Quelle procédure suit-on si l’application ne démarre plus ? Ces réponses révèlent l’expérience de la production, au-delà de la démonstration.

La documentation doit permettre d’installer, exploiter et maintenir le projet. Elle n’a pas besoin de tout raconter, mais doit transmettre les dépendances, paramètres et procédures nécessaires. Un secret ne doit pas être stocké en clair dans un document partagé pour rendre l’installation plus facile.

Sécurité et données : vérifier les réflexes

Présentez un scénario d’accès : le prestataire doit consulter une base ou intervenir sur un serveur. Demandez comment il limiterait les droits et organiserait les accès. Un compte individuel, un périmètre adapté et une révocation prévue sont de meilleurs signes qu’un partage généralisé de mots de passe.

Évitez les données réelles en environnement de test lorsque des données synthétiques ou convenablement préparées suffisent. Le simple retrait des noms ne garantit pas qu’un jeu de données soit anonyme. Les combinaisons de champs peuvent permettre une réidentification.

Si le prestataire traite des données personnelles pour votre compte, examinez les rôles et les obligations contractuelles applicables. La qualification de sous-traitant au sens du RGPD dépend de la situation, pas uniquement du titre « freelance ». Les instructions, la confidentialité, la sécurité et les conditions de fin de prestation doivent être traitées.

Demandez comment les dépendances logicielles sont choisies et maintenues. Une bibliothèque peut accélérer le développement tout en introduisant une licence ou une charge de maintenance. Le candidat doit pouvoir expliquer ses choix et les limites de son intervention.

Aucun entretien ne certifie l’absence future de faille. Il permet de vérifier des pratiques et d’identifier les contrôles supplémentaires nécessaires pour le projet.

Comparer les propositions sur un périmètre commun

Deux devis ne sont pas comparables s’ils ne couvrent pas la même chose. L’un peut inclure la migration, les tests et l’accompagnement ; l’autre seulement le développement d’une fonctionnalité. Reconstituez les inclusions et les dépendances avant de comparer les montants.

Distinguez un forfait, une intervention au temps passé et une phase exploratoire. Chaque modèle répartit différemment l’incertitude. Une estimation ne devient pas exacte parce qu’elle affiche une seule valeur. Les hypothèses et les conditions de révision doivent être visibles.

Dans une simulation fictive, une proposition de dix jours à 600 euros représente 6 000 euros, tandis qu’une autre de douze jours à 550 euros représente 6 600 euros. Si la seconde inclut une reprise de données absente de la première, le tarif journalier seul conduit à une comparaison erronée. Ces chiffres sont illustratifs, pas des références de marché.

Examinez le calendrier réel : jours disponibles, dépendances aux validations et autres engagements. Dix jours de charge ne signifient pas nécessairement dix jours calendaires entre la signature et la livraison.

Clarifiez les corrections après recette et la maintenance. Une anomalie par rapport au périmètre accepté ne se confond pas avec une nouvelle demande. Les modalités doivent être établies avant que cette distinction devienne conflictuelle.

Contractualiser la continuité autant que la livraison

Le contrat doit préciser le périmètre, les livrables, les modalités de validation, le paiement et le traitement des changements. Les droits de propriété intellectuelle, les licences et les composants tiers méritent une rédaction adaptée. Le paiement d’une prestation ne doit pas être supposé régler automatiquement tous les droits sur tous les éléments.

Prévoyez les accès au dépôt, aux hébergements et aux services nécessaires. L’entreprise doit savoir qui détient les comptes et comment reprendre la main. Une réversibilité explicite protège aussi le prestataire en définissant ce qu’il doit transmettre à la fin.

Les obligations administratives doivent être vérifiées selon le contrat. En France, l’obligation de vigilance peut notamment s’appliquer à partir du seuil légal de 5 000 euros hors taxes, avec des vérifications prévues par les textes. Faites confirmer les pièces et la périodicité applicables plutôt que de réduire cette question à une formalité initiale.

Le mode de collaboration doit respecter l’autonomie réelle du prestataire. Une relation qui ressemble en pratique à un emploi subordonné soulève d’autres questions qu’un simple choix de contrat commercial. Faites examiner les situations ambiguës par une personne compétente.

Observer la communication pendant une petite phase de travail

Une courte phase contractualisée peut révéler la manière dont le développeur signale une incertitude. Regardez si les questions arrivent assez tôt, si les décisions sont résumées et si un obstacle est accompagné d’options. La fréquence des messages ne mesure pas à elle seule la qualité : un flot d’informations techniques peut rendre les arbitrages plus difficiles.

Définissez un point de contact et un canal de référence. Une décision prise oralement doit être confirmée lorsque son effet sur le périmètre ou le coût est important. Les échanges dispersés entre plusieurs messageries augmentent les risques d’instruction contradictoire.

Vous pouvez préparer ensemble une règle simple : quelle information exige une validation, qui répond et ce qui se passe sans réponse. Cela protège le calendrier tout en évitant que le prestataire tranche seul une décision métier. La capacité à dire « cette hypothèse doit être confirmée » constitue un élément d’expérience, pas un manque de confiance.

Si l’évaluation fait apparaître un besoin plus large de pilotage, distinguez ce rôle du développement. Un excellent technicien ne doit pas recevoir implicitement la responsabilité de coordonner tous les métiers sans moyens ni accord. Les fonctions, les disponibilités et les responsabilités doivent correspondre au contrat réel.

Décider à partir des risques restant ouverts

À la fin du processus, résumez les éléments établis : expérience comparable, raisonnement, capacité de livraison, communication et conditions contractuelles. Notez aussi les inconnues. Une sélection sérieuse n’exige pas que tout soit parfait ; elle exige de savoir ce qui reste à vérifier.

Si le doute porte sur une partie critique, commencez par une phase courte avec une sortie utile : audit, cadrage, prototype ciblé ou première fonctionnalité bien isolée. Les critères d’acceptation doivent permettre de décider de la suite sans dépendre d’une impression générale.

Le meilleur candidat n’est pas nécessairement celui qui promet le délai le plus court. C’est celui dont les compétences, la méthode et les conditions de travail correspondent au risque de votre projet, et dont les livrables pourront être compris et maintenus après son intervention.