d o c t r i n e

EXPERTISES - DÉCEMBRE 2013 415

Un peu de douceur dans un monde de brutes ?

Les « méthodes Agiles » consacrent une philosophie de travail évolutive et prag-matique reposant sur quatre

valeurs et douze principes énoncés par le Manifeste Agile, rédigé en 2001 par plusieurs experts de l’ingénie-rie logicielle (1), en partant du constat selon lequel une part importante des échecs industriels en matière informa-tique 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éve-loppement 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éfi-nissent 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

Logiciel Le contrat de développement logiciel en méthode Agile

un avantage compétitif pour le client ; 3) livrer fréquemment une applica-tion fonctionnelle, idéalement toutes les deux semaines ; 4) faire collabo-rer 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’avan-cé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 logi-cielles, 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éma-tique 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’auto-nomie, la motivation et la collabora-tion 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’in-génierie logicielle (développements pilotés par les tests, intégration des modifications plusieurs fois par jour, etc.). Cette dernière méthode se foca-lise un peu moins sur les cérémonies Agiles à respecter par ailleurs dans le cadre du déroulement méthodolo-gique 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 conve-nue n’a pas permis de gérer efficace-ment ce changement.

EXPERTISES - DÉCEMBRE 2013416

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 informa-tiques 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 contrac-tuels (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 égale-ment une alternative au découpage du projet en phases linéaires et successives (conformément à une matrice définissant les responsabili-té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 chan-gements survenant en cours de contrat, dont l’intégration dans le champ contractuel n’est traditionnel-lement 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 cher-chant à 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 prati-ciens qui accompagnent leurs clients dans le cadre des contentieux judi-ciaires afférents aux projets informa-tiques, que les méthodes agiles se sont développées et se propagent de plus en plus.

Les prestataires « agiles » reven-diquent 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 fonction-nels 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écau-tions 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 contrac-tualisation, juridiquement indispen-sable. 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 autoprocla-mé « 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’en-tendent 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èle-ment possible les principes opéra-tionnels et organisationnels de déve-loppement 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 docu-ment 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’ana-lyse de conformité des travaux, et la mesure du « reste à faire ».

Au sein du backlog, chaque fonction-nalité 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 presta-taire - 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 fonctionna-lité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

EXPERTISES - DÉCEMBRE 2013 417

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 Program-ming », ces demandes sont expri-mé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’actua-lisation, et les « cérémonies agiles » dans le détail des-quelles nous n’en-trerons pas ici, permettent d’assu-rer 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 presta-taire. 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 fonc-tions 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éren-tiel 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éci-fications fonctionnelles et techniques (qui sont menées elles aussi par cour-tes 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 clai-rement 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 figu-reront de toute façon dans le PAQ, mais dont le sens doit être parfaite-ment compris par les deux parties. Les notions typiquement agiles de « product owner », « user stories », « démonstration », « rétrospec-tive », « 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 naturel-lement 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 compa-tible avec la possibilité pour le client de faire évoluer ses besoins. Mais en pratique, on observe que les modifications du périmètre contrac-tuel 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 fonction-nalité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 initiale-ment 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 correspon-dant à 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 forfai-taire correspondant à un périmètre commandé de manière ferme, et un prix formulé au temps passé corres-pondant à 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’éla-boration de conditions financières conformes à la méthode choisie, et respectueuses des responsabi-lité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 fonctionnali-tés qu’il est convenu de développer par itération.

En synthèse, il est donc indispen-sable que le contrat reflète avec précision les concepts, cérémonies, métriques, et procédures d’exécu-tion 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éthodo-logie adoptée.

L’AGILITÉ DANSLA RÉALISATION DES DÉVELOPPEMENTS LOGICIELS

Sur le plan technique et s’agissant de la réalisation des livrables, les

EXPERTISES - DÉCEMBRE 2013418

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 iden-tique toutes les étapes de développe-ment logiciel. On parle alors d’itéra-tion, ou sprint.

Ainsi chaque sprint cumule les opéra-tions 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éra-tionnelle 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évelop-pement 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éra-tion 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 rela-tions contractuelles, seule la rési-liation 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érale-ment inférieure à six semaines) et les modalités de définition et d’adapta-tion 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’identi-fier une éventuelle dérive. Si la vélo-cité réelle est supérieure à la vélocité convenue, les parties doivent en iden-tifier 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 coupe-ret qui tombe en fin de projet ou de phase. Le rédacteur du contrat veille-ra à introduire des recettes partielles (parfois confondues avec les cérémo-nies d’acceptation des fonctionnalités démontrées en fin de sprint), et de nouveaux critères de recette valo-risant la conformité du livrable aux

attentes actuelles et pragmatiques des utilisateurs, en conservant à l’es-prit que ces attentes sont susceptibles de varier dans le temps…

UN FONCTIONNEMENT COLLABORATIF EXIGEANT

Par ailleurs, tous les projets informa-tiques possèdent, indépendamment de la méthode qui les gouverne, une dimension humaine capitale, impli-quant 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’in-tégration des deux équipes au sein d’une seule équipe projet, qui inter-vient 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 évidem-ment concerné au premier chef par la définition initiale du projet en termes de fonctionnalités et d’objec-tifs (élaboration des principes direc-teurs 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 fonc-tionnels 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 fonc-tionnel final (la méthode Scrum insis-tant 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évelop-pement avec les fonctionnalités déjà livrées, et celles qui doivent encore être spécifiées et réalisées par la

EXPERTISES - DÉCEMBRE 2013 419

suite. D’où la nécessité, surtout si le projet est complexe, d’un expert fonc-tionnel du métier au sein de l’équipe du prestataire, qui doit porter son conseil et proposer des rationalisa-tions fonctionnelles selon les meil-leures 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 traduc-tion 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 obli-gations d’information et de collabo-ration 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é renfor-cé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 infor-matique ne sont pas les seuls impli-qué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 concep-tion 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 garan-tir la cohérence fonctionnelle et tech-nique du projet. En réalité, l’intégra-tion des deux équipes au sein d’une seule est un peu artificielle : ce qui se produit réellement, c’est l’intensi-fication corrélative de l’obligation de conseil du prestataire, et de l’obliga-tion de collaboration du client.

Enfin, la question du transfert des connaissances devra focaliser l’at-tention du praticien soucieux de garantir la pérennité de la solu-tion 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éve-loppé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 docu-mentation. Or, s’il est possible d’af-firmer qu’en phase d’intégration, le caractère opérationnel des fonc-tionnalités livrées est plus important que leur documentation immédiate, il ne faut jamais oublier que la solu-tion logicielle sera ensuite exploitée dans la durée par le client, et pourra faire l’objet de prestations de main-tenance 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 particu-liè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ération-nel, 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 exis-tantes, 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 effi-cace 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’utilisa-teur à 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 presta-taire, 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 utilisa-teurs 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’éner-gie consacrée au projet ne peuvent plus être rattrapés.

Néanmoins, les caractères transpa-rent, 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 2013420

conduite du changement, et d’accom-pagnement 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’équi-per le client d’une solution informa-tique qui va lui permettre de réaliser des gains de productivité et de ratio-naliser 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ération-nels 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 infor-matiques ou des clients utilisateurs.

Thomas BEAUGRAND Avocat associéJean-Baptiste BELIN Avocat collaborateurStaub & 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 tradition-

nelles, 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éve-

loppement : révolution ou adaptation ? ».