Principes pour des systèmes maîtrisables
Comment l’ouverture, la réparabilité, la documentation et des dépendances claires favorisent une informatique robuste.
Une informatique robuste n’est pas celle qui comporte le plus de produits. C’est celle dont la finalité, les dépendances et les chemins de reprise sont compris. La technologie peut être exigeante, mais son exploitation ne devrait pas dépendre du hasard, de la mémoire d’une seule personne ou d’interfaces opaques.
Partir de la fonction
Avant de choisir des composants, il faut préciser la fonction à préserver. Qui a besoin de quelle information ? Quel temps de réponse est nécessaire ? Qu’est-ce qui peut être temporairement indisponible, et qu’est-ce qui ne le peut pas ? Ces questions offrent un cadre durable aux décisions d’architecture.
Considérer la chaîne d’information
Les applications fonctionnent rarement seules. Terminaux, identités, réseaux, résolution de noms, sources de temps, stockage, sauvegardes et voies de communication forment une chaîne. Un problème dans un maillon discret peut interrompre une fonction métier visible.
Utiliser l’ouverture à bon escient
L’open source et les standards ouverts sont des outils, pas une décoration. Ils sont utiles lorsqu’ils améliorent la remplaçabilité, l’auditabilité, la maintenabilité ou la transmission des connaissances. Un composant ouvert sans responsabilité ni savoir d’exploitation ne résout aucun problème.
L’indépendance vis-à-vis des fournisseurs ne signifie pas les éviter tous. Elle consiste à aligner les décisions sur la mission et à rendre visibles les dépendances évitables.
Prévoir la réparabilité
La réparabilité commence avant la panne. Des chemins alternatifs, des sauvegardes de configuration, des changements traçables et une documentation accessible doivent exister avant l’incident. Un système n’est pas robuste lorsque sa reprise ne réside que dans la mémoire d’une personne.
Rendre les dépendances visibles
Chaque dépendance peut être justifiée. Elle devient problématique lorsqu’elle est inconnue, inutile ou hors de toute influence. Cela vaut pour les dépendances techniques comme pour les contrats, les comptes, les personnes clés et les services externes.
Une vue utile répond au minimum à ces questions :
- Quelle fonction en dépend ?
- Qui en est responsable ?
- Comment cette dépendance est-elle surveillée ?
- Quelle alternative ou quel mode d’urgence existe ?
- Comment l’état peut-il être restauré ?
Traiter la documentation comme un outil d’exploitation
La documentation n’est pas une photographie de fin de projet. C’est un outil d’exploitation qui doit répondre aux questions posées lors des changements, des transmissions et des incidents. Les décisions méritent autant d’attention que les configurations.
Rendre le savoir transmissible
Un système maîtrisable ne doit pas dépendre durablement d’un savoir individuel. Des sessions de transmission, des parcours partagés et une terminologie claire rendent les connaissances plus résilientes.
Penser ensemble sécurité et protection des données
La sécurité ne découle pas d’un contrôle unique. Identités, autorisations, frontières réseau, mises à jour, sauvegardes, journalisation et reprise fonctionnent ensemble. La protection des données exige en outre de comprendre les flux de données, leurs finalités et leurs destinataires externes.
Choisir consciemment la simplicité
Chaque composant supplémentaire augmente le travail d’exploitation, de mise à jour et de documentation. La solution viable la plus simple est souvent la plus robuste : assez claire pour être exploitée, assez ouverte pour évoluer et assez complète pour être rétablie.