Il y a une vérité plate dans mon métier: tant que l’argent coule, personne ne veut entendre parler d’architecture. C’est vu comme du luxe, du « on verra plus tard », de la théorie de gars qui dessine des boîtes. Mais le jour où le budget serre, là, tout d’un coup, l’architecture devient le sujet de l’heure. Parce que c’est elle qui décide si on peut couper proprement ou si tout est tellement collé ensemble qu’on ne peut rien toucher sans casser autre chose. En février 2008, avec l’ambiance économique qu’on a, je vis ça de proche dans mes mandats.

Comme architecte, mon vrai travail dans une période serrée, c’est de rendre les coûts visibles dans la structure même du système. Un système bien découpé, c’est un système où tu peux dire « on coupe ce module-là, ça touche juste ces deux affaires ». Un système mal découpé, c’est une boule de spaghetti où chaque coupure est une roulette russe. La différence ne se voit pas quand tout roule. Elle se voit le jour où on doit faire des choix.

flowchart LR
    subgraph Couple[Tout colle ensemble]
    A1[Module A] --- B1[Module B]
    B1 --- C1[Module C]
    A1 --- C1
    end
    subgraph Decouple[Bien decoupe]
    A2[Module A] --> I[Interface]
    B2[Module B] --> I
    C2[Module C] --> I
    end

Le terrain m’a appris que les meilleures décisions d’architecture en temps de crise ne sont pas les plus brillantes — ce sont les plus réversibles. Quand on n’a pas d’argent pour se tromper deux fois, on cherche les choix qu’on peut défaire sans tout reconstruire. Une frontière claire entre deux composants vaut mille lignes de documentation. Un contrat d’interface stable permet de remplacer ce qu’il y a derrière sans avertir toute la planète.

Concrètement, je regarde les couplages. Où est-ce que deux systèmes se parlent direct dans la base de données de l’autre? Où est-ce qu’un changement ici oblige un déploiement là-bas? Chaque dépendance cachée, c’est une facture qu’on ne voit pas encore. Et en période serrée, ces factures-là sortent au pire moment.

// Le piege: le module B fouille direct dans les tables de A
var cmd = new SqlCommand(
    "SELECT statut FROM moduleA_commandes WHERE id = @id", conn);

// Mieux: B passe par un contrat que A expose et controle
public interface ICommandeService {
    StatutCommande ObtenirStatut(int commandeId);
}
// A peut changer sa base sans casser B, tant que le contrat tient.

Le piège que je vois le plus souvent, c’est de confondre « économiser » pis « ne pas investir dans la structure ». Sauter l’étape de découpage parce que ça prend du temps, c’est emprunter à un taux d’intérêt brutal. Ça va vite au début, pis ça coûte une fortune à chaque changement suivant. L’architecture, ce n’est pas une dépense de plus — c’est ce qui rend les futures dépenses prévisibles.

Ce que je retiens, c’est qu’une bonne architecture est une assurance contre les surprises. On ne la remarque pas quand tout va bien. Mais le jour où il faut couper, migrer, consolider ou réagir vite, c’est elle qui décide si l’équipe peut bouger ou si elle est prise. En période où chaque décision compte, ça vaut de l’or.

Ma note de terrain pour février 2008 reste simple: documenter les frontières, pas les détails. Une page qui dit « voici les gros morceaux, voici qui parle à qui, voici ce qu’on peut couper sans danger » vaut plus qu’un gros document que personne ne lit. Quand quelqu’un arrive dans le dossier sous pression, c’est ça qui le sauve.

La suite, je la garde modeste: clarifier les frontières, casser les couplages les plus dangereux, pis rendre chaque dépendance visible. C’est moins spectaculaire qu’une grande refonte, mais c’est exactement ce qui permet à une équipe de traverser une année difficile sans se peinturer dans le coin. L’architecture, quand l’argent manque, arrête d’être de la théorie. Elle devient le terrain.