Pas fiable et impossible à réaliser dans les délais prévus, un vrai casse-tête... S'il y a toujours eu une constance dans le logiciel, c'est sans doute celle du chaos. Et s'il y a toujours eu une priorité, c'est sans doute celle de la qualité. La lutte - manichéenne - a démarré officiellement en octobre 1968, lors d'une conférence organisée par le comité scientifique de l'Otan à Garmisch-Partenkirchen. Alors que le président Johnson décide d'interrompre les bombardements au Nord-Vietnam, les informaticiens se rassemblent pour poser les bases du génie logiciel - ou software engineering -, inventant le concept au passage. En introduction du " Trentenaire du génie logiciel " , organisé au Conservatoire national des arts et métiers en décembre 1999, Jean-Claude Rault, consultant et enseignant au Cnam, remarque : " Les textes des exposés et comptes rendus de discussions figurant dans les actes de ces deux conférences (celles d'octobre 1968 et celle d'octobre 1969 à Rome - NDLR) sont d'une étonnante actualité. " Les composants et la réutilisation du logiciel, la notion de cycle de vie, la difficulté de la validation et de la vérification, les méthodes formelles, la conduite de projet, l'estimation des coûts et des délais, ou encore les concepts sous-jacents à l'orientation objet, tout y est. " C'est surtout l'époque où l'on a pris conscience qu'il fallait structurer la programmation et abandonner l'usage intempestif du " Goto " " , complète André Gouadon, consultant chez Q-Labs. Tout y est, mais à l'état embryonnaire. La maturation sera longue avant de parvenir à des méthodes de développement dignes de ce nom et accompagnées des outils adéquats. En attendant, le logiciel reste le maillon faible de la chaîne informatique. A tel point que, vers le milieu des années soixante-dix, les professionnels n'hésitent pas à parler d'une véritable crise du logiciel. Les trente années suivantes verront lentement déferler une pléthore de méthodes, pour lesquelles il est extrêmement complexe de dresser une typologie, voire d'établir un recensement, digne de ce nom. Il faut donc attendre 1977 pour voir arriver la première méthode marquante, Structured Analysis (SA). Elle provient de méthodes fonctionnelles bien connues et générales, sans grand rapport avec l'informatique. C'est le stockage des données qui la distingue de ses prédécesseurs. En effet, les flux informationnels possèdent une propriété unique : ils ne sont pas consommés par la transformation.

En résumé, une information envoyée peut simultanément être conservée. SA fait donc intervenir le fait que l'on peut stocker des données, puis les reprendre à l'envi. En outre, l'approche SA répond bien à l'analyse fonctionnelle au sens strict en décomposant les fonctions et en mettant les flux en évidence. Il ne manque à SA que le temps. Créée la même année par D. T. Ross, SADT (Structured Analysis and Design Technique) s'en charge. On se donne des outils pour modéliser le temps grâce à des activités de processus. La méthode se présente comme un mélange entre les aspects fonctionnel et dynamique. Elle se pose notamment la question de savoir ce qui déclenche une fonction. Les concepts de datagrammes et d'actigrammes y répondent, mettant respectivement en valeur les données (transformées par des actions) et les actions (reliées par des données). Quelques années plus tard, en 1985, arrive SART (Structured Analysis-Real Time), héritage de SA. Autant cette dernière cible l'informatique de gestion, autant l'extension " RT " vise le monde industriel. Tout en restant dans une approche fonctionnelle, les processus et les flux sont, ici, gérés dynamiquement. Les méthodes fonctionnelles antérieures à 1975 démontrent leurs limites sur trois points essentiels. Le premier : elles génèrent une forte redondance des informations. Deuxième point, découlant du précédent : les mises à jour des données sont démultipliées. Troisième point enfin, conséquence implacable : on aboutit rapidement à une incohérence du système si l'information n'est pas mise simultanément à jour partout où elle devrait l'être. A la grande époque de la crise du logiciel, dans les années soixante-dix à quatre-vingt, ces incertitudes conduisent les éditeurs à facturer à l'avance les coûts de maintenance... Ces soucis d'ubiquité conduisent tout droit à la centralisation des données, posant de nouveaux problèmes de conception. En effet, celles-ci ne figurent qu'une seule fois dans la base, et elles sont partagées par toutes les applications - et donc par les utilisateurs. Bernard Morand, maître de conférences en informatique à l'Institut universitaire de technologie de Caen, résume les deux problèmes qui se posent alors : " Comment construire une base qui soit indépendante des applications actuelles ou à venir ? Comment définir les procédures d'exploitation appropriées ? Les méthodes d'analyse par fonction ne marchent plus à cause de l'indépendance par rapport aux résultats. En outre, les utilisateurs sont de plein droit dans le système informatique. " Il faut donc concevoir la base de données selon un modèle bien défini. C'est ainsi que les anciennes méthodes, telle Corig ^(*) , et quelques modèles théoriques (relationnel de Codd, entité-relation de Chen ou réseaux de Petri) vont donner naissance à la méthode phare des années quatre-vingt : Merise. Conçue entre 1977 et 1979, la méthode systémique est l'oeuvre collective de Tardieu, Nancy, Heckenroth, puis, plus tard, de Tabourier. Elle culmine à la fin des années quatre-vingt, période à laquelle une étude du cabinet Young estime que 50 % des entreprises utilisent une méthode - un chiffre peut-être surévalué -, et que 60 % d'entre elles ont adopté Merise.

Cycles d'abstraction, de vie et de décision forment le triptyque de la pensée Merisienne. Le premier est encore très utilisé avec les effets pervers que le succès peut engendrer : " Aujourd'hui, de nombreux concepteurs utilisent le modèle conceptuel de données de Merise en étant persuadés de faire du Merise, ironise Christophe Kolski, enseignant-chercheur au laboratoire d'automatique et de mécanique industrielles et humaines à l'université de Valenciennes. Mais cette méthode va beaucoup plus loin ! " Plus loin, certes, mais limitée par des postulats qui, aujourd'hui, paraissent surannés, voire risqués : un projet informatique est un travail à la chaîne, dont on peut prévoir le résultat, et propriété exclusive des informaticiens.

Le credo ne tient plus. Les projets d'aujourd'hui sont " communicants " , selon la formule de Bernard Morand. Ils deviennent " évolutifs et globaux ", avec une information à distribuer et à partager. Les applications doivent être " indépendantes mais interopérables " , et les architectures matérielles décentralisées. Les utilisateurs deviennent des décideurs sur les projets. Les langages sont à la sauce objet. Les méthodes, enfin, " exploitent un capital d'expérience, sont unifiées par une notation commune (UML - NDLR) et procèdent de manière incrémentale ". C'est la révolution de l'objet. " Cette période me semble coïncider avec la fin des grands projets, où l'informatique était grosse consommatrice de budget et gérée au plus haut niveau de la hiérarchie. Les projets actuels relèvent souvent davantage de la réingénierie que de la première informatisation " , poursuit Bernard Morand. Historiquement, la genèse des méthodes objets passe d'abord par le langage. Simula, en 1967, introduit la notion de classe. Smalltalk achève de poser les bases de l'objet avec l'héritage. En 1979, l'atelier de génie logiciel Ada constitue presque une méthode. En tout cas, il procure un outil qui peut servir de base. Ces fondations posées, Coad et Yourdon proposent, à la fin des années quatre-vingt, le concept d'OOA - pour " analyse orientée objet " -, et Gary Booch celui d'OOD - pour " conception " (Design).

A la même époque apparaissent également une pléthore de méthodes objet, dont la plus célèbre, OMT (Object Modeling Technique), conçue par James Rumbaugh, s'impose dans le monde anglo-saxon au milieu des années quatre-vingt. Où en sommes-nous aujourd'hui, à trente-trois ans de Garmisch-Partenkirchen ? Tout d'abord, le génie logiciel n'a sans doute jamais autant été au coeur des préoccupations de l'industrie de l'édition logicielle. Il dispose non seulement de l'expérience de ces trois décennies, mais aussi d'un début de consensus en termes de normes. Ainsi, UML (Unified Modeling Language) fournit aux méthodes une notation commune. Et, dans de nombreux cas, il remplace carrément la méthode. Normalisé par l'Object Management Group, c'est une sorte de mode d'emploi méthodologique quasi unanimement reconnu. Tandis que la bataille se livre, d'une part, sur les méthodes proprement dites et, d'autre part, sur les outils les mettant en oeuvre.

Là où Merise a constitué une copie conforme de méthodes utilisées en génie civil - étude fonctionnelle, avant-projet, étude détaillée, etc. -, l'objet développe des usages proches de ceux des ateliers d'usine, tels les îlots de production ou le juste-à-temps. Aujourd'hui, " l'informatique a besoin de plus de méthode que les autres industries. Ne serait-ce que parce qu'elle est plus abstraite, estime Jean-Pierre Meinadier, professeur au Cnam et titulaire de la chaire intégration des systèmes. Le logiciel n'est pas soumis à des lois physiques qui rendraient prévisible son fonctionnement, et donc la manière dont on va le construire. "

(*) Corig : Conception et réalisation en informatique de gestion, considérée comme la première méthode d'analyse et de programmation structurée, inventée par Robert Mallet, fondateur de CGI, en 1974.