Des bugs dans le cerveau aux bugs dans le code

Pourquoi est-il si difficile de créer du logiciel sans bugs? Probablement en grande partie parce que l'outil principal que nous utilisons est lui-même un très mauvais exemple de conception rationnelle, et pour cause, et quand on y regarde de près s'avère bourré de bugs.

Cet outil, c'est le cerveau; ou si l'on veut, mais en ne le prenant que comme une métaphore, le logiciel, appelé "Intelligence", que nous faisons tourner sur le matériel qu'est le "Cerveau". (Faire le parallèle entre l'esprit-logiciel et le cerveau-matériel, c'est en soi rentrer dans la vaste controverse de l'intelligence artificielle, et ce n'est pas mon propos.)

La Loi des Bugs

Je ne suis pas loin de penser que l'énoncé suivant est une loi fondamentale du développement:

Il n'existe de bugs dans nos programmes qu'en raison de bugs dans notre pensée.

Le terme "bug" est en soi un choix terminologique malheureux, c'est un excellent exemple de la psychologie de la projection que j'évoquais dans un précédent billet: on visualise une petite bestiole dont l'existence et les décisions sont autonomes et indépendantes de notre volonté. Je lui préfère en général le terme "défaut", qui indique plus clairement ce qui est, selon moi, toujours à l'origine de ce qu'on appele familièrement un bug: une erreur du programmeur, se traduisant par un code source qui spécifie un comportement différent de ce qu'il devrait être.

Mais c'est au moins un terme familier, et si vous dites à quelqu'un "tu ne t'en aperçois pas mais ton cerveau est plein de bugs", vous êtes au moins sûr de faire une forte impression.

Biais cognitifs

L'étude des bugs du cerveau relève de la psychologie, et le terme plus communément accepté est celui de "biais cognitif". Contrairement à la situation qui prévaut dans le domaine du logiciel, les sciences cognitives ont produit, s'agissant des biais cognitifs, des connaissances scientifiques démontrées de façon robuste, répétable, qui ne sont plus affaire d'opinion. Indépendamment de ce que je voudrais croire ou de mes bonnes intentions, je suis bien contraint de reconnaitre que mon cerveau, à peu de choses près dans la même mesure que celui de mes congénères, est sujet à un certain nombre de biais cognitifs.

Intéressons-nous par exemple au biais de confirmation. Nous allons voir que ce phénomène, qui est par ailleurs l'un des plus importants et sournois dans la psychologie humaine, est tout à fait pertinent pour éclairer notre approche du développement logiciel.

Il est mis en évidence par de nombreuses expériences dont les premières remontent aux années 1960 avec les travaux de Peter Wason.

Wason montre à ses sujets un triplet composé de trois chiffres: (2, 4, 6) et indique que ce triplet répond à une "règle de construction" qu'il s'agit de deviner. Il demande aux sujets de lui fournir des exemples supplémentaires afin de "tester" diverses hypothèses quant à l'énoncé de cette règle. L'expérimentateur se borne à donner une réponse binaire: "oui, votre exemple est conforme à la règle" ou bien "non, votre exemple n'est pas conforme". C'est donc une tâche inductive, très ouverte par nature.

En étudiant de près les hypothèses formulées par les personnes confrontées à cet épreuve et les "essais" fournis successivement, Wason est en mesure de démontrer une tendance tout à fait systématique: on propose beaucoup plus facilement des exemples "de confirmation", c'est-à-dire conformes à l'hypothèse qu'on a la plus récemment formulée. Or c'est une erreur, car si des exemples confirmés peuvent nous amener à valider une réponse avant de la proposer, la démarche la plus fructueuse consiste à proposer des exemples qui (s'ils sont acceptés par l'expérimentateur comme conformes à la règle) invalident notre hypothèse et nous forcent à la reformuler.

D'autres expériences de Wason conforteront le "biais de confirmation" comme une erreur de raisonnement tellement courante qu'on peut la considérer comme systématique chez l'être humain: ainsi sur une tâche consistant à déterminer lesquelles parmi quatre cartes on doit retourner pour vérifier une règle du type "SI telle figure apparaît au recto ALORS telle autre doit apparaître au verso", seuls 10% des sujets donnent la bonne réponse! Ceci alors que plus de 90% des sujets reconnaissent, une fois qu'on leur a donné cette réponse, qu'elle est effectivement correcte et qu'ils pouvaient logiquement le déterminer à la lecture de l'énoncé: ce qui écarte donc l'hypothèse d'une ambiguité ou d'une mauvaise compréhension de la tâche.

(Si vous êtes tenté à la lecture de ce billet de développer vos propres facultés en matière d'induction et de formulation d'exemples contradictoires, essayez le jeu Zendo, passionnant pour les petits et les grands...)

Application au développement

Revenons au développement de logiciels, et plus précisément à un des épisodes de l'historique du génie logiciel. En 1976, Glenford Myers, auteur de l'ouvrage de référence "Software Reliability, Principles and Practices", écrit ceci:

Il est impossible de tester vos propres programmes. Aucun programmeur ne devrait tenter de tester son propre programme. Ceci s'applique à toutes les formes de test, que ce soit le test système, fonctionnel ou le test unitaire. [...] Le test doit être une activité extrêmement destructrice, et il est des raisons psychologiques profondes qui empêchent le programmeur d'adopter une attitude destructrice vis-à-vis de son propre programme."

Les mots employés sont très forts: "impossible", "toutes les formes de test". Myers ne cite pas Wason et ne détaille pas dans cet ouvrage les "raisons psychologiques profondes" auxquelles il fait allusion, mais il semble clairement s'agir de notre tendance à imaginer plus facilement des jeux d'essais qui visent à confirmer nos hypothèses que ceux pouvant les infirmer. (Il existe d'ailleurs quelques études cherchant à démontrer directement l'impact du biais de confirmation sur l'incidence des défauts dans le code.)

Cette affirmation que Myers présente comme un "axiome" deviendra pendant de nombreuses années l'orthodoxie en matière de test logiciel. (Une recherche Google avec la phrase "test their own code" donne assez facilement des exemples récents de billets d'opinion reprenant sans la critiquer cette idée, comme si elle allait de soi.)

En un sens, cette affirmation a eu un effet positif: elle a favorisé l'apparition d'une sous-discipline, le test indépendant, dont l'apport est certainement bénéfique; bien qu'en France la culture soit apparemment bien moins sensible à l'intérêt d'employer des personnes dans un rôle dédié de "testeur" ou "assurance qualité", par rapport aux Etats-Unis.

TDD ou l'inversion géniale

Pourtant, je soupçonne cette attitude d'avoir également généré de sérieux dégâts, en berçant d'innombrable développeurs dans la douillette illusion que "tester leur propre code" était non seulement une erreur mais une faute professionnelle. Pensez-y la prochaine fois que vous rencontrez sur un site Web une NullPointerException, l'exemple par excellence d'une défaillance logicielle qu'on peut parfaitement éviter en testant plus soigneusement son code.

Les choses n'ont commencé à changer que relativement récemment, et grâce à l'introduction de la pratique agile du Développement par les Tests (ou TDD).

Il s'agit pour moi (et pour d'autres, comme Steve McConnell dans Code Complete) de l'une des contributions majeures de la mouvance Agile à ce qu'il faut bien encore appeler le génie logiciel. Depuis les années 2000 le discours autour de cette pratique a considérablement évolué en sophistication, mais l'idée élémentaire est restée la même.

Elle exploite la notion d'un test unitaire automatisé, c'est-à-dire un bout de code qu'on écrit uniquement pour mettre en évidence qu'un autre bout de code (celui-là utilisé directement dans le programme réel) fonctionne comme attendu. Il va de soi qu'un test unitaire automatisé, en soi, reste un "test", un "essai" qu'on confronte à une hypothèse: l'automatisation ne change rien de fondamental.

Ce qui est radical, c'est l'idée suivante:

écrire le test avant d'écrire le code correspondant

Cela n'a l'air de rien mais cette simple inversion suffit simultanément:

• à donner raison à Glenford Myers sur l'importance du biais de confirmation en matière de test
• à lui donner tort sur les conclusions: un développeur peut et doit tester son code

En effet, avant d'avoir écrit un élément de programme, nous ne sommes pas sujets au biais de confirmation, puisque nous ignorons encore les détails de l'implémentation. Ces détails fonctionnenent en programmation comme l'hypothèse à tester dans la tâche de Wason: si nous avions connaissance de notre implémentation, nous serions tenté de ne penser qu'à des jeux d'essais qui confortent l'impression que nous avons que notre code est correct.

En inversant l'ordre de marche, nous avons tenu compte de nos propres limitations cognitives, et nous leur avons apporté une solution nettement plus efficace, car nécessitant moins de coordination, que la solution classique "embaucher des testeurs indépendants pour tester le code mal fichu des développeurs". (Cette dernière solution garde cependant de son intérêt, car il existe bien d'autres aspects de la qualité logicielle qui peuvent bénéficier du travail d'un testeur que la seule qualité technique du code source.)

Conclusions

Ce premier exemple donne une perspective un peu différente sur le TDD que celle habituellement présentée, et surtout démontrant à quel point s'intéresser au développement logiciel par le biais des sciences cognitives, et notamment par celui des biais cognitifs, peut être puissant et fructueux.


L'approche usuelle du génie logiciel a été d'écarter systématiquement ces considérations, qui reposent pourtant sur des bases scientifiques robustes, pour ne considérer que les aspects "objectifs" du logiciel, vu comme une "chose naturelle" indépendante de l'esprit humain qui l'a créé: c'est pourquoi, à mon sens, cette discipline telle qu'elle a été conçue jusque là ne peut pas résoudre les difficultés qu'elle prétendait aborder. Pour progresser, il est impératif de tenir compte des aspects cognitifs qui jouent un rôle déterminant dans la création de logiciels.

Le champ d'application de cette démarche va bien au-delà de la technique, on peut lui trouver des applications dans la gestion de projet, la gestion des compétences, l'estimation des délais, bref à l'ensemble des préoccupations des professions du logiciel.

Théorie de la rupture

La théorie de la rupture est due à Clayton Christensen qui la présente en 1997 dans The Innovator's Dilemma. Le sous-titre, éloquent, avertit du risque que présentent certaines innovations ou "ruptures technologiques": "lorsque de nouvelles technologies entraînent la chute de grandes entreprises".

Christensen distingue deux types d'innovation, l'innovation de continuité et l'innovation de rupture. La première est caractérisée par des produits qui renforcent, dans le contexte concurrentiel, la position dominante des acteurs déjà bien placés sur ce marché: ces produits sont jugés sur des critères de performance déjà reconnus. Imaginez par exemple la dernière génération des appareils photos numériques, qui passent de 8 à 12 megapixels. (Une innovation "révolutionnaire" n'est pas nécessairement une rupture en ce sens, ainsi l'article Wikipedia consacré à la théorie précise que l'automobile fut une révolution mais pas, dans ses effets sur les acteurs de l'économie industrielle, une véritable rupture.)

L'innovation de rupture se caractérise par l'ouverture de nouveaux marchés, et la mise en danger des acteurs dominants dans un marché donné; elle propose quelque chose d'inattendu en décalage avec les critères de valorisation dominants.

L'histoire de la photo numérique à ses débuts est à ce titre éclairante, sa victime emblématique étant Polaroid, l'un de ces noms de marque passés dans l'usage courant, tant son emprise sur un important segment du marché était complète. Pourtant, en 2001 Polaroid se mettait en faillite, pour ne renaître de ses cendres qu'à la suite du rachat de la marque et presque uniquement de cela par des investisseurs cherchant à profiter d'une image encore favorable.

Pourtant, seulement dix ans plus tôt, bien malin qui aurait pu prédire à la photographie le bel avenir qui est devenu notre présent: disparition inéluctable non seulement des modèles argentiques mais également de tout un secteur d'économie qui en dépendait, comme les petites boutiques qui assuraient le développement de nos "péloches".

Ainsi en 1991 le modèle Fotoman, est selon une critique pourtant lucide "incapable de produire des images de qualité professionnelle". En noir et blanc et d'une résolution maximum de 320x240, il coûte la bagatelle de 1000$. Ce n'est en fait qu'un gadget, conseillé aux personnes qui souhaitent s'amuser sur leur PC à triturer et retoucher leurs photos.

Comment un tel produit arrive-t-il, petit à petit, à s'imposer jusqu'à vingt ans plus tard avoir totalement détrôné la génération précédente? Pour avoir un début de réponse, il faut comprendre que les acteurs dominants du marché le sont en vertu de l'excellence de leurs produits selon des critères de performance appréciés par la clientèle: en l'occurrence, la finesse de l'image, le bon rendu des couleurs, etc. De ce point de vue la photo numérique présente des avantages (facilité de stockage, moins d'usure mécanique, manipulation numérique) mais ceux-ci ne sont pas suffisant pour l'emporter face aux concurrents dominants.

Oui, mais certains marchés n'ont que faire de ces critères de performance majeurs. Parmi les premiers clients auxquels s'adresse le numérique on trouve des fabricants d'avions, qui doivent prendre leurs appareils sous toutes les coutures pendant leur construction pour des raisons règlementaires, et vont donc faire des économies considérables sur le développement chimique, mais ne se soucient guère d'une résolution très fine. Ou bien encore des journalistes qui vont privilégier la transmission rapide d'une information brûlante mais ne sont que peu handicapés, compte tenu des qualités d'impression, par une résolution limitée ou par le noir et blanc.

L'innovation de rupture est donc portée par des produits initialement totalement inadéquats quand on les juge à l'aune des critères de performance établis, mais qui vont conquérir un marché de niche puis se développer. L'innovation plus classique, "de continuité", permet progressivement à ces produits de rattraper tout ou partie de leur retard sur ces critères dominants, et c'est ainsi qu'ils peuvent finir par mettre en danger les leaders du marché.

Alors, en quoi le débat entre "Génie Logiciel" et "Agile" peut-il être considéré comme une instantiation de ce modèle? Certes, il faut faire preuve d'un peu de prudence: considérer l'un et l'autre comme des "produits" en concurrence sur un "marché" relève, sinon de la métaphore, d'une moins d'une interprétation assez libre de ces termes. Je trouve pourtant que le modèle s'applique plutôt bien, et permet d'expliquer non seulement le succès initial de l'approche Agile mais également ses évolutions au cours des dernières années. (Evolutions qui sont souvent mal connues des personnes qui pratiquent ces approches et même de certains experts: toujours ce blocage sur l'histoire...)

L'idée est donc d'analyser le Génie Logiciel comme le produit dominant, et d'expliquer cette domination par le fait qu'il répond aux critères exigés par le marché. L'histoire du projet Chorus nous suggère que "le succès du projet" ne fait pas nécessairement partie de ces critères... alors quels sont-ils? Selon quel critère de performance le discours classique du Génie Logiciel, issu des conférences de 1968 et 1969, est-il, malgré ces échecs, jugé satisfaisant, à tel point qu'on enseigne encore le cycle en V dans les universités?

Je laisse la question en suspens jusqu'au prochain billet... A vous de réagir dans les commentaires.

Chorus, une histoire pas drôle

Lors de mes interventions (par exemple dernièrement pour Agile Tour Nancy) sur le sujet que j'ai abordé au fil des précédents billets, il y a toujours un moment ou je sais que j'arriverai à tirer un rire de toute la salle: je viens de rappeler la date de naissance du Génie Logiciel et le contexte de sa création, celui de la "crise du logiciel".

Il n'y a plus qu'à lancer un constat: "Heureusement, nous avons tous remarqué que la Crise du Logiciel est maintenant résolue." Effet garanti.

Quels étaient effet les symptômes de ladite Crise en 1968? Dépassement de délais, mauvaise qualité, inadaptation des logiciels aux besoins des utilisateurs...

Que peut-on observer en 2010? Qu'il existe encore des projets comme Chorus. Si vous n'en avez jamais entendu parler, je vous conseille de vous documenter: c'est de votre argent qu'il s'agit, puisque Chorus est le nouveau système d'information destiné à toutes les administrations françaises. Le projet prévu sur quatre ans démarre en Mars 2006, son coût annoncé aux parlementaires à l'origine est déjà important: 600M€.

Dès le début 2008 apparaissent les premières dérives et l'on apprend que des retards sont à envisager, que le budget serait dépassé. Fin 2008, une "mise au point" du ministère permet d'apprendre qu'en fait le budget communiqué ne tenait pas compte des coûts de fonctionnement, chiffrés à 100M€ annuels sur cinq ans: la facture serait donc de 1,1Md€. Un petit oubli, en somme. (Un rapport parlementaire de juillet 2010, un peu inquiétant, recommande "d'actualiser l'évaluation du coût complet de Chorus" - ce qui laisse supposer que ce coût réel est encore inconnu à l'heure actuelle...) Les délais s'accumulent, et dès 2009 Chorus qui devait être déployé entièrement à partir de 2010 se voit repoussé à janvier 2011, et ce malgré une révision à la baisse de ses objectifs fonctionnels.

Il y a pire: Chorus... ne fonctionne pas. Plus exactement son installation perturbe le paiement des factures aux fournisseurs des administrations. Alors que l'Etat gronde le secteur privé sur les délais de paiement, son propre système d'information met en difficulté de très nombreuses PME qui se retrouvent dans l'incapacité d'encaisser leur dû: un comble! Est-ce une difficulté transitoire? C'est en tout cas un transitoire qui dure... et la Cour des Comptes émet des réserves sur l'éventualité que Chorus puisse un jour assumer pleinement la comptabilité de l'Etat français.

Alors, oui, cela fait rire, de constater que quarante ans après, les méthodes proposées par le Génie Logiciel, loin d'avoir résolu la crise, semblent contribuer à la perpétuer: c'est évidemment un rire jaune.

Pourtant force est de constater que le Génie Logiciel se porte bien. On enseigne toujours le cycle en V dans les universités: voici un exemple, notez cependant qu'à l'heure où j'écris ces lignes il vous sera nécessaire de défiler plusieurs pages d'avertissements PHP avant de lire le descriptif de cette unité d'enseignement. (Tout un symbole...)

Comment comprendre cette situation dominante occupée par le Génie Logiciel? Et quelle grille de lecture nous permettrait de mieux appréhender le positionnement des approches Agiles dans ce débat? J'ai trouvé un certain nombre d'explications dans les thèses de Christensen, auteur de la Théorie de la Rupture. Ce sera le sujet du prochain billet.

La cascade, retour aux sources

Si vous avez apprécié le précédent billet sur la discrète et méconnue histoire du Génie Logiciel, je vous recommande chaudement cette vidéo d'une intervention de Glen Vanderburg en partie sur le même sujet.

Dans la série "comprendre l'origine des idées pour éviter de nous faire piéger par elles", Glen retrace également l'historique du "waterfall" ou processus en cascade, dont le fameux "cycle en V" est une variante mieux connue en France.

On y découvre que la raison de la popularité de ce processus d'ingénierie est que la plupart des lecteurs ont préféré retenir le diagramme n°3 dans le papier de Winston Royce datant de 1970, et ce malgré l'avertissement de Royce sur l'aspect "dangereux et incomplet" du processus représenté dans ledit diagramme; oui, mais les diagrammes suivants dans ce même article étaient... de plus en plus complexes, puisque représentant une pensée plus sophistiquée, et par voie de conséquence impossibles à graver en mémoire aussi facilement. Il n'en fallait pas plus pour que de nombreux décideurs et influenceurs ne gardent en mémoire que la solution "simple, élégante et totalement fausse" selon la citation de H.L. Mencken.

Cette théorie est intéressante (et la conférence de Glen savoureuse), mais un peu battue en brèche par la lecture attentive des actes de la conférence de 1968, puisque dès le second diagramme contenu dans ces derniers on peut tomber sur une représentation tout à fait classique en phases successives du processus de développement, et ce deux ans donc avant l'article de Royce.

Il est cependant exact que c'est l'article de Royce qui sera pendant des années cité comme principal soutien d'une conception "phasiste" de l'organisation des activités de développement. A vous de juger de la pertinence de cette théorie!

Quarante ans de crise

Connaissez-vous l'expression "crise du logiciel"? Peut-être connaissez-vous un peu mieux une de ses manifestations, la célèbre illustration du "Projet Balançoire". Tellement célèbre qu'elle a depuis quelque temps son propre site web 2.0, normalement elle se passe de commentaires...

Le terme "crise du logiciel" est contemporain d'une autre expression certainement plus familière, "Génie Logiciel", formulée en 1968 lors d'une conférence organisée sous les auspices de l'OTAN. La seconde fut proposée comme solution de la première.

La Crise se manifestait par divers aspects. Les projets de développement dépassaient les délais et budgets impartis, les logiciels produits étaient de mauvaise qualité et leurs performances insuffisantes, ils ne répondaient pas aux exigences exprimées, ils étaient difficiles à faire évoluer.

Il y eut non pas une mais deux conférences de l'OTAN sur le Génie Logiciel, à un an d'intervalle. Que se passa-t-il durant ces douze mois? Presque en filigrane du discours officiel, on devine un événement d'importance.

En 1968, la première conférence semble poser une question. "L'approche de l'ingénieur est-elle appropriée pour aborder le développement de logiciels?" Environ cinquante experts venus de onze pays sont présents. Parmi les participants on compte des sommités comme Edsger Dijkstra (connu pour sa campagne contre le "goto" et en faveur de la programmation structurée), Alan Perlis (créateur d'Algol et auteur de proverbes qui sont au logiciel ce qu'une certaine tradition japonaise est au jeu de Go) ou Peter Naur (co-crédité de l'invention de la notation BNF pour décrire les langages de programmation).

Les actes des deux conférences disponibles sur le Web, dans une version PDF d'une qualité remarquable alors que la plupart des documents de cette époque sont en général simplement scannés, donc non indexés ni "cherchables", méritent d'être lus avec attention; j'avoue ne les avoir que trop rapidement parcourus jusqu'à présent, en tout cas pas avec la minutie qu'un historien leur accorderait. On y trouve par exemple ce conseil de Peter Naur qui recommande de s'intéresser aux idées d'un jeune architecte, Christopher Alexander. Le même Alexander qui sera redécouvert vingt anx plus tard par un certain Kent Beck, donnant naissance au mouvement des Design Patterns. Structurés d'une façon très systématique, ils couvrent la quasi-totalité des préoccupations encore d'actualité aujourd'hui quant à la façon de mener des projets dans le domaine du logiciel.


Ces documents sont éloquents quant au degré de controverse que suscite la question du génie logiciel. Voici une citation d'un participant: "La chose la plus dangereuse dans le domaine du logiciel est l'idée, apparemment presque universelle, que vous allez spécifier ce qu'il y a à réaliser, puis le réaliser. Voilà d'où viennent la plupart de nos ennuis. On appelle réussis les projets qui sont conformes à leurs spécifications. Mais ces spécifications s'appuient sur l'ignorance dans laquelle étaient les concepteurs avant de démarrer le boulot!"

Les titres de la conférence de 1968 reflètent un certain degré d'incertitude: "Réflexions sur le séquencement de l'écriture d'un logiciel", "Vers une méthodologie de la conception", "Quelques réflexions sur la production de systèmes de grande taille". Certes la plupart des participants utilisent l'expression "Génie Logiciel" comme si elle allait de soi, et des lacunes sont déjà apparentes (on parle notamment assez peu du facteur humain), mais on peut deviner une véritable controverse sur les grandes lignes de ce qui préoccupera cette discipline.

En 1969 les titres des articles proposés ont gagné en assurance. "Critères pour un langage de description de systèmes", "La conception de systèmes très fiables en exploitation continue", etc. Mais c'est surtout en lisant entre les lignes qu'on décèle un changement, et notamment en lisant "The Writing of the NATO reports" de Brian Randell, une sorte de "making of" datant de 1996. Une drôle d'ambiance règne apparemment à la conférence de 1969, mais on ne peut que la deviner dans la description à demi-mot qu'en fait Randell:

Contrairement à la première conférence, ou il était tout à fait clair que le terme de Génie Logiciel reflétait l'expression d'un besoin plutôt qu'une réalité, à Rome on avait déjà tendance à en parler comme si le sujet existait déjà. Et, pendant la conférence, l'intention cachée des organisateurs se précisa, à savoir: persuader l'OTAN de financer la mise en place d'un Institut International du Génie Logiciel. Cependant les choses ne se passèrent pas comme ils l'avaient prévu. Les sessions qui étaient censées fournir les preuves d'un large et ferme soutien à cette initiative furent en fait dominées par le plus grand scepticisme, au point qu'un des participants, Tom Simpson de chez IBM, écrivit une superbe et courte satire intitulée "Masterpiece Engineering" (Ingénierie du Chef-d'Oeuvre).

Un article qui parlait, par exemple, de mesurer la productivité des peintres en nombre de coups de pinceau par journée. Et Randell d'ajouter que les organisateurs réussirent à le "persuader" d'omettre cet article satirique de Tom Simpson des actes officiels!

L'acte de naissance définitif du Génie Logiciel ayant ainsi été associé à un acte de censure, Randell ajoute qu'il s'interdit pendant la décennie qui suivit d'utiliser le terme, le jugeant injustifié. Il n'acceptera de revenir sur cette décision que pour une conférence marquant en 1979 le dixième anniversaire de Rome, où il profita de l'occasion pour adresser à Barry Boehm, alors la "nouvelle star" de la discipline, une série de piques, que Boehm "ignora soigneusement, je suis navré de le rapporter, à moins qu'il n'ait pas été en mesure de les reconnaitre comme telles".

Ingénieur en logiciel, un métier sans histoire?

Souvent, pour prendre du recul par rapport au monde du logiciel, je m'évade vers d'autres disciplines. Au cours de ces balades, le paysage m'étant par définition étranger, j'ai le loisir de me comporter en touriste, sans me sentir aggressé lorsqu'une de mes idées toutes faites, confrontée à la réalité locale, se retrouve bouleversée.

Parmi les guides que j'affectionne, Stephen Jay Gould était particulièrement doué pour emmener le lecteur dans un coin intéressant de son propre fief, la biologie et l'évolution. J'ai surtout apprécié dans ses écrits l'usage qu'il faisait de l'histoire des idées scientifiques. Il n'avait pas son pareil pour montrer comment, loin d'être un inexorable progrès comme peut le laisser croire certaines images d'Epinal, de nombreuses découvertes sont le fait de curieux renversements, et bien souvent la lecture qui en est faite finit elle aussi à l'envers de la réalité.

Dans Aux Racines du Temps, par exemple, Gould revient sur les portraits souvent dressés de trois acteurs importants dans l'estimation de l'âge de la Terre et des débuts du "temps géologique", un débat qui est un précurseur important à l'acceptation des théories de Darwin: pour que l'évolution puisse avoir lieu, il faut que nos origines remontent à bien plus que la période donnée par la Bible, à savoir quelques milliers d'années seulement.

L'image d'Epinal de ce débat est celle de deux héros (Hutton et Lyell) triomphant, grâce à leur lucidité scientifique et leur courage exemplaire, du rétrograde et fondamentaliste Thomas Burnet. Gould met en évidence l'inspiration véritable, fortement naturaliste, des arguments avancés par Burnet, la forte emprise idéologique sous laquelle Hutton formula les siens ou le scepticisme de Lyell vis-à-vis des idées de Darwin. Le travail de Gould est minutieusement documenté, étayé notamment par une lecture de première main des textes originaux, lesquels éclairent de façon implacable sur les motivations véritables des uns et des autres.

A lire Gould, on comprend qu'il faut se méfier d'une interprétation trop simpliste de l'histoire des idées. Plus nous travaillons dans le monde des idées, plus les idées peuvent exercer sur nous un contrôle d'autant plus fort et d'autant plus insidieux que nous en ignorons les origines.
C'est à ce stade que souvent, loin de rester de simples promenades, ces lectures me ramènent indirectement à mon propre métier.

Je me fais parfois la réflexion que notre profession tourne résolument le dos à sa propre histoire. Je ne prétends pas être particulièrement bon élève de ce point de vue, et lors de mes courtes études, l'histoire était parmi mes points faibles. Je manque sans doute cruellement de culture générale, mais au sein de ma propre profession, je me fais parfois l'impression du borgne au royaume des aveugles.

Ainsi des idées nous sont-elles présentées comme "neuves" et "révolutionnaires" alors que, pour qui s'est penché sur l'historique de la discipline, il ne s'agit que de réchauffé: des idées présentes dans tel ou tel dialecte de Lisp ou de Smalltalk depuis trente ou quarante ans. (Si vous ne me croyez pas, penchez-vous sur les comparaisons entre XML et les "s-expressions" ou entre la Programmation Orientée Aspects et les MOP ou Meta-Object Protocols.)

On pourrait aussi se demander combien, parmi ceux qui se réclament aujourd'hui du mouvement Agile, ont conscience de ses prédécesseurs, tels le RAD ou le Processus en Spirale dû à Barry Boehm. De façon générale, notre profession tend à considérer toute idée âge de plus de cinq ans comme obsolète et peu digne d'intérêt, et c'est sans doute en partie pour cela qu'on a parfois l'impression que notre industrie est aussi dominée par des cycles de mode que la haute couture.

Parmi les idées qui ont façonné les métiers du logiciel, une l'a fait de façon particulièrement forte et durable, l'idée du Génie Logiciel. Le logiciel relève-t-il vraiment d'une activité d'ingénieur? La question, lancinante, revient comme un serpent de mer dans les conférences consacrées au sujet, mais elle est rarement traitée sous un angle historique.

Au quotidien, trop rares sont ceux qui semblent conscients que le "logiciel" ayant lui-même une histoire d'à peine plus d'un demi-siècle, il a bien fallu inventer l'expression Génie Logiciel; que celle-ci ne va pas de soi, et que l'application des techniques de l'ingénieur au domaine du logiciel relève, non pas des lois de la nature, mais d'une décision à laquelle il a fallu rallier divers groupes: des militaires, des scientifiques, des groupes industriels.

Nous allons donc nous plonger dans la discrète histoire du Génie Logiciel. C'est une excursion qui a de quoi satisfaire les esprits curieux, même s'il devaient en ressortir plus convaincus que jamais de la pertinence de ce mariage. Mais nous verrons que cette histoire a de quoi alimenter bien des doutes...