Si je dois résumer mon année avec un mot techno, ce sera probablement le moins vendeur : responsabilité. Mon passage vers un rôle d’architecte-développeur ne m’éloigne pas du code; il m’oblige plutôt à suivre ce qui arrive avant et après son exécution.

Trois chaînes vues cette année montrent bien le changement :

document -> SharePoint -> SQL Server -> sauvegarde -> restauration
VM       -> hyperviseur -> hôte       -> panne       -> redémarrage
message  -> SMTP        -> filtre     -> quarantaine -> correction

Chaque ligne possède une interface visible et plusieurs états cachés. Un document paraît simplement « dans le portail », mais il dépend d’une identité, d’une base de contenu et d’une procédure de restauration. Une VM paraît indépendante, mais partage ses disques et son hôte avec d’autres services. Une boîte propre paraît protégée, même si un vrai message attend dans la quarantaine.

Dessiner aussi les pannes

Je commence à trouver les diagrammes plus utiles lorsqu’ils montrent les files, les propriétaires et les chemins de reprise plutôt que seulement des boîtes de produits. Pour un site SharePoint, je veux savoir quelle base contient le contenu et qui approuve sa fermeture. Pour une VM, je veux connaître l’hôte de rechange et l’ordre de démarrage. Pour un filtre, je veux voir qui révise les faux positifs.

Une petite fiche commune pourrait suffire :

Service       : Espace projet Atlas
Propriétaire  : équipe Projets
Dépendances   : annuaire, IIS, SQL Server, stockage
État critique : documents approuvés et permissions
Reprise       : restaurer la base, rattacher, vérifier un document
Testé le      : 2006-11-15

Ce n’est pas de la documentation pour décorer une étagère. Lorsqu’une personne quitte ou qu’un serveur tombe, la fiche indique où commencer. Si une dépendance n’a aucun propriétaire, le trou devient visible avant l’incident.

Je lui ajouterais deux mesures observables plutôt qu’une longue description. Pour le portail, le temps d’ouverture d’un document et la date du dernier backup restauré. Pour l’hôte virtuel, la mémoire disponible après la perte d’un nœud et le temps de redémarrage des services prioritaires. Après un incident ou un exercice, on corrige la fiche avec ce qui est réellement arrivé. Elle devient ainsi une petite boucle d’apprentissage, pas une photo oubliée de l’architecture.

Le Web participatif ajoute le même besoin à une autre échelle. Le navigateur envoie maintenant du contenu à la plateforme. Il faut le valider, l’attribuer, le modérer et le garder dans un stockage qui peut grossir sans prévenir. Le bouton Publier transforme le visiteur en source de données; il transforme aussi l’exploitant en gardien d’un contenu qu’il n’a pas produit.

Dans le salon, Sony et Nintendo montrent une autre sorte d’architecture. La PlayStation 3 consacre sa complexité au calcul parallèle et à la haute définition. La Wii accepte moins de puissance pour mettre des capteurs et une nouvelle boucle d’interaction dans la main. Une spécification technique ne vaut donc qu’en fonction du problème choisi.

Pour mes projets, je garderais trois habitudes de 2006 : nommer le propriétaire en même temps que le système, mesurer la capacité partagée dans un scénario de panne et tester le retour avant d’en avoir besoin. Ça ne garantit pas une année tranquille. Ça évite au moins que le premier exercice de reprise ait lieu le jour où tout le monde attend déjà.