Conclusion : omissions et limites des méthodes agiles
Méthodes agiles

Les méthodes dites « agiles », qui apparaissent sous cette appellation dans les années 2000 ont cependant une histoire un peu plus ancienne. Comme souvent, et malheureusement, en informatique on change la terminologie à défaut de changer de concepts. Le seul résultat certain de cette pratique déplorable est la confusion dans les esprits, en particulier celui des décideurs qui ont fini par perdre toute confiance dans ce que leur racontent leur DSI et/ou leurs experts informatiques. Le scepticisme et la défiance règne.

À la fin des années 1980, James Martin, auteur prolixe, a publié en trois volumes, chez Prentice Hall, son Information Engineering, qui a donné naissance, quelques années plus tard au RAD (Rapid Application Development) vite connu sous l'appellation « Quick and Dirty » et complètement décrédibilisé suite aux mauvaises pratiques qu'il a engendré. Il y avait beaucoup de bonnes choses dans l'Information Engineering, mais comme on peut s'en souvenir, c'est l'époque de la rupture technologique, avec le développement fulgurant des architectures distribuées, du client-serveur avec ses différentes variantes (client lourd, client semi-lourd, client léger, etc.). Les langages « anciens » comme Cobol, même rénovés avec les générateurs d'applications et autres L4G qui fleurissent vers la fin des années 1980, n'intéressent plus grand monde (quand bien même il reste encore des milliards de lignes de codes en Cobol dans les banques, les assurances, dans les administrations...). La mode est désormais aux langages objets (C++, Java) et aux méthodes de conception orientées objets qui, dans les années 1990, donneront naissance au langage UML. On est encore dans l'euphorie de l'intelligence artificielle, dont le battage médiatique a réussi à faire croire à de nombreux décideurs que l'on va pouvoir mécaniser la fabrication des programmes (en se débarrassant des programmeurs, ces gêneurs qui font des erreurs et qui sont incapables de s'exprimer dans un langage compréhensible de tous) et enfin, connaître le meilleur des mondes informatiques où l'erreur a disparu comme par magie. Le réveil, qui prend les allures d'un crash, sera particulièrement brutal (cf. le rapport Chaos du Standish Group [Doc. H 3 200]).

C'est également la période de tous les excès issus d'une démarche qualité mal comprise, qui va vite se transformer en bureaucratie, dont l'objectif est de satisfaire à des normes souvent ineptes (la norme du DOD 2167, tristement célèbre, est encore dans les mémoires de certains), inventées par des « experts » n'ayant jamais réalisé un système de leur vie. Comme on le sait, l'échec sera au rendez-vous, avec en plus un discrédit général sur la qualité dont on n'ose même plus prononcer le nom dans les entreprises qui se veulent sérieuses et informées.

Il faut également signaler le cycle de développement dit « en spirale » popularisé par B. Boehm dans son article de la revue IEEE Computer, vol. 21, n^o 5, mai 1988, A spiral model of software development and enhancement. Comme tout ce qu'a publié B. Boehm, c'est intelligent et profond, fondé sur la vraie expérience de l'auteur en matière de système logiciel. L'idée de Boehm est de coupler le processus de développement classique « en cascade » avec une gestion de risque qui donne des critères de convergence permettant de réaliser le système attendu par les parties prenantes. C'est une façon élégante de gérer les rétroactions sur une base réellement objective : quel décideur sensé pourrait refuser de prendre en compte les risques identifiés qui mettraient le projet en échec ?

Sur toute cette période, le lecteur intéressé peut consulter le recueil de textes, sélectionnés par D. Reifer, Software management, publié par l'IEEE en 1993, qui donne une bonne photo des problématiques de l'époque.

En fait, rien de vraiment nouveau dans la démarche agile, si ce n'est, comme on dit au football, une remise de la balle au centre.