Expertises des Systèmes d'information - Le mensuel du droit de l'informatique et du multimédia - Avril 2017 - n°423 - 151

de décision par le client, les obligations de
formation voire de transfert de savoir-faire
peuvent devenir nécessaires.
Ensuite, l'obligation de documentation
peut nécessiter une attention particulière(6). Dans la plupart des projets agiles,
les tâches à réaliser sont priorisées par le
client, qui tend généralement à préférer les
tâches opérationnelles qui créent du résultat à celles liées à la documentation. Aussi
il pourra être pertinent de prévoir une obligation de documenter à la charge du prestataire. Dans ce cas, ce dernier devra tenir
compte du temps nécessaire à la documentation lors de l'évaluation du nombre
de tâches (User Stories)(7) qu'il proposera de
réaliser pendant une itération (Sprint).
Enfin, abordons l'une des questions les plus
débattues parmi les juristes s'intéressant à
l'Agilité, compte-tenu de l'implication du
client et de la quasi-disparition du cahier
des charges : les obligations de résultats
disparaissent-elles avec l'Agilité ? Selon
nous(8), les obligations de résultats sont toutà-fait envisageables. En effet, d'une part, s'il
devient adaptable, le cahier des charges
ne disparaît pas, et d'autre part, les obligations du client peuvent être circonscrites de
façon suffisamment précise. Ainsi, l'inexécution par le prestataire de son obligation
de faire pourra être attestée simplement
par la preuve que l'obligation n'a pas été
réalisée. Evidemment en retour le prestataire pourra chercher à prouver que le
client n'a pas non plus exécuté l'une de
ses obligations, comme celle de définir le
besoin, de recetter(9) ou de payer le prix.
Or ce triptyque d'obligations est modifié
au profit d'une plus grande implication du
client, il devient donc absolument nécessaire de s'y attarder.
D'une part, l'Agilité permettant l'adaptation du projet à un besoin réel que le client
est amené à préciser au cours du projet,
l'expression du besoin n'interviendra plus
uniquement au lancement du projet et à
l'occasion de quelques réunions du comité
de pilotage. Le client devra donc se rendre
suffisamment disponible ou mobiliser le
personnel nécessaire pour prioriser les
tâches (User stories) identifiées dans le
cahier des charges du produit (Product
Backlog), dans un cahier des charges de
l'itération (Sprint Backlog).
De la même manière, le caractère itératif
de la plupart des méthodes agiles amène
le prestataire à livrer régulièrement, ce qui
induit une obligation de recetter plus forte

à la charge du client. En effet, ces recettes
provisoires conditionnent la poursuite du
projet et son orientation. Il est donc impératif que le client réceptionne les livrables
dans un délai qui devra être déterminé.
Cette obligation de recetter devra nécessairement apparaître et être circonscrite(10),
car elle peut aussi constituer une obligation de résultat à la charge du client.
D'autre part, le prix, et particulièrement
son critère de fixation, fait l'objet de
nombreux débats(11). Certains affirment en
effet que l'Agilité met fin aux prix forfaitaires. En tout état de cause la méthode
de fixation du prix évolue, avec l'apparition d'un référentiel évolutif (pour plus de
détails voir II.). Il est désormais impossible
de conditionner le prix à la réalisation du
cahier des charges initial, aussi le prix de
la prestation ne pourra être évalué qu'en
régie ou en forfait par unité d'œuvre(12).
Cependant cette dernière méthode d'évaluation éveille la méfiance des agilistes car
son caractère subjectif pourrait dégrader
les relations entre le responsable projet
du client (Product Owner) et l'équipe du
prestataire. Le caractère évolutif du besoin
implique donc de nombreuses modifications de la relation contractuelle, que nous
allons maintenant approfondir.

DE LA SOUPLESSE
CONTRACTUELLE
Comme nous avons pu l'évoquer, l'adaptation du projet aux évolutions du besoin(13)
est l'une des caractéristiques principales
de l'Agilité. Il est donc nécessaire d'étudier
comment cette évolution peut être prise en
compte et quels sont les paramètres qui
constituent le nouveau référentiel du projet.
Il est nécessaire de bien comprendre que le
cahier des charges initial ne disparaît pas,
mais qu'il n'est plus le référentiel immuable
du projet. Au contraire il est amené à
être modifié pour prendre en compte les
contraintes techniques ou les évolutions
du besoin initial. Aussi il sera intéressant
de prévoir dès la rédaction du contrat
les conditions d'évolution du cahier des
charges (Product Backlog), ce qui permettra de structurer le pilotage du projet, par
exemple en nommant un responsable
projet du côté du client (Product Owner)
ayant la possibilité de modifier ce cahier
des charges. Cependant, le cahier des
charges n'est pas le seul paramètre du
contrat à devenir évolutif. En effet, l'Agilité

EXPERTISES AVRIL 2017

fait apparaître le concept de « variables
d'ajustement », ces variables sont un
ensemble de paramètres dont la flexibilité devra être déterminée dès le début du
projet. Ainsi, les parties au contrat s'accordent dès le début du projet sur le fait
que certaines variables pourront évoluer
et dans quelle mesure, maîtrisant ainsi
mieux l'évolution du projet.
En revanche, si les flexibilités du projet
sont assumées comme nous venons de le
voir, l'Agilité n'induit pas la disparition des
paramètres du contrat. Car certains de ces
paramètres s'assouplissent, et d'autres en
revanche prennent une nouvelle importance. Par exemple, si le besoin est souvent
une variable d'ajustement, le budget au
contraire, peut devenir une constante.
En conséquence et contrairement à un
projet classique, un projet Agile pourra
prendre fin lorsque le budget défini sera
atteint et non pas à la réalisation du cahier
des charges. C'est pourquoi il est nécessaire d'organiser le projet agile dans un
contrat précisant clairement tous les paramètres du contrat ainsi que leur caractère
variable ou non.
Dans ce contexte de souplesse contractuelle, un mode de rupture pour convenance est envisageable. Cependant,
ce mode de rupture peut constituer une
source d'insécurité contractuelle, voire de
déséquilibre notable du contrat, l'existence
de ce dernier devenant au pouvoir de l'une
des parties. Aussi, cette possibilité devra
être encadrée contractuellement si elle ne
peut être évitée. D'une part, en prévoyant
que seul le client bénéficie de cette possibilité(14), et uniquement à l'issue de l'une des
itérations (sprints). Et d'autre part, le contrat
peut être adéquatement rééquilibré par
une proposition commerciale comprenant la prise en compte de ce risque et un
fonctionnement adapté de la société prestataire. En effet, les contreparties de cette
possibilité unilatérale de rompre devront
être très clairement présentées, afin de
mettre en exergue le caractère équilibré
du contrat.
Ainsi, le projet agile peut, assez couramment, prendre fin sans être concrètement finalisé ou terminé. C'est pourquoi
il est indispensable de prévoir de façon
précise sa réversibilité. Cette dernière
devra être envisagée au sens large, tant
pour ce qui est des droits de propriété
intellectuelle(15) que des conditions matérielles de la fin du projet. Si le client devient
propriétaire des résultats, le contrat devra

151

Table des matières de la publication Expertises des Systèmes d'information - Le mensuel du droit de l'informatique et du multimédia - Avril 2017 - n°423