Contractualisation Agile

Certains pensent qu'il est impossible de concevoir un bon contrat agile au-delà de la simple mise à disposition de moyens, et que tout mécanisme plus complexe priverait des bénéfices d'une démarche Agile bien comprise, voire serait amoral. Explorons aujourd'hui cette question, pour essayer d'aller au-delà d'un constat à mon goût trop limitatif et envisager des formes contractuelles nouvelles qui pourraient s'adapter à des environnements culturels, relationnels et applicatifs variés.

Contrat et gestion de risque

Tout d'abord, voyons quel est l'objet d'un contrat. Il vise à gérer les relations entre un client et un fournisseur, et en particulier à réguler les risques du projet en définissant qui est en charge de chaque type de risque. Or sur un projet informatique visant à produire ou faire évoluer une application, les risques sont de deux natures:

Traditionnellement, un contrat de forfait en cascade reporte sur le client la gestion du risque sur le besoin et sur le fournisseur celle du risque technique. Ainsi chacun recevant la gestion du risque qu'il maîtrise le mieux est à même de mettre en place les mécanismes de prévention de ce risque - et cela fonctionne bien ainsi dans les projets en cascade "qui marchent". On constate cependant des dérives, le fournisseur essayant de transférer une partie de son risque au client, et réciproquement. En fait, il se trouve que le risque sur le besoin est le plus souvent le plus grand: il est en général plus difficile de savoir quoi faire pour faire bien que de bien faire une fois que l'on sait quoi. Devant un risque difficile à gérer, le client est souvent tenté de reporter une partie du risque sur le besoin sur son fournisseur - et un fournisseur avisé essaye en général d'avoir une certaine marge pour accepter une partie de ce risque sans douleur.

Dans une démarche Agile, on va recherche autour de la construction d'un produit logiciel les vertus suivantes:

• flexibilité
• réactivité
• visibilité
• exploration

Mais en revanche, cette démarche se déploiera mieux si on a les conditions suivantes présentes:

• collaboration
• confiance
• communication
• implication

On remarque que le système peut être vertueux, au sens où la visibilité et la flexibilité, par exemple, contribuent à créer la confiance, qui renforce à son tour la visibilité. A l'inverse, le système peut dériver dans une spirale vicieuse si l'on n'y prend garde (défiance => moins d’ouverture => manque de visibilité => plus de défiance...), et le contrat est un des instruments qui permet ou empêche de se maintenir dans une spirale vertueuse.

Engagement de moyen

La première forme de contrat que nous pratiquons chez OCTO est la mise à disposition d'une équipe, dispositif de construction d'un produit logiciel, formée d'un certain nombre de profils et compétences complémentaires : développeurs, architectes, analystes, ergonomes, coach... Dans un dispositif mixte, certaines des personnes peuvent être de l'entreprise client, ou d’une entreprise tierce. OCTO apporte:

• une démarche itérative, incrémentale et pilotée par les tests, contribuant à la sécurisation de la construction du logiciel dans la durée et à la visibilité sur cette construction;
• des livrables fournissant la visibilité (dossier de cadrage 360, burn down chart, backlog visuel, kanban...) et permettant également la réversibilité du contrat.

Cette mise à disposition en contrat de type engagement de moyen peut sembler favoriser le fournisseur, qui n'assume en apparence que peu de risque. Certes, mais le risque pour le client est de durée très limitée par rapport à un forfait classique: de une à trois semaines, la durée d'une itération, voire moins si le suivi est journalier, contre plusieurs mois (voire plus...) pour un forfait en cascade. Risque en apparence plus important, mais très limité dans le temps, contre une sécurité apparente apportée par l'engagement forfaitaire, mais plus difficile à mesurer avant échéance et souvent mise en brèche, et encore plus sur les projets de grande taille, je choisis vite!

OCTO Technology utilise cette forme très couramment, que ce soit sur des projets encadrés par nos consultants (avec des développeurs client ou tiers) ou des projets 100% OCTO - en fait c'est le format de la majorité de nos projets Agile actuels. Ce type de contrat permet une flexibilité maximale sur le pilotage du projet et s’avère à l’usage simple à gérer pour l'ensemble des acteurs. C'est pour cela qu'il est le premier envisagé. Cependant, certains contextes culturels rendent l'absence d'engagement forfaitaire difficile à accepter. On peut alors envisager des formes contractuelles plus « engageantes », tout en évitant qu'elles soient un obstacle à la flexibilité et la collaboration recherchées.

Vers un forfait sur une métrique

Une deuxième forme de contrat consiste à utiliser une métrique sur la production de logiciel, par exemple le point de complexité ou la fonctionnalité unitaire. Cela nécessite:

• de démarrer le projet par un cadrage afin de cerner le macro-besoin et les points structurants;
• d'amorcer ensuite une période de "rodage" de l'équipe pendant laquelle on mesure la vélocité effective;
• et ensuite de rentrer dans une phase forfaitaire, à partir d'un backlog priorisé, sur une durée limitée (2 à 4 mois).

A partir du backlog, le fournisseur construit le produit, itération par itération. Le client peut changer l'ordre des fonctions élémentaires non développées, et en ajouter tout en restant dans le même volume global, évalué selon une métrique partagé (points de complexité ou autre).

Cette forme de contrat présente l'inconvénient d'attacher une incitation financière à un outil de mesure qui est par ailleurs utile pour améliorer la productivité de l'équipe. On peut ainsi craindre de nuire à la fiabilité de la mesure en y attachant d'autres enjeux, et donc à son efficacité en tant qu'outil d'amélioration continue. Cependant, dans un contexte où ce risque est assumé et où on arrive à créer un climat de confiance suffisant (nécessaire au bon déroulement de tout projet, Agile ou pas!), dans la mesure aussi où les incertitudes techniques sont modérées, cette forme contractuelle peut être utilisée à bon escient et aider à l'adoption d'une démarche Agile dans un contexte culturellement attaché au forfait.

Sur un des projets de CMS chez un client OCTO Technology, la partie forfaitaire se fait sur un rythme de 3 mois. Un montant forfaitaire est proposé après construction du backlog. Le contenu du backlog peut évoluer tant que l'on reste dans une complexité équivalente. 90% du forfait est facturé à l'avancement. La portion restante de 10% est retenue jusqu'à ce que soit constatée la satisfaction des trois critères suivants:

• achèvement du backlog du trimestre,
• capacité à mettre le système en production,
• satisfaction des utilisateurs.

Jusqu'à ce jour, la démarche donne satisfaction et un climat de confiance a été construit avec notre client.

Un signe que votre contrat dérive? Votre métrique est l'homme-jour et / ou vous négociez le poids de chaque nouvelle fonctionnalité. ( "Tu me la fais à 10, celle-là, pas comme l'autre la semaine dernière!")

Target cost

Une autre forme de contrat, plus contraignante mais plus engageante, est ce qu'on appelle le target cost ou target delay. En target cost, le fournisseur s'engage à construire un produit logiciel sur une intention: une démonstration de nouvel extranet pour un salon, une nouvelle application iPhone, un remplacement d'un outil de prise de commande... pour un budget donné (et en général un délai plus ou moins ferme associé). L'intention n'est pas nécessairement déclinée en fonctions très précises, mais on a pu construire un premier backlog, éventuellement une story map ou un mindmap.

Ce backlog est évalué et donne alors un budget nominal sous une forme :

Volume de l’effort nominal x (coût de l'effort pour le fournisseur + marge du fournisseur)

La marge cible du fournisseur est celle correspondant au volume de l'effort nominal. Le contrat de target cost peut alors être considéré comme ayant un montant fixe, comme dans un contrat de forfait classique, ou alors rajouter une possibilité d’ajustement du montant payé comme suit:

• Si le produit logiciel satisfait le client pour le budget nominal, tout va bien, le fournisseur reçoit le budget nominal.
• Si l'objectif est atteint pour un effort moindre, le fournisseur reçoit toujours la marge nominale, mais seulement le coût de l'effort pour le consommé effectif.
• Si le volume d'effort est plus important, le fournisseur reçoit la marge nominale, mais seulement le coût de l'effort pour chaque unité d'effort supplémentaire.

Clarifions un peu ceci : supposons une version d’un applicatif dont l’effort de développement est évalué à 200 h.j, pour un coût de 10 Ecus/h.j et une marge cible de 20% (unité monétaire et marge complètement fantaisistes). Le budget nominal est donc de (10+20%) x 200 = 2400 Ecus. Le fournisseur recevra donc :

• 2400 Ecus pour une version livrée en effort nominal ;
• 1900 Ecus = 10 x 150 + 10 x 20% x 200 si le projet est terminé pour un effort de 150 h.j ;
• 3400 Ecus = 10 x 300 + 10 x 20% x 200 si le projet dépasse en charge et est livré pour un effort de 300 h.j.

Selon le cas, le fournisseur réalisera une marge de 20%, 26,7% (= 1900 / 1500) ou 13,3% (= 3400 / 3000). Ainsi:

• le fournisseur est motivé pour terminer à budget nominal ou plus faible pour maximiser sa marge par unité d'effort;
• le client est motivé pour terminer à budget nominal ou plus faible pour minimiser le coût global.

Le système est effectivement vertueux si d'autres motivations que simplement économiques aident à la tenue du budget, par exemple une volonté commune de produire le logiciel pour la date annoncée. Il peut se retourner contre le client ou le fournisseur si l'autre partie n'a qu'une motivation faible pour tenir l'engagement.

Le mécanisme d'un target delay est similaire, sauf que c'est le délai qui est ici considéré, souvent couplé avec le coût. Un contrat de ce type a été utilisé pour la construction de la plate-forme Web Babyloan, site Internet de micro-crédit solidaire. Le cahier des charges tenait sur 7 lignes de Français courant, plus un mindmap (raisonnable) en format A4.

Partage de profit

Enfin, une dernière forme contractuelle (pour aujourd'hui) peut être envisagée sous la forme d'un partage de bénéfices. Si le produit logiciel enrichi ou développé concourt suffisamment directement au chiffre d'affaire ou à la marge du client, une mesure en Euros peut être associée à la performance du logiciel réalisé. Le fournisseur reçoit alors un pourcentage de cette mesure comme paiement de sa contribution. Ce mécanisme peut être complété par une part fixe, une part liée à l'effort... mais on conserve un lien direct entre performance du produit et retour financier pour le client. On voit que ce mécanisme peut être vertueux et permettre un climat réellement collaboratif, là encore spécialement dans un climat de confiance établi et entretenu. Il peut aussi donner lieu à des dérives, en particulier si trop d'autres facteurs ont une influence sur la performance financière liée au produit logiciel et que l'influence du fournisseur n'est que très mince.

Ces deux dernières formes de forfaits agiles partagent les risques différemment: on voit que le client assume une partie du risque technique, mais aussi que le fournisseur assure également une partie du risque sur le besoin. L'échange peut sembler intéressant au client dans la mesure où ce dernier risque est le plus souvent le plus important. Il est également vertueux dans la mesure où les risques sont clairement partagés et où les deux acteurs peuvent aider à la gestion des deux types de risque. Ces deux formes de forfaits ne peuvent cependant fonctionner que si le fournisseur a des moyens de gérer les risques sur le besoin.

En conclusion

On voit donc qu'il existe des formes de contrat au forfait qui permettent de conserver au moins certains des avantages d'une démarche agile, tout en engageant plus fortement le fournisseur et le client. Je pense qu'il faut néanmoins agir avec vigilance et se poser en premier lieu la question sur les vertus recherchées, la nature des principaux risques et les contraintes de l'environnement, en particulier culturelles. Il convient également de garder en mémoire les fondamentaux d'une bonne démarche agile que sont la construction collaborative de la trajectoire et de l'architecture, la démarche itérative, incrémentale pilotée par les tests et le souci de la visibilité et de la transparence. Muni de ces éléments et tout en essayant de ne pas faire plus compliqué que nécessaire, nous pouvons dans chaque contexte envisager une contractualisation qui mène à une relation client / fournisseur saine et constructive.