Le contrat de développement logiciel : que régler

Un contrat de développement logiciel mal rédigé engendre des conflits quasi certains : qui possède le code, ce qui était réellement inclus, qui paie les retards. En Suisse, le Code des obligations offre un cadre, mais laisse de nombreux points à la volonté des parties. Un contrat clair ne sert pas à mieux se disputer : il sert à ne pas se disputer du tout. Voyons ce qu’il faut régler, du côté de celui qui commande comme de celui qui développe.

La nature du contrat

Il faut d’abord comprendre quel type de rapport se crée. En Suisse, le développement sur commande s’apparente souvent au contrat d’entreprise, dans lequel le fournisseur doit livrer un ouvrage qui fonctionne, et non seulement mettre à disposition des heures de travail. D’autres modèles, comme le forfait avec obligation de résultat ou la prestation en régie (temps et matériel), répartissent le risque différemment. Confondre « je te paie pour un résultat » et « je te paie pour le temps que tu y consacres » est à l’origine de nombreux litiges.

Propriété du code et droits

C’est le point sur lequel on se retrouve le plus souvent en désaccord une fois le travail terminé. Il faut clarifier par écrit :

À qui appartiennent les droits sur le logiciel développé : sans une cession expresse, le mandant risque de ne pas détenir tous les droits qu’il croit avoir.
Le code source : est-il livré ou reste-t-il chez le fournisseur ? C’est une différence énorme pour la liberté future du mandant.
Les composants préexistants du fournisseur réutilisés dans le projet : en règle générale ils restent les siens, mais une licence d’usage claire en faveur du mandant est nécessaire.
Les composants open source inclus : ils doivent être déclarés, avec leurs licences respectives et les contraintes qu’ils impliquent.

Celui qui commande veut pouvoir utiliser, modifier et faire évoluer le logiciel, y compris avec un autre fournisseur. Celui qui développe veut protéger son savoir-faire réutilisable. Le contrat trouve le point d’équilibre.

Spécifications, recette et modifications

Une grande partie des conflits naît du « ce n’est pas ce que j’avais demandé ». Pour l’éviter :

Spécifications annexées : ce que le logiciel doit faire, avec un niveau de détail suffisant. C’est l’ancre de toute discussion ultérieure.
Critères de recette : comment vérifier que le résultat est conforme, et ce qui se passe s’il ne l’est pas.
Gestion des modifications : une procédure pour les demandes de changement en cours de projet, avec impact sur les délais et le prix. Sans elle, chaque « petit ajout » devient un contentieux.
Jalons et paiements : lier les acomptes à des étapes vérifiables protège les deux parties.

Délais, garantie et maintenance

Délais et retards : des échéances réalistes et les conséquences du retard, en distinguant les causes imputables au fournisseur de celles du mandant (par exemple des contenus ou des validations manquants).
Garantie sur les défauts : la durée et les modalités selon lesquelles les défauts sont corrigés après la livraison.
Maintenance et évolution : la maintenance est un contrat distinct du développement. Les délais d’intervention, les corrections, les mises à jour et les coûts doivent être définis par écrit et séparément.

Responsabilité, données et sortie

Limites de responsabilité : dans les limites admises par le droit suisse, on définit les plafonds et les exclusions. La responsabilité pour dol et faute grave ne peut être exclue.
Protection des données : si le logiciel traite des données personnelles, le contrat doit régler les rôles et obligations en la matière.
Confidentialité : les informations et matériels échangés doivent être protégés.
Résiliation et sortie : comment le rapport prend fin, ce qui est remis (code, documentation, identifiants) et comment se déroule le passage à un autre fournisseur. La clause de sortie est celle qui se révèle décisive lorsque les relations se dégradent.

En résumé

Définissez la nature du contrat : résultat ou régie changent tout le risque.
Réglez par écrit la propriété du code, le code source, les composants préexistants et l’open source.
Ancrez le projet à des spécifications, des critères de recette et une procédure pour les modifications.
N’oubliez pas la garantie, la maintenance séparée, la responsabilité, les données et la clause de sortie.

Comment nous vous aidons

Nous rédigeons et révisons des contrats de développement logiciel sur mesure, du côté de celui qui commande comme de celui qui développe, avec une attention particulière à la propriété du code, à la recette et à la sortie. Parlons de votre contrat.