Contrat au forfait et démarche agile

Une discussion récente avec un acheteur d'une grande administration m'a conforté dans l'idée que le contrat au forfait n'est pas un obstacle à l'introduction de l'agilité. Au contraire, l'agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.

Voici un petit résumé des quelques idées que je lui ai présentées, reprises de ma contribution au livre de Véronique Rota :

Le client est celui qui demande une solution informatique à un problème et le fournisseur celui qui développe la solution. La contractualisation des relations entre le client et le fournisseur n'est pas considérée comme essentielle. Elle n'est même recommandée par les méthodes Agiles : le Manifeste Agile rappelle qu'une bonne collaboration est plus importante qu'un contrat. Cependant, les directions juridiques et financières, en rationalisant les achats de prestations, imposent bien souvent un contrat à prix fixé aux fournisseurs. Pour elles, il est impératif d'avoir une enveloppe budgétaire définie à l'avance et un cadre pour se protéger contre les aléas. Comment un client, qui est déjà convaincu des bienfaits de l'agilité, peut-il élaborer un appel d'offres et sélectionner un fournisseur pour un contrat au forfait dans ce contexte ?

Le périmètre est la variable d'ajustement

A ce client prêt à effectuer la transition vers l'agilité, je conseille d'élaborer un appel d'offres Agile (AOA), dans lequel c'est un processus de développement agile qui est préconisé aux fournisseurs (par exemple Scrum, qui est le plus simple à mettre en oeuvre). Le budget et le délai, au lieu d'être demandés aux fournisseurs, sont fixés par le client et annoncés dans l'AOA. Le plus souvent le client est bien incapable de donner ses exigences précises, il exprime simplement des souhaits, au mieux une vision qu'il a du produit futur. Partant de ce principe qu'il est impossible de définir le périmètre fonctionnel à l'avance, le client fournit simplement sa vision du projet dans l'AOA. Le périmètre deviendra la variable d'ajustement.

Sélection sur les compétences

La sélection du fournisseur est faite sur la qualité de la réponse, la pertinence du processus (agile) proposé et sur les compétences de l'équipe pressentie. Le changement par rapport à la pratique d'évaluation actuelle des réponses à appel d'offres est que le prix n'est pas considéré, puisque c'est le client qui le fixe. Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés. Mais c'est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu'il impose une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable. Avec un CFA, l'objectif du client n'est plus de reporter les risques sur le fournisseur, il devient de collaborer avec lui pour obtenir le meilleur produit dans le délai défini.

Point de vue du client

Les clauses du contrat sont adaptées à l'agilité. Voici quelques exemples de ce qu'il est possible d'y introduire, pour le bénéfice du client :

  • le client doit recevoir un produit partiel, mais fonctionnel, à la fin de chaque itération : il peut ainsi fournir un feed-back rapide ;
  • le client peut arrêter le contrat à la fin de chaque itération (en contrepartie d'une indemnité fonction du temps passé pour le fournisseur ) : il peut ainsi stopper à temps un projet voué à l'échec ;
  • le client définit les priorités : le fait de développer les fonctionnalités à forte valeur ajoutée en premier permet de lever les risques tôt (risques techniques, bien sûr mais surtout risques de livrer un produit en inadéquation avec les attentes) ;
  • le client peut changer d'avis sur le contenu fonctionnel (sur les parties qui n'ont pas encore commencé), à condition que ce qu'il ajoute au backlog (terme Scrum pour désigner la liste des choses qui apportent de la valeur au client et qui sont à faire par le fournisseur) soit contrebalancé par ce qu'il y retire.

Point de vue du fournisseur

Du point de vue du prestataire titulaire d'un contrat avec un client qui a remporté l'appel d'offres :

  • si c'est dans un cadre agile (réponse à AOA puis CFA), c'est évidemment plus simple puisque le client est déjà convaincu de l'intérêt de l'agilité. Je suggère au fournisseur d’annexer le backlog dans le contrat. Ce backlog est élaboré soit par le client lors de l’AOA, s’il a déjà une idée précise de ce qu’il veut, soit conjointement par le prestataire et le client, lors d’une première phase de recueil des besoins (appelée Sprint 0 dans Scrum). En associant à chaque élément du backlog une estimation en points, le dialogue avec le client sur les évolutions du périmètre fonctionnel et les négociations éventuelles sera grandement facilité.
  • si c'est dans le cadre d'un forfait classique, l'agilité du fournisseur est limitée par le contrat. Le fournisseur peut néanmoins introduire des pratiques agiles (livraisons fréquentes avec des itérations courtes pour commencer), essayer de collaborer au maximum avec le client, le sensibiliser à l'idée des tests qui pilotent le développement (TDD) et le convaincre de passer au forfait Agile pour le prochain appel d'offres.

Le fait de montrer rapidement au client le résultat des itérations et de l’impliquer dans les réunions de planification favorise sa confiance et le met ainsi dans de meilleures dispositions, l'incitant à s'impliquer davantage.

Commentaires

1. Le mercredi 16 avril 2008, 22:04 par Eric

Bonjour,

En tant que fournisseur, lorsque je présente une méthodologie agile en réponse à un forfait, on m'oppose bien souvent le respect du périmètre initial en regard de ce que représentent les spécifications fonctionnelles détaillées dans des méthodes traditionnelles.
Les spécifications détaillées sont en effet annexées au contrat et sont la référence en cas de conflit.
Que peut-il en être du backlog produit ? En effet, lors du sprint 0 nous réalisons un (premier) recueil des besoins, duquel nous tirons le backlog produit. Mais, le principe même de Scrum et des méthodes agiles est d'obtenir des retours du client après chaque itération, afin que celui-ci réajuste son expression du besoin ou la compréhension de cette dernière par l'équipe.
Le backlog peut donc évoluer assez nettement au fil du projet. Quel est alors l'intérêt de l'annexer au contrat dans le sens où il ne reflètera forcément pas le produit livré au moment du conflit ?

2. Le jeudi 17 avril 2008, 08:14 par Fabrice

Oui j'ai eu le même problème, mais il faut bien expliquer que cette annexe est le point de départ du projet et pas la référence comme dans un forfait classique, car cette référence évolue à chaque backlog !
Le suivi des exigences est extrêmement important, il faut vraiment assurer une bonne traçabilité pour pouvoir tenir face aux vieilles habitudes, et le changement de périmètre est décidé par le client lui même donc pas de polémiques possibles, si il n'y a pas de décision du client alors on reste sur le périmètre initial qui est en annexe.
Le gros problème est que sur les premiers forfaits agiles il y a beaucoup plus de charges de suivi de projet, gestion des tests et aussi de cout de licences pour les outils de suivi qui sont peut être plus couteux que sur un projet classique, ce qui ne favorise pas la diffusion des forfaits agiles. Car il ne faut pas de leurrer, le client lors des premières expériences, a souvent le réflexe de revenir aux anciennes habitudes lors des premiers conflits.

3. Le mardi 22 avril 2008, 09:24 par jc-Qualitystreet.fr

Le point de vue de Xebia sur la question:
www.tv4it.net/permalink/4...

J'ai rencontré Guillaume Bodet mercredi dernier. On a bu des bières au Nemours en discutant d'agilité et de forfait. Je pense qu'on a à peu près le même point de vue sur le sujet. JC, pour une bière, c'est ma dernière semaine à Paris... Claude