doctrine Logiciel Le contrat de développement logiciel en méthode Agile Un peu de douceur dans un monde de brutes? Les «méthodes Agiles» consacrent une philosophie de travail évolutive et pragmatique reposant sur quatre valeurs et douze principes énoncés par le Manifeste Agile, rédigé en 2001 par plusieurs experts de l ingénierie logicielle (1), en partant du constat selon lequel une part importante des échecs industriels en matière informatique est due à une trop grande rigidité méthodologique et juridique. DES PRINCIPES ISSUS DE LA PRATIQUE DES PROFESSIONNELS DE L INFORMATIQUE Selon le Manifeste Agile, les quatre valeurs fondamentales de l Agilité sont : 1) la primauté des individus et des interactions sur des processus impersonnels et des outils génériques ; 2) le développement de logiciels opérationnels plutôt que l élaboration d une documentation exhaustive ; 3) la nécessité d une collaboration de chaque instant avec le client au lieu de la stricte application d une matrice de répartition des tâches ; 4) le développement d une réponse efficace au changement imprévu, davantage que le suivi d un plan préétabli qui devient caduc en cours de projet. Le Manifeste Agile décline ensuite les douze principes théoriques qui définissent l Agilité, et que nous énumérons rapidement ci-après : 1) satisfaire le client en livrant tôt et régulièrement les composants produits ; 2) accueillir l éventuel changement à chaque étape du développement et en faire un avantage compétitif pour le client ; 3) livrer fréquemment une application fonctionnelle, idéalement toutes les deux semaines ; 4) faire collaborer les différents métiers du client de manière quotidienne ; 5) placer les individus motivés au centre du projet ; 6) privilégier la transmission orale des informations ; 7) mesurer l avancée du projet par rapport au nombre de fonctionnalités livrées ; 8) réaliser le projet selon une cadence régulière et proportionnée aux ressources ; 9) privilégier la qualité des livrables ; 10) optimiser le travail en évitant la réalisation de tâches superflues ; 11) promouvoir l auto-organisation des équipes ; 12) réfléchir régulièrement aux moyens d amélioration. Les méthodes agiles constituent davantage un guide des bonnes pratiques opérationnelles pour le développement de solutions logicielles, qu un ensemble exhaustif de règles contractuelles. Aussi existe-t-il en réalité plusieurs méthodes agiles, les plus connues étant les méthodes «Scrum», «extreme Programming» ou encore «Lean/ Kanban». Chacune de ces méthodes tente de répondre à une problématique particulière tout en s inspirant de l esprit commun du Manifeste Agile. Par exemple, la méthode «Scrum» est une méthode de gestion de projet à laquelle aucune technique particulière d ingénierie logicielle n est associée, et qui vise avant tout à renforcer l autonomie, la motivation et la collaboration de l équipe de développement avec l équipe du client. A l inverse, la méthode «extreme Programming» favorise le développement d un code de qualité en appliquant de manière rigoureuse les bonnes pratiques d ingénierie logicielle (développements pilotés par les tests, intégration des modifications plusieurs fois par jour, etc.). Cette dernière méthode se focalise un peu moins sur les cérémonies Agiles à respecter par ailleurs dans le cadre du déroulement méthodologique du projet. L APPRÉHENSION RAISONNÉE DU CHANGEMENT Les méthodes agiles sont donc plurales. Mais toutes proposent une alternative aux méthodes de gestion classiques des projets informatiques, «en cascade» ou «en V», qui sont parfois critiquées pour leur rigidité structurelle excessive interdisant la prise en compte des changements en cours de projet (2). Le principal atout revendiqué par les prestataires agiles est, en effet, de pouvoir appréhender le changement de circonstances en cours de projet. De fait, de très nombreux projets informatiques échouent et créent des préjudices parfois extrêmement lourds, parce qu un changement est survenu en cours d exécution (les projets informatiques s étendent parfois sur 12, 15 mois ou plus), soit dans les besoins du client, soit dans la complexité technique des tâches du prestataire, et que la méthode convenue n a pas permis de gérer efficacement ce changement. EXPERTISES - DÉCEMBRE 2013 415
C est dire qu un changement de circonstances, qui normalement vient déjouer les prévisions contractuelles des parties (notamment calendaires et budgétaires), est au contraire appréhendé et géré par application des méthodes agiles. D où une certaine confusion des juristes, car les projets informatiques obéissent traditionnellement à des principes qui peuvent paraître contraires à ceux du Manifeste Agile. A titre d exemple, les méthodes agiles contredisent l intangibilité des principaux éléments contractuels (périmètre fonctionnel défini, prix forfaitaire, durée bornée dans le temps, prestations définies dans une proposition commerciale initiale et sur la base d un cahier des charges avant le démarrage du projet). Les méthodes agiles proposent également une alternative au découpage du projet en phases linéaires et successives (conformément à une matrice définissant les responsabilités du client et du prestataire, chacun fournissant à tour de rôle ce qui relève de sa responsabilité). Les méthodes agiles permettent surtout la prise en compte des changements survenant en cours de contrat, dont l intégration dans le champ contractuel n est traditionnellement possible qu après une phase de renégociation où s affrontent les intérêts opposés de chaque partie (le client cherchant à inclure au forfait ce qu il interprète comme des «conséquences logiques» de ses besoins, ou encore des défauts d analyse initiale du prestataire, et le prestataire cherchant à l inverse à exclure du forfait tout ce qui ne répond pas strictement au périmètre fonctionnel et technique sur lequel il s est contractuellement engagé). C est avant tout en réaction à des difficultés bien connues des praticiens qui accompagnent leurs clients dans le cadre des contentieux judiciaires afférents aux projets informatiques, que les méthodes agiles se sont développées et se propagent de plus en plus. Les prestataires «agiles» revendiquent un taux de réussite des projets qui leur sont confiés supérieur à la moyenne essentiellement parce que les indices de mesure du succès sont différents, plus proches de la satisfaction des utilisateurs fonctionnels que de la conformité stricte à un périmètre initial. LES PIÈGES DE LA CONTRACTUALISATION AGILE Pour autant, la réalisation d un «projet agile» peut être un chemin semé d embûches, si certaines précautions ne sont pas traitées au stade de la contractualisation. Car bien que le Manifeste Agile lui-même minore l importance du contrat, en pratique tous les acteurs de l Agilité ont bien dû admettre qu ils ne peuvent faire l impasse sur l étape de la contractualisation, juridiquement indispensable. Au contraire, il est capital que le contrat reflète très précisément la méthodologie et les concepts agiles mis en œuvre, pour éviter de cruelles déconvenues ultérieures en cas de divergence d interprétation. De plus, il serait faux de prétendre que tout prestataire autoproclamé «agile» l est réellement. Pour certains, l Agilité est un argument commercial qui sert à accroître l obligation de collaboration du client, tout en déresponsabilisant le prestataire. Autre écueil encore : parfois le prestataire et le client s entendent effectivement pour mettre en œuvre un projet Agile, mais dans les faits, n appliquent pas vraiment la même Agilité Dans ces cas-là, un contrat précis permet d assurer la conformité du projet à l orthodoxie des méthodes agiles, et de revenir aux procédures convenues en cas de divergence. Dans tous les cas, il est primordial que le contrat reflète le plus fidèlement possible les principes opérationnels et organisationnels de développement en méthode agile, qui se caractérisent essentiellement par un mode de travail évolutif (1), itératif (2) et collaboratif (3). L AGILITÉ DU PÉRIMÈTRE CONTRACTUEL : DES BESOINS ÉVOLUTIFS À UN PRIX FORFAITAIRE Les méthodes agiles promeuvent une conception dynamique des projets informatiques qui se caractérise d abord au stade de la définition du périmètre contractuel (1), même en cas de «rigidité» des conditions financières (2). Le backlog, un référentiel contractuel évolutif Selon la méthode agile, le document pertinent qui définit les besoins du client, ne sera ni le cahier des charges ni la proposition technique et commerciale du prestataire, qui jouent un rôle préparatoire, mais une liste fonctionnelle élaborée de manière conjointe par les parties, appelée backlog. C est ce backlog qui constitue le document de référence sur la base duquel s effectuent l analyse de conformité des travaux, et la mesure du «reste à faire». Au sein du backlog, chaque fonctionnalité est exprimée en unité de valeur métier, pour quantifier l importance que revêt chaque fonctionnalité aux yeux des utilisateurs, et en points de complexité pour quantifier la difficulté technique de réalisation par le prestataire - et donc également ses charges, et in fine le prix à payer par le client pour le développement des fonctionnalités. Mais contrairement à un cahier des charges, le périmètre contractuel défini dans le backlog n est pas figé pour toute la durée du contrat. Il est par essence évolutif. En fonction de l état d avancement du projet, des difficultés, impondérables et autres retards rencontrés, le client pourra décider de modifier les fonctionnalités initialement commandées, en revoyant leur ordre de priorité, voire d abandonner certaines si elles sont devenues obsolètes au fil du projet ou pour y substituer de nouveaux besoins plus importants. A titre d exemple, les fonctionnalités initialement définies par les parties 416 EXPERTISES - DÉCEMBRE 2013
peuvent être modifiées par le client tout au long du projet en fonction des souhaits émis par les utilisateurs de la solution, c est-à-dire les représentants des «fonctions métiers» du client qui sont les vrais destinataires de la future solution. Dans le cas de la méthode agile «extreme Programming», ces demandes sont exprimées sous forme de «user stories» : le besoin n est pas exprimé de manière générique comme dans un cahier des charges, mais sous forme d une courte description concrète du besoin fonctionnel de l utilisateur (du type : «j aimerais réserver un billet d avion»). Les instances d arbitrage et d actualisation, et les «cérémonies agiles» dans le détail des-quelles nous n entrerons pas ici, permettent d assurer cette flexibilité. Ces cérémonies varient peu d une méthode à l autre, mais toutes organisent le copilotage du projet et la délibération du client assisté par les conseils du prestataire. En particulier, les priorisations et repriorisations des besoins métiers qui sont effectuées par le client doivent tenir compte des interdépendances et interactions des fonctions entre elles, et donc des règles de gestion qu il est indispensable de maîtriser parfaitement, et de manière consensuelle, côté prestataire comme côté client. Au stade de la rédaction du contrat, il est donc indispensable de vérifier que les spécificités de la méthode agile choisie sont bien stipulées. A cet égard, le contrat doit préciser la nature évolutive du backlog annexé : en effet, seul le dernier backlog en date, comportant les fonctionnalités retenues et priorisées, sert de référentiel de conformité pour réceptionner la solution cible. Ensuite, tout s enchaîne : le contrat doit prévoir également les modalités de rédaction et validation des spécifications fonctionnelles et techniques (qui sont menées elles aussi par courtes itérations, et qui donnent tout de suite lieu aux développements correspondants sans attendre la rédaction de l intégralité du dossier de conception). Il est donc nécessaire que le contrat définisse la durée de chaque itération, et stipule très clairement que si les dates du calendrier sont fixes, le contenu fonctionnel qui sera livré par le prestataire dépendra entièrement du stade d évolution du projet, et des arbitrages fonctionnels du client. Enfin, le contrat doit nécessairement définir les notions agiles, qui figureront de toute façon dans le PAQ, mais dont le sens doit être parfaitement compris par les deux parties. Les notions typiquement agiles de «product owner», «user stories», «démonstration», «rétrospective», «vélocité», etc., doivent être consensuelles. La possibilité du forfait face à l adaptabilité du périmètre contractuel En dépit du caractère évolutif du périmètre contractuel, les méthodes agiles ne semblent pas avoir remis en cause la pratique de réalisation au forfait des projets de développement logiciel, au grand dam de certains prestataires qui préfèrent naturellement intervenir en régie dans un contexte qui ressemble fort à une prestation d intégration continue. Il est vrai que l engagement au forfait semble a priori peu compatible avec la possibilité pour le client de faire évoluer ses besoins. Mais en pratique, on observe que les modifications du périmètre contractuel initial entraînent rarement une augmentation du prix initial, dès lors que les unités de valeurs et les points de complexité des nouvelles fonctionnalités ne dépassent pas l enveloppe globale du backlog en termes de charges. C est d ailleurs tout l enjeu de la repriorisation : le client peut toujours remplacer, au terme d un sprint, une fonctionnalité A initialement prévue, par une fonctionnalité B devenue plus pertinente, à nombre de points de complexité identique. Ainsi, les prestataires agiles s engagent sur un prix forfaitaire correspondant à un nombre de jours/hommes total, ce qui permet de faire évoluer les fonctionnalités effectivement développées dans les limites du prix forfaitaire contractuellement prévu. En clair : le résultat contractuel n est plus une liste de fonctionnalités, mais une enveloppe de complexité dans laquelle le client décide des besoins qu il privilégie. Il est possible de cumuler au sein d un même contrat un prix forfaitaire correspondant à un périmètre commandé de manière ferme, et un prix formulé au temps passé correspondant à un périmètre prospectif. C est ici l inventivité des rédacteurs de contrats qui doit parler, ainsi que l ingéniosité des parties dans l élaboration de conditions financières conformes à la méthode choisie, et respectueuses des responsabilités assumées par chacun. A titre d exemple, certains prestataires proposent des systèmes de bonus/ malus selon que l équipe respecte ou non le nombre de fonctionnalités qu il est convenu de développer par itération. En synthèse, il est donc indispensable que le contrat reflète avec précision les concepts, cérémonies, métriques, et procédures d exécution propres aux méthodes agiles. Dans ce but, le praticien veillera à se méfier de la «fausse Agilité», qu il s agisse d un argument de vente un peu expéditif du prestataire, ou d un engouement un peu superficiel du client. La meilleure recommandation possible est donc de conseiller aux clients utilisateurs de s engager dans un projet agile en connaissance de cause, informés de ces spécificités, en acceptant sciemment que le résultat fonctionnel ne sera pas forcément la solution esquissée dans son cahier des charges, et en toute hypothèse, en s appuyant sur un contrat rendant parfaitement compte de la méthodologie adoptée. L AGILITÉ DANS LA RÉALISATION DES DÉVELOPPEMENTS LOGICIELS Sur le plan technique et s agissant de la réalisation des livrables, les EXPERTISES - DÉCEMBRE 2013 417
méthodes agiles sont qualifiées d itératives car elles privilégient la répétition fréquente de cycles de courte durée comportant de manière identique toutes les étapes de développement logiciel. On parle alors d itération, ou sprint. Ainsi chaque sprint cumule les opérations de spécifications fonctionnelles, de développement puis de tests à partir des user stories, (au lieu de les échelonner dans le temps avec une première phase de spécification par le prestataire, à valider par le client, puis une phase de développement, là aussi soumise à recette il s agit là de la fameuse «navette» des projets classiques). Idéalement, chaque sprint se termine donc par la livraison d un incrément logiciel définitif, prêt à être mis en production, et qui fait l objet d une démonstration opérationnelle aux utilisateurs. En cas de non-conformité, le développement peut aussi être corrigé à l occasion du sprint suivant. La courte durée des sprints instaure donc un rythme de travail dynamique qui permet en principe de capitaliser l expérience acquise par l équipe de développement lors des sprints précédents, et de réagir rapidement en cas de réorientation du projet. Concrètement, les méthodes agiles permettent donc à chaque itération d obtenir des fonctionnalités opérationnelles et autonomes. Ainsi, même en cas de rupture anticipée du contrat, le client doit pouvoir mettre en production les parties fonctionnelles qui lui ont déjà été livrées, indépendamment du fait que la solution entière ne lui sera pas fournie. Dans ce contexte, en cas de rupture anticipée des relations contractuelles, seule la résiliation est possible, la résolution du contrat étant neutralisée par le caractère opérationnel des précédents livrables, s ils ont été recettés. La pratique n est cependant pas toujours conforme à cette théorie, car elle dépend très largement de la nature et de la complexité de chaque solution informatique cible. En outre, la succession des sprints permet normalement au client de suivre à la loupe l état d avancement du projet, de prononcer la recette partielle des livrables, de manière progressive, et de mettre à jour, en cas de besoin, les fonctionnalités du backlog. Les opérations de tests sont menées de façon collaborative sur des durées très courtes et permettent de constater et de corriger les écarts dans un délai extrêmement réduit. Le praticien qui rédige un contrat de développement en méthode agile doit donc traduire juridiquement la notion de sprint, sa durée (généralement inférieure à six semaines) et les modalités de définition et d adaptation de son contenu prévisionnel. Le contrat doit également prévoir les différentes options qui s offrent aux parties au terme de chaque sprint (à partir du retour d expérience de l équipe et en fonction des arbitrages fonctionnels du client). Le contrat doit aussi prévoir une métrique indispensable en méthode agile, la «vélocité», qui permet de mesurer le nombre de fonctionnalités développées pendant chaque sprint, et de le comparer aux prévisions contractuelles. C est cette métrique qui permet de mesurer le taux de couverture fonctionnelle, et d identifier une éventuelle dérive. Si la vélocité réelle est supérieure à la vélocité convenue, les parties doivent en identifier l origine, et «corriger le tir» en ramenant la vélocité prévisionnelle à la vélocité réelle de l équipe. Le contrat doit encore stipuler le nombre maximum de sprints envisagé pour répondre à l ensemble des besoins fonctionnels du client, tel qu exprimé dans le backlog. Au niveau de la clause de recette, la méthodologie agile imposera de rompre avec le dogme du couperet qui tombe en fin de projet ou de phase. Le rédacteur du contrat veillera à introduire des recettes partielles (parfois confondues avec les cérémonies d acceptation des fonctionnalités démontrées en fin de sprint), et de nouveaux critères de recette valorisant la conformité du livrable aux attentes actuelles et pragmatiques des utilisateurs, en conservant à l esprit que ces attentes sont susceptibles de varier dans le temps UN FONCTIONNEMENT COLLABORATIF EXIGEANT Par ailleurs, tous les projets informatiques possèdent, indépendamment de la méthode qui les gouverne, une dimension humaine capitale, impliquant des échanges réguliers entre le client et l équipe du prestataire. En fait, les méthodes agiles exigent des parties une collaboration si intense ainsi qu une implication si forte du client dans la réalisation du projet, qu elles promeuvent en générale l intégration des deux équipes au sein d une seule équipe projet, qui intervient dans un même lieu, et selon les mêmes processus. Une collaboration généralisée à tous les stades du projet Cette collaboration des parties est un impératif présent à tous les stades du projet agile. Ainsi, le client est évidemment concerné au premier chef par la définition initiale du projet en termes de fonctionnalités et d objectifs (élaboration des principes directeurs et des fonctionnalités logicielles attendues dans le backlog), puisque cela lui incombe. Il doit néanmoins solliciter le conseil du prestataire afin de réaliser les regroupements fonctionnels les plus pertinents au sein du backlog, et effectuer des priorisations efficaces. En termes de gouvernance, le client peut aussi être amené à contrôler de manière quotidienne la cohérence entre les décisions prises par l équipe au cours des sprints, et l objectif fonctionnel final (la méthode Scrum insistant sur des réunions quotidiennes). Si les sprints impliquent de travailler de manière réactive sur de courtes séquences, il ne faut jamais perdre de vue les interdépendances des fonctionnalités en cours de développement avec les fonctionnalités déjà livrées, et celles qui doivent encore être spécifiées et réalisées par la 418 EXPERTISES - DÉCEMBRE 2013
suite. D où la nécessité, surtout si le projet est complexe, d un expert fonctionnel du métier au sein de l équipe du prestataire, qui doit porter son conseil et proposer des rationalisations fonctionnelles selon les meilleures pratiques, afin que le client comme son prestataire puissent toujours remettre en perspective les travaux de chaque sprint. Cette intensité de la collaboration devra elle aussi trouver une traduction efficace sur le plan contractuel, pour assurer la bonne réussite du projet. Les parties veilleront donc à prévoir les moyens nécessaires pour leur permettre de travailler ensemble de manière efficace et conforme, là encore, à la méthode retenue. Les clauses relatives à la gouvernance du projet, aux instances de décision, et aux obligations d information et de collaboration devront donc être adaptées avec le plus grand soin pour tenir compte de cette caractéristique essentielle des méthodes agiles. La mobilisation significative des ressources du client Cette exigence de proximité renforcée entre les parties n est pas neutre d un point de vue économique. Du côté du client, la méthodologie agile suppose l affectation de ressources internes suffisantes (par exemple à mi-temps ou, idéalement de manière dédiée). Mieux vaut identifier ce coût avant la formation du contrat pour éviter de désorganiser certains services pendant la durée du projet, d autant que les préposés de la direction informatique ne sont pas les seuls impliqués dans la réalisation du projet, et qu il faut clairement prévoir que les opérationnels en charge des métiers du client devront consacrer un temps très significatif. En effet, les équipes métiers sont concernées à tous les stades du projet, de la définition des besoins fonctionnels à la validation des résultats des travaux de conception puis de développement, en passant par les tests et l émission des éventuelles réserves. De son côté, le prestataire, bien souvent seul détenteur de l'expérience et de l'expertise agile, devra être capable d assumer une part supérieure du pilotage afin de garantir la cohérence fonctionnelle et technique du projet. En réalité, l intégration des deux équipes au sein d une seule est un peu artificielle : ce qui se produit réellement, c est l intensification corrélative de l obligation de conseil du prestataire, et de l obligation de collaboration du client. Enfin, la question du transfert des connaissances devra focaliser l attention du praticien soucieux de garantir la pérennité de la solution développée. Le contrat devra donc prévoir les conditions dans lesquelles le prestataire rédigera la documentation nécessaire au fur et à mesure du projet, pour permettre au client de maîtriser la solution développée après la fin du contrat. Même si les méthodes agiles n interdisent pas toute documentation écrite, elle considère la documentation comme secondaire, et la proximité des équipes présente généralement le risque que la communication orale supplante la rédaction de la documentation. Or, s il est possible d affirmer qu en phase d intégration, le caractère opérationnel des fonctionnalités livrées est plus important que leur documentation immédiate, il ne faut jamais oublier que la solution logicielle sera ensuite exploitée dans la durée par le client, et pourra faire l objet de prestations de maintenance corrective et évolutive, qui impliquent une documentation à jour et complète. Depuis quelques années, les méthodes agiles s affirment comme un gage de réussite sérieux des projets informatiques, en renforçant la collaboration du client et du prestataire autour d une méthode de développement itérative particulièrement souple faisant une large place au changement. Toutefois, ces méthodes ne sont pas pour autant d absolues garanties de succès, des imprévus peuvent toujours conduire à l échec du projet et à de considérables préjudices. En effet d un point de vue opérationnel, les méthodes agiles comportent de nombreux avantages apparents. Notamment, l absence de référentiel strict et intangible défini par le client (type cahier des charges) favorise le développement de solutions en rupture avec les technologies existantes, tout en donnant une place centrale aux fonctionnalités concrètement attendues par les utilisateurs. Par conséquent, les méthodes agiles peuvent constituer un vecteur efficace de conduite du changement, ce qui est primordial dans la mesure où les résistances internes sont l une des raisons de l échec des projets informatiques. L adhésion de l utilisateur à une solution qui ré-pond à un cahier des charges vieux de 18 mois est moins évidente que l adhésion de l utilisateur à une fonctionnalité qu il a décrite trois semaines plus tôt, mais cela implique donc une implication considérable des métiers. Alors certes, le client peut parfois avoir l impression tenace de «faire un chèque en blanc» au prestataire, et de n avoir aucune garantie sur ce qui lui sera livré in fine. Mais d une part, la méthode implique une grande transparence et une codécision qui font du client un acteur constant du projet, et d autre part, le découpage en courtes séquences supprime l effet tunnel pour réduire le risque de mauvaise surprise au stade de la recette de l entière solution. C est de cette implication du client, de sa DSI mais aussi de ses utilisateurs métiers que dépend, sinon le succès du projet - car le conseil et le coaching agile du prestataire y font beaucoup également - à tout le moins l absence de déconvenue tardive au moment où le temps perdu et l énergie consacrée au projet ne peuvent plus être rattrapés. Néanmoins, les caractères transparent, itératif, évolutif et collaboratif des méthodes agiles ne constituent pas une garantie de succès, pour les raisons susmentionnées, et parce que les impératifs classiques de cadrage initial (études d avant-projet), de EXPERTISES - DÉCEMBRE 2013 419
conduite du changement, et d accompagnement juridique, demeurent indispensables comme dans le cadre des méthodes classiques. On dit parfois que l Agilité ne conviendrait qu aux clients indécis dont les besoins fonctionnels ne sont pas encore mûrs. C est excessif, car elles permettent tout aussi bien de mener à terme un projet dont le client a clairement conçu, dès le début et de manière pérenne, le périmètre précis de ses besoins. Il ne s agit là que de méthodes : l objectif demeure d équiper le client d une solution informatique qui va lui permettre de réaliser des gains de productivité et de rationaliser ses processus au mieux. Pour être pleinement efficaces, les méthodes agiles impliquent donc une évolution des mentalités au sein de l entreprise, et de son conseil. On ne saurait trop insister sur le fait que le contrat stipule le plus fidèlement possible les principes opérationnels de développement logiciel en méthode agile. Ces méthodes agiles doivent être appréhendées par les professionnels du droit, dans le but de leur conférer une traduction juridique et contractuelle pertinente et efficace pour les entreprises qui y recourent, qu il s agisse des prestataires informatiques ou des clients utilisateurs. Thomas BEAUGRAND Avocat associé Jean-Baptiste BELIN Avocat collaborateur Staub & Associés (1) Le Manifeste Agile est consultable sur http:// www.agilemanifesto.org (2) Pour une présentation plus détaillée des différences existantes entre les méthodes agiles et les méthodes d organisation traditionnelles, voir l article «Les Méthodes Agiles : de la souplesse dans les projets informatiques», publié en deux parties (le 26 novembre 2011 puis le 11 janvier 2012) sur le blog Immateria (http://www.immateria.fr), ainsi que l article publié par E. Varet et S. Leriche dans le numéro de mai 2012 de la revue Expertise sous le titre : «Méthodologie Agile et contrats de développement : révolution ou adaptation?». 420 EXPERTISES - DÉCEMBRE 2013