Si au niveau atomique le temps et les durées nous sont incompréhensibles [1], plus nous remontons les couches et plus le temps devient palpable, jusqu'à s'étioler à nouveau vers l'infini. Il reste, certes, peut-être difficile d'appréhender l'infime fraction de seconde que nécessite une opération au niveau du CPU. Les secondes qui passent à afficher une page nous paraissent, elles, bien plus concrètes. De là, le temps de travail des développeurs et développeuses qui s'organise en itérations de quelques semaines [2] retrouve une échelle humaine, tout comme la liste des fonctionnalités prévues pour les quelques prochains mois. Parfois, le tout est planifié sur un trimestre, voire sur un semestre et parfois, en année — bien que personne n'y croit vraiment.
Ce passage de l'électronique à l'écrit, et de l'écrit au monde des idées produit un étirement du temps, à tel point qu'au plus haut niveau d'abstraction nous parlons en années, voire plus loin encore [3]. C'est là que se trouve le temps de l'architecture logicielle.
Si le court terme du développement se compte en jours, celui de l'architecture se compte en mois. Le moyen terme passe alors de quelques mois aux semestres, et le long terme [4] de l'ingénierie logicielle se transforme en plan de deux, trois, voire même cinq ans et plus pour l'architecture.
Non seulement le temps d'architecture s'étire au-delà des habitudes, il débute aussi bien avant le développement, puis continue en se transformant pendant ce dernier : s'il faut préparer l'avenir, il faut ensuite suivre et ajuster. Pour cela, l'architecture doit s'adapter sans que jamais ses principes et ses fondamentaux ne succombent aux nouveautés.
Tout cela pose de nombreuses difficultés aux ingénieur·e·s, puisqu'un temps qui s'étire, c'est aussi une boucle de feedback qui s'allonge : le moindre ajustement au réel, la moindre correction, le moindre changement de besoins nécessitent d'autant plus de ressources, de temps et d'énergie à mesure que l'âge de l'architecture augmente. Pour cela, le savoir et l'expérience sont cruciaux pour s'offrir, en amont même du développement, des options et des garde-fous.
Toute technique pour réduire la boucle de feedback est bonne à prendre, que ce soit par du prototypage, ou une définition claire du périmètre minimal requis. Cette quête est celle des réponses aux questions posées par l'architecture, et la recherche de preuves permettant de confirmer les hypothèses qui seront retenues. Tout cela a pour but qu'au lieu de remettre en cause l'architecture, le changement y trouve sa place naturelle, comme s'il avait toujours été prévu, comme si cet inconnu là était déjà connu d'avance !
C'est aussi un changement de perception du temps qui s'accompagne d'une bonne dose de gestion de la frustration : les choses ne se feront jamais aussi vite que nous le voudrions — l'architecture se rie des impatients. La dispersion des efforts est une menace constante, qui demande de la discipline et de la rigueur. Lorsqu'une urgence se présente, lorsque l'imprévu débarque, il faut savoir tenir bon, et savoir retrouver son chemin aux premiers signes d'une accalmie. Le temps d'architecture ne peut tolérer l'urgence permanente, sinon ce ne serait plus l'heure de l'architecture, ce serait celui du naufrage !
Si l'architecture logicielle est l'affaire de toutes et tous les ingénieur·e·s, vivre dans cette étrange dimension au temps distendu est le quotidien des architectes. Ces dernier·ière·s doivent d'ailleurs apprendre à traverser, dans un sens ou dans l'autre, le voile qui sépare le temps d'architecture du temps du développement. Cela rejoint, de façon très similaire, la nécessité qui s'impose à elleux de rapprocher le monde des idées du monde du logiciel — et vice-versa.