Révolution relativement récente dans le monde de l’industrie informatique (leurs premières manifestations sont apparues à la fin des années 90), les « Méthodes Agiles » sont des méthodes organisationnelles et opérationnelles qui gagnent en notoriété depuis quelques années et investissent à présent tous les domaines de l’activité logicielle, depuis la réalisation d’un site internet jusqu’aux plus grands projets d’intégration/déploiement de progiciels de gestion (ERP).
media_file_144

Bien que plusieurs écoles existent (« Xtreme Programming », « Scrum »), ces méthodes renvoient toutes au « Manifeste Agile » rédigé en 2001 par une quinzaine d’experts de l’ingénierie logicielle.

A partir du constat selon lequel certains échecs industriels seraient dus à une trop grande rigidité méthodologique et juridique, ces experts soulignent que l’adaptabilité des processus de développement s’avère vitale lorsque l’entreprise se lance dans un projet au long cours – surtout en période de crise économique, et dans des domaines technologiques qui se renouvellent tous les deux ou trois ans.

Si ces experts ont développé des méthodes opératoires pour renforcer les chances de succès des projets informatiques, les juristes en charge de rédiger les contrats IT doivent alors impérativement les appréhender et les traduire en termes juridiques, afin que le contrat ne contredise pas la réalité du terrain : si amélioration il y a, le contrat doit la prendre compte et lui donner force.

L’objet de l’étude qui suit n’est pas d’explorer en détail les subtiles distinctions entre les nombreuses méthodes de gestion de projet qui foisonnent depuis une vingtaine d’années, mais de souligner les principales innovations induites par les Méthodes Agiles, par rapport aux méthodes traditionnelles que le praticien sait traduire en engagements contractuels. Il est donc question de montrer quelques pistes pour que le droit s’adapte à la réalité opérationnelle du projet.


1. Les principes de l’Agilité

Les principes fondamentaux des Méthodes Agiles sont les suivants : « des individus et des interactions, plutôt que des processus impersonnels et des outils génériques » ; « des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive » ; « une collaboration poussée avec le client plutôt que la contractualisation stricte du projet » ; « l’acceptation d’un changement bien conçu plutôt que la conformité rigoureuse à des plans parfois caducs ».

Il s’agit donc d’une émanation très pragmatique, issue de l’expérience des techniciens plutôt que d’une théorie abstraite. Les Méthodes Agiles s’expriment sous la forme de préceptes proches du mantra : livrer fréquemment des modules opérationnels, pratiquer un contrôle qualité permanent, privilégier la cohésion des équipes, leur contact direct et leur auto-organisation, notamment.

Le premier avantage revendiqué par les promoteurs des Méthodes Agiles consiste à accueillir favorablement le changement en cours de projet, quelle qu’en soit l’origine. D’où peut survenir le changement ? D’une part, de la mutation des besoins du client ou de son contexte économique, en cours de projet. D’autre part, de l’apparition de difficultés analytiques ou techniques en cours de développement.

Les juristes connaissent parfaitement ces deux phénomènes : ils les analysent depuis des années en tant que fautes contractuelles, génératrices de dommages et intérêts. En effet, le client commet une faute contractuelle s’il éloigne ses demandes du périmètre fonctionnel initialement défini, car il déjoue ainsi les prévisions techniques et budgétaires de son cocontractant. En face, le prestataire est responsable d’un défaut de délivrance conforme s’il dépasse les délais ou échoue à corriger les anomalies et non-conformités du produit… Et l’évolution jurisprudentielle a renforcé l’intensité des obligations du prestataire, notamment via la théorie des obligations essentielles comme l’illustre par exemple l’affaire Faurecia. Au premier abord, les préceptes de l’Agilité pourraient donc paraître inconsistants, voire dangereux, aux yeux du juriste.

Mais dans les faits, ces changements existent. Sur un projet qui s’étend parfois sur douze ou quinze mois, le besoin du client va très probablement évoluer. Et des complications techniques sont toujours possibles. A partir de ce constat, les Méthodes Agiles ont été pensées pour intégrer le paramètre « changement » dans la feuille de route du projet IT. Le nombre d’entreprises qui y recourent (prestataires comme clients) démontre aujourd’hui leur efficacité. Il s’agit bien d’une alternative concrète aux méthodes habituelles de gestion de projet. Les Méthodes Agiles contredisent donc plusieurs schèmes classiques, et prônent une intensification de la collaboration entre équipes du client et du prestataire, pour un copilotage efficace et réactif, plus axé sur la qualité que sur la conformité.

Le juriste ne doit donc plus appréhender le changement comme cause d’une dérive calendaire, mais comme l’un des paramètres évolutif que les parties ont accepté par contrat. De même, le juriste doit accepter que le contrat ne régisse pas tous les process, mais en pose uniquement les principes opératoires. L’on soulignera toutefois qu’aussi pertinentes qu’elles puissent être sur le terrain, ces méthodes ne peuvent suppléer la signature du contrat, surtout au regard des enjeux financiers. Mais le juriste doit se départir d’un certain nombre de dogmes et de réflexes, afin de mettre son encadrement contractuel au diapason de la pratique adoptée. En effet, si les Méthodes Agiles ne constituent pas automatiquement une garantie de succès, au moins semblent-elles proposer de nouveaux concepts et supprimer des conflits à l’origine de lourds préjudices, ce que le praticien ne peut ignorer.

 

2. Les dangers du changement de physionomie du projet IT

Dans un contexte classique, le projet d’informatisation (ou plus souvent aujourd’hui, de modernisation du système d’information, mais nous visons également ici tout projet technologique notamment dans les secteurs de l’internet et des communications électroniques) obéit à un corpus de règles relativement figé.

Traditionnellement, les projets IT sont menés en mode cascade, c’est-à-dire par étapes linéaires et successives. Schématiquement, une navette s’instaure entre le client et le prestataire, chacun fournissant à tour de rôle ce qui relève de sa responsabilité : émission des besoins du client, spécifications techniques puis développement et intégration aux soins du prestataire, tests et recette du client, jusqu’au déploiement de la solution cible décrite dès le lancement du projet. Certes les méthodes de travail sont parfois plus complexes que la présentation sommaire ici dressée, mais pour le praticien, le contrat IT reflète toujours en dernière analyse le caractère unilatéral des travaux informatiques.

Ainsi, le contrat IT comporte souvent une matrice de répartition des tâches, qui va détailler les responsabilités incombant au client (expression de son besoin, fourniture des contenus spécifiques, exposé de ses contraintes métier, préparation des données à migrer…) et celles incombant au prestataire (analyse préalable, spécifications techniques et fonctionnelles, etc.).

Ainsi, avant de sélectionner son prestataire, le client identifie son besoin et tente de le définir, d’autant plus clairement qu’il dispose d’une Direction Informatique en son sein. Il s’agit là d’une étape critique où réside l’origine de nombreux contentieux : l’expression des besoins est cruciale, qu’il s’agisse de choisir un ERP, d’installer un PABX, de commander le développement d’un logiciel spécifique ou de réaliser un site de commerce en ligne.

Le client connaît son métier, ses besoins et ses contraintes ; le prestataire connaît quant à lui la technologie en vigueur, l’état de l’art, et les qualités de ses produits. C’est donc au client de synthétiser ses besoins et ses pré-requis dans un document techniquement et juridiquement valide, traditionnellement exhaustif, en sollicitant éventuellement l’assistance d’un professionnel (AMOA). Il appartient ensuite au prestataire d’évaluer sa capacité à répondre à ce besoin.

Le contrat IT fait souvent de cette expression initiale des besoins le premier référentiel de conformité, placé en annexe. Le client a donc tendance à la définir le plus précisément possible. Or, il doit surtout penser son projet IT dans une optique dynamique. En effet, trop d’entreprises se contentent d’effectuer un bilan de leurs besoins au moment où elles lancent le projet, et acceptent une proposition commerciale qui y correspond à l’instantT. Si le besoin du client évolue, la proposition du prestataire devient rapidement inadéquate, et ce dernier se retrouve pris entre deux feux : d’une part la nécessité de satisfaire son client, voire de répondre à son engagement de résultat… et d’autre part l’équilibre budgétaire de sa proposition – surtout si celle-ci est forfaitaire. On ne compte plus les projets informatiques au forfait qui tournent à l’intégration continue… et ruinent les capacités du prestataire. Le client et le prestataire s’affrontent alors pour qualifier les demandes, parfois extrêmement nombreuses, entre « corrections dans le périmètre convenu » et « demandes nouvelles hors périmètre », « demandes évolutives », « nouveaux besoins »…

En cas de contentieux, le prestataire dénoncera un manque de définition des besoins, imputable aux choix trop peu prospectifs du client. Celui-ci fustigera l’incompétence technique du prestataire, l’insuffisance de son analyse préalable, ou encore des engagements contractuels irréalistes voire dolosifs. Parfois, les griefs sont fondés, et il revient au praticien de les démontrer devant le juge afin d’obtenir l’indemnisation de son client, qui a consommé ses ressources en vain.

Mais l’entreprise qui définit son projet IT doit impérativement prévoir les hypothèses d’évolution de ses demandes et calquer l’expression de ses besoins informatiques sur ses propres perspectives de développement commercial ou industriel. Un exercice qui s’avère plutôt ardu dans un contexte linéaire classique. Comme on va le voir, les Méthodes Agiles proposent à l’inverse une gestion de projet itérative et collaborative : au lieu de laisser le client décider seul de ses besoins, avec plus ou moins de bonheur, le prestataire participe à ses côtés, dès le début du projet, à un travail de spécification fonctionnelle afin de définir de façon évolutive le besoin réel du client et de faire évoluer le projet en fonction de l’évolution de ces besoins. Dès lors, le praticien comprend qu’il doit abandonner la notion de « matrice de répartition des tâches », car celles-ci seront gérées de façon très différente, conjointement et simultanément.

(à suivre)

 

Pour aller plus loin : Agile Tour Paris 2014 avec Thomas Beaugrand
« Contractualisation Agile, contentieux et médiation »

« Contractualisation Agile, de sa rédaction au contentieux »