Agilité et contrat forfaitaire, un mariage impossible ?
L'un des bénéfices de l'agilité, c'est la prise en compte intrinsèque du changement. Pour un projet, une entité ou une organisation, le changement, c'est tout le temps. Les besoins, la réglementation, la concurrence, les technologies, les opportunités, l'innovation... Autant de variations potentielles qui font que l'agilité est simplement adaptée à l'ère du temps.
Cependant, lorsqu'il s'agit de contractualiser un projet en mode agile entre un client et un fournisseur, ça se complique. Car dans "l'esprit" du contrat traditionnel, le changement est souvent considéré comme un manquement de l'une des parties. De plus, l'objectif juridique d'un contrat est plutôt de limiter au maximum sa propre responsabilité, tout en faisant porter le maximum du risque inhérent à tout projet sur l'autre partie.
Pour autant, le contrat forfaitaire est depuis longtemps largement plébiscité par les clients, qui y trouvent un moyen de rationaliser leurs achats et de se concentrer sur leur cœur de métier. Et aujourd'hui, la plupart des sociétés de services IT savent y répondre. Mais l'agilité devient également un mode d'organisation incontournable dans les projets. Alors, le mariage est-il impossible ? Comment intégrer simultanément ces deux besoins d'agilité et d'externalisation dans la contractualisation entre deux parties ?
[Je précise que le point de vue décrit dans ce post est celui d'un pratiquant pragmatique de l'agilité. Je ne suis pas juriste, mais informaticien et responsable de projets ! ]
[Je précise que le point de vue décrit dans ce post est celui d'un pratiquant pragmatique de l'agilité. Je ne suis pas juriste, mais informaticien et responsable de projets ! ]
Le contrat classique
Tout d'abord, revenons sur le contrat forfaitaire classique. Pour ce type de contrat, le cahier des charges initial est le premier référentiel de conformité. Un périmètre fixe, un calendrier fixe, un prix fixe, et bien souvent des pénalités en cas de non-respect de ces engagements. La validation finale d'un périmètre déterminé en amont acte de la terminaison du projet.
A ce stade, avant de parler d'agilité, il y a du travail !
En effet, cette vision rigide du contrat n'est non seulement pas compatible avec l'agilité, mais c'est tout simplement un déni des caractéristiques intrinsèques de la réalisation d'une solution IT aujourd'hui :
A ce stade, avant de parler d'agilité, il y a du travail !
En effet, cette vision rigide du contrat n'est non seulement pas compatible avec l'agilité, mais c'est tout simplement un déni des caractéristiques intrinsèques de la réalisation d'une solution IT aujourd'hui :
- le caractère continu de l'émergence des besoins de l'utilisateur, dont l'outil de travail informatique doit pouvoir s'adapter très rapidement tout en garantissant une qualité irréprochable
- le caractère exploratoire du design de cette solution, qui doit s'intégrer dans un SI de plus en plus ouvert et hétérogène
Les conséquences de cette rigidité contractuelle, voir culturelle, sont préjudiciables pour chacune des parties:
- Engagement sur la base d’hypothèses non vérifiées
- Délais ou exigences non tenables dans la réalité
- Baisse du prix (ou maintien des marges), mais baisse du niveau des ressources (juniors, stagiaires,...)
- Maintien des délais, mais amputation de la phase de test et baisse de la qualité
- Processus lourd de gestion du changement, négociations systématiques pour toutes variations
- Crispations régulières autour du thème de la non-conformité
- Au final, pertes de temps (voir d'argent) pour le client et/ou le fournisseur
Un engagement nécessaire
Pour ce qui est de la définition d'un calendrier et d'un prix fixe, on ne peut pas toujours blâmer le client. Il y parfois certaines contraintes qu'il est nécessaire de prendre en compte : une mise en service impérative avant une échéance donnée, ou un budget déterminé en amont par des instances stratégiques. On se rend compte que la principale variable d'ajustement, c'est le périmètre.
Mais là encore, un client est en droit de s'attendre à un engagement fort d'un prestataire sur la fourniture d'un contenu, d'une valeur tangible. La fourniture de certaines fonctionnalités n'est souvent pas une option pour les métiers qui doivent en bénéficier.
Le contrat agile
Soyons clair. L'agilité est née dans les années 90 au sein d'entreprises où la réalisation d'application était internalisée. La mise en oeuvre contractuelle initiale de l'agilité, c'est bien la régie.
Mais ce modèle contractuel possède de nombreuses limites. Tout d'abord, il engendre des dérives, notamment budgétaires. Ensuite, il s'adapte peu aux grands projets ou programmes, où des entités fortement cohésives doivent être mises en place et coordonnées. Enfin, il est contraignant car l'entreprise doit gérer et piloter par elle-même des compétences qui ne sont pas dans son cœur de métier.
La nécessité d'externaliser des périmètres projets complets est donc réelle, mais lorsqu'on veut le faire en agile, certains éléments sont à considérer dans la contractualisation.
L’esprit du contrat
Le contrat classique décrit principalement les responsabilités des parties et détaille le périmètre attendu de la réalisation, c'est à dire le résultat. Le client impose, le fournisseur s'engage. La séparation client / fournisseur est nette, et conduit souvent faire diverger les intérêts au cours de la prestation. Et lorsque l'on se réfère au contrat en cours de projet, c'est souvent mauvais signe...
Le contrat agile doit avant tout décrire comment les parties vont collaborer. Ce qui compte, ce n'est pas de décrire le résultat, mais de décrire la relation qui unit les parties et l'objectif de qualité. Il s'agit d'élaborer une sorte de "joint-venture" où les intérêts sont mis en commun (cf relational contact).
Dès lors, les contractants ne doivent plus se voir comme de potentiels adversaires, mais comme des partenaires, dont l'engagement est d’œuvrer pour le succès tout au long du projet.
L'intégration des 3 Contraintes - Périmètre, Coût, Calendrier
Le contrat classique implique un périmètre fixe et parfaitement détaillé au départ (le "parfaitement détaillé", c'est pour la théorie. Ceux qui répondent régulièrement à des appels d'offre me comprendront).
Même si le prix et les délais sont également fixés contractuellement, dans la course de la prestation, ce sont bien ces deux dernières contraintes qui vont devoir s'ajuster aux variations inévitables du terrain.
De plus, la fixation du périmètre au départ est une hérésie dans l'approche agile, non pas que cela soit incompatible, mais plutôt parce que ça va limiter la possibilité d'adapter ou d'améliorer la solution, fonctionnellement ou techniquement, en cours de projet.
En agile, le périmètre doit donc rester évolutif. Le détail nécessaire à l'implémentation est élaboré "just in time" de manière collaborative. Ceci ne signifie pas une absence de vision commune de la cible au moment de la contractualisation. Cette vision est même nécessaire. En revanche, le coût et le délais, réduits à la taille d'une itération, sont fixes.
Ces deux visions de la variabilité des contraintes d'un projet sont schématisées ci-dessous :
En agile donc, le périmètre évolue dans des contraintes données : coût et/ou délais. Pour autant, l'agile impose aussi certaines contraintes sur le périmètre qu'il est nécessaire de prendre en compte :
La prise en compte de ces contraintes s'effectue en amont avec l'élaboration d'une première version du Product Backlog. Cette version initiale peut être annexée au contrat. C'est sur cette base que va se prendre l'engagement. Mais sachant ce qu'est un Product Backlog (une liste priorisée d'éléments dont le détail et les critères d'acceptation sont élaborés conjointement et progressivement), deux questions se posent :
Evaluer la charge et les délais
Pour évaluer la charge et les délais, il faut que les parties s'assurent de la bonne compréhension des éléments initiaux du Product Backlog, et partagent cette compréhension. Pour se faire, 3 solutions:
L'évolutivité du périmètre (Change for Free)
Pour garantir la souplesse sur le périmètre et le respect d'une valeur majeure de l'agilité (l'adaptation au changement), il faut piloter le projet par la valeur.
Concrètement, il faut identifier dans le Backlog la partie qu'il est absolument nécessaire de produire (c'est à dire celle qui apporte la plus grande part de valeur au regard de l'investissement), et une autre partie qui peut être soumise à variation (c'est à dire moins prioritaire au sens business).
La partie fixe, c'est le donc le "Must Have". Un maximum à 80% du Backlog semble raisonnable pour cette partie fixe.
La partie variable peut être entre découpée en deux sous-partie :
Il existe plusieurs techniques agiles, que je ne décrirais pas ici, et qui nous aident à déterminer et piloter cette valeur (MoSCoW, Kano, Risk-to Value Matrix, Cost-to-Value Matrix).
Une clause du contrat doit donc expliquer ce principe d'arbitrage sur le périmètre, c'est à dire la possibilité de modifier ou d'ajouter des fonctionnalités en retirant du Backlog des éléments de complexité identique (à condition que l'élément retiré ne soit pas en cours de réalisation). Ce mécanisme, aussi appelé "trade-in / trade-out", met en avant la nécessaire obligation de s'accorder sur l'évaluation de la complexité (ou taille) des éléments du Backlog avant de contractualiser.
Le prix
Pour fixer le prix, il y a à priori deux possibilités :
Le prix fixe par point de complexité est probablement la tarification qui s'apparente le plus au forfait classique. Elle est généralement plus facilement applicable à de nombreux contextes, et permet d'entrer dans l'agilité sans faire de grande révolution contractuelle. Ci-dessous la mise en oeuvre step by step :
Le point clé de la mise en oeuvre de cette approche, c'est la visibilité! Il faut qu'elle soit suffisante à moyen terme pour anticiper sur les moyens à mettre en oeuvre. La nécessité de travailler conjointement pour maintenir et partager cette visibilité doit apparaître dans le contrat.
Opérationnellement, deux pratiques agiles nous aident à gérer cette nécessaire anticipation de l’avenir proche :
Le processus de réalisation
Le contrat agile étant fondamentalement collaboratif, il est important de décrire cette collaboration, c'est à dire la manière dont on va travailler ensemble et réaliser le produit. Si c'est du Scrum, on décrira :
Même si tout ce processus est décrit, il doit rester fondamentalement évolutif. L'équipe, en cours de projet, doit garder la liberté d'adapter le process et/ou les outils utilisés, ainsi que de faire évoluer les DoR et DoD, en collaboration avec le Product Owner.
L'acceptation et la facturation
At last but not least, les clés de paiement! En agile, il est indispensable que le process de validation se cale sur le process de livraison, c'est à dire itératif et incrémental. La facturation doit aussi suivre le même modèle.
Dès lors, on détermine un processus de validation qui avance en parallèle et au même rythme que les livraisons, mais de manière légèrement décalée. Par exemple, la fin de l'itération N valide aussi le contenu livré en itération N-1. Les éventuels défauts relevés intègrent alors les itérations suivantes.
L'arrêt anticipé (Money for nothing)
Enfin, il est possible d'introduire une clause de retrait anticipée. Avec un délai de prévenance, le client peut mettre fin au projet à la fin de n'importe quelle itération. Les parties s'accordent alors sur le paiement d'une partie du reste du périmètre, celui qui ne sera jamais livré. C'est un deal win-win :
En conclusion
Le contrat agile opère une sorte de rééquilibrage par rapport au contrat classique. Les obligations du client sont plus fortes et son degré d'implication dans la réussite du projet est plus grand.
En contrepartie, il gagne en maîtrise budgétaire, car le prestataire perd la possibilité de faire marcher la "machine à avenant" pour le moindre petit changement. Le client gagne aussi en souplesse, car il peut stopper le projet quand il le souhaite.
Au final, l'objectif est que les deux parties y gagnent : meilleure qualité (au sens de la fourniture du besoin) et une relation qui s'établit sur le long terme.
Soyons clair. L'agilité est née dans les années 90 au sein d'entreprises où la réalisation d'application était internalisée. La mise en oeuvre contractuelle initiale de l'agilité, c'est bien la régie.
Mais ce modèle contractuel possède de nombreuses limites. Tout d'abord, il engendre des dérives, notamment budgétaires. Ensuite, il s'adapte peu aux grands projets ou programmes, où des entités fortement cohésives doivent être mises en place et coordonnées. Enfin, il est contraignant car l'entreprise doit gérer et piloter par elle-même des compétences qui ne sont pas dans son cœur de métier.
La nécessité d'externaliser des périmètres projets complets est donc réelle, mais lorsqu'on veut le faire en agile, certains éléments sont à considérer dans la contractualisation.
L’esprit du contrat
Le contrat classique décrit principalement les responsabilités des parties et détaille le périmètre attendu de la réalisation, c'est à dire le résultat. Le client impose, le fournisseur s'engage. La séparation client / fournisseur est nette, et conduit souvent faire diverger les intérêts au cours de la prestation. Et lorsque l'on se réfère au contrat en cours de projet, c'est souvent mauvais signe...
Le contrat agile doit avant tout décrire comment les parties vont collaborer. Ce qui compte, ce n'est pas de décrire le résultat, mais de décrire la relation qui unit les parties et l'objectif de qualité. Il s'agit d'élaborer une sorte de "joint-venture" où les intérêts sont mis en commun (cf relational contact).
Dès lors, les contractants ne doivent plus se voir comme de potentiels adversaires, mais comme des partenaires, dont l'engagement est d’œuvrer pour le succès tout au long du projet.
L'intégration des 3 Contraintes - Périmètre, Coût, Calendrier
Le contrat classique implique un périmètre fixe et parfaitement détaillé au départ (le "parfaitement détaillé", c'est pour la théorie. Ceux qui répondent régulièrement à des appels d'offre me comprendront).
Même si le prix et les délais sont également fixés contractuellement, dans la course de la prestation, ce sont bien ces deux dernières contraintes qui vont devoir s'ajuster aux variations inévitables du terrain.
De plus, la fixation du périmètre au départ est une hérésie dans l'approche agile, non pas que cela soit incompatible, mais plutôt parce que ça va limiter la possibilité d'adapter ou d'améliorer la solution, fonctionnellement ou techniquement, en cours de projet.
En agile, le périmètre doit donc rester évolutif. Le détail nécessaire à l'implémentation est élaboré "just in time" de manière collaborative. Ceci ne signifie pas une absence de vision commune de la cible au moment de la contractualisation. Cette vision est même nécessaire. En revanche, le coût et le délais, réduits à la taille d'une itération, sont fixes.
Ces deux visions de la variabilité des contraintes d'un projet sont schématisées ci-dessous :
En agile donc, le périmètre évolue dans des contraintes données : coût et/ou délais. Pour autant, l'agile impose aussi certaines contraintes sur le périmètre qu'il est nécessaire de prendre en compte :
- il doit être découpé "verticalement", en petit morceau ayant un sens fonctionnel (User Story par exemple)
- ces morceaux doivent être évalués en termes de valeur et priorisés par le business
- un sous-ensemble de ces morceaux doit être considéré comme un minimum indispensable pour réellement parler d'apport de valeur pour le client (MVP)
La prise en compte de ces contraintes s'effectue en amont avec l'élaboration d'une première version du Product Backlog. Cette version initiale peut être annexée au contrat. C'est sur cette base que va se prendre l'engagement. Mais sachant ce qu'est un Product Backlog (une liste priorisée d'éléments dont le détail et les critères d'acceptation sont élaborés conjointement et progressivement), deux questions se posent :
- comment évaluer finement la charge et les délais de cet engagement, sans prendre de risques démesurés ?
- comment maintenir la possibilité de faire évoluer ce périmètre, sans rentrer dans un processus lourd de "change management" ?
Evaluer la charge et les délais
Pour évaluer la charge et les délais, il faut que les parties s'assurent de la bonne compréhension des éléments initiaux du Product Backlog, et partagent cette compréhension. Pour se faire, 3 solutions:
- exécuter une phase d'initialisation, dont le but est d'apprendre. Le fournisseur apprend sur les besoins métiers, et le client apprend sur la solution cible. Cela peut se faire par la réalisation d'un prototype, ou en exécutant quelques itérations préliminaires. A la fin de cette phase, les parties s'accordent sur l'évaluation de la complexité des éléments du Backlog, et en fonction d'une capacité donnée, d'un planning de release. La forme contractuelle de cette phase initiale s'apparente à de la régie forfaitée (consulting services)
- dans le cas où le fournisseur connait déjà le contexte client, il est possible de se baser sur les données historiques de ce qui a déjà été produit. L'effort portera donc sur la création collaborative du Product Backlog lui-même, tâche qu'il sera nécessaire d'accompagner (de coacher) surtout s'il s'agit d'une nouvelle approche pour le client
- enfin, si les deux premières solutions ne sont pas applicables, il est nécessaire d'élaborer des hypothèses et de les faire valider. Si le client n'est pas en mesure d'intégrer ces hypothèse dans le contrat, autant oublier l'approche agile au forfait et partir sur un bon vieux cycle ne V!
L'évolutivité du périmètre (Change for Free)
Pour garantir la souplesse sur le périmètre et le respect d'une valeur majeure de l'agilité (l'adaptation au changement), il faut piloter le projet par la valeur.
Concrètement, il faut identifier dans le Backlog la partie qu'il est absolument nécessaire de produire (c'est à dire celle qui apporte la plus grande part de valeur au regard de l'investissement), et une autre partie qui peut être soumise à variation (c'est à dire moins prioritaire au sens business).
La partie fixe, c'est le donc le "Must Have". Un maximum à 80% du Backlog semble raisonnable pour cette partie fixe.
La partie variable peut être entre découpée en deux sous-partie :
- une zone "Should Have", comportant des éléments pouvant servir d'arbitrage en cas d'ajout d'éléments plus prioritaires
- une zone "Nice to Have", qu'il sera possible de livrer uniquement si le projet est en avance ou si la complexité de certains éléments est revue à la baisse en cours de projet
Il existe plusieurs techniques agiles, que je ne décrirais pas ici, et qui nous aident à déterminer et piloter cette valeur (MoSCoW, Kano, Risk-to Value Matrix, Cost-to-Value Matrix).
Une clause du contrat doit donc expliquer ce principe d'arbitrage sur le périmètre, c'est à dire la possibilité de modifier ou d'ajouter des fonctionnalités en retirant du Backlog des éléments de complexité identique (à condition que l'élément retiré ne soit pas en cours de réalisation). Ce mécanisme, aussi appelé "trade-in / trade-out", met en avant la nécessaire obligation de s'accorder sur l'évaluation de la complexité (ou taille) des éléments du Backlog avant de contractualiser.
Le prix
Pour fixer le prix, il y a à priori deux possibilités :
- prix fixe par point de complexité
- prix fixe par itération
Le prix fixe par point de complexité est probablement la tarification qui s'apparente le plus au forfait classique. Elle est généralement plus facilement applicable à de nombreux contextes, et permet d'entrer dans l'agilité sans faire de grande révolution contractuelle. Ci-dessous la mise en oeuvre step by step :
- Les éléments du Backlog sont estimés en point relatif de complexité (typiquement des Story Point)
- On évalue pour un certain nombre d'éléments du Backlog la charge associée de développement
- On en déduit la charge moyenne de développement associée à 1 point de complexité
- On applique des ratios à cette charge de développement afin d'obtenir la charge globale pour 1 point. Les ratios concernent toutes les activités du projet (design, test, management, ...).
- Le coût du point est calculé en fonction du pourcentage de chaque activité et du profil type intervenant sur chaque activité
- Le prix total du Backlog initial est alors connu par une simple multiplication (coût du point X nombre de point X marge cible)
Le prix fixe par itération est un mode de tarification plus agile. Cela s'apparente à la mise en place d'un centre de services à base d'unité d'oeuvre (l'unité d'oeuvre est ici l'itération). L'idée est de se concentrer plus sur le produit à réaliser que sur le projet, qui ne reste jamais qu'un moyen. Une fois en place, le cadre est plus souple pour le client, qui peut faire évoluer son Backlog avec beaucoup moins de contraintes. C'est aussi plus souple pour le fournisseur, qui adapte sa capacité en fonction d'un périmètre qu'il s'engage à délivrer à chaque itération.
Le point clé de la mise en oeuvre de cette approche, c'est la visibilité! Il faut qu'elle soit suffisante à moyen terme pour anticiper sur les moyens à mettre en oeuvre. La nécessité de travailler conjointement pour maintenir et partager cette visibilité doit apparaître dans le contrat.
Opérationnellement, deux pratiques agiles nous aident à gérer cette nécessaire anticipation de l’avenir proche :
- le backlog grooming : littéralement, affinage ou toilettage du Product Backlog. Il s'agit de réunions régulières avec le Product Owner, qui ont pour objectif d'affiner le besoin à moyen terme, et de partager ou d'accroître la compréhension des éléments susceptibles d'intégrer les itérations à venir
- le rolling-wave planning : avec les résultats des sessions de grooming, le projet est planifié par vague de quelques itérations, tout en maintenant un planning plus high-level pour les releases majeures
Le processus de réalisation
Le contrat agile étant fondamentalement collaboratif, il est important de décrire cette collaboration, c'est à dire la manière dont on va travailler ensemble et réaliser le produit. Si c'est du Scrum, on décrira :
- les rôles du Product Owner, du ScrumMaster et de l'Equipe
- les cérémonies régulières, leur déroulement, leur objectif et les personnes attendues (Daily Standup, Sprint Planning, Sprint Review, Sprint Restrospective). Il est notamment important de parfaitement décrire les attendus de la part Product Owner (en termes de clarifications fonctionnelles) et du ScrumMaster (en termes d'accompagnement et de facilitation)
- les artefacts de pilotage et de status report, que sont le Product Backlog, le Sprint Backlog, le Scrum Board, ainsi que les différents outils de monitoring (Sprint Burndown Chart, Project Burnup Chart, Release Planning)
- Les livrables en entrée d'itération (User Stories + Critères d'acceptation) et en sortie (Incrément Potentiellement Déployable) répondant aux check-lists associées (Definition of Ready et Definition of Done)
Même si tout ce processus est décrit, il doit rester fondamentalement évolutif. L'équipe, en cours de projet, doit garder la liberté d'adapter le process et/ou les outils utilisés, ainsi que de faire évoluer les DoR et DoD, en collaboration avec le Product Owner.
L'acceptation et la facturation
At last but not least, les clés de paiement! En agile, il est indispensable que le process de validation se cale sur le process de livraison, c'est à dire itératif et incrémental. La facturation doit aussi suivre le même modèle.
- La recette incrémentale
Dès lors, on détermine un processus de validation qui avance en parallèle et au même rythme que les livraisons, mais de manière légèrement décalée. Par exemple, la fin de l'itération N valide aussi le contenu livré en itération N-1. Les éventuels défauts relevés intègrent alors les itérations suivantes.
- La facturation à l'itération
- 80% du montant du contrat est payé durant le cycle des itérations et 20% en fin de VSR ou de garantie
- Ces 80% sont divisés par le nombre d'itération (exemple avec 8 itérations, soit 10% payé à chaque itération)
- Chaque jalon de paiement est validé si 80% de la valeur livrable cumulée est effectivement validée par le client (exemple pour un Backlog de 80 Story Point livrable en 8 itérations, 17 Story Point validés à la deuxième itération représente 85% de la valeur livrable à date, la clé de paiement est validée et la facturation est déclenchée).
L'arrêt anticipé (Money for nothing)
Enfin, il est possible d'introduire une clause de retrait anticipée. Avec un délai de prévenance, le client peut mettre fin au projet à la fin de n'importe quelle itération. Les parties s'accordent alors sur le paiement d'une partie du reste du périmètre, celui qui ne sera jamais livré. C'est un deal win-win :
- Le client est gagnant car il économise du budget
- Le fournisseur est gagnant, car même si son chiffre d'affaire diminue, sa marge augmente
En conclusion
Le contrat agile opère une sorte de rééquilibrage par rapport au contrat classique. Les obligations du client sont plus fortes et son degré d'implication dans la réussite du projet est plus grand.
En contrepartie, il gagne en maîtrise budgétaire, car le prestataire perd la possibilité de faire marcher la "machine à avenant" pour le moindre petit changement. Le client gagne aussi en souplesse, car il peut stopper le projet quand il le souhaite.
Au final, l'objectif est que les deux parties y gagnent : meilleure qualité (au sens de la fourniture du besoin) et une relation qui s'établit sur le long terme.
Commentaires
Enregistrer un commentaire