Impact Radar : Comprendre un changement avant de le faire

Il y a quelques semaines, une équipe plateforme avec laquelle je travaille a décidé de déprécier un service d'authentification interne. Ça semblait simple — le service avait deux consommateurs connus. Ils ont mis à jour le diagramme, notifié les équipes concernées, et commencé à planifier la migration.

Trois sprints plus tard, ils ont découvert quatre autres services qui en dépendaient. Deux étaient dans des projets différents. Un faisait partie d'un flux legacy que personne n'avait cartographié. Le calendrier de migration a doublé.

L'information était là. Elle se trouvait dans les relations, dans la hiérarchie C4, dans les diagrammes de flux. Mais personne ne pouvait voir le tableau complet d'un seul coup. Il fallait tracer chaque connexion manuellement, à travers les niveaux, à travers les projets, en espérant ne manquer aucun chemin.

C'est le problème que résout Impact Radar.

Clic droit, tout voir

Impact Radar vit là où vous travaillez déjà — sur le diagramme. Faites un clic droit sur n'importe quel élément de votre modèle C4 — un système, conteneur, composant ou élément de code — et sélectionnez Analyser l'impact. L'analyse s'exécute instantanément.

Le diagramme se transforme. Chaque élément en dehors de la zone d'impact s'estompe. Les éléments affectés restent vifs, et les relations entre eux s'illuminent, colorées selon la proximité :

• Rouge — directement connecté (degré 1)
• Ambre — à un saut (degré 2)
• Jaune — à deux sauts (degré 3)

Les arêtes s'animent pour montrer la direction du flux de dépendances. Vous voyez le rayon d'impact d'un changement en un coup d'œil.

Le panneau d'impact

Un panneau glisse depuis la droite avec l'analyse complète. Pas de page séparée, pas de changement de contexte — vous êtes toujours sur votre diagramme, toujours dans votre projet.

En haut, un seul chiffre : "Impacte X% de votre architecture." C'est le pourcentage des éléments de votre projet qui se trouvent dans la zone d'impact. C'est un indicateur instinctif. Si vous cliquez droit sur un composant utilitaire et voyez 2%, vous êtes probablement tranquille. Si vous cliquez droit sur une API gateway centrale et voyez 38%, vous savez que ce changement mérite une discussion.

Score de risque

Sous le pourcentage se trouve la Jauge de risque — un score de 0 à 100 calculé à partir de quatre facteurs pondérés :

• Dépendants en amont (30%) — Combien d'éléments dépendent de celui-ci ? Plus il y a de consommateurs, plus le rayon d'impact est large.
• Portée en aval (25%) — De combien de dépendances cet élément dépend-il ? Les changements ici pourraient nécessiter la mise à jour de ces dépendances.
• Enfants structurels (25%) — Pour les conteneurs et systèmes, combien d'éléments enfants vivent à l'intérieur ? Modifier ou supprimer un conteneur signifie gérer chaque composant qu'il contient.
• Ratio de couplage (20%) — À quel point cet élément est-il connecté par rapport au reste du graphe ? Un couplage élevé signifie un risque élevé.

La jauge affiche vert, ambre ou rouge selon le score. En dessous, un détail de chaque facteur pour comprendre exactement ce qui motive le chiffre.

Amont et aval

L'analyse sépare l'impact en deux directions. L'amont montre tout ce qui dépend de l'élément sélectionné — les services qui l'appellent, les systèmes qui le consomment, les composants qui l'importent. L'aval montre tout ce dont l'élément dépend — les bases de données qu'il interroge, les APIs qu'il appelle, les bibliothèques qu'il utilise.

Chaque direction est organisée par degré. Les éléments de degré 1 sont directement connectés. Les éléments de degré 2 sont à un saut — ils ne touchent pas directement votre élément, mais ils touchent quelque chose qui le fait. Le degré 3 étend l'analyse d'un pas supplémentaire.

Cette vue en couches aide à penser l'impact en anneaux concentriques. Les changements de degré 1 sont immédiats. Les degrés 2 et 3 sont les effets secondaires — ceux qui tendent à surprendre les équipes qui n'ont regardé que les connexions directes.

Chemin critique

Si la chaîne de dépendances va en profondeur, Impact Radar met en évidence le chemin critique — la plus longue chaîne depuis l'élément sélectionné jusqu'au nœud affecté le plus distant. C'est le chemin où les changements mettent le plus de temps à se propager et où les défaillances en cascade sont les plus probables.

Chaque nœud du chemin critique est cliquable. Vous pouvez tracer la chaîne étape par étape et comprendre exactement comment un changement à une extrémité atteint l'autre.

Dépendances inter-projets

L'architecture ne s'arrête pas aux frontières d'un projet. Si votre organisation utilise la vue Architecture Globale d'Archyl pour connecter des systèmes entre projets, Impact Radar suit ces connexions aussi.

Le panneau inclut une section Dépendances inter-projets qui montre les éléments d'autres projets dans la zone d'impact. Chaque entrée affiche le nom du projet, pour savoir immédiatement quelles équipes impliquer.

C'est là qu'Impact Radar passe d'utile à essentiel. Dans un seul projet, vous pourriez tracer les dépendances manuellement. Sur cinq projets maintenus par différentes équipes ? C'est là que les oublis arrivent. Impact Radar trace le graphe complet automatiquement, indépendamment des frontières de projet.

Flux impactés

Si vous avez documenté des flux utilisateur ou système dans Archyl, Impact Radar les croise avec la zone d'impact. La section Flux impactés liste chaque flux qui inclut au moins une étape touchant un élément impacté, avec le nombre d'étapes affectées.

Un flux affichant "4/12 étapes impactées" raconte une histoire différente de "1/12 étapes impactées". Le premier signifie que le changement traverse une portion significative du parcours utilisateur. Le second signifie que c'est un point de contact périphérique.

Simulation "Et si ?"

En bas du panneau, un bouton : Simuler la suppression. C'est le bouton "que se passe-t-il si on supprime ça ?".

Activez-le, et Impact Radar calcule la cascade complète :

• Relations cassées — Chaque connexion explicite vers ou depuis l'élément (et ses enfants) qui deviendrait une référence pendante.
• Structurellement détruits — Les enfants directs qui seraient supprimés avec l'élément. Supprimer un conteneur, et chaque composant à l'intérieur disparaît aussi.
• Éléments orphelins — Les éléments qui deviennent inaccessibles depuis le reste du graphe après la suppression. Ils ne sont pas directement supprimés, mais ils sont effectivement morts — des nœuds déconnectés sans chemin vers quoi que ce soit.
• Ruptures inter-projets — Les relations globales d'autres projets qui seraient coupées.
• Impact total en cascade — Le nombre total de tout ce qui est affecté.

Ce n'est pas spéculatif. C'est un calcul déterministe sur le graphe de relations. Les chiffres disent exactement ce qui se passe si vous procédez.

Pourquoi c'est important

Le processus habituel pour évaluer des changements architecturaux aujourd'hui est une réunion. Quelqu'un propose un changement. L'équipe discute de qui pourrait être affecté. Les gens mentionnent des dépendances de mémoire. Quelqu'un vérifie un diagramme. Quelqu'un d'autre vérifie un autre diagramme. La réunion se termine avec une action de "creuser le sujet".

Impact Radar compresse ce cycle en un clic droit. L'analyse est exhaustive — elle suit chaque relation, chaque arête structurelle et chaque lien inter-projet du graphe. Elle ne dépend pas de la mémoire de qui que ce soit sur le câblage du système. Elle lit le modèle que vous avez déjà construit et montre ce que le modèle dit.

Cela change la façon dont les équipes abordent l'évolution architecturale :

• Avant de déprécier un service, voir chaque consommateur à travers chaque projet.
• Avant de restructurer une hiérarchie de composants, comprendre l'effet d'entraînement en aval.
• Avant un refactoring majeur, quantifier le rayon d'impact et identifier quelles équipes doivent être impliquées.
• Pendant les revues d'incident, tracer la chaîne de dépendances pour comprendre pourquoi une défaillance dans un composant a cascadé à travers le système.

Pour commencer

Impact Radar est disponible dès maintenant sur tous les plans. Ouvrez n'importe quel projet, faites un clic droit sur n'importe quel élément de votre diagramme C4, et sélectionnez Analyser l'impact.

L'analyse fonctionne d'autant mieux que votre modèle architectural est connecté — quand les relations entre éléments sont documentées, quand les flux capturent de vrais parcours utilisateur, et quand les liens inter-projets reflètent les véritables frontières système. Plus votre modèle est complet, plus l'analyse d'impact est utile.

Votre architecture est un graphe. Impact Radar vous permet de le lire.

Envie de construire un modèle architectural plus connecté ? Commencez par l'Introduction au modèle C4, puis connectez vos projets avec la Collaboration en temps réel et l'Architecture Globale. Pour les équipes qui veulent de la gouvernance autour des changements, les Demandes de changement d'architecture se marient naturellement avec Impact Radar — analysez l'impact d'abord, puis proposez le changement.