Tribunes

Développement au forfait et méthodes agiles, deux mondes pas forcément parallèles

Sur le papier, développement au forfait et méthodes agiles semblent incompatibles. Dans les faits, injecter des méthodes agiles dans un développement au forfait est tout à fait possible, autant que l'inverse. Malgré tout, des réticences culturelles, chez les fournisseurs comme chez les clients, freinent encore les projets mixtes.

PublicitéDéveloppement au forfait versus méthodes agiles

Avec un engagement de résultat de la part de la société de services informatiques, le développement de nouvelles applications, au forfait, rassure l'entreprise cliente : le périmètre fonctionnel, le calendrier et le budget du projet sont définis de manière contractuelle, dès le départ. En théorie, c'est le mode idéal pour un client. Dans les faits, le forfait a démontré ses limites : un manque de souplesse et de réactivité face à l'évolution des besoins du client en cours de projet. Avec pour conséquence, l'abandon ou la non-adhésion des utilisateurs à bon nombre de projets. Or, dans un environnement économique fortement concurrentiel et en perpétuel changement, au sein duquel l'informatique est au service du business de l'entreprise, ces écueils sont de taille !

C'est la raison pour laquelle de nouvelles méthodes de développement ont été imaginées, en particulier les méthodes agiles, qui reposent sur quatre piliers : l'équipe et les interactions entre les individus doivent primer sur les processus et les outils, le développement de l'application est prioritaire à l'élaboration d'une documentation exhaustive, la collaboration avec le client est plus importante que la négociation du contrat, et enfin, l'ouverture au changement doit être privilégiée par rapport au suivi d'un plan rigide.

Dans un projet agile, les fonctionnalités essentielles sont définies avec le client et développées prioritairement, tandis que les fonctionnalités plus secondaires sont reportées en fin de projet. La communication entre la SSII et l'entreprise garantit un développement de qualité et conforme aux attentes des utilisateurs (adhésion à l'outil) et permet de réduire le coût de possession à long terme (maintenance réduite, obsolescence moins rapide, etc.). Tandis que les itérations permettent de réagir, même en cours de projet, à d'éventuelles évolutions des besoins du client.

Une question de compromis et de culture d'entreprise

Dans certaines sociétés, l'agilité au changement a été érigée en « valeur d'entreprise » et « transpire » à tous les niveaux (organisation, management, production...). Un développement informatique impliquant des méthodes agiles ne leur posera aucun problème, et sera même requis. Mais dans la plupart des cas encore, le développement de nouvelles applications selon les méthodes agiles fait reculer. Toute la difficulté repose sur l'équilibre à trouver en termes de risques, de qualité, de coût, de délais et, bien sûr, de périmètre développé.

Il s'agit donc d'imaginer des projets mixtes, mêlant habilement forfait et méthodes agiles. Plus exactement, il s'agit de proposer un projet basé sur l'une ou l'autre des méthodes, dans lequel sont injectés des modes de fonctionnement de la seconde. Ainsi, certains projets au forfait pourront bénéficier, dans certaines phases, des modes de fonctionnement propres aux méthodes agiles. Inversement, certaines parties d'un projet conçues selon les méthodes agiles, pourront être développées au forfait.

PublicitéToutefois, définir la méthode idéale de façon empirique est impossible : l'équilibre doit se trouver à deux, entre le client et le fournisseur, sur un projet de développement donné. La nature des relations et du contrat dépendra de la culture et de la position du client vis-à-vis des méthodes agiles, mais aussi de la typologie du projet et du fournisseur. Mais dans un monde en perpétuel mouvement et dont les évolutions sont de plus en plus rapides, il semble difficile aujourd'hui ne pas travailler par itération, en phase constante avec les évolutions des enjeux et des besoins.

Certaines entreprises ont d'ailleurs glissé vers les méthodes agiles dans le cadre de leurs développements informatiques, sans même s'en apercevoir ! Depuis près de trois ans, dans un contexte de crise économique, nombreuses d'entre elles font en effet le choix de mini-forfaits, pour des lots très précis. En ce sens, elles appliquent elles-mêmes les principes de base des méthodes agiles, en priorisant leurs besoins, sans s'imposer le développement, et les coûts inhérents, d'un projet global.

Une première phase agile, le reste au forfait

Dans le cadre d'un développement selon les méthodes agiles, on passe d'une relation du client donneur d'ordre et payeur avec une société qui exécute « industriellement » la prestation, à une relation de partenariat où les deux parties s'engagent sur un objectif à moyen terme. Mais les questions de qualité, de délais, de coûts et de périmètre subsistent ! Un projet 100% méthodes agiles peut effrayer le client, tandis qu'un projet au 100% au forfait fait peser plus de risques sur la SSII. Le bon équilibre est d'autant plus complexe à trouver si les deux entreprises n'ont encore jamais travaillé ensemble.

Pour s'assurer du bon déroulement d'un projet, chacune des équipes doit donc apprendre à connaître l'autre, quant à ses attentes, ses méthodes de travail et ses exigences. Cette collaboration étroite entre équipes, qui compte parmi les quatre piliers des méthodes agiles, doit être mise en place dès le départ : sur un premier lot, voire même dès les phases de définition des besoins ou de réponse à appel d'offre. Elle permet de créer de la proximité entre les deux équipes, tout en garantissant au client que le fournisseur a parfaitement compris ses enjeux métiers et ses attentes.

Une fois la confiance installée, la mise en oeuvre d'un forfait, et la définition de ses étapes pour le reste du projet, sera beaucoup plus simple. Malgré tout, l'injection de méthodes agiles dans cette seconde phase est tout à fait envisageable : découpage en lots, fonctionnalités à plus forte valeur ajoutée développées prioritairement, livraisons et intégration en continu, itération, ajustement après chaque phase, etc. Au final, cette solution permet de maximiser les chances de réussite du projet, tout en minimisant les risques de part et d'autre, grâce notamment à une validation de la démarche -et des livrables- au début et tout au long du projet.

Article rédigé par

Nicolas Odet, Directeur Général Adjoint du Groupe Hardis
Nicolas Odet a rejoint Hardis en 2000 où il a successivement occupé les postes de Responsable Vente et Marketing du pôle de compétences Nouvelles Technologies, de Directeur du Département Infrastructure et Infogérance de 2006 à 2008, et de Directeur des Services, du Marketing et de la Communication de 2009 à 2012. Il a notamment piloté la transformation de l'offre d'Hardis vers le cloud computing. Directeur Général Adjoint du Groupe Hardis depuis début 2013 et membre du comité exécutif, il participe à la définition des orientations stratégiques du groupe et au pilotage de leurs déclinaisons opérationnelles.

Avant d'intégrer Hardis, Nicolas Odet a occupé des postes d'ingénieurs d'affaires chez IBM (division systèmes et stockages) et chez Sagem (solutions réseaux et fibre optique).

Nicolas Odet est titulaire du diplôme de Grenoble Ecole de Management (GEM), spécialiste du management technologique, obtenu en 1998.