La clause la plus souvent oubliée d’un projet logiciel : le critère d’acceptation

En tant que société de logiciels, c’est l’un des premiers sujets que nous abordons dans chaque projet. Un projet qui démarre sans critère d’acceptation écrit est un projet où chacun attend quelque chose de différent jusqu’au jour de la livraison.

Lorsqu'un dossier de litige logiciel s'ouvre, les parties débattent généralement de ceci. Le logiciel fonctionne-t-il ou non.

La raison pour laquelle ce débat ne peut être tranché n'est pas technique. Le contrat ne précise pas ce que signifie « fonctionner ». En l'absence de critère de recette, le développeur affirme avoir livré, le client affirme n'avoir rien reçu, et chacun a raison selon son propre critère.

Cette seule lacune est le dénominateur commun des litiges logiciels que j'ai vus.

Comment rédiger le critère de recette

La recette est le moment qui produit la conséquence juridique de la livraison. C'est également à partir de là que commence à courir le délai de responsabilité pour vices. Autrement dit, l'incertitude sur cette date entraîne aussi l'incertitude sur le moment où la responsabilité prend fin.

Une clause de recette qui fonctionne comprend les éléments suivants. La liste des tests de recette, l'environnement dans lequel le test sera exécuté, qui l'exécute, le délai d'objection, et la règle selon laquelle la recette est réputée acquise si aucune objection n'arrive dans ce délai.

L'élément le plus souvent oublié est l'environnement de test. Un logiciel qui fonctionne sur la machine du développeur peut ne pas fonctionner dans l'environnement du client, et à ce moment-là on discute de qui en est responsable. Si l'environnement est défini dans le contrat, ce débat ne se produit pas.

Subordonner le critère de recette à la satisfaction subjective est, quant à lui, le pire choix. Une recette conditionnée « à la satisfaction du client » crée une obligation sans limite de durée, et le travail du développeur ne se termine jamais.

Les droits de propriété intellectuelle ne sont pas cédés automatiquement

La deuxième erreur fréquente est la présomption de propriété. Le client pense qu'en contrepartie du prix payé, il est propriétaire du code. Juridiquement, ce n'est pas le cas.

Les programmes d'ordinateur sont protégés en tant qu'œuvre au titre de la loi n° 5846, et, sauf convention contraire, les droits patrimoniaux restent au titulaire de l'œuvre. La cession doit être expressément prévue, faite par écrit, et les droits cédés doivent être énumérés un par un. Une formule générale telle que « tous les droits sont cédés » reste ouverte à la contestation.

Il faut par ailleurs distinguer trois catégories. Le code écrit spécifiquement pour le client est généralement cédé. Les composants préexistants du développeur ne sont pas cédés, ils sont concédés sous licence, et l'étendue ainsi que la durée de cette licence sont rédigées séparément. Les composants open source sont soumis à leurs propres licences, et la liste de ceux qui sont utilisés doit être annexée au contrat.

Lorsque ces trois catégories ne sont pas distinguées, voici ce qui se produit. Le client croit être propriétaire de l'intégralité du code, le développeur continue d'utiliser sa propre bibliothèque dans un autre projet, et le problème n'est remarqué qu'au moment d'un litige.

Un contrat sans gestion des changements ne fonctionne pas

Aussi bien rédigé que soit le cahier des charges, des demandes de changement surviennent en cours de projet. Si le contrat ne précise pas comment cette demande sera traitée, chaque demande se transforme en négociation.

Une clause qui fonctionne répond aux questions suivantes. À qui et sous quelle forme la demande est-elle transmise. Par qui et en combien de jours l'analyse d'impact est-elle réalisée. Comment l'effet sur le prix et le calendrier est-il calculé. Avec la signature de qui l'approbation est-elle donnée. Que devient une demande non approuvée.

Lorsque ces cinq questions trouvent réponse, le changement cesse d'être une crise pour devenir un processus.

La qualité de sous-traitant de données naît sans qu'on s'en aperçoive

Si le développeur accède à des données personnelles du client, il acquiert la qualité de sous-traitant au sens de la loi n° 6698. Cette qualité est souvent acquise sans que personne ne s'en rende compte.

Le cas le plus fréquent est l'utilisation de données réelles dans l'environnement de test. Une copie de la base de données de production est transférée vers l'environnement de test, les développeurs travaillent avec, et à partir de ce moment naît une relation de traitement de données. Si le contrat ne contient aucune clause à ce sujet, cette relation se déroule sans fondement juridique.

La solution la plus propre consiste à ne jamais laisser cette situation se produire. Tester avec des données masquées ou synthétiques n'est pas techniquement difficile et élimine en grande partie le risque. Si l'accès à des données réelles est réellement indispensable, l'objet, la durée et la finalité du traitement, l'assujettissement du développeur aux instructions, le recours à des sous-traitants ultérieurs, les mesures de sécurité, ainsi que la restitution ou la destruction des données à la fin du contrat doivent être régis par écrit.

La maintenance est un contrat distinct

Enfin, la maintenance et le support. Il s'agit d'une prestation distincte du développement et qui doit être régie séparément.

Ce qu'il faut rédiger, ce n'est pas le délai d'intervention, mais la classification des incidents. Si l'on ne définit pas quel incident relève de quelle classe, chaque incident est réclamé avec la priorité la plus élevée. Une fois les classes définies, le délai d'intervention et de résolution est rédigé séparément pour chacune.

Il y a aussi la question de la mesure. Un engagement de niveau de service qui n'est pas mesurable reste sans sanction en cas de manquement. La manière dont cette mesure sera effectuée, et sur la base du relevé de qui, doit figurer dans le contrat.

Qui doit rédiger le contrat

L'ensemble de ces clauses exige que le droit et l'ingénierie décident conjointement. L'avocat ne peut pas rédiger seul le critère de recette, car il ne sait pas ce qui est testable. L'ingénieur ne peut pas rédiger seul la cession des droits de propriété intellectuelle.

La partie qui aborde la négociation du contrat sans équipe technique finit par accepter des clauses qui se révéleront inapplicables par la suite. Une clause inapplicable, lorsqu'un litige survient, se comporte comme si elle n'avait jamais existé.