En 20 ans, l’agilité est passée du statut de fantasme altermondialiste à celui de méthode mainstream. Les organisations de toute taille tâchent d’adapter ces principes à leur fonctionnement actuel et les usines agiles, remplaçant des centres de service partagés, fleurissent dans les grands groupes. Cette industrialisation met sur le devant de la scène des problématiques jusqu’ici éclipsées par les concepts au cœur de la méthode agile, par exemple : quel contrat passer avec une équipe agile ?

Atteindre le Graal de l’agilité au forfait

Deux grands modes de contractualisation existent en matière de prestations informatiques : la régie, où le prestataire facture au temps qu’il a passé sur le projet, et le forfait, où le prestataire s’engage sur un prix pour atteindre un résultat préalablement défini par le client.

La régie est le choix par défaut pour les équipes agiles

Le mode de contractualisation traditionnellement choisi par les clients souhaitant mettre en place une cellule agile est la régie : il semble adapté au caractère itératif et progressif des méthodes telles que SCRUM. Cependant, la régie présente un gros inconvénient : le client porte l’intégralité du risque financier (le client finance seul les éventuels retards du projet*). Indépendamment de son éthique de travail, l’intérêt du prestataire est d’atteindre le plafond du contrat.

D’où une question compréhensible et de plus en plus fréquente venant des consommateurs de prestations agiles : comment faire de l’agile au forfait ?

Contrat agile : régie ou forfait ?

Les philosophies de l’agilité et du forfait s’opposent radicalement

Le premier grand bénéfice de l’agilité repose dans sa capacité à accompagner la maturation des besoins et à intégrer des changements de périmètre, qu’ils viennent d’un changement de la demande ou de difficultés techniques non anticipées. A l’inverse, c’est la maturité manifeste d’un projet client qui permet à un prestataire de s’assurer de sa capacité à le satisfaire tout en dégageant un bénéfice, donc à s’engager sur un prix fixe pour un délai et un produit donnés.

L’agilité place au centre de son dispositif la confiance, alors que l’approche forfaitaire est contrainte par un cadre initial rigide qui pousse à la négociation, voire à des relations conflictuelles. L’intérêt du client étant ici de charger la barque et celui du prestataire de minimiser ses coûts.

Alors que l’agilité embrasse pleinement cette souplesse en réduisant au strict minimum la documentation projet, le prestataire au forfait a besoin d’un écrit pour évaluer son prix et piloter son risque financier.

En une phrase : l’agilité est adaptée en terrain inconnu et le forfait en terrain maitrisé.

Quel compromis trouver ? Un contrat hybride, cohérent avec la philosophie agile

Les méthodes agiles, lorsqu’elles sont bien mises en oeuvre, ont un autre bénéfice inestimable : celui de développer la collaboration et l’engagement de l’équipe : tout à coup tous les contributeurs se retrouvent dans le même bateau et se mettent naturellement à ramer dans le même sens. Le contrat d’une équipe agile devrait être compatible avec cette intention de solidarité. Solidarité qui pourrait être traduite financièrement par les deux propositions suivantes :

• Le client et le prestataire partagent financièrement les succès
• Le client et le prestataire assument financièrement la responsabilité d’un retard

Contrat agile : un modèle hybride entre régie et forfait ?

Il existe de nombreux modèles qui cherchent à trouver un meilleur équilibre des responsabilités. En voici un qui m’a semblé juste et parmi les plus élégants.

1 : Le projet commence par une présentation de l’ambition du projet

ex : une application de pilotage à distance de votre voiture électrique comprenant les fonctions du macro-backlog suivant : …

2 : Cette vision donne lieu à l’estimation et la négociation d’une charge et d’un montant cible

ex : 650 jours-hommes et 400 k€

3 : Cette charge est traduite, selon les contraintes projet, en un nombre de personnes et une durée

ex : Equipe de 4 personnes (constante pour simplifier) pendant 8 mois

4 : La mise en œuvre s’organise de façon agile : si le client ajoute de nouvelles fonctionnalités de taille importantes, il doit en retirer une de poids équivalent du macro-backlog ; les fonctionnalités de petite taille sont jugées négligeables et font partie du processus agile habituel

5 : A chaque fin de sprint, le client a la possibilité de clôturer le projet s’il est satisfait du résultat ou que toutes les fonctions ont été implémentées

6 : Si le client clôture en avance, le client ne paye qu’une partie du montant restant sur le contrat (ex : 33%) ainsi le client et le prestataire partagent les bénéfices (ou les économies) qui découlent de cette performance

ex : après 5 mois de travail, le client estime que le résultat est suffisant, il règle 1 mois (33% des trois mois restants) : le client économise 100 k€ (2 mois) et le prestataire gagne 50k€ de marge pure

Un contrat agile : partager les succès

7 : Si le projet n’est pas terminé à l’issue de la date convenue initialement (sans changement structurant du périmètre comme indiqué dans l’étape 4) le client paye le prestataire à un tarif réduit voir à prix coûtant (ex : 50%) ainsi les deux doivent assumer financièrement ce retard

ex : si le projet est 2 mois en retard, le prestataire n’aura facturé que 50 k€ au lieu de 100k€ par mois supplémentaires (50% des 2 mois).

Un contrat agile : être solidaire face aux échecs

Un tel dispositif contractuel tente de combiner les meilleurs aspects de la régie et du forfait :

• De la souplesse dans la définition de la solution qui peut être conçue progressivement au fur et à mesure de l’avancée du projet
• Une incentive pour le client et prestataire à être plus performants que ce qui a été évalué en début de projet et à trouver un bon équilibre valeur / coût

Ce modèle est parfois nommé « Money for Nothing, Changes for free » : money for nothing pour l’incentive et changes for free pour la souplesse dans la conception.

Sur le même sujet de convergence ou divergences d’intérêts entre clients et fournisseurs, lire « Les SSII viennent de Mars, les DSI viennent de Vénus«