Pour les agences web, le contrat au forfait est encore de nos jours le modèle le plus utilisé. Et pourtant, nombreuses sont les agences qui revendiquent une utilisation poussée des méthodes Agile. Le forfait est une offre commerciale construite sur un périmètre fermé, la méthode de production Agile autorise le changement.
N’y a-t-il pas là un paradoxe ?
De par sa nature le forfait impose un fonctionnement en complet désaccord avec les méthodologies agiles :
Le projet au forfait nécessite la rédaction d’un cahier des charges complet et exhaustif, une évaluation détaillée du budget et la construction du projet basée sur un périmètre fixé à l’avance.
Les méthodes agiles valorisent l’expérimentation via des itérations courtes et rapidement mises en application. Leur fondement est basé sur un constat simple : il est très rare qu’un projet informatique soit pensé de A à Z en amont, et quand bien même lorsque cela est le cas, les spécifications fixées d’avance auront tendance à figer le projet dans une perspective valable à un instant T, présentant le risque d’une obsolescence de ce périmètre (tout ou partie) lors de la mise en production de l’application.
Peut-on associer le périmètre fixe avec les méthodes agiles qui élèvent la notion de changement comme avantage concurrentiel ?
Une petite recherche sur internet vous montrera que le débat n’est pas nouveau, qu’il est toujours aussi passionné et rares sont ceux qui proposent une solution faisant l’unanimité. Sont confrontés des intérêts divergents : d’un coté le développeur qui cherche sa liberté, de l’autre le commanditaire qui cherche l’assurance d’un résultat pour un prix donné et comparable.
La réalité du contrat au forfait n’est pourtant pas toujours très saine. Si les choses se passent souvent bien, certaines statistiques montrent que beaucoup de projets échouent. Selon le Standish Group (étude de 2009) : en moyenne, 38% des projets informatiques atteignent leurs objectifs initiaux. 33% aboutissent à un échec et 29% sont purement et simplement abandonnés.
Une interview intéressante de Damien Chevalier, parue sur Viadeo, expose assez bien les problématiques rencontrées dans les projets informatiques.
La rédaction d’un cahier des charges, l’évaluation détaillée du budget, les phases de validation, la production en suivant le plan directeur, aboutissent souvent à des négociations sur les modifications, négociations sur les retards et des livraisons douloureuses pour tous les acteurs du projet.
Alors … peut-on imaginer un process Win/Win ? Où tous les acteurs seraient heureux et gagnants ? Pourquoi s’obstine-t-on à nous imposer un modèle qui nous vient tout droit du BTP ? Des bâtisseurs de cathédrale ? Non que ce modèle soit mauvais en soi dans le contexte du BTP, mais simplement qu’il n’est plus tout à fait adapté à l’univers du numérique. Nous en sommes tous conscients et pourtant … le contrat forfaitaire est encore et toujours là.
Créer un logiciel, refondre un site internet, inventer un service cloud, n’est pas une opération simplement quantifiable sur la seule base du cahier des charges, lui-même jamais totalement juste, détaillé et fermé.
Contrairement à un immeuble, les produits numériques ne sont pas fixés sur une base immuable pour quelques centaines d’années. Leur socle est un océan flexible, mouvant, évoluant, grandissant, augmentant … alors, pourquoi ignorer délibérément cette force intrinsèquement changeante ? Imagine-t-on qu’un projet numérique soit immuable avant, pendant et après sa construction ?
Abandonner des features inutiles en cours de route, les remplacer par de nouvelles ayant une plus forte valeur ajoutée et qui n’étaient pas identifiées lors de la rédaction du cahier des charges ... est-ce possible dans le cadre d’un contrat ?
Le contrat forfaitaire oblige le prestataire à une gymnastique délicate pour intégrer le conseil et la réflexion commune qui émergent nécessairement pendant la production. Et ce jeu d’avenants et de négociations est une véritable perte de temps et d’énergie pour toutes les parties. Ne serait-ce pas plus intéressant de garder le focus sur le projet ?
On parle aujourd’hui de Time To Market, on le répète partout, il faut aller vite et bien, et il faut s’adapter constamment. Il faut se tromper, vite, pour s’améliorer rapidement. Alors, acceptons l’impossibilité de tout prévoir d’avance, acceptons le changement.
Les questions récurrentes :
Quand j’en parle autour de moi, en mettant en doute le bien-fondé du contrat forfaitaire, on me pose toujours la même question : oui, mais mon budget ? Comment je le détermine ? Il me faut un devis ! Il me faut un planning !
Le planning, parlons-en ! Dans le concret cela ressemble à ça (comme le dirait San Antonio dans “les vacances de Bérrurier” : “Mettons-nous bien d'accord, mes drôles : ces personnages et cette compagnie sont fictifs absolument ! Ils n'existent pas, n'ont jamais existé, ne se permettront jamais d'exister. Et c'est bien dommage !”) :
- 2 mois pour rédiger un cahier des charges, le relire et le faire valider par la direction
- 1 mois pour consulter les agences, recevoir les devis et sélectionner le héros
- 2 mois pour concevoir l’UX et les maquettes graphiques, les faire valider par les résponsables des marques, les corriger, les refaire valider, etc.
- “il faudrait accélérer maintenant”
- 1 à 2 mois pour les développements
- 1 mois pour la mise en prod, les tests, les corrections, les optimisations, l’import et la saisie des contenus, etc.
- “Nous ne sommes pas contents, nous organisons un comité de pilotage, le site doit être en ligne”
- 1 mois pour la recette finale et le règlement des dernières prestations (ajouts et modifications ayant eu lieu pendant la production, lors des fameuses coding nights)
Ce scénario fait rêver ? Il est pourtant très réel et trop fréquent.
Et quelle en est la conclusion ? Le client est déçu parce que son “time to market” est raté. Son benchmark réalisé en amont (vieux de 8 mois) est obsolète : sa concurrence l’a rattrapé, voir devancé. Et le prestataire ? Pas content aussi. Il y a laissé des plumes, il a grignoté sa marge, ses équipes sont épuisées et ne veulent plus entendre parler des retours du client (alors même que ces retours sont enfin constructifs et prometteurs d’améliorations). De longs mois pour la construction d’un projet qui aura une durée de vie de combien ? 3 ans ? 5 ans en tirant vraiment dessus …
Pour une maison le rapport n’est pas le même … un an (voir 2) de construction pour un bâtiment qui sera transmis à nos enfants et nos petits-enfants nous semble plutôt acceptable.
Alors quelles sont les alternatives ?
Pour le budget, oui … nous sommes bien d’accord : il est difficile de démarrer un projet sans élaborer un budget, surtout chez les grands comptes.
Mais ne faudrait-il pas simplement déterminer un budget global, sans nécessairement entrer dans les détails ? Dire, par exemple, “cette année je peux investir 40 k€” … que fait-on avec ? Voilà déjà une bonne base, saine. On peut faire beaucoup de choses avec ce budget ! Pas tout, certes, mais c’est déjà un bon départ.
Une agence Agile pourra notamment répondre : “avec 40 k€, je peux vous proposer un premier lot comprenant une maquette graphique et 5 sprints avec une équipe de 2 développeurs … ça va être un super projet ! A nous (vous et nous) de remplir ces sprints avec tout ce qu’il vous faudra … et le reste, on verra l’année prochaine non ?
En 3 mois de travail, la première release de votre site sera en ligne”.
La voilà notre alternative : 3 mois vs 8 mois ! Une équipe hyper motivée, des échanges quotidiens, un projet qui va vite, des décisions prises au fil des développements, des bières échangées et plein de bonne humeur … et surtout une vraie fierté de voir émerger du néant un magnifique projet.
Comparons plus en détail le budget au forfait par rapport à un budget découpé par lots :
Avant tout, notez : plus un projet avance, moins la valeur ajoutée est forte et perceptible. Le début de projet est le moment où la valeur créée est la plus forte.
À gauche, le graphique vous montre comment se passe un projet dont le budget est fixé au départ, le forfait. Dans la plupart des cas, la valeur ajoutée en fin de projet, celle qui est souvent peu perceptible, va en réalité grignoter la marge réalisée par l’équipe de production. L’effet néfaste étant que cette équipe de production va automatiquement perdre sa motivation et risque même de faire baisser totalement la priorité de votre projet au profit d’un autre. C’est le moment où vous demandez de changer une virgule et que ce changement prend 3 mois à être fait.
À droite, nous avons le même projet mais, cette fois, nous découpons le budget en lots. Plus le projet avance, plus les lots sont petits. Mais comme ils correspondent toujours à la réalité de ce qui est construit, vous conservez une équipe motivée et impliquée dans votre projet.
Ha! Oui, vous allez me répondre : le budget par lots est supérieur ! Non, il est réaliste.
Il faut également préciser : les deux graphiques sont basés sur un périmètre projet constant. La réalité du graphique de gauche est qu’il peut y avoir des avenants, et donc un budget en évolution. La réalité du graphique de droite est que le périmètre des lots 2, 3 et 4 est ajusté en cours de route, par conséquent le périmètre s’adapte naturellement aux besoins.
Graphique inspiré par : http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-forfait/
Et le cahier des charges ?
Il existe ! Il s’appelle désormais Backlog, et il est construit conjointement par le client et l’équipe. De plus, il est ouvert et autorise tous les changements possibles en cours de route. L’objectif est fixé, c’est le chemin pour atteindre cet objectif qui est évolutif, qui permet quelques détours et raccourcis, selon les besoins du moment.
Oui, mais il y a des risques ?
Ne nous voilons pas la face : tout projet impose une responsabilité partagée.
Les deux causes les plus fréquentes de l’échec de certains projets sont d’une part une mauvaise gestion de projet et la non-considération des besoins réels du client et d’autre part l’incompétence et le manque de maturité du commanditaire (voir les chiffres du Chaos Manifesto 2013 - édité par le Standish Group (https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf).
Effectivement, si d’un côté nous avons une équipe expérimentée et un chef de projet héroïque et de l’autre un commanditaire qui ne s’occupe de rien et contredit tout … ça sera compliqué. La réciproque est également vraie.
Il s’agit donc de rassembler 2 partenaires compétents. On ne demande pas d’avoir une maîtrise commune des processus métiers, mais un certain degré de maturité et une équipe dédiée, côté commanditaire et côté prestataire. Savoir être à l’écoute des besoins comme des recommandations est devenu aujourd’hui un pré-requis nécessaire, de même que l’engagement du commanditaire à un niveau de responsabilité au moins égal à celui du prestataire nous semble primordial.
La flexibilité apportée par les méthodes agiles est également intéressante pour le commanditaire : le fait de travailler par incréments et par livraisons successives garantit automatiquement une meilleure visibilité sur l’avancée des travaux, sur l’orientation prise par le projet et sur les compétences réelles de l’équipe. Le budget est débloqué au fur et à mesure des livraisons. Si le client s'aperçoit que l’équipe ne tourne pas et que la bière n’est pas fraîche, il peut tout arrêter. Prendre son dépôt GIT et passer à une autre équipe en ayant juste “perdu” les quelques milliers d’euros des premiers sprints (pas vraiment perdu d’ailleurs, puisqu’il y aura quand même les premiers lots qui auront été réalisés). Et encore ! ce scénario “catastrophe” ne peut en soit pas réellement exister : Le client voit le prestataire régulièrement, le suit de prêt. Il faudrait y mettre une réelle mauvaise volonté pour ne pas s’apercevoir rapidement de l’incompétence de l’équipe et pour ne pas tenter de résoudre vite les problèmes. Souvenez-vous : se tromper rapidement, corriger rapidement !
Ok, mais je fais comment avec ma direction ?
On les forme ! on leur explique ! on les coach ! ils participent au projet, ce sont nos Stackholders ! Et pour eux on range la bière et on sort le champagne ;-)
Pour le DAF on peut trouver un intermédiaire entre forfait et régie : une approche budgétaire globale découpée en plusieurs lots, un budget ferme pour le premier lot, celui qui est connu et maîtrisé. Par la suite, le budget sera affiné en même temps que le product backlog. À ce propos, la méthode Scrum est une bonne méthode puisqu’elle intègre une notion de Backlog qui remplace en quelque sorte le cahier des charges et permet par conséquent de faire de vraies estimations de budget.
Si nous avançons en suivant une méthode de travail incrémentielle, le budget devrait suivre cette même logique et s’aligner sur les incréments (sprint ou release). Ainsi, nous ne sommes pas en mode “Régie” : ce n’est pas le temps passé par l’équipe qui est financé mais bien l’incrément qui contient un objectif fixe. Nous ne sommes pas non plus tout à fait en mode forfait : le budget global reste ajustable et suivre les modifications de périmètres, seul le budget du lot en cours est fixé et l’équipe s’engage à le respecter.
En conclusion, tout prestataire et tout commanditaire souhaite engager un projet gagnant / gagnant dès son lancement. Maintenir cette bonne relation de partenariat demande un certain équilibre qui se trouve au juste milieu du Forfait et de la Régie. Certains parlent de forfait régitisé ou de régie forfaitisé … un mélange pas toujours évident ni simple à comprendre. Chez Blackbird nous préférons parler de forfaits évolutifs, par lots. L’avenant et la modification budgétaire sont des réalités auxquelles il faut être prêt à s’engager pour avoir un produit adapté aux attentes et aux évolutions de ces attentes.
Au final, on pourrait dire qu’un contrat au forfait incrémental serait la solution ;-)
Je vous invite à lire :
Pourquoi un projet Agile ne pourra jamais être vendu au forfait ?
La référence étymologique à Forfait : “se faire du mal” est assez amusante. Le point de vue est radical mais apporte de vrais arguments en faveur du système “Régie”. Néanmoins, le contrat Agile, proposé par les auteurs, est une solution trop lourde à mon sens. Noyer une relation de partenariat, et de confiance, sous un contrat de 40 pages n’est pas un bon départ, sauf peut-être dans le cadre de projets particulièrement importants.
Le point de vue de la MOA:
C’est vrai … maquiller un contrat de régie en contrat Agile pour des raisons purement marketing n’est pas une bonne approche : on vend un produit, pas une méthode. L’agilité n’élimine pas complètement la rédaction d’un cahier des charges : Le backlog est de fait un cahier des charges. Ceci permet d’estimer un budget et par conséquent d’anticiper ce qui sera inclus ou non. Au final, on peut tout à fait utiliser les méthodes Agiles ET un cadre budgétaire. Prolongez la lecture dans les commentaires, enrichissants (même si parfois un peu stériles).
Illustration : freepik.com.
