Par Roger CADIERGUES le 04 Juillet 2019
La lettre précédente résumait les défis essentiels auxquels nous sommes apparemment confrontés, et les exigences en résultant. C'est la poursuite de cet examen que nous allons faire maintenant.
Nous en étions restés aux obstacles dits 4 et 5
Exactement, les obstacles suivants :
4. Le volume des connaissances nécessaires à nos métiers
ne cesse d'augmenter.
5. Les données et les procédures n'arrêtent pas d'évoluer.
Pour vaincre ces obstacles je vous propose de rêver un peu, comme si tous
les problèmes étaient résolus. Nous verrons ensuite comment
la réalité peut se conformer aux besoins que je viens d'exprimer.
"Rêvons" donc puisque vous le souhaitez
La croissance des compétences et l'instabilité des contraintes et procédures sont désormais les deux clefs fondamentales de nos métiers. Face à ce défi l'idée la plus séduisante est de "tout mettre" sur Internet, ce qui a l'avantage d'une mise à jour continue. Hélas c'est un vrai piège.
Avouez que vous entendre dire au sein d'un site Internet qu'"Internet est un piège" a de quoi surprendre
Bien entendu votre surprise est naturelle. Pour m'expliquer je vais prendre
un exemple, fictif certes, mais proche de ce qui peut survenir. Il s'agit du
calcul le plus traditionnel des spécialistes du chauffage, celui des
coefficients U (jadis K) des parois à partir des conductivités
thermiques. Pour ce faire vous utilisez des tables de conductivité des
principaux matériaux de construction. Supposons (ce n'est pas une utopie
comme le montrent des incidents récents) que :
- jusqu'à fin Décembre 2005 la table recommandée est la
table "Lambda2005",
- mais qu'à partir du 1er Janvier 2006 la table recommandée soit
la table "Lambda2006".
Votre réaction normale est de dire qu'à partir du 1 Janvier 2006
tous les projets seront calculés avec Lambda2006. Supposons que nous
venions à contrôler, sinon même à modifier partiellement
un projet qui ait été calculé non pas en 2006 mais en Décembre
2005, la décision n'est pas simple, car cette situat
Qu'entendez-vous par problème de fond ?
Le simple problème suivant : les rédacteurs de normes (non pas ceux de règlements) n'indiquent pas une date à partir de laquelle la norme est applicable. Il faudrait manifestement que soit prévu un temps d'adaptation. Et un temps de neutralisation pendant lequel les projets en cours respecteraient "l'ancienne" norme. C'est simple : vous ne pouvez pas reprendre tous les calculs d'un projet en cours parce que, du jour au lendemain, les règles qu'on veut vous imposer ont changé.
Qu'entendez-vous par problème pratique ?
Exactement le même. Mais surtout que les données, comme les procédures
doivent être datées. Si votre documentation a purement et simplement
remplacé les tables Lambda2005 par les tables Lambda 2006 vous ne pouvez
travailler sur les projets commencés en 2005 que si vous avez pris la
précaution de conserver Lambda2005.
Cette situation signifie qu'il ne faut pas suivre aveuglément l'évolution
des procédures ou des données. Il faut admettre (ce qui semble
curieusement surprenant à certains esprits) que les données et
les procédures recommandées doivent être datées,
et n'ont pas une valeur intemporelle. Evolutivité oui, mais datation
également : tel est la condition de base à respecter.
En supposant qu'il en est ainsi, comment voyez-vous vaincre les obstacles que vous avez appelés 4 et 5 ?
C'est assez facile à faire, du moins théoriquement. Car la réalité
est là : les données et les outils d'un moment sont très
souvent dépassés par le temps. Inutile de le cacher, c'est un
défi très lourd. Facile à dénoncer, difficile à
vaincre. C'est pourtant ce que nous vous proposerons de faire en 2006.
C'est ainsi, sur cette parole d'espoir, que se clôt la lettre hebdomadaire,
dont le remplaçant 2006 se met dès maintenant en place. En vous
remerciant, en tous cas, pour votre attention et vos réactions sur la
lettre hebdomadaire, en espérant vous revoir bientôt, je vous invite
sur le nouvel espace 2006 en cours de création. Sachez que, grâce
à vous, nous continuerons plus que jamais …
Roger CADIERGUES
