Méthodes Agiles : un équilibre contractuel remis en cause? Jonathan Rofé Matinales IPT DLA Piper Paris 24 mars 2011
Rappel Définition: Méthodes de conception de logiciel qui, favorisant une approche pragmatique, se concentrent sur la satisfaction de ce que VEUT le client, et non sur ce qu il VOULAIT. Il s agit de mieux réagir aux demandes évolutives du client, et donc de l impliquer en sollicitant sa validation permanente Genèse Premières méthodes à la fin des années 80-Début 90 1991 : James Martin propose une méthode de développement rapide mettant en œuvre un principe adaptatif et fondé sur la validation permanente des utilisateurs (RAD) Deuxième vague entre 94 et 2001 : une dizaine de méthodes 2001 : The Agile Manifesto : 17 experts des méthodes trouvant des valeurs communes à leurs méthodes 2
Capgemini 11 mars 2011 3
Un mode opératoire singulier 1/2 Les "itérations" Fonctionnalités priorisées Blocs de fonctionnalités testables de manière autonome Développement/Test/Amélioration/Développement (boucle) L équipe Les utilisateurs finaux sont intégrés à l équipe (pas de "chambre noire") Groupe de travail a le pouvoir de décision Validation permanente des demandes et des spécifications Le pilotage du projet Réalisation en jalons/itérations/time boxing Pilotage par les enjeux/risques Hiérarchisation des besoins 4
Un mode opératoire singulier 2/2 Recette Une recette multi-itérations Fonctionnalités priorisées Blocs de fonctionnalités testables de manière autonome Un référentiel «mouvant» Gouvernance La réactivité est la clef du succès Risques de blocage La décision n appartient pas à quelques-uns seulement 5
Une répartition des rôles inhabituelle MOE/MOA intégrées en phase de réalisation Co-pilotage/co-working mène le projet Interdépendance des obligations Concept de MOE affaibli La collaboration érigée en dogme La collaboration, obligation fondamentale dans les contrats IT (et rappelée régulièrement par la jurisprudence).est l'essence même des "projets Agile"! Impact sur la portée des obligations (Obligation de résultat/moyens) 6
Une nouvelle répartition des risques 1/3 Les principaux risques des projets IT : évolution du périmètre mauvaise appréciation de la complexité des tâches dérapages de calendrier sont inhérents aux méthodes Agiles: l'évolution du périmètre fait partie du projet notions d'unité de Valeur/Backlog: la valeur des fonctionnalités est définie par le besoin et non par leur coût - les priorités sont revues en permanence le calendrier est circonscrit ("time boxing") contraintes fortes sur le client 7
Une nouvelle répartition des risques 2/3 Recette = validation de l'obligation de délivrance conforme Quel mécanisme de recette? Principes itératifs v. recette globale Quel référentiel de conformité? Le cahier des charges du client n'est plus la bible.ni la proposition du prestataire C est quoi un manquement contractuel? Multiplication des risques de blocage du projet? 8
Une nouvelle répartition des risques 3/3 La méthode est plutôt source de dilution de risque pour le Prestataire d'un point de vue opérationnel: Rôle primordial du client à tous les stades du projet Référentiel de conformité évolutif et peu formalisé Une MOA «impliquée» Une MOE «partagée» mais le risque financier demeure difficile à appréhender Le forfait semble être un concept contradictoire avec les principes de la méthode Agile (l évolution du besoin est prise en compte) Solutions: Mécanisme de révision : «le forfait agile» Régie plafonnée Obligations de renégocier en fin de forfait ou de plafond Limitation du nombre d'itérations 9
Peut-on utiliser nos contrats standards usuels? Risques opérationnels Le contrat ne reflète pas la réalité opérationnelle Le client n a pas conscience du niveau d implication nécessaire Les attentes sont erronées (Cahier des charges) Risques financiers Pour le prestataire: forfait VS forfait «AGILE» Pour le client: les évolutions de périmètre vont inciter à la "production" d avenants Risques juridiques La réalisation du projet se fera en dehors des «clous» contractuels Quelle interprétation : le contrat ou la pratique? 10
Une évolution nécessaire des mentalités Le client doit assumer la dilution de la responsabilité du prestataire Le prestataire doit veiller à ne pas appliquer les méthodes Agiles à tous les projets La méthode devenant structurante dans la réussite du projet, elle devient facteur de réussite ou d échec avec tous les clients Clients matures, compétents et avec des équipes La zone de risque financière reste difficile à appréhender contractuellement 11
Annexe Exemple de clauses impactées par le recours à une méthode Agile
Quelles clauses impactées? Préambule Raconter l histoire du projet Définitions Spécifications, Itérations, etc. Hiérarchie contractuelle Le cahier des charges ne doit pas être la bible.ni la proposition du prestataire? Gouvernance Le processus de décision doit être simplifié Les utilisateurs doivent être impliqués très en amont 13
Quelles clauses impactées? Recette La clause doit décrire le processus: Développement/Test/Amélioration/Développement (boucle) Conditions financières Réfléchir à des mécanismes permettant de sécuriser le prix pour le client et le prestataire Ex: limitation du nombre d itérations Responsabilité Obligation de résultat? Garantie, Réversibilité, 14