17 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Forfait ou régie : la question se pose dès qu’on fait développer un logiciel. La plupart des réponses comparent deux modes de facturation, et elles supposent qu’un forfait fixe à la fois le prix et la liste des fonctionnalités. Il existe pourtant deux sortes de forfait. Le forfait à périmètre fixe chiffre un cahier des charges. Le forfait à budget fixe et périmètre fonctionnel flexible fixe le budget et le problème à résoudre, et laisse évoluer les fonctionnalités qui y répondent.
Le forfait à périmètre fixe et la régie ont un point commun : l’un comme l’autre reposent sur une prédiction. Le premier prédit le coût d’une liste de fonctionnalités. La seconde prédit un nombre de journées. Et cette prédiction se met à l’épreuve sur une seule question : quand le besoin change en cours de route, qui paie ?
Car le besoin change. Quand Microsoft mesure l’effet de ses idées par expérience contrôlée, une sur trois seulement améliore l’indicateur visé. Un tiers n’a aucun effet, un tiers le dégrade (Kohavi et Thomke, Harvard Business Review, 2017). Personne ne sait d’avance lesquelles. On l’apprend à l’usage.
Au forfait à périmètre fixe, le prestataire s’engage à livrer une liste de fonctionnalités, décrite dans un cahier des charges, pour un prix fixé à la signature.
En régie, le prestataire met des personnes à disposition et facture le temps passé, au jour. Ce qui est fixé à la signature, c’est le prix d’une journée.
Au forfait à budget fixe et périmètre fonctionnel flexible, le prix est fixé, et le problème à résoudre aussi. Ce qui reste flexible, c’est la manière d’y répondre : les fonctionnalités développées.
Le forfait à périmètre fixe fige donc le prix total et la liste. La régie ne fixe que le tarif journalier. Le forfait à budget fixe fige le budget et le problème, pas la liste. Pour comprendre qui porte le risque, il faut regarder comment chacun arrive à ses chiffres.
Tout part du cahier des charges. Le prestataire découpe la liste en tâches, puis estime chaque tâche en jours de travail. Il additionne. Il multiplie par son tarif. Il obtient un prix.
Ce prix repose entièrement sur des estimations. Or une estimation reste une supposition sur un travail qui n’a pas encore été fait. Vasco Duarte a étudié ce que valent ces suppositions. Il travaille dans le logiciel depuis 1997 et a été l’un des moteurs de l’adoption de l’agilité chez Nokia et F-Secure. Dans son livre NoEstimates (chap. 1), il rapporte les données qu’il a recueillies dans une entreprise entre 2001 et 2003, sur dix-sept projets. Le retard moyen sur l’estimation y atteignait 62 %. Un projet prévu pour trois mois en durait près de cinq.
Un prestataire qui s’engage sur un prix connaît ce risque, et il le reporte dans son chiffre. Evan Leybourn, cofondateur du Business Agility Institute, un organisme international consacré à l’agilité des organisations, a écrit un guide des contrats agiles, How Much Does This Cost? (partie « Fixed contracts »). Il y explique que, lorsque le prix et la liste sont fixés tous les deux, on augmente la marge pour imprévus avant de remettre le devis. Tomas Rybing, auteur de Applied Capacity Planning With NoEstimates (2015), décrit la même pratique (p. 4-5) : un coefficient tiré de l’intuition, multiplié à l’estimation pour tenir compte des obstacles qu’on sait rencontrer sans savoir lesquels. Il cite des valeurs comme 30 % ou le double. Certains professionnels qui accompagnent les développeurs indépendants conseillent une marge d’erreur de 30 % à 250 %, selon le projet et le secteur.
Duarte (chap. 2) en montre la limite. Une marge trop large rend l’offre plus chère que celle des concurrents. Une marge plus modeste ne suffit pas non plus, à cause de la loi de Parkinson. Une fois le délai accordé, le travail tend à s’étendre jusqu’à le remplir. Une tâche plus longue que prévu consomme sa part de marge, puis un peu plus. Une tâche terminée plus tôt ne rend pas le temps gagné, qui se perd en attendant que la suivante puisse commencer. À la fin du projet, il ne reste plus de marge, et le retard revient quand même. Pour Duarte, une marge donne ainsi, sans que personne le dise, la permission d’être en retard.
Le planning suit la même logique que le prix. Les tâches estimées sont ordonnées, souvent dans un diagramme de Gantt, et regroupées en jalons. Chaque jalon a sa date. La recette vient à la fin, quand tout est livré.
Ce planning est détaillé, et c’est ce qui le rend difficile à modifier. Duarte (chap. 7) le souligne : changer l’ordre du travail dans un plan détaillé oblige à tout reprendre, l’enchaînement des tâches, leur contenu, leur attribution. Plus le plan est simple, plus il absorbe facilement les changements.
Or la liste s’écrit avant que le logiciel n’existe, le jour où l’on en sait le moins sur l’usage qu’en feront les utilisateurs de votre application. En cours de route, le besoin bouge. Une fonctionnalité prévue ne sert plus. Une autre, que personne n’avait imaginée, devient urgente. Chacune de ces découvertes sort de la liste signée. Elle fait l’objet d’une demande de modification, chiffrée à part. Elle devient un avenant, et l’avenant, c’est le client qui le paie.
Les écarts peuvent être lourds. Sur 4 677 projets informatiques, le coût réel atteint en moyenne 1,8 fois le coût estimé, soit 80 % de plus (Flyvbjerg et al., JMIS 2022). Cette moyenne est tirée par une minorité de projets aux dépassements extrêmes : dans le même échantillon, le dépassement médian est proche de zéro. Mais personne ne sait, au moment de signer, de quel côté tombera son projet.
Sur le papier, le forfait à périmètre fixe protège le client de l’erreur d’estimation. Le prix est signé, et c’est au prestataire d’absorber l’écart. Dans les faits, cette protection tient mal. La marge pour imprévus, que le client paie dans le devis, s’épuise en route, comme le montre la loi de Parkinson. Et ce que l’on découvre en cours de projet, quand ce n’est pas dans la liste signée, revient sous forme d’avenant, que le client paie aussi. Le client finit donc par payer plus que le prix signé. La date ne tient pas mieux : pour ce cas, où le prix et la liste sont fixés, Leybourn conseille de laisser la date de livraison flexible et de la décaler autant que nécessaire.
Quand le prix, la liste et la date sont fixés tous les trois, Leybourn est plus direct encore. Il écrit qu’il faut renoncer au projet (« Cancel the work »). Selon lui, un tel projet ne convient pas à une approche agile, et même mené avec une méthode traditionnelle, il risque fort d’échouer sans un peu de souplesse.
Nous en tirons ceci : quand le prix, la liste et la date sont tous bloqués, l’un des trois finit par lâcher. Le budget dépasse, la livraison prend du retard, ou des fonctionnalités sont abandonnées.
En régie, le prix d’une journée est connu. Le nombre de journées ne l’est pas.
Le budget de départ se construit pourtant de la même façon qu’au forfait à périmètre fixe : quelqu’un estime le nombre de jours nécessaires et le multiplie par le tarif. La différence, c’est que ce chiffre n’engage personne. C’est une enveloppe prévisionnelle. La facture, elle, suit les jours réellement passés, justifiés chaque mois par un compte rendu d’activité.
Si le travail prend deux fois plus de temps que prévu, il coûte deux fois plus. Le risque d’estimation est entièrement du côté du client.
Leybourn (partie « Time and material contracts ») y voit pourtant le contrat le plus souple. Le client peut arrêter dès que ce que coûte la suite dépasse ce qu’elle rapporte. Pour borner la dépense, il décrit une variante plafonnée, où le plafond doit rester assez haut pour que l’investissement reste rentable. Le budget redevient alors une limite, mais une limite qu’on a encore estimée.
C’est la force de la régie : la liste reste modifiable. Le client change de priorité quand il le souhaite, sans avenant. Beaucoup d’équipes travaillent alors par itérations courtes, de deux semaines par exemple. Elles estiment chaque élément en points de complexité, mesurent combien de points elles terminent par itération, et en déduisent une date.
Duarte (chap. 2) relève le défaut de cette mécanique : en avançant, l’équipe comprend mieux le travail. Certaines équipes finissent alors par réestimer plusieurs fois tout ce qui reste à faire, et la date qu’on en avait déduite ne tient plus.
Il propose autre chose (chap. 5). Ne plus estimer la taille des éléments, mais les découper assez petits pour qu’ils se ressemblent. Compter combien en sont terminés chaque semaine. Prolonger ce rythme pour prévoir la suite. Il ajoute qu’un travail découvert en cours de route n’est pas une dérive du périmètre : c’est de la valeur découverte. Et il défend un principe qui renverse le forfait à périmètre fixe (chap. 2) : fixer la durée et le coût, laisser la liste varier.
Rybing applique cette idée sous le nom de planification par la capacité (p. 2-6). Chaque vendredi, son équipe compte les tâches terminées sur son tableau, ce qui prend moins de cinq minutes. La moyenne donne une capacité, 18 tâches par semaine dans son exemple. De là, une simple division : 213 anomalies à corriger, 18 par semaine, soit 12 semaines, le double des 6 semaines prévues au planning. Ou, dans les 6 semaines, à peu près la moitié des corrections.
Duarte ne parle d’ailleurs plus d’estimation, mais de prévision. Ces outils sont les meilleurs dont on dispose quand on est obligé de prédire. Ils limitent les dégâts, et ils poussent vers un périmètre fonctionnel flexible. Mais ils reposent encore sur une forme d’estimation : ils supposent que le rythme passé vaut pour la suite. On a remplacé une supposition sur l’avenir par une extrapolation du passé.
Ce que la régie vend, enfin, ce sont des journées. Rien dans le modèle n’oblige à mettre chaque mois un logiciel utilisable entre les mains de vos utilisateurs. Et le prestataire doit garder l’autorité sur les personnes qu’il met à disposition. Quand c’est le client qui dirige leur travail au quotidien, l’opération peut être requalifiée en prêt de main-d’œuvre illicite : le Code du travail interdit toute opération à but lucratif ayant pour objet exclusif le prêt de main-d’œuvre (article L8241-1).
Pour Leybourn, un contrat se définit d’abord par le niveau de risque que chaque partie accepte de porter. Le forfait à périmètre fixe et la régie se présentent comme opposés. Ils partent pourtant du même geste : estimer le travail avant de le faire. Le forfait à périmètre fixe transforme cette estimation en prix. La régie la transforme en enveloppe prévisionnelle, et cherche ensuite à garder de la visibilité : comptes rendus d’activité, suivi de la consommation, date de fin recalculée.
Pourquoi tient-on tant à ces prévisions ? Frédéric Leguédois, coach agile et formateur, y répond dans sa conférence « Éloge de la simplicité » (Devoxx France) : face à l’incertitude, le planning est un imaginaire qui rassure. « Le planning, c’est un doudou organisationnel. »
Un doudou rassure. Il ne protège de rien. Un planning recalculé chaque semaine donne l’impression de piloter le budget. Le budget, lui, continue de suivre ce que le travail coûte réellement.
Le forfait en soi n’est pas en cause. Ce qui pose problème, c’est de figer en même temps le budget et la liste des fonctionnalités. Une liste de fonctionnalités datée avant de commencer est ce que Frédéric Leguédois appelle un planning. Dans la même conférence, « Éloge de la simplicité », il dit ce qu’il pense d’un planning : « Le planning, c’est la liste de tout ce que nous sommes sûrs de ne pas faire aujourd’hui. » Il ajoute qu’un planning regroupe des informations « inutiles aujourd’hui » et « fausses à partir de demain ». Autrement dit, ce qui est prévu pour dans six mois ne sert à rien aujourd’hui, et ce sera probablement faux le jour venu. Figer à la fois le budget et cette liste fait porter tout le risque de l’incertitude à l’une des parties, et plus personne ne peut s’adapter. Ne rien figer, à l’inverse, laisse le budget dériver.
Il reste une combinaison que ni l’un ni l’autre ne propose : fixer le budget et le problème à résoudre, laisser flexible le périmètre fonctionnel qui y répond, et cesser de prédire ce qui ne peut pas l’être.
Vous pensez que c’est nouveau ? Les bâtisseurs de cathédrales travaillaient déjà ainsi. Une cathédrale gothique se construisait avec l’argent qui rentrait : les revenus de l’évêque et des chanoines, les dons et les legs des fidèles. À Strasbourg, au début du XIIIe siècle, le clergé crée une caisse à part, l’Œuvre Notre-Dame, pour gérer les dons, les legs, les offrandes et les aumônes destinés au chantier. Quand l’argent manquait, les travaux ralentissaient, et parfois s’arrêtaient pour longtemps.
On ne commençait pas non plus par la façade. On commençait le plus souvent par le chœur, la partie de l’église où se célèbrent les offices. À Notre-Dame de Paris, le chantier s’ouvre en 1163. L’autel du chœur est consacré en 1182, et un mur provisoire sépare le chœur du chantier : les cérémonies peuvent s’y tenir pendant qu’on construit la nef. À Cologne, le chœur est consacré en 1322, soixante-quatorze ans après la première pierre. Le chantier s’interrompt vers 1520 et ne reprend qu’en 1842, financé pour environ 60 % par une association de donateurs. La cathédrale est achevée en 1880. À Beauvais, l’argent a manqué pour aller plus loin que le chœur et le transept : la nef n’a jamais été construite. Dans chacune de ces cathédrales, on se servait de ce qui était bâti bien avant que le reste n’existe.
Leybourn décrit une forme voisine : un prix fixé par semaine ou par itération, une date fixée, une liste de fonctionnalités flexible. Le prix ne sort plus d’une estimation : « The cost is effectively budgeted, instead of estimated » (le coût est budgété, et non estimé). Il continue pourtant de mesurer le rythme d’acceptation pour prévoir combien d’éléments tiendront dans le temps imparti. C’est encore une prédiction.
C’est sur ce point que notre modèle s’en écarte. C’est un forfait : un budget mensuel fixe, sans date de fin à prévoir ni rythme à prolonger. Ce qui est fixé, c’est le budget et le problème à résoudre. Ce qui reste flexible, c’est le périmètre fonctionnel, c’est-à-dire les fonctionnalités qui répondent à ce problème. Chacune est une expérience, menée sous la même question.
Comment le budget se définit. Le budget mensuel se construit avec vous, à partir de vos chiffres et de vos objectifs, lors d’un second rendez-vous. Il ne part pas d’une liste de fonctionnalités à chiffrer. Il part du temps que vous décidez d’investir dans votre logiciel, au regard de ce que vous coûte son absence. Le contrat couvre 15 jours ouvrés par mois et par membre d’équipe.
Comment le travail se planifie. Il n’y a ni Gantt, ni jalons datés, ni rythme prolongé pour prévoir une date de fin. L’approche prédit ce qui est prévisible : le budget mensuel et les jours de développement par mois. Elle ne cherche pas à prédire l’imprévisible : ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains. Elle s’inscrit dans ce que Frédéric Leguédois appelle, dans sa formation « Un retour à l’essence de l’Agilité », un « fonctionnement sans projection ». Et elle pose une seule question : quelle est la chose la plus utile à faire maintenant ?
Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer. Chaque jour, vous la voyez avancer sur votre environnement de recette.
Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez. Nous appliquons le jour même ce que l’usage nous apprend sur une fonctionnalité. Une application vivante n’est jamais finie : si l’on cesse de la faire évoluer, elle ne reçoit plus que des correctifs de sécurité et des mises à jour des composants sur lesquels elle repose, et c’est une application qui se meurt.
Ce qui se passe quand le besoin change. Le problème reste le même. C’est la façon d’y répondre qui change, et rien n’est à renégocier. La fonctionnalité qui ne sert plus sort de la liste. Celle qui devient urgente passe devant. Le budget ne bouge pas. Ce que nous développons, en revanche, suit ce que vos utilisateurs nous apprennent en s’en servant.
Ce n’est pas de la régie pour autant. Ce que vous recevez chaque mois n’est pas un relevé de temps. C’est un logiciel dont vos utilisateurs se servent.
Nous développons votre application sur mesure pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Ce budget est arrêté avant de commencer, avec le problème à résoudre. La liste des fonctionnalités, en revanche, suit ce que l’usage nous apprend. C’est donc un forfait, mais pas un forfait à périmètre fixe.
Votre enveloppe achète du travail pour atténuer ce problème en permanence, dès le premier jour de développement. Nous visons sa résolution complète, sans pouvoir la garantir ni la dater. Vous n’attendez pas ce jour-là pour que l’atténuation commence. Chaque mois vous voyez ce qui en sort, et vous décidez de continuer. Vous pouvez mettre fin au contrat par écrit à tout moment, sans justification.
Une garantie de résultat sert à protéger un client qui ne peut pas partir. Ici, vous le pouvez chaque mois.
Pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Au forfait à périmètre fixe, le prestataire porte l’erreur d’estimation sur la liste signée. Le client porte le changement de besoin, avenant après avenant.
En régie, le client porte les deux. Le changement ne coûte pas d’avenant, mais chaque journée de plus s’ajoute à la facture.
Au forfait à budget fixe et périmètre fonctionnel flexible, il n’y a plus d’estimation à dépasser. Le budget est connu avant de commencer, et il tient, parce que rien ne dépend d’une prédiction. Le changement de besoin modifie ce qui est développé, pas ce qui est payé. Et le client peut mettre fin au contrat par écrit à tout moment, sans justification. Son partenaire technique a donc tout intérêt à bien faire son travail : sinon, le client met fin au contrat. Plus le logiciel sert au client, plus il a de raisons de poursuivre, et plus son partenaire technique a de raisons de soigner son travail.
Le forfait à périmètre fixe reste adapté à un besoin qui ne bougera pas. Un travail qu’on refait à l’identique devient prévisible. Un logiciel, lui, se développe toujours pour la première fois.
Au forfait à périmètre fixe, le prix est la somme d’estimations faites avant de commencer, sur une liste de fonctionnalités dont on ignore complètement la pertinence. Le coût réel finit souvent au-dessus du budget prévu, pour très peu de fonctionnalités développées qui ont un véritable intérêt commercial : chez Microsoft, nous l’avons vu, une idée sur trois seulement améliore l’indicateur visé. Nous expliquons pourquoi le coût dépasse le budget dans notre article sur les dépassements de budget.
Notre guide reprend ces sources en détail. Vous y trouverez aussi les questions à poser avant de signer un devis pour le développement de votre outil sur mesure.
Vous avez un logiciel à faire développer, ou un outil qui ne suit plus votre activité ? On en parle ?
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.
Quel budget pour créer une application ? Le montant ne suffit pas : visez un objectif plutôt qu'une liste, avec des utilisateurs dès le premier mois.