Ces avocats sont bien conscients des dérives classiques dues aux phénomènes de "changements en cours de projets" (mutation du besoin côté client ou imprévu technique côté fournisseur) :

"Les juristes connaissent parfaitement ces deux phénomènes : ils les analysent depuis des années en tant que fautes contractuelles, génératrices de dommages et intérêts."

Ils comprennent donc d'autant mieux l"intérêt que peut présenter la mise en œuvre de l'agilité, et en tirent les conséquences :

"Le juriste ne doit donc plus appréhender le changement comme cause d’une dérive calendaire, mais comme l’un des paramètres évolutif que les parties ont accepté par contrat. De même, le juriste doit accepter que le contrat ne régisse pas tous les process, mais en pose uniquement les principes opératoires."

Sans proposer de modèle de contrat, les auteurs donnent les idées clefs d'un contrat agile :

  • La définition du besoin n'est plus une partie à part entière du contrat.

"Il est possible d’annexer au contrat un premier backlog, à condition de prévoir alors qu’il sera évolutif, et de mettre en place les modalités d’évolution dudit backlog et l’instance qui validera ses orientations successives."

  • Le développement itératif du produit doit être explicité.

"Le praticien qui rédige un contrat IT doit donc traduire en droit les notions de courtes itérations de durées identiques, et les options qui s’offrent aux parties au terme de chacune d’elles."

  • Les éléments importants de l'organisation sont à faire apparaître.

"Usine logicielle, unité de lieu… autant d’éléments à faire monter en puissance, au chapitre des modalités de réalisation des prestations du contrat."

  • Le "planning projet" projet n'a plus la même forme.

"Il peut alors devenir illusoire d'assortir les jalons intermédiaires d’une obligation de résultat… bien qu'il reste important d'encadrer les grandes étapes du projet et de leur fixer des "deadlines"."

  • La réception se faisant différemment, doit apparaître différemment.

"...[le praticien qui rédige le contrat IT] doit imaginer de nouveaux critères de recette, en conservant à l’esprit qu’eux-mêmes seront susceptibles de varier dans le temps, et qu’il n’est donc pas utile de les « sanctifier » dans le contrat."

  • Ils parlent également de vélocité, réversibilité, de coaching, de collaboration étroite, de la possibilité de faire de projets mixtes (classique + agile), etc.

Je finis sur cet extrait de la conclusion, qui me plaît bien :

"A l’instar des logiciels libres, les Méthodes Agiles sont issues de la pratique, et semblent parfois permettre de tels gains de valeur qu’elles impliquent désormais une révolution culturelle au sein de l’entreprise. La protection frileuse du code source ou la relation classique « client-prestataire » sont parfois des freins à l’efficacité des projets IT ; on constate au contraire que l’innovation, loin d’être menacée par ces nouvelles propositions, peut en être décuplée. Quant au juriste, il relève précisément de son office de s’approprier ces nouveaux concepts pour leur apporter une traduction juridique et contractuelle pertinente. "

En somme, des juristes... agiles.