doctrine
Logiciel
Le contrat de développement
logiciel en méthode Agile
U n p e u d e d ouceur dans un monde de brutes ?
L
es « 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
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
EXPERTISES - DÉCEMBRE 2013
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.
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 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.
416
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).
EXPERTISES - DÉCEMBRE 2013
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
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
EXPERTISES - DÉCEMBRE 2013
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É DANS
LA RÉALISATION
DES DÉVELOPPEMENTS
LOGICIELS
Sur le plan technique et s’agissant
de la réalisation des livrables, les
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 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.
418
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
EXPERTISES - DÉCEMBRE 2013
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
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.
EXPERTISES - DÉCEMBRE 2013
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
419
 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
420
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 collaborateur
Staub & Associés
EXPERTISES - DÉCEMBRE 2013
(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 ? ».