Revues légères et risk-storming

Pourquoi les comités de revue lourds échouent souvent

De nombreuses organisations gouvernent l’architecture au moyen d’un comité de revue d’architecture : un groupe d’architectes seniors qui se réunit chaque mois, reçoit une présentation ou un long document, et approuve ou rejette des conceptions. L’intention est bonne : un regard indépendant et expérimenté sur les décisions importantes. Les résultats sont souvent médiocres, pour des raisons structurelles plutôt que personnelles.

Le calendrier est le premier problème. Un comité qui se réunit à des étapes fixes voit une conception soit trop tôt (rien n’est encore décidé), soit, bien plus souvent, trop tard, quand l’équipe a déjà construit un prototype, s’est engagée auprès d’un fournisseur et a promis une date. Un rejet coûte alors si cher que le comité approuve avec des conditions que personne ne suit. Le contexte est le deuxième : des relecteurs qui passent une heure sur un système qu’ils n’ont jamais vu posent des questions génériques et manquent les risques précis que les développeurs, les équipes d’exploitation et les ingénieurs sécurité de l’équipe pourraient citer en quelques minutes. Les incitations sont le troisième : quand une revue est un examen, les équipes présentent la conception qu’elles veulent faire approuver, pas les doutes qu’elles ont, et le comité apprend peu. L’attente est le quatrième : une réunion mensuelle à l’ordre du jour chargé ajoute des semaines d’attente à chaque décision importante, ce qui pousse les équipes à éviter le comité en qualifiant leurs décisions de mineures.

Rien de tout cela ne signifie qu’une revue indépendante est inutile. Les secteurs réglementés (banque, santé, aviation) exigent souvent une validation documentée, et certaines décisions ont réellement besoin de l’autorité d’un groupe de haut niveau. La leçon est que la revue doit être fréquente, précoce, collaborative et centrée sur les risques, l’approbation formelle étant réservée aux rares décisions qui l’exigent vraiment. La section 11.4 revient sur la façon dont la gouvernance peut fonctionner sans points de validation lents.

Ce qu’apporte une bonne revue légère

Une revue légère est une séance courte et structurée, en général d’une heure ou deux, pendant laquelle les personnes qui connaissent le mieux une conception et quelques personnes qui la découvrent cherchent ensemble les risques. Elle vise quatre choses : découvrir les risques tant qu’ils coûtent peu à traiter, construire une compréhension partagée de la conception dans l’équipe, offrir une remise en question indépendante des hypothèses de l’architecte, et laisser une trace des risques acceptés, atténués ou écartés. Son résultat est une liste de risques priorisée avec des responsables, pas un verdict.

Plusieurs techniques correspondent à cette description. Elles diffèrent par ce qu’elles examinent (un diagramme, un plan, un document ou un système en fonctionnement) et par ce qu’elles font le mieux, et elles se combinent bien.

Risk-storming

Le risk-storming est une technique visuelle et collaborative créée par Simon Brown, l’auteur du modèle C4 (section 4.3). Il repose sur une observation simple : des personnes différentes voient des risques différents, et le meilleur moyen de les recueillir est de placer tout le monde devant les mêmes diagrammes et de demander à chacun de les examiner seul avant d’en discuter. Il comporte quatre étapes.

1. Dessiner l’architecture. Affichez des diagrammes de ce que vous prévoyez de construire ou de modifier, idéalement à plus d’un niveau : un diagramme de contexte système et un diagramme de conteneurs suffisent en général, avec un diagramme de composants pour le conteneur le plus risqué. 2. Identifier les risques individuellement. Chaque participant écrit en silence un risque par note adhésive, avec une courte description et une priorité, pendant une dizaine de minutes. Le silence compte : il empêche la première personne qui parle, ou la plus haut placée, d’ancrer tous les autres, ce qui est la principale façon dont les discussions de groupe perdent de l’information. 3. Rassembler les risques sur les diagrammes. Chacun place ses notes sur la partie du diagramme que le risque concerne. Des grappes apparaissent immédiatement, et le diagramme devient une carte de chaleur. 4. Examiner et résumer. Le groupe discute des grappes, puis accorde une attention particulière à deux types de notes : les risques soulevés par une seule personne (souvent quelqu’un qui possède un savoir que les autres n’ont pas, comme l’ingénieur du support) et les risques auxquels différentes personnes ont donné des priorités très différentes (signe d’un malentendu). Les risques retenus entrent dans un registre des risques avec des responsables ; les éléments dont on a convenu qu’ils ne sont pas des risques sont consignés aussi.

La priorité se note en général comme la probabilité multipliée par l’impact, chacun étant coté faible (1), moyen (2) ou élevé (3), ce qui donne des scores de 1 à 9. Les recommandations de Brown les répartissent en élevé (6 ou 9), moyen (3 ou 4) et faible (1 ou 2), représentés par convention avec des notes roses ou rouges, jaunes ou orangées, et vertes. Une liste de rappel aide chacun à penser au-delà de sa propre spécialité : scalabilité, disponibilité, performances, sécurité, cohérence des données, dépendances envers des tiers, coût, maturité des technologies, compétences de l’équipe, et livraison et exploitation.

Les pre-mortems

Le risk-storming examine une structure. Un pre-mortem examine un plan. Gary Klein l’a décrit dans la Harvard Business Review en septembre 2007. Une autopsie (post-mortem) explique pourquoi un patient est mort, ce qui aide tout le monde sauf le patient ; un pre-mortem a lieu avant le début du projet, quand les réponses peuvent encore en changer le cours.

La procédure est courte. L’animateur présente au groupe le plan ou la décision, puis annonce que l’on se trouve quelques mois plus tard et que le projet a échoué, gravement. Chaque personne passe quelques minutes à écrire, seule, toutes les raisons de l’échec qui lui viennent à l’esprit. L’animateur fait ensuite le tour de la salle en recueillant une raison à la fois jusqu’à épuisement des listes, et le responsable du plan les examine pour trouver des moyens de le renforcer. Klein cite des travaux de Deborah Mitchell, Jay Russo et Nancy Pennington (1989) montrant qu’imaginer qu’un événement s’est déjà produit (le recul prospectif) augmente d’environ 30 % la capacité des personnes à trouver les raisons de résultats futurs. Ce cadrage change aussi la dynamique sociale : la question n’est plus de savoir si le plan pourrait échouer, ce qui paraît déloyal, mais pourquoi il a échoué, ce qui invite à la créativité.

En architecture, les pre-mortems sont particulièrement utiles avant les gros engagements : adopter un style piloté par les événements, migrer vers un nouveau cloud, remplacer un système hérité (section 11.6) ou introduire une plateforme. Parmi les résultats typiques qu’une revue fondée sur les diagrammes manquerait : l’équipe qui manque de compétences dans la nouvelle technologie, la migration qui s’enlise à mi-chemin avec deux systèmes à exploiter, un fournisseur clé qui change ses tarifs, et le métier qui perd patience avant que les bénéfices apparaissent.

Les katas d’architecture

Les katas d’architecture ont été créés par Ted Neward, en s’inspirant des katas de code de Dave Thomas, comme exercices d’entraînement pour les architectes. Un kata est un court énoncé décrivant un système fictif (quelques paragraphes d’exigences, d’utilisateurs et de contraintes, volontairement incomplets). De petites équipes de trois à cinq personnes y travaillent pendant un temps fixé, en interrogeant un modérateur qui joue le client pour découvrir les exigences manquantes, puis esquissent une architecture et la présentent aux autres équipes, qui la contestent durement mais loyalement avant que la salle ne vote. Neal Ford tient à jour une collection publique de katas, et O’Reilly a organisé des compétitions de katas d’architecture.

Les katas ne sont pas des revues d’une conception réelle, mais ils contribuent à la culture de la revue de deux façons. Ils développent la capacité à expliquer et à défendre une conception face aux questions, et à poser de bonnes questions sur celle de quelqu’un d’autre, ce dont les revues légères ont justement besoin. Et un kata interne sur un vrai problème à venir, avec deux ou trois équipes qui conçoivent chacune de leur côté, est un moyen peu coûteux d’explorer l’espace des options avant de s’engager : quand trois équipes produisent trois conceptions différentes, les différences montrent où se trouvent les vrais compromis.

TARA et revues fondées sur des listes de contrôle

Les revues de systèmes qui existent déjà font face à un autre problème : l’architecture telle que construite peut différer de l’architecture telle que décrite, et les éléments de preuve sont dispersés entre les personnes, les documents, le code et les données de production. Eoin Woods, coauteur de Software Systems Architecture, a décrit en 2011 la Tiny Architectural Review Approach (TARA) comme une alternative industrielle, volontairement légère, aux méthodes très centrées sur les scénarios. Un petit nombre de relecteurs recueillent les exigences clés et le contexte du système, établissent sa structure réelle, évaluent sa mise en œuvre à l’aide d’une analyse automatisée (dépendances entre modules, taille, métriques de code, couverture de tests) ainsi que d’informations d’exécution comme les journaux, s’appuient sur leur jugement d’experts pour relier ce qu’ils trouvent aux exigences, et présentent leurs constats et recommandations sous une forme prédéfinie. Sa force est la rapidité et les preuves ; sa faiblesse, que Woods a reconnue, est sa dépendance à l’expertise des relecteurs.

Les listes de contrôle complètent toutes les techniques. Une liste de contrôle ne trouve pas de risques par elle-même, mais elle évite qu’une revue oublie toute une catégorie (restauration des sauvegardes, secrets, coût à grande échelle) simplement parce que personne dans la salle n’y a pensé. Gardez des listes de contrôle courtes, propres à l’historique d’incidents de votre organisation, et formulées sous forme de questions qui exigent des éléments de preuve plutôt qu’un oui ou un non.

Documents de conception et revues de RFC

La section 4.8 a présenté les documents de conception et les RFC comme un moyen de proposer un changement par écrit avant de le construire. Bien les relire est une compétence à part entière. Une revue écrite présente de réels avantages sur une réunion : les relecteurs commentent quand ils ont le temps de réfléchir, les collègues à distance ou plus discrets contribuent à égalité, et les commentaires constituent une trace. Ses échecs typiques sont des documents que personne ne lit, des fils de commentaires qui ne se referment jamais et des revues qui deviennent un point de validation officieux.

La bonne pratique consiste à indiquer en tête la décision recherchée et la date limite des commentaires, à nommer les relecteurs dont l’avis est requis (sécurité, exploitation, responsables des services concernés) et à inviter toute autre personne ; à demander aux relecteurs d’étiqueter chaque commentaire comme question, suggestion ou objection bloquante, pour que l’auteur sache lesquels doivent être résolus ; à relire au regard des scénarios de qualité et de la liste de contrôle ci-dessous, et non des goûts personnels ; à conclure par une courte réunion uniquement pour les objections non résolues ; et à consigner les décisions importantes sous forme d’ADR. Dans les organisations qui utilisent le processus de consultation (section 11.4), la RFC est le moyen de solliciter des conseils, et la décision reste à son auteur.