Les méthodes agiles sont apparues dans un contexte socioéconomique bien particulier, aux alentours des années 2000-2001 : accroissement continu de la complexité des applications et des projets, frénésie technologique ininterrompue, prise de conscience par les informaticiens de l'importance des architectures, offshore et délocalisation des développements, intégration massive de progiciels de toute nature, interopérabilité généralisée et système de systèmes, besoin de réactivité toujours plus grand vis-à-vis des chaînes de valeur de l'entreprise, etc. En parallèle, score des projets en matière de coût, qualité, délai toujours aussi décevant, bogues à très haute visibilité comme ceux très récents chez France Télécom et Bouygues Télécom, discrédit et suspicion des méthodes aux yeux des décideurs, ... en bref : " la crise du logiciel " persiste et signe.

Dans ce contexte troublé, un groupe de consultants américains propose de créer une nouvelle alliance, autour du manifeste AGILE, et engage une lutte frontale contre les méthodes dites " lourdes " en remettant la programmation et les tests au centre du débat méthodologique, comme dans l'eXtreme Programming.

À quoi bon la méthode si les acteurs sont incompétents ! Si la technologie, ses contraintes et ses limites ne sont pas maîtrisées ! C'est une vraie question. Comment concilier agilité et réactivité avec la nécessaire rigueur des disciplines de l'ingénierie ?

Face à ce qui a toutes les apparences d'une nouvelle mode made in the USA que bien sûr certains, en mal de sensationnel, se sont empressés de présenter comme LA révolution méthodologique, il convient de raison garder et de distinguer lucidement le gadget médiatique du vrai problème auquel ces " nouvelles " méthodes veulent apporter une solution.

Ce qui fait problème dans les projets, c'est la dynamique des événements et des interactions qui assaillent le chef de projet, c'est la mise en situation des cycles de développement statiques dans les contextes particuliers toujours spécifiques et, bien sûr, la compétence des acteurs et la maîtrise qu'ils ont d'une technologie très complexe. Il y a dans le manifeste et les ouvrages traitant des méthodes agiles des vérités profondes qui côtoient des naïvetés, et parfois des contre-vérités. Il y a un vrai risque d'ériger le bricolage cognitif en nouvelle " science " de l'ingénieur, ce qui serait un comble et une vraie régression.

Organisé par le Centre pour la Maîtrise des Systèmes et du Logiciel (CMSL) du Conservatoire National des Arts et Métiers (CNAM) et d'une durée de deux jours, le présent séminaire a pour but de faire le point et voir clair sur les attendus des méthodes agiles. La première journée (mercredi 30 mars 2005) sera consacrée à un tutorial sur les techniques, démarches, méthodes et outils aujourd'hui disponibles pour le développement agile. La seconde journée (jeudi 31 mars 2005) comprendra deux types d'exposés : d'une part des descriptions de retours d'expériences sur la mise en pratique du développement agile dans différents secteurs professionnels et, d'autre part, des analyses critiques de techniques et méthodes en usage. L'inscription pourra se faire, au choix des participants, pour une ou deux journées.


Copyright (C) CNAM-CMSL 2005, Tous droits réservés.