Méthodes agiles : le renouveau des relations client / fournisseur dans l'ingénierie

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.

Selon une étude de VersionOne, éditeur d'outil pour les méthodes agiles, 22 % des entreprises qui ont adopté les méthodes agiles l'ont fait parce qu'elles y voient une façon d'accélérer la commercialisation d'un produit (time-to-market). C'est la première motivation des organisations selon cette enquête. A 21%, les entreprises interrogées estiment que les méthodes agiles améliorent aussi la capacité à pouvoir changer les priorités. Suivent loin derrière l'augmentation de la productivité (12 %), l'amélioration de la qualité logicielle (10 %), un meilleur alignement métier/IT (9 %).

Cette même étude, qui a sondé plus de 3 000 entreprises ayant déjà adopté les méthodes agiles, considère en revanche que le frein n°1 réside dans la capacité à changer la structure organisationnelle d'une entreprise (à 45 %). Suivent la résistance naturelle au changement (à 44 %) le manque de compétences en interne (à 42% ).

Dans les entreprises interrogées, l'étude montre que le directeur de projet est le prescripteur principal des principes d'agilité. Les méthodes agiles semblent séduire avant tout des équipes bien fournies. Dans 32 % des cas selon VersionOne, ces principes sont adoptés par des groupes de développement de plus de 250 personnes.

Télécharger l'étude « The state of agile dévelopement » pour 2008

En chimie – ou en cuisine -, on parle d'émulsion. Lorsque deux substances liquides, qui à l'origine n'ont pas la capacité à se mélanger, forment au final une solution homogène. Ce principe pourrait également s'appliquer aux méthodes agiles lorsqu'on aborde le problème de la contractualisation. Reposant sur le développement itératif et plaçant le client au coeur du projet, le développement dit agile s'oppose radicalement avec le principe original du contrat au forfait, par lequel sont formalisés la plupart des projets informatiques. L'enjeu n°1 de l'entreprise agile est alors de concilier deux impératifs, à priori assez éloignés.

Le contrat au forfait scellé entre un fournisseur et un client formalise, par un cahier des charges ferme, un périmètre de fonctionnalités que le fournisseur doit réaliser en une période donnée. Et ce en cloisonnant les deux mondes : « le client se repose sur ce contrat pour se rassurer sur la facture finale, même en fournissant un cahier des charges flou », explique Jacques Witté, architecte logicielle chez UsineWeb, société de conception et de gestion de projet. De l'autre côté, chez le fournisseur, la réalisation du devis, face au flou artistique qui entoure le projet, reste « un exercice vaudou ». La relation, dès lors, apparaît comme très déséquilibrée.

Le développement par itération, quant à lui, induit par les méthodes agiles, implique de penser par étape – et donc par version - le produit final, tout en impliquant, à la fin de chaque itération courte, le client. Donnant ainsi la possibilité de modifier les fonctionnalités – et donc le produit final – au cours même de l'évolution du projet. Au final, le donneur d'ordre trouve là une flexibilité que le contrat au forfait ne permet pas.
Reste à trouver une façon de contractualiser ce mode d'interaction un peu inhabituel dans la relation entre donneur d'ordre et prestataire.

Dissocier cahier des charges et contrat

Une des clés de cette contractualisation consiste à « séparer le cahier des charges de la partie contractuelle », insiste Jacques Witté. Une stratégie qui conduit à séparer le nombre de jours dans la pratique et les fonctionnalités. « L’équipe de mise en oeuvre (en particulier l’architecte logiciel) réécrit le cahier des charges en le découpant en milestones (groupes de fonctionnalités) chiffrés en jours x homme. Puis, l’ensemble des milestones (le chiffrage du cahier des charges) détermine un nombre de jours x homme total du projet », explique-t-il. Enfin, « le client s’engage à signer la mise en oeuvre d’un pourcentage de ce nombre de jours total du projet ». Alors que le contrat définit chaque tranche de temps qui serviront à calculer les itérations, le cahier des charges reste basé sur le fonctionnel et peut être modifié « à la volée ». Selon les critères des méthodes agiles. Sur cette base, les jours non-utilisés sont ré-attribués à l'itération suivante. La facturation peut être alors effectuée en fonction de chaque itération.

Même son de cloche chez la société People in Action (PIA), spécialiste des RIA (Rich Internet Applications) en environnement professionnel. « A partir du cahier des charges fourni par le client, on fragmente le projet en lots (liés généralement aux fonctionnalités) et on détermine le nombre de jours x homme, nécessaire pour chaque itération . On écrit aussi une liste de critères d'acceptation qui est validée par le client. Puis il s'engage sur un pourcentage de cette même liste – et ainsi du nombre de jours x homme qui peut être alors réaffecté dynamiquement sur les autres lots, selon les priorités décidées par le client », raconte Emmanuel Levi-Valensi, directeur associé de PIA.

La pilule de la facture

Reste alors à convaincre le client. Car si les méthodes agiles impliquent « un clash culturel » dans la gestion de projet « comme avec les projets du Web 2.0 par rapport aux projets informatiques classiques », souligne Jacques Witté, elles ont également un coût supplémentaire qui doit être justifié auprès du client.

L'enjeu n°1 consiste alors à faire accepter ces bouleversements, tant en termes de gouvernance que pour le volet financier.

Une des justifications du surcoût de ces méthodes auprès des entreprises clientes réside dans l'expertise des ressources mises à disposition. Une approche qualitative qui « sert à expliquer l'agilité aux clients », selon Jacques Witté. « L'un des avantages [des méthodes agiles, NDLR] est de distiller les meilleures ressources au bon moment dans l'évolution des développements », explique-t-il, histoire de justifier le surcoût d'une formulation agile d'un contrat au forfait.

C'est après une expérience d'externalisation de processus en Inde qu'a débarqué l'agilité au sein de la DSI de Bouygues Télécom. Reposant initialement, et très fortement, sur des fournisseurs externes, la DSI de l'opérateur a décidé de débuter un vaste rapatriement des activités, en rationalisant ses prestataires d'abord, avant d'enchainer sur une véritable réinternalisation de ses processus. « Nous avons repris en main les applications critiques et les processus métier, aussi bien dans le développement que la production », explique Alain Moustard, le DSI.
Un enjeu capital pour l'entreprise et pour l'informatique, au coeur des processus d'un opérateur. Mais, dans un marché bouillonnant des télécoms, où l'opérateur se mue en une porte d'entrée pour la téléphonie fixe, la téléphonie mobile, l'Internet, voire la télévision, il a fallu réaligner les processus pour gagner en réactivité.

Refondre les processus de sortie d'offres

« Il y a 2 ans, nous sortions une offre illimitée avec Neo. Nous étions les seuls à l'époque et nous le sommes restés longtemps. SFR et Orange sont arrivés 18 mois après. A cette époque, il nous fallait 4 à 5 mois pour sortir ce type d'offre. Il n'y avait dès lors pas vraiment d'urgence à partir du moment où il n'y avait pas de réaction rapide en face », commente Alain Moustard.

Aujourd'hui, le contexte a changé. La guerre entre opérateurs fait rage, alimentée par des consommateurs sans cesse à la recherche d'offres packagées et pour un coût toujours plus modique. Prendre systématiquement une longueur d'avance sur la concurrence fait figure d'avantage concurrentiel majeur dans cet environnement.

« La sortie de nos offres est très dépendante du marché, de ce que font SFR et Orange. Nous avons besoin d'une réactivité très forte. Nous sortons nos offres en quelques semaines. Pour passer de quelques mois à quelques semaines, nous avons cherché des outils nous permettant d'être plus agiles. Dans l'automatisation de la conception de l'offre, des prix et des tests, ainsi que dans l'accélération des tests. Et nous avons refragmenté les équipes ». S'extraire du sempiternel et lourd cycle en V – la méthode de gestion de projet classique -  devenait indispensable pour accélérer l'ensemble de la chaîne.

L'agilité pour le prototypage

« Grâce aux méthodes agiles, nous avons modifié le prototypage », raconte Alain Moustard, qui  explique que la définition d'un cahier des charges est difficile quand on démarre une nouvelle activité. « Quand on a lancé la ligne fixe, il nous a fallu fabriquer un nouveau SI pour aller toucher le monde des entreprises. Mais, pour définir nos besoins métiers, nous avions en face de nous des maîtrises d'ouvrage qui ne savaient pas bien ce qu'elles voulaient », constate-t-il. En avançant pas à pas, itération par itération, à partir de besoins définis initialement à 60 %, Bouygues Télécom est parvenu à constituer un SI pour le fixe en 3 ou 4 mois.

« Avancer en mode prototypage permet de traduire progressivement les besoins en développement de façon à ce que le client (les directions métier, ndlr) alimente sa réflexion ». Et ce sur des périodes courtes de l'ordre d'une semaine – période généralement consacrée à un sprint (une itération dans la terminologie de la méthode agile Scrum).

Thierry Alexandre, qui dirige quant à lui le centre de développement de Nantes de l'opérateur – là où sont centralisées les équipes de développement après l'épisode indien -, insiste sur le fait que le prototypage agile permet de travailler dans la sérénité. « On découvre très tôt les problèmes et cela permet de produire des versions successives de qualité. » Un processus de fabrication qui a d'ailleurs fait ses preuves lors du lancement des activités de FAI de l'opérateur. « Sur ce créneau, tout le monde partait de zéro, commente-t-il. Il a fallu apprendre le métier de FAI. On ne pouvait pas partir dans le modèle classique de cycle en V. Il fallait ajuster le tir au fur et à mesure de la montée en compétence. »

Cette transition de l'opérateur vers les méthodes agiles passe également par la mise en place d'un attirail d'outils – ici Open Source – pour contrôler le versioning - la sortie des versions -, et accélérer les transitions entre les différentes phases du développement. Le centre de Nantes s'est notamment équipé d'un « ordonnanceur ».  « A partir des builds (versions de développement, ndlr), nous enchaînons automatiquement sur les compilations, puis, surtout, nous faisons passer des batteries de tests. »

L'agilité par la polyvalence des équipes

Si l'agilité n'était pas un concept complètement nouveau pour Bouygues Télécom, il a toutefois fallu recruter de nouveaux collaborateurs et les former aux nouvelles méthodes de conduite de projet. L'accent a alors été mis sur la polyvalence des profils recherchés. « Un critère d'agilité », s'amuse Alain Moustard. « Les équipes font à la fois du développement, de la production et des tests. Celui qui conçoit, développe et teste. C'est aussi cela qui fait gagner du temps avec les prestataires et permet d'éviter les intermédiaires. » Un profil mêlant à la fois des compétences d'ingénieur, d'architecte et de programmeur en somme. Au final, les processus de sorties des offres ont été divisés presque par deux, tant en temps passé qu'en budgets.

« Il y a deux ans, il fallait 22 semaines pour sortir une offre. Nous sommes passés à 15 et certains modules commencent à sortir en 3 semaines », affirme Alain Moustard. Avant d'ajouter : « il faudra encore aller plus loin » dans la réactivité.

Parce qu'elles rendent les développements plus prévisibles,  les méthodes agiles constituent aujourd'hui un moyen de garantir une relation de confiance entre le client et le fournisseur. C'est un des messages qu'a tenté de faire passer ce matin Jeff McKenna, chef évangéliste Agile de Serena, spécialiste de la gestion de projet et de gestion de cycle de vie, lors d'un entretien avec la presse. McKenna était en France pour porter la bonne parole autour de Scrum, la méthode agile tendance, dont il est le co-créateur.

Les méthodes agiles (comme Scrum ou XP - Extreme programming) revisitent la gestion de projet en reposant les développements sur de courtes itérations (on parle de Sprint), et donnant la possibilité au client d'interagir avec les équipes de développement en cours de projet pour redéfinir les besoins et les priorités. Les gains généralement mis en avant sont des produits finaux plus proches des desiderata des clients et des développements plus rapides, notamment.

Jeff McKenna explique  que c'est parce que les développements sont plus prévisibles – et donc plus maîtrisés  - que cette relation de confiance entre les 2 parties s'établit. « Le client peut faire confiance à l'éditeur dans sa capacité à faire le logiciel souhaité, avec un panel de fonctionnalités  garanties », souligne-t-il. Aujourd'hui, lorsqu'il rédige un cahier des charges demandant dix fonctionnalités, un client sait par avance que toutes ne seront pas réalisées. En étant agile, il est en revanche assuré qu'au moins huit de ses dix fonctionnalités seront livrées, avec peut-être une marge d'erreur de 1 », commente-t-il.

Et il semblerait que les méthodes agiles fassent leur chemin dans les entreprises. Avec 85 000 certifications, Scrum progresse dans les projets mondiaux – en France, la société Valtech délivre les certifications.  Surtout le concept commence à gagner les couches dirigeantes. « Au départ, la décision d'utiliser les méthodes agiles reposait sur les épaules du developpeur, raconte-t-il, mais on voit de plus en plus le middle management adopter l'agilité, dès qu'il est question de gérer une équipe. ». S'il reconnait facilement que rares sont les cas d'adoption à l'échelle d'une entreprise entière, mais encore une fois, McKenna explique que l'adoption progresse, citant notamment en exemple Salesforce. « L'agilité s'adapte parfaitement au marché du Saas parce que les mises à jour sont fréquentes et les projets plus courts », explique-t-il.

Des méthodes contractuelles encore expérimentales

Reste encore à formaliser ce relation de confiance dans un contrat pour attirer un peu plus les entreprises. Car pour l'heure, c'est bien là que le bât blesse, comme nous l'évoquions dans un précédent article. Comment concilier le contrat au forfait qui repose sur un cahier des charges fonctionnel ferme, avec les développements par itérations, permettant de faire évoluer les besoins en cours de projet? Si certains parlent d'exercice vaudou – et donc d'une incompréhension au niveau des entreprises - , Jeff McKenna préfère parler de façon de penser différente. Tout en rappelant, qu'effectivement sur ce terrain, on en est encore aux premiers stades : « Il y a plusieurs expérimentations autour de différents types de contrats pour encadrer le développement agile. Mais il s'agit surtout de formaliser un process comme un service qui conduit vers un produit finalisé à partir de définitions peu précises et peu établies du côté du client. » Faire accoucher les esprits en somme, comme l'art de la maïeutique chez Grecs.

« Les entreprises qui découvrent l'agilité découvrent au passage de nouvelles formes de contrats », poursuit-il, expliquant que parmi certaines expérimentations, le contrat passé  - et facturé – à l'itération a donné de bons résultats :« Prenons l'exemple de cette petite entreprise travaillant pour la défense en Grande-Bretagne et qui a pour habitude de mener des itérations (sprint) de deux semaines. Leur idée est de formaliser les contrats au rythme de ces deux semaines. Ils se mettent d'accord avec les clients sur les fonctionnalités à développer pendant ces deux semaines. Au terme de cette période , ils tirent un bilan avec le client et ce dernier confirme s'il souhaite renouveler le contrat ». Une réussite, selon lui.

Le ciment de l'offshore ? En apparence antinomique avec l'externalisation à l'étranger (offshore), les méthodes agiles pourraient bien en être en réalité le liant, à chaque fois quil s'agit de délocaliser des développements. Une démarche agile, qui fractionne les cycles de développement en de courtes itérations, peuit trouver son chemin dans les procédures industrielles qui régissent de plus en plus l'externalisation offshore. Chine, Inde, Europe de l'Est ou encore Afrique du Nord (on parle alors plutôt de nearshore), quelle que que soit la localisation du site, les problématiques restent souvent les mêmes : distance, formation, éducation et méthode de travail. Autant de contraintes et disparités qui pourraient rendre la tâche plus ardue qu'avec des projets réalisés sous le même fuseau horaire.

Comment dès lors concilier l'agilité, qui insère les développeurs au cœur de processus, et l'offshore, quand ces mêmes développeurs sont à des milliers de kilomètres ? Comment entretenir les relations de confiance que créent intrinsèquement les méthodes agiles dans les relations clients / fournisseurs ?

Pour Nathalie Lopez, directrice adjointe et responsable de l'offre agile chez Valtech, la greffe peut prendre, mais à condition de procéder à quelques ajustements. Tout en faisant ce constat, qui rend ladite greffe non seulement possible, mais souhaitable : « avec la démarche classique client / fournisseur, le client n'est presque jamais satisfait surtout avec l'offshore ».

Réduire l'éloignement

C'est notamment pour répondre au problème d'éloignement amené par l'offshore que les prestataires recourrent à l'agilité. Selon le rapport 2008 de la société VersionOne, qui cartographie l'état de l'art des méthodes agiles, les entreprises ayant déjà adopté l'agilité dans leur processus de développement fonctionnent avec un ou plusieurs sites distants. Il s'agirait donc d'une motivation poussant à se lancer dans une stratégie dite agile.

Mieux, sur la totalité des entreprises sondées (plus de 3 000 réparties dans 80 pays), 21 % d'entre elles utilisent les méthodes agiles pour répondre au besoin de processus de développement outsourcés et quelque 20 % supplémentaires envisagent de le faire à terme.

Pour Nathalie Lopez, « l'agilité compense bien la distance en favorisant la communication au quotidien avec les équipes offshore et elle permet le contrôle et la maîtrise des développements au jour le jour ». Et cela est notamment réalisable grâce à la mise en place d'outils favorisant l'intégration continue, principe qui consiste à contrôler chaque modification du code source afin de limiter toute anomalie ou régression des fonctionnalités de l'application en cours de développement. Cette observation en continu, surtout si elle est répétitive, est clé, insiste Nathalie Lopez, qui parle même de ciment du projet, surtout dans un contexte offshore. Un contexte où chaque mise à jour doit être contrôlée et validée immédiatement pour que les développements se poursuivent – pas question de tirer un trait sur l'un des gros avantages de l'agilité, l'accélération des temps de développement.

Désigner un champion fonctionnel

Reste alors à trouver le moyen d'assurer et de pérenniser la communication entre les équipes de développeurs. Et c'est là notamment que les entreprises doivent réaliser quelques ajustements. « Il faut en effet plus de formalisation, plus de documentation et valider la compréhension des aspects fonctionnels », résume Nathalie Lopez. En gros, les différences culturelles, ou les décalages liées au langage, peuvent s'avérer très pénalisantes dans l'exécution du projet. Pour répondre à cette problématique, « on est obligé de davantage structurer et de mettre en place des rôles supplémentaires », poursuit-elle. On parle alors du « champion fonctionnel », le garant de la compréhension de l'ensemble des fonctions de l'application au niveau de l'équipe offshore. Un poste clé qui s'apparente alors celui d'un ambassadeur, qui peut également être dépêché sur le site du client, afin de faire office de relais.

Nathalie Lopez insiste enfin sur la nécessité de fixer les réunions qui ponctuent les sprints. « Et ne jamais changer leur timing ». Histoire d'avoir une visibilité récurrente sur le projet et surtout de pourvoir évaluer et mesurer l'avancement des travaux à intervalle régulier par le biais d'indicateurs. Un carcan indispensable, que chaque équipe doit inclure dans son planning.

Alors l'agilité, remède absolu contre tous les maux du développement offshore ? Pas si simple. Dans un excellent article, Martin Fowler, consultant au sein du cabinet ToughWorks, attire l'attention sur l'épreuve de force qu'engendre la mise en place de l'agilité dans un contexte offhsore. « Bien plus pénible que dans un contexte de gestion classique [notamment en raison de la distance et à des disparités culturelles, ndlr]. Mais les méthodes classiques sont encore bien plus pénibles que les méthodes agiles. » Le moindre de tous les maux, en quelque sorte.