Mis à jour le 19 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Vous avez une idée de produit, et peut-être déjà des clients qui l’attendent. Il vous faut quelqu’un pour le construire. Recruter un salarié, c’est un salaire, des cotisations, et un préavis le jour où vous vous séparez. Vous pensez alors à un développeur indépendant, un freelance, trouvé dans votre réseau ou sur une plateforme de mise en relation, ou à une agence de développement, une entreprise dont le métier est de construire des logiciels pour d’autres.
Avant de comparer des développeurs ou des agences, comparez les contrats qu’ils proposent. Le contrat décide qui paie quand votre besoin change, quand vos utilisateurs auront le produit entre les mains, à qui appartient le code et comment vous pourrez partir. Les comptes qui font fonctionner votre application, et la suite le jour où la personne qui connaît le code n’est plus disponible, se règlent aussi avant le premier jour.
Il construit ce que vous lui confiez : une application web, une application mobile, une fonctionnalité ajoutée à un logiciel existant. Souvent, il choisit aussi les technologies.
Vous ne payez pas ce qu’un salarié coûte en plus de son salaire : ni cotisations patronales, ni congés payés, ni complément de salaire pendant un arrêt maladie, ni honoraires de cabinet de recrutement. Et vous travaillez directement avec celui qui développe, sans intermédiaire.
Vous choisissez aussi un développeur spécialisé dans la brique technique dont votre produit a besoin : une application mobile, un système de paiement en ligne, une connexion à un autre logiciel. Vous n’avez pas à salarier un profil généraliste à plein temps. Et il peut commencer tout de suite, alors qu’un candidat déjà en poste doit d’abord démissionner et effectuer son préavis chez son employeur actuel avant de vous rejoindre.
Il est payé pour son travail, que votre produit trouve ses clients ou non. Un cofondateur technique payé en parts, lui, lie son avenir à celui de votre entreprise.
Une agence construit ce qui n’existe pas encore : un site, une application mobile, un logiciel sur mesure. Vous n’avez ni poste à créer, ni période d’essai à attendre. Vous signez un contrat avec une entreprise, et le développement commence.
Quand un salarié, un associé ou un développeur indépendant écrit seul le logiciel, sa connaissance repose sur une personne. Une agence peut confier votre produit à plusieurs développeurs, et remplacer celui qui s’en va. Elle ne le fait pas toujours : demandez combien de personnes connaîtront votre code.
Un développeur indépendant ou une agence facture le plus souvent de deux façons. À la journée, c’est la régie : vous payez le temps passé, au tarif journalier convenu. Au projet, c’est le forfait à périmètre fixe : un prix pour une liste de fonctionnalités décrite à la signature.
Il existe une troisième façon de payer, qui ne repose pas sur une estimation. Au forfait à budget fixe et périmètre fonctionnel flexible, le prix est fixé, et le problème à résoudre aussi. Ce qui reste flexible, c’est la manière d’y répondre : les fonctionnalités développées.
Votre besoin changera en cours de route : vos premiers utilisateurs vous montreront ce qui manque et ce qui ne sert à rien. Chacun de ces contrats répond autrement à une question : qui paie ce changement ?
Au forfait à périmètre fixe, le prestataire porte l’erreur d’estimation sur la liste signée. Le client porte le changement de besoin, avenant après avenant. En régie, le client porte les deux. Le changement ne coûte pas d’avenant, mais chaque journée de plus s’ajoute à la facture.
Les écarts peuvent être lourds. Sur 4 677 projets informatiques, le coût réel atteint en moyenne 1,8 fois le coût estimé, soit 80 % de plus, d’après une étude publiée en 2022 par Bent Flyvbjerg, professeur à l’université d’Oxford, et ses coauteurs. Cette moyenne est tirée par une minorité de projets aux dépassements extrêmes : dans le même échantillon, le dépassement médian est proche de zéro. Mais personne ne sait, au moment de signer, de quel côté tombera son projet.
Au forfait à budget fixe et périmètre fonctionnel flexible, aucune liste de fonctionnalités n’est signée : le changement ne coûte ni avenant ni journée de plus. Le budget reste le même quand le besoin évolue ; les fonctionnalités développées s’adaptent. En contrepartie, ce modèle vous demande du temps. C’est vous qui décidez de ce qui a le plus de valeur pour vos utilisateurs, et vous réorientez les priorités quand votre marché change. Si vous ne pouvez pas y consacrer de temps, ce contrat vous conviendra mal.
Le forfait à périmètre fixe reste adapté à un besoin qui ne bougera pas. Un produit qui cherche encore ses clients n’est pas dans ce cas. Le prix et le planning ne se construisent pas de la même façon au forfait et en régie.
Le coût du développement d’un logiciel sur mesure repose sur le temps que vous décidez d’investir dans son développement et dans ses ajustements quotidiens pour suivre l’évolution de votre activité, au regard de ce que vous coûte son absence.
Avant de signer, posez cette question à votre prestataire : si mon besoin change, qu’est-ce qui change dans ce que je paie ?
Syntec Numérique, la fédération professionnelle des entreprises du numérique, aujourd’hui Numeum, a publié en 2015 avec le cabinet d’avocats Staub & Associés une fiche pratique sur le développement d’une application mobile. Elle s’adresse aux prestataires. Elle leur explique comment protéger leurs intérêts dans le contrat, notamment quand le client veut changer ce qui a été signé.
Le principe est posé ainsi : « le périmètre contractuel défini en commun dans le contrat ne pourra pas être modifié par le client de manière unilatérale ». La clause proposée en exemple ajoute : « Toute modification d’un document contractuel doit faire l’objet d’un avenant écrit entre les Parties ».
Pour une startup, cela pèse dès les premiers mois. Vos premiers utilisateurs vous apprennent ce qui leur manque, et ce qui ne leur sert à rien. Chaque modification de la liste signée devient un avenant, chiffré à part, que vous payez.
En 2020, le tribunal de commerce de Paris a rejeté la demande de remboursement d’une jeune entreprise qui avait fait développer deux applications mobiles et un site, sans cahier des charges, en méthode agile. Elle avait changé de prestataire, et réclamait les sommes versées au premier. Selon Le Monde Informatique, il a relevé que la méthode agile « conduit à de nombreux allers-retours entre les parties », et que les difficultés invoquées « ne présentent pas de caractère anormal ».
À notre avis, deux choses vous protègent alors : voir en continu le logiciel entre les mains de vos utilisateurs, et pouvoir arrêter le contrat dès qu’il ne vous convient plus.
La fiche de Syntec Numérique décrit aussi l’enchaînement d’un développement au forfait. Le prestataire réalise d’abord une maquette de l’application, le storyboard, qui comprend « les spécifications fonctionnelles détaillées ». Il veille à obtenir son acceptation par le client « avant de démarrer la réalisation des prestations de développements ».
Vient ensuite le développement, puis la recette, l’étape où le client vérifie que l’application est conforme. Dans la clause donnée en exemple, le client dispose de 10 jours pour une première vérification, puis de 30 jours de vérification en service régulier. Pour le prestataire, la signature du procès-verbal de recette est une étape importante : elle « libère le prestataire de ses obligations contractuelles et enclenche généralement un jalon de paiement significatif ».
Dans ce schéma, vos utilisateurs découvrent le produit une fois tout développé et vérifié. En régie, rien dans le modèle n’oblige à mettre un logiciel utilisable entre les mains de vos utilisateurs au fil du développement.
Or, pour une startup, c’est l’usage qui dit si le produit répond à un besoin. Plus tôt vos utilisateurs l’ont entre les mains, plus tôt vous savez quoi changer. Un premier produit minimal sert justement à le vérifier.
Demandez donc à votre prestataire quand vos utilisateurs pourront se servir du logiciel.
Marty Cagan, fondateur du Silicon Valley Product Group, un cabinet qui forme les équipes produit, a été vice-président senior produit et design d’eBay. Il distingue quatre risques dans tout produit : personne ne veut l’acheter ou s’en servir, personne ne comprend comment l’utiliser, on ne peut pas le construire avec le temps, les compétences et la technologie disponibles, ou il ne fait pas vivre l’entreprise. Il confie la faisabilité aux ingénieurs, et la demande des clients comme la viabilité pour l’entreprise au responsable du produit.
Dans votre startup, le responsable du produit, c’est vous. Le prestataire répond de la faisabilité. Savoir si des clients veulent de votre produit, et s’il fait vivre votre entreprise, reste votre affaire, quel que soit celui qui écrit le code.
Le droit du travail sépare de la même façon ce que vous décidez de ce que le prestataire décide. Un travailleur indépendant immatriculé est présumé ne pas être votre salarié (article L8221-6 du Code du travail). Cette présomption tombe s’il travaille pour vous « dans des conditions qui le placent dans un lien de subordination juridique permanente ». Pierre Bonneau, avocat associé en droit social chez CMS Francis Lefebvre, rappelle dans un article de 2016 que le juge regarde les conditions réelles du travail, et non ce qu’écrit le contrat. Parmi les indices qu’il cite : la fourniture des outils de travail, la fixation des horaires, un compte rendu régulier, une notation avec possibilité de sanction.
Si le lien de subordination est établi, l’Urssaf peut réclamer des cotisations, le développeur peut faire valoir devant les prud’hommes les droits d’un salarié, et l’infraction de travail dissimulé peut être retenue.
Vous fixez donc le résultat attendu, et vous jugez ce qui est livré. Les horaires, les outils et la façon de travailler restent les siens. Si vous voulez quelqu’un qui travaille à plein temps sous votre direction, c’est un salarié qu’il vous faut, par exemple un premier développeur.
Il en va de même avec une agence : elle choisit elle-même sa façon de travailler. Si vous voulez des développeurs dans votre équipe, à qui vous donnez le travail chaque jour, c’est un recrutement, ou une mise à disposition en régie. Dans ce dernier cas, le prestataire doit garder l’autorité sur les personnes qu’il met à disposition. Le Code du travail interdit toute opération à but lucratif ayant pour objet exclusif le prêt de main-d’œuvre (article L8241-1). Le risque apparaît quand le prestataire ne fournit que des personnes, sans prestation qui lui soit propre.
Juger ce qui est livré suppose de savoir le lire. Un fondateur qui n’est pas technique voit l’écran, pas le code.
Ce qu’il a construit, et ce qu’il a fait vivre. Avant de signer, demandez au prestataire de vous montrer un logiciel qu’il a mis en production, puis fait évoluer pendant plusieurs années. Et demandez à ses anciens clients comment il travaille quand un problème survient.
Un regard technique extérieur. Un CTO à temps partagé peut lire le code à votre place : il vérifie le travail livré, et défend vos intérêts auprès du prestataire.
Quand un salarié développe un logiciel dans le cadre de ses fonctions, les droits d’exploitation de ce logiciel reviennent à son employeur (article L113-9 du Code de la propriété intellectuelle). Cette règle vise les salariés, et ne s’applique ni à un développeur indépendant ni à une agence.
Payer la facture ne vous rend pas propriétaire du code. « La cession des droits n’est pas automatique en matière de propriété intellectuelle », rappelle le site d’information juridique Le Monde du Droit : le contrat de développement doit contenir une clause de cession. Ce qu’elle ne mentionne pas est réputé non cédé.
L’article L131-3 du Code de la propriété intellectuelle exige que chaque droit cédé fasse l’objet d’une mention distincte dans l’acte de cession. Il exige aussi que l’on délimite l’étendue de ces droits, leur destination, le lieu où ils s’exercent et leur durée. Précisez aussi dans le contrat si la cession est exclusive. Si elle ne l’est pas, le prestataire peut exploiter le même code ailleurs, ou le concéder à d’autres entreprises.
Une partie du code peut aussi rester au prestataire. La fiche de Syntec Numérique, destinée aux prestataires « de toutes tailles » qui développent des applications mobiles, leur conseille d’exclure par avance des droits cédés leurs « connaissances antérieures ». Sa clause type prévoit que le prestataire « reste pleinement propriétaire » des « moyens, procédés et savoir-faire » qu’il met en œuvre, et en concède au client « un droit d’utilisation non exclusif ».
Cette clause protège un savoir-faire que le prestataire réutilise d’un client à l’autre. Pour vous, elle signifie qu’une partie du code de votre application peut ne pas vous appartenir : vous avez seulement le droit de l’utiliser, sous licence. La même clause type autorise le client à sous-concéder cette licence « à toute personne de son choix » : c’est ce qui vous permettra de confier ensuite votre application à un autre développeur. Demandez quelles parties du code restent au prestataire, et vérifiez que votre contrat vous laisse cette liberté.
Sans cession, rien dans le contrat n’oblige à vous remettre le code le jour où vous le demandez. Un témoignage publié en 2008 sur LinuxFr.org raconte un tel cas. Faites relire la clause par un avocat avant de signer.
Un logiciel ne se résume pas à son code. Pour être en ligne, il lui faut aussi un nom de domaine, un hébergeur, et un dépôt, l’espace où son code source est conservé. Si ces comptes sont ouverts au nom du prestataire, c’est lui qui y a accès : vous aurez besoin de lui pour chaque modification, et pour partir.
Ouvrez ces comptes au nom de votre entreprise avant le premier jour de travail, et donnez-lui un accès. Pour une application mobile, faites de même avec les comptes qui permettent de la publier sur les magasins d’applications. Le jour où vous travaillez avec quelqu’un d’autre, vous retirez un accès.
Le Monde du Droit conseille, pour pouvoir accéder au code source si le prestataire fait défaut, un contrat d’entiercement : le code et sa documentation sont déposés chez un tiers, et mis à jour à une fréquence convenue. À notre avis, un dépôt ouvert au nom de votre entreprise règle la question plus simplement : vous avez le code chaque jour, sans attendre que le prestataire fasse défaut.
Avec un seul développeur, une autre mission, des congés ou une maladie suffisent à le rendre indisponible. Tant que la connaissance du logiciel n’est pas écrite, elle part avec lui.
Demandez-lui dès le début ce qu’un autre développeur aurait besoin de savoir pour reprendre le logiciel : comment l’installer, comment le mettre en ligne, quels tests vérifient qu’une modification ne casse pas ce qui fonctionnait. Et faites-le écrire, au fil du travail.
S’il est déjà parti, la reprise de l’application par un autre prestataire commence par rassembler les accès et écrire des tests avant toute modification.
Un prestataire se choisit aussi sur la façon dont on peut le quitter. Mélina Loupia, journaliste spécialisée en technologie et en cybersécurité, prévient dans un guide publié par Clubic en février 2026 : sans clause de réversibilité, une entreprise peut se trouver incapable de changer de prestataire sans perdre des mois de travail. Le contrat doit prévoir la récupération des données, l’accès aux configurations, la remise de la documentation et le délai de préavis. Ce préavis est souvent de deux mois. Mettre fin à une prestation de développement à prix et périmètre fixes a un coût : le Code civil permet au client de résilier le contrat même une fois le travail commencé, à condition de dédommager le prestataire de ses dépenses, de ses travaux et de tout ce qu’il aurait pu gagner (article 1794). Ces contrats prévoient souvent des pénalités de résiliation.
Une clause écrite ne prouve pas encore que le départ est possible. Seul un essai le prouve. Faites-le une fois, avant d’en avoir besoin : demandez qu’on vous remette le code et la documentation, puis confiez-les à quelqu’un d’autre que le prestataire. S’il parvient à faire fonctionner le logiciel à partir de ce qu’on vous a remis, vous pouvez partir.
La possibilité de partir change aussi la relation. À notre avis, quand le client peut mettre fin au contrat à tout moment, son prestataire a tout intérêt à bien faire son travail : sinon, le client met fin au contrat.
Y Combinator, un accélérateur de startups américain, conseille aux fondateurs qui ne sont pas techniques que leur équipe ait les compétences pour construire elle-même son produit, plutôt que de le confier à quelqu’un d’autre. Faire appel à un développeur indépendant ou à une agence, c’est confier son produit à quelqu’un d’autre. À notre avis, ce conseil compte surtout quand votre produit est d’abord une technologie, dont la difficulté technique fait la valeur. Les décisions techniques y sont des décisions stratégiques, et elles reviennent à un cofondateur technique.
À notre avis, un développeur indépendant est la bonne réponse quand le travail a un contour net et que quelqu’un d’autre que lui peut juger ce qu’il livre. Trois situations s’y prêtent.
Une compétence précise sur un produit qui existe déjà. Une connexion à un logiciel de comptabilité, un système de paiement en ligne.
Un MVP, le produit minimum viable. Ce n’est pas une première version du produit, mais le plus petit test qui vérifie que l’idée vaut d’être construite. Décidez avant la première ligne de code si ce test est jetable ou s’il deviendra la fondation de votre produit. S’il devient la fondation, son code doit être de qualité production dès le départ, et tout ce qui précède s’applique : la cession, les comptes, la reprise.
Un fondateur entouré. Un associé, un directeur technique à temps partagé ou un conseiller technique relit ce qui est livré.
Si votre produit doit évoluer pendant des années, le développeur qui le construit ne sera pas forcément celui qui le fera évoluer. La cession, les comptes et la documentation se règlent avant le premier jour.
À notre avis, une agence convient quand plusieurs développeurs doivent connaître le code de votre produit, à condition que le contrat le prévoie : demandez combien de personnes le connaîtront.
Un développeur indépendant ou une agence se paie en argent. Si votre produit doit avancer avant que vous ayez des fonds, il reste le cofondateur technique, payé en parts, au prix d’une partie de votre capital.
Parmi ces trois contrats, nous avons choisi le forfait à budget fixe et périmètre fonctionnel flexible, parce qu’un produit qui cherche ses clients change en route. Vous changez de direction quand vous voulez, en toute réactivité, sans avenant ni surcoût.
Nous prenons aussi les décisions techniques que demande votre produit, comme le ferait un directeur technique : les technologies, l’architecture, la façon de le tester et de le mettre en production. Nous les alignons sur vos objectifs.
Chez DEVEDANOS, nous développons votre logiciel sur mesure, utilisable en un mois, pour un budget mensuel fixe, et l’ajustons en continu à l’évolution de votre activité. Le budget se construit avec vous, à partir de vos chiffres et de vos objectifs : nous fixons ensemble le montant et le problème que votre application doit résoudre. Les utilisateurs de votre application s’en servent dès le premier mois de développement, et c’est leur usage qui définit la ou les fonctionnalités suivantes.
Notre approche est adaptative : elle prédit ce qui est prévisible, le budget mensuel et les jours de développement par mois, et ne cherche pas à prédire ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains.
Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Le code source, l’infrastructure, le pipeline de déploiement et la documentation sont votre propriété intellectuelle dès le règlement de la première mensualité. Période d’essai jusqu’à 15 jours ouvrés sur le premier mois : aucune facture si vous ne voulez pas des livrables.
Vous pouvez mettre fin au contrat par écrit à tout moment, sans justification. Pendant le mois de réversibilité, nous accompagnons votre équipe jusqu’à ce qu’elle puisse construire, tester et déployer sans nous. Le pipeline continue de protéger chaque modification future, quel que soit le développeur qui intervient.
Nous avons besoin d’une pleine autonomie sur la façon de travailler, du début à la fin du projet. Nous ne mettons donc pas de développeurs à disposition dans votre équipe, et nous ne prenons pas de projet dont vous fixez vous-même la méthode de travail. C’est cette autonomie qui nous permet de répondre d’une application utilisable en un mois, et de chaque régression.
Nous construisons notamment des marketplaces, des applications métier et des applications mobiles.
Vous cherchez un développeur ou une agence pour faire développer votre application ? On en parle ?
Comment intégrer l'IA dans son entreprise : partir d'une tâche précise, savoir quand une règle suffit, choisir entre un outil d'automatisation et un logiciel sur mesure, et connaître les risques.
Fichier Excel partagé entre plusieurs utilisateurs, erreurs, versions qui se croisent : quand le tableur est devenu une application, et ce que change le passage à une application web métier.
Reprise d'application web : ce qu'il faut récupérer avant de changer de prestataire informatique, pourquoi des tests précèdent toute modification, et quand une refonte s'impose.