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 :

Forum de l’article

Richard Feynman et la conduite de projets

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
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é.

Derniers commentaires

Une illustration de la concurrence monopolistique
Attention : les GPU sont très forts en produits scalaires, (en multiplication de matrices par (...)

Python
"on dit plutôt maintenant développeurs" ... Il y a (au moins) deux expressions qui (...)

À la Commission de développement de l’informatique du Ministère des Finances
Article tout aussi instructif que plaisant à lire. On pensera aussi à "Comédies Françaises", (...)

À la Commission de développement de l’informatique du Ministère des Finances
Dans le style qui t’est caractéristique, j’avoue que j’ai bien aimé ! J’ai même eu l’occasion (...)

Informatique confidentielle
La clé pour comprendre est peut-être qu’il s’agit ici de "machine virtuelle" et non de (...)