1. Le marché du freelance tech en France en 2026
Commençons par les chiffres. En 2026, on estime à plus de 150 000 le nombre de développeurs exerçant en indépendant en France, en hausse d'environ 18 % depuis 2024. Le télétravail a rebattu les cartes de la géographie, mais pas totalement : un freelance basé à Paris facture encore 10 à 15 % plus cher qu'un profil équivalent en région.
Côté tarifs, les ordres de grandeur sont désormais assez stables sur les plateformes de référence (Malt, Free-Work, FreelanceRepublik, Comet) :
Junior (0-3 ans) : 300 à 450 € / jour selon la stack.
Confirmé (4-7 ans) : 450 à 600 € / jour.
Senior / expert (8 ans et plus) : 600 à 800 € / jour, davantage sur les expertises rares (data, cybersécurité, IA).
À titre de comparaison, une ESN facture en moyenne 20 à 30 % plus cher qu'un freelance à compétences équivalentes. Les plateformes prélèvent quant à elles une commission de 10 à 15 % sur la prestation.
Ces chiffres sont utiles pour cadrer un budget, mais ils ne disent rien du plus important : à l'intérieur d'une même fourchette, vous trouverez des profils qui vont livrer un outil propre, documenté et intégré à votre SI, et d'autres qui vont vous livrer une application isolée qui deviendra une dette technique dans six mois. La différence ne se lit pas sur un TJM.
2. Freelance, agence ou ESN : ce qui change vraiment
Trois options s'offrent à vous quand vous envisagez un projet logiciel. Chacune a un positionnement structurel qu'il est utile de comprendre avant de comparer les devis.
L'ESN (ex-SSII) vend de la ressource au jour. Elle place un ou plusieurs consultants chez vous, en régie ou au forfait. L'avantage : une équipe mobilisable rapidement, un contrat-cadre, des processus. L'inconvénient : vous payez des frais de structure importants, vous n'êtes pas toujours sûr du profil qui sera effectivement affecté à votre projet, et le turnover est une réalité. Le consultant qui a conçu votre système n'est certainement pas celui qui le maintiendra.
L'agence vend un livrable. Elle a tendance à proposer un package (design, dev, hébergement, maintenance) et à travailler au forfait. C'est adapté à un site web, un e-commerce sur plateforme standard, une application mobile clé en main. C'est plus discutable quand il s'agit d'un logiciel métier qui doit s'intégrer dans l'écosystème existant d'une PME, car l'agence applique souvent sa méthode et ses briques préférées, que ce soit adapté ou non.
Le freelance vend sa compétence directement. Pas d'intermédiaire, pas de marge de structure, un interlocuteur unique du premier appel au déploiement. En contrepartie, vous dépendez d'une seule personne : maladie, surcharge ou perte de motivation, ce risque est réel. Il faut l'adresser par le contrat et par la documentation, sans prétendre qu'il n'existe pas.
Le choix ne se fait pas entre "un freelance" et "une ESN" dans l'absolu. Il se fait entre un prestataire précis et un autre, évalués sur la nature exacte de votre projet.
Pour une PME dont le besoin est un outil métier sur mesure, une automatisation, ou la refonte d'un système qui ne suit plus, le freelance expérimenté est très souvent le meilleur rapport qualité-prix, à condition de savoir l'évaluer.
3. Le critère que personne ne regarde : la capacité d'architecte
La plupart des dirigeants évaluent un freelance sur trois éléments : sa stack technique, son portfolio, son TJM. Ces critères sont nécessaires. Ils sont aussi très insuffisants.
Un projet logiciel en PME n'échoue presque jamais parce que le développeur ne sait pas coder. Il échoue parce qu'il a codé la mauvaise chose, mal connectée au reste du système, sans comprendre ce qu'il y avait autour. Les chiffres sont connus depuis vingt ans : environ 70 % des projets IT dépassent délais ou budget, et les causes racines restent stables d'une étude à l'autre : spécifications floues, mauvaise compréhension métier, changements de périmètre en cours de route, outil qui ne s'intègre pas à l'existant.
Aucun de ces échecs n'est un problème de code. Ce sont tous des problèmes d'architecture au sens large : comprendre un processus métier, identifier où sont les données, où sont les frictions, quels systèmes doivent se parler, ce qu'il faut automatiser et ce qu'il faut laisser manuel.
Un bon freelance, pour une PME, ce n'est pas celui qui maîtrise le framework à la mode. C'est celui qui, au premier rendez-vous, pose plus de questions sur comment vous travaillez aujourd'hui que sur ce que vous voulez développer. Celui qui regarde votre ERP, votre compta, vos exports Excel et vos circuits de validation avant de parler technologie. Celui qui, parfois, vous dit que le projet tel que vous l'avez formulé n'est pas le bon, puis vous en propose un autre, plus simple, plus ciblé, qui résout le vrai problème.
Cette capacité à raisonner en système plutôt qu'en fonctionnalité se détecte en un entretien. Encore faut-il poser les bonnes questions.
4. Les questions qui disqualifient un prestataire en 15 minutes
Lors d'un premier rendez-vous, vous n'avez pas besoin d'évaluer la maîtrise technique du freelance, vous n'êtes pas développeur, ce n'est pas votre rôle. Vous avez besoin de détecter s'il raisonne en architecte ou en exécutant. Voici six questions qui permettent de trancher.
« Quels outils utilisez-vous aujourd'hui dans votre entreprise ? »
Posée par le freelance, pas par vous. Un prestataire qui démarre par cette question comprend que son logiciel va devoir cohabiter avec l'existant. Un prestataire qui attaque directement par « et techniquement, vous voulez du React ou du Vue ? » passe à côté du sujet.
« Où sont vos données aujourd'hui ? »
Dans un CRM ? Un ERP ? Des fichiers Excel partagés ? Une base Access qui traîne depuis 2011 ? Un freelance qui ne s'intéresse pas à l'état de vos données actuelles va vous livrer un outil joli, mais qui tombera en panne au premier import réel.
« Qui va saisir les données, et dans quel ordre ? »
C'est une question de processus, pas de logiciel. La réponse détermine toute l'ergonomie de l'outil. Si elle n'est pas posée, l'application sera conçue contre l'usage et finira par être contournée par vos équipes, qui repasseront sous Excel.
« Qu'est-ce qu'on met dans la v1, qu'est-ce qu'on garde pour plus tard ? »
Un freelance expérimenté sait découper. Il préfère livrer un périmètre restreint qui fonctionne en 8 semaines qu'un périmètre large qui sera à moitié fini au bout de 6 mois. Méfiez-vous du prestataire qui accepte tout votre cahier des charges sans discuter.
« Comment allez-vous documenter le projet ? »
Documentation fonctionnelle, documentation technique, procédure de reprise : c'est votre assurance contre la dépendance. Un freelance sérieux sait qu'il doit rendre son propre code compréhensible par un successeur, et il le prévoit dès le départ.
« Si je dois changer de prestataire dans 18 mois, qu'est-ce que je récupère ? »
La réponse doit être immédiate et concrète : le code source versionné, les accès aux serveurs, la documentation, les comptes techniques. Si le prestataire élude ou prétend que « ça ne se pose pas », c'est qu'il compte sur votre dépendance. Fuyez.
Un bon développeur freelance doit pouvoir être remplacé. Pas parce qu'on cherche à le remplacer, mais parce que tout ce qui ne peut pas l'être est une vulnérabilité pour votre entreprise.
5. Trois situations types de PME
Pour rendre tout ceci concret, voici trois contextes que je rencontre très régulièrement chez des dirigeants de PME. Vous vous reconnaîtrez peut-être dans l'un d'eux.
« J'ai un tableur Excel qui fait tourner toute mon activité, et tout le monde a peur de le toucher »
Le fichier a grossi pendant cinq ans. Il contient des formules que son créateur a oubliées, des macros qui plantent une fois par mois, des onglets cachés que personne n'ose supprimer. C'est devenu un outil critique mais instable. Vous cherchez un freelance pour « faire un vrai logiciel ». Le bon prestataire passera une demi-journée à cartographier ce que fait réellement le fichier avant de proposer quoi que ce soit, car 40 % des colonnes sont probablement inutilisées et 60 % du besoin ne se trouve probablement pas dans le fichier, mais dans les échanges d'e-mails autour.
« Mon ERP ne fait pas ce dont j'ai besoin, mais je ne peux pas en changer »
Migrer un ERP coûte entre 80 000 et 400 000 € et immobilise l'entreprise pendant un an. Dans 80 % des cas, ce n'est pas la bonne option. Le bon freelance ne vous proposera pas de le remplacer : il construira autour. Une surcouche qui lit les données de l'ERP via son API, ajoute les fonctions manquantes et renvoie les résultats dans les écrans que vos équipes connaissent déjà. C'est rapide, économique et réversible, exactement ce qu'un logiciel sur mesure doit être.
« J'ai trois outils qui ne se parlent pas et mes équipes ressaisissent tout »
Le CRM d'un côté, la facturation de l'autre, la compta encore ailleurs, et une assistante qui passe deux heures par jour à faire le pont entre les trois. C'est le scénario typique d'un projet d'intégration, qui coûte bien moins cher qu'un nouveau logiciel et dégage immédiatement du temps productif. Le bon freelance regardera les trois APIs, vérifiera ce qui est faisable directement et ce qui demande un middleware, puis vous livrera un résultat mesurable : X heures gagnées par semaine.
6. Sécuriser le projet sans brider le freelance
Une fois que vous avez identifié un prestataire crédible, il reste à cadrer la collaboration. Quelques points non négociables, qui ne coûtent rien à formaliser et évitent 90 % des litiges.
- Une phase de cadrage payée, courte, distincte du reste. Une à deux semaines pour auditer l'existant, produire une note d'architecture et un chiffrage réaliste. Sans engagement de la suite. C'est le meilleur test possible : un freelance qui refuse ce format n'a pas confiance dans sa propre capacité à scoper.
- Un découpage en jalons de 2 à 4 semaines. Chaque jalon produit quelque chose de testable. Vous payez au jalon livré, pas au temps passé. Cela oblige le prestataire à livrer incrémentalement, et vous permet de sortir à tout moment sans tout perdre.
- Le code vous appartient, le dépôt Git est chez vous. À la signature, vous ouvrez vos propres comptes (GitHub, hébergeur, services tiers) et le freelance y accède comme collaborateur. Jamais l'inverse. C'est la règle la plus simple pour éviter la captivité technique.
- Documentation livrée au fur et à mesure, pas à la fin. Un README technique, un guide d'utilisation, une note d'architecture. À chaque jalon, pas en bloc à la livraison finale, car la livraison finale arrive souvent dans la précipitation et la documentation passe à la trappe.
- Une clause de réversibilité explicite. Que se passe-t-il si vous arrêtez la collaboration ? Transmission des accès sous X jours, remise de la documentation, période de support minimale. Écrit, signé, daté.
Ces cinq points ne sont pas un signe de méfiance. Ils sont le signe qu'on traite le projet comme un projet d'entreprise, pas comme une prestation ponctuelle. Un bon freelance les propose de lui-même, souvent avant que vous n'y pensiez.
Un projet logiciel en tête ?
Structuration d'outils internes, automatisation, intégration entre systèmes, refonte d'applications métier qui ne suivent plus. 25 ans de métier, 13 en indépendant, 34 projets en production. Le premier échange est gratuit et sert à voir si le besoin est clair, ou à le clarifier ensemble.
Discutons de votre besoin