Forfait vs régie
Développer un projet logiciel au forfait, c’est contractualiser une enveloppe financière fixe pour un projet qui a été spécifié dans le détail. C’est la mise en place d’une relation client-fournisseur avec le risque pour le client de devoir rester dans le carcan de la spécification alors même que les besoins évoluent en cours de projet. Un risque financier existe également pour le fournisseur si le projet a été mal estimé au départ.
Pour le mode de fonctionnement en régie, en revanche, quelque soit le le périmètre et la durée du projet et leur évolution, le coût du projet est défini par un tarif journalier par profil. Dans ce cas de figure, le risque pour le client est de maîtriser plus difficilement son budget. La mise en place d’un partnenariat client-prestataire équitable est alors nécessaire.
Les risques du forfait
Pour une ESN, le risque de travailler au forfait est important. Il est encore monnaie courante dans l’univers du développement numérique car adopter cette approche contractuelle permet souvent, pour une ESN, de gagner un marché. Le risque est d’autant plus grand que le projet sera complexe et de grande envergure.
Dans le cas d’un projet simple à cadrer, comme un site vitrine par exemple de quelques 10aine de pages, le risque de dérapage est faible à partir du moment ou un cahier des charges fonctionnel et des spécifications techniques détaillées ont été réalisées en amont.
Mais pour la plupart des projets technologiques, on constate depuis longtemps que le prédictif atteint vite ses limites alors même que des mois ont été passés (avec le coût qui va avec) à spécifier un projet dans le détail. Ce constat, démontré par de nombreuses études, vient tout simplement du fait qu’un besoin initial évolue rapidement avec le temps :
- parce que le marché évolue,
- parce que la réponse à un besoin utilisateur doit-être testée et ajustée en permanence,
- parce que les objectifs de l’entreprise qui suit ses clients et prospects de plus en plus finement doit s’adapter en continue.
C’est sur ce constat que la pensée agile a bâti son nid et les méthodes agiles et lean deviennent la norme aujourd’hui dans le monde du développement technologique.
Travailler au forfait en utilisant les framework agiles, c’est à dire en adaptant en permanence l’évolution d’un produit ou service au marché relève donc d’une gageure.
Sans prédiction fiable, comment contractualiser de manière figée un périmètre changeant avec des méthodes agiles qui encouragent justement ce changement pour pouvoir apporter au plus vite et en continue de la valeur à un produit pour ses utilisateurs ?
L’effet pervers d’une telle contractualisation au forfait va être que les prestataires, pour des raisons financières, et les clients, pour des raisons contractuelles, ne seront pas en mesure d’adopter l’agilité pour leur projet.
Le projet devra être conforme à des spécifications devenues obsolètes en cours de route et le produit proposé à ses utilisateurs ne rencontrera pas le succès escompté. La qualité pourra en pâtir et la dette technique grandir pour que la durée prédite soit respectée.
Ces conséquences se vérifient presque toujours sur des projets de plusieurs mois voire années dans un univers technologique en pleine effervescence et des tendances de consommation versatiles.
Quelles alternatives au forfait ?
Quelle alternative au forfait et comment faire pour une entreprise avec un budget donné pour réussir un projet technologique ?
Chaque société possède son écosystème technologique et un historique qui la rendent unique. Adopter des solutions sur étagère n’est pas toujours possible. Une solution sur mesure demande à la fois une parfaite connaissance de la société et une grande agilité pour être en mesure de proposer des processus capables de s’adapter en permanence à son marché . Pour cela , une entreprise se doit de trouver un partenaire de confiance et créer une collaboration étroite avec son prestataire dans un contexte gagnant-gagnant.
La régie est un moyen intéressant de fonctionner avec un prestataire qui voit son risque financier limité et aura comme unique souci d’apporter l’expertise et la qualité nécessaire au projet. Cependant, il ne faut pas non plus que l’entreprise, si elle est confrontée à des prestataires peu scrupuleux, ne deviennent la vache à lait sur des projets qui s’éternisent. Un cadre est donc indispensable pour créer l’équilibre entre des intérêts divergents.
Régie et agilité
La contractualisation agile est une démarche qui permet de réduire les risques sur un projet. La vision et les objectifs du projet sont clairement définis. Ils répondent à des enjeux utilisateurs précis. Un chiffrage initial est réalisé pour valider la faisabilité du projet et une première enveloppe budgétaire. Pour que cette étape sécurise les parties, il est nécessaire à ce stade de créer un backlog stratégique du produit qui porte la vision et explicite la valeur ajoutée du projet. Ce backlog est ensuite découper de manière suffisamment fine pour que les estimations soit réalistes. C’est le backlog tactique du projet qui va permettre de clarifier les solutions fonctionnelles et techniques, d’organiser le déroulé du projet et de donnée de la visibilité aux commanditaires.
Ce backlog doit-être également priorisé afin que certains de ses éléments puissent constituer des variables d’ajustement en cas d’erreur d’estimation. Le client doit-être fortement impliqué dans cette phase . Tout projet qui réussi est un projet co-construit où le client et ses représentants métiers et techniques participent à l’élaboration et à la priorisation du backlog.
Et cette collaboration étroite doit se poursuivre sur toute la durée du projet. Si l’on fonctionne avec le framework Scrum, chaque sprint sera l’occasion de valider le périmètre du sprint achevé et du suivant en évaluant en permanence avec le client la pertinence des éléments développés.
En cas de changement au cours du projet, il est possible d’aller cibler des éléments à faible priorité pour les remplacer par de nouvelles fonctionnalités qui font sens sans impacter le budget. En cas de variation sur les estimations initiales, il est également possible de reporter à plus tard ces éléments du backlog de priorité faible pour respecter le budget et les délais. Ces ajustements réguliers induits par la méthode agile doivent être réalisés en bonne intelligence et pour cela, les règles du jeu doivent avoir été validées au début du projet de manière explicites voire contractuelle.
Chaque projet est différent et bien-entendu, le risque d’être confronté à un blocage impactant les délais et les coûts est toujours possible.
Dans le cas où un blocage survient qui n’a pu être anticipé et sans que l’une des parties soit clairement responsable de ce blocage, la collaboration agile peut aussi accréditer un partage de l’impact financier sur le projet qui permettra d’éviter les contentieux et poursuivre le projet sur des bases saines.
Ce type de solution peut-être mis en place au cas par cas, en fonction du contexte projet et avoir bien des variantes. L’essentiel pour le succès d’un projet est de trouver le chemin d’une collaboration où les partenaires restent focus avant tout sur le succès de la mission et la réalisation de l’objectif de l’entreprise.
Pour faire cela, le fonctionnement en régie accompagné d’une bonne dose d’agilité (qui met en avant la collaboration avec les clients plus que la négociation contractuelle dans ses 4 grands principes fondateurs), reste aujourd’hui l’approche la plus satisfaisante pour réussir un projet technologique complexe.