Contrat de développement logiciel : les clauses à vérifier

Un contrat de développement logiciel protège surtout par ce qu'il précise : le périmètre et la façon de le valider (la recette), le prix et la gestion des changements, les droits sur le code, la garantie, les données personnelles, la responsabilité et les conditions de sortie. Un contrat flou sur un seul de ces points suffit à transformer un désaccord ordinaire en litige.

Cet article passe en revue les clauses à lire, dans l'ordre où elles posent problème en pratique. Il décrit le cadre général en droit français et ne remplace pas un conseil juridique : faites relire votre contrat par un avocat, surtout si le projet est critique pour votre activité.

Le périmètre : ce qui est commandé, et ce qui ne l'est pas

Tout part de là. Le contrat doit renvoyer à un document qui décrit ce qui sera livré : un cahier des charges, une liste de fonctions, ou mieux, un prototype validé qui montre les écrans et les parcours. Ce qui n'est pas décrit n'est pas commandé, et sera facturé en plus ou refusé.

Trois points à vérifier :

• Les exclusions explicites. Reprise des données de l'ancien outil, intégrations avec votre ERP ou votre comptabilité, version anglaise, formation : écrites noir sur blanc, elles évitent la mauvaise surprise.
• Les hypothèses. Un chiffrage repose toujours sur des hypothèses (nombre d'utilisateurs, accès à une API existante, disponibilité de vos équipes). Elles doivent figurer au contrat, avec ce qui se passe si elles tombent.
• La hiérarchie des documents. Si le devis, le cahier des charges et les conditions générales se contredisent, lequel l'emporte ? Le contrat doit le dire.

Notre méthode pour comparer des devis montre comment ces hypothèses expliquent la plupart des écarts de prix.

La recette : comment le logiciel est validé

La recette est le moment où vous vérifiez que ce qui est livré correspond à ce qui était commandé. C'est la clause la plus souvent négligée et la plus souvent invoquée en cas de conflit, parce qu'elle déclenche le paiement du solde et le début de la garantie.

Un contrat solide prévoit :

• des scénarios de test convenus à l'avance, plutôt qu'un jugement global ;
• une durée de recette (par exemple quelques semaines), et ce qui se passe si vous ne répondez pas dans ce délai ;
• un classement des anomalies (bloquante, majeure, mineure), avec la règle : seules les anomalies bloquantes empêchent la validation ;
• un procès-verbal signé, avec ou sans réserves, et le délai de levée des réserves.

Sur un projet livré par paliers, prévoyez une recette par palier : chaque étape validée réduit le risque de la suivante.

Le prix, les avenants et le calendrier

Le contrat dit si le prix est forfaitaire (un montant pour un périmètre) ou calculé au temps passé. La différence est expliquée dans forfait ou régie. Dans les deux cas, vérifiez :

• l'échéancier : acompte, paiements liés aux paliers validés, solde à la recette ;
• la procédure de changement : toute modification du périmètre passe par un avenant écrit, chiffré, signé avant d'être réalisé ;
• le calendrier et ses conditions : une date de livraison n'engage le prestataire que si vos propres obligations (fournir des contenus, valider dans les délais) sont elles aussi datées ;
• les éventuelles pénalités de retard, leur plafond, et ce qu'elles excluent.

Propriété du code et licences

C'est la clause la plus technique juridiquement. En droit français, une cession de droits d'auteur doit, selon l'article L131-3 du code de la propriété intellectuelle, mentionner distinctement chaque droit cédé et délimiter son étendue, sa destination, son lieu et sa durée. Une phrase comme « le client est propriétaire de tout » ne remplit pas cette exigence.

Le contrat doit distinguer trois couches : le code écrit pour vous, les briques réutilisables du prestataire (concédées en licence) et les composants open source (soumis à leur propre licence). Nous détaillons ces distinctions dans à qui appartient le code source d'un logiciel sur mesure.

Garantie et maintenance : deux choses différentes

Entre professionnels, la garantie d'un développement sur mesure est avant tout contractuelle : c'est au contrat de fixer sa durée, les délais de correction selon la gravité et ses exclusions. Une anomalie est un écart par rapport à ce qui était convenu ; une demande qui change le comportement prévu est une évolution. Plus cette frontière est écrite, moins elle se discute.

La maintenance, elle, est un engagement dans la durée. Ce qu'elle doit couvrir est détaillé dans notre article sur la maintenance d'une application métier.

Les données personnelles : l'article 28 du RGPD

Dès que le prestataire héberge votre application ou accède à des données personnelles (vos clients, vos salariés), il agit en principe comme sous-traitant au sens du RGPD. L'article 28 du règlement (UE) 2016/679 impose alors un contrat qui fixe l'objet, la durée, la nature et la finalité du traitement, le type de données et les catégories de personnes concernées.

Ce contrat doit notamment prévoir que le sous-traitant :

• ne traite les données que sur instruction documentée du client ;
• garantit la confidentialité des personnes qui y accèdent ;
• met en œuvre les mesures de sécurité de l'article 32 ;
• n'engage un autre sous-traitant (un hébergeur, par exemple) qu'avec l'autorisation écrite du client, et lui impose les mêmes obligations ;
• aide le client à répondre aux demandes des personnes et à respecter ses obligations de sécurité et de notification ;
• supprime ou restitue les données en fin de contrat, au choix du client ;
• met à disposition les informations nécessaires aux audits.

Ces clauses figurent souvent dans une annexe dédiée. Ce que l'application elle-même doit prévoir est traité dans notre article sur le RGPD.

La responsabilité et ses limites

La plupart des contrats plafonnent la responsabilité du prestataire, souvent en la liant au montant du contrat. C'est courant et négociable, avec deux garde-fous du code civil :

• selon l'article 1231-3, le débiteur n'est tenu que des dommages prévus ou prévisibles lors de la conclusion du contrat, sauf faute lourde ou dolosive ;
• selon l'article 1170, une clause qui prive de sa substance l'obligation essentielle du débiteur est réputée non écrite.

En cas d'inexécution, l'article 1217 ouvre plusieurs voies : suspendre sa propre exécution, demander l'exécution forcée, obtenir une réduction du prix, la résolution du contrat ou des dommages et intérêts. Un contrat bien écrit organise ces situations en amont (délais de mise en demeure, plan de correction) pour éviter d'avoir à les plaider.

Vérifiez aussi la sous-traitance : le prestataire peut-il confier tout ou partie du développement à un tiers, et vous en informe-t-il ? Notre guide pour choisir une agence de développement explique pourquoi cette question compte.

La sortie : réversibilité et fin de contrat

Une relation peut s'arrêter pour de bonnes raisons : projet terminé, changement de stratégie, désaccord. Le contrat doit dire ce qui se passe ce jour-là :

• la durée, le préavis et les cas de résiliation ;
• ce qui vous est remis (code source ou accès à un dépôt chez un tiers, selon les droits prévus, documentation, accès aux comptes) ;
• l'export de vos données dans un format exploitable ;
• l'assistance du prestataire pendant la transition, et son prix.

C'est l'objet de la réversibilité, que nous détaillons dans pouvoir changer de prestataire logiciel.

Les autres clauses à ne pas oublier

• Confidentialité : ce que chacun peut dire du projet, et pendant combien de temps après la fin du contrat.
• Non-sollicitation du personnel : fréquente, à lire pour en connaître la durée et la portée.
• Loi applicable et juridiction : utile dès que le prestataire est à l'étranger.
• Références : le prestataire peut-il citer votre nom ? Ce point se négocie, il n'est pas acquis.

La position de LPR Studio

Nos engagements dépendent de la formule retenue et sont écrits dans le contrat, projet par projet. Le prototype de démonstration reste notre propriété : il est présenté en visio, pas livré. Ensuite, les droits sur le code sont définis au cas par cas dans le contrat. En formule abonnement, LPR Studio reste éditeur et exploitant de l'application ; au forfait, le prix est fixe pour un périmètre écrit. Les trois formules sont décrites sur la page des offres, et notre façon de travailler sur la page approche.

Par où commencer

Le meilleur contrat repose sur un périmètre que les deux parties voient de la même façon. Chez LPR Studio, le prototype visuel est gratuit et présenté en visio sous 5 jours ouvrés : il sert de base commune au chiffrage, puis à la recette. Faites ensuite relire le contrat par votre avocat avant de signer.