Modèle de contrat de développement logiciel au forfait 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 logiciel sur mesure à périmètre défini. Une entreprise qui fait réaliser une application métier, un portail client ou un module d’intégration signe un contrat au forfait lorsque le besoin est suffisamment stabilisé pour être décrit dans un cahier des charges. Le forfait fige le périmètre, le prix et le délai : le prestataire s’engage sur un résultat, à charge pour lui d’absorber les aléas de réalisation qui n’ajoutent rien au périmètre convenu.

Vous êtes prestataire et vous vous engagez sur un livrable. Une ESN ou un studio de développement qui répond à un appel d’offres au forfait accepte de porter le risque de l’estimation. Le contrat protège alors le prestataire par une définition précise du périmètre, une procédure de gestion des évolutions qui renvoie tout ajout à un avenant, et une obligation de collaboration mise à la charge du client.

Le besoin est stable et documenté. Le forfait suppose des spécifications arrêtées avant la signature. C’est la condition qui distingue un vrai marché à forfait d’une prestation facturée au temps passé. Un prix ferme sans périmètre figé est une source de litige, pas une sécurité.

Quand ce modèle ne convient pas. Si le besoin évolue en permanence et se précise au fil des itérations, un contrat en régie informatique ou une méthode agile encadrée reflète mieux la réalité de la collaboration. Si le logiciel existe déjà et que le prestataire concède un simple droit d’usage, la qualification relève de la licence logicielle. Si le projet consiste à intégrer et paramétrer des progiciels tiers plutôt qu’à écrire du code spécifique, un contrat d’intégration informatique est plus adapté. Enfin, la maintenance qui suit la livraison relève d’un contrat de tierce maintenance applicative distinct.

Ce que dit le droit français

Le développement au forfait est un contrat d’entreprise. Il s’analyse en un louage d’ouvrage, ou contrat d’entreprise, régi par les articles 1710 et 1787 et suivants du Code civil, dans sa variante au forfait : prix global, ferme et définitif, contre un périmètre figé. L’article 1793 du Code civil, qui régit le marché à forfait, vise expressément la construction immobilière ; sa transposition au développement logiciel est discutée et son régime reste largement gouverné par la jurisprudence informatique. [À VÉRIFIER JURISTE : transposition de l’article 1793 hors du secteur du bâtiment.]

Le prestataire est débiteur d’une obligation de conseil et de mise en garde renforcée. La jurisprudence constante impose au professionnel de l’informatique d’éclairer un client souvent profane sur l’adéquation de la solution à son besoin, sur les contraintes techniques et sur les prérequis. En contrepartie, le client est tenu d’une obligation de collaboration : fournir les informations, valider les livrables, mobiliser ses équipes. Le manquement de l’une des parties tempère la responsabilité de l’autre.

Le logiciel est une œuvre protégée par le droit d’auteur. L’article L. 112-2, 13° du Code de la propriété intellectuelle range les logiciels parmi les œuvres de l’esprit, et l’article L. 122-6 réserve à leur auteur les droits patrimoniaux de reproduction et d’adaptation. Il n’existe aucune cession automatique au client qui commande et paie le développement. Le transfert exige une clause de cession de droits d’auteur expresse et écrite, comportant les mentions de l’article L. 131-3 : droits cédés, étendue, destination, lieu et durée. La cession globale des œuvres futures est prohibée par l’article L. 131-1, ce qui impose de rattacher la cession à des développements identifiables.

Le code source et les composants tiers appellent un traitement à part. Le contrat doit prévoir le sort du code source (remise, dépôt, accès) et l’inventaire des composants tiers et briques open source, dont les licences peuvent contaminer les développements. L’article L. 122-6-1 réserve par ailleurs à l’utilisateur légitime certaines prérogatives d’ordre public : copie de sauvegarde et actes nécessaires à l’interopérabilité, que le contrat ne peut lui retirer.

La recette fixe le point de départ des garanties. La procédure de réception et de recette matérialise la conformité du livrable au cahier des charges : recette provisoire, levée des réserves, recette définitive. Elle commande le transfert des risques, l’exigibilité du solde et le point de départ de la garantie de conformité au cahier des charges. Dans ce contrat d’entreprise, les défauts du livrable relèvent de la responsabilité contractuelle du prestataire, tenu d’une obligation de résultat sur la conformité, et non de la garantie des vices cachés, propre à la vente. Le prestataire doit en outre au client une garantie d’éviction, qui le protège contre les revendications de tiers, notamment en cas de contrefaçon.

Les clauses limitant la responsabilité connaissent des bornes. Entre professionnels, un plafond et l’exclusion des dommages indirects sont licites, mais une clause limitative de responsabilité qui prive de sa substance l’obligation essentielle du prestataire est réputée non écrite (article 1170 du Code civil, dans la lignée des arrêts Chronopost et Faurecia). La réparation reste bornée au dommage prévisible lors de la conclusion (article 1231-3 du Code civil), sauf faute lourde ou dolosive. L’action se prescrit par cinq ans selon le droit commun (article 2224 du Code civil).

Le traitement de données personnelles déclenche des obligations propres. Si le développement conduit le prestataire à traiter des données personnelles pour le compte du client, un acte de sous-traitance conforme à l’article 28 du RGPD devient obligatoire : instructions documentées, confidentialité, mesures de sécurité et encadrement des sous-traitants ultérieurs. [À VÉRIFIER JURISTE : périmètre exact des obligations RGPD selon les données manipulées pendant et après le développement.]

Ce que contient ce modèle, article par article

Article 1. Objet et définitions. L’article qualifie le contrat de louage d’ouvrage au forfait, identifie le logiciel à réaliser et renvoie aux annexes techniques. Il pose le vocabulaire (livrable, jalon, recette, réserve) qui structure le reste du texte.

Article 2. Cahier des charges et périmètre. Le cahier des charges annexé constitue le socle du forfait : fonctionnalités, contraintes techniques, environnement cible, exclusions. Tout ce qui n’y figure pas sort du périmètre et relève d’un avenant. Une hiérarchie des documents contractuels départage le contrat et ses annexes en cas de contradiction.

Article 3. Obligations des parties. L’article détaille l’obligation de conseil et de mise en garde du prestataire et, en miroir, l’obligation de collaboration du client : mise à disposition des informations, désignation d’un interlocuteur, validation des livrables dans un délai convenu. Le retard du client neutralise d’autant l’engagement du prestataire.

Article 4. Prix ferme et modalités de paiement. Le prix ferme, global et définitif, est adossé à un échéancier lié aux jalons. L’article fixe le délai de paiement dans le plafond de l’article L. 441-10 du Code de commerce et prévoit des pénalités de retard. Tout ajout au périmètre passe par un avenant chiffré.

Article 5. Délais, planning et jalons. Les délais d’exécution sont associés à des jalons intermédiaires. L’article distingue les délais fermes des délais indicatifs et articule les retards imputables au prestataire, au client ou à un tiers.

Article 6. Gestion des évolutions. La procédure de change request canalise toute demande de modification : formalisation, chiffrage, impact sur le délai, avenant. C’est le mécanisme qui empêche le périmètre de dériver et le forfait de se transformer, de fait, en régie.

Article 7. Réception et recette. La recette organise la vérification de conformité : recette provisoire, liste des réserves, délai de correction, recette définitive. Elle fixe le point de départ des garanties et conditionne le paiement du solde. Un procès-verbal en trace chaque étape.

Article 8. Propriété intellectuelle. L’article distingue la propriété intellectuelle antérieure du prestataire, qui reste sienne et fait l’objet d’une licence d’usage, et les développements spécifiques réalisés pour le client. La cession des droits d’auteur sur ces derniers reprend les mentions de l’article L. 131-3 du Code de la propriété intellectuelle et traite le sort du code source et des composants tiers.

Article 9. Garanties. L’article organise la garantie de conformité au cahier des charges, la responsabilité contractuelle du prestataire au titre des défauts du livrable (obligation de résultat) et la garantie d’éviction contre les revendications de tiers. Il fixe la durée de la garantie et distingue la correction des anomalies de la maintenance ultérieure.

Article 10. 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-3 du Code civil.

Article 11. Maintenance et réversibilité. L’article renvoie la maintenance corrective et évolutive à un contrat dédié et organise la réversibilité : remise du code source documenté, transfert de connaissances, restitution des données. Il évite au client de rester captif de son prestataire.

Article 12. Confidentialité, durée et litiges. Engagement de confidentialité réciproque, durée du contrat jusqu’à la recette définitive et la fin de la garantie, force majeure (article 1218 du Code civil), droit français et attribution de juridiction, le cas échéant précédée d’une étape amiable.

Les pièges à éviter

Signer un forfait sur un périmètre flou. Un prix ferme sans cahier des charges stabilisé n’est pas un forfait, c’est un litige différé. Le périmètre doit être décrit avant la signature, faute de quoi chaque désaccord fonctionnel se transforme en négociation sur le prix. Le forfait protège les deux parties uniquement si le socle est figé.

Croire que payer le développement rend propriétaire. Le client qui règle la facture n’acquiert aucun droit sur le logiciel sans clause de cession écrite et détaillée. En l’absence des mentions de l’article L. 131-3 du Code de la propriété intellectuelle, il ne dispose que d’un droit d’usage et se trouve dépendant du prestataire pour toute évolution. La cession doit viser des développements identifiés, la cession globale des œuvres futures étant prohibée.

Laisser le forfait glisser vers la régie. Accepter les demandes de modification au fil de l’eau, sans avenant ni chiffrage, dilue le périmètre et fait perdre au forfait sa raison d’être. La procédure de change request n’est pas une formalité : elle protège le prestataire contre le travail non payé et le client contre les dépassements non maîtrisés. Un forfait dont le périmètre n’est jamais figé s’expose à une requalification en prestation au temps passé.

Bâcler la recette. Une réception sans procès-verbal, sans réserves formalisées ni recette définitive, prive les deux parties d’un point de repère. Elle brouille le transfert des risques, le paiement du solde et le point de départ des garanties. La recette est le moment où la conformité au cahier des charges se constate, pas une formalité administrative.

Fixer un plafond de responsabilité dérisoire. Un plafond limité à une fraction du prix, face à un logiciel dont dépend une fonction critique du client, risque d’être écarté par le juge comme privant l’obligation essentielle de sa substance. Le plafond doit rester proportionné à l’enjeu réel du projet et à la nature des dommages prévisibles.

Oublier le code source et les composants tiers. Un contrat muet sur la remise du code source laisse le client incapable de faire maintenir son logiciel par un autre prestataire. L’absence d’inventaire des briques open source expose à des conflits de licence. Ces deux points se règlent dans la clause de propriété intellectuelle et dans la réversibilité, pas après la livraison.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description du logiciel, le prix et son échéancier, le délai global et les jalons. Le cahier des charges annexé mérite le plus grand soin, car c’est lui qui définit le forfait.

La clause de propriété intellectuelle s’ajuste selon l’usage prévu. Un client qui compte faire évoluer le logiciel par ses propres moyens ou par un tiers a besoin d’une cession large des droits patrimoniaux et de la remise du code source documenté. Un client qui restera lié au prestataire peut se contenter d’un droit d’usage étendu. Dans les deux cas, la frontière entre le socle réutilisable du prestataire et les développements spécifiques doit être tracée sans ambiguïté.

La procédure de recette se calibre selon la criticité du logiciel. Pour une application au cœur du métier, prévoyez une recette provisoire suivie d’une période de vérification en conditions réelles avant la recette définitive. Pour un outil secondaire, une recette unique suffit. Reliez toujours la levée des réserves à un délai et à un procès-verbal.

Adaptez enfin les garanties et la suite du projet. Si le logiciel traite des données personnelles, ajoutez un acte de sous-traitance conforme à l’article 28 du RGPD. Si la maintenance est attendue, renvoyez-la à un contrat de tierce maintenance applicative distinct plutôt que de la mêler au forfait de développement. Prévoyez la réversibilité dès l’origine, quand la sortie n’est pas encore un enjeu.

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 la criticité réelle de votre logiciel, ni la nature des données traitées, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : un projet dont le périmètre reste mouvant, où le choix entre forfait, régie et méthode agile doit être arbitré au regard du risque de requalification ; un développement qui intègre des composants tiers ou open source dont les licences engagent la propriété du résultat ; et un projet manipulant des données personnelles à grande échelle ou sensibles, qui impose un acte de sous-traitance renforcé et, le cas échéant, une analyse d’impact.

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.