Jacques Witte blog at usineweb.fr

La bonne formulation d’un contrat reste la pierre angulaire du commencement d’un projet et surtout la réussite de sa finalisation...

Dans le cadre d’équipes fonctionnant en méthodes agiles, comment faire pour que ces document soient en accord avec la real politik de la mise en oeuvre “agile” notamment le développement itératif du produit ?

Le background

Tout d’abord, rappelons brièvement deux concepts:

• le développement itératif
  1. Consiste en un développement “par version” d’un produit,
  2. Chaque itération (version) est courte (se compte en jours tout au plus) et livre un produit fonctionnel (exploitable par le client).
  3. A la suite de chaque livraison, le client peut définir ou re-définir le cahier des charges de la nouvelle itération jusqu’à atteindre le produit fini

• le contrat au forfait
  1. Consiste en un contrat qui détermine une liste exhaustive de fonctionnalités de la version finale d’un produit à réaliser dans des échéances données

Les points de vues

Il est clair que ces deux concepts s’affrontent: on ne peut pas signer un contrat au forfait d’un produit et en assurer un développement agile sans payer le prix de la contradiction….

Quelles sont les marges de manoeuvre existantes ? Il faut d’abord confronter les deux points de vues:

• point de vue client
  1. le client veut se rassurer sur combien il va payer au total (sachant qu’il prévoit souvent pour les finitions une marge de X % de dérapage)
  2. le client veut définir l’ensemble des fonctionnalités du produit, même si celles-ci peuvent être floues (de peur de se retrouver à la livraison de celui-ci sans marge de négociation possible)
  3. le client veut que le produit soient réalisé dans une échéance temps (date de début, date de fin) pour respecter ses impératifs stratégiques propres (commercial, de communication, d’organisation…)

• point de vue de l’équipe de mise en oeuvre
  1. l’interprétation et donc le chiffrage d’un gros contrat au forfait (liste exhaustive de fonctionnalités) est un exercice vaudou difficile qui, sous-estimé, impacte la rentabilité du contrat (alors que celui-ci n’a pas démarré)
  2. l’équipe de mise en oeuvre va donc souvent surestimer les temps de production (le plus souvent en facteur multiplicatif) sur chaque fonctionnalité floue ou susceptible de changer
  3. le client par nature lorsqu’il reçoit le produit s’aperçoit que l’interprétation de la mise en oeuvre de telle fonctionnalité était erroné (c’est l’effet surprise) et demande (avec raison) des correctifs qui deviennent une charge de travail non chiffrée pour l’équipe

Vers une solution

Il faut donc trouver une solution contractuelle qui:

1. satisfasse le client sur la vision macro-planning du projet sur lequel les deux parties s’engagent
2. apporte de la flexibilité sur les phases charnières du projet pour l’équipe de mise en oeuvre (afin de réduire “l’effet surprise”)
3. permette d’éviter les engagements contractuels basés sur des fonctionnalités ou chiffrages flous ou susceptibles de changer (sur lesquelles on ne peut malheureusement pas revenir une fois signé…)

Une méthode contractuelle

La recette, consisterait à ne pas confondre cahier des charges et contrat :

1. Le client fournit un cahier des charges de son produit
2. L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit ce cahier des charges en le découpant en milestones (groupe de fonctionnalités) chiffrés en jours/hommes
3. L’ensemble des milestones (cad le chiffrage du cahier des charge) détermine un nombre de jours/hommes total du projet
4. Le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet (25%, 50%, 75%, 100%...), ce qui signifie la réservation du planning de l’équipe de mise en oeuvre
5. Le client signe la mise en oeuvre de la milestone 1, ce qui signifie l’engagement de début de travaux
6. Ce nombre de jours total est ensuite affecté dynamiquement aux milestones suivants la milestone1:

• dans un ordre qui peut être revisité de façon “agile” par le client & l’architecte
• dans un contenu (cad le détail des fonctionnalités de chaque milestones) qui peut être revu de façon “agile” par le client & l’architecte en fonction du recettage de la précédente milestone et de l’évolution du projet

Le tout constitue une formulation agile d’un contrat au forfait...

Synthèse

Par le biais de sa formulation agile, le contrat + le cahier des charges offrent au client la capacité d’établir une vraie stratégie de mise en oeuvre de son produit:

• flexible dans le temps
• flexible dans les moyens (humain, financier, d’infrastructure) engagés
• flexible dans sa finalité (ce que fait le produit)

Références

• les méthodes agiles
• avantage d’un contrat au forfait et démarche agile
• agilité pour un contrat au forfait

Citations

• article dans Le Mag IT