Big Data, Science des données, aide à la décision en entreprise, business intelligence, data warehouse, reporting, OLAP, web analytics, data visualization, data mining, internet des objets, informatique cognitive, intelligence artificielle...

Abonnez-vous gratuitement à Decideo !


Decideo

 


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


Rédigé par Nicolas ODET, Hardis le 6 Janvier 2012

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.



Nicolas Odet, Directeur du pôle Services, Directeur du Marketing et de la Communication, Hardis
Nicolas Odet, Directeur du pôle Services, Directeur du Marketing et de la Communication, Hardis
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.

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 œuvre 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.




Commentaires

1.Posté par Pierre de Battista le 10/01/2012 10:57
Bonjour,

Oui bien sur, c'est le modéle vers lequel tout le monde souhaiterais aller.
Mais la question cruciale, la plus compliquée et pour laquelle je n'ai toujours pas de réponse : quel modéle contractuel ? Peut-on forfaitiser de l'agilité ? comment définir les périmètres entre le client et le prestataire ?
auriez-vous des expmples concerts

2.Posté par Xylo le 26/01/2012 17:52
Un modèle de contrat :
http://contrat-agile.org/

Nouveau commentaire :
Facebook Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.