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
logo imprimer
Licence : CC by-nd

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.


Forum
Répondre à cet article
Richard Feynman et la conduite de projets
Aredius44 - le 21 août 2015

J’ai suivi lors de la conférence Jules Verne de 2015 un exposé de François Delarosière
https://fr.wikipedia.org/wiki/Fran%C3%A7ois_Delarozi%C3%A8re

d’après ce que j’ai compris, il est très loin de toute "méthode" de conduite de projets. Pourtant il tient les délais et fait des machines qui n’ont rien de simple.

voir
http://lefenetrou.blogspot.fr/2015/08/nantes-lelephant-rencontre-le-cheval.html

Richard Feynman et la conduite de projets
Jean KOTT - le 13 février 2015

Bonjour Laurent,
Sur les méthodes, on a dit tout et le contraire de tout. Je commence par tordre le cou à deux postulats implicites, évidemment faux, qui guident un peu trop, du moins à mon goût, les actions de management sur les projets grands ou petits :
Postulat n° 1 : Tout problème admet une solution optimale atteignable en un temps et un coût bornés à l’avance
Postulat n° 2 : Il existe un procédé effectif permettant de faire aboutir un projet dans les bornes fixées au postulat n° 1.

La réalité est que le Monde n’est pas un domaine récursif et que croire en ces deux postulats donc déterminer des moyens avant d’avoir la moindre idée de ce qui attend les équipes qui vont travailler dessus est un facteur dont la conséquence peut être un échec cuisant sur le plan financier et humain. A part la méthode pointée par R.Feynman (dont j’ai dévoré plus jeune son bouquin de physique) on ne nous dit rien des contraintes techniques et financières sous lesquelles ont travaillé les équipes du projet en question.
La seule expérience précédente était Apollo qui a eu des moyens pratiquement illimités (les Américains voulaient être sur la Lune avant les Soviétiques) et dont l’intégration a été assez prudente. Il y eut pourtant 3 morts en 1967 (je crois) suite à l’incendie qui a ravagé une capsule sur le point d’être lancée avec ses trois astronautes à bord. L’extraordinaire réussite de la mission et la grande redondance du système qui a permis le sauvetage de l’équipage d’Apollo XIII ont fini par faire oublier les risques inhérents à de tels projets. En outre, la Navette était un concept entièrement nouveau et l’expérience acquise ne pouvait bénéficier que de manière fragmentaire.

Pour en revenir au top down, ce n’est pas incompatible avec la prudence en intégration (on teste des petits éléments et on les intègre petit à petit) mais on se trouve avec la même problématique que ce que tu évoques dans ton article à savoir qu’une erreur détectée à l’intégration peut remettre en cause toute la conception initiale, il est hélas bien tard pour s’en rendre compte. Dans un tel cas, on préfère avoir recours à des verrues et des patchs plus moins heureux dont on ne peut réellement anticiper quels seront les effets lors de la mise en production.

Sur une méthode top-down, adaptée à un projet partant de la feuille blanche, il faut accepter l’idée que ni les coûts, ni les délais ne pourront être garantis car les incertitudes sont trop grandes surtout en l’absence d’expérience précédente. C’est pour ça qu’aujourd’hui en entreprise, on préfère développer à partir de composants existants et éprouvés au sein de grands progiciels (tels les ERP) dont l’implémentation en entreprise est mieux maîtrisée par les équipes des éditeurs. On se prive probablement de bonnes idées en procédant ainsi mais on cherche plus à limiter les risques qu’autre chose.

J’arrête là sous peine d’être poursuivi par la Police du Web pour délit d’abus de commentaire confinant au délit d’opinion mais, je pense reprendre ce commentaire sous forme d’un papier plus long et mieux organisé.



pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.31