Analyse d'impact

Visualisez les dependances upstream et downstream de vos composants pour evaluer les consequences d'un changement.

Avant de modifier un composant critique, vous voulez savoir ce qui sera affecte. L'analyse d'impact repond a cette question en visualisant toutes les dependances d'un composant, qu'il s'agisse des services qui en dependent (downstream) ou des services dont il depend (upstream).

Analyse d'impact — vue canvas avec surbrillanceAnalyse d'impact — vue canvas avec surbrillance

Concept#

L'analyse d'impact utilise les connexions de votre architecture pour tracer les dependances :

Analyse Downstream#

"Si je modifie ce service, quels composants seront impactes ?"

L'analyse parcourt toutes les connexions sortantes et leurs cascades pour identifier les composants qui dependent de l'element selectionne.

Analyse Upstream#

"De quels services ce composant depend-il ?"

L'analyse parcourt toutes les connexions entrantes pour identifier les dependances amont.

Lancer une analyse#

Via le menu contextuel#

Menu contextuel — Analyser l'impactMenu contextuel — Analyser l'impact

  1. Clic droit sur un node
  2. Selectionnez Analyser l'impact (downstream) ou Voir les dependances (upstream)
  3. Le panneau d'impact s'ouvre

Via le panneau de proprietes#

  1. Selectionnez un node
  2. Dans le panneau de proprietes, onglet Impact
  3. Cliquez sur Downstream ou Upstream

Panneau d'impact#

Le panneau affiche les resultats de l'analyse :

Vue groupee par niveau#

Les composants impactes sont groupes par niveau de proximite :

NiveauDescription
DirectConnexion directe avec l'element analyse
IndirectA travers un intermediaire
CascadeA travers plusieurs intermediaires

Cette hierarchie vous aide a evaluer la severite de l'impact.

Informations par composant#

Pour chaque composant liste :

  • Nom : Label du composant
  • Type : Type de node (Backend, Database, etc.)
  • Chemin : La route de dependance (A → B → C)
  • Type de relation : depends_on, calls, stores_in, etc.

Alertes de criticite#

Les composants marques comme critical dans leurs proprietes semantiques sont signales :

  • Badge rouge "Critique"
  • Avertissement si dans la chaine d'impact direct

Un composant critique dans la chaine d'impact signifie qu'une modification peut avoir des consequences majeures sur le systeme.

Highlighting visuel#

Pendant l'analyse, le canvas affiche un overlay visuel :

Elements en surbrillance#

  • Element analyse : Bordure epaisse, couleur distinctive
  • Impact direct : Halo colore intense
  • Impact indirect : Halo plus leger
  • Cascade : Halo subtil

Connexions#

Les connexions impliquees dans la chaine d'impact sont mises en evidence avec une couleur distinctive.

Suivi du pan/zoom#

L'overlay suit les mouvements du canvas. Vous pouvez zoomer et vous deplacer tout en conservant la visualisation.

Types de relations et impact#

L'analyse utilise les types de relations pour qualifier l'impact :

TypePoidsInterpretation
depends_onFortDependance technique, impact probable
callsFortAppel synchrone, impact immediat
stores_inMoyenEcriture, impact sur les donnees
reads_fromMoyenLecture, impact sur la disponibilite
routes_toFaibleRoutage, impact reseau
replicates_toFaibleReplication, impact asynchone

Les connexions avec un poids fort sont prioritaires dans l'affichage.

Cas d'usage#

Avant une modification#

Imaginez que vous devez mettre a jour l'API Gateway :

  1. Selectionnez l'API Gateway
  2. Lancez l'analyse downstream
  3. Identifiez tous les services qui en dependent
  4. Planifiez la communication et les tests

Diagnostic d'incident#

Un service est en panne. Quels autres services sont affectes ?

  1. Selectionnez le service en panne
  2. Analyse downstream pour voir l'impact
  3. Analyse upstream pour identifier la cause potentielle

Revue d'architecture#

Evaluez la criticite d'un composant :

  1. Analysez ses dependances downstream
  2. Un composant avec beaucoup de dependants directs est critique
  3. Considerez l'ajout de replicas ou de fallbacks

Migration#

Planifiez la migration d'un service :

  1. Identifiez toutes les dependances avec l'analyse
  2. Listez les services a modifier (connexions, URLs)
  3. Etablissez l'ordre de migration

Proprietes semantiques et analyse#

Les proprietes semantiques enrichissent l'analyse :

Criticite#

Les composants critical ou high sont signales prominement.

Owner#

Le rapport inclut les owners des composants impactes. Utile pour coordonner les communications.

Type de relation#

Les relations typees (calls, stores_in) donnent plus de contexte que les connexions generiques.

Renseignez les proprietes semantiques et les types de relation pour obtenir des analyses d'impact plus pertinentes.

Limitations#

Profondeur#

L'analyse parcourt jusqu'a 10 niveaux de profondeur. Au-dela, les resultats sont tronques avec une indication.

Connexions manquantes#

L'analyse se base sur les connexions existantes. Si une dependance n'est pas documentee dans le diagramme, elle ne sera pas detectee.

Interpretation#

L'analyse montre les dependances structurelles, pas les dependances fonctionnelles. Un service peut etre impacte meme sans connexion directe si la modification affecte les donnees qu'il consomme.

Vue detail#

Cliquez sur un composant dans le panneau d'impact pour ouvrir la vue detail :

  • Chemin complet : La route de dependance
  • Insights : Observations automatiques (type de relation, criticite)
  • Tips : Suggestions selon le type de composant
  • Actions : Selectionner le node, ouvrir ses proprietes

Bonnes pratiques#

Avant tout changement majeur#

  1. Lancez l'analyse d'impact
  2. Documentez les composants affectes
  3. Notifiez les owners
  4. Planifiez les tests de regression

Architecture resiliente#

Si l'analyse revele beaucoup de dependances sur un seul composant :

  • Considerez l'ajout de replicas
  • Implementez des fallbacks
  • Evaluez le decoupling (queues, events)

Documentation continue#

Maintenez les connexions a jour. L'analyse n'est pertinente que si le diagramme reflete la realite.

Prochaines etapes#