Après quelques années à coder sur des mandats, j’ai compris une affaire que personne te dit à l’école: le vrai monstre, c’est pas la performance, c’est pas le matériel, c’est la complexité. Un système qui grossit trop vite devient un nœud de dépendances cachées où plus personne comprend l’ensemble. Pis ça, ça coûte cher.

Le piège est sournois. Chaque petite fonction qu’on ajoute semble innocente. Mais elle se branche sur trois autres modules, qui se branchent sur cinq autres. Au bout d’un an, changer une ligne dans un coin fait planter quelque chose à l’autre bout, pis personne sait pourquoi.

Comment le monstre grandit

flowchart TD
    A[Petite fonction ajoutée] --> M1[Module commandes]
    A --> M2[Module clients]
    A --> M3[Module facturation]
    M1 --> X[Dépendances cachées]
    M2 --> X
    M3 --> X
    X --> Q{Je touche<br/>une ligne?}
    Q -->|Et si ça casse<br/>ailleurs?| P[Peur de tout briser]
    Q -->|Aucun test<br/>pour me rassurer| P
    P --> F[On n'ose plus toucher<br/>= la dette gèle le code]

C’est ça, le vrai coût. Pas le temps de calcul, mais la peur de toucher au système. Quand une équipe arrête d’oser modifier le code parce que personne comprend les effets de bord, le projet est déjà malade. La complexité, c’est une dette qu’on paye en lenteur pis en bugs, longtemps après l’avoir contractée.

Ce que j’essaie de faire

Comme développeur, ma défense contre le monstre, c’est la simplicité acharnée. Découper en morceaux qui ont une seule responsabilité claire. Réduire les dépendances entre les parties. Nommer les choses pour qu’un nouveau comprenne sans toute l’histoire. C’est moins glamour qu’une grosse fonctionnalité, mais ça garde le système vivant.

Ce que j’en retiens

Le vrai monstre, c’était la complexité — pis je le réalise un peu plus à chaque mandat. La performance, on finit par la régler avec du meilleur matériel. La complexité, elle, se règle juste avec de la discipline pis du courage de simplifier. C’est le combat le plus important du métier, pis le moins reconnu.