Aspects juridiques de la contractualisation agile

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