Contrat freelance développeur web : les clauses qui comptent vraiment
Un contrat de développement se joue sur quatre clauses : la cession des droits sur le code (qui n'est jamais automatique pour un indépendant), la recette et sa validation tacite, le sort des dépendances open source, et la frontière entre garantie de conformité et maintenance facturée.
La clause qui décide de tout : la propriété du code
C'est le malentendu le plus coûteux du métier. Un client qui a payé une prestation de développement croit spontanément détenir le code. Juridiquement, ce n'est pas le cas tant qu'une cession n'a pas été consentie dans les formes.
Le logiciel est protégé par le droit d'auteur. L'article L.113-9 du CPI prévoit une dévolution automatique des droits à l'employeur pour les logiciels créés par des salariés dans l'exercice de leurs fonctions. Cette règle ne s'applique pas à un prestataire indépendant. Pour un freelance, la cession doit être expresse et écrite, et respecter les exigences de l'article L.131-3 du CPI : chaque droit cédé mentionné distinctement, avec l'étendue, la destination, le lieu et la durée.
💡 Clause à trois étages, la plus solide en pratique. (1) Cession exclusive des droits patrimoniaux sur les développements spécifiques, (2) sous condition suspensive du paiement intégral, (3) avec réserve expresse de vos composants préexistants, concédés au client sous licence non exclusive, perpétuelle et irrévocable pour les besoins du projet.
Vos briques réutilisables : la clause de réserve
Aucun développeur ne repart d'une page blanche. Vos utilitaires, votre boilerplate, vos hooks, votre couche d'authentification constituent votre capital. Sans clause de réserve, une cession exclusive rédigée largement peut être lue comme vous privant du droit de les réutiliser chez un autre client.
La formulation à insérer distingue trois catégories : les développements spécifiques (cédés), les composants préexistants du prestataire (licenciés, non cédés), et les composants tiers (soumis à leurs propres licences).
Les dépendances open source : la clause qu'on oublie
Votre livrable embarque des dizaines de bibliothèques tierces sous licences variées. Vous ne pouvez pas céder au client des droits que vous ne détenez pas.
- Prévoyez une clause précisant que les composants tiers restent régis par leurs licences respectives.
- Annexez, si le projet est significatif, la liste des dépendances et de leurs licences.
- Signalez explicitement les licences à effet contaminant (type copyleft) si le client envisage une distribution commerciale : c'est un sujet qui peut ressurgir des années plus tard lors d'un audit de due diligence.
Recette et validation : la clause anti-blocage
Le scénario classique : vous livrez, le client ne teste pas, et votre facture attend. La parade est une procédure de recette écrite :
- Livraison sur un environnement de recette identifié.
- Délai de test défini, par exemple 10 jours ouvrés.
- Retours formalisés par écrit, dans un canal unique, qualifiés en anomalies bloquantes / majeures / mineures.
- Validation tacite à l'expiration du délai en l'absence de retour.
- Nombre d'itérations de correction incluses.
La qualification des anomalies évite l'autre piège : une demande d'évolution présentée comme un bug. Définissez l'anomalie par écart au cahier des charges, pas par insatisfaction.
Garantie de conformité ≠ maintenance
| Garantie de conformité | Maintenance | |
|---|---|---|
| Objet | Anomalies par rapport au périmètre convenu | Évolutions, mises à jour, support |
| Durée | Période définie après recette (souvent 1 à 3 mois) | Contrat séparé, récurrent |
| Prix | Inclus | Facturé |
Sans cette distinction écrite, tout devient « du SAV ». Si la maintenance est prévue, un contrat de prestation récurrente au forfait mensuel est le bon véhicule.
Dépôt Git, accès et fin de mission
Trois points à écrire noir sur blanc :
- Où vit le code : idéalement sur une organisation appartenant au client, à laquelle vous êtes invité. Cela évite toute ambiguïté sur la détention.
- Les accès reçus : hébergement, base de données, API tierces, comptes de service. Listez-les, et prévoyez leur restitution ou révocation en fin de mission.
- La documentation de livraison : README d'installation, variables d'environnement, procédure de déploiement. Précisez ce qui est inclus, sinon la demande arrivera après la dernière facture.
Obligation de moyens, et responsabilité plafonnée
Stipulez une obligation de moyens. Un engagement de résultat sur des performances, une disponibilité ou un référencement vous rend responsable de facteurs que vous ne maîtrisez pas — hébergement, charge réelle, évolutions d'API tierces.
Plafonnez la responsabilité au montant total facturé sur la mission et excluez les dommages indirects : perte d'exploitation, perte de données, préjudice commercial. Un bug en production dans un tunnel de paiement peut représenter un préjudice sans commune mesure avec le montant de votre prestation.
Le cas de la régie chez le client
Missions longues, dans les locaux du client, avec ses outils et son management : c'est le terrain de la requalification en salariat déguisé. Le contrat doit préserver votre autonomie : pas d'horaires imposés, pas de lien hiérarchique, livrables définis, liberté d'organisation. Le contrat de mission au TJM est conçu pour ce format.
Questions fréquentes
Le client est-il automatiquement propriétaire du code que je développe ?
Non. Le transfert automatique des droits sur un logiciel à l'employeur, prévu par l'article L.113-9 du Code de la propriété intellectuelle, ne vaut que pour les salariés. Pour un prestataire indépendant, les droits restent à l'auteur tant qu'une cession écrite et conforme aux exigences légales n'a pas été consentie.
Peut-on réutiliser du code écrit pour un client précédent ?
Oui pour vos briques génériques et votre savoir-faire, à condition de l'avoir prévu au contrat sous forme d'une clause de réserve sur vos composants préexistants, assortie d'une licence d'utilisation accordée au client. Non pour du code spécifique déjà cédé de manière exclusive.
Qui doit héberger le dépôt Git pendant la mission ?
À trancher explicitement. Le plus sûr est un dépôt appartenant au client, sur lequel vous disposez d'un accès. Travailler sur un dépôt personnel crée une ambiguïté sur la détention du code et complique la fin de mission.
La maintenance est-elle incluse après la livraison ?
Seulement si le contrat le prévoit. Il faut distinguer la garantie de conformité, qui couvre gratuitement les anomalies constatées pendant une période définie, de la maintenance évolutive, qui est une prestation distincte et facturée.
Que se passe-t-il si le client fournit des specs incomplètes ?
C'est le principal facteur de dérapage. La parade contractuelle est une clause d'obligations du client couplée à une clause de suspension des délais en cas de retard ou d'insuffisance des éléments fournis.
Votre contrat de prestation développeur, personnalisé et conforme.
Générer mon contrat →