Forfait, régie ou jalons : comment structurer un contrat de développement logiciel

Points clés

• Le forfait fixe à la fois le prix et le périmètre. Il convient quand le périmètre est réduit et bien compris ; sinon, le prestataire intègre le risque dans son prix, et chaque changement devient une négociation.
• La régie facture le temps réellement passé. Elle absorbe bien les changements, mais exige de la visibilité, de la confiance et un plafond budgétaire pour vous protéger.
• Le contrat par jalons se situe entre les deux : le travail est découpé en étapes, chacune avec un résultat défini, des critères de recette et un paiement. Pour la plupart des applications sur mesure, c'est le meilleur équilibre.
• Une phase de cadrage courte et rémunérée, avant le contrat principal, fiabilise n'importe quel modèle, car l'estimation repose sur des faits et non sur des hypothèses.
• Quel que soit le modèle, exigez des critères de recette écrits, une procédure de demande de modification, une cession des droits de propriété intellectuelle et une clause de réversibilité.

Le modèle d'un contrat de développement logiciel détermine deux choses : la manière dont le prix est fixé, et qui supporte le risque quand le travail se révèle plus important ou différent de ce qui était prévu. En logiciel sur mesure, c'est presque toujours le cas, parce que les détails d'un produit ne deviennent clairs qu'au fil de sa construction. Trois modèles sont courants : le forfait, la régie, et le contrat par jalons qui combine les deux. Voici comment fonctionne chacun d'eux, quand y recourir et ce qu'il faut inscrire au contrat, quel que soit votre choix.

Les trois modèles en un coup d'œil

Le forfait : prévisible sur le papier

Un contrat au forfait fixe un montant unique pour un périmètre convenu. Il séduit parce que le budget paraît certain, et il convient aux missions courtes et bien définies : une fonctionnalité aux spécifications claires, une migration dont le point de départ est connu, un audit.

Pour des produits plus importants, cette certitude est souvent illusoire. Une estimation faite avant le démarrage est la moins fiable que vous obtiendrez jamais ; les travaux sur l'estimation décrivent ce phénomène sous le nom de cône d'incertitude (en anglais) : les premières estimations peuvent s'écarter fortement de la réalité, dans un sens comme dans l'autre, et ne se resserrent qu'à mesure que le projet avance. Un prestataire qui s'engage sur un forfait dans ces conditions se protège de l'une de ces trois manières :

• en ajoutant une prime de risque à son prix, que vous payez même si tout se passe bien ;
• en définissant le périmètre de la façon la plus étroite possible, pour que tout ce qui n'est pas écrit devienne une demande de modification payante ;
• ou, sous la pression, en rognant sur ce qui ne se voit pas : les tests, la documentation, la sécurité.

Il n'y a là aucune mauvaise foi : c'est la conséquence logique du modèle. Martin Fowler observe qu'un forfait peut fonctionner (en anglais) pour un logiciel appelé à évoluer, à condition que ce soit le périmètre, et non le budget ou la date, qui reste souple : vous fixez le budget et décidez ensemble des fonctionnalités qui y tiennent.

La régie : souple, à condition de voir le travail

En régie, vous payez le temps réellement travaillé, à un taux journalier ou horaire convenu. C'est le reflet le plus honnête de la façon dont un logiciel se construit, et ce modèle absorbe facilement les changements : quand les priorités bougent, l'équipe travaille simplement sur autre chose. C'est aussi le modèle le plus proche de la préférence exprimée par le Manifeste Agile pour « la collaboration avec les clients plus que la négociation contractuelle ».

Le risque, en revanche, passe de votre côté. La régie fonctionne bien quand vous voyez ce que vous payez :

• des démonstrations régulières d'un logiciel qui fonctionne, pas des rapports d'avancement ;
• un accès au dépôt de code et à l'outil de suivi des tâches, pour voir la progression entre deux démonstrations ;
• un plafond budgétaire par mois ou par phase, avec l'engagement de s'arrêter pour en discuter avant de le dépasser ;
• une équipe en qui vous avez confiance, ce qui explique que ce soit le modèle habituel pour la maintenance évolutive et les partenariats de long terme.

Les jalons : le juste milieu pragmatique

Un contrat par jalons découpe le projet en étapes. Chaque étape a un résultat défini, des critères de recette écrits et un montant, payé une fois les critères remplis. Pour une application sur mesure, une structure type ressemble à ceci :

1. Cadrage et architecture, à prix forfaitaire : utilisateurs, processus métier, intégrations, modèle de données, risques et plan de livraison. Le résultat vous appartient et vous pouvez le confier à n'importe quelle équipe.
2. Une première version utilisable, dont le périmètre découle de ce qu'a révélé le cadrage.
3. Les versions suivantes, chacune planifiée et chiffrée une fois la précédente en service.

L'engagement reste ainsi proportionné à ce que l'on sait. Le prestataire estime une étape qu'il comprend, plutôt qu'un produit entier qu'il ne connaît que par description, et vous n'êtes jamais à plus d'une étape de pouvoir arrêter, changer de cap ou changer d'équipe. C'est proche de la façon dont sont menés les services numériques publics au Royaume-Uni, avec une phase de cadrage (en anglais) avant tout engagement sur la réalisation.

Les clauses à prévoir, quel que soit le modèle

Le modèle compte moins que ce que dit le contrat. Quel que soit votre choix, vérifiez la présence de ces clauses.

• Critères de recette. Ce que « terminé » signifie pour chaque livrable, par écrit, et le délai dont vous disposez pour tester avant de prononcer la recette.
• Demandes de modification. Tout travail hors du périmètre convenu fait l'objet d'un devis écrit, avec son impact sur le coût et les délais, avant de commencer.
• Échéancier de paiement. Des paiements liés aux résultats livrés, et non à des dates du calendrier ou à un acompte important au démarrage.
• Propriété intellectuelle. Une cession écrite des droits à votre profit, dès leur création. Notre guide à qui appartient le code explique pourquoi payer ne suffit pas en droit français.
• Comptes et accès. Les dépôts et l'hébergement sur vos propres comptes dès le premier jour.
• Garantie. La durée pendant laquelle le prestataire corrige gratuitement les défauts du travail livré.
• Résiliation et réversibilité. Ce qui se passe si l'une des parties met fin au contrat : préavis, éléments remis et assistance due à une nouvelle équipe. Notre checklist de passation détaille le contenu d'une passation complète.
• Protection des données. Un contrat de sous-traitance au sens de l'article 28 du RGPD (en anglais) si le prestataire doit traiter des données personnelles.

Comment choisir

• Une mission courte et entièrement spécifiée ? Le forfait.
• Un nouveau produit, ou un périmètre que vous ne savez pas encore décrire en détail ? Commencez par une phase de cadrage rémunérée, puis passez aux jalons.
• Des évolutions et de la maintenance continues, avec une équipe que vous connaissez ? La régie, avec un plafond mensuel.
• Une application héritée ou en difficulté ? D'abord un diagnostic court au forfait, puis des jalons une fois les risques connus. Notre guide reprendre ou réécrire explique pourquoi.

Pour comprendre ce qui détermine le budget total, consultez notre guide sur le coût d'une application web sur mesure.

Questions fréquentes

Le forfait n'est-il pas toujours plus sûr pour le client ? Seulement si le périmètre est réellement figé. Pour un produit appelé à évoluer, vous payez une prime de risque dès le départ et vous subissez quand même des demandes de modification par la suite : le coût final dépasse souvent celui d'une estimation honnête en régie.

Quel plafond budgétaire raisonnable fixer en régie ? Un montant que vous pouvez vous permettre de dépenser avant de replanifier : souvent un mois de travail de l'équipe, ou l'estimation de la phase en cours. L'objectif est d'imposer une discussion avant que l'argent soit dépensé, pas après.

Peut-on changer de modèle en cours de projet ? Oui. Passer d'un cadrage au forfait à des jalons, puis à la régie pour la maintenance, est courant et pertinent : le modèle suit le niveau de connaissance du projet.

Qui rédige les critères de recette ? Les deux parties, avant le démarrage des travaux. Le prestataire les propose à partir des spécifications ; vous vérifiez qu'ils décrivent ce dont vos utilisateurs ont réellement besoin.

---

Chez FNB Solutions, nous travaillons par jalons, avec des critères de recette écrits pour chacun, et une phase de cadrage rémunérée optionnelle dont le plan écrit vous appartient. Toute demande hors périmètre fait l'objet d'un devis écrit avant de commencer. Nos conditions contractuelles sont publiques. Pour discuter de votre projet, parlons-en.

Sources

• Fixed Price, Martin Fowler (en anglais)
• Cone of Uncertainty, Wikipédia (en anglais)
• Le fonctionnement de la phase de cadrage, GOV.UK Service Manual (en anglais)
• Manifeste pour le développement Agile de logiciels
• Article 28 du RGPD : sous-traitant (en anglais)