Facebook EmaiInACirclel
Externalisation IT

Les contrats « Agiles »

Dan Deusan
Dan Deusan
Head of Business Development

Une très grande majorité de projets que Pentalog réalise pour ses clients est faite en mode Agile et nous avons en permanence la problématique d’adapter le cadre contractuel au nouveau contexte Agile. Cette problématique d’adaptation est encore plus difficile dans le cas des forfaits. L’idée de cet article est de présenter dans les grandes lignes quelques solutions possibles qui sont en général de bons compromis pour toutes les parties.

Les contrats représentent des supports pour couvrir, entre autres les moments où les deux parties n’arrivent plus à se parler. Ils reflètent nos peurs et nos espoirs et chaque partie essaie de prévoir des murs de protection qui seront probablement très utiles en cas de litige. Or ces murs réduisent au final la valeur créée et sont un vrai problème sur le long terme, en particulier dans un monde où seuls ceux qui maximisent la valeur arrivent à survivre. Par convention, les contrats doivent limiter le comportement opportuniste des deux parties qui cherchent toujours par instinct leur propre intérêt. La vision Agile préconise que chacune des parties doit agir en bonne foi et que la relation va naturellement limiter le comportement opportuniste.

Le contrat au forfait : une vraie-fausse sécurité

En ce qui concerne les projets en mode forfait, dans le cas des contrats traditionnels le client n’est pas protégé même si le risque le plus important est généralement sur le fournisseur. En effet, le client favorise en général le prix le plus bas au détriment du reste, souvent donné par le fournisseur le plus « désespéré » ou le plus optimiste. Dans les deux cas il y aura des risques d’incompréhension de la complexité du projet et au final, d’abandon du contrat. Il faut également tenir compte que le coût pourrait être d’autant augmenté par le chiffrage des risques (pour les fournisseurs compétents), par les retards, par le manque de qualité (pour les fournisseurs moins peu scrupuleux) et par l’excès de fonctionnalités. Ce dernier point devrait protéger le client mais en définitive, cela génère des applications ayant plus de 60% de fonctionnalités rarement ou jamais utilisées (étude de Standish Group présenté à XP2002 par Jim Johnson, Président).

Le contrat Agile : l’alternative

D’après ce que j’ai pu constater, les nouveaux clients souhaitent généralement partir sur un premier projet en mode forfait, avec un périmètre et un budget fixe. Je peux comprendre la démarche, le client souhaite d’abord tester sans trop de risque son fournisseur. En revanche, vu qu’il y a déjà des risques liés à ce type de contrat, je pense qu’il est quand même préférable de partir sur une organisation Scrum, qui n’est par ailleurs pas incompatible avec l’idée du forfait.

Il y a deux idées pré-conçues concernant les méthodologies agiles :

  • Les exigences du projet ne sont pas connues avant la première itération. Ces exigences peuvent être connues suite au résultat du « Release planning » ou de la version initiale du Backlog Produit, contenant l’ensemble des exigences clarifiées et estimées. Le premier sprint peut donc commencer sans problèmes sur un périmètre défini et donc estimé.
  • Ces exigences doivent impérativement changer dans un cadre Agile. Il faut comprendre que ce cadre Agile assure l’opportunité et le mécanisme permettant d’intégrer des changements permettant de s’adapter. Ceci dit, personne n’est obligé d’utiliser ce cadre. Le contenu peut rester fixe et le cadre Agile apportera toujours des avantages comme la transparence, les retours fréquents, les lots limités, moins de gaspillage, moins de temps d’attente et de travail en cours, etc.

Le simple fait de mettre en place Scrum apporte de la flexibilité dans le cadre forfaitaire : possibilité de remplacer des exigences existantes avec des nouvelles équivalentes en termes de charge de travail et changer l’ordre d’implémentation de ces exigences.

Pour l’avoir déjà constaté, je préconise de limiter la durée de ce premier contrat forfaitaire pour éviter les dérapages assez fréquents sur la qualité. En effet, c’est la seule variable d’ajustement sur un projet où l’ensemble du périmètre et des deadline sont fixés d’avance.

La solution : enchaîner les contrats

L’une des options pour arriver à un contrat complètement synchronisé avec une organisation « gagnant – gagnant » est d’avoir un enchaînement de contrats comme nous l’explique Greg Hutchings dans son article « Contract Evolution on a Large Agile Project« . Dans l’exemple qu’il présente dans cet article, l’évolution contractuelle n’a pas été prévue dès le départ mais elle a été la conséquence de l’évolution de la relation client/fournisseur et, dans un second temps de la maturité du projet. Voici les quatre types de contrats qu’il préconise :

  • Contrat avec un prix et un périmètre fixes : il s’agit du mode traditionnel qui résulte du manque de confiance entre les deux parties. Comme je l’ai indiqué plus haut, pour limiter les risques importants, il faudrait à minima éviter de partir dans un cycle séquentiel et restreindre la durée du contrat.
  • Contrat en mode équipe dédiée par itération avec bonus / malus : ce type de contrat est réalisé en mode Agile mais avec plus de confiance, de la part du client qui accepte de passer en mode équipe dédiée (plus intéressant financièrement) mais qui veut néanmoins garder un « contrôle » en jouant sur deux paramètres : qualité des livrables et vélocité de l’équipe. Ces facteurs peuvent bonifier ou pénaliser le prix final. Je préfère nettement le premier cas mais cela peut malgré tout avoir une influence négative sur la transparence et sur certains « jeux » de l’équipe qui fera tout pour éviter les malus.
  • Contrat avec des prix fixés par unité de travail : dans ce type de contrat, le système bonus/malus est supprimé. Le client et l’équipe doivent bien intégrer la notion d’unité de travail : points relatifs associés aux cas d’utilisation. Le coût de chaque itération dépend ici du nombre de points relatifs livrés à la fin de l’itération. Greg Hutchings considère, et je suis d’accord avec lui, que ce type de contrat est idéal pour chacune des parties. Par contre, pour arriver à une bonne estimation basée sur l’unité de travail, il faut prévoir une analyse plus détaillée et un décalage de deux sprints environ par rapport au sprint d’implémentation (l’analyse et l’estimation du sprint N se fait au sprint N-2).
  • Contrat en mode équipe dédiée – plafonné par itération : ce type de contrat est bien adapté pour les phases de maintenance. Le client a un budget fixé annuellement et le périmètre est variable.

D’autres types de contrats existent également et incluent explicitement le partage des risques et/ou pertes/profits pour assurer un alignement parfait entre les objectifs des deux parties et contractualiser la philosophie « win-win ». Je reviendrai sur ces contrats dans un prochain article.

Pour terminer sur ce sujet, je suis complètement d’accord avec Craig Larman qui dit que les bons contrats sont ceux qui soutiennent la mise en place des valeurs Agile comme : la transparence, la collaboration et donc la confiance. Je considère que la confiance est l’élément clé permettant, une fois acquise, le relâchement du modèle contractuel pour assurer un des quatre principes du Manifeste Agile « La collaboration avec les clients plus que la négociation contractuelle. » et donc maximiser la valeur produite.

Sources :
  • « Practices for Scaling Lean & Agile Development », Craig Larman, Bas Vodde
  • « Agile Contracts », Mary Poppendieck

Vous avez un projet ? Confiez-le nous ! 


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *