Les projets informatiques, un constat d'échec ?

Nombreux sont les projets informatiques qui sont, encore aujourd'hui, menés selon une approche classique (dite "en cascade" ou "en V"), c'est-à-dire, basée sur des activités séquentielles. Ce qui les caractérise aussi c'est qu'ils reposent principalement sur une méthode prédictive, parce que le plus souvent le périmètre fonctionnel est défini dès le stade de l'appel d'offres et qu'un prix et une échéance impérative sont déjà fixés. L'expérience a montré que ce type de projet est souvent source de difficultés. La raison est simple. Elle vient du fait que, d'un côté, on a un client qui exige un strict respect des engagements alors que ses besoins ne sont pas toujours parfaitement définis et que des évolutions fonctionnelles sont apparues en cours de projet, et, d'un autre côté, on a un prestataire qui n'entend pas prendre exclusivement à sa charge ces évolutions, et ce d'autant que lui-même a peut-être – pour obtenir le marché – sous-estimé la charge et qu'il est déjà en dépassement budgétaire. Selon plusieurs études récentes, deux tiers des projets informatiques seraient des échecs, soit parce qu'ils sont abandonnés en cours de route, soit parce que, bien qu'aboutissant, ils se font au prix de dépassements budgétaires importants ou au détriment de certaines fonctionnalités jugées essentielles.

Une méthode en réaction

C'est justement en réaction à cette méthode de développement et sur la base de ce constat d'échec que des méthodes de développement dites "agiles" ont vu le jour. On pense notamment à la méthode SCRUM, qui est l'une des méthodes "agiles" les plus utilisées dans le cadre des projets informatiques. Elle repose sur une approche itérative et incrémentale. En d'autres termes, selon cette approche, le besoin n'est pas figé en début de projet. Il est évolutif, ce qui suppose une forte collaboration entre le client et le prestataire, qui, lui, doit faire preuve de flexibilité. Par ailleurs, la satisfaction du besoin réel du client est évaluée de manière continue, à travers la livraison régulière d'un produit partiel testé et intégré.

Les idées reçues

Et parce que justement le besoin fonctionnel n'est pas figé dans le cadre d'une approche agile, certains pensent que seul le modèle en régie serait compatible avec cette méthode de développement et ce à l'exclusion donc du modèle au forfait. Alors, qu'on s'entende sur les notions de "forfait" et de "régie". Si d'un point de vue juridique, quand on évoque le "forfait", on pense au prix du contrat – qui présenterait la particularité d'être global, définitif et donc insusceptible de révision, sauf avenant, dans le langage courant de l'informatique – la notion de "forfait" ne se limite pas aux caractéristiques du prix. En effet, selon un modèle "au forfait", d'une part, le prestataire s'engage, après analyse du cahier des charges, à réaliser le projet dans un certains nombres de jours et pour un certain prix ; d'autre part, il s'engage sur un ou plusieurs résultat(s), c'est-à-dire sur la fourniture d'un ou plusieurs livrable(s), selon un calendrier défini en amont. Il s'agit, on l'aura compris, du modèle économique privilégié lorsque les contours du projet sont bien définis, que la précision des spécifications fonctionnelles et techniques ne laissent pas, ou en tout cas très peu, de marge d'interprétation. Ce modèle s'oppose à la "régie", qui est en fait ni plus ni moins qu'une "délégation" de personnel. Le prestataire met à disposition du client un ou plusieurs développeurs ainsi qu'un chef de projet (en option) pour mettre en œuvre le projet. Le prestataire s'engage ainsi sur des moyens. Le prix est calculé selon un tarif journalier (TJM). Le modèle en régie est ainsi traditionnellement privilégié pour les projets dont le périmètre n'est pas encore bien défini et pour lesquels le cahier des charges est susceptible d'évoluer. Tout ceci explique pourquoi nombreux sont ceux qui pensent que le modèle en régie est celui qui est le plus adapté pour un projet de développement en mode "agile", dans lequel le besoin du client n'est, par définition, pas figé.

Les solutions pour une agilité au forfait

Pourtant ce qui caractérise un projet informatique "agile", c'est le mode de développement choisi par les parties, privilégiant une approche, incrémentale, itérative et collaborative et ce au détriment d'une approche reposant sur des activités séquentielles. Le modèle économique – forfait ou régie – est donc indifférent. Il est d'ailleurs de plus en plus fréquent de voir des prestataires informatiques s'engager sur un modèle au forfait dans le cadre du développement d'un logiciel, selon une méthode de type Agile (comme la méthode SCRUM). Mais cela suppose, on le conçoit parfaitement, qu'un certain nombre de prérequis techniques et juridiques soient réunis. C'est notamment le cas si l'expression de besoins est, sans pour autant être définitive, suffisamment mature pour que le prestataire puisse mesurer son engagement en termes de coût, de délai et de résultat. Ce sera également le cas si le contrat permet de garantir une certaine agilité en cours de projet en permettant au client de revoir et d'ajuster ses besoins au fur et à mesure de la réalisation des développements. L'insertion de certaines clauses peut contribuer à créer cette agilité. On pense notamment à la clause dite de "changement gratuit", qui permet au client de changer d'avis sans que cela remette en cause le contrat, et en restant à prix constant : ainsi, à chaque fin de sprint (itération), il se voit reconnaître la faculté de changer d'avis sur le contenu du backlog produit (son expression de besoins), à condition que ce qu'il ajoute, en termes de points de complexité, soit contrebalancé par ce qu'il retire ; l'intérêt pour le client est qu'il peut avoir plus de valeur ajoutée (ou utilité) pour un prix équivalent. La clause dite de "révision" participe également à cet esprit d'agilité. Elle permet au client de revenir, dans le sprint suivant, sur un produit partiel livré ou sur une storie livrée et recetée. Bien entendu, une telle faculté doit être encadrée afin que sa mise en œuvre ne pénalise pas l'avancement du projet, ni n'entraîne une surconsommation du budget au détriment du reste à faire. Enfin, la clause dite du "gagnant-gagnant" peut jouer aussi un rôle dès lors qu'elle autorise le client à mettre un terme au contrat à chaque fin de sprint s'il estime que le produit apporte suffisamment de valeur. Dans une telle hypothèse de cessation anticipée, le prestataire est payé au prorata des travaux effectués (stories livrées) plus un pourcentage de la différence entre le prix fixé au départ et la somme proratisée ; c'est du gagnant-gagnant car le client dispose d'un produit qui lui apporte de la valeur pour un prix inférieur à celui prévu initialement dans le contrat (par exemple, il va payer 70 % du prix pour un produit qui représente 80 % de son besoin en termes de valeur ajoutée). Quant au prestataire, il est payé plus que ce qu'il a réalisé sans consommer les ressources, ce qui lui permet d'être dédommagé pour la réaffectation de ses équipes.

À côté de ces clauses, des montages contractuels spécifiques peuvent également être envisagés dans l'optique de créer la confiance en faveur d'un contrat agile au forfait. Inversement, des solutions existent pour rassurer le client lorsqu'il s'oriente sur des développements agiles en régie. À suivre…

Alexandre Fiévée, avocat counsel en droit de l’informatique, en droit des technologies nouvelles et en droit de la propriété intellectuelle au sein du cabinet Derriennic Associés