On parle souvent de Single Point of Failure comme d’un problème d’architecture.
Un serveur unique. Une base de données mal répliquée. Un composant critique sans redondance.

C’est une lecture utile, mais incomplète.

Avec le recul, les SPOF les plus dangereux que j’ai observés ne sont pas techniques. Ils sont organisationnels.

Un SPOF peut être une personne qui détient seule une connaissance clé.
Une décision structurante qui n’a jamais été formalisée.
Un arbitrage implicite que plus personne n’ose remettre en question.
Un fournisseur devenu critique sans que cela ait été réellement assumé comme tel.

Ces SPOF-là ne déclenchent aucune alerte.
Ils ne remontent pas dans les outils de supervision.
Ils ne figurent dans aucun diagramme d’architecture.

Et pourtant, ce sont souvent eux qui font le plus de dégâts lorsqu’un incident survient.

Dans ces situations, la panne technique n’est qu’un déclencheur. La vraie rupture apparaît lorsque l’organisation découvre qu’elle ne sait plus qui décide, qui arbitre, ou qui est légitime pour agir. Le système ne tombe pas parce qu’un composant est défaillant, mais parce que la capacité de décision n’est pas distribuée.

C’est là que le rôle du DSI et du RSSI dépasse largement la technique. Identifier un SPOF organisationnel demande du discernement, parfois du courage. Cela suppose de poser des questions inconfortables :
Que se passe-t-il si cette personne n’est pas disponible ?
Cette décision est-elle comprise ou seulement appliquée ?
Sommes-nous capables d’expliquer pourquoi ce choix a été fait ?

Éliminer un SPOF technique est souvent une question d’investissement.
Réduire un SPOF organisationnel est presque toujours une question de gouvernance.

Et c’est sans doute pour cela qu’ils sont plus difficiles à traiter.

À retenir
Un système résilient n’est pas seulement redondant techniquement.
Il est capable de décider, même lorsque les repères habituels disparaissent.