Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Richard Feynman et la conduite de projets
Article mis en ligne le 4 février 2015

par Laurent Bloch

Un des derniers écrits du physicien Richard P. Feynman, prix Nobel 1965, fut une annexe au rapport de la Commission Rogers rédigé à la demande des autorités gouvernementales américaines à la suite de l’accident dramatique de la navette spatiale Challenger le 28 janvier 1986 et destiné à en élucider les circonstances. Il y a suffisamment de points communs entre un sinistre spatial et un sinistre informatique pour que les leçons tirées de celui-là puissent être utiles à ceux qui se préoccupent de celui-ci ; en effet, si les objets produits par l’industrie spatiale et par l’industrie informatique paraissent très dissemblables, les méthodes de conduite de projet mises en œuvre dans l’un et l’autre cas puisent à la même source d’inspiration (le projet Apollo dans les années 1960), et risquent donc d’avoir des effets similaires. En outre, même si le risque semble bien moindre de mettre en danger des vies humaines dans le second cas que dans le premier, il convient de noter qu’une navette spatiale incorpore des millions de lignes de logiciel informatique, soit embarqué soit dans les installations au sol, sans oublier les programmes qui ont servi à sa conception. Il n’y a donc aucune raison de se priver des enseignements prodigués à cette occasion par un des scientifiques les plus réputés du XXe siècle, notamment pour ses talents pédagogiques.

Pour établir son rapport, R. Feynman a rencontré différents experts qui avaient participé à la conception et à la réalisation de la navette spatiale, ou qui avaient donné des consultations à son sujet avant ou après l’accident, et il a lu leurs rapports. Il a été frappé par la discordance extraordinaire, parmi les experts et les officiels de la NASA, des opinions relatives au risque d’accident mortel, puisqu’elles vont de 1 accident sur 100 vols à 1 accident sur 100 000 vols, où les premières émanent surtout des ingénieurs qui ont réellement travaillé sur le projet, et les dernières plutôt des managers. Il a également observé la diminution au fil du temps de la sévérité des critères de certification, au fur et à mesure que les vols sans incidents instauraient l’idée que « puisque le risque avait été encouru jusqu’à présent sans qu’un accident survienne, il pouvait être accepté pour la prochaine fois ».

Pour ce qui nous concerne ici, le passage le plus intéressant du texte est celui qui a trait aux moteurs à combustible liquide de la navette (Space Shuttle Main Engines, SSME). Ces composants sont parmi les plus complexes de l’ensemble. Feynman explique que la méthode habituelle de conception de tels moteurs (par exemple pour des avions civils ou militaires) procède selon une démarche de bas en haut (bottom up) : on commence par étudier les caractéristiques souhaitables des matériaux à utiliser, puis on teste des pièces élémentaires au banc d’essai. Sur la base des connaissances acquises ainsi, on commence à tester des sous-ensembles plus complexes. Les défauts et les erreurs de conception sont corrigés au fur et à mesure : comme ils ne portent que sur des parties de l’ensemble, les coûts sont modérés. Si des défauts sont encore détectés au moment de l’assemblage de l’ensemble, ils restent relativement faciles à localiser et à corriger, notamment du fait de l’expérience acquise par les tests de sous-ensembles.

Or les moteurs à combustible liquide de la navette n’ont pas été conçus selon cette démarche bottom up, mais selon l’approche inverse, de haut en bas (top down), c’est-à-dire que le moteur a été conçu et réalisé tout en même temps, avec très peu d’études et d’essais préalables des matériaux et des composants ; avec une telle démarche, la recherche de l’origine d’un défaut ou d’une erreur de conception est beaucoup plus difficile qu’avec la méthode bottom up, parce que l’on dispose de peu d’informations sur les caractéristiques des composants. Il faut alors utiliser le moteur complet comme banc d’essai pour trouver la panne, ce qui est très difficile et onéreux. Il est en outre difficile dans ces conditions d’acquérir une compréhension détaillée des caractéristiques et du fonctionnement du moteur, compréhension qui aurait été de nature à fonder la confiance que l’on aurait pu avoir en lui.

La méthode top down a un autre inconvénient : si l’on trouve une erreur de conception sur un sous-ensemble, comme la conception n’en a pas été isolée, mais intégrée dans la conception d’ensemble, il faut repenser la conception générale. Il est à craindre que pour des erreurs jugées mineures (à tort ou à raison), la lourdeur des investigations à entreprendre n’incite pas à renoncer à reprendre la conception de l’ensemble, alors qu’il faudrait le faire.

Nous pensons que cette critique de la méthode top down par Richard P. Feynman s’applique bien aux systèmes informatiques, et particulièrement aux systèmes de sécurité informatique. Mais ne lui faisons pas dire ce qu’elle ne dit pas : il convient bien sûr d’avoir une vision d’ensemble du système, simplement il ne faut pas lui accorder les vertus qu’elle n’a pas, elle ne doit pas être trop précise, ce n’est pas d’elle qu’il faudra déduire la conception détaillée des éléments et des sous-systèmes.