Méthodes agiles : comment donner de l'agilité à un contrat au forfait (2e partie)

En chimie – ou en cuisine -, on parle d'émulsion. Lorsque deux substances liquides, qui à l'origine n'ont pas la capacité à se mélanger, forment au final une solution homogène. Ce principe pourrait également s'appliquer aux méthodes agiles lorsqu'on aborde le problème de la contractualisation. Reposant sur le développement itératif et plaçant le client au coeur du projet (lire Méthodes agiles : le renouveau des relations client / fournisseur dans l'ingénierie (Première Partie)), le développement dit agile s'oppose radicalement avec le principe original du contrat au forfait, par lequel sont formalisés la plupart des projets informatiques. L'enjeu n°1 de l'entreprise agile est alors de concilier deux impératifs, à priori assez éloignés.

Le contrat au forfait scellé entre un fournisseur et un client formalise, par un cahier des charges ferme, un périmètre de fonctionnalités que le fournisseur doit réaliser en une période donnée. Et ce en cloisonnant les deux mondes : « le client se repose sur ce contrat pour se rassurer sur la facture finale, même en fournissant un cahier des charges flou », explique Jacques Witté, architecte logicielle chez UsineWeb, société de conception et de gestion de projet. De l'autre côté, chez le fournisseur, la réalisation du devis, face au flou artistique qui entoure le projet, reste « un exercice vaudou ». La relation, dès lors, apparaît comme très déséquilibrée.
Le développement par itération, quant à lui, induit par les méthodes agiles, implique de penser par étape – et donc par version - le produit final, tout en impliquant, à la fin de chaque itération courte, le client. Donnant ainsi la possibilité de modifier les fonctionnalités – et donc le produit final – au cours même de l'évolution du projet. Au final, le donneur d'ordre trouve là une flexibilité que le contrat au forfait ne permet pas.
Reste à trouver une façon de contractualiser ce mode d'interaction un peu inhabituel dans la relation entre donneur d'ordre et prestataire.

Dissocier cahier des charges et contrat

Une des clés de cette contractualisation consiste à « séparer le cahier des charges de la partie contractuelle », insiste Jacques Witté. Une stratégie qui conduit à séparer le nombre de jours dans la pratique et les fonctionnalités. « L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit le cahier des charges en le découpant en milestones (groupes de fonctionnalités) chiffrés en jours x homme. Puis, l’ensemble des milestones (le chiffrage du cahier des charges) détermine un nombre de jours x homme total du projet », explique-t-il. Enfin, « le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet ». Alors que le contrat définit chaque tranche de temps qui serviront à calculer les itérations, le cahier des charges reste basé sur le fonctionnel et peut être modifié « à la volée ». Selon les critères des méthodes agiles. Sur cette base, les jours non-utilisés sont ré-attribués à l'itération suivante. La facturation peut être alors effectuée en fonction de chaque itération.

Même son de cloche chez la société People in Action (PIA), spécialiste des RIA (Rich Internet Applications) en environnement professionnel. « A partir du cahier des charges fourni par le client, on fragmente le projet en lots (liés généralement aux fonctionnalités) et on détermine le nombre de jours x homme, nécessaire pour chaque itération . On écrit aussi une liste de critères d'acceptation qui est validée par le client. Puis il s'engage sur un pourcentage de cette même liste – et ainsi du nombre de jours x homme qui peut être alors réaffecté dynamiquement sur les autres lots, selon les priorités décidées par le client », raconte Emmanuel Levi-Valensi, directeur associé de PIA.

La pilule de la facture

Reste alors à convaincre le client. Car si les méthodes agiles impliquent « un clash culturel » dans la gestion de projet « comme avec les projets du Web 2.0 par rapport aux projets informatiques classiques », souligne Jacques Witté, elles ont également un coût supplémentaire qui doit être justifié auprès du client.
L'enjeu n°1 consiste alors à faire accepter ces bouleversements, tant en termes de gouvernance que pour le volet financier.

Une des justifications du surcoût de ces méthodes auprès des entreprises clientes réside dans l'expertise des ressources mises à disposition. Une approche qualitative qui « sert à expliquer l'agilité aux clients », selon Jacques Witté. « L'un des avantages [des méthodes agiles, NDLR] est de distiller les meilleures ressources au bon moment dans l'évolution des développements », explique-t-il, histoire de justifier le surcoût d'une formulation agile d'un contrat au forfait.