La méthode Agile repose sur des principes fondamentaux, consacrant la souplesse et l’évolutivité des projets. Ces caractéristiques peuvent paraitre contradictoires avec certaines règles de base du droit des contrats à propos du périmètre contractuel.
La délimitation du périmètre contractuel illustre bien cette possibilité.
Quelle est la vision « classique » du contrat informatique ?
Le périmètre contractuel d’un projet informatique est défini dans le contrat informatique, afin d’assurer la sécurité juridique et la prévisibilité budgétaire. Cela passe donc par une phase préparatoire rigoureuse permettant de fixer les spécifications du projet. Toutes ces caractéristiques seront alors traduites dans un cahier de charges intégré au contrat.
Si les spécifications sont bien définies et les objectifs du projet bien intégrés, cette approche permet un encadrement juridique solide.
Toutefois, l’inconvénient de la méthode réside dans le caractère figé des spécifications, qui enferment l’exécution du projet dans une voie prédéfinie.
Toute modification en cours de phase d’exécution se traduira par des « change requests ». Ces derniers sont plus ou moins faciles à mettre en œuvre selon les procédures contractuelles convenues. Les modifications ainsi opérées exposent alors à une renégociation des prix, ce qui peut rendre la gestion budgétaire du projet plus aléatoire.
Qu’en est-il du périmètre contractuel en méthode Agile ?
Lorsque le projet est conduit en mode Agile, le périmètre contractuel est défini d’une manière ouverte. Il est sujet à discussion et ajustements lors de chaque itération de la phase de développement.
Au-delà de la question juridique que pose cette grande flexibilité de l’objet contractuel, il convient également d’en tenir compte dans la mise en œuvre du contrat.
Les éléments clés du processus Agile doivent être établis avec soin, afin que les attentes du client et la conformité du travail fourni puissent être appréciés sur des bases claires. Ainsi, le « Product Backlog » doit faire l’objet d’une attention particulière puisqu’il sera utilisé pour baliser tout le processus de développement. Sa structure et la clarté des points à développer sont donc à soigner.
Le « Product Vision » permet, quant à lui :
- de définir les grands objectifs du projet et, dès lors,
- de potentiellement orienter toute l’interprétation d’un point non clairement défini.
Ces deux documents sont essentiels dans le processus Agile et leur rédaction initiale est donc importante. La position de ces documents dans la hiérarchie des documents contractuels doit également être précisée.
Enfin, le caractère évolutif de l’objet contractuel impose une vigilance accrue tout au long du processus de développement, afin de s’assurer que toutes les décisions portant sur la définition de l’objet et ses ajustements soient clairement documentées dans les comptes-rendus validés par les deux parties.
Notre conseil :
Les méthodes Agile offrent une grande flexibilité en vue d’atteindre les objectifs poursuivis par le contrat.
Il est donc possible de changer certains aspects du produit final pendant l’exécution du contrat.
Afin de sécuriser le processus de développement par rapport aux attentes du client et à leur compréhension par le prestataire, il est essentiel de bien intégrer le processus Agile dans le contrat (notamment les étapes et le rôle des parties lors des moments clés où se discute la mise à jour du Product Backlog).
Si vous désirez approfondir le sujet, consultez la page dédiée aux méthodes Agile !
