Contrat de prestation de services pour développeur freelance gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous commandez un développement au forfait. Une PME confie à un développeur freelance la réalisation d’une application ou d’un module, avec un périmètre défini par un cahier des charges et un livrable soumis à recette. La prestation aboutit à un résultat identifiable dont la conformité conditionne le paiement du solde. Le contrat doit décrire ce livrable avec assez de précision pour que sa vérification soit possible.

Vous renforcez une équipe technique en régie. Une ETI intègre un développeur indépendant à un projet en cours, facturé au temps passé sur la base d’un taux journalier. La mission n’a pas de livrable unique, mais une capacité de travail mise à disposition. La régularité de la prestation, la durée et l’autonomie du prestataire deviennent alors les points sensibles du texte, car la régie longue durée chez un client unique concentre le risque de requalification.

Vous externalisez la maintenance d’une application existante. Une société délègue à un freelance la correction des anomalies et les évolutions mineures de son système. Le contrat organise une prestation à exécution successive : périmètre de la maintenance, délais d’intervention, conditions de reconduction et sort du code modifié.

Vous travaillez avec un prestataire individuel. Un développeur en freelance conclut le même contrat qu’une agence, avec une vigilance renforcée : documenter l’indépendance réelle du prestataire, qui organise librement son travail et conserve d’autres clients, pour écarter tout risque de requalification en contrat de travail. La nature intuitu personae de la mission, liée à la compétence d’une personne précise, mérite d’être stipulée.

Quand ce modèle ne convient pas. Si vous éditez un logiciel destiné à être commercialisé sous licence, un contrat de licence ou d’édition complète le dispositif. Si le développeur est intégré à vos équipes, reçoit des directives permanentes et n’a pas de clientèle propre, aucun contrat commercial ne neutralisera le risque social : la relation relève du salariat. Pour une relation-cadre appelée à donner lieu à plusieurs commandes successives, un contrat cadre de services assorti de bons de commande est plus adapté.

Ce que dit le droit français

La prestation de développement relève du contrat d’entreprise. Le Code civil range le louage d’ouvrage aux articles 1710 et 1779 et suivants : une partie s’engage à faire quelque chose pour l’autre, moyennant un prix convenu. C’est un contrat innommé qui relève du droit commun des contrats, articles 1101 et suivants. Ce cadre laisse une grande liberté de rédaction, ce qui rend la qualité du contrat entièrement tributaire de sa clarté. L’objet et les livrables doivent être déterminés ou déterminables, conformément à l’article 1163 du Code civil.

L’obligation du développeur est de moyens ou de résultat. Cette distinction, d’origine jurisprudentielle, commande le régime de preuve. Dans l’obligation de moyens, le client doit prouver un manquement à la diligence attendue ; dans l’obligation de résultat, l’inexécution suffit à engager le prestataire, sauf cause étrangère. Le développement logiciel relève le plus souvent d’une obligation de moyens, car le résultat dépend aussi des spécifications et de l’environnement du client. La responsabilité contractuelle se fonde sur l’article 1231-1 du Code civil.

La cession du code doit être constatée par écrit. Le paiement d’une prestation n’emporte pas cession des droits d’auteur sur le logiciel. L’article L. 131-2 du Code de la propriété intellectuelle impose un écrit, et l’article L. 131-3 exige que chaque droit cédé soit mentionné distinctement, avec délimitation de son domaine d’exploitation quant à l’étendue, la destination, le lieu et la durée. Sans clause de cession de droits d’auteur conforme, le client qui finance un développement n’en devient pas titulaire.

Les délais de paiement entre professionnels sont plafonnés. L’article L. 441-10 du Code de commerce fixe un délai de trente jours à défaut d’accord, et un plafond de soixante jours à compter de l’émission de la facture, ou quarante-cinq jours fin de mois si les parties le prévoient expressément. Le contrat doit stipuler les pénalités de retard, d’un taux au moins égal à trois fois le taux d’intérêt légal, et l’indemnité forfaitaire de recouvrement. [À VÉRIFIER JURISTE : montant en vigueur de l’indemnité forfaitaire, fixé par l’article D. 441-5 du Code de commerce.]

Le lien de subordination fait basculer la qualification. Le juge requalifie une prestation en contrat de travail lorsque les conditions réelles d’exécution révèlent une subordination : directives permanentes, contrôle et sanction, intégration à un service organisé. L’article L. 8221-6 du Code du travail pose une présomption de non-salariat pour l’indépendant immatriculé, mais cette présomption cède devant la preuve d’une subordination effective. L’enjeu est lourd : le travail dissimulé de l’article L. 8221-5 expose à une indemnité forfaitaire de six mois de salaire selon l’article L. 8223-1, outre les rappels de cotisations.

Les clauses limitant la responsabilité connaissent des bornes. Une clause qui prive de sa substance l’obligation essentielle du prestataire est réputée non écrite, en application de l’article 1170 du Code civil. Une clause limitative ne joue pas non plus en cas de faute lourde ou dolosive, mais reste valable entre professionnels dans ces limites. La résiliation pour inexécution suppose en principe une mise en demeure préalable, selon les articles 1224 et suivants et 1344 du Code civil.

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre technique. L’article fondateur. Il décrit la mission de développement, distingue ce qui est inclus de ce qui ne l’est pas, et renvoie à un cahier des charges annexé lorsque le projet est complexe. Un périmètre flou est la première source de litige : le développeur facture des dépassements que le client conteste, faute d’avoir défini la limite initiale.

Article 2. Nature de l’obligation et livrables. Le modèle qualifie expressément l’engagement, obligation de moyens ou de résultat, et liste les livrables : code source, documentation technique, jeux d’essai. Cette qualification écrite évite que le débat sur la responsabilité ne se joue après coup.

Article 3. Recette et acceptation. La recette organise la vérification du livrable par le client, les critères d’acceptation, le délai de test et le sort des réserves. Le solde du prix est en général conditionné à une recette sans réserve, ce qui protège le client contre une livraison partielle.

Article 4. Autonomie du prestataire. Une stipulation propre à ce contrat : le développeur organise librement l’exécution, sans lien de subordination, et conserve la faculté de travailler pour d’autres clients. Cet article documente l’indépendance réelle, pièce utile face à un risque de requalification, notamment en régie.

Article 5. Prix, facturation et délais de paiement. Montant au forfait ou taux journalier en régie, échéancier, délai de paiement conforme au plafond légal, pénalités de retard et indemnité forfaitaire de recouvrement. Un acompte à la commande et des versements liés aux jalons sécurisent la trésorerie du prestataire.

Article 6. Propriété intellectuelle des développements. L’article distingue le patrimoine antérieur du développeur, bibliothèques et composants réutilisables qui lui restent acquis, et les développements spécifiques créés pour le client. La cession de ces derniers est constatée par écrit, droit par droit, conformément aux articles L. 131-2 et L. 131-3 du Code de la propriété intellectuelle. Un droit d’usage est prévu sur les composants antérieurs mobilisés.

Article 7. Évolutions et demandes de changement. La gestion des évolutions encadre les demandes hors périmètre initial : procédure de validation, chiffrage, impact sur les délais. Elle évite que chaque ajout ne soit facturé ou refusé au coup par coup, sans traçabilité.

Article 8. Confidentialité. Chaque partie protège les informations sensibles reçues de l’autre. Le développeur accède au code, aux données et parfois à la stratégie produit du client, ce qui justifie une obligation ferme de confidentialité, distincte de l’obligation de non-utilisation, dont l’article 1112-2 du Code civil rappelle le principe.

Article 9. Responsabilité. Plafond de responsabilité, exclusion des dommages indirects, et rappel que la limitation ne joue ni pour la faute lourde ou dolosive, ni au point de vider l’obligation essentielle de sa substance. La rédaction reste dans les bornes des articles 1170 et 1231-1 du Code civil.

Article 10. Durée, maintenance et résiliation. Prise d’effet, durée, et pour les prestations récurrentes, conditions de maintenance et de reconduction. La résiliation pour faute intervient après mise en demeure restée sans effet, avec restitution des éléments confiés et paiement des prestations exécutées.

Article 11. Droit applicable et litiges. Droit français, avec attribution de juridiction, et le cas échéant une étape de règlement amiable préalable.

Les pièges à éviter

Décrire la mission en une phrase. Un objet rédigé en une ligne, comme « développement d’une application », ouvre la porte à toutes les contestations sur ce qui était compris. Détaillez le périmètre fonctionnel, listez les livrables et leurs critères de recette, et renvoyez à un cahier des charges pour les projets complexes. La précision initiale coûte moins cher que le litige final.

Oublier la cession des droits sur le code. Le paiement d’un développement n’emporte pas cession des droits d’auteur. Un client qui règle la création d’un logiciel sans clause de cession conforme n’acquiert pas les droits d’exploitation et ne pourra ni le revendre, ni le confier à un autre prestataire pour le faire évoluer. La frontière entre patrimoine antérieur du développeur et développements spécifiques doit être fixée noir sur blanc, droit par droit.

Négliger le risque de requalification en régie. Imposer des horaires, fournir un poste de travail permanent, intégrer le développeur à l’organigramme et aux rituels de l’équipe : chacun de ces réflexes nourrit la preuve d’un lien de subordination. Pour un freelance travaillant à temps plein et sur la durée pour votre entreprise, la vigilance sur l’autonomie réelle prime sur la formulation du contrat.

Confondre obligation de moyens et obligation de résultat. Employer indistinctement les deux notions, ou n’en qualifier aucune, laisse le régime de responsabilité à l’appréciation d’un juge. Un développeur qui promet un livrable daté sans le vouloir peut se retrouver tenu d’un résultat ; un client qui attend un logiciel conforme sans l’écrire peut n’obtenir qu’une obligation de moyens.

Laisser filer les délais de paiement hors du cadre légal. Un délai de paiement supérieur au plafond de l’article L. 441-10 du Code de commerce expose le débiteur à une sanction administrative. L’absence de pénalités de retard dans le contrat prive par ailleurs le développeur d’un levier de recouvrement pourtant prévu par la loi.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description de la mission, le prix et ses modalités, la durée. Le reste du texte convient à la plupart des prestations de développement courantes.

La description de la mission mérite le plus grand soin. C’est elle qui départage le périmètre facturable de ce qui relève d’une demande de changement, et qui oriente la qualification de l’obligation. Pour une mission au forfait, décrivez le livrable et ses critères de recette ; pour une mission en régie, précisez le taux journalier, le mode de suivi du temps passé et le plafond éventuel de jours. Dans les deux cas, ajustez la clause d’autonomie au mode de travail réel, la régie appelant une vigilance particulière.

La clause de propriété intellectuelle s’ajuste selon la finalité du code. Pour un développement destiné à l’usage interne du client, une cession des droits d’exploitation suffit en général ; pour un logiciel appelé à être commercialisé ou intégré à un produit, la cession doit être étendue et sécurisée, droit par droit, avec un sort clair des composants antérieurs du développeur. Précisez ce que le prestataire réutilise de sa bibliothèque et sous quelle licence le client peut continuer à s’en servir.

Adaptez enfin les articles sur les données personnelles au contenu réel de la mission. Dès que le développeur traite des données personnelles pour votre compte, par exemple en accédant à une base de production, l’article 28 du RGPD impose un acte juridique contraignant : le renvoi vers un accord de sous-traitance conforme n’est pas optionnel. Un développement qui ne touche à aucune donnée personnelle s’en dispense.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni votre secteur, ni l’architecture technique de la solution, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : un développement dont dépend un actif stratégique, comme un logiciel destiné à être commercialisé, où la sécurisation de la cession des droits est déterminante ; une relation en régie longue durée avec un freelance unique, exposée à un risque de requalification ; et un contrat international où le droit applicable et la juridiction compétente sont eux-mêmes en négociation.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.