Aspects juridiques de la contractualisation agile

Université de Nice Sophia-Antipolis

Faculté de droit et de science politique - IUP Management et Gestion des Entreprises

Aspects juridiques de la contractualisation agile

Par M. Camille PLANAT

Mémoire en vue de l'obtention du diplôme de Master 2 à finalité professionnelle « Droit de la propriété intellectuelle et des nouvelles technologies », mention « droit économique et des affaires »,

Réalisé sous la direction de M. Christophe COLETTE (tuteur enseignant), et de Maître Pascal AGOSTI (tuteur professionnel).

Novembre 2012

2

3

Je tiens dans un premier temps à remercier Maître Pascal AGOSTI, avocat au Barreau de Nice, pour m'avoir confié ce travail de recherche. Je remercie également Maître Éric CAPRIOLI, Maître Ilène CHOUKRI, Maître Fabienne PITIOT, Maître Catherine KOVALEFF, Monika ZWOLINSKA, Nathalie RODRIGUES et Maître Isabelle CANTERO pour leur accueil chaleureux au cabinet CAPRIOLI et Associés à Nice ainsi que pour leurs précieux conseils.

Je tiens à remercier Monsieur Christophe COLETTE, Professeur à l'Université de Nice, pour m'avoir soutenu dans ce travail et avoir accepté le rôle de tuteur enseignant.

Je tiens à remercier Sophie BRICCA-DRUFFIN et Gérard DOUX ainsi que toute l'équipe enseignante du Master 2 Droit de la propriété intellectuelle et des nouvelles technologies de l'IUP Management et Gestion des Entreprises de Valbonne Sophia Antipolis.

Je remercie toutes les personnes que je n'ai pas nommées ici et qui, de près ou de loin, m'ont aidé dans ce travail et/ou ont contribué au bon déroulement de cette année universitaire.

4

Résumé :

L'utilisation d'une méthode agile pour le développement d'applications a des conséquences juridiques sur le contrat de développement de logiciel spécifique, jusqu'ici qualifié en droit français de contrat de louage d'ouvrage. En particulier, l'importance que prend la dimension collaborative dans les projets agiles est telle que l'on voit émerger une obligation de collaboration essentielle, reposant sur les deux parties (I., 1.). Dans certains cas apparaît même une forme d'affectio societatis (I., 2.). Le risque de requalification des contrats de travail des salariés en mission est augmenté eu égard à la dimension collaborative (II., 1). En outre, l'utilisation d'une méthode agile peut écourter la phase de formation du contrat (II., 2.).

Abstract :

The use of an agile method for developing applications has legal consequences over the software development agreement so far qualified by French lawyers as «contrat de louage d'ouvrage» (contract for services). In particular, the growing importance of collaborative dimension in agile projects is such that we see the emergence of a fundamental obligation of cooperation, which applies on two parties (I. 1.). In some cases there is even a form of affectio societatis (I. 2.). The risk of reclassification of workers' employment contracts is increased because of the collaborative dimension (II. 1). In addition, the use of an agile method can shorten the pre-contractual phase (II. 2.).

5

Sommaire

I. LA QUALIFICATION DU CONTRAT				11
1. LA DÉTERMINATION DES OBLIGATIONS DES PARTIES				12
2. LA RECHERCHE D'UN CADRE JURIDIQUE				20
II. LE RÉGIME JURIDIQUE DU CONTRAT AGILE				28
1. DROIT APPLICABLE				28		2. RESPONSABILITÉ ET CONTENTIEUX
			36
ANNEXE : CONTRAT DE PRESTATION DE	SERVICE	RÉALISÉ	SELON	LES
MÉTHODOLOGIES AGILES				46

Principales abréviations :

BOI Bulletin officiel des impôts

BTP Bâtiment et travaux publics

CPI Code de la Propriété Intellectuelle

LPF Livre des procédures fiscales

NCPC Nouveau code de procédure civile

PECL Principles of European Contract Law

PQS Plan de qualité de service

UNIDROIT Institut international pour l'unification du droit

privé

Introduction

6

« Alors que dans le modèle de l'ingénierie, l'objet du contrat est d'être exactement exécuté ou, en cas de défaillance, de servir de base au règlement du contentieux, la possibilité d'aléas ou d'évolutions après la signature de l'accord initial est ici intégrée. L'idée est d'inciter, par les clauses du contrat, à «remonter» la détection des problèmes le plus tôt possible, avant que le coût de la modification ne soit trop grand, du fait des irréversibilités. Pendant toute la durée du développement, le traitement des événements imprévus intègre étroitement la dimension technique et la dimension économique. Pour ce faire, le constructeur et le fournisseur se sont préalablement accordés sur les critères et les méthodes d'évaluation : planification commune, méthodes de contrôle-qualité, principes de chiffrage économique. Le contrat n'a pas pour vocation à se substituer à l'exploration commune. Il a pour but de l'appuyer, de lui servir de cadre et d'être un instrument de dialogue et de négociation. »1

1 Giard V. et Midler Ch., Management et gestion des projets, Economica, 1996, p. 12

7

Si l'on souhaite concrétiser un projet de développement logiciel, il y a deux possibilités : développer le logiciel soi-même ou faire appel à un prestataire extérieur.

C'est la seconde solution qui nous intéresse ici. Comment y parvenir ? Une bonne évaluation de la complexité technique du projet, des compétences et de la solidité financière du prestataire, des moyens mis en oeuvre, une juste détermination des besoins du client, la collaboration entre les parties et le respect de leurs obligations réciproques sont autant de facteurs de réussite.

Envisager la portée de ces obligations est fondamental pour le juriste puisque cela va lui permettre de rédiger le contrat dans le respect du droit applicable. C'est à dire qu'à travers le contrat il va apporter davantage de sécurité juridique au déroulement du projet.

Or, pour mener à bien le projet, il faut une méthode adéquate. Pour cela on a transposé à l'informatique des méthodologies de gestion utilisées jusqu'alors dans d'autres secteurs tels que le bâtiment, l'automobile voire les programmes d'équipements militaires et spatiaux². Nous verrons qu'il existe cependant des différences fondamentales entre ces disciplines et le développement d'applications. Les méthodes agiles résultent notamment de la prise en compte de ces différences, mais aussi des difficultés et des échecs vécus dans les projets logiciels.

En effet les méthodes traditionnelles consacrent une division du travail verticale (séparation entre conception et construction) et horizontale (parcellisation des tâches), en vue d'accroître la productivité et de rendre les ressources humaines facilement remplaçables. Cette division systémique s'accompagne de méthodes de management bureaucratiques et prédictives. Appliquées à l'informatique elles conduisent à ce qu'une part trop importante du travail soit gaspillée à suivre la méthodologie, les projets sont ainsi ralentis et le changement est redouté.

2 Giard V. et Midler Ch., « Management et gestion de projet : bilan et perspectives », Encyclopédie de Gestion, Economica, 1996

8

On oppose alors ces méthodologies « lourdes », notamment adaptées à un processus industriel conçu pour des individus remplaçables, aux méthodologies « légères » ou « agiles », davantage favorables à une créativité débridée. Une méthode est « agile » car capable de changer rapidement, avec souplesse et aisance. Le management agile, notion plus large, s'inspire de certaines méthodes japonaises de production et de gestion de la qualité telles que le lean ou le kaizen.³

Cette terminologie est née du manifeste agile, acte unificateur des pratiques agiles en matière de création logicielle, datant de 2001. On peut assimiler ce manifeste à un acte de soft law et s'y référer, par exemple pour l'interprétation des clauses du contrat (II, 1.1). Les premières méthodologies légères ont émergé au début des années 90 face au constat de l'inadéquation du cycle de développement de type cascade avec les nouveaux besoins applicatifs.

Quatre valeurs fondamentales communes à toutes les méthodes agiles sont prônées par le manifeste agile (elles se déclinent en douze principes) :

« Les individus et leurs interactions plus que les processus et les outils

Des logiciels opérationnels plus qu'une documentation exhaustive

La collaboration avec les clients plus que la négociation contractuelle

L'adaptation au changement plus que le suivi d'un plan

Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers. »4

3 Voir « Roue de Deming » ou « Cycle de Shewhart », illustartion de la méthode PDCA, présentée dans les années 50 par Williams Edwards Deming au Nippon Keidanren, l'organisation patronale japonaise.

4 Les quatre valeurs agiles [ http://agilemanifesto.org/iso/fr/]

9

Pour résumer, la méthode agile est une méthode de gestion de projet utilisée pour le développement d'applications, dont les caractéristiques principales sont la capacité d'adaptation au changement, l'orientation vers l'individu et l'implication maximum du client en vue de permettre une satisfaction réelle de son besoin. Ceci au détriment de l'inertie administrative et productive qui résulte de processus de décision trop complexes, d'outils de contrôle inadaptés ou trop invasifs, d'un excès de documentation et de négociation sur des points susceptibles de changer à tout moment, comme c'est le cas dans l'ingénierie logicielle.

Dans les processus industriels traditionnels on cherche à établir une planification permettant une utilisation optimale de nos ressources humaines peu ou pas qualifiées. C'est pourquoi on commence par planifier et concevoir afin de rendre la construction plus simple. On peut se permettre cette démarche car dans ces disciplines, malgré la lourdeur de la méthodologie, la construction représente la majeure partie du coût de réalisation d'un projet (environ 90% en matière de BTP).

En revanche en matière de développement logiciel, la plus grosse partie du travail est une activité de conception si l'on compare le codage et les tests à une activité de construction. On peut même aller plus loin en affirmant que seule l'utilisation du compilateur relève de la construction, le code source étant alors considéré comme un document de conception.

La construction est donc si bon marché qu'elle est gratuite, tout l'effort est dans la conception, ce qui nécessite du personnel qualifié et créatif. Or, en raison du caractère intellectuel des processus mis en oeuvre, du nombre et de la complexité des problèmes qui se posent et de la créativité nécessaire pour les résoudre, il est difficile de planifier en matière de développement logiciel.

Ainsi de plus en plus de projets informatiques sont conduits selon une démarche agile dont l'orthodoxie va de pair avec la témérité des parties au contrat, d'où l'intérêt d'apporter quelques réflexions théoriques et pratiques sur la façon adéquate d'adopter une

10

méthode agile du point de vue du droit. De plus, cette question est absente de la doctrine et la jurisprudence inexistante.

Il se peut néanmoins que de tels contrats aient fait l'objet de décisions judiciaires marginalement diffusées, ou que l'utilisation de la méthode n'ait été invoquée ni par le juge ni par les parties. On peut aussi expliquer ce silence par la nouveauté du mouvement et par la rupture qu'il implique avec les réflexes juridiques habituels, rupture qui irait de pair avec la réticence de certains juristes à s'impliquer dans des projets dont ils auraient peur de ne pas maîtriser les contours, ou pire, qui leur donneraient moins de travail. Outre l'argument d'une dilution du risque du prestataire vers le client pour ce qui est des contrats au forfait, il est légitime de se demander si ces méthodes - devant l'engouement qu'elles suscitent - ne sont pas simplement efficaces ; parce qu'elles ne semblent pas générer trop de contentieux.

Il est de jurisprudence constante que contrat de développement de logiciel spécifique relève du contrat de louage d'ouvrage, cependant l'application des principes agiles est susceptible de remettre cette qualification en question. Cette tentative d'éclairage se voulant en premier lieu juridique, les aspects managériaux des méthodes agiles ne feront l'objet de développements qu'en tant que relatifs aux problèmes juridiques posés. La présente contribution n'ayant pas vocation à se soustraire à l'expertise de spécialistes contractuels, l'auteur décline toute responsabilité quant à l'utilisation qui en est faite.

La problématique est la suivante :

Quelles peuvent être les conséquences sur le contrat, de l'adoption d'une méthodologie agile pour la conduite d'un projet de développement logiciel, lorsque l'on souhaite assurer une sécurité juridique constante ?

Pour y répondre il convient d'abord de s'attacher à la qualification du contrat (I), pour ensuite pouvoir déterminer le régime juridique qui lui est applicable (II).

11

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.

1.2 Les Obligations du client

Le client prend traditionnellement avantage dans le rapport de force, notamment de deux manières. La première c'est de réaliser un appel d'offre, de cette façon les prestataires en concours seront prêts à accepter l'impossible pour le remporter. La deuxième, qui accompagne souvent la première, c'est de proposer un projet de contrat comme base de négociations. La partie qui prend cette initiative prend automatiquement avantage sur l'autre car il y aura pour cette dernière beaucoup plus de points à discuter puisqu'elle n'a pas rédigé elle-même la proposition. Lorsqu'elle obtiendra une concession de la part de la partie rédactrice, ce sera au prix d'une autre de sa part. On peut ainsi dire que la partie qui n'a pas rédigé la proposition de contrat démarre la négociation avec une dette.

L'obligation principale pesant sur le client est celle du paiement du prix. Cette obligation correspond à la contrepartie du travail du prestataire tel que nous l'avons défini précédemment. Le périmètre fonctionnel étant de nature changeante, on peut conclure un contrat dans lequel les parties décident dès le départ d'un prix définitif et où le nombre de livrables dépend alors de la quantité de travail à fournir. Cependant le client ne sera pas sûr de parvenir à l'issue du projet pour le prix initial. Ce modèle consiste en réalité en ce que l'on appelle une régie plafonnée, c'est alors davantage le prestataire qui y trouve son

18

compte puisque peu importe la charge de travail, son engagement se limite au prix convenu. En pratique on va essayer de rééquilibrer le risque par des clauses d'indexation du prix des fonctionnalités en fonction de leur complexité ou valeur métier, variables déterminées et mesurées d'un commun accord.

L'obligation de livrer incombant au prestataire correspond à l'obligation du client de prendre livraison. Puisque la chose livrée est incorporelle on peut alors confondre cette obligation avec celle de réception, aussi appelée recette. En effet, pour que prix d'une livraison soit exigible par le prestataire, il faut que le client ait accepté ce qui lui est livré - le plus souvent après une phase de test. La recette est donc la manifestation de la volonté du client d'accepter la livraison. En pratique la recette peut être définitive, provisoire ou faite sous réserves. Le contrat devra de toute façon en préciser les modalités.

L'obligation de collaboration est habituellement considérée comme la contrepartie de l'obligation d'information et de conseil du prestataire dans les contrats de service. Le devoir de collaboration commun à tous les contrats d'entreprise se déduit de l'obligation de bonne foi posée à l'article 1134 al.3 du code civil. Il est néanmoins limité puisqu'on l'y conçoit d'abord de manière négative : le devoir de non-immixtion du maître de l'ouvrage dans les travaux de l'entrepreneur. Ainsi, ce dernier peut s'exonérer de sa responsabilité si les faits invoqués résultent d'une intervention du maître de l'ouvrage. Une ingérence du maître de l'ouvrage peut également entraîner la responsabilité pénale de l'entrepreneur pour prêt de main d'oeuvre illicite (II, 1.1).

Ce devoir de non-immixtion est toutefois à tempérer car, dans le contexte d'une méthode agile, la notion de collaboration est beaucoup plus exacerbée que pour une méthode classique. Deux des quatre valeurs fondamentales du manifeste agile impliquent cela :

« Les individus et leurs interactions plus que les processus et les outils f...] La collaboration avec les clients plus que la négociation contractuelle ».

19

Quant aux principes concernés, il y en a plusieurs, mais le plus évocateur est le suivant :

« Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »

On voit bien que l'agilité éloigne le contrat du cadre du louage d'ouvrage eu égard à la question d'indépendance. Dans le contrat fourni en annexe on trouve d'autres obligations qui se rattachent à la collaboration :

maintenir la disponibilité de personnel qualifié, notamment le chef de projet client, pour aider le prestataire à effectuer ses prestations ;

mettre à disposition du prestataire tous les moyens nécessaires notamment précisés dans le plan de qualité de service, lui garantir l'accès aux locaux, matériels, selon un planning décidé en commun ;

traiter les demandes du prestataire, par exemple en cas d'obstacle, pour ne pas ralentir le travail ;

L'obligation de collaboration issue d'un contrat agile apporte ainsi une dimension nouvelle, à tel point qu'il est permis d'envisager l'incapacité du contrat d'entreprise à encadrer un projet agile. Il s'agit alors de rechercher quel cadre juridique pourrait correspondre (2).

On rencontre aussi très souvent une obligation de sécurité relative au système informatique utilisé à l'occasion des développements, cette obligation se doit d'être réciproque, les membres des équipes auront à accepter une charte en la matière. En outre, lorsque des données personnelles sont traitées grâce au logiciel objet du contrat, il est courant de trouver des clauses qui laissent à la charge du client la détermination de la façon de respecter la loi informatique et libertés. En effet les SSII préfèrent bien souvent

20

ne pas engager leur responsabilité sur des questions qu'ils ne maîtrisent pas forcément. Cette gestion s'avère souvent être un casse-tête technique et juridique, sans compter que les dispositions applicables sont parfois difficiles à interpréter dans un contexte international. Ce genre de difficultés se rencontre généralement davantage dans les contrats d'intégration que dans les contrats portant exclusivement sur des logiciels.

2. La Recherche d'un cadre juridique

La nature juridique d'un contrat détermine son régime car des règles d'ordre public viennent réglementer chaque contrat nommé. De plus un contrat nommé possède un ensemble de règles supplétives, ce qui permet de compléter le contrat quand certains éléments ont été omis par les parties.Le contrat agile laisse planer une telle incertitude sur les obligations des parties que l'on pourrait légitimement se demander si l'engagement contracté n'a pas un caractère potestatif. En outre, les obligations en présence sont des obligations de moyens. Celle qui conduit à beaucoup d'interrogations est l'obligation de collaboration, elle pèse évidemment sur les deux parties conformément aux principes agiles.

On peut certainement argumenter dans le sens de l'existence d'un avant contrat, plus précisément d'une promesse synallagmatique de contracter. En effet dans notre cas deux personnes s'engagent l'une envers l'autre à conclure de futurs accords. Ces accords portent notamment sur les livraisons et le transfert des droits intellectuels. Mais c'est insuffisant puisqu'il s'agit ici de sécuriser la démarche agile de manière proactive, on va donc rédiger un contrat dès que possible, quitte à le préciser et le compléter ensuite. Ainsi, pour un projet piloté selon une méthode agile, deux cadres juridiques sont selon nous susceptibles d'application : le contrat de louage d'ouvrage (2.1) et le contrat de société (2.2).

Afin de limiter les risques de requalification par le juge, les parties peuvent insérer dans le contrat une « clause de détermination » pour préciser la qualification qu'il convient de donner à l'acte et, également, celles à exclure. La qualification donnée par les parties doit correspondre à une des qualifications que le contrat est susceptible de recevoir au vu de ses éléments objectifs. C'est alors la volonté des parties qui doit guider le juge dès lors que la qualification proposée ne se heurte pas à une réglementation impérative.

Il faut néanmoins souligner qu'une clause de détermination n'est pas efficace lorsqu'elle poursuit un but frauduleux, cherchant à faire échapper le contrat aux conséquences impératives de la qualification à laquelle il devrait normalement être soumis. Ainsi, la clause ne permet pas d'éviter la requalification du contrat en contrat de travail, risque fréquent avec les contrats d'entreprise, mais aussi avec les sociétés en participation¹¹.

2.1. Le Contrat de louage d'ouvrage

Il est constant que la doctrine et la jurisprudence considèrent l'activité de développement d'un logiciel spécifique comme une prestation de service relevant du contrat d'entreprise. Le logiciel standard faisant, quant à lui, l'objet d'un contrat de vente. L'article 1710 du code civil définit ainsi le contrat d'entreprise : « Le louage d'ouvrage est un contrat par lequel l'une des parties s'engage à faire quelque chose pour l'autre, moyennant un prix convenu entre elles. » Définition qui ressemble fort à celle du contrat en général, à l'article 1101 du même code : « Le contrat est une convention par laquelle

21

11 Cass. ch. sociale, 25 octobre 2005, n° 01-45147, Publié au bulletin

22

une ou plusieurs personnes s'obligent, envers une ou plusieurs autres, à donner, à faire ou à ne pas faire quelque chose. »

La doctrine actuelle semble unanime sur la nature incertaine du contrat d'entreprise et sur la capacité limitée de la jurisprudence à y remédier, consensus parallèle à l'idée d'une réforme du droit des contrats, voire de la nécessité d'un code européen des contrats. On peut expliquer ces incertitudes par les changements de paradigme induits au cours des différentes révolutions industrielles et par la construction empirique d'un droit des contrats spéciaux hyper spécialisé se mélangeant les pinceaux ; aussi par les confusions terminologiques opérées par les praticiens, y compris les rédacteurs du code civil.

Toutefois, la définition de l'article 1701 du code civil a été complétée par la doctrine et la jurisprudence, redonnant au contrat de louage d'ouvrage une certaine légitimité. Ainsi, le contrat d'entreprise est-il aujourd'hui davantage « la convention par laquelle une personne charge une autre, moyennant rémunération, d'exécuter, en toute indépendance et sans la représenter, un travail. »12

Ce qui le distingue du contrat de travail c'est que l'entrepreneur effectue son ouvrage en toute indépendance. Le travail est ainsi effectué sans représentation, ce qui l'oppose au contrat de mandat. Et pour clairement le distinguer du contrat de vente la doctrine contemporaine a tendance à ajouter le critère du caractère « sur mesure » de la prestation.¹³

C'est bien cette question d'indépendance du prestataire qui pose problème dans un cadre agile vu la place qu'on accorde à la notion de collaboration. L'obligation de collaboration est accessoire dans le contrat d'entreprise tandis qu'en l'espèce on y attache bien plus d'importance, ce qui la ramène à une place essentielle en plus de tempérer

12 Cass. civ. 1ère, 19 février 1968 : Bull civ. I, n°69 ; JCP 1968, II, 15490

13 G. Durant Pasquier, Le maître de l'ouvrage, contribution à l'harmonisation du régime du contrat d'entreprise, Paris II, 2005, n° 263

23

grandement la portée du devoir de non-immixtion du prestataire. L'obligation de collaboration semble même peser sur chacune des parties dans le contrat agile.

2.2. Le contrat de société

Si l'on considère cette volonté de collaboration comme essentielle cela la rapproche de la notion d'affectio societatis. Une fois les principes agiles bien assimilés il est plutôt aisé de concevoir ce glissement de collaboration à association (ou société). Mais dès que l'on prend connaissance de quelques clauses qui se retrouvent régulièrement dans les contrats agiles, on voit clairement que certaines impliquent d'une part le partage du risque (acceptation d'une variabilité de la complexité des livrables), et d'autre part le partage des gains et des pertes (écart entre valeur évaluée et valeur produite, ou encore écart entre délai estimé et délai effectif, toujours à propos des livrables). Nous examinerons davantage ces clauses dans la seconde partie, lors de la rédaction du contrat agile.

Dans ce cas pourquoi ne pas considérer que nous sommes en présence d'un contrat de société ? Le contrat de société est défini dans le code civil à l'article 1832 :

« La société est instituée par deux ou plusieurs personnes qui conviennent par un contrat d'affecter à une entreprise commune des biens ou leur industrie en vue de partager le bénéfice ou de profiter de l'économie qui pourra en résulter.

Elle peut être instituée, dans les cas prévus par la loi, par l'acte de volonté d'une seule personne.

Les associés s'engagent à contribuer aux pertes. »

On a donc plusieurs critères :

La composition : « un ou des associés, », ce critère est satisfait par la présence des parties ;

Les apports : « qui affectent leurs biens ou leur industrie, », le prestataire apporte ses compétences et son travail tandis que le client apporte des fonds ;

La volonté de collaboration active, volontaire et intéressée (ou affectio societatis) : « à une entreprise commune, », ce critère peut être satisfait comme nous l'avons expliqué plus haut, il n'est cependant pas indispensable selon les adeptes du courant objectiviste. M. Viandier estime que l'affectio societatis est un critère psychologique qui se satisfait lui-même : il y a une société parce que les associés se comportent comme tel, il y a une société parce qu'il y a une société. Il a affirmé qu'il faudrait distinguer les associés et les simples investisseurs, ces derniers plaçant de l'argent dans la société mais n'entendant pas collaborer à sa vie¹⁴.

L'objet social : « en vue de partager le bénéfice ou de profiter de l'économie qui pourra en résulter. », cet objet pourrait être « concevoir un logiciel », « collaborer à la conception d'un logiciel », ou encore « profiter de l'économie réalisée à l'occasion du développement d'un logiciel de façon collaborative ». Pour éviter une requalification au motif d'une inégalité entre les parties, il serait bon d'organiser un transfert équitable de la propriété du logiciel. Par exemple le prestataire pourrait conserver le droit d'exploiter les codes sources selon certaines modalités, cela semble

24

14 Alain VIANDIER, La notion d'associé, Paris, Librairie générale de droit et de jurisprudence, 1978, 314 pages

25

être un minimum. Dans la même optique, le pouvoir de décision devra être partagé entre les associés.

La participation aux résultats : « Les associés s'engagent à contribuer aux pertes. », celle-ci peut résulter de clauses conduisant à un partage du risque (clause de partage des gains et pertes, clause gagnant-gagnant,...), néanmoins la Cour de cassation a pu rappeler le principe selon lequel « la participation aux pertes manifestant l'existence d'une société peut résulter des conséquences de l'exécution du contrat et non uniquement des stipulations de celui-ci »¹⁵. Dans la même décision elle affirme « que l'affectio societatis peut découler de la volonté de participer aux bénéfices et aux pertes dans une entreprise commune ». Encore faudrait-il que l'on puisse considérer les conséquences envisageables d'un contrat comme relevant d'une réelle volonté. Pour cela, un référentiel fiable semble requis, pour rappel les méthodes agiles valorisent « Les individus et leurs interactions plus que les processus et les outils »¹⁶.

En outre on peut déduire de ces critères un principe d'égalité, lequel est régulièrement rappelé en jurisprudence, y compris par le Conseil constitutionnel¹⁷. Ce principe signifie que doit exister une égalité des parts ou des actions et que doivent être évitées ou sanctionnées toutes les inégalités qui ne prendraient pas directement leur source dans l'intérêt commun ou dans un usage légitime du pouvoir résultant des parts détenues.

La douzième chambre, deuxième section de la Cour d'appel de Versailles a fait application de ces critères le 4 mars 1999 à l'occasion d'un litige portant sur la création d'un logiciel spécifique. Le prestataire n'avait pas été à même d'élaborer le logiciel commandé dans un délai convenable et avait livré des éléments disparates dénués de toute

15 Cass. Com. 19 nov. 2002, n° 99-14.919

16 Manifeste agile, op. cit., p5

17 Cons. const., 16 janv. 1982, no 81-132 DC, Rev. sociétés 1982, p. 132, note J. G. ; Cons. const., 7 janv. 1988, no 87-232, Rev. sociétés 1988, p. 229, note Guyon ; T. com. Lyon, 5e ch., 7 déc. 1993 : Juris-Data n° 042218

26

performance. Le client, mécontent, demandait la résolution judiciaire de la convention pour manquements par le prestataire à son obligation de délivrance.

Pour se défendre, le fournisseur arguait que s'il était tenu de certaines obligations pour sa part, le client était tenu d'une obligation de collaboration, de sorte que le contrat devait être qualifié de contrat de société, société en participation, et, dès lors, inclure une certaine forme d'aléa. Le tribunal saisi ne suivit pas le prestataire dans cette tentative et décida que la simple collaboration résultant d'une convention de prestation de services ne permettait nullement de dire qu'il y avait eu création d'une société en participation.

Le prestataire ne rapportant pas la preuve de l'affectio societatis, des apports et de la volonté de partager les bénéfices et les pertes, il n'y avait pas eu de volonté de se comporter de part et d'autre sur un pied d'égalité. La résolution fut alors prononcée aux torts du fournisseur.

Si l'on s'oriente vers une qualification en contrat de société il faudra alors prendre soin de bien respecter les critères nécessaires. S'agissant de la forme juridique, c'est la société en participation qui semble la meilleure alternative au contrat d'entreprise pour notre projet agile. L'intérêt de la société en participation est qu'elle n'a pas à être immatriculée, qu'elle n'a pas la personnalité morale ni de patrimoine propre. Elle n'est pas non plus soumise à publicité. Les sociétés en participation peuvent être civiles ou commerciales, selon leur objet.

En outre c'est cette qualification qui semble être la plus intéressante d'un point de vue fiscal, aspect qui mériterait à lui seul de faire l'objet d'une étude. Utiliser la procédure de rescrit pour s'assurer ou non de la licéité du montage pourrait en constituer le préalable. Notons que lorsque le contribuable pénètre la sphère de l'abus de droit, le délai de réponse de l'administration passe de trois à six mois en vertu de l'article L64 B du livre des procédures fiscales (ci-après « LPF »). Pour se rassurer on peut se rappeler que le principe

d'autonomie du droit fiscal par rapport au droit privé n'a qu'une portée limitée¹⁸. La société devra néanmoins être déclarée à l'administration fiscale. En effet, celle-ci peut, sans invoquer même implicitement la procédure de répression des abus de droit, écarter comme ne lui étant pas opposable une convention de société en participation à laquelle les parties ont entendu conserver un caractère occulte¹⁹. C'est-à-dire qu'à défaut de déclaration le contribuable ne pourra pas solliciter l'avis du comité de l'abus de droit fiscal pour contester la position de l'administration, comme cela est normalement prévu à l'article L64 du LPF.

Puisqu'il s'agit de fiscalité, on peut évoquer le fait que le développement logiciel peut dans certains cas être une activité éligible au crédit d'impôt recherche.²⁰

27

18 M. Cozian, Les grands principes de la fiscalité des entreprises, op. cit., doc. n° 1, p. 6, n° 6 : "Propos désobligeants sur une tarte à la crème : l'autonomie et le réalisme du droit fiscal"

19 CE 29 janvier 2003 n° 233373, 8e et 3e s.-s., SNC Cidal, concl. G. Bachelier, BDCF 4/03 n° 53

20 4 A-1-00 BOI n°27 du 8 FEVRIER 2000 ; 274 A-3-12 BOI n° 19 du 23 février 2012

28

II. Le régime juridique du contrat agile

Il s'agit ici de déterminer quelles sont les règles de droit applicables à notre situation contractuelle. Nous étudierons d'abord le droit applicable (1), puis les questions de responsabilité et de contentieux (2).

1. Droit applicable

Si l'on reporte l'étude des questions de responsabilité (2), l'exposé des règles relatives au régime du contrat en lui-même sera relativement succinct (1.1). Ces dernières sont peu nombreuses à côté de toutes les réglementations susceptibles de s'appliquer à l'occasion un projet de développement de logiciel spécifique, qu'il soit ou non piloté selon une démarche agile (1.2).

29

1.1 droit du contrat

Dans les contrats internationaux les parties vont être amenées à déterminer la loi qui sera applicable à leurs relations. Le choix de la loi française permettra au contractant plus au fait du droit Français de mieux maîtriser l'étendue de ses obligations contractuelles. De plus un professionnel du droit français sera toujours plus accessible qu'un professionnel d'un droit étranger.

Le contrat de louage d'ouvrage est réglementé par les articles 1787 et suivants du code civil. Ces dispositions dérogent au droit commun des obligations qui s'appliquera alors de façon subsidiaire par rapport au droit spécial du contrat de louage d'ouvrage.

Le régime juridique de la société en participation est prévu par le code civil, elle y est définie à l'article 1871 :

« Les associés peuvent convenir que la société ne sera point immatriculée. La société est dite alors " société en participation ". Elle n'est pas une personne morale et n'est pas soumise à publicité. Elle peut être prouvée par tous moyens.

« Les associés conviennent librement de l'objet, du fonctionnement et des conditions de la société en participation, sous réserve de ne pas déroger aux dispositions impératives des articles 1832, 1832-1, 1833, 1836 (2ème alinéa), 1841, 1844 (1er alinéa) et 1844-1 (2ème alinéa). »

L'article suivant dispose qu' « A moins qu'une organisation différente n'ait été prévue, les rapports entre associés sont régis, en tant que de raison, soit par les

30

dispositions applicables aux sociétés civiles, si la société a un caractère civil, soit, si elle a un caractère commercial, par celles applicables aux sociétés en nom collectif. »

Si le client a l'intention de louer ou revendre le logiciel, d'en commercialiser des exemplaires ou toute autre opération ayant pour effet de donner à la société un objet commercial, l'absence de statuts impliquera la soumission au règles applicables aux sociétés en nom collectif, codifiées aux articles L221-1 et suivants du code de commerce.

En revanche, si l'objet de la société se limite à la création du logiciel, alors la société aura un caractère civil et sera soumise aux règles applicables aux sociétés civiles, c'est-à-dire les articles 1845 et suivants du code civil.

Même si la société en participation peut être prouvée par tous moyens on peut trouver nécessaire de rédiger ses statuts, ne serait-ce que pour éclairer l'administration fiscale sur son objet. Les associés voudront probablement en préciser l'organisation pour anticiper sur les problèmes de droit social quant à la mise à disposition de main d'oeuvre (1.2). Cependant cette idée d'organisation ne doit pas conduire à une bureaucratie excessive, à ce titre il est utile de rappeler les deux derniers principes agiles :

« Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

En ce qui concerne l'interprétation du contrat, les articles 1156 à 1164 du code civil sont applicables. Il résulte de ces dispositions que les juges ne doivent pas dénaturer

31

une clause claire et précise.²¹ Les parties peuvent également se référer aux principes UNIDROIT ou PECL pour l'interprétation de leur convention, cette référence devra résulter d'une clause claire et précise. De la même manière, si l'on utilise une méthode agile et que l'on souhaite que les principes agiles guident l'interprétation du contrat, il faudra le préciser clairement, en choisissant un ordre de préférence si l'on se réfère à plusieurs sources normatives.

Même remarque en ce qui concerne la complétion du contrat, c'est-à-dire si les parties ont omis certaines stipulations. En effet l'article 1135 du code civil dispose que « Les conventions obligent non seulement à ce qui y est exprimé, mais encore à toutes les suites que l'équité, l'usage ou la loi donnent à l'obligation d'après sa nature. ». Les parties peuvent par exemple se référer à « l'état de l'art agile », en prenant soin de déterminer la ou les sources de cet état de l'art, quitte à les reprendre dans un document annexé au contrat pour éviter tout équivoque.

1.2 Réglementations diverses

En matière de propriété intellectuelle vont s'appliquer les dispositions relatives à la cession des droits de l'auteur et, à mi-chemin avec le droit social, le droit des créations salariées en matière de logiciel. On peut également citer les dispositions spécifiques qui viennent limiter l'exercice de son droit moral par l'auteur d'un logiciel.

Lorsqu'il est une création originale, le logiciel est protégé par le droit d'auteur. La condition d'originalité est remplie lorsque le logiciel porte la marque de l'apport

21 Civ. 15 avr. 1872, DP 1872, I, 176 ; S. 1872, I, 132. V. J. BORE, « Un centenaire : le contrôle par la Cour de cassation de la dénaturation des actes », RTD civ. 1872.249

32

intellectuel de son auteur.²² En cas de plagiat, le contrefacteur ne sera ainsi réputé auteur que des parties portant « la marque de son apport intellectuel ». Cependant l'article L113-9 du code de la propriété intellectuelle dispose :

« Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur qui est seul habilité à les exercer.

« Toute contestation sur l'application du présent article est soumise au tribunal de grande instance du siège social de l'employeur.

« [...] »

Par conséquent, dans la plupart des cas seul l'employeur jouit de droits d'auteur sur le logiciel créé par ses employés. En revanche, si les effectifs du prestataire et du client travaillent ensemble, conformément à la méthodologie agile, les employés du prestataire pourraient être amenés à suivre des instructions dictées par un ou des employés du client. Cela pose problème non seulement quant à l'attribution de la qualité d'auteur, l'oeuvre risquant d'être soumise au régime de l'oeuvre collective, mais cela peut aussi consister en un prêt de main d'oeuvre illicite.

En ce qui concerne la transmission des droits, premièrement « La cession globale des oeuvres futures est nulle »²³. Cela signifie qu'une clause dans l'accord initial qui stipulerait que toutes les livraisons du logiciel seraient transmises du même coup serait nulle et sans effet, sinon celui d'un pacte de préférence. Les oeuvres cédées doivent donc d'abord être précisément identifiées.

22 Cass. ass. plén. 7 mars 1986 : Bull. civ. 1986 n^° 3, p. 5

23 CPI, article L131-1

33

Ensuite, « La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. », c'est la formule de l'article L131-3, alinéa premier, du CPI. Par conséquent, la méthode agile étant itérative, on pourra soit transmettre les droits à chaque livraison ayant donné lieu à recette sans réserves, soit à l'issue des développements, c'est-à-dire une fois que le logiciel aura été livré en totalité.

En matière de droit social, comme nous l'avons évoqué plus haut, on peut facilement glisser vers une situation illicite. En effet, un contrat de prestation de service encourt la requalification en contrat de travail si un lien de subordination peut être établi entre le client et le prestataire. Par exemple dans le cas où les employés du prestataire reçoivent des instructions du client et vice-versa, il y a un risque pour que cet acte soit qualifié de prêt de main d'oeuvre illicite. Le prestataire doit agir en toute indépendance pour rester dans le cadre du contrat de louage d'ouvrage. Selon la jurisprudence cette indépendance se caractérise par différents éléments : liberté d'horaires, initiative des décisions dans l'exécution du contrat, etc.

Cependant, lorsqu'elle a un but non lucratif cette opération est licite à condition de respecter les dispositions de l'article L8241-2 du code du travail. Cependant les obligations déclaratives sont contraignantes et l'accord du salarié est nécessaire, dans le cas contraire celui-ci pourra demander la requalification de son contrat de travail.

Le dernier alinéa de l'article L8241-1 du code du travail dispose qu' « Une opération de prêt de main-d'oeuvre ne poursuit pas de but lucratif lorsque l'entreprise prêteuse ne facture à l'entreprise utilisatrice, pendant la mise à disposition, que les salaires versés au salarié, les charges sociales afférentes et les frais professionnels remboursés à l'intéressé au titre de la mise à disposition. » En l'espèce la situation est différente puisque le client va payer pour des fonctionnalités livrées, le prestataire facture certainement sa prestation au-delà du strict coût de la main-d'oeuvre. Par suite, une

interprétation a contrario de cet article consiste à dire qu'en cas de contrat au forfait la mise à disposition de main-d'oeuvre est illicite.

Si malgré tout le personnel du prestataire est amené à travailler sur site client ou l'inverse, la question des chartes et règlements intérieurs suscite un intérêt double. Du point de vue de l'entreprise qui reçoit le personnel il y a un dilemme : si on fait signer le règlement intérieur et la charte informatique au personnel reçu cela peut indiquer un lien de subordination et par là même rendre l'opération illicite car relevant du travail dissimulé, cependant ces documents sont importants pour des questions de responsabilité. Du point de vue de l'entreprise émettrice, il s'agit du délit de marchandage, autrement dit prêt de main-d'oeuvre illicite. Dans tous les cas elle n'a pas intérêt à voir ses employés signer ce genre de documents.

Afin de lutter contre le travail dissimulé, le code du travail impose au client une obligation de vigilance : « toute personne qui ne s'est pas assurée, lors de la conclusion d'un contrat et tous les six mois, jusqu'à la fin de l'exécution du contrat, dont l'objet porte sur une obligation d'un montant au moins égal à 3 000 euros en vue de l'exécution d'un travail, de la fourniture d'une prestation de services ou de l'accomplissement d'un acte de commerce, que son cocontractant s'acquitte de ses obligations au regard de l'article L. 324-10 [aujourd'hui L8222-1] sera tenue solidairement avec celui qui a fait l'objet d'un procès-verbal pour délit de travail dissimulé »²⁴.

Ce qu'impose l'article L8222-1 du code du travail à l'entreprise cliente, c'est de demander à son prestataire qu'il fournisse de nombreux documents afin de vérifier la situation fiscale et sociale de ce dernier, lors de la conclusion du contrat et tous les six mois jusqu'à la fin de son exécution. L'article D8222-5 du code du travail en précise la liste :

« 1O Une attestation de fourniture des déclarations sociales et de paiement des cotisations et contributions de sécurité sociale prévue à l'article L. 243-15 émanant de l'organisme de protection sociale chargé du recouvrement des

34

24 CA Rennes CH. SÉCURITÉ SOCIALE 2 juin 2010 N° 08/08681

35

cotisations et des contributions datant de moins de six mois dont elle s'assure de l'authenticité auprès de l'organisme de recouvrement des cotisations de sécurité sociale.

« 2° Lorsque l'immatriculation du cocontractant au registre du commerce et des sociétés ou au répertoire des métiers est obligatoire ou lorsqu'il s'agit d'une profession réglementée, l'un des documents suivants :

a) Un extrait de l'inscription au registre du commerce et des sociétés (K ou K bis);

b) Une carte d'identification justifiant de l'inscription au répertoire des métiers ;

c) Un devis, un document publicitaire ou une correspondance professionnelle, à condition qu'y soient mentionnés le nom ou la dénomination sociale, l'adresse complète et le numéro d'immatriculation au registre du commerce et des sociétés ou au répertoire des métiers ou à une liste ou un tableau d'un ordre professionnel, ou la référence de l'agrément délivré par l'autorité compétente ;

d) Un récépissé du dépôt de déclaration auprès d'un centre de formalités des entreprises pour les personnes en cours d'inscription. »

Si le prestataire est un étranger on se référera à l'article D8222-7 du code du travail. Si c'est un particulier c'est l'article D8222-4 qui s'applique. Ces documents sont à fournir dès lors que le contrat porte sur une somme de 3000 euros (article R8222-1 du code du travail).

36

2. Responsabilité et contentieux

La question du contentieux de la responsabilité a vocation à être étudiée sous deux aspects : il convient d'abord de l'étudier au stade de la formation du contrat (2.1) ; puis, une fois le contrat formé, au stade de son exécution (2.2).

2.1 La formation du contrat

La formation du contrat résulte de la rencontre de l'offre et de la demande, tel est l'esprit originel de la liberté contractuelle qui inspira la rédaction du code civil, et dont découle le principe du consensualisme. Cependant tous les contrats ne se forment pas instantanément, à plus forte raison lorsqu'ils sont complexes. La formulation de l'offre peut mettre un certain temps à se construire. C'est ainsi que la doctrine a consacré la théorie des pourparlers. La jurisprudence encadre les pourparlers à travers les principes de liberté contractuelle et de bonne foi. Nombre de contentieux trouvent leur source dans une conduite inadéquate des pourparlers par les parties.

Dans les contrats informatiques, la phase pré-contractuelle est très importante dans la mesure où durant cette phase, le client va définir ses besoins et tenter de trouver le prestataire qui répondra au mieux à ses attentes et à ses contraintes techniques ou économiques. Chacun peut conduire les discussions au mieux de ses intérêts, quitte à négocier en parallèle avec un autre candidat. Cependant les parties qui négocient doivent le faire de manière loyale. Cela implique qu'elles échangent l'information nécessaire,

37

qu'elles ne prolongent pas la discussion lorsque la décision de rompre a déjà été prise ou encore qu'elles ne formulent pas de proposition inacceptable.

Pendant cette phase les parties peuvent être amenées à échanger des informations confidentielles, c'est pourquoi la signature d'un accord sur ce point s'avère souvent indispensable, surtout en matière de nouvelles technologies. Il est en effet fréquent que le client soit amené à communiquer des informations qu'il ne souhaite pas voir divulguées à des tiers pour faire connaître ses besoins et ses objectifs. De même, le candidat prestataire peut être amené à décrire en détail certaines des technologies qu'il maîtrise afin d'argumenter son offre et faire valoir ses avantages. La rédaction d'un tel accord implique une certaine précision afin de pouvoir déterminer quelles sont les informations concernées ainsi que la portée et la durée de l'engagement pris.

De plus les parties vont certainement exposer des frais à la conduite des négociations, que ce soit pour le transport, des études préalables, voire l'embauche de personnel, ce qui est souvent le cas pour les projets les plus ambitieux. Elles peuvent donc également s'engager à partager les frais ainsi générés.

Le recours à une méthode agile n'est pas sans influence sur cette phase pré-contractuelle. Le terrain des négociations risque en effet de glisser des spécifications vers l'organisation. Ceci s'explique par la méthode empirique de construction du cahier des charges ou « product backlog ». Il est alors prévisible que les parties préfèrent raccourcir la durée des négociations pré-contractuelles pour rapidement entrer dans un cadre défini par écrit. Cela est d'autant plus facile pour elles puisque les principes agiles impliquent le changement, qui peut consister en une rupture de la relation. La possibilité de rupture étant envisagée dès le départ, les parties engageront beaucoup moins leur responsabilité lors du recours à cette option, si tant est qu'elles aient été loyales dans leur démarche.

Si les parties sont bien imprégnées de l'esprit des principes agiles pendant les négociations - principes qui impliquent le changement donc une acceptation implicite ou non d'un certain flou dans l'objet de l'engagement - cela va avoir pour effet, d'une part de

38

faire perdre en précision la détermination du moment où leurs volontés se rencontrent, et d'autre part de précipiter le moment de la formation du contrat. En effet, en vertu de l'article 1134 du code civil, seules les conventions légalement formées obligent les parties. Entre professionnels l'écrit n'est pas obligatoire, le contrat sera donc formé dès l'échange des consentements. Ceci n'est pas sans conséquence, en cas de contentieux, sur le travail du praticien. En effet ce dernier aura plus de mal à déterminer le moment exact où le contrat s'est formé, donc à distinguer entre phase pré-contractuelle et phase contractuelle. De plus la phase pré-contractuelle aura tendance a être plus courte puisque les parties sont d'accord sur une part d'indétermination dans leur engagement, indétermination qui résulte de l'adoption d'une méthode agile, ce qui par conséquent accélère l'échange des consentements. Autrement dit il sera plus difficile de savoir ce qui relève de la responsabilité délictuelle ou contractuelle, ce qui relève du droit commun des contrats ou du droit d'un contrat spécial.

La première distinction a toute son importance en matière de stratégie judiciaire : soit on plaide que le contrat s'est formé et on agit sur le fondement de la responsabilité contractuelle, soit on reconnaît qu'aucun contrat ne s'est formé et on demande réparation de la rupture des pourparlers sur le terrain de la responsabilité délictuelle. Effectivement, la faute dans la rupture des pourparlers est purement délictuelle²⁵. En droit allemand la solution est différente puisque l'on considère que l'entrée en pourparlers constitue une sorte d'accord implicite, autrement dit elle créé un rapport d'obligation dans le cadre duquel on applique la responsabilité contractuelle.

Si les parties ont conclu un accord de principe, cela a pour effet de mettre à leur charge une obligation contractuelle de négocier accompagnée d'un devoir de bonne foi.²⁶ La rupture d'un tel accord ne peut être réparée que par des dommages et intérêts sur le fondement de la responsabilité contractuelle de droit commun, l'exécution forcée est exclue dans ce cas puisqu'elle aurait pour seul effet de recommencer des négociations.

25 Paris, 5 avr 2002, RTD civ. 2002.802, obs J. MESTRE et B. FAGES confirmé par Cass. 2e civ., 4 mars 2004, n°02-14022, inédit (demandes en première instance fondées sur la R délictuelle, en appel sur la RCC :1978 irrecevables)

26 CA Paris, 7 nov. 2002, Europe Finance et Industrie (EFI) c/ Viel et Compagnie, Expertises 2003, no 269, p. 153

39

Une alternative à ce type d'accord est le pacte de préférence, par lequel l'une des parties reconnaît à l'autre un droit de priorité à conclure le contrat définitif, c'est-à-dire une sorte de droit de préemption d'origine conventionnelle. Dès lors, si le promettant conclut le contrat projeté avec un tiers sans le proposer au préalable au bénéficiaire du pacte, il engage sa responsabilité contractuelle. Ce type d'engagement peut se rencontrer dans les contrats informatiques, généralement en faveur du prestataire, en contrepartie d'une étude préalable.

Mais ce contrat préalable peut aussi comporter des engagements supplémentaires. Ainsi en est-il de la clause d'exclusivité, par laquelle chaque partie s'engage à s'abstenir de toute autre discussion du même objet avec un tiers.

Il faut noter que le contentieux pré-contractuel échappe aux stipulations habituellement existantes entre les parties si elles sont déjà en relations d'affaires par ailleurs. Elles ont pu par exemple s'engager sur des clauses attributives de compétence, lesquelles ne seront pas applicables. En matière de contrats internationaux c'est l'art 12.1 de la convention de Rome II du 11 juillet 2007 qui règle la question de la loi applicable aux obligations non contractuelles : on applique la loi qui aurait été applicable si le contrat avait été conclu. En outre, la mise en oeuvre de la responsabilité suppose une faute et un dommage reliés par un lien de causalité, la réparation ne pouvant consister qu'en des dommages et intérêts.

2.2 L'exécution du contrat

Une fois formé, le contrat est la loi des parties, il doit être exécuté de bonne foi et oblige « non seulement à ce qui y est exprimé, mais aussi à toutes les suites que l'équité,

40

l'usage ou la loi donnent à l'obligation d'après sa nature. »²⁷ Les parties sont donc tenues d'exécuter les obligations du contrat mais aussi celles que la loi, la jurisprudence ou l'usage imposent dans le cas de telle ou telle relation contractuelle. Une clause d'intégralité peut éventuellement renforcer la portée des engagements souscrits en prescrivant que ceux-ci ne sont pas détachables les uns des autres.

Il convient ici d'envisager les possibilités offertes en cas d'inexécution par le débiteur de l'une ou plusieurs de ses obligations contractuelles. L'expression « inexécution » recouvre plusieurs réalités. Ce peut être une absence d'exécution (totale ou partielle) ou bien une exécution défectueuse. Le créancier de l'obligation est alors en droit d'obtenir l'exécution forcée de la part du débiteur. Cependant l'exécution forcée n'est pas toujours possible, dans ce cas l'inexécution sera compensée par des dommages et intérêts.

La pratique la plus courante est de prévoir les questions de responsabilité dans le contrat. Cependant la loi peut toujours suppléer la volonté des parties en cas de vide contractuel. En revanche, le contrat ne devra pas contredire des dispositions d'ordre public. Les règles qui s'appliqueront seront celles du contrat d'entreprise (I, 2.1 ; II, 1.1), ou celles de la société en participation (I, 2.2 ; II, 1.1). L'intérêt de la distinction entre les obligations de moyens et de résultat prend ici tout son sens. Néanmoins il faut garder à l'esprit que la clause limitative de responsabilité qui contredit la portée de l'obligation essentielle est réputée non écrite²⁸.

Une autre alternative au créancier de l'obligation est de se retrancher derrière l'exception d'inexécution, c'est-à-dire qu'il pourra s'abstenir d'exécuter à son tour la prestation qu'il aurait dû effectuer en contrepartie. Par exemple, on peut retarder contractuellement la cession des droits de propriété intellectuelle sur le code source d'une livraison jusqu'au moment du paiement par le client. Notons au passage que le droit de rétention n'est pas vraiment efficace en matière de logiciel puisque celui-ci peut être facilement reproduit. Il pourrait en revanche être exercé par le prestataire à qui le client,

27 Code civil, article 1135

28 Cour de cassation, 29 juin 2010, Sté. Faurécia contre Sté. Oracle

41

débiteur d'un ou plusieurs paiements, aurait remis du matériel informatique pour qu'il y installe le logiciel et le configure.

Le créancier de l'obligation inexécutée peut également rompre le contrat. Il existe deux possibilités : la résolution et la résiliation.

La résolution du contrat consiste à priver rétroactivement le contrat de tous ses effets, les parties devront alors chacune se restituer leurs prestations. C'est différent de l'annulation (2.1) puisqu'en l'espèce le contrat a été valablement formé. La résolution peut résulter d'une clause résolutoire. Celle-ci prévoit que la convention sera résolue de plein droit dans le cas d'inexécution totale ou partielle de ses obligations par l'un des cocontractants. Si la partie à qui est opposée la résolution la conteste et este en justice, le jugement qui sera prononcé ne fera que constater que les conditions prévues par la clause résolutoire ont bien été réunies.

Néanmoins, « La condition résolutoire est toujours sous-entendue dans les contrats synallagmatiques, pour le cas où l'une des deux parties ne satisfera point à son engagement. »²⁹ La résolution devra alors être demandée en justice. Il existe en revanche, dans certains cas gravissimes, une possibilité de résolution unilatérale consacrée par la jurisprudence.³⁰

Quant à la résiliation, son effet est l'anéantissement du contrat pour l'avenir, elle concerne essentiellement les contrats à exécution successive. L'article 1794 du code civil, en matière de contrat d'entreprise, le prévoit :

« Le maître peut résilier, par sa seule volonté, le marché à forfait, quoique l'ouvrage soit déjà commencé, en dédommageant l'entrepreneur de toutes ses dépenses, de tous ses travaux, et de tout ce qu'il aurait pu gagner dans cette entreprise. »

29 Code civil, article 1184 alinéa 1er

30 Civ. 1ere, 20 fevr. 2001, n° 99-15170, Bull. Civ. I, n° 40 ; D. 2001.1568, note Ch. JAMIN

42

La méthode agile étant une méthode itérative (basée sur des cycles), elle implique des livraisons successives. On préférera alors ce second mode de rupture à moins qu'il s'agisse d'une inexécution grave, par exemple si le prestataire n'exécutait aucune de ses obligations.

Pour régler plus facilement les questions de responsabilité en cas d'inexécution, il peut parfois paraître important de mettre en place une convention de preuve pour déterminer contractuellement de la valeur probante de certains documents qui pourraient être présentés en cas de différend, à l'appui d'un compromis ou d'une action en responsabilité.

Les parties peuvent convenir contractuellement du tribunal qui sera compétent en cas de litige. Cependant, conformément à l'article 48 du code de procédure civile une telle clause ne sera valable qu'entre « des personnes ayant toutes contracté en qualité de commerçant » et lorsqu'elle aura « été spécifiée de façon très apparente dans l'engagement de la partie à qui elle est opposée. » Cette clause est le plus souvent accompagnée d'une clause de conciliation amiable, voire même d'une clause compromissoire fixant la compétence d'un tribunal arbitral.³¹

Si les parties ont décidé de clauses de garanties il conviendra de les appliquer. En l'absence de toute précision, le juge considérerait, en matière de prestations informatiques, que le fournisseur du programme est seulement débiteur d'une obligation de moyens.³² Cependant l'article 1792 du code civil établit une responsabilité du constructeur de l'ouvrage envers le maître ou l'acquéreur de l'ouvrage pour les dommages qui compromettent la solidité de l'ouvrage ou le rendent impropre à sa destination, cette action se prescrit par dix ans. En outre, l'article 1792-3 institue une garantie de bon fonctionnement de deux ans pour les éléments d'équipement dissociables de l'ouvrage.

31 Code civil, article 2059 et suivants

32 Com. 3 déc. 1985, n° 84-14.463, Bull. civ. IV, n° 284 [sol. impl.] , RTD civ. 1986. 372, obs. Rémy, et 765, obs. Huet.

43

L'applicabilité de ces articles, inspirés par le secteur de la construction, est contestable. Comme nous le rappelions en introduction, le développement logiciel est une activité de conception. Néanmoins, l'article 1792-1 assimile l'architecte au constructeur de l'ouvrage. Le législateur de 1978³³ a ainsi voulu appliquer le même régime de responsabilité à toutes les personnes accomplissant « une mission assimilable à celle d'un locateur d'ouvrage », y compris celles accomplissant une prestation strictement intellectuelle. Et c'est dire tous les points communs entre l'architecture et l'architecture logicielle, la seconde n'ayant cependant pas encore acquis - en raison de son jeune age - la même maturité que la première.

La garantie contre les vices cachés ne peut jouer concernant un logiciel que dans l'hypothèse où le contrat porte sur un système dans lequel un vice du logiciel induirait une indisponibilité du service. La Cour de cassation ne semble pas distinguer entre la garantie portant sur le logiciel lui-même et celle portant sur le système complet dans lequel il est intégré, ce qui pourrait être interprété favorablement à la thèse de la garantie légale en matière de logiciel (y compris, peut-être la nouvelle garantie de conformité introduite par l'ordonnance du 17 février 2005)³⁴. Cependant les créations intellectuelles sont soumises à des régimes particuliers. Dans ce cas pourquoi ne pas préférer la garantie contre l'éviction ou garantie de jouissance paisible habituellement appliquée en matière de droit d'auteur, bien qu'empruntant son régime à la vente ? On préférera cependant les garanties conventionnelles eu égard aux incertitudes de régime quant à la garantie dans les contrats portant sur des logiciels.

En ce qui concerne le contentieux relatif à l'exécution du contrat, l'adoption d'une méthode agile ne semble pas avoir de grandes conséquences sinon de former la convention plus rapidement (2.1) et donc de ramener les questions qui auraient fait l'objet d'une responsabilité délictuelle vers le contentieux contractuel.

33 Loi n°78-12 du 4 janvier 1978 - art. 1 JORF 5 janvier 1978 en vigueur le 1er janvier 1979

34 Warusfel B., Recours de l'acheteur face à la défaillance logicielle d'un système, RLDI 2005/4, no 120, p. 32

44

45

Table des matières

I. LA QUALIFICATION DU CONTRAT				11
1. LA DÉTERMINATION DES OBLIGATIONS DES PARTIES				12
1.1 LES OBLIGATIONS DU PRESTATAIRE				13
1.2 LES OBLIGATIONS DU CLIENT				17
2. LA RECHERCHE D'UN CADRE JURIDIQUE				20
2.1. LE CONTRAT DE LOUAGE D'OUVRAGE				21
2.2. LE CONTRAT DE SOCIÉTÉ				23
II. LE RÉGIME JURIDIQUE DU CONTRAT AGILE				28
1. DROIT APPLICABLE				28
1.1 DROIT DU CONTRAT				29
1.2 RÉGLEMENTATIONS DIVERSES				31
2. RESPONSABILITÉ ET CONTENTIEUX				36
2.1 LA FORMATION DU CONTRAT				36
2.2 L'EXÉCUTION DU CONTRAT				39
ANNEXE : CONTRAT DE PRESTATION DE	SERVICE	RÉALISÉ	SELON	LES
MÉTHODOLOGIES AGILES				46

46

Annexe : Contrat de prestation de service réalisé selon les méthodologies agiles

Les commentaires de l'auteur du mémoire sont en bleu, entre des barres dégradées bleues, les commentaires des auteurs du contrat sont en orange.

CONTRAT DE PRESTATION DE SERVICES
RÉALISÉS SELON LES METHODOLOGIES
AGILES

- v 1.1 -

Ce document est sous contrat Creative Commons Paternité-Partage des
Conditions Initiales à l'Identique 2.0 France License
Vous n'avez pas le droit de commercialiser le contrat et ses versions amendées mais pouvez l'utiliser
dans le cadre d'une collaboration client/fournisseur.

47

Les auteurs de ce contrat déclinent toute responsabilité quant à l'utilisation qui en est faite.

Notice : Le contrat contient des zones éditables et des zones de commentaire.

La typologie est la suivante :

D Zone à éditer : <Modifier ce texte>

D Paragraphe facultatif : {paragraphe facultatif} Zone de commentaire : <Commentaire>

- SOMMAIRE -

Ci-après dénommées ensemble les « Parties » et individuellement une « Partie »

ENTRE :

<DÉNOMINATION SOCIALE>

Société <forme juridique> au capital social de <montant> euros, inscrite au RCS de <ville> sous le numéro <numéro>, dont le siège social est sis <adresse>.

Représentée par <nom>, agissant en sa qualité de <statut>, dûment habilité à l'effet des présentes.

Ci-après dénommée le « Client »

D'une part

ET :

Le Prestataire

<Raison Sociale, Adresse, RCS>

Représentée par le signataire du présent contrat, dûment habilité à l'effet des présentes.

Ci-après dénommée « le Prestataire »

D'autre part

Le CLIENT souhaite faire développer une solution de plus grande qualité. Il s'est donc intéressé aux méthodes agiles dans le souci de rester maître de ce développement et de ses contraintes afférentes

Il a été exposé et convenu ce qui suit :

1. PRÉAMBULE

1.1. LE PRESTATAIRE

Le Prestataire est <description de la société Prestataire en quelques lignes>. 1.2. LES MÉTHODES AGILES

Les méthodes agiles sont des groupes de pratiques utilisées notamment dans le cadre des projets de développement de logiciels. Ces méthodes (Scrum, XP) tendent depuis leur apparition dans les années 90 à supplanter les méthodes traditionnelles (méthodes en cascade) en ce qu'elles permettent, grâce au cycle de développement itératif, incrémental et adaptatif, une approche plus pragmatique des besoins du client en autorisant une réactivité permanente à ses demandes et aux besoins évolutifs des utilisateurs, ce qui permet de privilégier la réalisation d'un produit véritablement opérationnel, à moindre coût, dans un délai contraint.

Les principes de ces méthodes agiles ont été exprimés en 2001 dans le Manifeste Agile. Ce manifeste prône quatre valeurs fondamentales :

o « Personnes et interaction plutôt que processus et outils »

o « Logiciel fonctionnel plutôt que documentation complète »

o « Collaboration avec le client plutôt que négociation de contrat »

o « Réagir au changement plutôt que suivre un plan »

De ces quatre valeurs fondamentales, il ressort que l'application des méthodes agiles dans la conduite d'un projet de conception de logiciel implique :

o De disposer d'une équipe de développement soudée et responsabilisée, capable de communiquer efficacement grâce à un cérémonial documentaire minimal.

o

o De donner la priorité au fonctionnement de l'application sur l'élaboration d'une documentation technique exhaustive.

o D'impliquer étroitement le client dans la réalisation de l'application par une collaboration permanente et un retour d'information continu sur l'adéquation des développements à ses attentes.

o De prendre en compte le fait que les conditions et les objectifs d'une entreprise peuvent évoluer avec le temps conduisant à garder la plus grande flexibilité à la planification et aux spécifications initiales afin de permettre l'adaptation aux demandes du client tout au long du projet.

Ces méthodes et leur application par le Prestataire sont plus largement décrites en Annexe 1.

1.3. LE CLIENT

(( Anomalie Bloquante » : désigne toute Anomalie qui provoque l'impossibilité d'utiliser au moins une fonction du Développement ou du Logiciel.

(coût, délai, périmètre évolutif).

Le CLIENT après avoir étudié les bénéfices de ces méthodes considère qu'elles répondent à ses besoins et objectifs :

o disposer d'une méthodologie adaptative, lui permettant de bénéficier d'une organisation informatique claire et pertinente ;

o adapter le logiciel à ses besoins métier, voire changer d'avis, même pendant la phase de développement de celui-ci et au besoin mettre fin au projet s'il estime que celui-ci remplit ses objectifs en cours de réalisation.

Il a, enfin, une parfaite conscience que la maximisation de la valeur produite par le logiciel, née de l'application des méthodes agiles (livraisons fréquentes, implication du client, la gestion des priorités basées sur des estimations de valeur et de coût) nécessite de sa part une grande implication dans la conduite du changement qu'induit l'introduction de ces méthodes dans son entreprise.

C'est pour ces raisons que, connaissant bien les méthodes agiles, et estimant qu'elles lui permettront une parfaite maîtrise des coûts et des délais et une grande souplesse d'adaptation à ses besoins en cours de développement, le CLIENT s'est tourné vers LE PRESTATAIRE.

LE PRESTATAIRE a maintenu à la disposition du CLIENT les informations techniques et commerciales relatives à sa méthodologie de développement pour permettre au CLIENT de confirmer, si besoin en était, que celle-ci est de nature à répondre à ses objectifs. LE PRESTATAIRE est également resté à la disposition du CLIENT pour répondre à toute demande d'information et procéder à toute démonstration que celui-ci a pu requérir.

Dans ces conditions, le CLIENT a établi et transmis au PRESTATAIRE un cahier des charges exprimant ses besoins en termes de fonctionnalités attendues du logiciel. Ce cahier des charges a été reformulé sous la forme de deux documents : Vision (Annexe 2) et Product Backlog V.0 (Annexe 7).Sur la base de ces documents, LE PRESTATAIRE a réalisé une estimation de charges, structure et délais qui est jointe à l'Annexe 3.

Après discussion sur la base de ces documents, les Parties se sont accordées sur les termes du présent contrat dont le préambule fait partie intégrante et dispose de la même valeur que les autres dispositions.

2. DEFINITIONS

Dans le cadre du présent contrat, les termes ci-après avec une majuscule, au singulier ou au pluriel, ont été définis de la manière suivante :

(( Anomalie » : désigne toute anomalie de fonctionnement d'un Développement ou du Logiciel qui consiste en une différence entre le fonctionnement constaté du Développement ou du Logiciel et celui décrit dans le Sprint Backlog pour le Développement ou dans le Product Backlog pour le Logiciel et qui est exclusivement imputable au Développement ou au Logiciel, reproductible et documenté par le CLIENT.

« Sprint » : désigne la séquence de base de réalisation d'un Développement qui est d'une courte durée

« Anomalie Majeure » : désigne toute Anomalie qui génère une dégradation importante d'au moins une fonction du Développement ou du Logiciel ou des performances.

« Anomalie Mineure » : désigne toute Anomalie autre qu'une Anomalie Bloquante ou une Anomalie Majeure qui ne gêne pas l'utilisation du Développement ou du Logiciel et ne dégrade pas leurs performances.

« Vision » : désigne le document établi par le CLIENT avec l'aide du PRESTATAIRE dans lequel celui-ci a consigné les objectifs du projets et les grande fonctionnalités. Le document présentant cette « vision » est joint en Annexe 2. Ce document peut être assimilé à une version, modifiée conformément aux principes agiles, du traditionnel « cahier des charges ».

« Développement » : désigne le programme informatique, en code source et en code objet, qui a vocation à implémenter les fonctions définies dans un Sprint Backlog et qui est délivré à l'issue du Sprint afférent. Le Développement est une subdivision fonctionnelle du Logiciel.

« Logiciel » ou « Product » : désigne le programme informatique final, en code source, regroupant l'ensemble des Développements qui a vocation à implémenter les fonctions définies dans le Product Backlog, ainsi que la documentation d'exploitation afférente.

« Niveaux de Service » : désigne le nombre d'unités de mesure associé à certaines des prestations de service quantifiables prévus dans le Plan Qualité de Service. Les Niveaux de Service faisant l'objet d'un engagement de la part du PRESTATAIRE sont expressément visés dans ledit Plan Qualité de Service.

« Plan Qualité de Service » ou « PQS » : désigne le document qui précise la méthodologie mise en place pour satisfaire les besoins exprimés par le CLIENT en matière de qualité des services fournis dans le cadre du présent contrat. A cet effet, le Plan Qualité de Service décrit la façon dont sont organisées les relations entre les Parties, la liste des tâches incombant à chaque Partie au titre du présent contrat et leur survenance dans le temps ainsi que les Niveaux de Service sur lesquels LE PRESTATAIRE accepte de s'engager pour la réalisation de ses prestations dans le cadre du présent contrat ainsi que les éventuelles pénalités qui y sont associées. Le Plan Qualité de Service sera établi par LE PRESTATAIRE pendant la phase de lancement et sera soumis pour validation au Comité de Pilotage. Toutefois, une version initiale du Plan Qualité de Service est jointe en Annexe 4.

« Story Point » : désigne l'unité de mesure du périmètre d'un logiciel en termes de fonctionnalités. « Product Backlog » : désigne la liste priorisée des fonctionnalités du produit.

« Product Owner » : désigne le membre du personnel du CLIENT qui est l'interlocuteur privilégié et à disposition de l'équipe de développement du PRESTATAIRE. Le Product Owner doit posséder une expertise fonctionnelle métier et le pouvoir nécessaire pour engager le CLIENT aux fins de prendre les décisions nécessaires au bon déroulement de la réalisation des Développements et du Logiciel.

« Scrum Master» : désigne le membre de l'équipe de développement du PRESTATAIRE qui est l'animateur de cette équipe. Il a la charge d'optimiser la capacité de production de cette équipe en l'aidant à travailler de façon autonome et à s'améliorer au fil du temps et de traiter les obstacles qui ralentissent ou empêchent l'équipe de travailler, le cas échéant, en demandant au CLIENT de les supprimer.

« Spécifications » : désigne les spécifications fonctionnelles apportant des compléments au Product Backlog pour le Logiciel et dans les Sprint Backlogs pour les Développements.

(à titre indicatif, de l'ordre de 2 à 4 semaines). Un Sprint débute par un Sprint Planning et se termine par un Sprint Review.

(( Sprint Backlog » : désigne la liste des fonctionnalités à réaliser lors d'un sprint et la liste des tâches correspondantes qui sont établies à l'occasion d'un Sprint Planning. La charge afférente à chaque tâche est déterminée par l'équipe de développement du PRESTATAIRE.

(( Sprint Planning » : désigne la réunion de l'équipe de développement du PRESTATAIRE et du Product Owner qui a lieu au début de chaque Sprint pour déterminer l'objectif et le contenu de celui-ci et qui permet d'établir le Sprint Backlog.

(( Sprint Review » : désigne la réunion de l'équipe de développement du PRESTATAIRE et du Product Owner qui a lieu à l'issue de chaque Sprint pour l'essentiel afin de faire une démonstration du Développement et d'ajuster le contenu du Product Backlog en fonction des souhaits exprimés par le CLIENT.

"Rétrospective" : désigne la réunion qui a lieu à l'issue de chaque Sprint et dont l'objectif est discuter des axes d'améliorations de l'équipe. Sont présents à cette réunion : le Scrum Master, l'équipe, et le Product Owner. Épisodiquement, d'autres acteurs comme le Directeur de Projet PRESTATAIRE peuvent être invités à cette réunion.

3. OBJET DU CONTRAT

3.1. Le présent contrat a pour objet de définir les conditions dans lesquelles et les modalités selon

lesquelles LE PRESTATAIRE s'est engagée à réaliser les prestations de développement du Logiciel :

o en utilisant la méthodologie décrite en Annexe 1 ;

o conformément au Product Backlog (Annexe 7 pour mémoire) et à la Vision joint en Annexe 2 ;

o conformément au Plan Qualité de Service présenté à l'article 6 et dont la version initiale est jointe en Annexe 4 ;

o dans le respect de l'estimation de charges, structure et délais jointe à l'Annexe 3, le cas échéant modifiée dans les conditions du présent contrat ;

o selon les conditions particulières et financières de l'Annexe 5.

3.2. Le présent contrat est régi par les dispositions de l'article 1779 3° du Code Civil.

Le présent contrat est dépourvu de tout affectio societatis et n'aura aucun effet sur l'indépendance de chaque Partie en ce qui concerne l'exercice de son activité et la poursuite de son objet social, chaque Partie continuant à exercer en toute indépendance sa gestion, ses droits

et ses obligations et à assumer ses responsabilités. A ce titre, il ne peut en aucun cas être
interprété comme créant entre les Parties un lien d'associés, une relation de mandat ou comme un contrat de location gérance ou même de sous-traitance de l'activité du CLIENT. Il est exclusif de toute notion de mise à disposition de personnel entrant dans le cadre de la réglementation sur le travail temporaire.

4.1. L'accord conclu entre les parties comprend par ordre de valeur juridique décroissante :

4. DOCUMENTS CONTRACTUELS

o le présent contrat, les Conditions Particulières jointes en Annexe 5 et l'estimation de charges, structure et délais jointe en Annexe 3 dans sa version V0, le cas échéant modifiée dans les conditions du présent contrat ;

o la Méthodologie Agile jointe en Annexe 1 ;

o le Plan Qualité de Service dans sa dernière version, approuvée par le Comité de Pilotage, qui annulera et remplacera la version V0 jointe en Annexe 4 ;

o le Product Backlog ;

o La vision, jointe en Annexe 2.

Ces documents sont désignés ci-après ensemble par le « Contrat ».

4.2. En cas de contradiction entre deux ou plusieurs des documents ci-dessus, le document situé le

plus haut dans la hiérarchie contractuelle prévaudra, que ladite contradiction soit volontaire ou non. En cas de document susceptible de faire l'objet de versions successives, la version la plus récente du document prévaudra.

4.3. Les versions successives des documents approuvés en Comité de Pilotage, ont la même valeur

contractuelle que le document initial (V0) et prendront place de la précédente version annulée et remplacée par la dernière version approuvée en Comité de Pilotage.

4.4. Les éventuels avenants au Contrat devront indiquer leur rang dans la hiérarchie contractuelle. À

défaut, ils auront le rang du document qu'ils ont pour objet de modifier et, en cas de pluralité de documents modifiés par le même avenant, le rang du document amendé le moins élevé dans la hiérarchie contractuelle. Si un avenant n'indique pas son rang dans la hiérarchie contractuelle et qu'il n'a pas pour objet de modifier un ou plusieurs documents déjà existants, il acquerra automatiquement le rang le moins élevé dans la hiérarchie contractuelle.

4.5. Par ailleurs, dans l'hypothèse où une disposition du Contrat serait considérée comme nulle,

invalide ou inapplicable, par une loi, un règlement ou une décision de justice passée en force de chose jugée, elle sera réputée non écrite et les autres dispositions du Contrat garderont toute leur force et leur portée. Les Parties s'efforceront dans un délai de un (1) mois, à compter de l'événement ayant entraîné la nullité, l'invalidité ou l'inapplicabilité de la clause, de s'accorder sur les termes d'une clause de remplacement respectant l'esprit et l'économie de la clause précédente, et plus généralement du Contrat, et conformément aux règles d'interprétation des articles 1156 et suivants du Code civil.

5. MISE EN OEUVRE DES PRESTATIONS

5.1. DÉCOUPAGE DES PRESTATIONS

La réalisation des prestations objet du Contrat comprendra une phase de lancement puis une phase opérationnelle et, le cas échéant, une phase de finalisation.

5.1.1. Phase de lancement

La phase de lancement comprend les prestations initiales de mise en place des conditions méthodologiques, organisationnelles, matérielles et humaines en vue de la réalisation des prestations de développement du Logiciel.

La phase de lancement permet également d'actualiser le périmètre fonctionnel du Logiciel consigné dans la Vision sur la base duquel LE PRESTATAIRE a produit son estimation de charges, structure et délais et, le cas échéant, d'ajuster ces documents.

La phase de lancement comprend les opérations suivantes :

o Établissement du Plan Qualité de Service.

o Réalisation du Sprint 0 qui recouvre notamment :

? La présentation des personnels du PRESTATAIRE et du CLIENT impliqués dans la

réalisation des prestations objet du Contrat.

? La mise en place de la Méthodologie AGILE présentée en Annexe 1.

? La mise en place de l'infrastructure de développement et de l'usine logicielle choisies

par LE PRESTATAIRE.

? L'ajustement par LE PRESTATAIRE de l'estimation de charges, structure et délais à la
hausse ou à la baisse conformément aux Conditions Particulières.

? La revue du Product Backlog.

? L'établissement du contenu du Sprint suivant.

o Réalisation des Sprints 1 à 3 : Les sprints 1 à 3 sont des sprints de production dont les objectifs sont :

o Délivrer des incréments de logiciels.

o Stabiliser les indicateurs et métriques associées choisis dans le PQS. A l'issue du sprint 3, PRESTATAIRE s'engage sur la valeur définitive des seuils d'alerte pour chaque indicateur.

5.1.2. Phase opérationnelle

La phase opérationnelle des prestations de développement du Logiciel est composée de Sprints successifs à l'issue desquels LE PRESTATAIRE délivrera un Développement qui devra être validé

par le CLIENT selon la procédure de réception des Développements visée à l'article 9.

La phase opérationnelle des prestations s'achèvera par la délivrance du Logiciel par LE PRESTATAIRE qui devra être validé par le CLIENT en vertu de la procédure de réception du Logiciel visée à l'article 8.

5.1.3. Phase de finalisation

Si le CLIENT met en oeuvre la procédure résultant des dispositions de l'article 17.2 du Contrat « ATTEINTE ANTICIPÉE DES OBJECTIFS DU CLIENT », les Parties poursuivront l'exécution du Contrat pendant deux Sprints de manière à finaliser la mise au point des Développements issus du dernier Sprint exécuté ou en cours d'exécution au jour de la décision du CLIENT.

Les Sprint Backlogs de ces deux derniers Sprints seront arrêtés par le Comité de Pilotage.

5.2. LIEU D'EXÉCUTION DES PRESTATIONS

Le lieu d'exécution des prestations est fixé aux Conditions Particulières.

5.3. PERSONNELS AFFECTÉS À LA RÉALISATION DES PRESTATIONS

5.3.1. Les personnels du PRESTATAIRE, même s'ils venaient à être détachés dans les locaux du CLIENT, resteront en toutes circonstances sous l'autorité hiérarchique et disciplinaire du PRESTATAIRE qui est leur seul employeur et qui assumera la gestion sociale, administrative et comptable de celui-ci.

A ce titre, LE PRESTATAIRE devra obtenir tous passeports, visas, permis de travail, autorisations et autres documents nécessaires à l'emploi de ses personnels.

LE PRESTATAIRE sera seul responsable de la répartition des tâches, de la programmation des tâches et de l'acceptation des tâches réalisées par ses personnels.

Les absences des personnels, pour quelque motif que ce soit, et notamment maladie, formation et congés, seront autorisées et/ou gérées par LE PRESTATAIRE. Cette dernière devra toutefois veiller à :

? informer le CLIENT de l'absence d'un membre du personnel dans les meilleurs délais et rechercher avec lui une solution permettant d'assurer la continuité des prestations ;

? autoriser les périodes de congé ou de formation des personnels en concertation avec le CLIENT en vue du bon déroulement des prestations.

5.3.2. En aucune manière les personnels du PRESTATAIRE ne sauraient être soumis à un quelconque lien de subordination émanant du CLIENT et, réciproquement, les personnels du CLIENT en contact avec LE PRESTATAIRE ne sauraient être soumis à l'autorité, ni à la subordination de cette dernière.

Cette clause ne suffit pas à éviter toute infraction à la législation sociale (travail dissimulé et prêt de main d'oeuvre illicite), les stipulations qui y figurent doivent impérativement être respectées (voir II, 1.2).

5.4. ENVIRONNEMENT TECHNIQUE

A compléter : Description de l'environnement technique du projet

Le CLIENT fournira au PRESTATAIRE toutes autres ressources humaines, techniques, logistiques et organisationnelles nécessaires à la bonne exécution des prestations de développement du Logiciel.

6. PLAN QUALITE DE SERVICE

6.1. Les relations entre les Parties, notamment au sein du Comité de Pilotage, le déroulement des

Sprints, le détail des rôles et responsabilités de chaque Partie seront précisés dans le Plan Qualité de Service qui sera réalisé pendant la phase de lancement.

6.2. Le Niveau de Service fourni au CLIENT sera également défini dans le Plan Qualité de Service

pendant la phase de lancement. Il contiendra la liste des valeurs mesurables permettant d'exprimer de manière factuelle le niveau du service rendu. L'obligation contractuelle du PRESTATAIRE, quant à la qualité du service, sera ainsi énoncée par ces grandeurs objectivement mesurables et représentatives. Le Plan Qualité de Service précisera également comment et avec quelle fréquence seront mesurés les indicateurs concernés.

6.3. {Le Plan Qualité de Service prévoira les pénalités contractuelles applicables en cas de non

atteinte d'un Niveau de Service.

Le fait générateur d'une pénalité sera un écart constaté entre le Niveau de Service d'une prestation effectivement mesuré à l'aide d'un indicateur défini au Plan Qualité de Service et le Niveau de Service souscrit pour ladite Prestation.

Les pénalités seront calculées sur une base périodique à partir des formules de calcul exposées dans la Plan Qualité de Service.

Les pénalités ne seront pas applicables dans les cas de non responsabilité du PRESTATAIRE visés à l'article 10 et, en tout état de cause, lorsque la non-atteinte d'un Niveau de Service n'est pas imputable à un manquement du PRESTATAIRE à ses obligations contractuelles.

A la fin de la périodicité prévue dans le Plan Qualité de Service, les pénalités seront consolidées dans un document qui donnera lieu à une réunion du Comité de Pilotage. Au cours de cette réunion, LE PRESTATAIRE indiquera celles des pénalités qui selon elle ne devraient pas être appliquées, en particulier, lorsque LE PRESTATAIRE estimera qu'elle n'est pas responsable de la non atteinte du Niveau de Service d'une prestation.

A l'issue de cette réunion, le CLIENT décidera, dans un délai de cinq (5) jours ouvrés, des pénalités qu'il appliquera effectivement et de celles qu'il abandonne. Pour celles que le CLIENT appliquera, il devra émettre une demande par lettre recommandée avec accusé de réception adressée au PRESTATAIRE. Les pénalités non réclamées dans le délai susvisé seront réputées abandonnées par le CLIENT.

En tout état de cause, le montant consolidé de toutes les pénalités sur la période considérée sera plafonné un pourcentage (défini dans l'Annexe Financière) du montant de la dernière facture en date émise par LE PRESTATAIRE.

Les avoirs émis au titre des pénalités constituent une indemnité forfaitaire de dommages-intérêts pour ce qui concerne les manquements du PRESTATAIRE à l'origine desdites pénalités.}

6.4. Une version initiale V 0 du Plan Qualité de Service est fournie en Annexe 4.

7. INTERLOCUTEURS PRIVILÉGIÉS - COMITE DE PILOTAGE

7.1. En complément des rôles traditionnels décrits en Annexe 1, chacune des Parties s'engage à désigner un interlocuteur privilégié chargé des relations avec l'autre Partie.

Le CLIENT désignera un interlocuteur responsable (dénommé ci-après le « Chef de Projet CLIENT »), ayant une connaissance approfondie de l'organisation du CLIENT et de l'ensemble des besoins du CLIENT. Cet interlocuteur devra disposer des pouvoirs suffisants pour prendre les décisions engageant le CLIENT.

8. RÉCEPTION DES DÉVELOPPEMENTS ET DU LOGICIEL

Cet interlocuteur aura principalement les missions suivantes :

o Définition de la stratégie générale du système d'information et du budget informatique.

o Conduite du changement.

o Suivi de la qualité des prestations sur la base des indicateurs définis dans le Plan Qualité de Service.

o Participation aux Comités de Pilotage.

LE PRESTATAIRE désignera un interlocuteur (dénommé ci-après le « Directeur de Projet du PRESTATAIRE ») qui aura principalement les missions suivantes :

o Responsabilité de la fourniture des prestations dans le respect des engagements du présent contrat.

o Coordination de l'équipe opérationnelle du PRESTATAIRE.

o Production des documents de suivi de projet.

o Participation et animation des Comités de Pilotage.

o Recouvrement des créances.

En fonction de la taille du projet les Conditions Particulières peuvent prévoir que :

o Les rôles de Chef de projet CLIENT et de Product Owner pourront être assumés par la même personne,

o Les rôles de Directeur de Projet DU PRESTATAIRE et de Scrum Master pourront être assumés par la même personne.

7.2. Le Comité de Pilotage réunira à minima le Product Owner, le Scrum Master, le Chef de Projet

Client et le Directeur de Projet du PRESTATAIRE ainsi que tout intervenant jugé nécessaire, à l'initiative du CLIENT ou du PRESTATAIRE, et aura pour objet :

o D'assurer le suivi des prestations et du Plan Qualité de Service notamment via les indicateurs de qualité.

o D'assurer le traitement et le suivi des obstacles survenus et des plans d'actions proposés pour les résoudre.

o De contrôler l'exécution du budget arrêté.

o De faire une revue des factures impayées et d'examiner les éventuelles contestations formulées par le CLIENT en ce qui concerne la facturation.

o D'assurer la recherche de l'amélioration continue en prenant en compte les réunions de rétrospective menées à l'issue de chaque Sprint.

7.3. Le Comité de Pilotage se réunira selon la périodicité définie au Plan Qualité de Service. Des

réunions supplémentaires pourront être demandées par l'une ou l'autre des Parties en cas de besoin.

A l'issue de chacune des réunions, LE PRESTATAIRE rédigera, dans un délai d'une (1) semaine, un compte rendu dont le texte sera réputé approuvé par le CLIENT si aucune modification n'est demandée dans la semaine qui suit la réception.

8.1. LIVRAISON

LE PRESTATAIRE s'engage à livrer à la fin de chaque Sprint et à la fin du projet :

o Le code des Développements, et à la fin du projet, du Logiciel à date.

o Les actifs des tests unitaires et fonctionnels à date.

o Les scripts de construction et de déploiement.

o Les Spécifications afférentes aux Développements, et à la fin du projet, du Logiciel.

o Le rapport d'exécution des tests unitaires.

o Le bon de livraison détaillant les Développements livrés.

8.2. RECETTE

8.2.1. Objet

Le CLIENT procèdera à la recette des Développements ou du Logiciel à compter de la livraison du code, des Spécifications afférentes et du rapport d'exécution des tests unitaires.

La procédure de recette a pour objectif de contrôler que les Développements ou le Logiciel sont conformes aux attentes spécifiées dans le Backlog de Sprint.

Le CLIENT s'engage, par conséquent, à mettre à disposition des personnels du PRESTATAIRE affectés à la réalisation des prestations, des personnels dûment assermentés et compétents.

8.2.2. Recettes incrémentales

Pour garantir le respect des fonctionnalités, le CLIENT devra opérer la recette du Développement issu d'un Sprint N au plus tard avant la fin du Sprint N+1. En l'absence d'acceptation expresse, de réserves ou de refus émis dans ce délai, le démarrage du Sprint N+2 vaudra recette tacite du Développement issu du Sprint N.

8.2.3. Recette définitive

Le Client devra opérer la recette définitive du Logiciel livré au plus tard trente (30) jours calendaires après la dernière livraison. En l'absence d'acceptation expresse, de réserves ou de refus émis dans ce délai, la mise en production du Logiciel vaudra recette tacite de celui-ci. En tout état de cause, la recette définitive du Logiciel sera réputée prononcée à l'expiration du délai de trente (30) jours calendaires à compter de la dernière livraison.

8.2.4. Procédure

La procédure de recette est définie en détail dans le POS.

Au terme de la procédure de recette définitive, le CLIENT émettra un procès-verbal de recette donnant lieu :

o soit à une acceptation sans réserve du Logiciel ;

o soit à une acceptation avec réserves du Logiciel ;

o soit à un refus.

Tout procès-verbal de recette sans réserve entraîne réception du Logiciel livré.

La durée maximale de la procédure de recette définitive du Logiciel est fixée à quatre (4) semaines calendaires.

8.2.5. Levée des réserves

En cas de procès-verbal de recette avec réserves d'un Développement issu d'un Sprint N, le Sprint N+1 ne sera pas remis en cause. Toutefois, LE PRESTATAIRE s'engage à lever les réserves avant la fin du Sprint N+1 pour soumettre la correction de ces réserves à la validation du CLIENT dans le cadre de la recette du Développement issu du Sprint N+1.

En cas de procès-verbal de refus, le CLIENT devra porter les Anomalies relevées à la connaissance du PRESTATAIRE en les documentant par écrit, c'est à dire en décrivant de manière précise l'environnement et les conditions de la survenance de chaque Anomalie afin de permettre au PRESTATAIRE de les reproduire et de les corriger en temps utile.

Suite à la notification de ces Anomalies, le Prestataire procèdera à la correction du Développement ou du Logiciel en cause et présentera, pour recette, les corrections effectuées dans un délai maximal de dix (10) jours ouvrés à compter de la réception du procès-verbal de refus, ou tout autre délai plus long convenu avec le CLIENT. LE PRESTATAIRE effectuera une seule re-livraison des corrections en vue de la recette du Développement ou du Logiciel en cause.

Pour permettre de tracer les Anomalies et d'en faire un suivi efficace, toute Anomalie constatée par le CLIENT devra être notifiée par écrit au PRESTATAIRE sur une fiche d'Anomalie comportant la date et le contexte de sa survenance. Le CLIENT retracera l'ensemble des événements concernant chaque fiche d'Anomalie sur un livre de bord, et notamment la date de prise en compte de l'Anomalie et de sa correction par LE PRESTATAIRE.

La levée des réserves résultant d'un procès-verbal de recette avec réserves ou d'un procès-verbal de refus sera formalisée par l'établissement d'un nouveau procès-verbal de recette.

9. GARANTIES

9.1. Au titre des garanties légales de délivrance conforme et contre les vices cachés, LE

PRESTATAIRE garantit le CLIENT, pendant une période de six (6) mois à compter de la livraison du Logiciel, contre toute Anomalie de celui-ci. En cas de manquement du Client à son obligation de recette incrémentale comme indiqué ci-avant, la période de garantie sera réduite à trois (3) mois.

9.2. En cas de mise en oeuvre de ces garanties, LE PRESTATAIRE aura pour seule obligation de

corriger l'Anomalie.

9.3. LE PRESTATAIRE sera libérée de toute obligation au titre de ces garanties en cas d'anomalie de

fonctionnement du Logiciel causé par :

o une erreur de manipulation du CLIENT ;

o le non respect des dispositions du Contrat ou de la documentation du Logiciel ;

o un fait non inhérent au Logiciel, notamment une anomalie ou une interruption de fonctionnement des équipements informatiques du CLIENT sur lesquels le Logiciel est installé ou

o l'utilisation de matériels ou de logiciels non compatibles avec le Logiciel.

Toute intervention du PRESTATAIRE au titre d'anomalies de fonctionnement exclues de la garantie, sera facturée au tarif en vigueur.

9.4. LE PRESTATAIRE exclut toute autre garantie afférente au Logiciel résultant de la loi ou de la

jurisprudence.

Le CLIENT reconnait que les performances du Logiciel dépendent de son aptitude à l'utiliser correctement. A ce titre, LE PRESTATAIRE ne garantit pas que le Logiciel satisfera à tous les besoins du CLIENT, notamment de performance ou de rentabilité, ni que son fonctionnement sera continu et sans erreur eu égard a son haut degré technologique et a la diversité des composantes logicielles et matérielles des systèmes informatiques sur lesquels il est susceptibles d'être utilisé.

9.5. Le CLIENT est informé que les Développements et le Logiciel sont susceptibles d'intégrer des

modules ou des bibliothèques dites « libres » ou « open source » dont les licences peuvent contenir des exclusions pures et simples de toutes garanties.

Dans ce cas, le CLIENT accepte que LE PRESTATAIRE ne puisse lui conférer plus de garantie qu'elle n'en tient elle-même des licences de ces modules ou bibliothèques. LE PRESTATAIRE exclut par conséquent toute garantie relative aux modules ou bibliothèques dites « libres » ou « open source » dont les licences contiendraient une exclusion de garantie.

Le CLIENT pourra prendre connaissance de l'étendue des garanties associées aux modules ou bibliothèques dites « libres » ou « open source » en se reportant aux licences de celles-ci que LE PRESTATAIRE joindra systématiquement au code, lorsque ces licences l'imposent, lors de la livraison des Développements ou du Logiciel concernés.

10. OBLIGATIONS DES PARTIES

10.1. OBLIGATIONS DU PRESTATAIRE

10.1.1. Obligations générales

LE PRESTATAIRE s'engage à réaliser ses prestations dans le respect des règles de l'art afférentes aux Méthodes Agiles présentées en Annexe 1 et dans le respect des lois et règlementations en vigueur applicables à son activité.

Par ailleurs, LE PRESTATAIRE est soumis à une obligation de conseil et de mise en garde dans le cadre de l'exécution du Contrat pour autant que les informations fournies par le CLIENT permettent au PRESTATAIRE d'exercer cette obligation. Le périmètre de cette obligation est en outre fonction des prestations commandées par le CLIENT.

10.1.2. Constitution et maintien d'une équipe projet

LE PRESTATAIRE s'engage à constituer et maintenir une équipe constituée de personnels qualifiés et compétents eu égard aux prestations souhaitées par le CLIENT. Conformément aux Méthodes Agiles, LE PRESTATAIRE s'engage à constituer une équipe de taille réduite, dépourvue de hiérarchie.

LE PRESTATAIRE s'engage à maintenir tout au long du projet à la disposition des personnels du CLIENT affectés à la réalisation des prestations, les informations suivantes :

10.1.3. Obligations essentielles résultant de la Méthodologie AGILE

LE PRESTATAIRE s'engage à livrer le Logiciel dans les délais convenus avec le CLIENT.

LE PRESTATAIRE s'engage également à ne pas dépasser le prix convenu avec le CLIENT pour la réalisation du Logiciel tel que fixé à la date de signature du Contrat ou révisé ultérieurement comme indiqué à l'article 11.1.

LE PRESTATAIRE s'engage à livrer un logiciel conforme à la Vision et au Product Backlog. Toutefois, les Méthodes Agiles impliquent que le périmètre des prestations soit modulable, particulièrement en vue d'assurer le respect du prix et des délais. A ce titre, la Vision et le Product Backlog pourront être amendés d'un commun accord des Parties, en cours d'exécution du Contrat, dans le cadre de changements de périmètre à la hausse ou à la baisse, dans les cas suivants :

o Le CLIENT souhaite modifier les spécifications de certaines fonctions consignées dans la Vision ou y ajouter des fonctionnalités (modification de l'Annexe 2) mais ces modifications n'ont pas d'impact sur l'estimation de charges, structure et délais faite initialement (aucune modification de l'Annexe 3).

o Le CLIENT souhaite modifier les spécifications de certaines fonctions consignées dans la Vision ou y ajouter des fonctionnalités (modification de l'Annexe 2) mais ces modifications augmentent les estimations initialement faites (modification de l'Annexe 3).

o Le CLIENT souhaite modifier les spécifications de certaines fonctions consignées dans la Vision ou y ajouter des fonctionnalités (modification de l'Annexe 2), ces modifications augmentent les estimations initialement faites mais le CLIENT choisit le mécanisme de Trade in/Trade out (aucune modification de l'Annexe 3).

Ce mécanisme permet au CLIENT, d'un commun accord avec LE PRESTATAIRE, de supprimer certaines fonctionnalités qu'il juge moins importantes pour y substituer les modifications qu'il souhaite apporter à d'autres fonctions ou les nouvelles fonctionnalités voulues afin de garder le prix inchangé. L'équilibre est mesuré en termes de Story Points.

o Le CLIENT exerce, en cours de projet, son droit de résiliation anticipée comme indiqué à l'article 17.2 et revoit donc à la baisse les spécifications consignées dans la Vision (modification de l'Annexe 2 et de l'Annexe 3).

Dans les cas de modification susvisés de l'Annexe 2 ou l'Annexe 3, les Parties régulariseront d'un commun accord un avenant au Contrat.

10.1.4. Respect de la qualité de Service

LE PRESTATAIRE s'engage à réaliser les prestations dans le respect des Niveaux de Service définis dans le Plan Qualité de Service (Annexe 4). Ces Niveaux de Service sont mesurés grâce à des indicateurs et peuvent donner lieu à l'application de pénalités comme indiqué à l'article 6 lorsque la non atteinte du Niveau de Service est exclusivement imputable à un manquement du PRESTATAIRE à ses obligations contractuelles.

10.1.5. Transparence

D Burndown Chart. D Tableau des tâches

D Liste des obstacles rencontrés.
D Rapports d'outils de tests

D Indicateurs de qualité.

10.2. OBLIGATIONS DU CLIENT

10.2.1. Collaboration

Le succès d'un projet informatique ne dépend pas seulement de la qualité des prestations, mais aussi de facteurs échappant au contrôle de tout prestataire et qui sont du ressort du client, telles que les structures de l'entreprise, les méthodes de travail et la qualification et l'implication du personnel affecté au projet.

La réalisation de prestations informatiques selon les Méthodes Agiles repose sur l'intervention de personnels du client qualifiés et compétents et sur une collaboration et réactivité sans faille de ces personnels avec ceux du prestataire du fait du processus itératif et incrémental de développement.

A ce titre, le CLIENT collaborera en permanence et étroitement avec LE PRESTATAIRE à l'exécution des prestations du Contrat. Le CLIENT affectera à la réalisation des prestations tous personnels, mettra à la disposition du PRESTATAIRE tous moyens et informations et prendra toutes mesures nécessaires à la bonne exécution des prestations et, plus généralement, du Contrat.

Par ailleurs, le CLIENT fera son affaire d'adapter son organisation et ses méthodes de travail aux principes et processus des Méthodes Agiles et des fonctionnalités offertes par le Logiciel.

Dans l'hypothèse où le CLIENT ne disposerait pas en interne des personnels ayant l'expertise nécessaire et en nombre suffisant pour lui permettre d'assumer ses obligations, notamment de collaboration, au titre du Contrat, il devra recourir aux services d'un ou plusieurs prestataires externes appropriés.

10.2.2. Personnels

En outre, le CLIENT s'engage à constituer et maintenir une équipe composée de personnels qualifiés et compétents eu égard aux prestations commandées par ses soins. Le CLIENT prendra toutes mesures utiles pour assurer la disponibilité de son équipe mais également des futurs utilisateurs concernés par le Logiciel et de tout autre personnel qui s'avèrerait nécessaire à la bonne exécution des prestations.

Le CLIENT garantit au PRESTATAIRE la disponibilité du Chef de projet CLIENT, du Product Owner et de représentants des futurs utilisateurs sur toute la durée du projet. Le CLIENT garantit également au PRESTATAIRE que le Chef de projet CLIENT et le Product Owner ont une vision du projet convergente avec leur direction ainsi que le mandat des futurs utilisateurs et le pouvoir de décision suffisant pour prendre des décisions en toute autonomie et engager le CLIENT. De façon générale, le CLIENT confèrera aux choix et décisions prises par ses représentants dans le cadre du projet, l'autorité nécessaire à la mise en oeuvre, en tant que de besoin.

10.2.3. Maîtrise d'ouvrage et maîtrise d'oeuvre du CLIENT

10.2.6. Sécurité

Au titre de sa maîtrise d'ouvrage, le CLIENT s'engage notamment à :

o Apporter toutes les informations utiles au PRESTATAIRE en temps utile.

o Faciliter les interventions du PRESTATAIRE.

o Procéder à la recette des Développements et du Logiciel.

o Participer au Comité de Pilotage de manière proactive et constructive.

o Participer de la même manière à toutes les réunions impliquées par la mise en oeuvre des Méthodes Agiles, en particulier les Sprint Plannings, ainsi qu'à toutes autres réunions requises par LE PRESTATAIRE.

Dans le cas où le CLIENT entendrait faire intervenir des tiers dans un projet global dont les prestations du Contrat ne constitueraient qu'une partie, le CLIENT assumera l'entière

responsabilité de la coordination des divers intervenants en tant que maître d'oeuvre.

10.2.4. Moyens

Le CLIENT s'engage à mettre à la disposition du PRESTATAIRE tous moyens nécessaires à l'exécution des prestations, notamment ceux qui seront précisés dans le Plan Qualité de Service, auxquels pourront s'ajouter d'autres moyens que LE PRESTATAIRE jugerait nécessaires à la bonne exécution des prestations.

Le CLIENT assurera également au PRESTATAIRE :

o Les accès aux machines, infrastructures, réseaux, systèmes d'exploitation et logiciels nécessaires à la réalisation des prestations à la date indiquée par LE PRESTATAIRE à qui le CLIENT garantit le bon fonctionnement de ces éléments.

o La disponibilité des personnels compétents sur les environnements, plateformes, logiciels, progiciels et outils avec lesquels le Logiciel devra interagir et cela, suivant un planning décidé entre les Parties en début de Sprint.

Tout manquement à cette obligation donnera lieu à un amendement des engagements du PRESTATAIRE et du Contrat.

Le CLIENT aura la charge de tous les coûts de locaux, d'énergie, de réseaux, d'infrastructure et de tous autres éléments qui ne sont pas expressément à la charge du PRESTATAIRE aux termes du Contrat.

10.2.5. Traitement des demandes

Une équipe de développement selon la Méthodologie Agile est une équipe hyper productive. Afin de ne pas ralentir le rythme de l'équipe du PRESTATAIRE, le CLIENT garantit qu'il traitera toutes les demandes de suppression d'obstacles qui lui seront soumises par le Scrum Master

du PRESTATAIRE dans un délai de

<délai de traitement obstacles en jours calendaires>

calendaires et cela quelque soit la nature de cet obstacle.

Plus généralement, le CLIENT s'engage à traiter toute demande du PRESTATAIRE dans le délai indiqué par celle-ci eu égard au degré d'urgence de sa demande et, en tout état de cause, dans un dans un délai de <délai de traitement obstacles en jours calendaires> calendaires.

11.1.2. Néanmoins, ce prix pourra être modifié par LE PRESTATAIRE ou par le CLIENT, d'un commun accord des Parties, dans les cas suivants :

Le CLIENT prendra toutes les précautions nécessaires pour éviter les pertes, destructions, altérations ou erreurs dans ses données, fichiers et ses programmes.

Le CLIENT fera en sorte de se prémunir, par tous les moyens à sa convenance et notamment par des sauvegardes régulières, contre tous risques de pertes, de destructions ou d'altérations de ses données, fichiers et programmes.

Par ailleurs, le CLIENT s'engage à communiquer au PRESTATAIRE les mesures de sécurité requises pour les traitements de ses données et fichiers par les Développements ou le Logiciel et pour assurer le fonctionnement des Développements ou du Logiciel dans son environnement informatique.

Le CLIENT informera LE PRESTATAIRE dans le cas où il lui transmettrait des données personnelles aux fins de traitement par les Développements ou le Logiciel dans le cadre du Contrat et lui indiquera les obligations, notamment de sécurisation, qu'elle devra observer au nom et pour le compte du CLIENT eu égard à la loi du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés.

10.2.7. Paiement du prix

Le CLIENT s'engage à effectuer le paiement du prix dû au titre des prestations effectuées par LE PRESTATAIRE dans les délais indiqués à l'article 11.

10.3. OBLIGATIONS DES PARTIES

Les Méthodes Agiles prônent la collaboration plutôt que la négociation contractuelle.

Tous les projets informatiques sont susceptibles de connaître des difficultés non identifiées lors de la conclusion du contrat. Chacune des Parties s'engage à la plus totale transparence vis-à-vis de l'autre Partie en ce qui concerne les difficultés qu'elle pourrait rencontrer, qu'elles soient techniques, financières, humaines, organisationnelles ou logistiques.

Partant, chaque Partie s'engage à informer l'autre Partie de toute difficulté qu'elle rencontrerait, et qui serait de nature à perturber la bonne exécution des prestations, dans le plus bref délai à compter de la connaissance de cette difficulté.

Dans un tel cas, les Parties rechercheront en toute bonne foi une solution pour surmonter cette difficulté en respectant l'équilibre du Contrat ou pour partager les risques afférents équitablement.

11. CONDITIONS FINANCIÈRES

11.1. PRIX

11.1.1. Le prix des prestations eu égard au périmètre résultant de la Vision est défini dans l'estimation de charges, structure et délais jointe en Annexe 3.

o À la baisse si :

? Le CLIENT souhaite exercer son droit de sortie anticipée prévu par l'article 17.2.

? LE PRESTATAIRE, à l'issue du Sprint 0, revoit à la baisse le prix comme indiqué dans les Conditions Particulières.

o À la hausse si :

? Le CLIENT souhaite intégrer des fonctionnalités supplémentaires non prévues dans le Cahier des Charges, non estimées initialement en Annexe 3 et n'exerce pas son droit de Trade in / Trade out.

? LE PRESTATAIRE, à l'issue du Sprint 0, revoit à la hausse le prix comme indiqué dans les Conditions Particulières.

11.1.3. Les prestations qui n'entreraient pas dans le périmètre du Contrat seront facturées, soit sur la base d'un devis établi par LE PRESTATAIRE, soit en fonction des tarifs en vigueur au moment de la réalisation. A titre indicatif, les tarifs du PRESTATAIRE en vigueur à la date de conclusion du Contrat sont joints en Annexe 6.

11.1.4. Le CLIENT pourra prendre la décision d'arrêter le projet s'il estime que celui-ci a atteint un stade de réalisation correspondant à ses objectifs dans les conditions fixées au 17.2 ci-après.

11.2. MODALITÉS DE FACTURATION

LE PRESTATAIRE facturera ses prestations de la manière suivante :

o Facturation au réel en euros HT à l'issue du Sprint 0

o Facturation forfaitaire (montant forfaitaire défini dans l'Annexe financière) en euros HT à l'issue de chaque Sprint

o Ajustement au réel tous les <Nombre de sprints entre deux régularisations>

11.3. MODALITÉS ET DÉLAIS DE PAIEMENT

11.3.1. Le paiement des factures du PRESTATAIRE est dû à <délai de paiement en lettres> (<délai de paiement en chiffres>) jours date de facture et par <modalité de paiement>.

11.3.2. Le CLIENT s'engage à régler les factures du PRESTATAIRE dans leur intégralité. Le paiement d'une facture ne pourra être différé que si elle fait l'objet d'une contestation dûment motivée par le CLIENT et communiquée au Comité de Pilotage. Le non-paiement ne peut valoir que pour la partie dûment contestée.

11.3.3. De convention expresse et sauf report sollicité dans les cinq (5) jours suivant la date de réception de facture pour un motif tenant à un manquement du PRESTATAIRE à ses obligations au titre du Contrat et accordé par LE PRESTATAIRE, le défaut de paiement à l'échéance entraînera de plein droit et sans mise en demeure :

o L'exigibilité immédiate de toutes les sommes restant dues à l'échéance.

o Des intérêts de retard mensuels sur les sommes restant dues, jusqu'à complet paiement,

12.1.2. Le CLIENT garantit être titulaire de tous les droits de propriété intellectuelle nécessaires pour lui permettre de transmettre ces données, fichiers et documents au PRESTATAIRE en vue de

au plus élevé des deux taux suivants : 3 fois le taux d'intérêt légal ou le taux légal en vigueur à la date de facture plus 3 points.

Dans un tel cas, LE PRESTATAIRE pourra en outre suspendre toutes les prestations en cours, quels que soient leur nature et leur niveau d'avancement jusqu'à complet paiement des sommes dues et des intérêts.

11.3.4. Les prestations complémentaires éventuellement demandées par le CLIENT seront facturées à l'issue du mois au cours duquel elles auront été exécutées.

11.4. CLAUSE DE REAJUSTEMENT

Si par suite de circonstance d'ordre économique, technique ou commercial survenant après la signature du Contrat, l'économie de celui-ci et plus généralement l'équilibre qu'il instaure entre les Parties se trouvait modifié au point de rendre son exécution préjudiciable pour l'une ou l'autre des Parties, la Partie subissant ce préjudice aurait la faculté de solliciter l'autre Partie pour que soit déterminée, d'un commun accord, dans un esprit de mutuelle compréhension et d'équité, la solution la plus adaptée pour faire disparaître le déséquilibre constaté, en procédant, si nécessaire, à un amendement de certaines dispositions contractuelles en jouant sur le périmètre des prestations ou sur le prix.

Si les Parties ne parvenaient pas à trouver cette solution dans un délai de deux (2) mois à compter de la sollicitation, elles auraient alors la possibilité, sur l'initiative de la Partie la plus diligente, de faire appel aux bons offices d'un médiateur choisi d'un commun accord. Ce médiateur aurait pour mission de rapprocher les Parties et, d'une manière générale, de présenter toutes les recommandations qui lui paraîtraient utiles.

En tout état de cause, ces recommandations auraient un caractère confidentiel et ne pourraient pas être exploitées dans le cadre d'une procédure judiciaire.

Les Parties acceptent irrévocablement de supporter par moitié les frais et honoraires exposés dans le cadre de cette mission de conciliation, à l'exception des frais et honoraires des propres conseils.

12. PROPRIETE INTELLECTUELLE

12.1. DROITS DE PROPRIÉTÉ INTELLECTUELLE DU CLIENT

12.1.1. Le CLIENT est et demeure propriétaire de tous droits de propriété intellectuelle sur les données, fichiers et documents couverts par de tels droits transmis ou mis à la disposition du PRESTATAIRE dans le cadre de l'exécution du Contrat.

Le Contrat n'emporte aucun transfert de droits de propriété intellectuelle au profit du PRESTATAIRE sur ces données, fichiers et documents autres que les droits nécessaires à l'exécution par LE PRESTATAIRE de ses obligations au titre du Contrat. En conséquence, LE PRESTATAIRE s'interdit d'utiliser ces données, fichiers et documents à d'autres fins que l'exécution de ses obligations au titre du Contrat.

l'exécution de ses obligations au titre du Contrat, et garantit LE PRESTATAIRE contre toute revendication ou réclamation d'un tiers à ce sujet.

12.1.3. A la cessation du Contrat pour quelle que cause que ce soit, LE PRESTATAIRE remettra au CLIENT l'ensemble des données, fichiers et documents du CLIENT qui lui auront été ainsi confiés pour les besoins de l'exécution de ses obligations au titre du Contrat.

12.2. DROITS DE PROPRIÉTÉ INTELLECTUELLE DU PRESTATAIRE

LE PRESTATAIRE est et demeure propriétaire de tous droits de propriété intellectuelle sur les outils, méthodes et savoir-faire qu'elle sera amenée à réaliser ou à utiliser dans le cadre du Contrat.

Le Contrat n'emporte aucun transfert de droits de propriété intellectuelle au profit du CLIENT sur ces outils, méthodes et savoir-faire.

12.3. RESPECT DES DROITS DE PROPRIÉTÉ INTELLECTUELLE

Chaque Partie s'engage à ne à ne rien faire et à ne rien laisser faire qui puisse mettre en péril les droits de propriété intellectuelle de l'autre Partie. Chaque Partie s'interdit notamment de conférer quel que droit et de constituer quelle que garantie, sûreté ou privilège que ce soit sur les éléments couverts par les droits de propriété intellectuelle de l'autre Partie.

Chaque Partie s'engage à faire prendre aux détenteurs de ses parts sociales, ses mandataires sociaux et ses employés qui auraient accès à ces éléments pour les besoins de l'exécution du Contrat, un engagement de ne pas porter atteinte aux droits de propriété intellectuelle susvisés de l'autre Partie de même portée que le présent engagement.

12.4. CESSION DE DROITS D'AUTEUR SUR LE LOGICIEL AU CLIENT

12.4.1. LE PRESTATAIRE cède au CLIENT l'intégralité de ses droits d'auteur sur les Développements et le Logiciel pour la durée légale de protection de ceux-ci et pour le monde entier.

La présente cession comprend notamment le droit de reproduction, le droit de communication au public, le droit de modification, le droit d'adaptation, le droit de traduction, le droit de localisation, le droit de distribution, de vente, de location, et plus généralement, le droit d'exploitation par tous moyens, tous procédés, sur tous supports, par tous media et réseaux de communication, connus ou inconnus à ce jour, à titre gratuit ou onéreux, et pour toutes finalités. La rémunération de la présente cession est comprise dans le prix payé au PRESTATAIRE aux termes de l'article 11.

12.4.2. La présente cession interviendra après prononcé de la recette définitive et sous réserve du complet paiement du prix du Logiciel. Toutefois, en cas de cessation anticipée du Contrat, quelle qu'en soit la cause et sauf en cas de résiliation pour faute du CLIENT, la cession se produira à la date de la cessation sur les Développements ou le Logiciel réalisés à cette date.

12.4.3. En cas de Développements standards et réutilisables, les Parties pourront convenir que LE PRESTATAIRE conservera les droits d'auteur sur ceux-ci, à charge de concéder au CLIENT une licence d'exploitation sur ceux-ci.

12.5. GARANTIE DE JOUISSANCE PAISIBLE

12.5.1. Au titre de la garantie légale de jouissance paisible, LE PRESTATAIRE s'engage à n'introduire dans les Développements ou le Logiciel aucun élément sur lequel un préposé ou un tiers disposerait de droits d'auteur sans autorisation de ce préposé ou tiers.

12.5.2. Partant, en cas de demande ou d'action en revendication ou en contrefaçon d'un préposé ou d'un tiers dirigée contre le CLIENT au motif qu'un Développement ou le Logiciel porteraient atteinte à ses droits d'auteur, LE PRESTATAIRE supportera tous frais et dommages-intérêts mis à sa charge en vertu d'une décision de justice passée en force de chose jugée ou d'une transaction, dans les conditions suivantes :

o le CLIENT informera LE PRESTATAIRE par écrit, dans le plus bref délai, de l'existence d'une telle demande ou action et communiquera au PRESTATAIRE toutes informations relatives à cette demande ou action ;

o LE PRESTATAIRE assurera seule la direction de la défense du CLIENT et de toute négociation pour le compte du CLIENT en vue d'une transaction ;

o le CLIENT coopèrera activement avec LE PRESTATAIRE en tout ce qui concerne le règlement de la demande ou de l'action.

12.5.3. Dans le cas où une telle action serait reconnue fondée par une décision de justice passée en force de chose jugée ou par une transaction ou dans le cas où LE PRESTATAIRE estimerait qu'elle serait susceptible de l'être, le CLIENT acceptera que LE PRESTATAIRE, au choix de cette dernière :

o obtienne le droit pour le CLIENT de continuer à utiliser le Développement ou le Logiciel ou en cause ;

o ou modifie le Développement ou le Logiciel de façon à ce qu'il cesse d'être contrefaisant ;

o procure au CLIENT un développement ou un logiciel ayant les mêmes fonctions, dans des délais compatibles avec l'activité du CLIENT ;

o rembourse au CLIENT le prix effectivement payé par celui-ci pour le Développement incriminé ou le Logiciel selon le cas.

12.5.4. Le présent article constitue le seul et unique recours du CLIENT à l'encontre du PRESTATAIRE au titre de la garantie de jouissance paisible des Développements et du Logiciel et sous réserve que le Développement ou le Logiciel en cause n'ait pas été modifié par le CLIENT ou un tiers et que la demande ou l'action du préposé ou du tiers soit exclusivement fondée sur le Développement ou le Logiciel.

12.6. MODULES ET BIBLIOTHÈQUES LIBRES

Le CLIENT est informé que LE PRESTATAIRE est susceptible d'intégrer des modules ou bibliothèques dites « libres » ou « open source » dans les Développements ou le Logiciel. LE PRESTATAIRE s'engage à n'intégrer de tels éléments dans les Développements ou le Logiciel que lorsque leur licence le permet.

Dans un tel cas, les droits d'auteur sur ces modules ou bibliothèques ne seront pas cédés au CLIENT en vertu de l'article 12.4. Le CLIENT tiendra ses droits d'utilisation de ces modules ou bibliothèques de la licence respective dite « libre » qui sera systématiquement jointe au code de

ceux-ci par LE PRESTATAIRE, lorsque la licence l'impose, lors de la livraison des Développements ou du Logiciel concernés.

Par ailleurs, certaines licences dites « libres », dont l'exemple le plus courant est la GPL, mettent des obligations à la charge de l'utilisateur des modules ou bibliothèques qu'elles couvrent. L'utilisateur peut ainsi être obligé de mettre le code source des modules ou bibliothèques qu'il utilise, qu'ils soient modifiés ou non, à la disposition de la communauté des développeurs du monde dit « libre ». Cette obligation de mise à disposition peut parfois s'étendre au code source des logiciels qui interagissent avec ces modules ou bibliothèques.

Dans un tel, cas LE PRESTATAIRE ne peut en aucun cas s'engager sur la confidentialité du code source des Développements ou du Logiciel qui contiendrait de tels modules ou bibliothèques. En outre, le CLIENT prendra connaissance des termes des licences des modules ou bibliothèques dits « libres » qui seraient livrés avec les Développements ou le Logiciel afin de s'assurer de l'absence de risque tenant à une obligation de mettre le code source de ses logiciels fonctionnant avec ces modules ou bibliothèques à la disposition de la communauté des développeurs du monde dit « libre ».

Pour des raisons de sécurité et de confidentialité, il est plus prudent pour le client de ne pas conclure une telle clause. Il faudrait au contraire que le prestataire garantisse qu'il s'abstiendra d'utiliser des modules ou des bibliothèques, statiques ou dynamiques, distribués sous licence libre contaminante.

Cet article (12.6., §3 et §4), combiné à l'article 13.3 « La présente obligation de confidentialité ne concerne pas les informations [...] qui étaient tombées ou tomberaient dans le domaine public de façon non fautive et licite », pourrait avoir pour effet de faire perdre au code source du logiciel son caractère confidentiel en cas d'utilisation de modules ou bibliothèques distribués sous licence contaminante.

13. CONFIDENTIALITE

13.1. PÉRIMÈTRE DE LA CONFIDENTIALITÉ

Chaque Partie gardera strictement confidentielles toutes données et informations de quelque nature que ce soit appartenant à ou détenues par l'autre Partie, que celle-ci aurait expressément identifiées comme confidentielles ou qui seraient manifestement non publiques, mises à disposition de la Partie réceptrice par la Partie émettrice ou dont la Partie réceptrice aurait pu avoir connaissance dans le cadre de l'exécution du Contrat (ci-après désignées par « Informations Confidentielles »). En cas de doute de la Partie réceptrice sur le caractère confidentiel ou public d'une information appartenant à ou détenue par la Partie émettrice, la Partie réceptrice devra interroger la Partie émettrice à ce sujet.

Les Parties conviennent que le contenu du Contrat, tous documents émis en exécution du Contrat, les outils, méthodes et savoir-faire du PRESTATAIRE ainsi que les fichiers et données du CLIENT sont des Informations Confidentielles.

13.2. OBLIGATION DE CONFIDENTIALITÉ

Chaque Partie s'interdit d'utiliser les Informations Confidentielles de l'autre Partie pour toute autre fin que l'exécution de ses obligations au titre du Contrat et s'interdit de divulguer ces Informations Confidentielles à toute personne autre que celles qui ont besoin d'en avoir connaissance aux fins d'exécution du Contrat.

Chaque Partie s'assurera que les détenteurs de parts de son capital social, ses mandataires sociaux, ses employés et ses cocontractants qui ont besoin d'avoir connaissance d'Informations Confidentielles aux fins d'exécution du Contrat soient liés par une obligation de confidentialité de même portée que la présente obligation avant toute divulgation d'Informations Confidentielles à ceux-ci. Chaque Partie se porte fort du respect par les détenteurs de parts de son capital social, ses mandataires sociaux, ses employés et ses cocontractants de la présente obligation de confidentialité.

Chaque Partie pourra communiquer, sous obligation de confidentialité, le Contrat et les documents afférents à son assureur, à ses partenaires financiers ou bancaires et à ses commissaires aux comptes.

13.3. EXCEPTIONS À L'OBLIGATION DE CONFIDENTIALITÉ

La présente obligation de confidentialité ne concerne pas les informations :

o qui étaient déjà licitement en la possession de la Partie réceptrice avant leur divulgation par la Partie émettrice ;

o qui auraient été fournies à la Partie réceptrice de façon non fautive et licite par un tiers ;

o qui étaient tombées ou tomberaient dans le domaine public de façon non fautive et licite ;

o que la Partie réceptrice serait obligée de divulguer par une obligation légale ou une décision de justice exécutoire mais seulement dans la limite de ce qui est nécessaire au respect de cette obligation légale ou décision de justice et sous réserve d'avoir informé la Partie émettrice par écrit dans le plus bref délai à compter de la connaissance de cette obligation de divulgation.

En cas de perte de tout support contenant une Information Confidentielle, la Partie réceptrice en informera la Partie émettrice par écrit dans le plus bref délai.

La présente obligation de confidentialité s'appliquera pendant toute la durée du Contrat et se poursuivra au-delà aussi longtemps que les Informations Confidentielles ne seront pas dans le domaine public et, en tout état de cause, pour une durée minimale de cinq (5) ans à compter de la cessation du Contrat pour quelle que cause que ce soit.

Chaque Partie s'engage à restituer à l'autre Partie tout support en sa possession contenant des Informations Confidentielles de l'autre Partie dans un délai de quinze (15) jours calendaires à compter de la cessation du Contrat pour quelle que cause que ce soit.

14. PORTABILITÉ

14.1. LE PRESTATAIRE s'engage, à la demande du CLIENT, à effectuer les opérations de nature à

permettre à celui-ci de prendre ou de confier à un tiers la suite de la réalisation des prestations du PRESTATAIRE en cas de sortie anticipée ou de résiliation du Contrat à l'initiative du CLIENT.

La demande de portabilité sera signifiée par le CLIENT au PRESTATAIRE par lettre recommandée avec accusé de réception trois (3) mois avant la cessation du Contrat.

14.2. Au titre des opérations de portabilité, LE PRESTATAIRE s'engage à livrer au CLIENT les

Développements non encore livrés, contre paiement du prix si ceux-ci n'ont pas encore été payés, et à lui restituer tout ce qui doit l'être en vertu du Contrat en cas de cessation de celui-ci.

LE PRESTATAIRE s'engage en outre à fournir au CLIENT une assistance technique et une formation en vue d'assurer le transfert des compétences nécessaires à la portabilité, dans la limite de <à compléter> jours/homme par mois pendant les trois (3) mois de la période de portabilité.

LE PRESTATAIRE s'engage également à assurer un soutien pendant une durée de un (1) mois à compter de la date de fin de la portabilité sur les différentes questions posées par le CLIENT. Ce soutien se fera par téléphone ou par l'envoi de document ou par déplacements éventuels.

14.3. Le montant de la portabilité fera l'objet d'un devis après réception par LE PRESTATAIRE de la

demande du CLIENT dans la mesure où la charge nécessaire pour assurer les opérations de portabilité dépendra du périmètre des Développements concernés par la portabilité. Le déclenchement des opérations de portabilité sera subordonné à l'acceptation de ce devis.

15. AUDIT

15.1. Le CLIENT, pourra faire procéder à ses frais, après en avoir avisé LE PRESTATAIRE par lettre

recommandée avec accusé de réception avec un préavis minimum d'un (1) mois, à un audit mené par un cabinet d'audit de réputation internationale ou nationale. Cette faculté pourra être mise en oeuvre par le CLIENT au maximum une fois par an.

Ce cabinet d'audit devra préalablement à toute opération d'audit être agréé par LE PRESTATAIRE qui ne pourra refuser cet agrément sans motif raisonnable. Le CLIENT devra en outre soumettre ce cabinet d'audit à une obligation de confidentialité concernant toutes les informations auquel il pourra avoir accès. Aucun document ou support d'information du PRESTATAIRE ne pourra sortir de ses locaux sans son accord.

L'audit ne pourra porter que sur les prestations relevant du Contrat.

15.2. Le CLIENT dispose d'un crédit annuel gratuit de deux (2) jours/homme de la part du

PRESTATAIRE pour le ou les audits qu'il diligenterait. Au-delà de ce crédit, le temps passé par le personnel du PRESTATAIRE pour les besoins de l'audit sera facturé sur la base de ses tarifs en vigueur.

Le rapport d'audit sera gratuitement adressé au PRESTATAIRE et fera l'objet d'un examen approfondi dans le cadre du Comité de Pilotage qui se prononcera sur l'existence d'un manquement ou non du PRESTATAIRE à ses obligations au titre du Contrat.

15.3. Au cas où un rapport d'audit ferait apparaître quelque manquement que ce soit du

PRESTATAIRE à ses obligations au titre du Contrat, cette dernière s'engage expressément à mettre en oeuvre, à ses frais, toute mesure corrective de nature à remédier à ce manquement dans un délai de trente (30) jours calendaires à compter de la réception de la demande du CLIENT à ce sujet.

16. RESPONSABILITE

Par ailleurs, si à un stade quelconque de la réalisation des prestations objet du Contrat, le CLIENT refuse de prendre en compte les recommandations, préconisations ou mises en garde du

16.1. RESPONSABILITÉ DU CLIENT

Le CLIENT est entièrement responsable de l'utilisation qu'il fera des Développements et du Logiciel dans la mesure où ceux-ci fonctionnent normalement ainsi que du traitement de ses données par ceux-ci. Le CLIENT est seul responsable de la précision, de l'exactitude et de la complétude des données qu'il fera traiter par les Développements et le Logiciel. Il appartiendra au CLIENT de vérifier que les résultats de ces traitements sont corrects.

Le CLIENT sera seul responsable de tous dommages qu'il se causerait ou causerait à un tiers à l'occasion de l'utilisation des Développements ou du Logiciel et du résultat du traitement de ses données par ceux-ci. Le CLIENT décharge LE PRESTATAIRE de toute responsabilité pour tous dommages que le CLIENT se causerait ou causerait à un tiers à cette occasion.

Le CLIENT garantit LE PRESTATAIRE contre toute action en responsabilité civile d'un tiers motivée par le fait qu'il aurait subi un dommage du fait de l'utilisation par le CLIENT des Développements ou du Logiciel ou du résultat du traitement des données du CLIENT par ceux-ci.

16.2. RESPONSABILITÉ DU PRESTATAIRE

LE PRESTATAIRE ne pourra être tenue pour responsable que du manquement à ses obligations telles que prévues au Contrat, à l'exclusion des dommages causés au CLIENT ou à un tiers par une anomalie de fonctionnement d'un Développement ou du Logiciel non due à un tel manquement du PRESTATAIRE. Compte tenu de la collaboration étroite des Parties pour l'exécution du Contrat, la responsabilité du PRESTATAIRE est subordonnée à la démonstration préalable par le CLIENT de la parfaite exécution de ses propres obligations.

Ces stipulations excluent la responsabilité du prestataire lorsque les dommages causés au client par des anomalies de fonctionnement ne résultent pas d'un manquement du prestataire à ses obligations.

La recette implique que les anomalies soient notifiées au prestataire (8.2.5). Ce dernier garantit le client « contre toute Anomalie » du logiciel (9.1). Cette garantie implique que le prestataire répare tout dommage résultant d'une anomalie ainsi que celle-ci.

Il aurait fallu préciser davantage la responsabilité du prestataire par rapport à la garantie et à la notification des anomalies, par exemple en se référant au moment où les anomalies interviendraient.

PRESTATAIRE, cette dernière sera dégagée de la responsabilité qui lui incombe à due proportion des conséquences résultant du défaut de prise en compte desdites recommandations, préconisations ou mises en garde.

LE PRESTATAIRE ne pourra être tenue pour responsable que des dommages directs subis par le CLIENT à l'exclusion des dommages ne présentant pas le caractère certain requis pour ouvrir droit à indemnisation tels que les pertes ou altérations de fichiers ou de données, les pertes de marchés, les pertes de clientèle, les pertes de chiffre d'affaires ou de bénéfices, les manques à gagner et les augmentations de coûts ou de dépenses.

LE PRESTATAIRE ne pourra pas être tenue pour responsable des dommages subis par le CLIENT à l'occasion de l'exécution du Contrat lorsque ces dommages auront été causés par la négligence, l'erreur ou la faute contractuelle ou délictuelle du CLIENT, par le fait d'un tiers, par une catastrophe naturelle, notamment un orage, un incendie, une inondation, ou par un cas de force majeure tel que défini ci-après ou tous événements hors du contrôle raisonnable du PRESTATAIRE.

En toutes hypothèses, à l'exception des dommages à l'intégrité physique des personnes, la responsabilité du PRESTATAIRE, y compris au titre d'une garantie relative aux Développements ou au Logiciel ou à des droits de propriété intellectuelle du PRESTATAIRE, ne pourra pas être engagée au delà de l'expiration d'un délai d'un (1) an à compter du fait générateur du dommage ou à compter de la cessation du Contrat pour quelle que cause que ce soit et sera limitée à < responsabilité dommage en % du prix payé > % du prix effectivement payé par le CLIENT au PRESTATAIRE en exécution du Contrat au titre de l'année civile de survenance du dommage.

16.3. FORCE MAJEURE

En cas de force majeure entraînant une impossibilité pour LE PRESTATAIRE d'exécuter ses obligations au titre du Contrat, LE PRESTATAIRE en informera le CLIENT dans le plus bref délai à compter de la survenance de cette impossibilité. Les obligations du PRESTATAIRE seront suspendues et sa responsabilité sera dégagée uniquement pour les obligations ou les prestations que le cas de force majeure rendra impossible à réaliser. Les Parties se concerteront pour convenir de bonne foi d'une solution de nature à permettre la poursuite du Contrat.

Sont réputés événements de force majeure aux termes du Contrat tous les événements imprévisibles, irrésistibles et extérieurs aux Parties conformément aux critères définis par la jurisprudence des juridictions françaises et aussi, de convention expresse entre les Parties, une explosion, un tremblement de terre, une grève ne concernant pas LE PRESTATAIRE, des émeutes, des troubles publics, une guerre, une défaillance des réseaux de communication, d'approvisionnement en énergie ou de transport, une défaillance des prestataires de livraison ou de transport ainsi que les faits de nature pénale commis par des tiers et plus particulièrement ceux résultants d'attaques pirates de tous types sur les systèmes d'information.

Les attaques pirates ne sont pas des événements imprévisibles ni irrésistibles, on pourrait argumenter que certaines attaques DOS émanant d'un nombre important de machines sont irrésistibles. Cette clause risque d'être interprétée comme limitant la responsabilité du prestataire quant à tout manquement à une de ses obligations essentielles (par exemple si sa prestation consiste à sécuriser le système d'information du client et/ou développer des modules ou logiciels de sécurité).

Dans la mesure où le cas de force majeure rendrait impossible la poursuite du Contrat pendant une durée supérieure à soixante (60) jours calendaires, celui-ci pourra être résilié de plein droit et sans formalité judiciaire par l'une ou l'autre des Parties par lettre recommandée avec accusé de réception adressée à l'autre Partie sans qu'il ne soit dû d'indemnités de part et d'autre.

16.4. ASSURANCES

LE PRESTATAIRE déclare être assurée pour sa responsabilité civile professionnelle auprès d'une compagnie notoirement solvable pour les dommages matériels et immatériels consécutifs à une faute dans l'exécution des prestations.

LE PRESTATAIRE s'engage à maintenir ces garanties pendant la durée du Contrat et à fournir sur demande expresse du CLIENT, une attestation avec le nom de la compagnie, le numéro de la police d'assurance et la nature et le montant des garanties.

Par ailleurs, le CLIENT reconnaît être le seul à même de prévoir et chiffrer le préjudice susceptible d'être subi par lui en cas de difficulté survenant dans l'exécution du Contrat dont les conditions et modalités (notamment les modalités financières) ont été arrêtés eu égard aux répartitions de responsabilité susvisées. En conséquence, le CLIENT fera son affaire de s'assurer contre tous les risques qui ne relèveraient pas de la responsabilité du PRESTATAIRE aux termes du Contrat.

17. DUREE ET CESSATION

17.1. DURÉE

Le Contrat prendra effet à compter de la date de signature par la seconde Partie pour la durée nécessaire à l'achèvement des prestations et à la réception du Logiciel et au plus tard le <date de

fin de contrat>.

17.2. ATTEINTE ANTICIPÉE DES OBJECTIFS DU CLIENT

Le CLIENT pourra décider à tout moment que le projet a atteint des objectifs suffisants pour correspondre à ses besoins. LE PRESTATAIRE accepte, sous les conditions prévues ci-après, que le CLIENT puisse bénéficier de cette possibilité sans devoir régler l'intégralité du prix initialement convenu dérogeant ainsi aux dispositions de l'article 1794 du Code Civil.

S'il souhaite clore le projet, le CLIENT devra notifier au PRESTATAIRE qu'il estime le projet réalisé de manière anticipée par lettre recommandée avec accusé de réception.

Cette notification vaudra procès-verbal de recette définitive sans réserves du projet et celui-ci sera considéré comme achevé libérant les Parties de leurs obligations sous réserve du 17.4 ci-après et du paiement de toutes les sommes encore dues au PRESTATAIRE par le CLIENT.

Dans cette notification le CLIENT devra indiquer :

o s'il entend bénéficier ou renoncer à la phase de finalisation prévue au 5.1.3.

o s'il entend bénéficier ou renoncer à la portabilité prévue à l'article 14.

Si le CLIENT souhaite que l'une ou l'autre des options soit mise en oeuvre, LE PRESTATAIRE émettra un devis de réalisation de prestation en régie sur la base du tarif annexé pour un montant minimal de 28 jours de prestation par option choisie pour l'équipe projet.

S'il renonce aux deux options ci-dessus, le CLIENT s'acquittera du solde des factures émises non encore réglées, de toute autre somme due au titre du Contrat.

{Le CLIENT s'acquittera également d'une indemnité de préavis égale à <indemnité en nbe de Sprint dû par un client en cas d'arrêt anticipé> fois le montant d'un Sprint calculé sur la base du prix payé depuis le début du projet divisé par le nombre de Sprint réalisés.}

Dans tous les autres cas, le CLIENT s'acquittera immédiatement du solde des factures émises non encore réglées et de toute autre somme due au titre du Contrat.

17.3. RÉSILIATION POUR FAUTE

En cas de manquement de l'une des Parties à une des obligations mises à sa charge par le Contrat, la Partie victime de ce manquement pourra résilier le Contrat, de plein droit et sans formalité judicaire, après avoir adressé à l'autre Partie, par lettre recommandée avec accusé de réception, une mise en demeure de faire cesser ledit manquement, restée infructueuse pendant trente (30) jours calendaires.

La résiliation interviendrait alors sur nouvelle lettre recommandée avec accusé réception et serait effective à réception de cette lettre ou à l'issue d'un délai de trois (3) mois à compter de la

réception de cette lettre en cas de demande de portabilité dans les cas visés à l'article 14.

17.4. MAINTIEN EN VIGUEUR

Nonobstant la cessation du Contrat pour quelle que cause que ce soit, les articles « Garanties », « Propriété intellectuelle », « Confidentialité », « Responsabilité», « Non débauchage », « Droit applicable et juridiction compétente » resteront en vigueur après la fin du Contrat.

18. DISPOSITIONS DIVERSES

En tout état de cause, LE PRESTATAIRE demeurera le seul interlocuteur du CLIENT et restera seule responsable de l'exécution de la totalité des prestations objet du Contrat.

18.1. INTEGRALITE DU CONTRAT

Le Contrat et ses annexes qui en font partie intégrante expriment l'intégralité des obligations des Parties l'une à l'égard de l'autre relativement à son objet et forment un ensemble indivisible et indissociable. Il annule et remplace tous engagements, offres ou propositions, oraux ou écrits, antérieurs et relatifs au même objet.

Le Contrat ne pourra être modifié que par un avenant signé par les Parties, à l'exception des cas de modification alternatifs expressément prévus au Contrat. Les avenants ultérieurs feront partie du Contrat et seront soumis à l'ensemble des dispositions qui le régissent.

18.2. NON RENONCIATION

Le fait pour l'une des Parties de ne pas se prévaloir ou de tarder à se prévaloir de l'application d'une disposition du Contrat ne saurait être interprété comme une renonciation à se prévaloir de cette disposition à l'avenir.

18.3. NON DÉBAUCHAGE

Le CLIENT s'engage à ne pas faire d'offres d'embauche, débaucher, embaucher ou associer, directement ou indirectement, tout détenteur de parts de son capital social, mandataire social ou membre du personnel du PRESTATAIRE ayant participé à la négociation ou à l'exécution du Contrat, pendant la durée du Contrat et un (1) après sa cessation pour quelle que cause que ce soit.

Le CLIENT informera LE PRESTATAIRE de toute sollicitation ou proposition de travail qu'il pourrait recevoir de tout détenteur de parts du capital social, mandataire social ou membre du personnel du PRESTATAIRE.

En cas de non-respect de cette obligation, le CLIENT versera au PRESTATAIRE, à première demande de celle-ci, une somme égale à douze (12) mois de la rémunération nette de chacun des personnels embauchés en contravention avec la présente clause.

18.4. CESSION

Le Contrat est conclu "intuitu personae". En conséquence, aucune Partie n'est autorisée à transférer à un tiers tout ou partie des droits et obligations qui en découlent pour elle, sans l'accord préalable écrit de l'autre Partie.

18.5. SOUS-TRAITANCE

LE PRESTATAIRE pourra sous-traiter l'exécution de certaines prestations objet du Contrat, sous réserve de l'acceptation expresse, préalable et écrite du CLIENT. La sous-traitance de l'ensemble des prestations n'est pas autorisée.

La sous-traitance autorisée de certaines obligations du PRESTATAIRE n'aura pas pour effet de créer quelque relation contractuelle que ce soit entre le CLIENT et le(s) sous-traitant(s).

Les délégations de paiement ne sont pas autorisées. L'ensemble des paiements liés à l'exécution du Contrat sera réglé au PRESTATAIRE, à charge pour elle de régler ses sous-traitants.

18.6. RÉFÉRENCES

Le CLIENT autorise d'ores et déjau PRESTATAIRE à faire publiquement état, à titre de référence commerciale d'une part, du nom du CLIENT et de son choix parmi les offres de services proposées par LE PRESTATAIRE et d'autre part, de la nature des prestations fournies par LE PRESTATAIRE.

De plus, après accord préalable et écrit du CLIENT, LE PRESTATAIRE pourra publiquement faire état des prestations fournies ou à fournir, décrire et publier la qualité de services des prestations fournies par LE PRESTATAIRE, les raisons qui ont motivé le CLIENT à choisir LE PRESTATAIRE ainsi que les bénéfices que le CLIENT a obtenus.

18.7. DOMICILE

Pour les besoins de l'exécution du Contrat, chacune des Parties fait élection de domicile à son adresse figurant en tête du Contrat ou à toute autre adresse qu'elle notifierait par écrit à l'autre Partie.

18.8. RÈGLEMENT AMIABLE

A l'exception des cas d'urgence justifiant le recours à une procédure judiciaire d'urgence, les Parties s'engagent, en cas de différend survenant entre elles relatif à la formation, la validité, l'interprétation, l'exécution ou la cessation du Contrat, préalablement à toute action judiciaire, à mettre en oeuvre une procédure destinée à faciliter un règlement amiable le plus rapidement possible.

A cet effet, dès qu'une Partie identifiera un tel différend avec l'autre Partie, il lui appartiendra de demander la convocation d'une première réunion ad hoc, réunissant des interlocuteurs des deux Parties de niveau Direction Générale, afin de discuter du règlement de la question objet du différend. Cette convocation sera effectuée par lettre recommandée avec accusé de réception. Cette première réunion se tiendra dans un délai maximal de dix (10) jours ouvrables courant à compter de la notification d'envoi à la Partie destinataire. Les Parties disposeront ensuite d'un délai de trente (30) jours pour fixer, à l'issue de chaque réunion, des réunions additionnelles. Si dans ce délai, aucune solution n'est trouvée, entérinée par un écrit signé des représentants des deux Parties, chaque Partie reprendra sa liberté d'action.

18.9. DROIT APPLICABLE ET JURIDICTION COMPETENTE

Le Contrat est soumis au droit français à l'exclusion de toute autre législation.

FAUTE DE RÈGLEMENT AMIABLE DANS LES CONDITIONS SUSVISÉES, TOUT LITIGE CONCERNANT LA FORMATION, LA VALIDITÉ, L'INTERPRÉTATION, L'EXÉCUTION OU LA CESSATION DU CONTRAT SERA SOUMIS AUX TRIBUNAUX DU RESSORT DE LA COUR D'APPEL DE <Cours d'appel tribunal compétent> PARIS A QUI COMPÉTENCE EST ATTRIBUÉE, NONOBSTANT PLURALITÉ DE DÉFENDEURS, INTERVENTION FORCÉE, NOTAMMENT APPEL EN GARANTIE. CETTE ATTRIBUTION DE COMPÉTENCE S'APPLIQUE ÉGALEMENT EN MATIÈRE DE RÉFÉRÉ.

******************************

Fait à

En deux originaux

LE CLIENT LE PRESTATAIRE

Nom Nom

Qualité Qualité

Date Date

Signature Signature

ANNEXE 1

Méthodes Agiles

La présente description des Méthodes Agiles permet de décrire les principes sur lesquels les Parties ont entendu réaliser le projet. Les autres documents contractuels de rang inférieur ne peuvent déroger aux grands principes exposés, même si expressément ou tacitement ils peuvent adapter aux besoins particuliers les modalités de sa mise en oeuvre, notamment dans le PQS.

Principes des Méthodes Agiles

Le spectre du développement dit agile repose sur un certain nombre de principes et en particulier :

o Un pilotage orienté Produit : les critères de succès sont explicités dès le démarrage du projet et font l'objet d'une attention permanente. L'analyse de valeur du logiciel permet d'arbitrer en permanence pour optimiser la valeur produite en regard de l'effort fourni. Le Directeur de Produit (appelé Product Owner - voir définition en article 2) coopère avec le Client et l'Équipe pour maximiser la valeur du logiciel livré, compte tenu des contraintes qui sont les siennes (budget et délais, en particulier).

Le développement est priorisé par le risque et la valeur métier. La production incrémentale permet d'éradiquer les risques au plus tôt et de maximiser le revenu potentiel, tout en autorisant un pilotage très transparent de la progression.

Le changement de périmètre est possible et passé au crible de l'analyse de valeur et de l'analyse de risque. L'impact sur le planning est mesuré avec le Prestataire (LE PRESTATAIRE), et un arbitrage éclairé peut être effectué par le Client et le Prestataire.

Ainsi, le Client, en cas de périmètre revu à la hausse peut, soit amender son Cahier des Charges en conséquence, soit supprimer certaines fonctionnalités jugées moins importantes pour intégrer les changements souhaités et garder son budget projet inchangé. Pour cela, il opèrera un système d'échange de Story Points (voir définition en article 2) en accord avec le Prestataire. C'est le mécanisme du Trade in / Trade out.

De la même manière, le Client peut revoir le périmètre à la baisse (droit d'interruption anticipée) dont les modalités sont définies au Contrat.

o L'excellence des équipes : le développement logiciel est une activité d'ingénierie qui requiert des compétences pointues et variées. Les équipes du Prestataire sont de petite taille, expérimentées, pluridisciplinaires, dotées de toutes les compétences nécessaires au

développement d'applications modulaires, évolutives, performantes, documentées, intégrables et exploitables. Pour ces équipes, la qualité n'est jamais une variable d'ajustement, ni le test une activité négociable.

La stabilité de l'équipe est un facteur clé du succès d'un développement, et le turn-over un risque commun à tous les projets. Le Prestataire fait en sorte que sur deux mois glissant les deux tiers de l'équipe soient stables.

Les membres de l'équipe sont identifiés et présentés au Client qui peut ou non valider la pertinence des profils dans le contexte projet. Les équipes sont constituées au moins à 75% de membres senior (plus de 5 ans d'expérience).

o Un développement incrémental : La réalisation est incrémentale. Les incréments, d'une durée typique de 2 semaines, aboutissent à la livraison d'un logiciel (éventuellement partiel) parfaitement opérationnel. Les fonctionnalités développées durant l'incrément sont systématiquement intégrées et testées. Seules celles effectivement validées au terme de l'incrément sont prises en compte dans la mesure de la progression. L'effet tunnel est ainsi supprimé et le pilotage de l'avancement est rendu transparent.

o Qualité et productivité : Les équipes du Prestataire disposent d'une usine logicielle performante, et tous leurs membres sont rompus aux techniques de développement issues de l'eXtreme Programming (XP) : gestion de source et propriété collective du code, tests unitaires systématiques, tests d'intégration et tests fonctionnels automatisés, conception continue, refactoring, pair programming, build automatisé, intégration continue, qualimétrie automatisée, normes de développement, etc.

o Une transparence absolue : le déroulement du développement est totalement transparent. L'intégralité des artefacts est continuellement accessible au Client. En particulier, selon les artefacts mis en oeuvre dans le cadre du projet du Client : le code source, les documents de conception, les rapports de tests, les rapports d'intégration continue, le tableau de bord qualité, l'outil de gestion de projet, le portail projet (wiki) où sont consignés tous les comptes-rendus. Une description plus précise de ces outils est fournie dans la section consacrée à l'usine logicielle. Une analyse des risques et des problèmes, ainsi qu'une liste des actions prises pour les mitiger ou les supprimer sont également maintenues publiques dans le portail projet.

Contrairement aux méthodes formelles traditionnelles, les méthodes agiles sont davantage un système de valeurs qu'une prescription rigoureuse quant à l'enchaînement d'activités et de livrables intermédiaires.

Ce système de valeurs a été formalisé en 2001 sous la forme du Manifeste Agile :

Individus et interactions plutôt que les processus et les outils
Un logiciel qui fonctionne plutôt qu'une documentation exhaustive
La collaboration entre les parties plutôt que la négociation contractuelle
Répondre au changement plutôt que suivre un plan

La contractualisation d'une réalisation en Méthodes Agiles est nouvelle sur le marché français tant sur les concepts qu'elle sous tend que sur la nature des relations instaurées entre le Client et le Prestataire.

Des incertitudes tant du point de vue technologique que fonctionnel ont été identifiées par les deux Parties avant la signature de ce Contrat.

Le Contrat prévoit donc en conséquence, les modalités possibles d'ajustement du périmètre contractuel.

Description de la démarche projet du Prestataire et définitions de l'agilité

Le Prestataire réalisera le développement du Logiciel en s'appuyant sur Scrum et XP (eXtreme Programming), les deux méthodes agiles les plus répandues dans l'industrie logicielle.

Ce paragraphe définit la terminologie agile qui est utilisée dans le Contrat et qui le sera tout au long du projet.

Scrum se positionne au niveau de la gestion et de l'organisation de projet là où XP se positionne au niveau des activités de développement. C'est la raison pour laquelle ces deux méthodologies fonctionnent bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

SCRUM

Davantage qu'une méthode formelle, Scrum peut être vue comme un cadre méthodologique dont l'implémentation doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en oeuvre.

Scrum définit un jeu minimal d'acteurs, de cérémonies et d'artefacts qui permettent de relever les défis principaux du développement incrémental : la planification, la gestion du temps et la gestion des risques. Scrum est entièrement pilotée par la valeur métier - la gestion des risques, en particulier, est réalisé au travers de ce prisme.

Le logiciel développé s'appelle en terminologie Scrum, le Produit (Product). Scrum identifie trois acteurs :

o le Product Owner (Directeur de Produit), qui possède l'expertise fonctionnelle et est à même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès d'un projet agile. Le Product Owner est issu du personnel du Client et est suffisamment disponible pour l'équipe (voir obligations du Client).

o le Scrum Master, membre de l'Équipe, et dont la tâche principale est d'optimiser la capacité de production de l'Équipe en l'aidant à travailler de façon autonome et à s'améliorer constamment. Il est également le garant de la bonne implémentation de Scrum. Il est enfin le garant vis-à-vis de l'Équipe, de la suppression de tous les obstacles qui empêchent l'équipe d'avancer. Dans certains cas, il se retournera vers le Client qui est, en dernier recours, en charge de supprimer tous les obstacles lorsqu'ils sont portés à sa connaissance.

o l'Équipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis comme une borne supérieure), et qui prend en charge le développement du Produit (planification,

conception, codage, tests, documentation) sans spécialisation des rôles. La particularité d'une Équipe Scrum est d'être « auto-organisée », et donc dépourvue de hiérarchie.

L'unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l'ordre de 2 à 4 semaines) dont le périmètre est garanti et défini lors d'une cérémonie de planification initiale.

Le schéma suivant décrit l'articulation générale de Scrum :

Scrum définit également trois artefacts :

o Le Burndown Chart, qui est une représentation graphique de l'avancement du projet, visible de tous les personnels Client et Prestataire impliqués dans le projet.

o Le Product Backlog est fondamental à Scrum - sans lui, rien n'est possible.

Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du Product Backlog sont rédigés sous forme de « User Stories ».

o Une User Story est une forme simplifiée et faiblement détaillée de cas d'utilisation, et doit se focaliser sur les objectifs métiers du logiciel développé. Elle est accompagnée de critères d'acceptance servant à sa validation (Scenario de test, script de test, etc ..)

Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de Scrum : le Sprint Planning (planification du Sprint).

Le Sprint Planning réunit l'Équipe et le Product Owner pour déterminer l'objectif et le contenu du Sprint à venir. C'est durant cette cérémonie que l'estimation fine de la charge de développement de chaque User Story est déterminée. Les User Stories sont découpées en tâches dont chacune fait l'objet d'une estimation de charge- exprimée en heures ou en jours. Il est important de noter que c'est l'Équipe qui détermine la charge afférente à chaque tâche. Le principal résultat de cette cérémonie est le Sprint Backlog, qui regroupe l'ensemble des fonctionnalités que l'Équipe s'engage à produire durant l'itération naissante, et liste les tâches correspondantes.

Au terme de chaque Sprint, le produit partiel est livré avec le niveau de qualité attendu pour son exploitation en production - cette caractéristique est à l'origine du qualificatif « incrémental » souvent associé aux méthodes agiles. Les User Stories implémentées font l'objet d'une démonstration publique à laquelle le Client est tenu d'assister. Au même titre que les livraisons sont incrémentales, les recettes, effectuées par le client, le sont également.

Ainsi la recette incrémentale nécessite que la recette du contenu développé pendant le Sprint N doit impérativement être prononcée avant la fin du Sprint N+1 (cf $ engagements).

Outre le Sprint Planning, voici les principales cérémonies introduites par Scrum :

o la mêlée quotidienne (Daily Scrum), courte cérémonie (de l'ordre de 15 minutes) menée chaque jour avec les membres de l'Équipe et le Product Owner, et dont l'objectif est de maintenir chacun au courant de l'activité de tous, de déterminer les tâches de la journée et d'identifier les éventuels obstacles qui ralentissent ou empêchent la progression du sprint.

o

XP comprend un certain nombre de pratiques dont la mise en place est souvent associée à l'adoption des méthodes agiles comme :

la revue de sprint (Sprint Review), qui consiste pour l'essentiel, au terme de chaque itération, à faire une démonstration publique du résultat du Sprint ; cette cérémonie permet de garantir le caractère incrémental du développement (pour être démontré, le produit doit être utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins d'ajuster le contenu du Product Backlog. Le personnel du Client, notamment le Product Owner, doit être présent à cette cérémonie.

o la rétrospective, qui réunit l'Équipe, au terme de chaque Sprint afin d'identifier les erreurs commises lors du Sprint précédent et de définir un plan d'actions (concret et affecté) en vue d'améliorer le processus ; la rétrospective est une cérémonie capitale qui incarne l'un des principes fondamentaux énoncés par le Manifeste Agile : A intervalles réguliers, l'Équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.

Scrum, on le voit, adresse la problématique du processus de production du logiciel. Les promesses du développement itératif et incrémental ne peuvent cependant pas être tenues sans adopter un certain nombre de pratiques de génie logiciel, réunies sous le terme eXtreme Programming (XP).

La complexité des User Story à développer s'évalue en Points de Fonction (FP), qui représente une mesure relative par rapport à un niveau de complexité étalon.

La productivité de l'équipe s'appelle la vélocité et s'évalue en Points de Fonction par Sprint. Cette vélocité a tendance à augmenter dans le temps jusqu'à se stabiliser à un niveau de « croisière ».

Le Prestataire maintient aussi un tableau de bord de son projet, le Kanban, dans lequel le Client trouvera l'intégralité des informations nécessaires à sa compréhension de l'état d'avancement de l'Équipe.

EXTREME PROGRAMMING - XP

La première des pratiques de l'eXtreme Programming, la plus fondamentale également, est le test.

L'approche incrémentale suppose une vision minimaliste du développement : seules les fonctionnalités effectivement nécessaires sont développées, et le design adopté doit être le plus simple imaginable permettant d'implémenter intégralement la fonctionnalité. Conséquence de cette recherche de simplicité, certains choix de design, suffisants à un moment donné, peuvent s'avérer inadaptés lors de développements ultérieurs. L'ajustement se fait alors par refactoring (ou ré-ingénierie), qui consiste à modifier le design voire l'architecture d'un composant sans changer son comportement. Le refactoring - une opération techniquement triviale avec les environnements de développement java, plus délicate lorsqu'il s'agit de la base de données - comporte un risque de régression évident, risque couvert en principe par la pratique des tests unitaires et la recette incrémentale.

Le test automatisé n'est pas seulement une bonne pratique du développement agile : il en est l'épine dorsale.

XP inclut la systématisation des tests unitaires automatisés, et fait du taux de couverture des tests - la proportion du code exécutée par les tests unitaires - une métrique clé pour estimer le niveau de qualité des développements.

o Intégration Continue ; cette pratique consiste à déclencher de façon systématique le système de build - qui comprend notamment la compilation et l'exécution des tests unitaires et d'intégration - chaque fois qu'un membre de l'Équipe valide des sources dans le référentiel projet ; c'est une pratique essentielle pour détecter et corriger au plus tôt les problèmes d'intégration des développements. A plus grande échelle, l'intégration continue permet de tester de façon régulière (au moins quotidiennement) l'intégration de composants développés par des équipes distinctes.

o Propriété Collective ; la propriété collective du code consiste à ne pas spécialiser certains membres de l'équipe sur certains composants - et donc à favoriser la polyvalence au sein de l'Équipe. Elle est favorisée par des pratiques telles que la programmation en binôme qui permet l'appropriation d'une base commune de code. Les équipes avec un haut niveau d'appropriation collective de code sont réputées pour être plus robustes : un Sprint ne sera par exemple pas forcément menacé par l'absence ponctuelle d'un membre de l'Équipe.

o Normes de développement ; sans être une particularité de l'eXtreme Programming, les normes de développement en sont un élément clé, facilitant les tests, l'intégration continue et l'appropriation collective de la base de code. Elles renforcent également la consistance des APIs (interfaces d'accès).

o Programmation en binôme (Pair Programming), qui consiste à développer à deux sur un même poste ; cette pratique n'est utilisée que ponctuellement, par exemple sur une nouvelle technologie, une problématique pointue, un fonctionnel plus complexe, ou plus simplement, si l'un des membres de l'Équipe demande de l'assistance. C'est aussi une pratique utile lors des montées en charge de l'Équipe : elle permet d'intégrer plus rapidement les nouveaux développeurs.

o Rythme soutenable ; ce principe est commun à toutes les méthodes agiles, et directement issu du heijunka Lean ; il part du principe qu'il n'y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d'une charge de travail supérieure à sa capacité de production.

Certaines des pratiques de l'eXtreme Programming ont irrigué Scrum - « une équipe », « une même pièce », la notion de « stories », le « rythme soutenable » ou encore le « planning game », raison pour laquelle ces deux approche sont très complémentaires.

ANNEXE 2

Vision du CLIENT

ANNEXE 3

Estimation de charges, structure et délais du PRESTATAIRE

ANNEXE 4

Plan Qualité de Service

Version initiale

1. Contexte d'utilisation du plan

L'objectif de ce Plan de Qualité de Service est de présenter les dispositions prises par CLIENT et par l'équipe projet pour :

- Organiser le déroulement du projet. - En assurer la qualité.

Ce plan de qualité de service (désigné tout au long du document par l'acronyme PQS) est :

· Un document de référence pour tous les acteurs du projet. Il permet de partager une vision commune entre CLIENT et PRESTATAIRE.

· Un engagement sur les critères de qualité du projet. Il est réalisé en collaboration avec CLIENT et approuvé par lui.

· Un descriptif de la gouvernance du projet.

Chaque partie se doit de respecter le PQS dans sa dernière version amendée au contrat.

2. Domaine d'application

Description du contexte du projet.

Exemple : ...

1. Présentation

2. Contexte

3 .Objectifs

3. Responsabilité de l'assurance qualité

1. Responsables

Conformément aux principes de la méthodologie agile SCRUM, l'ensemble des membres de l'équipe est responsable de la qualité du projet et se doit ainsi de respecter les engagements pris dans le présent PQS.

XX XXX, en tant directeur de projet, se porte garant du respect du PQS, au nom de l'équipe et au nom de PRESTATAIRE.

YY YYY, en tant que chef de projet, se porte garant du respect du PQS, au nom du CLIENT

Cette section décrit l'ensemble des dispositions à mettre en oeuvre pour s'assurer du bon déroulement de la prestation.

4. Suivi de l'exécution du plan

1. Pilotage

Bilan de Sprint	Revue des indicateurs de performance et décisions associées, point sur les risques		· Chef de projet CLIENT · Directeur de Projet PRESTATAIRE	Comité de pilotage
Revue de l'avancement de la release en cours et du planning de mise en production, point sur les risques et problèmes, revue de la capacité d'exécution	· Chef de projet client · Directeur de Projet PRESTATAIRE · Product Owner · Scrum Master

2. Critères de suivi de la prestation

Afin de s'assurer du niveau de qualité de la prestation, PRESTATAIRE propose des critères qualitatifs et quantitatifs qui sont évalués par des indicateurs.

Ces indicateurs servent à mettre en lumière des situations anormales, par exemple :

- Baisse de la productivité

- Instabilité de l'équipe

- Défaut de qualité du produit

Ces situations peuvent être dues à des événements indépendants des deux parties ou un manquement d'une ou des deux parties.

Des seuils sont fixés pour chaque indicateur.

Le franchissement d'un de ces seuils déclenche une analyse causale en comité de pilotage. Des pénalités financières seront appliquées dans le cas où PRESTATAIRE aurait manqué à ses engagements. (SI l'option des pénalités n'est pas retenue -> supprimer le paragraphe 6.3 du contrat)

La méthode de calcul et le montant des pénalités sont spécifiés dans l'annexe financière.

3. Liste des critères évalués par un indicateur

Critères avec seuil d'alerte

- Prédictibilité

- Productivité de l'équipe

- Qualité du logiciel délivré : Technique et fonctionnelle

Critère	Prédictibilité
Objectif	Suivre le respect du périmètre fonctionnel de chaque itération
Définition	Nombre de fonctionnalités démontrées en fin d'itération par rapport aux fonctionnalités prévues.
Mesure	Soit A = Somme des points de complexité
	correspondant aux fonctionnalités		livrées et
	démontrées en fin d'itération.
	Soit B = Somme des points de		complexité
	correspondant aux fonctionnalités		prévues en
	réunion de planification d'itération.
	Prédictibilité = (A/B)*100
Unité de mesure	%
Seuils	Objectif	100 %
(phase opérationnelle)	Alerte	< 75 %

e de lance e de lance

Critère

	Productivité
Objectif	Suivre la capacité de l'équipe à enrichir le produit à chaque itération
Définition	Le nombre de «story points » qui ont été implémentés dans un sprint rapporté à la taille de l'équipe.
Mesure	Soit A = Somme des «story points » correspondant aux fonctionnalités livrées et démontrées en fin d'itération. Soit B = Charge totale de l'équipe. Productivité : X = (A/B)
Unité de mesure	N/A
Seuils (phase opérationnelle)	Objectif	A définir à l'issu de la phas
	Alerte	A définir à l'issu de la phas

e de lance

Critère

	Qualité du logiciel livré : Fonctionnelle
Objectif	Suivre la qualité du logiciel livré du point de vue fonctionnel
Définition	Nombres d'anomalies (y compris régressions) découvertes après la livraison de l'incrément de produit.
Seuils (phase opérationnelle)	Objectif	0
	Alerte	A définir à l'issu de la phas

8

40

Critère

	Qualité du logiciel livré : Technique
Objectif	Suivre l'évolution de la dette technique
Définition	A minima, couverture de code (non généré) par les tests unitaires et complexité cyclomatique.
Mesure	Mesure automatique à l'aide d'un outil adapté
Seuils (phase opérationnelle)	Objectif	Couverture de code : 85% Complexité cyclomatique :
	Alerte	Couverture de code < 60 % Complexité cyclomatique >

Critères sans seuil d'alerte

- Implication de l'équipe

- Satisfaction client

Critère	Implication de l'équipe
Objectif	Mesurer l'implication de l'équipe
Définition	Une mesure de l'implication des membres de l'équipe au sein de l'équipe et de l'organisation.
Mesure	Lors de chaque rétrospective d'itération chaque membre de l'équipe réponds à la question suivante : « Sur une échelle de 1 à 5, recommanderiez vous cette équipe et ce projet à un de vos collègues ? »
Outil de mesure	Moyenne des notes
Unité de mesure	Note de 0 à 5
Objectif	5

Comme spécifié dans le paragraphe 5.1 (« Découpage des prestations ») du contrat agile, le projet est découpé en trois grandes phases :

Critère	Satisfaction client
Objectif	Mesurer la satisfaction du client
Définition	Une mesure de la capacité de l'équipe à répondre aux attentes du client.
Mesure	A l'issu de chaque démonstration chaque personnes impliquées dans le projet coté client doit répondre à la question suivante : « Sur une échelle de 1 à 5, recommanderiez vous cette équipe et ce projet à un de vos collègues ? »
Outil de mesure	Moyenne des notes
Unité de mesure	Notes de 0 à 5
Objectif	5

5. Documents applicables et de références

Le projet devra se dérouler selon les principes de la méthodologie SCRUM décrite dans l'Annexe 1 du contrat.

Tout au long du projet, les deux parties pourront se référer à l'annexe 2 du contrat : « Vision (Cahier des charges) ». Ce document décrit les objectifs du projet et donne les grandes fonctionnalités attendues du produit à réaliser.

Enfin, le montant de la prestation, l'échéancier de paiement et la méthode de calcul du montant forfaitaire d'éventuelles pénalités se trouvent dans l'annexe 6 : « Annexe financière »

6. Terminologie

La terminologie liée à la pratique de la méthodologie agile SCRUM est entièrement définie dans le contrat agile dans l'annexe 1 « Méthodes Agiles »

7. Organisation du projet

- Phase de lancement

- Phase opérationnelle

- Phase de finalisation

-

Phase de lancement

La phase de lancement du projet se découpe en deux parties :

- Sprint 0 : Le contenu et les objectifs du Sprint 0 sont décrits dans le contrat (5.1.1)

- Sprints 1 à 3 : Les sprints 1 à 3 sont des sprints de production dont les objectifs sont :

o Délivrer des incréments de logiciels.

o Stabiliser les indicateurs choisis pour suivre le projet. A l'issue du sprint 3, PRESTATAIRE s'engage sur la valeur définitive des seuils d'alerte pour chaque indicateur.

Phase opérationnelle

La phase opérationnelle est une succession de Sprints à l'issue desquels PRESTATAIRE livre des incréments de logiciel.

Ces incréments sont testés et validés par CLIENT lors de recettes incrémentales. Phase de finalisation

Finalisation régulière :

Un comité de pilotage exceptionnel défini le contenu des deux dernières itérations du projet. Arrêt anticipé du projet :

CLIENT à la possibilité d'interrompre le projet lorsqu'il considère que le projet a atteint des objectifs suffisants.

Les modalités de cet arrêt anticipé sont spécifiées dans le paragraphe 17.2 du contrat agile : « Atteinte anticipée des objectifs du client »

8. Pratiques d'ingénierie

Les pratiques d'ingénierie suivies par PRESTATAIRE se basent principalement sur des techniques issues de l'eXtreme Progamming (XP). L'XP est un ensemble de 13 pratiques dont la définition est consultable à l'adresse suivante : ( http://fr.wikipedia.org/wiki/Extreme_programming) PRESTATAIRE systématise l'utilisation de quatre d'entres elles :

- Développement piloté par les tests (appelé aussi TDD)

- Propriété Collective

- Normes de développement

- Programmation en binôme (Pair Programming)

Il aurait fallu évoquer toutes les méthodes susceptibles d'inspirer les pratiques de développement du

projet, en effet l'annexe 1 précise que le projet sera piloté selon les méthodologies « scrum » et « XP ». L'annexe 1 contient déjà une description de ces méthodes. Se référer à l'article de Wikipedia pour la définition de XP consiste à lui donner valeur contractuelle, en cas de divergences entre ces deux sources c'est l'annexe 1 qui prévaudra (voir 4.2). C'est préférable car un article Wikipedia est modifiable par tout internaute, il suffit de créer un compte en quelques clics pour pouvoir contribuer à l'encyclopédie.

9. Gestion des modifications

Les demandes de changement sont de deux types :

· Anomalie: écart constaté avec les critères d'acceptation d'une story (cf. Définition d'une story dans le contrat agile : Annexe 1)

· Evolution: L'écart est du à une modification, un ajout ou une suppression au niveau des spécifications des besoins

Le processus détaillé de gestion des modifications est à définir en phase de lancement, en respectant les principes suivants:

· A la fin de chaque itération, un PV de recette provisoire est signé sur la base des éléments prévus en début de sprint et démontrés en fin de sprint, il mentionne les éventuels anomalies et évolutions souhaitées

· CLIENT dispose ensuite de 2 semaines maximum pour effectuer la recette partielle ou complète d'un incrément

· Les retours de démonstration mentionnés dans le bon de livraison sont traités dans le sprint N+1

· Les retours de recette sont planifiés par défaut dans le sprint N+2

ANNEXE 5

Conditions Particulières

au Contrat de prestation de

services réalisés selon les

Méthodes Agiles

1. RÉFÉRENCE CONTRACTUELLE / OBJET

ENTRE :

<DÉNOMINATION SOCIALE>

Société <forme juridique> au capital social de <montant> euros, inscrite au RCS de <ville> sous le numéro <numéro>, dont le siège social est sis <adresse>.

Représentée par <nom>, agissant en sa qualité de <statut>, dûment habilité à l'effet des présentes.

Ci-après dénommée le « Client »

D'une part

ET :

LE PRESTATAIRE

<Raison Sociale, Adresse, RCS>

Représentée par le signataire du présent contrat, dûment habilité à l'effet des présentes.

Ci-après dénommée « LE PRESTATAIRE »

D'autre part

Ces stipulations apparaissent contraires à celles de l'article 5.3 (« personnels affectés à la réalisation des prestations », voir note sous l'article 5.3 ; voir II, 1.2 Réglementations diverses).

Les présentes Conditions Particulières sont prises en application du Contrat en référence. Elles ont pour objet de compléter et/ou amender la lettre et la portée dudit Contrat. La signature par le CLIENT des Conditions Particulières emporte acceptation expresse des termes dudit Contrat qui n'auront pas été complétés et/ou amendés. Les termes en majuscule figurant aux présentes sont définis au sein dudit Contrat.

2. COMPLÉMENTS / AMENDEMENTS AU CONTRAT

2.1. LE PRESTATAIRE pourra ajuster l'estimation de charges, structure et délais pendant le Sprint 0

conformément aux articles 5.1.1. et 11.1.2. :

? à la baisse dans la limite de <limite basse re restimation Backlog en %> ? à la hausse dans la limite de <limite basse re restimation Backlog en %>

%; %.

2.2. Comme annoncé à l'article 5.2., LE PRESTATAIRE réalisera les prestations objet du Contrat sur le

site <lieu d'exécution>.

< Si exécutées chez le Client

Les prestations seront intégralement délivrées tel que décrit dans les conditions particulière chez le CLIENT. Le Client fournira de ce fait une salle projet ayant suffisamment d'espace pour accueillir les personnels du PRESTATAIRE et leur permettre de travailler dans des conditions satisfaisantes.

Pour des raisons de sécurité, LE PRESTATAIRE fournira à l'occasion du Sprint 0 une liste des personnels qu'elle affectera à la réalisation des prestations et pour lesquels le CLIENT lui délivrera dans le même temps une autorisation d'accès à ses locaux pour la durée du Contrat. LE PRESTATAIRE s'engage à maintenir ladite liste à jour et à communiquer toute modification dans les meilleurs délais au CLIENT. Réciproquement, le CLIENT s'engage à délivrer dans les meilleurs délais au PRESTATAIRE une autorisation d'accès à ses locaux mise à jour en conséquence.

Le CLIENT devra permettre l'accès à ses locaux aux personnels du PRESTATAIRE autorisés, aux jours et heures ouvrés, sauf en cas de nécessité où il devra mettre en place une procédure d'accès à ses locaux en dehors des périodes habituelles.

LE PRESTATAIRE devra s'assurer que ses personnels se conforment à toute réglementation en vigueur dans les locaux du CLIENT, notamment aux règles d'hygiène et de sécurité, et plus généralement au règlement intérieur du CLIENT et au calendrier et horaires de celui-ci, le cas échéant en usant de son pouvoir disciplinaire.

A cet effet, le CLIENT remettra au PRESTATAIRE un exemplaire de son règlement intérieur et des règles d'hygiène et de sécurité avant le début des prestations.>

2.3. Conformément à l'article 7.1. :

? Le rôle de Chef de projet sera assumé par <nom Chef de projet CLIENT>.

? Le rôle de Product Owner sera assumé par <nom du PO>.

? Le rôle de Directeur de Projet PRESTATAIRE sera assumé par <nom Directeur de Projet

Prestataire>.

? Le rôle de Scrum Master sera assumé par <nom du SM>

2.4. Lorsque la phase de finalisation prévue au 5.1.3. ou la portabilité prévue à l'article 14 seront

mises en oeuvre à la demande du CLIENT en vertu de l'article 17.2., les modalités de facturation seront les suivantes :

À compléter

ANNEXE 6
Tarifs

<Cette partie spécifie les tarifs journaliers de prestations dans le cas de réalisations hors contrat supplémentaires. Les bases tarifaires sont pré négociées.>

ANNEXE 7

Product Backlog