En 2015, 80 % des entreprises étaient dotées d’équipes pratiquant l’agilité. À titre de comparaison, elles n’étaient que 35 % entre 2012 et 2014.
Pourquoi une telle évolution ? Le fondement de l’agilité repose sur le constat que de nombreux projets informatiques échouent pour cause de non-respect des délais, des coûts ou du cahier des charges. L’évolution permanente des besoins clients impose de repenser des modèles trop rigides. Les marchés actuels impliquent une gestion en temps réel et une forte réactivité. Mais l’agilité est-elle pour autant adaptée à tous les types de projets et en particulier aux projets de pilotage de la performance ?
Si les cycles de développement classiques d’un projet EPM (management de la performance de l’entreprise) étaient auparavant assez longs – de quelques semaines à plusieurs mois – les clients souhaitent désormais voir des résultats tangibles dans des délais réduits. De nouvelles solutions, nées avec Internet et la démocratisation du Cloud, apparaissent régulièrement et promettent des délais d’implémentation jamais vus précédemment.
En tant qu’intégrateur, il est indispensable que nous nous appropriions cette nouvelle donne tout en nous adaptant aux demandes de nos clients.
Les limites des projets classiques
Le premier risque inhérent à un projet dit « en V » est lié à la prédominance de la documentation sur le logiciel. Un projet classique est rythmé par la livraison de documents à valeur contractuelle censés définir la cible à atteindre : cahier des charges, conception fonctionnelle, technique…. Des centaines voire des milliers de pages doivent être rédigées, relues, diffusées puis corrigées en plusieurs versions successives. Les malentendus ou les erreurs d’interprétations du document peuvent générer de véritables écarts entre le produit attendu par le client et le produit réellement livré.
Un autre écueil est le fameux « effet silo » de la phase de développement, au cours de laquelle le client ne peut vérifier que la réalisation est conforme à ses attentes. Afin de limiter les risques, la réalisation de la solution est conditionnée à la validation du dossier de conception qui décrit l’exhaustivité du produit attendu.
La validation de ce document clé est parfois problématique et peut engendrer un retard dans les phases suivantes : désaccord entre sachants sur une règle de gestion spécifique, incertitude sur la disponibilité d’une source ou la finesse souhaitée sur un axe d’analyse…. Lorsque la conception est finalement validée, tout changement est vécu comme une contrainte et peut provoquer d’âpres négociations entre les partenaires.
La méthode agile permet de pallier ces risques en favorisant la collaboration avec le client. Elle ambitionne d’apporter une valeur métier tangible dans les délais les plus brefs, tout en accueillant favorablement les changements tout au long du projet. Dans ce contexte, si l’agilité semble tout à fait adaptée aux projets de type web, elle paraît moins évidente dans le cadre d’un projet EPM, qui s’appuie la plupart du temps sur un progiciel du marché, plus ou moins souple, et qui impose ses propres contraintes. Dans ce contexte, agilité ne peut donc pas signifier liberté totale.
Quels bénéfices à l’agilité dans un projet EPM ?
Les avantages à mettre en place la méthode agile sont nombreux pour le client comme pour l’intégrateur. Le premier d’entre eux est de permettre une visualisation très rapide des résultats :
des démonstrations sont en effet organisées à une fréquence définie conjointement (en pratique, toutes les 1 à 4 semaines). Ces démonstrations sont l’occasion de vérifier que la réponse proposée est conforme aux attentes ou d’apporter des modifications si nécessaire sans attendre la phase de recette. Suite à la démonstration, le client peut immédiatement se connecter à la solution, effectuer ses propres tests et valider les développements. Cette capacité à effectuer un retour immédiat a un bénéfice direct sur le déroulement de la recette ultérieure.
Apporter de la valeur métier
Plutôt que de livrer 100% de la solution à un horizon lointain, cette méthode privilégie la livraison incrémentale de fonctionnalités, priorisées selon leur valeur pour le métier et la maturité du besoin. Ce sont donc les fonctionnalités les plus attendues et les plus stables qui seront développées et livrées en premier. C’est le client qui priorise les sujets et qui construit donc, étape par étape, le chemin vers la solution finale.
Intégrer l’incertitude et favoriser le changement La méthode agile intègre l’inéluctabilité du changement en s’affranchissant du dossier de conception classique : il est improbable sinon impossible d’avoir une vision complètement exhaustive et immuable de la solution finale au début de la réalisation. Les premiers sprints de développements commencent par les éléments faisant consensus tandis que tous les facteurs d’incertitudes sont traités en parallèle sans bloquer l’avancement du projet.
Renforcement de la relation et capitalisation
Un autre bénéfice majeur lié à l’application de la méthode agile est son impact sur la qualité de la relation entre les partenaires. Les sprints de développement sont rythmés par de nombreuses rencontres entre les développeurs et le client : planification du sprint, démonstrations, rétrospectives… Ces rencontres permettent aux partenaires de travailler ensemble en toute transparence, de mieux comprendre les enjeux respectifs et surtout de capitaliser sur les bonnes (ou mauvaises pratiques) constatées, et ce dans un souci d’amélioration continue du processus.
Les conditions de succès d’un projet EPM en méthode agile
Les principes de l’agilité sont donc parfaitement adaptés à un projet de pilotage de la performance, sous réserve que certaines conditions soient remplies. La première est liée à la disponibilité du métier. L’implication forte des utilisateurs est nécessaire tout au long du projet, y compris lors des sprints de développements. Cet investissement est ensuite largement récupéré au cours de la phase de recette. La seconde condition est la présence d’un chef de projet métier, nommé Product Owner, garant de la solution finale et des fonctionnalités que celle-ci doit intégrer. Le Product Owner doit avoir une excellente vision de la cible afin de se positionner en tant qu’arbitre sur les points litigieux, garantir le respect des délais et du budget et éviter les dérives liées aux développements de fonctionnalités sans forte valeur métier.
Ces deux conditions sont des prérequis à tout projet en méthode agile. Dans le contexte d’un projet EPM il est, de plus, indispensable de définir en amont les enjeux et objectifs du projet ainsi que les contraintes spécifiques liées au contexte ou à la solution choisie. Ces éléments viendront définir le cadre au sein duquel l’agilité peut être mise en œuvre. A titre d’exemple, certaines solutions permettent aisément d’ajouter un axe d’analyse dans le modèle de données tandis que d’autres imposent un modèle figé, difficile à faire évoluer en cours de projet sans en impacter le coût ou les délais. C’est le rôle de l’intégrateur de mettre en évidence ces contraintes afin que le client fasse un choix éclairé et comprenne les enjeux de ces décisions.
Si les critères ci-dessus sont correctement traités, la méthode agile est non seulement parfaitement adaptée à ce type de projet, mais elle peut même sauver de l’échec un projet enlisé. Comment ? En mettant l’accent sur la satisfaction du client et la relation entre les partenaires, plutôt que sur la documentation et la négociation contractuelle, et en permettant d’avancer progressivement et en confiance vers le résultat attendu. Pragmatique et constructive, cette vision devrait ainsi être utilisée à chaque fois que les conditions le permettent.
