Architecture cyber

Architecture cyber

Une architecture ne s’effondre presque jamais d’un coup. Elle se dégrade décision après décision, et chacune, prise isolément, semble raisonnable : un raccourci pour tenir le sprint, une dépendance ajoutée parce que personne n’a le temps de la challenger, une bascule planifiée un vendredi parce que ça libère le lundi. Rien de tout ça ne déclenche d’alerte. C’est justement le problème. Le jour où ça casse, personne ne pointe la vraie décision fautive : elle date de huit mois, et depuis, tout le monde a oublié qu’elle existait.

Le sujet, ici, ce n’est pas la liste des bonnes pratiques qu’on connaît déjà et qu’on n’applique jamais faute de temps. C’est la mécanique : pourquoi la segmentation dessinée sur un schéma ne survit jamais à la première demande d’exception, pourquoi la confiance accordée entre deux composants finit toujours plus large que prévu, et pourquoi un système qu’on n’observe pas se défend en réalité à l’aveugle : on croit juste le contraire, parce que rien ne clignote.

La résilience suit la même logique : un système qui ne sait pas dégrader proprement ne « tient » pas plus longtemps, il casse juste d’un coup plutôt qu’en plusieurs fois, et personne n’a le temps de réagir entre les deux. Défendre un système par sa surface d’attaque, l’observer avant l’incident plutôt qu’en découvrir les traces après, construire quelque chose qui tient, dégrade puis redémarre : c’est le même réflexe appliqué trois fois, pas trois compétences séparées.

Le reste (événementiel, monolithe contre microservices, la manière dont le code est organisé) n’est pas hors sujet : c’est la même question posée plus tôt dans le cycle, avant que l’architecture ne devienne l’excuse qu’on invoque pour ne plus la remettre en cause.