logo site
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

Contre les méthodes de conduite de projet

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
Les architectes avec nous !
Emmanuel Saint-James - le 2 octobre 2014

Bonjour Laurent

Ton article, auquel je souscris pour l’essentiel, contient une inexactitude
sur laquelle je vais rebondir. Tu parles de l’introduction
du "couple maître d’ouvrage - maître d’œuvre, en oubliant curieusement
l’architecte au passage". L’architecte n’est pas oublié, c’est lui le
maître d’oeuvre la plupart du temps (voir l’article maîtrise d’oeuvre
de Wikipedia et ses liens vers les définitions juridiques), mais cette
locution a été préférée parce qu’elle recouvre le travail
en équipe lorsqu’il s’agit d’une agence d’architectes et non d’un
seul, et aussi le cas d’un ingénieur et non d’un
architecte (ou de nouveau une agence d’ingénieurs autrement dit un
bureau d’études). Vu ton affection pour le travail en équipe et le
métier d’ingénieur, tu apprécieras sûremente la place qui leur est
ainsi faite, et à raison tant les architectes tombent facilement
dans un dogmatisme esthétique (le néo-classicisme hier, le totalitarisme
de l’angle droit aujourd’hui).

Maintenant je voudrais relever que l’analogie entre projets
informatique et architectural est d’autant plus malvenue qu’elle
repose sur une vision idéalisée du projet architectural. Ayant été
maître d’ouvrage une fois dans ma vie, j’ai été très frappé de la similitude
entre les ratés du chantier et ceux des projets informatiques.
Un projet architectural est lui aussi soumis a
des aléas entre la rédaction de son cahier des charges et la livraison
du produit fini : description inexacte du sous-sol du terrain par le
bureau des mines, services de l’urbanisme et de la voirie émettant des demandes contradictoires, voisins qui s’opposent au permis de
construire, demandes injustifiées des banquiers et assureurs, et je ne
parle que de mon vécu personnel, j’en ai entendu de pires. A chaque
fois, l’architecte doit repenser les spécifications du projet
comme tu le racontes pour un projet informatique s’il ne
veut pas déboucher sur un produit insatisfaisant. Et c’est justement
lorsque ces retours sur les spécifications sont traités trop
précipitamment que des erreurs apparaissent en fin de chantier,
exactement comme ces bugs qui surviennent lorsqu’on étend un programme à des spécifications non prévues au départ.

Comme il est plus facile de corriger des erreurs de programmation que
des erreurs de bétonneuse, on peut croire que les deux types de
projets sont différents, mais je crois plutôt que cette facilité du
premier autorise une réflexion rétrospective suivie d’effet, alors qu’on se l’interdit seulement pour ne pas remuer le couteau dans la plaie pour un produit architectural car on sait qu’il devra inévitablement accepté en l’état.
Ce que ça révèle dans les deux cas, c’est que nous manquons de méthodologies pour rédiger de bonnes spécifications.
Le critère final est bien le même : le quotidien des utilisateurs a-t-il amélioré ?
Mais comment décliner cela concrètement
sans tomber dans une description procédurière d’une réalisation trop précise
pour s’adapter aux aléas du chantier ? Vaste question.•

Derniers commentaires

0 | 5 | 10

Information, données, codage informatique
Merci pour cette contribution. Cela dit, la « bijection avec l’ensemble des citoyens » est plus (...)

Information, données, codage informatique
Bonjour, La concision du texte le rend effectivement pédagogique, et en introduisant le concept (...)

Histoire et avenir des processeurs RISC
Merci de votre contribution. Ci-dessous quelques réponses : 1. L’agencement du texte du (...)

Processeurs asynchrones, ascenseurs embouteillés et emploi du temps
Bonjour, une remarque : "Aussi existe-t-il un domaine de recherche prometteur, les processeurs (...)

Histoire et avenir des processeurs RISC
Bonjour, je salue ce bel effort que je viens de parcourir en diagonale, ma recherche initiale (...)