En matière de développement informatique, la méthode classique en « V » modèle a révélé ses limites. Pour les grands projets, la méthode Agile serait-elle de nature à mieux répondre aux besoins du client ? Hervé Gabadou, avocat associé du cabinet Courtois Lebel fondateur et coresponsable du département Informatique et réseaux, en expose les avantages et les limites.

En matière de développement informatique, la méthode classique en « V » modèle a révélé ses limites. Pour les grands projets, la méthode Agile serait-elle de nature à mieux répondre aux besoins du client ? Hervé Gabadou, avocat associé du cabinet Courtois Lebel fondateur et coresponsable du département Informatique et réseaux, en expose les avantages et les limites.

Il n'y a pas une mais plusieurs méthodes relevant de l'agilité (1). Héritage du 20e siècle, la méthode Agile vise à réduire le temps nécessaire à la réalisation de développements logiciels. En 2001, le Manifeste Agile, recensant les douze principes du développement logiciel, naquit de l'initiative de 17 personnes. Le postulat de départ de l'agilité : l'incapacité du client à définir ses besoins de manière exhaustive et un environnement technologique instable. L'agilité renvoie à la capacité d'adaptation aux changements de contexte et à l'évolution des besoins. Pour le juriste qui est habitué aux projets réalisés selon une méthode classique en « V » modèle, et de ses échecs, l'agilité présente de nombreuses vertus, dont un devoir de transparence et de collaboration, et un écueil important : l'absence de référentiel stable pour déterminer l'obligation de délivrance du prestataire et le calendrier de réalisation. 

Une collaboration étroite érigée en principe de fonctionnement

Elle semble d'ailleurs reposer sur un paradoxe : l'aveu primordial d'une expression  de besoins insuffisante et la volonté d'atteindre malgré tout une certaine exhaustivité de ces besoins au fil de l'eau d'un développement itératif et incrémental. En réalité, c'est une collaboration étroite érigée en principe de fonctionnement et une gouvernance adéquate qui cautionnent cet objectif.
La réponse à cette question n'est pas binaire. Quelle méthode Agile pour quels grands projets ? Les caractéristiques de cette méthode impliquent une très grande disponibilité des équipes métiers et un niveau de compétence qui ne sont pas à la portée de toutes les équipes de projet de la maîtrise d'ouvrage :
- le développement du code sur la base de cas d'utilisation ;
- une interaction très forte des équipes métier, qui se traduit par des programmations en binôme ;
- des utilisateurs impliqués très tôt dans le projet ;
- et une fréquence de livraisons élevées.
Une autre question se pose : est-elle davantage adaptée à des projets dont la caractéristique est de reposer sur une très grande part de développements spécifiques plutôt que sur de simples paramétrages  d'une solution largement « packagée » ?

Le développement itératif privilégié

On sait que l'agilité privilégie le développement itératif à une documentation abondante. Elle requiert une gouvernance de projet adéquate, la présence d'un plan de développement de projet suivi et mis à jour rigoureusement.  Le juriste veillera à ces aspects au moment de rédiger les contrats qui sous-tendent ces projets. Quelles sont cependant les incidences de cette méthode sur l'exploitation de la solution informatique en « l'état futur d'achèvement », si celle-ci doit être infogérée  ultérieurement?  Comment sera assurée la tierce maintenance applicative dans ces conditions? Est-ce à dire que la maîtrise d'œuvre interne au client doit être omniprésente, aux côtés de ses « métiers », pour bénéficier d'un transfert de compétence au fil de l'eau à défaut de documentation complète ? On commence à mesurer les limites de cette méthode pour l'adapter à tous projets.
 
Vers une méthode combinant le meilleur des deux modèles ?

De fait, la réponse à cette question relève du bon sens. La complexité du projet, la compétence, la culture de l'entreprise, la maturité et la disponibilité des équipes, seront autant d'indicateurs pour le choix en faveur de l'une ou de l'autre méthode. Un vrai travail de qualification sera indispensable en amont du projet. On notera néanmoins, non sans un certain amusement, que les projets réalisés selon la méthode en « V » et les contrats y afférents, qui sont censés être un rempart contre les dérives de projet, échouent encore souvent par manque d'implication, une expression des besoins déficiente et une gestion conflictuelle de l'évolution des besoins de la maîtrise d'ouvrage, compte tenu d'une trop grande rigidité (voire déséquilibre) des contrats.
Ne serions-nous pas plutôt avisés de proposer une méthode combinant le meilleur des deux modèles ?

1) La méthode de développement rapide (RAD), la méthode DSDM (Dynamic, Software Development Method), la méthode du Processus Unifié (UP), la méthode RUP (Rational Unified Process), la méthode XP – extreme Programming, la méthode Scrum, la méthode FDD (Feature Driven Development), la méthode ASD (Adaptive Software Development, etc.)


------
Fondé en 1969, Courtois Lebel est un cabinet d'avocats d'affaires qui offre à ses clients des services dans les principaux domaines du droit des affaires avec une réelle ouverture internationale. Les avocats sont spécialistes des dossiers complexes, mais enracinés dans la réalité économique et à la recherche de solutions pratiques.
Le cabinet est organisé autour de 8 pôles d'expertise : Corporate et M&A, Concurrence distribution et droit commercial, Fiscal, Social, Propriété Intellectuelle, Réglementation bancaire et assurance, Informatique et réseaux, Contentieux des affaires.
Courtois Lebel est membre d'AEL, réseau de cabinets d'avocats européens, et d'ALFA, réseau international regroupant 9500 avocats dans le monde.