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. 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é.

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. 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. Avec un modèle classique, on entre dans un protocole de qualification qui pénalise le projet. 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 ».

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.

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. « Le contrôle des coûts est entre les mains des clients, car il peut arrêter à tout moment le cheminements des itérations ».
Car les itérations pèse sur le budget du projet, reste que le gain se situe dans l’accélération des développements, et dans un time-to-market beaucoup plus rapide, 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.

À propos de Hicham AIT BASLAM

Une expérience de 16 ans, passée dans le conseil et le management de grands projets complexes à dimension internationale impliquant des équipes pluridisciplinaires et hétérogènes culturellement, à traiter de problématique d’intégration (FrontOffice, BackOffice) et d’architecture SI, d’alignement du SI sur la stratégie de l’entreprise, d’amélioration continue de la qualité, des process de delivery et la performance des équipes. Elle est constituée sur le terrain par la direction de nombreux centres de delivery et programmes de la phase amont jusqu’à la réalisation et livraison, marquée aussi par la Transformation et Refonte de plusieurs SI Stratégique, par le redressement de projets informatiques en difficultés, Business développement de plusieurs SSII, développement de nouvelles offres sur le marché. Toutes ces expériences m’ont permis d’avoir une vision générale des systèmes d’information éclairés sous différents angles et sur les solutions globales à haute valeur ajoutée. Mon expérience, en tant que directeur de projet, manager « évangéliste » de l’agilité, et compte tenu de ma croyance profonde dans les valeurs de l’agilité pour les petites, moyennes ou grandes organisations, m’a conduit à travers la France et l’Afrique. J’ai eu suffisamment de chance pour être impliqué dans de vraies mutations organisationnelles et transformation SI basées sur les disciplines et les pratiques du manifeste Agile et l’approche DevOps. Aujourd’hui, je me positionne dans le management de business unit, centre de delivery, la direction des projets à fort dimension (Internationale, Managériale, Business, Technologique), je me consacre entièrement à accompagner de grands comptes à réussir la transformation de leur SI, la transition vers l’agilité et à la traduction de la vision stratégique en résultat.

Publié le 24/10/2009, dans Méthodes Agiles, SI Agile. Bookmarquez ce permalien. Poster un commentaire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :