Contrats informatiques - Méthodologie Agile et contrats de développement - Révolution ou adaptation ?

15 mai 2012

Stéphane Leriche, Eléonore Varet

De manière synthétique, la méthode Agile s’analyse comme une méthode itérative [1] et incrémentale de développement de logiciels favorisant une approche pragmatique et évolutive des projets de développement de solutions informatiques en se concentrant sur les objectifs opérationnels et les besoins réels du client. L’idée directrice est une mise en production rapide des fonctionnalités d’une solution, selon un ordre de priorité déterminé en fonction de la valeur métier de chaque fonctionnalité et ciblé sur le besoin du client au moment du passage en production plutôt que sur une projection de son besoin au lancement du projet.

L’agilité valorise l’interaction des individus plus que les processus et les outils, des logiciels opérationnels davantage qu’une documentation exhaustive, la collaboration accrue des clients et l’évolutivité [2]. Le concept adaptatif est en effet au cœur de ces méthodes [3] et se réalise fonctionnellement par l’adaptation permanente aux évolutions du besoin des utilisateurs et techniquement par un remaniement régulier du code.

Là où les projets classiques sont développés selon le mode « cascade » par étapes linéaires et successives en suivant un phasage bien connu de développement d’une solution cible (expression du besoin, conception générale, conception détaillée, réalisation, recette et déploiement), ces différentes phases sont réalisées concomitamment sur la base de courtes itérations dans les projets Agile, réduisant ainsi considérablement le délai entre définition du besoin et mise en production [4]. Plutôt qu’un planning, des processus et un séquencement figés, la méthode Agile privilégie de courtes itérations (« sprints » [5]) visant la mise en production accélérée des fonctionnalités prioritaires, priorités révisables et ré-aménageables à tout moment en cours de projet.

Cette approche est ainsi de nature à bouleverser les réflexes contractuels acquis en brouillant la répartition des responsabilités entre client et fournisseur et en inscrivant le contrat dans une temporalité plus saccadée, délaissant l’approche globalisante caractéristique des projets en « cascade ». Les recettes d’intégration, vérification d’aptitude au bon fonctionnement (VABF) et vérification de service régulier (VSR) n’ont plus, dans un tel schéma, les rôles de sésame et juge de paix que leur confère la pratique contractuelle classique lorsqu’il s’agit de déterminer la bonne fin d’un projet. L’accent se porte au contraire sur les tests unitaires qui seuls révéleront l’adéquation du code et des performances du produit aux besoins de l’utilisateur.

La méthode Agile se veut ainsi une nouvelle manière d’appréhender la négociation et la gestion d’un projet informatique en privilégiant la réalité du terrain plutôt que la référence à une documentation contractuelle exhaustive et « omnisciente ». L’incidence de ce nouveau paradigme sur la pratique des contrats informatiques méritait donc d’être étudiée.

1.                  Les carences de l’approche classique

Les contrats de développement ou d’intégration d’applications informatiques réservent habituellement à l’expression initiale des besoins un rôle déterminant. Cette expression de besoin initiale, formalisée dans un cahier des charges, est en effet le premier référentiel de conformité à partir duquel l’accomplissement de ses obligations par le prestataire sera apprécié.

Cette approche, typique des contrats au forfait, s’efforce de déterminer à l’avance les trois points clés d’un contrat de réalisation de ou d’intégration de logiciels : le périmètre, le prix et le calendrier. Le contrat est, le plus souvent, le résultat d’un appel d’offres pendant lequel les prestataires sont soumis à une concurrence très forte les poussant à pratiquer un dumping des prix et à accepter les exigences du client en termes de délais en vue de l’obtention du marché.

En conduisant les prestataires à s’engager sur un périmètre fonctionnel en début de projet pour un budget forfaitaire et des délais impératifs et dans le cadre d’une obligation de résultat voire de bonne fin, les clients cherchent à transférer le plus possible sur ceux-ci les risques et la complexité des projets informatiques. Le client espère ainsi se reposer sur le contrat pour se rassurer sur le coût du projet, même en présence d’un cahier des charges lacunaire.

Les effets pervers sont nombreux et connus : une gestion des ressources à l’économie par le prestataire au détriment de la qualité et une renégociation systématique par le prestataire en cours de projet de chaque changement fonctionnel à un prix élevé pour éviter de supporter des pertes significatives sur l’ensemble du projet. Toute modification des besoins du client affectant l’un quelconque de ces paramètres (périmètre, prix, calendrier) implique alors une renégociation plus ou moins lourde selon l’importance du changement et la fluidité du modèle de gouvernance mis en place.

L’expérience montre que figer l’expression par le client de ses besoins en début de projet conduit à contractualiser les projets informatiques sur un mode statique là où ils sont en réalité dynamiques. Or, la complexité des projets informatiques ne peut être niée. Elle doit au contraire être appréhendée comme l’un des paramètres du projet afin que tout problème puisse être identifié et résolu rapidement.

En outre, cette distorsion entre pratique des projets informatiques et modes de contractualisation génère un contentieux fourni. Ainsi, la sortie de conception détaillée après analyse des écarts entre les besoins du client, tels qu’exprimés dans le cahier des charges, et les besoins du client, tels qu’ils résultent des ateliers de conception, est toujours une phase de crispation. Toute évolution du besoin par rapport au périmètre fonctionnel contractuellement défini constitue en effet un point d’achoppement, les parties s’épuisant à déterminer s’il s’agit d’un besoin nouveau, d’une évolution du besoin, d’une précision du besoin, d’un besoin implicite…L’opposition se cristallise alors, le prestataire reprochant au client une défaillance dans l’expression de ses besoins et le client dénonçant un manquement du prestataire à ses obligations de conseil, d’alerte et/ou de délivrance conforme [6].

Au mieux, les parties se détournent provisoirement de l’objectif opérationnel pour trouver une issue dans le cadre d’un avenant, aboutissant au fil du projet à une sorte de mille-feuille contractuel. Mais cela peut tout aussi bien conduire à l’échec du projet. Nombre de contentieux naissent des dérives budgétaires d’un projet, le client exigeant le strict respect du forfait alors même que ses besoins n’étaient pas parfaitement définis et que des évolutions fonctionnelles sont apparues en cours d’exécution.

Le litige opposant la MAIF et IBM au sujet de l’échec d’un projet d’intégration d’un progiciel de gestion de la relation-client (GRC) et ayant donné lieu à des décisions fort attendues par les spécialistes du secteur [7], constitue une formidable illustration des dérives engendrées par l’approche classique reposant sur le triptyque périmètre, délais et forfait.  Rappelons que dans ce litige, après un retentissant succès en première instance, la MAIF a succombé en appel malgré un contrat particulièrement favorable : obligation de résultat à la charge d’IBM, délais impératifs, forfait global etc…, preuve qu’un contrat solidement verrouillé ne saurait garantir la réussite d’un projet ou protéger le client contre l’ensemble des aléas et vicissitudes d’un marché.

Ce constat d’échec de trop nombreux projets [8] a d’ores et déjà conduit les praticiens à introduire davantage de souplesse dans les contrats en prévoyant une révision de la hiérarchie des documents contractuels applicables, en introduisant des mécanismes d’ajustement du prix (prix maximum garanti, partage des gains, etc.) et/ou du périmètre, en prévoyant les modalités d’une révision du calendrier du projet et/ou en anticipant les cas de sortie du contrat.

Il est ainsi devenu habituel que les spécifications détaillées une fois validées par le client viennent supplanter les autres documents applicables et plus particulièrement le cahier des charges. La méthode Agile vient prolonger et renforcer cette tendance à l’assouplissement des règles contractuelles de conception et réalisation des projets, libérant les contrats de développement logiciel de leur carcan trop rigide et formaliste.

2.                 Les reponses apportées par la méthode agile

Partant du constat effectué ci-dessus, l’un des principaux avantages de la méthode Agile est d’accueillir et reconnaître le besoin de changement sous toutes ses formes (évolution des besoins, changement de contexte économique, survenance de difficultés techniques) et à tous les stades du projet. Client et prestataire collaborent dès le début du projet à un travail de spécifications fonctionnelles afin de définir de manière évolutive le besoin réel du client et d’adapter le projet en fonction des changements de ce besoin. La satisfaction du besoin réel du client est ainsi évaluée de manière continue. L’accent est alors directement mis sur l’obtention rapide de lots de fonctionnalités prêtes à la production.

Concrètement, en contexte Agile, les travaux du prestataire sont pilotés à partir d’une liste de fonctionnalités attendues (Product Backlog) qui formalise le périmètre du projet sur la base d’une quantification de la valeur métier et de la complexité technique de chaque fonctionnalité. Cette liste est vivante, objet d’échanges quotidiens entre client et prestataire et actualisée à chaque itération. Une première liste de fonctionnalités avec un ordre de priorité défini est annexée au contrat mais celui-ci stipule les modalités de son évolution. Les spécifications détaillées se construisent donc tout au long du projet [9] et les fonctionnalités sont mises en production progressivement à partir de ce référentiel évolutif.

Par ailleurs, plutôt que de s’engager sur un périmètre fonctionnel en début de projet dont on sait qu’il est mouvant, le contrat Agile s’attache à chiffrer des jalons intermédiaires rapprochés (« sprint backlogs ») permettant de sécuriser les investissements tant pour le client que pour le prestataire. Les charges sont généralement évaluées en nombre de jour/homme nécessaires à la réalisation du projet et la contractualisation effectuée sur la base d’un engagement de consommation minimum de la part du client et de réalisation d’un maximum de fonctionnalités à forte valeur ajoutée du prestataire. Le contrat peut également prévoir une faculté de redistribution des jours/homme non consommés au titre d’une itération (voir figure 1 sur le cycle d’un projet Agile).

En outre, dans les contrats Agile, le client dispose normalement d’une faculté d’interruption du projet lui permettant de mettre un terme aux développements sans pour autant condamner le projet dans son intégralité. Les fonctionnalités développées et mises en production au titre des itérations précédentes restent acquises au client.

Cette démarche intègre par conséquent la gestion des risques d’un projet informatique de manière pragmatique. Cette approche se transcrit-t-elle aisément dans un moule contractuel lequel se caractérise généralement par une déclinaison binaire entre droits et obligations, voire, dans de nombreux contrats , entre droits du client et obligations du prestataire ?

Le manifeste Agile [10] rappelle qu’une bonne collaboration est plus importante qu’un contrat et certains des promoteurs de la méthode n’hésitent pas à affirmer que le processus de négociation contractuelle est en réalité contre-productif dans la mesure où il tend à faire surgir les antagonismes plutôt que d’œuvrer dans le sens d’une convergence collaborative. Le temps et les ressources consacrés à cette étape de négociation pourraient être avantageusement remplacés par une mise en route accélérée du projet.

Dés lors la généralisation de cette méthode signifie-t-elle la mort du contrat informatique tel qu’on le connaît ?

Ce serait certainement aller trop loin. La contractualisation répond à la réalité d’un besoin de rationalisation des achats de prestations informatiques des grands groupes et de prévisibilité budgétaire. La négociation du contrat doit en effet dessiner le cadre d’une relation commerciale saine et permettre de définir une enveloppe budgétaire.

Si le contrat demeure donc l’outil indispensable de la sécurité juridique du projet dans la mesure où il permet de fixer le cadre dans lequel celui-ci viendra s’inscrire et de répartir les risques entre le client et le prestataire, le modèle « classique » du contrat informatique ne peut sortir indemne d’une telle remise en perspective.

3.                 les repercussions sur le contrat

La méthode Agile suscite indéniablement une nouvelle manière d’appréhender contractuellement la relation client/fournisseur. Si des notions clés telles que la recette conservent droit de cité, dans la mesure où elles continuent de rythmer la vie du projet et de ponctuer chaque fin de « sprint »,  les notions de prestations au forfait (3.1) et d’obligation de résultat qu’elle soit de conformité ou de respect des délais (3.2), si chères au client, risquent quant à elles d’en ressortir fortement ébranlées. De même, la possibilité de sortie du client en cours de projet, corollaire essentiel du caractère évolutif et dynamique du contrat Agile, incite-t-elle à envisager de manière plus relâchée la force du lien contractuel (3.3).

3.1  Vers la fin du contrat « au forfait » ?

En tant qu’elle part de la réalité du projet pour en déduire les obligations respectives des parties, la méthode Agile induit une plus grande imbrication entre dimensions opérationnelle, financière et juridique dans la rédaction du contrat.  Dans la mesure où elle se présente comme une alternative au « triptyque infernal »- périmètre, prix et délais- imposé en début de projet, la méthode Agile semble, en première analyse, incompatible avec la notion de forfait. Dès lors que le périmètre des fonctionnalités, voire les besoins métier eux-mêmes, sont appelés à évoluer de manière souple et rapide, l’idée d’un prix global semble, de prime abord, exclu. Le dimensionnement final du projet n’étant, par hypothèse, pas connu ou en tout cas fortement incertain au jour de la conclusion du contrat, un forfait budgétaire d’ensemble paraît effectivement irréaliste.

Sauf à constituer un véritable repoussoir auprès des clients et de leur direction des achats, le contrat Agile ne saurait néanmoins priver le client de son besoin de prévisibilité budgétaire et on peut légitimement estimer que rares seront les projets effectivement conduits sur un système d’engagement en régie. A cet égard, chaque itération (sprint) pourra être réalisée selon un mode forfaitaire une fois l’évaluation des charges effectuées. En cas de désaccord sur le coût d’une itération, le client sera alors en droit d’arrêter le projet, de renoncer à la réalisation des fonctionnalités envisagées au titre de cette itération ou d’en modifier le périmètre.

Cette approche présente néanmoins l’inconvénient de réintroduire de la rigidité et de la pesanteur administrative là où la méthode Agile se propose de généraliser le principe de flexibilité. En effet, chaque « mini-forfait » devra faire l’objet d’une discussion entre les parties qui, quoiqu’ayant été anticipée dans son principe au moment de la signature du contrat, risque de ralentir significativement le rythme du projet, voire de provoquer des blocages.

C’est la raison pour laquelle d’autres mécanismes ont été envisagés permettant au prix d’être fixé le plus en amont possible, notamment en érigeant le périmètre en véritable variable d’ajustement du projet [11]. Dans un tel cadre, l’enveloppe budgétaire du projet est fixé par le client dès l’origine (par exemple au stade de l’appel d’offres) et c’est le périmètre des fonctionnalités qui sera ajusté au fur et à mesure en fonction des charges consommées par le prestataire telles que contrôlées conjointement par les deux parties. Ainsi, toute demande de nouvelle fonctionnalité devra impérativement être compensée par le retrait d’une autre fonctionnalité représentant une charge comparable en termes de jours/ homme ou points de fonction. Le projet se retrouve ainsi piloté autour de son axe financier, seul son périmètre étant sujet à évolution sur accord des parties. L’avantage de cette démarche est qu’elle limite les discussions entre les parties aux aspects fonctionnels et techniques et évite ainsi toute renégociation sur le plan des conditions tarifaires, potentiellement plus sujettes à polémique.

Ce n’est donc pas tant le principe d’un engagement au forfait qui est mis en échec par la démarche Agile mais bien la possibilité de déterminer contractuellement un forfait sur la base d’un périmètre et de délais intangibles.

3.2  L’obligation de résultat balayée ?

Le primat de la dimension opérationnelle met à l’épreuve certaines des « figures imposées » du contrat de développement ou d’intégration de logiciel et plus particulièrement la notion d’obligation de résultat, que celle-ci s’applique au respect de la conformité ou des délais.

A titre préliminaire, il importe de rappeler que contrairement à une idée répandue, les notions de forfait et d’obligation de résultat ne sont pas indissociablement liées. L’obligation de résultat peut très bien s’appliquer à des prestations réalisées en régie et sur la base de prix estimés, dès lors que le résultat à atteindre est quant à lui parfaitement spécifié. S’il est vrai que l’obligation de résultat sera le plus souvent associée à l’existence d’un forfait, les deux ne sont pas indissolublement liés.

Il n’en demeure pas moins que, dans le cadre d’un contrat Agile, l’absence de référence à un calendrier de projet impératif, à un forfait et à un référentiel contractuel défini en début de projet rend difficile de faire peser sur le prestataire une obligation générale de résultat. Quand bien même entendrait-on limiter le champ de l’obligation à résultat à chaque livraison en fin d’itération, la forte interdépendance entre les obligations du prestataire et du client, pleinement assumée en contexte Agile, semblerait militer pour une exclusion de toute référence à une obligation de résultat.

S’il importe d’éviter tout dogmatisme et de ne pas conclure hâtivement à l’incompatibilité entre obligation de résultat et méthode Agile, force est de reconnaître que l’espace réservé à celle-ci dans un tel contexte paraît très étroit compte tenu de la forte imbrication des relations entre client et prestataire, ceux-ci étant appelés à former des équipes mixtes.

Il est en effet établi de longue date en jurisprudence que la participation du créancier à l’exécution de la prestation est un facteur exclusif de l’obligation de résultat. Ainsi, dans un arrêt du 5 avril 2011 [12], la Cour de cassation rappelait aux juges du fond la nécessité de rechercher « s’agissant d’une date de livraison contractuellement planifiée, si l’exigence d’une collaboration étroite entre les parties pendant la phase d’étude ne comportait pas un aléa, exclusif de la qualification d’obligation de résultat ».

Ce constat ne manquera pas d’être une source d’inquiétude du point de vue des utilisateurs, et notamment de leurs directions juridiques. Il doit cependant être nuancé. Selon l’évolution jurisprudentielle récente, l’obligation de délivrance conforme semble devoir être relativisée, là encore pour tenir compte de la réalité opérationnelle. La jurisprudence récente atteste en effet d’un infléchissement de l’obligation de délivrance conforme du prestataire.

Si la non-conformité continue d’être appréciée au regard des caractéristiques convenues entre les parties, les juges exigent en revanche désormais la démonstration d’un certain degré de gravité des défauts constatés pour qu’un manquement du prestataire soit retenu. La seule constatation de l’existence ou de la subsistance de défauts ne suffit plus à engager ipso facto la responsabilité du prestataire.

Ainsi, la Cour d’appel de Versailles, un arrêt du 24 mars 2010 [13], a infirmé le jugement qui lui était déféré ayant prononcé la résolution judiciaire d’un contrat d’intégration aux torts du prestataire, au motif que chacune des parties avait contribué au non-respect du délai de livraison et à la persistance des non-conformités, lesquelles n’apparaissaient pas d’une gravité suffisante pour justifier la résolution de la convention compte tenu de la complexité applicative de la solution. Le prestataire était pourtant débiteur d’une obligation de résultat au titre de la livraison de la solution intégrée.

Dans une autre espèce où l’obligation du prestataire était qualifiée d’obligation de résultat, la Cour d’appel de Toulouse [14] a considéré que la rupture par le client du contrat était non seulement brutale mais injustifiée, l’expertise ayant fait ressortir que les défauts subsistant à cette date auraient pu être facilement corrigés.

Ces décisions confirment que la stipulation d’une obligation de résultat, si elle rassure le client au moment de la signature du contrat, ne constitue pas une protection à toute épreuve en cas de contentieux, a fortiori si elle n’est pas le reflet de la réalité opérationnelle et organisationnelle du projet.

Dans la cadre d’un contrat Agile, plutôt que de se reposer sur la stipulation d’une obligation de résultat « attrape-tout », le client sera donc bien inspiré d’identifier précisément les obligations pouvant être qualifiées comme tel. Enfin, la mise en place d’obligations de résultat « atténuées » ou de moyens « renforcées » sera toujours envisageable afin de faire reposer l’intégralité de la charge de la preuve sur le prestataire.

3.3    Une sortie du projet facilitée

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. Largement plébiscité dans le domaine des contrats d’exploitation et plus généralement d’outsourcing, ce modèle est le plus souvent délaissé en matière de contrat de développement et d’intégration. Dans l’approche classique, le projet est, en effet, envisagé comme une réalité unique et globale pouvant être contractuellement appréhendée d’un seul tenant. L’évolution ou la mutation n’étant pas au cœur du dispositif, le client a pour préoccupation essentielle de retenir le prestataire dans les liens contractuels initialement définis et de limiter au strict minimum la nécessité d’accords de volonté ultérieurs. Ici, au contraire, le contrat initial se limiterait à sa plus simple expression tout du moins sur le plan des aspects techniques, opérationnels voire financiers. La matière inhérente à chaque nouvelle livraison attendue faisant l’objet d’un accord particulier. Pour cohérente qu’elle soit, cette formule pâtit d’un défaut évident, à savoir la nécessité pour les parties de contractualiser leur vision technique, opérationnelle ou financière à chaque étape du projet. Une telle démarche semble, en effet, entrer en contradiction avec les fondements de la méthode Agile que constituent la souplesse et la rapidité. La nécessité de signer un document juridiquement engageant à chaque nouvelle phase paraît aller à l’encontre de tels principes.

(i) faire dépendre la mise en œuvre de chaque nouveau « sprint » d’une décision du client fondée sur des critères objectifs

Les parties au contrat peuvent également choisir de faire dépendre de critères objectifs et prédéfinis la décision du client de poursuivre le projet. La réalisation de la condition suspensive ne serait plus alors soumise à la seule volonté discrétionnaire de ce dernier, ce qui permettrait de purger le grief de potestativité.

Les critères choisis et conditionnant ce « GO/ NO GO » pourraient être fondés sur des indicateurs de qualité, de conformité ou de délais appréciés par rapport à un référentiel défini en commun. De manière évidente, le rejet définitif en recette d’un lot de fonctionnalités pourrait constituer un critère permettant l’arrêt du projet. On se situerait certes dans un cas de figure proche de la résiliation pour faute. Cependant, sauf à vouloir engager la responsabilité contractuelle du fournisseur, la décision unilatérale d’arrêter de projet nous paraît préférable à une résiliation pour manquement pure et simple et ce, en vue d’une sortie de contrat apaisée et collaborative.

D’autres indicateurs comme le calcul d’un ratio comparant les fonctionnalités implémentées (exprimées en points de fonction) par rapport à la charge consommée (en jour/ homme) pourraient également servir de fondement pour décider de l’arrêt du projet.

                 *          *          *

La méthode Agile apparaît donc comme un facteur de renouveau de la pratique des contrats informatiques se matérialisant par une approche plus consensuelle et pragmatique. Il faudrait néanmoins être naïf pour en déduire la fin des négociations contractuelles, des difficultés d’exécution et des situations de blocage. A plus forte raison si l’on considère que les principes décrits ci-avant ont tendance à décrire un contrat Agile « chimiquement pur » respectant en tous points les commandements émis par les promoteurs de la méthode. Dans la réalité, il est fort probable que la méthode Agile continuera, comme c’est déjà le cas aujourd’hui, de se diffuser par petites touches afin d’infléchir les défauts les plus criants de la méthode en cascade. C’est ainsi que l’on rencontre en pratique des modes de gestion de projet « mixtes » s’inspirant partiellement des enseignements de la méthode Agile sans en appliquer tous les principes.

Contrairement à la vision de certains idéalistes, la méthode Agile ne sonne pas le glas de l’irruption du juridique dans l’univers du développement informatique. Elle appelle, en revanche, à une vision rénovée du travail du juriste spécialisé plus centrée sur la prévention des dérives que sur leur sanction.

Expertises, mai 2012








[1] Le processus de développement agile s’effectue sur la base d’itérations, c’est-à-dire des cycles courts pendant lesquels l’ensemble des phases des méthodes de développement traditionnelles (définition des besoins, conception générale et détaillée, développement, recette, déploiement) sont réalisées.



[2] Le manifeste Agile, rédigé en 2001 par 17 experts reconnus pour leurs apports respectifs en termes de méthode de développement logiciel, a généralisé le recours aux méthodes agiles. Il repose sur quatre valeurs fondamentales : l’équipe, l’application, la collaboration et l’acceptation du changement.



[3] Il existe plusieurs méthodes agiles : RAD, DSDM, Scrum, FDD, XP ASD, Crystal clear, etc. Les deux méthodes les plus utilisées en France sont la méthode Scrum qui se différencie par la pratique de courtes réunions quotidiennes et la méthode XP (extreme programming) axée sur la construction de l’application par une approche de planification.



[4] « Les méthodes Agile impliquent davantage les utilisateurs », V. Berdot, X. Biseul et P. Tran, 01 Informatique, 5 novembre 2008.



[5] Selon la méthodologie dite « Scrum », la plus répandue, et qui servira de référence dans le cadre de cet article.



[6] Cour d’appel de Toulouse, 14 septembre 2010, Caminel c. Ceicom, n°08-06386.



[7] Cour d’appel de Poitiers, 1ère ch. Civ., 25 novembre 2011, www.legalis.net.



[8] 10% des projets IT sont arrêtés avant d’avoir abouti et moins de 20% se déroulent comme prévu initialement (source : H. Kloetzer, « La maîtrise d’ouvrage des projets informatiques », éditions Hermès Lavoisier, 2002 ).



[9] « Comment contractualiser un projet Agile ? », N. Lopez-Saussier et T. Beaugrand, www.itchannel.info.



[10] Voir note 2.



[11] Claude Aubry, « Contrat au forfait et démarche agile », www.aubryconseil.com/ 2008/ 04/14/401.



[12] Cass. Com., 5 avril 2011, CGI Assurances c. April, n°09-71756.



[13] Cour d’appel de Versailles, 24 mars 2010, Allianz IARD c. GFC-BTP, n°08-04309.



[14] Cour d’appel de Paris, 8 octobre 2010, Compagnie Albingia c. Sobersat, n°07-20690, qui juge fautive la résiliation par le client du contrat dans la mesure où « il a pu être remédié à certains [des] dysfonctionnements dont l’émergence était inévitable dans le cas de l’adaptation d’un progiciel à une installation informatique complexe […] et où  le client ne « justifi[ait] d’aucun manquement suffisamment grave (qui ne sauraient résulter des reports des délais acceptés et dépassement de prix) justifiant la résiliation ».



[15] Cette méthode paraît, en revanche, de nature à compliquer la démarche de « reconnaissance de revenus » dans la mesure où l’estimation de revenus de début de projet sera affectée d’un facteur d’incertitude particulièrement fort.

Auteurs

Barbier-Marion

Marion Barbier

Partner
France

Me joindre +33 (0)1 42 68 6000
Dupuis-Toubol-Frédérique

Frédérique Dupuis-Toubol

Partner & Executive Director
France

Me joindre +33 (0)1 42 68 6000
Mole-Ariane

Ariane Mole

Partner
France

Me joindre +33 (0)1 42 68 6000
Schuler-Marc

Marc Schuler

Partner
France

Me joindre +33 (0)1 42 68 6000
Tiourtite-Djazia

Djazia Tiourtite

Associate
France

Me joindre +33 (0)1 42 68 6000