Je vais peut être enfoncer des portes ouvertes mais la visite de cette villa magique m'a rappelé que les grandes problématiques d'architecture, de conception et de maintenance restaient les mêmes dans tous les domaines techniques. Le monde du génie logiciel, malgré son caractère souvent perçu comme immatériel, n'échappe peut-être pas à cette règle.
Étonnante de modernisme pour les années 1930 (TSF intégrée dans toutes les pièces, horloges synchronisées dans chaque salle, un troisième robinet pour de l'eau adoucie dans les cuisines et salles de bain, ...) ce "château moderne" a également la particularité d'avoir été conçu et réalisé en seulement 3 ans par l'architecte Robert Mallet-Stevens sur commande du riche industriel local Paul Cavrois. Ce dernier avait fixé son budget, ses exigences (une maison pour sa famille nombreuse et pour ses employés également, une maison moderne, ...) mais il avait également laissé entière liberté de conception et de réalisation à l'architecte, y compris concernant le mobilier et la décoration.
Cette villa a, depuis la seconde guerre mondiale et l'occupation, connu plusieurs périodes d'abandon, de pillage et de vandalisme.
Après la libération, la famille Cavrois doit consacrer 12 ans à une première réhabilitation de la villa.
Après le décès de Mme Cavrois, en 1985, la villa est revendue à un promoteur souhaitant la détruire pour bâtir un lotissement.
En 1990 la villa est classée monument historique. En 2001 débutent les travaux de restauration pour remettre le parc et la villa dans leur état de 1932.
A ce jour, en 2024, 23 ans et 23 millions d'euros plus tard, seuls 80% des lieux ont été restaurés et remeublés.
Pourquoi un tel écart entre les trois ans nécessaires à la construction de la villa et la vingtaine d'années nécessaires à sa restauration ?
Je ne suis pas historien et je suis loin de connaitre tous les détails de la vie de cette villa, mais plusieurs points m'ont interpelé lors de la visite, car ils ont résonné en moi comme autant de points de similitudes avec les problématiques que j'ai pu rencontrer le plus régulièrement durant mes 25 ans d'expérience en génie logiciel.
Le confort de la page blanche versus le défi posé par l'existant
C'est ce premier point qui m'a interpellé : un mécène donnant carte blanche à un architecte pour aller jusqu'au bout de sa vision.
Quel ingénieur n'a jamais rêvé de partir d'une feuille blanche, de zero, du néant pour matérialiser ses concepts ? Peut-on être ingénieur (ou architecte) sans une fibre créatrice ? Personnellement je ne pense pas.
Cette situation est de mon point de vue la plus confortable et la plus gratifiante.
J'ai vécu cette expérience plusieurs fois dans ma arrière et je pense que les années passées à travailler sur les sujets concernés ont été les plus "confortables" de ma vie professionnelle : un besoin, un buget et toute latitude sur les choix de conception.
J'ai également trouvé beaucoup de plaisir à travailler sur des projets déjà bien établis : j'ai participé à de très beaux projets qui avaient déjà plus de 10 ou 15 ans d'existance. Même en partant d'un existant, dès l'instant que la confiance est établie, on trouve facilement matière à s'épanouir. Faire évoluer, améliorer, optimiser : tout cela constitue également une activité de création. Et parfois un défi.
J'exclue en revanche des "situations confortables" les situations de pages blanches (et de page blanches uniquement) où malgré votre rôle de concepteur désigné vous n'avez plus la main sur les choix techniques. J'ai malheureusement déjà vécu cette situation également (heureusement une seule fois, et pas longtemps).
Sur ce dernier poinr, pour citer Steve Jobs : "Cela n'a aucun sens d'embaucher des gens intelligents et de leur dire quoi faire; Nous embauchons des gens intelligents pour qu'ils puissent nous dire quoi faire".
La dette technique et documentaire
Ecrire un logiciel, c'est déjà créer de la dette technique.
J'ai souvent entendu cette phrase et je pense que c'est souvent vrai : les logiciels sont créés à un instant donné autour de concepts, de technologies, de frameworks, de langages, de capacités de calcul du moment. Cela n'a pas vraiment d'incidence lorsque les logiciels sont conçus pour une durée de vie de 3 à 5 ans mais au delà de cette durée des précautions sont nécessaires pour maintenir l'évolutivité et surtout la maintenabilité du logiciel (car oui, écrire du code c'est aussi écrire des bugs).
Peut-on maitriser et résorber la dette technique sans avoir d'abord maitriser la dette documentaire ? Personnellement je ne pense pas. Les documents de spécification fonctionnelle, comme les documents de conception, permette de préserver le lien entre le besoin fonctionnel et la solution technique. Lorsque ce lien est laissé à la dérive, où même perdu, l'effort de de maintenabilité ou d'évolution est considérablement augmenté, et dans des proportions non prédictibles.
Pour reproduire les couleurs des murs de la villa, les architectes en rénovation ont du avoir recours à des "sondages" dans les murs afin de retrouver les tons d'origine. Les seuls éléments "documentaires" dont ils disposaient étaient en effet des photos d'époque ... en noir et blanc.
Ce procédé de sondage peut-être facilement comparé aux phases de rétro-conception qui sont nécessaires à la compréhension d'un logiciel dont la documentation de conception a été laissée à la dérive ... Ces activités sont souvent peu gratifiantes, longues, fastidieuses et donc très coûteuses.
L'architecte Robert Mallet-Stevens avait par ailleurs exprimé le souhait, dans son testament, de voir toutes ses archives détruites. Je n'irai pas remettre en cause l'intégrité morale de cet architecte, mais cela m'a toutefois rappelé quelques cas (toujours rencontrés dans ma carrière) d'omission plus ou moins volontaire de documentation. Le plus souvent ces omissions sont liées soit à la "sensation d'évidence" (le concepteur d'origine surestimait la limpidité de sa solution), soit au "manque de temps" (qui se paie cher sur le long terme). Plus rarement l'omission de documentation peut être le symptôme d'un phénomène bien plus toxique : la "sécurisation du poste de travail". Et ce phénomène, malheureusement, j'y ai été également confronté dans ma carrière (une seule fois).
D'autre cas d'omission documentaire peuvent également émerger à l'occasion d'une fausse bonne idée : dans une grande entreprise où je suis passé, qui disposait pourtant d'un sérieux référentiel qualité (avec templates documentaires, guides de rédaction etc ...), la mode des Wikis avait malheureusement atteint les concepteurs logiciels les plus juniors : les dossiers de conception rédigés sous forme de Wikis collaboritifs sont alors apparus. Ce choix pouvait paraitre plus "agile" mais c'était oublier que la structure d'un logiciel peut s'enrichir ou évoluer de version en version, alors que les Wikis ainsi créés, de par leur nature volatile, ne permettaient pas de tracer les choix antérieurs à la dernière version du logiciel.
La perte des compétences
Les briques jaunes utilisées lors de la construction de la villa en 1930 étaient une commande spéciale. Et après près d'un siècle, il a fallu trouver les bonnes personnes pour (re)faire les bons produits : pas simple.
C'est un peu comme à la fin des années 1990, lorsque j'ai débuté, et que je voyais passer certaines offres d'emploi associées à des salaires mirobolants : les experts COBOL étaient chassés comme des poules aux oeufs d'or. Mais qui voulait encore développer du COBOL en sortie d'école dans les années 90 ? Je pense que certains développeurs seniors grassement payés ont du se faire une petite fortune dans ces années là ...
J'ai l'impression qu'aujourd'hui le phénomène se reproduit pour les développements aéronautiques au long cours en ADA, parfois initiés il y a plus de 30 ans : à moins qu'une stratégie de migration vers des langages plus en vogues comme le C++ ou plus imuables comme le C, les recrutements ne doivent pas être faciles ...
Le savoir-faire est précieux. Le savoir-faire d'une entreprise se construit également en gardant les personnes. Et pourtant j'ai déjà entendu des responsables de département se gargariser d'avoir des taux de turn-over de "seulement 15%" (pour le secteur d'expertise concerné c'était pourtant énorme).
La perte des ressources
L'une des difficultés majeures concernant la rénovation de la villa depuis plusieurs années concerne la récupération, le rachat, de beaucoup d'éléments de mobilier volés, vendus ou donnés au fil des décennies.
Les difficultés sont du même ordre lorsqu'il s'agit de retrouver des cartes électroniques d'une époque révolue, de recompiler des librairies historiques proches du système de l'époque, de tirer l'ensemble des dépendances d'un applicatif de haut niveau écrit dans les années 80 ... Et les solutions sont les mêmes : on retrouve, on achète les services de gens pour retrouver, on refait ...
Et donc?
Et donc comment éviter toutes ces difficultés finalement communes au monde du logiciel et à celui du "design immobilier moderniste" ?
Dans les deux cas l'important semble être de prendre soin des choses et des gens :
- ne jamais laisser dépérir les projets dans lesquels on croit : documenter le besoin, la solution ET le lien entre les deux
- ne jamais insulter l'avenir et envisager les choses sur le long terme : préserver les moyens de production et le savoir faire
- toujours laisser la porte ouverte (le plus largement possible) aux évolutions futures : d'expérience cela ne représente presque jamais de surcoût et permet bien des économies sur le long terme.