Suite de notre article consacré aux Méthodes Agiles et aux conséquences que ces méthodes entraînent sur la rédaction, la négociation et la formation du contrat IT qui doit encadrer le projet.

 media_file_1443. Les développement collaboratif des fonctionnalités


3.1 L’expression des besoins : un backlog plutôt qu’un cahier des charges

Dans un projet en cascade, le cahier des charges classique expose le périmètre fonctionnel, ainsi que la durée du projet et les exigences de performances. Le contrat prévoit généralement que le cahier des charges complète et cristallise l’expression initiale du besoin, et sert de référentiel contractuel en cas de non-conformité constatée après livraison. Or, la précision du cahier des charges contraint souvent le prestataire à s’y tenir quelles que soient les difficultés rencontrées. Même s’il lui substitue ses propres spécifications, des écarts sont possibles entre les attentes du client et la compréhension du prestataire. Et même sans écart, le besoin du client peut évoluer de lui-même. C’est alors que son cahier des charges peut parfois se retourner contre le client, qui en devient prisonnier alors qu’il est en partie caduc.En contexte Agile, c’est moins le cahier des charges que le backlog, établi conjointement, qui permet de piloter les travaux. Le backlog est une liste fonctionnelle qui expose les besoins pratiques, item par item, objets d’échanges et de repriorisations. Cette liste présente les fonctionnalités attendues, auxquelles correspondent des unités de valeur et des points de complexité, c’est-à-dire une quantification de la valeur métier du module, et une estimation de sa complexité technique.

Le backlog permet ainsi d’assigner et de réassigner les priorités de réalisation en fonction de l’évolution du projet sur le terrain, à partir de ces critères d’appréciation. L’expression des besoins n’est pas figée : le client pourra prioriser telle ou telle fonctionnalité, demander à modifier la physionomie de telle autre, voire abandonner une demande pour y substituer un nouveau besoin. Le backlog traduit ces adaptations, actualisé en temps réel par les équipes du client et du prestataire. Le client exprime donc son besoin non plus en amont des travaux de développement, mais tout au long du projet. Au prestataire de se montrer parfaitement proactif.

Comment viser dans le contrat un backlog qui sera nécessairement évolutif ? Il est possible d’annexer au contrat un premier backlog, à condition de prévoir alors qu’il sera évolutif, et de mettre en place les modalités d’évolution dudit backlog et l’instance qui validera ses orientations successives.

3.2 le développement itératif : la fin de la « navette »

Dans un projet informatique classique (en cascade ou « en V »), le prestataire divise le projet en lots et l’organise en phases, qui sont lancées selon un calendrier (parfois indicatif, souvent impératif) conduisant théoriquement à un résultat prédéterminé. Le prestataire prend en charge la spécification fonctionnelle comme l’exécution technique, ce qui prive souvent le client de la visibilité sur les réalisations intermédiaires.

En contexte Agile, là encore la collaboration des équipes est placée au centre du projet. On voit émerger des notions telles que les users stories, qui procèdent moins d’une définition générique des fonctionnalités attendues que d’une expression concrète de leurs besoins par les utilisateurs eux-mêmes. Les users stories peuvent être actualisées tout au long du projet, et les fonctionnalités afférentes sont contrôlées dès leur mise à disposition, dans le cadre d’un développement sous forme de courtes itérations identiques (time boxing), appelées sprints et releases. Les releases peuvent cumuler en leur sein les opérations de spécification fonctionnelle, de développement puis de tests, au lieu de les échelonner dans le temps. En cas de non-conformité, le développement peut être corrigé avant de passer à la séquence suivante.

Le praticien qui rédige un contrat IT doit donc traduire en droit les notions de courtes itérations de durées identiques, et les options qui s’offrent aux parties au terme de chacune d’elles. Les phases du calendrier, souvent critiques lorsqu’elles ne sont pas respectées, doivent donc être remplacées par la mention d’une unité de mesure, le sprint, ou l’itération selon l’importance du projet. Le contrat doit ensuite stipuler le nombre de sprints envisagé pour parvenir à répondre à la demande du client.

Le prestataire propose également une usine logicielle, soit un ensemble d’applicatifs de développement utilisé par les équipes. Celles-ci sont en outre réunies en un même lieu afin de permettre des échanges concrets, plutôt que des échanges parfois pléthoriques d’emails et de synthèses. Cette unité de lieu n’a pas pour fonction de remplacer les comités de pilotage, mais fluidifie considérablement ceux-ci dans la mesure où les équipes bénéficient ipso facto du même niveau d’information. Usine logicielle, unité de lieu… autant d’éléments à faire monter en puissance, au chapitre des modalités de réalisation des prestations du contrat.

Enfin, le calendrier constitue en principe le fil rouge du projet, et fait se succéder les phases du projet à un rythme parfois très délicat. En contexte Agile, le temps est relativisé : il est un paramètre parmi d’autres dans la priorisation des développements. Si la notion de date finale de bascule conserve toute sa pertinence, en revanche les étapes intermédiaires peuvent varier selon les fonctionnalités que les utilisateurs privilégient. Il peut alors devenir illusoire d’assortir les jalons intermédiaires d’une obligation de résultat… bien qu’il reste important d’encadrer les grandes étapes du projet et de leur fixer des « deadlines ».

3.3 La recette des prestations : la fin de l’effet « tunnel »

En contexte classique, le client pâtit parfois d’un « effet tunnel », lorsque ses équipes n’interviennent pas dans les opérations de spécification et de développement de la solution. Schématiquement, le client a émis son besoin en amont, et contrôle les livrables en aval par référence aux spécifications issues du cahier des charges. Or, comme plusieurs mois séparent souvent la validation des spécifications par le client et la livraison des développements par le prestataire, les surprises sont parfois nombreuses au moment des opérations de réception ! Non-conformités fonctionnelles, défaut de performances, dysfonctionnements ou retards graves, les fiches de recette sont parfois extrêmement accablantes pour le prestataire – à moins qu’elles ne révèlent des fautes du client, qui refuse de procéder à un minimum de « conduite du changement » en interne ou qui a insuffisamment documenté son besoin en amont.

Mais à ce stade, le préjudice est consommé, et les partenaires doivent redoubler d’efforts pour parvenir à finaliser un projet qui connaît ses premières dérives. Les dérives s’aggravent parfois pour devenir de véritables accidents industriels, chacun ayant épuisé ses équipes en vain. Bien entendu, certains contentieux permettent de mettre en lumière l’insouciance coupable d’un client qui n’a pas mesuré les implications de son projet, ou à l’inverse, les lacunes du prestataire dans l’analyse du besoin, voire l’inadéquation de son produit. Mais très souvent, c’est la découverte d’écarts entre les livrables et leurs spécifications initiales qui déclenche la dérive.

En contexte Agile, les risques de mauvaise surprise semblent sérieusement réduits. A l’instar des opérations de spécifications, les opérations de tests sont menées de façon collaborative, sur des itérations très courtes. Les écarts sont donc constatés conjointement dans un délai extrêmement réduit, et doivent être corrigés de la même façon par le prestataire. Le fil directeur du développement résidant dans l’efficacité de la fonctionnalité, elle sera donc validée même si elle ne répond pas exactement au cahier des charges initial, dès lors que c’est en commun que le client et le prestataire délivrent leur validation sur un livrable réellement opérationnel et exploitable.

L’effet tunnel est ainsi supprimé puisque les utilisateurs testent les fonctionnalités promises très peu de temps après avoir qualifié leur besoin, et peuvent les mettre en production aussitôt.

Le praticien qui rédige le contrat IT doit donc renoncer au dogme de la recette qui tombe comme un couperet sur les développements en fin de phase : en contexte Agile, ceux-ci ont été spécifiés, puis réalisés, testés et validés (ou corrigés) en commun dans le cadre d’itérations courtes. En revanche, il doit imaginer de nouveaux critères de recette, en conservant à l’esprit qu’eux-mêmes seront susceptibles de varier dans le temps, et qu’il n’est donc pas utile de les « sanctifier » dans le contrat. Ces critères doivent se rattacher non plus au cahier des charges, mais au backlog et aux user stories, tels qu’ils existeront à l’époque de la recette.

 

4. De nouveaux principes de pilotage et d’évaluation

4.1 Le copilotage Agile du projet

On a vu que le backlog remplace le cahier des charges, et que les sprints et releases combattent l’effet tunnel. En outre, ces notions sont définies conjointement, et demeurent évolutives. Ainsi, l’ensemble des phases du projet traditionnellement juxtaposées (analyse, spécification, développement, recette, correction) est mené de front… Mais d’autres concepts font leur apparition et traduisent une montée en puissance de l’obligation de collaboration dans le contrat : la vélocité caractérise l’efficacité de l’équipe, c’est-à-dire sa faculté à produire un code de qualité et des unités de valeur importantes en fonction du nombre et de la durée des sprints. Dans un contexte ou le résultat compte parfois moins que la performance, cette mesure de la performance doit primer le simple respect des délais intermédiaires. Le contrat doit comporter les indices de mesure de cette performance, voire les vecteurs de récompense si elle est satisfaisante (par exemple par des systèmes de bonus / malus).

La collaboration devient centrale : la bonne entente, la répartition des rôles, la motivation commune et le feedback permanent sont très conseillés. Les équipes se réunissent fréquemment (la méthode Scrum insiste sur la réunion quotidienne). Les outils de communication (wiki notamment) acquièrent une grande acuité, et participent de cette communication permanente. Et les équipes du client sont d’autant plus enclines à accepter le changement, qu’elles participent justement à la définition de ce qui change.

On insistera toutefois sur le fait que le prestataire, bien souvent détenteur de l’expérience et de l’expertise Agile, doit « coacher » le client, et doit donc assumer une part supérieure du pilotage, en alertant le client sur d’éventuelles non-conformités aux Méthodes, et en rationalisant systématiquement les demandes du client en les inscrivant dans une réflexion plus globale sur la cohérence fonctionnelle et technique du projet, qu’il appartient au prestataire de mener et de soumettre au client.

De plus, les prototypes se multiplient : la solution informatique cible ne reste pas longtemps à l’état virtuel, et ses premiers composants sortent rapidement de l’usine logicielle puis sont corrigés au gré des validations. Le contrat doit prendre en compte le sort de ces prototypes, et décider notamment des droits de propriété intellectuelle s’y appliquant.

Les juristes habitués aux contrats IT ne manqueront pas de remarquer que certaines de ces notions Agiles apparaissent déjà dans les contrats IT classiques : l’engagement de reporting, l’obligation de collaboration, la conduite du changement existent depuis longtemps… Mais en contexte Agile, elles gagnent en intensité et doivent focaliser l’attention du praticien. Comme souligné plus haut, il ne sert à rien d’ériger le cahier des charges initial en référentiel de conformité, puisqu’il sera primé par le backlog. Tout au plus peut-il servir d’indication, mais force doit être donnée aux décisions du product owner, et aux validations et adaptations décidées en comité.

Le client doit toutefois s’interroger sur la réversibilité. Certes, l’adaptabilité des équipes aura permis de contourner les éventuelles difficultés techniques rencontrées. Mais le client doit pouvoir faire fonctionner et maintenir le système après le départ du prestataire. La très forte association entre produit et équipe ne doit pas créer de difficulté lorsque l’équipe change ultérieurement côté client. De ce constat émanent parfois certaines critiques relatives au manque de documentation.

4.2 L’évaluation du projet Agile

Les Méthodes Agiles imposent de penser les fonctionnalités attendues par le client non plus seulement en termes de coût ni de délais, mais de valeur. Quelle est la valeur réellement attachée à telle fonctionnalité ? Quels gains (productivité, ergonomique, confort, performances…) la fonctionnalité apporte réellement par rapport aux autres ? Cette notion de valeur implique un changement de culture au sein des métiers habituellement chargés d’établir le cahier des charges. D’où l’importance du product owner, autre illustration de la montée en puissance du capital humain dans les projets IT.

Les Méthodes Agiles procèdent d’une démarche éminemment pragmatique. Le contrat, qui par définition comporte des principes plus abstraits, doit évoluer pour éviter que l’organisation Agile du projet ne soit contredite par un encadrement trop corseté et par voie de conséquence, contre-productif. De la même façon, une obligation de résultat trop large, s’appliquant à la conformité de la solution obtenue par rapport à une solution cible définie ab initio, se marie assez mal avec le caractère mouvant du backlog. Le praticien doit donc appréhender ces notions et leur donner la place qui leur revient dans le « contrat Agile ».

Par ailleurs, on ne doit pas négliger que le forfait budgétaire rassure le client. L’engagement forfaitaire du prestataire est très adapté à un cahier des charges initial définissant un périmètre fonctionnel fermé et des contraintes temporelles strictes. En revanche, dans un contexte Agile, les parties adoptent au fur et à mesure des options non initialement envisagées, ce qui paraît de prime abord incompatible avec l’engagement au forfait. Et aussi souples soient-elles, les Méthodes Agiles ne peuvent suppléer entièrement les garanties que le client exige en termes de périmètre financier. La conciliation entre le « goût » du client pour le forfait et l’intérêt des Méthodes Agile reste un chantier ouvert, sur lequel travaillent les commerciaux et les juristes.

Les Méthodes Agiles signent-elles la fin du forfait et de l’engagement de résultat dans les contrats informatiques ? Il serait imprudent d’aller aussi loin. Premièrement, les projets IT sont complexes, et les clients peuvent cumuler commandes fermes et périmètre prospectif. Sur la partie ferme, le client peut fort bien exiger une enveloppe forfaitaire et un engagement de résultat en matière de conformité, s’il sait que son besoin ne connaîtra aucune fluctuation.

Le client qui parie sur l’Agilité souhaitera en outre conserver une sortie de secours, car son angoisse première est de donner un « chèque en blanc » au prestataire. Il s’agit alors d’être imaginatif, et de trouver des moyens d’intéressement commun au succès rapide du projet ou à sa diversification fonctionnelle. Certains prestataires proposent alors de convertir le cahier des charges initial en nombre de jours/hommes total, stipulé dans le contrat et réparti par fonctionnalité. Le forfait contractuel porte alors sur ce nombre de jours/hommes, et plus sur la couverture fonctionnelle du cahier des charges : celle-ci peut alors évoluer sans contredire les bases contractuelles du projet.

De plus, il est souvent proposé de facturer les prestations au terme de chaque release. Le client conserve ainsi une visibilité optimale sur le coût évolutif du projet, et la possibilité d’y mettre un terme quand bon lui semble. Le mécanisme de sortie doit être stipulé au contrat, rendant au client la faculté décisoire qui doit rester la sienne : il est la dernière instance et doit pouvoir décider des options fonctionnelles comme des montants investis. Sur le terrain, on constate d’ailleurs que les projets menés en mode Agile n’obéissent pas à une logique unique, mais agrègent plusieurs principes traditionnels aux innovations de l’Agilité. L’engagement au forfait couvre par exemple les fonctionnalités désignées comme indispensables, et des paiements proportionnels ou en régie peuvent être proposés pour les aspects moins contraignants du besoin du client.

5. Conclusion

Le projet Agile s’analyse moins en une course de fond épuisante qu’en une succession de sprints dont l’efficacité est jaugée quasiment sans délai. C’est la palette fonctionnelle et la qualité du code de la solution qui deviennent l’étalon-mesure du projet, plutôt que la conformité à un cahier des charges initial vieux de plusieurs mois. Les Méthodes Agiles sont donc pragmatiques, mais elles impliquent une évolution des mentalités et de l’économie du contrat.

Cet aggiornamento ne doit pas s’arrêter aux seules équipes techniques : le juriste qui encadre le projet, tout comme la Direction Générale qui en décide, doivent être sensibilisés aux Méthodes Agiles, et comprendre que les objectifs (couverture fonctionnelle, sécurité juridique, efficacité économique) peuvent être atteints autrement, à condition de renoncer à certains réflexes. L’aspect protéiforme des Méthodes Agiles permet également aux prestataires informatiques de proposer leur propre « offre Agile » et d’y puiser des avantages concurrentiels – ce qui ne va pas sans créer des difficultés sur la bonne interprétation de ce que sotn les Méthodes Agiles.

A l’instar des logiciels libres, les Méthodes Agiles sont issues de la pratique, et semblent parfois permettre de tels gains de valeur qu’elles impliquent désormais une révolution culturelle au sein de l’entreprise. La protection frileuse du code source ou la relation classique « client-prestataire » sont parfois des freins à l’efficacité des projets IT ; on constate au contraire que l’innovation, loin d’être menacée par ces nouvelles propositions, peut en être décuplée.

Quant au juriste, il relève précisément de son office de s’approprier ces nouveaux concepts pour leur apporter une traduction juridique et contractuelle pertinente. Le contrat ne peut être un monolithe intangible, théâtre du rapport de forces entre le client et son prestataire et checklist des engagements réciproques : il doit aussi s’adapter aux évolutions opérationnelles et accompagner l’émergence de nouveaux concepts pour en assurer l’efficacité.

A leur arrivée en France, les licences Open Source avaient défrayé la chronique. On les disait intransposables en droit français, anti-économiques, voire utopistes… On constate aujourd’hui qu’elles se sont multipliées au point d’innerver la plupart des projets informatiques. Plus aucun juriste français ne songe à les combattre, et elles témoignent de ce qu’une autre conception du droit d’auteur est possible et souhaitable. Si le contrat IT leur permet de s’épanouir, peut-être en ira-t-il de même des Méthodes Agiles ?

 

Pour aller plus loin : Agile Tour Paris 2014 avec Thomas Beaugrand
« Contractualisation Agile, contentieux et médiation »

« Contractualisation Agile, de sa rédaction au contentieux »