Aspects juridiques de la contractualisation agile

I. La Qualification du contrat

Le contrat que nous allons tenter de qualifier a pour objet un projet de conception de logiciel spécifique commandé par un client à un prestataire. Le projet sera conduit selon une méthode agile, des équipes mixtes (client/prestataire) seront constituées et amenées à travailler tant sur site client que sur site prestataire. Il a été convenu que la propriété intellectuelle sur les éléments livrés serait cédée au client.

La qualification juridique est l'opération intellectuelle qui vise à faire entrer des faits dans une ou plusieurs catégories juridiques, de manière à déterminer les règles de droit qui s'appliquent à ces faits, autrement dit leur régime juridique. Il faut rappeler que le juge n'est pas lié par la qualification donnée par les parties⁵. Par conséquent celles-ci doivent être attentives au droit positif lors de la conclusion du contrat, afin de connaître les règles qui lui sont applicables et d'éviter une requalification par le juge.

5 NCPC. article 12

« Le contrat est une convention par laquelle une ou plusieurs personnes s'obligent, envers une ou plusieurs autres, à donner, à faire ou à ne pas faire quelque chose. »6

Pour mener correctement une démarche de qualification contractuelle, il est nécessaire déterminer quelles sont les obligations respectives de chaque partie puis de les classer (1). Une fois ces obligations déterminées on va chercher si le lien contractuel et/ou les obligations qu'implique correspondent ou non à un contrat nommé et/ou à une ou plusieurs autres catégories juridiques existantes (2).

12

1. La Détermination des obligations des parties

Il s'agit de rechercher quelles sont les obligations des parties pour connaître leur régime particulier, voir si certaines peuvent être déterminantes pour la qualification et ainsi faire correspondre le contrat à un type réglementé.

6 C. civ. article 1101

13

1.1 Les Obligations du prestataire

Dans l'hypothèse d'un contrat classique les obligations du prestataire seraient de concevoir un logiciel fonctionnel, de le livrer dans les délais, de collaborer avec le client, de l'informer et de le conseiller, de lui transmettre les droits de propriété intellectuelle sur les éléments livrés, éventuellement d'assurer la maintenance du logiciel, etc. La prestation caractéristique du contrat, c'est-à-dire l'obligation principale pesant sur le prestataire consiste à « concevoir le logiciel »; l'objet de l'obligation étant de « faire » et l'objet du contrat « le logiciel ».

Cependant, si l'on applique les principes agiles, on accepte une part d'incertitude sur le résultat du projet, comme en témoigne notamment le deuxième principe agile :

« Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. »

Il s'agit de ne pas donner une valeur contractuelle de premier plan à un cahier des charges exhaustif car on accepte l'idée de changement. Le besoin du client va se définir au gré de l'expérience utilisateur. Ainsi on ne contracte pas un résultat mais la méthode pour y parvenir, le résultat étant la meilleure réponse possible au besoin du client. Ce résultat n'est pas concevable a priori puisque l'on fait appel à un prestataire pour le concevoir. Si le résultat n'est pas encore conçu au moment de la signature du contrat, alors annexer à celui-ci un cahier des charges prétendument exhaustif est impossible. C'est le serpent qui se mord la queue et cela revient à inscrire l'échec comme objet du contrat. En l'espèce, ce qui est strictement nécessaire est un accord sur la méthode et sur le périmètre fonctionnel du futur logiciel.

14

Les documents qui vont permettre de donner de l'agilité au cahier des charges sont notamment les « user stories », descriptions simplifiées du contenu des fonctionnalités à développer. Le principe des user stories est de se placer du point de vue de l'utilisateur final et de déterminer son besoin sans trop entrer dans le détail pour que le récit tienne sur un post-it. Cette pratique, accompagnée d'une démarche de prototypage, permet de cerner concrètement le besoin utilisateur. Selon les cas elle peut avoir lieu avant et/ou après la formalisation du contrat. Dans le modèle fourni en annexe, la liste en aura été regroupée dans la « Vision » - document assimilable au traditionnel cahier des charges. Le prototypage aura lieu, préférablement, au minimum après un accord de principe éventuellement accompagné d'une clause de partage des frais pour les prestataires les moins audacieux (voir II, 2.1 formation du contrat).

Le juriste va alors se poser la question de la valeur juridique de ces post-it et prototypes. Dans quelle mesure obligent-t-ils les parties l'une envers l'autre? Quelle est leur valeur probante ? Mais ce ne sont pas les bonnes questions ; ou plutôt ce sont des questions qui, posées à ce stade, sont susceptibles d'annihiler une démarche agile. L'objectif du juriste est certes de défendre les intérêts de son client ; mais ceux-ci se limitent-ils à une domination dans le rapport de forces entre les parties ou à une victoire certaine dans tout litige portant sur le contrat ?

Non ! le réel objectif est de mener le projet à son terme, et ce dans l'intérêt des deux parties. Pour cela il faut une bonne entente et surtout de la confiance ; une confiance qui ne devrait pas reposer sur les seuls outils contractuels mais davantage sur l'intérêt commun des parties. Dans ce cas pourquoi payer deux avocats au lieu d'un ? Neutre, il peut alors jouer le rôle de tiers de confiance.⁷

« Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »8

7 A New Role for Lawyers in Contract Negotiations ; Roland A. Paul ; 62 A.B.A. J. 93 ; 1976

8 Principe agile numéro 5 [ http://agilemanifesto.org/iso/fr/principles.html]

Pour tenter de nous rapprocher de cet idéal agile nous allons donc intégrer cette idée de changement. Cela implique que les obligations réciproques diffèrent quelque peu de celles de la contractualisation classique.

Si nous transposons l'obligation « concevoir le logiciel » dans un contexte agile, elle devient « essayer de concevoir le logiciel ». Nous ajoutons le terme « essayer » pour mettre en exergue l'idée de changement inhérente aux principes agiles. Quant à l'obligation de délivrance, c'est probablement la seconde obligation principale. On peut également considérer qu'elle fait partie de la première. L'idée est de livrer des fonctionnalités du logiciel. On parle de fonctionnalités dans l'optique de la seconde valeur agile : « Des logiciels opérationnels plus qu'une documentation exhaustive. » Nous envisageons ici cette valeur fondamentale en tant qu'elle appelle les trois principes agiles suivants (il y en a douze en tout) :

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et

régulièrement des fonctionnalités à grande valeur ajoutée.

[...]

« Livrez fréquemment un logiciel opérationnel avec des cycles de quelques

semaines à quelques mois et une préférence pour les plus courts.

[...]

« Un logiciel opérationnel est la principale mesure d'avancement. »9

Avec une méthode agile on va donc livrer des fonctionnalités opérationnelles. Cette pratique a de nombreux avantages, en particulier le client peut commencer à utiliser les fonctionnalités en production ou en test alors même que le logiciel n'est pas terminé, le prestataire peut alors anticiper sur les développements ultérieurs selon les informations renvoyées par l'utilisateur. Si le projet s'arrête le client conserve un logiciel fonctionnel dont le développement peut reprendre ultérieurement, éventuellement avec un autre

15

9 Les principes sous-jacents au manifeste agile [ http://agilemanifesto.org/iso/fr/principles.html]

prestataire ; c'est là qu'intervient la clause de réversibilité. De surcroît, un logiciel est plus facilement revendable lorsqu'il est fonctionnel.

Dans les projets agiles on admet ainsi généralement que les parties puissent mettre fin à leur relation à l'issue d'un cycle, ou « itération » par abus de langage, en respectant un préavis et certaines modalités à prévoir. On va donc livrer quelque chose qui fonctionne à l'issue de chaque cycle.

Cette livraison devrait être accompagnée de la transmission des droits de propriété intellectuelle sur les éléments livrés, de manière à ce que le client puisse pleinement jouir et disposer de ce pourquoi il paie. Cette transmission peut être réalisée soit par un contrat de licence, soit par une cession pour la durée du droit d'auteur (I, 2.1 ; II, 1). En effet, à défaut de stipulation contraire le client n'a qu'un droit d'utilisation sur le logiciel.¹⁰ Les parties devront prendre soin de respecter les dispositions du code de la propriété intellectuelle, notamment eu égard à la validité de la cession : l'étendue, la durée et la destination des droits cédés doivent être précisées. Une clause de réserve de propriété peut aussi retarder le transfert des droits de propriété intellectuelle au jour du paiement complet du prix par le client.

Il convient également d'évoquer l'obligation d'information incombant au prestataire. Dans les contrats d'entreprise elle a trois composantes : le devoir de renseignement, de mise en garde et de conseil. La mise en oeuvre d'une méthode agile ne peut que conduire à renforcer cette obligation puisque les parties vont travailler ensemble tout au long du projet.

En outre, le prestataire s'engage à réaliser sa prestation dans le respect des règles de l'art afférentes aux méthodes agiles, à constituer et maintenir une équipe compétente pour le projet, à livrer les fonctionnalités conformes à la « Vision », dans les délais, sans dépasser le prix convenu avec le client, à respecter la qualité de service selon le PQS.

16

10 Article L122-6-1 CPI

17

Certaines de ces obligations se rattachent néanmoins à l'obligation de délivrance : les questions de conformité de qualité et de délais.

On va également trouver très souvent une obligation réciproque de confidentialité plus ou moins précise selon la sensibilité des informations amenées à être échangées entre les parties.