Méthodes agiles : le renouveau des relations client / fournisseur dans l'ingénierie
Replacer le donneur d'ordre au coeur du cycle de développement d'un projet informatique, en instaurant des relations de collaboration avec le fournisseur. C'est, dans la théorie, l'un des principaux défis que doivent relever les méthodes agiles. Un concept de gestion de projet – pas uniquement informatique d'ailleurs – dont le but est de trancher avec le cycle classique de l'ingénierie logicielle, en instaurant notamment, par le biais de courtes étapes – on parle d'itération -, une relation de confiance entre prestataires et clients.
Si le principe d'agilité repose sur un manifeste très théorique élaboré dans les années 90, son application dans le cadre de projet logiciel n'en demeure pas moins très concret. Les méthodes agiles reprennent ainsi ce manifeste, mettant l'accent notamment sur la qualité du code, la planification et le pilotage du projet.
Le principe d'agilité consiste ainsi à faire évoluer le développement d'un produit en découpant son élaboration en de courtes étapes, qui débouchent, chacune inévitablement sur un livrable fonctionnel. Ces courtes « itérations », dont la durée est fixe, autorisent alors le client à intervenir en cours de projet pour redéfinir ses besoins en matière de fonctionnalités ou les priorités du projet. « L'agilité réside alors dans la façon de s'adapter au contexte et aux besoins des clients », souligne Mariano Boni, directeur technique de Dreamsoft-Solucom group, un cabinet de consultants expert en méthode agile. Le tout est « cimenté par une gestion des rôles – définis en amont - , de la communication et des échanges entre les membres des équipes » côté fournisseur. Mais également côté client qui doit alors ré-évaluer, avec l'équipe en place, ses besoins à chaque itération. Ces principes sont définis dans une méthode, qui décrit les mécanismes de déroulement d'un projet.
Parmi ces méthodes, on compte notamment Scrum et XP (Extreme Programming), qui se distinguent clairement. Toutes deux commencent à gagner en crédibilité sur le marché (voir l'encadré Les méthodes agiles : panorama et répartition).
Une pression du changement prise en compte
Principal résultat recherché : la réduction des cycles de développements et de déploiement. Du fait de la fréquence des interactions, le livrable est généralement conforme aux besoins du client et les objectifs métiers sont abordés dès le départ du projet. Autant de bénéfices qui tranchent avec le modèle classique, commente Oana Juncu, directeur de projet chez Sfeir, SSII française spécialisée dans les développements Web, qui explique qu' « aujourd'hui, les projets sont davantage soumis à la pression du changement, rendant difficile la mise en place de lourdes procédures de cahier des charges à rallonge, d'intervenants extérieurs multiples, sans compter les inévitables oublis. Le produit développé est ainsi réglé par des itérations fixes, avec des périmètres définis. Et, à la fin de chaque itération, le produit, soumis alors à des points de contrôle, doit fonctionner. »
La modèle classique dit en cascade agit sur de longs processus, impliquant alors une incapacité de faire évoluer les besoins. « Alors qu'inévitablement, on sait que sur un long projet, les besoins fonctionnels du client vont murir, souligne Oana Juncu. Avec un modèle classique, on entre dans un protocole de qualification qui pénalise le projet. Est-ce dans le périmètre ou pas [NDLR, défini en amont dans le contrat] ? » Le modèle en cascade, utilisé en grande majorité dans les projets informatiques, consiste à compartimenter le projet en phases distinctes sur le principe du non-retour. Lorsque une phase est achevée, son résultat sert de point d'entrée à la phase suivante.
Partager les risques dans la collaboration
« Dans le monde cruel de l’informatique, les contrats de développement logiciel ont souvent pour les clients un objectif supplémentaire de transférer le plus possible les risques sur un fournisseur qui « sait faire ». En s’engageant sur un périmètre fonctionnel et un montant, le fournisseur prend à son compte la complexité des projets informatiques », souligne David Gageot, dans un livre blanc de la société Valtech Technology, SSII spécialisée notamment dans le conseil autour des méthodes agiles.
En intégrant le client au coeur des processus de développement, le principe de l'agilité bouleverse la relation client/fournisseur. Et répartit les risques dans les deux camps. Un point que détaille notamment Pierre Pezziardi sur un blog de la société Octo Technology, cabinet d'architectes en systèmes d'information. « Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides ».
Facturer à l'étape
Conséquence directe, le calcul du coût du projet doit prendre en compte ces évolutions. Et c'est souvent ce point qui d'ailleurs est présenté comme un des freins principaux à l'acceptation par les entreprises du principe d'agilité dans un projet de développement (voir Motivations et freins à l'adoption des méthodes agiles). « Le contrôle des coûts est entre les mains des clients, car il peut arrêter à tout moment le cheminements des itérations », résume Oana Juncu.
Car les itérations pèse sur le budget du projet, comme l'explique Mariono Boni. « Multiplier les mises en production coûte davantage que de se limiter à un seule et unique déploiement de grande ampleur. Reste que le gain se situe dans l'accélération des développements, et dans un time-to-market beaucoup plus rapide », insiste-t-il. Un coût supplémentaire certes, mais compensé par un développement qui ne manque pas (ou rarement) son but. Un discours qui reste difficile à faire passer en temps de crise.
| Les méthodes agiles : panorama et répartition |
 Si l'éventail des méthodes agiles commence à s'étoffer, deux d'entre elles ont la côte, Scrum et eXtreme Programming (XP), résume Mariono Boni, directeur technique de Dreamsoft. Scrum (mélée en français) se distinguant d'une large tête sur le marché en terme d'adoption.Selon une étude réalisée par VersionOne, éditeur d'outil pour les méthodes agiles, 49 % des quelque 3 000 répondants – des entreprises envisageant ou ayant déjà adopté le principe d'agilité – suivent Scrum. 22 % d'entre elles ont recours à une méthode hybride, mélant XP et Scrum. Et, enfin, les 29% restant s'en remettent aux autres méthodes du marché. Si Mariono Boni explique qu'on ne peut pas mettre de l'agilité dans tous les projets, il apparaît également que chaque méthode ne répond pas à tous les scenarii. Des entreprises conjuguent ainsi des principes tirés de différentes méthodes, pour coller au plus prêt à leurs besoins. Cette même étude met en exergue cette cohabitation : quelque 5,3 % des répondants conjuguant plusieurs méthodes (sans autre précision). D'autres (3,7 %) utilisent eux les méthodes agiles sans en connaître l'étiquette. |
