Devis freelance développeur : périmètre, recette, code

Ton client veut « un site avec un espace membre ». Tu écris deux lignes dans ton devis, il signe, et trois mois plus tard tu en es à quarante demandes de modification que personne n’avait prévues. Le devis freelance développeur sert à éviter cette situation : il fixe ce que tu construis, comment tu es payé, quand le travail est terminé et à qui appartient le résultat. Cet article ne revient pas sur les mentions communes à tous les devis, détaillées dans le guide du devis freelance. Il se concentre sur ce qui est propre au développement.

Que doit contenir un devis de développeur en plus des mentions habituelles ?

Au-delà de l’identité des parties, des prix, de la validité et de la signature, un devis de développeur précise le périmètre, le mode de facturation, l’échéancier de paiement, la procédure de recette, la maintenance, la propriété du code et les coûts tiers. Ce sont ces sept points qui font la différence entre un devis propre et un litige.

Les mentions de base ne changent pas d’un métier à l’autre. Si tu veux vérifier les tiennes avant d’aller plus loin, lis d’abord l’article sur le devis freelance. Ensuite, reviens ici pour compléter ton modèle avec les pièces propres au code. Et si tu en es encore au stade du lancement de ton activité, la page sur comment se lancer comme développeur web freelance pose le cadre général.

Comment décrire le périmètre sans écrire un cahier des charges de cinquante pages ?

Une page suffit pour un projet de petite ou moyenne taille, à condition qu’elle réponde à six questions. Pas besoin d’un document formel : le but est que toi et ton client lisiez la même chose.

1. Quel est l’objectif ? Une phrase, par exemple « permettre aux clients de réserver un créneau en ligne ».
2. Qui s’en sert ? Visiteurs, administrateur, équipe interne.
3. Quelles fonctionnalités sont incluses ? Une liste courte, avec des mots que le client comprend.
4. Qu’est-ce qui est exclu ? Paiement en ligne, application mobile, traduction, import de données existantes, tout ce qui pourrait être supposé.
5. Quelles contraintes techniques ? Hébergement imposé, outil existant à connecter, navigateurs à prendre en charge.
6. Qui fournit quoi ? Textes, images, accès aux comptes, avec une date limite.

Le point 4 est souvent oublié, alors que c’est lui qui te protège. Une exclusion écrite évite la discussion du type « je pensais que c’était compris ».

Exemple : Léo construit un site de réservation pour un salon de massage. Son périmètre inclut 5 pages, un formulaire de réservation avec envoi d’un e-mail de confirmation et un espace d’administration pour bloquer des créneaux. Il exclut le paiement en ligne, la traduction du site et la reprise des anciens rendez-vous. Quand le client demande ensuite le paiement en ligne, Léo ne dispute rien : il renvoie à la ligne « exclusions » et propose un devis complémentaire.

Forfait ou régie, lequel choisir pour ton devis ?

Le forfait convient quand le périmètre est clair et stable, la régie quand il évolue en cours de route. Dans un forfait, tu fixes un prix pour un résultat décrit. En régie, tu factures le temps passé, avec un tarif journalier ou horaire et une estimation de volume.

Critère	Forfait	Régie
Périmètre	Précis et stable	Flou ou évolutif
Qui porte le risque de dépassement	Toi	Le client
Ce que tu gagnes à travailler vite	Du temps libéré, donc une marge	Rien, tu factures moins
Piège principal	Les demandes qui s’ajoutent sans être facturées	Un client qui s’inquiète de ne pas voir le total
Adapté à	Site vitrine, module précis, petit projet	Exploration, produit en construction, renfort chez un client

Beaucoup de développeurs combinent les deux. Ils facturent le lot de départ au forfait, puis les évolutions en régie avec un tarif horaire écrit. Tu peux aussi proposer une phase de cadrage payante, d’une ou deux journées, qui produit le périmètre sur lequel tu chiffres ensuite le forfait. Annonce-la avant que le client demande le devis complet, pour qu’il sache dès le départ que le cadrage a un prix.

Pour un premier client ou un projet que tu n’as jamais fait, protège-toi. Soit le forfait comprend une marge pour les aléas, soit tu passes en régie plafonnée, avec un nombre de jours maximum au-delà duquel tu refais le point avec ton client. Pour calculer ton prix journalier, utilise le simulateur de TJM.

Comment échelonner les paiements ?

Pour un projet de quelques semaines ou plus, ne facture pas tout à la fin. Un acompte à la signature, des paiements à la livraison de chaque lot et un solde à la recette réduisent ton risque et celui du client.

Par exemple, tu peux répartir ainsi, avec 30 % à la signature, 40 % à la livraison du module principal, 30 % à la validation de la recette. Ce découpage est une pratique courante, pas une règle. L’important est que chaque échéance soit rattachée à un événement vérifiable (« livraison du lot 2 ») plutôt qu’à une date, car un projet qui prend du retard par la faute du client ne doit pas bloquer ta trésorerie.

Les délais de règlement et les pénalités de retard font partie des mentions générales. Elles sont expliquées dans l’article sur le devis freelance.

Comment cadrer la recette et les corrections ?

La recette est l’étape où le client vérifie que ce que tu livres correspond au devis. Sans elle, un projet n’est jamais vraiment terminé : le client peut revenir six mois plus tard avec une liste de points « à corriger » qui sont en fait de nouvelles demandes.

Écris quatre choses dans ton devis :

• La durée de la recette, par exemple dix jours ouvrés à partir de la livraison.
• Les critères, c’est-à-dire la liste des fonctionnalités décrites dans le périmètre.
• La forme de la validation, par un e-mail de confirmation ou un document signé.
• La période de corrections incluse après la livraison, avec une durée que tu choisis.

Distingue ensuite deux types de retours. Une anomalie est un défaut par rapport à ce qui était prévu, et tu la corriges sans supplément. Une évolution est une demande nouvelle, qui se chiffre. Cette distinction règle la plupart des tensions de fin de projet.

Tu peux aussi prévoir qu’en l’absence de retour du client dans le délai de recette, la livraison est considérée comme acceptée. C’est une clause contractuelle qui se discute avec ton client. Si le projet est sensible, fais relire ta rédaction par un juriste.

Comment traiter les demandes qui sortent du périmètre ?

Une demande hors périmètre se traite par un devis complémentaire ou un avenant écrit, jamais par un accord oral. Tu chiffres le supplément, le client le valide, puis tu l’ajoutes au planning.

Pour que la discussion reste simple, écris dans ton devis deux règles, le tarif horaire ou journalier applicable à toute demande supplémentaire, et le nombre de tours de modifications inclus sur les parties visuelles (par exemple deux). Tu évites ainsi la situation où chaque petit changement devient une négociation.

La maintenance se met-elle dans le devis ou à part ?

La maintenance se met à part, dans un contrat ou une ligne séparée, parce qu’elle ne répond pas à la même logique que le projet. Le projet se termine, la maintenance dure. Mélanger les deux conduit à des corrections gratuites qui s’étirent indéfiniment.

Dans une offre de maintenance, précise :

• ce qui est couvert, comme les mises à jour de sécurité, les sauvegardes, la surveillance et les corrections d’anomalies ;
• ce qui ne l’est pas, par exemple les nouvelles fonctionnalités, la refonte ou le contenu ;
• les délais de réponse, par exemple sous deux jours ouvrés ;
• la forme, forfait mensuel ou heures prépayées à consommer ;
• la durée d’engagement et le préavis de résiliation.

La maintenance est aussi ta meilleure source de revenus récurrents. Propose-la systématiquement à chaque livraison, même si le client la refuse au premier projet : elle crée une relation durable et souvent des missions suivantes.

À qui appartient le code après la livraison ?

Sans écrit, tu restes titulaire des droits sur ton code. Le Code de la propriété intellectuelle (article L111-1) précise que la conclusion d’un contrat de louage d’ouvrage ou de service n’enlève rien aux droits de l’auteur. Pour que le client puisse utiliser, modifier ou revendre ce que tu as développé, il faut une cession ou une licence écrite.

La cession des droits est encadrée par l’article L131-3 du Code de la propriété intellectuelle : chacun des droits cédés doit faire l’objet d’une mention distincte, et le domaine d’exploitation doit être délimité selon son étendue, sa destination, son lieu et sa durée. Autrement dit, une phrase vague du type « le code appartient au client » ne suffit pas.

Voici les choix à faire et à écrire dans ton devis :

• Cession ou licence. Tu cèdes les droits d’exploitation, ou tu accordes une licence d’utilisation, parfois limitée dans le temps ou à un usage précis.
• Le moment du transfert. Le plus prudent est de le lier au paiement complet du prix.
• Les composants tiers. Les bibliothèques open source, thèmes et extensions gardent leur propre licence. Tu ne peux pas les céder.
• Tes briques réutilisables. Réserve-toi le droit de réutiliser ton savoir-faire et tes outils génériques pour d’autres clients.
• La livraison du code source. Précise si le client reçoit un accès au dépôt, une archive ou seulement le site en ligne.

Plus tu cèdes, plus ton prix devrait en tenir compte. Les clauses de cession et les conditions générales font aussi l’objet de l’article sur le contrat freelance.

Quels coûts tiers faut-il prévoir dans le devis ?

Un projet web s’accompagne souvent de dépenses qui ne sont pas ton travail : nom de domaine, hébergement, licences de thèmes ou d’extensions, API payantes, outil d’envoi d’e-mails. Décide à l’avance qui les paie et au nom de qui.

La bonne pratique est que ces comptes soient ouverts au nom du client, pour qu’il garde l’accès à ses outils si votre collaboration s’arrête. Si tu avances les frais, refacture-les à l’identique ou avec une marge indiquée dans le devis, jamais de manière implicite.

À quoi ressemble un devis de développeur complet ?

Voici un exemple de lignes pour le projet de Léo. Les montants sont fictifs et reposent sur un prix journalier de 400 € : remplace-les par ceux que ton calcul de prix plancher te donne.

Poste	Description	Quantité	Prix HT
Cadrage	Validation du périmètre et du planning	1,5 jour	600 €
Site	Intégration de 5 pages	3 jours	1 200 €
Réservation	Formulaire, e-mail de confirmation, espace d’administration	4 jours	1 600 €
Recette	Tests avec le client, 2 tours de corrections inclus	1 jour	400 €
Mise en ligne	Déploiement et prise en main	0,5 jour	200 €
Total		10 jours	4 000 €

Sous le tableau, ajoute les conditions propres au développement :

• exclusions, avec le paiement en ligne, la traduction et la reprise des données existantes ;
• échéancier, avec 1 200 € à la signature, 1 600 € à la livraison du module de réservation, 1 200 € à la validation de la recette ;
• recette, dix jours ouvrés puis une période de corrections de trente jours après la mise en ligne ;
• hébergement et nom de domaine, ouverts au nom du client, hors devis ;
• maintenance sous contrat séparé, sur demande ;
• propriété, avec cession des droits d’exploitation au paiement complet, hors composants tiers.

Tu peux afficher les jours ou seulement un prix par lot. Si tu montres les jours, le client voit que chaque modification a un coût en temps. Si tu masques les jours, tu es libre de ton organisation, mais le périmètre doit être encore plus précis.

Devis freelance développeur, par quoi commencer ?

Reprends ton dernier devis ou ton modèle et ajoute, dans l’ordre, une ligne d’exclusions, une procédure de recette, une phrase sur la propriété du code et une offre de maintenance à part. Ces quatre ajouts couvrent l’essentiel des litiges que rencontrent les développeurs indépendants. Ton prochain devis freelance développeur sera plus long de quelques lignes, et il t’évitera des semaines de discussions.

Questions fréquentes

Un devis signé peut-il être modifié ?

Oui, avec l’accord des deux parties, par un avenant écrit ou un devis complémentaire. Évite les modifications par message oral ou par échange informel, qui sont difficiles à prouver en cas de désaccord.

Un devis suffit-il comme contrat ?

Un devis signé engage les deux parties sur ce qu’il contient. Pour un projet important, complète-le par un contrat ou des conditions générales qui couvrent les points que le devis ne peut pas porter seul, comme la confidentialité ou la responsabilité.

Que faire si le client ne valide jamais la recette ?

Prévois dans le devis un délai de recette et une conséquence en cas de silence, par exemple une acceptation tacite. Relance par écrit à l’approche de la date limite, pour pouvoir t’y référer ensuite.

Peut-on facturer l’établissement du devis ?

Pour un petit projet, le devis reste gratuit en pratique. Pour un projet qui demande une vraie analyse, tu peux proposer une phase de cadrage payante, à condition de l’annoncer avant de commencer le travail.

Faut-il utiliser un modèle de devis tout fait ?

Un modèle fait gagner du temps pour la forme, mais il ne remplace pas la description du périmètre, qui change à chaque projet. Prends un modèle pour la structure, puis écris toi-même les exclusions, la recette et la propriété du code.