La faculté de sortir du projet de manière anticipée est un des traits distinctifs de la démarche Agile. Le client doit, en effet, pouvoir arrêter le projet quand il le souhaite sans contrainte autre que de rémunérer le prestataire pour les prestations déjà effectuées. Les divers « sprint backlogs » étant envisagés comme des modules fonctionnels autonomes, le client doit en effet pouvoir en conserver l’usage sans qu’il soit nécessaire de repartir de zéro comme c’est souvent le cas dans un projet de type « cascade ».

A l’inverse d’un contrat au forfait classique, la faculté de sortie de projet ne sera normalement pas subordonnée au versement d’une indemnité compensatrice par le client. Le risque de non-poursuite du projet aura en effet été appréhendé par le prestataire Agile comme une composante de son offre et intégrée dans sa grille de risque. Ce risque est le corollaire nécessaire de l’absence d’engagement global, en termes de forfait et de délais notamment, sans lequel l’économie d’un contrat Agile pencherait trop fortement en faveur du prestataire [15].

Il importe toutefois de veiller à ce que cette faculté de sortie sans contrepartie ne soit pas requalifiée en condition purement potestative rendant nulle la clause de dénonciation ou de résiliation insérée dans le contrat (article 1174 du Code civil). Ainsi toute clause faisant dépendre de la simple manifestation de volonté du client la poursuite ou non des prestations prévues au projet pourrait encourir un tel grief particulièrement en l’absence de mécanisme de compensation financière au profit du prestataire.

Afin de conjurer ce risque, deux méthodes nous paraissent envisageables :

(i) faire dépendre la mise en œuvre chaque nouveau « sprint » d’un accord de volonté préalable entre les parties sur le périmètre, les délais ou le prix

Dans un tel cas, les conditions techniques et financières associées à chaque nouvelle itération serait fixée par voie contractuelle dans le cadre d’accords opérationnels de type contrats d’application. Le contrat conclu à l’origine se rapprocherait alors fortement d’un contrat cadre renfermant les conditions générales ayant vocation à régir l’ensemble des contrats d’application qui seraient signés dans le cadre du projet.

Le projet Agile s’analyse moins en une course de fond épuisante qu’en une succession 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 donc 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. A l’instar des logiciels libres, les Méthodes Agiles sont issues de la pratique, et permettent manifestement 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, est en fait 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 ?

Partant de ce principe qu’il est impossible de définir le périmètre fonctionnel à l’avance, le client fournit simplement sa vision du projet dans l’AOA. Le périmètre deviendra la variable d’ajustement.

Sélection sur les compétences

La sélection du fournisseur est faite sur la qualité de la réponse, la pertinence du processus (agile) proposé et sur les compétences de l’équipe pressentie. Le changement par rapport à la pratique d’évaluation actuelle des réponses à appel d’offres est que le prix n’est pas considéré, puisque c’est le client qui le fixe. Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés.

Mais c’est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu’il impose une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable.

Avec un CFA, l’objectif du client n’est plus de reporter les risques sur le fournisseur, il devient de collaborer avec lui pour obtenir le meilleur produit dans le délai défini.

Point de vue du client

Les clauses du contrat sont adaptées à l’agilité. Voici quelques exemples de ce qu’il est possible d’y introduire, pour le bénéfice du client :

• le client doit recevoir un produit partiel, mais fonctionnel, à la fin de chaque itération : il peut ainsi fournir un feed-back rapide ;
• le client peut arrêter le contrat à la fin de chaque itération (en contrepartie d’une indemnité fonction du temps passé pour le fournisseur ) : il peut ainsi stopper à temps un projet voué à l’échec ;
• le client définit les priorités : le fait de développer les fonctionnalités à forte valeur ajoutée en premier permet de lever les risques tôt (risques techniques, bien sûr mais surtout risques de livrer un produit en inadéquation avec les attentes) ;
• le client peut changer d’avis sur le contenu fonctionnel (sur les parties qui n’ont pas encore commencé), à condition que ce qu’il ajoute au backlog (terme Scrum pour désigner la liste des choses qui apportent de la valeur au client et qui sont à faire par le fournisseur) soit contrebalancé par ce qu’il y retire.

Point de vue du fournisseur

Du point de vue du prestataire titulaire d’un contrat avec un client qui a remporté l’appel d’offres :

• si c’est dans un cadre agile (réponse à AOA puis CFA), c’est évidemment plus simple puisque le client est déjà convaincu de l’intérêt de l’agilité. Je suggère au fournisseur d’annexer le backlog dans le contrat. Ce backlog est élaboré soit par le client lors de l’AOA, s’il a déjà une idée précise de ce qu’il veut, soit conjointement par le prestataire et le client, lors d’une première phase de recueil des besoins (appelée Sprint 0 dans Scrum). En associant à chaque élément du backlog une estimation en points, le dialogue avec le client sur les évolutions du périmètre fonctionnel et les négociations éventuelles sera grandement facilité.
• si c’est dans le cadre d’un forfait classique, l’agilité du fournisseur est limitée par le contrat. Le fournisseur peut néanmoins introduire des pratiques agiles (livraisons fréquentes avec des itérations courtes pour commencer), essayer de collaborer au maximum avec le client, le sensibiliser à l’idée des tests qui pilotent le développement (TDD) et le convaincre de passer au forfait Agile pour le prochain appel d’offres.

Le fait de montrer rapidement au client le résultat des itérations et de l’impliquer dans les réunions de planification favorise sa confiance et le met ainsi dans de meilleures dispositions, l’incitant à s’impliquer davantage.

Comment formaliser la collaboration du client dans un contrat Agile ?

La nécessaire collaboration du client doit être effective dès le début du processus Agile. Pour cela, la méthode de pilotage doit être contraignante. Elle doit intégrer des modalités d’exécution du projet spécifiques dans le champ contractuel.

Cette formalisation des processus de gestion du projet va permettre de conscientiser le client sur son nécessaire apport à la réussite du projet.

Une implication accrue du client est donc requise dans la phase de développement, essentiellement lors des réunions avec l’équipe du prestataire où les décisions seront prises :

• points à développer lors du sprint,
• définition et évaluation des résultats,
• etc.

Le client doit alors veiller à mettre à disposition du projet suffisamment de ressources. Les clauses fixant des obligations de disponibilités, délais de réaction, etc. sont donc courantes dans la pratique des contrats Agile.

Quelles sont les conséquences de l’obligation de collaboration ?

Dans cette même optique de responsabiliser les parties sur leur nécessaire implication dans le processus Agile, des clauses de limitation de la responsabilité du prestataire en cas d’absence de collaboration du client nous paraissent essentielles. Si elles sont parfois jugées sévères, elles se justifient totalement. En effet, la commune intention des parties est bien de conduire le projet sur la base d’une méthode collaborative. On ajoutera que la collaboration insuffisante du client peut sans doute être qualifiée de manquement fautif aux obligations contractuelles dans le cadre d’un projet Agile dont ladite collaboration est une pierre angulaire.

De son côté, le prestataire sera attentif au fait que l’intensification du devoir de collaboration du client a pour conséquence un alourdissement proportionnel de son devoir de conseil. En effet, plus le client doit s’impliquer et prendre des décisions, plus il doit pouvoir se reposer sur les connaissances et conseils du prestataire pour le faire. On insistera donc sur la nécessité de documenter d’une manière suffisante :

• les conseils donnés et
• les décisions prises

afin de couper court à toute discussion ou contestation sur ces éléments en cas de problème ultérieur.

Que faire en l’absence de collaboration du client lors d’un projet Agile ?

Pour éviter un blocage lié à un manque de réactivité du client, il peut être tentant de prévoir des mécanismes d’acceptation tacite. Toutefois, une telle solution ne fait que reporter le problème. Le client risque de contester plus tard une décision qu’il n’aurait pas prise. De plus, cela ne correspond pas à l’esprit d’un processus collaboratif.

Cependant, des clauses de gouvernance peuvent permettre de clarifier les rôles et les procédures de décision. Elles ménagent des mécanismes qui évitent les blocages tout en stimulant l’implication des parties dans la prise de décision.