Outil: Matrice de Diagnostic Rapide des Dépendances

17 novembre 2025

🔍 Outil: Matrice de Diagnostic Rapide des Dépendances

Mode d’Emploi

Utilisez cet outil pendant l’atelier pour diagnostiquer rapidement les dépendances problématiques.

Pour chaque paire d’équipes/contextes, remplissez ce formulaire collaborativement.

Formulaire de Diagnostic

1. IDENTIFICATION

Équipe/Service A: ___________________
Équipe/Service B: ___________________

Y a-t-il une dépendance?

NON (pas de relation)
OUI, A dépend de B
OUI, B dépend de A
OUI, mutuellement dépendants

Si NON: Fin du diagnostic. Archivez comme “Indépendant”.

2. NATURE DE LA DÉPENDANCE

Type de communication:

Synchrone (HTTP, RPC, appel direct)
Asynchrone (events, messages, queue)
Batch (export/import programmé)
Direct DB access (lecture/écriture)

Fréquence:

Très haute (>100/min, constant)
Haute (10-100/min, multiple times/hour)
Moyenne (1-10/min)
Basse (<1/min, rare)

Documentée:

Bien documentée (spec, SLA)
Partiellement documentée
Pas documentée du tout

3. IMPACT SI CASSÉE

Si la dépendance casse, qu’arrive-t-il à A?

Complète dégrade (A inutilisable)
Major degradation (A lent ou partiel)
Minor impact (A peut continuer)
Aucun impact (A indépendant)

Si la dépendance casse, qu’arrive-t-il à B?

Complète dégrade
Major degradation
Minor impact
Aucun impact

4. CARACTÉRISTIQUES DE RISQUE

Cochez tous les risques applicables:

Blocage organisationnel: Une équipe attend l’autre pour progresser
Bottleneck technique: B surcharge si demandes de A augmentent
Breaking changes: Changements B cassent régulièrement A
Version incompatibility: Pas de versioning, compatibility issue
No fallback: Si B fail, A fail (pas de retry/circuit breaker)
Tight timing: A et B doivent déployer en synchronisation
Knowledge silos: Peu de gens comprennent la dépendance
Hidden dependencies: Dépendance non obvie (découverte tard)
Performance coupling: Performance de B directement impact A
Data inconsistency: Sync issues causent des bugs subtils

Nombre de cases cochées:

0-2: Dépendance acceptable
3-5: Dépendance à surveiller
6+: Dépendance PROBLÉMATIQUE → Dependency Breaker nécessaire

5. PATTERN ACTUEL

Quel pattern décrit cette dépendance?

Conformist - A adopte le modèle B
Anticorruption Layer - A crée une couche de traduction
Shared Kernel - A et B partagent du code
Partnership - A et B collaborent
Customer/Supplier Development - A et B co-design
Open-host Service - B expose une API commune
Published Language - B publie un langage
Separate Ways - A et B sont indépendants (mais il y a une dépendance?)
Big Ball Of Mud - Pas clair, amorphe

Le pattern est-il intentionnel?

OUI, c’est le choix des deux équipes
PARTIELLEMENT, c’est un compromis
NON, c’est accidentel/par défaut

6. SÉVÉRITÉ GLOBALE

Basé sur les réponses précédentes, classifiez:

Fréquence?          Impact si cassée?       Risques cochés?
├─ Très haute       + Complète dégradé      + 6+ risques
│  OU              │                        │
├─ Synchrone       │                        │
│  + Documentée?   │                        │
│    NON           │                        │
│                  ↓                        │
                SÉVÉRITÉ = 🔴 CRITICAL     │
                         ↓                 │
                Dependency Breaker        │
                   URGENT!                 │
                                          ↓

Sélectionnez:

🔴 CRITICAL (Blocker) - Fixer immédiatement (sprint prochain)
🟠 ÉLEVÉ (Important) - Fixer bientôt (dans 1-2 mois)
🟡 MOYEN (Monitor) - Tracker, fixer si crée friction (3-6 mois)
🟢 ACCEPTABLE (Allow) - OK tel quel, continuer à monitorer

7. DEPENDENCY BREAKER RECOMMANDÉ

Si sévérité ≥ ÉLEVÉ, quel dependency breaker?

Répondez aux questions de sélection:

La dépendance est synchrone?
├─ OUI
│  └─ Peut devenir asynchrone?
│     ├─ OUI → EVENT-DRIVEN (Type 1)
│     │         ou CACHE + ASYNC (Type 1)
│     │
│     └─ NON → API VERSIONING (Type 5)
│              (stabiliser pour moins de breaking changes)
│
└─ NON (déjà asynchrone)
   └─ C'est un chaos ou une dépendance clean?
      ├─ CHAOS → BUBBLE CONTEXT + ACL (Type 2)
      │          ou STRANGLER (Type 6)
      │
      └─ CLEAN → Acceptable, laisser

Une équipe bloque l'autre?
└─ OUI → ORGANIZATIONAL ALIGNMENT (Type 4)
         (restructurer les équipes)

Dependency Breaker Recommandé:

Type sélectionné: ________________
Pattern appliqué: ________________
Effort estimé: [ ] 1 sprint [ ] 2 sprints [ ] 1 quarter [ ] plus

8. PLAN D’ACTION

Si un dependency breaker est recommandé:

Action immédiate (cette semaine):

1. [ ] Socialiser le problème (montrer ce formulaire aux deux équipes)
2. [ ] Documenter la dépendance (pour la première fois?)
3. [ ] Estimer l'effort du fix
4. [ ] Assignez un propriétaire du projet

Prochain sprint/cycle:

1. [ ] Prototype du dependency breaker
2. [ ] POC avec un petit subset de requêtes
3. [ ] Benchmark (avant/après)
4. [ ] Plan de rollout

Rollout (1-3 mois selon complexité):

1. [ ] Déploiement progressif (pas big bang)
2. [ ] Fallback en place
3. [ ] Monitoring et alertes actifs
4. [ ] Support team prêt
5. [ ] Communication des équipes

Post-implementation (1 mois après rollout):

1. [ ] Mesurer les améliorations réelles
2. [ ] Feedback des deux équipes
3. [ ] Documenter les leçons apprises
4. [ ] Célébrer le succès

Exemple d’Atelier Complet

Contexte: E-commerce, 3 équipes

Session de 90 minutes:

Minute 0-10: Intro
  Montrer l'outil
  Expliquer les critères

Minute 10-40: Remplir pour Pair #1 (Frontend ↔ Backend)
  Collaboratif, group discussion
  Remplir le formulaire complètement
  Résultat: CRITICAL - Event-driven recommended

Minute 40-65: Remplir pour Pair #2 (Catalog → Pricing)
  Résultat: ÉLEVÉ - Versioning recommended

Minute 65-80: Remplir pour Pair #3 (Analytics ← Core)
  Résultat: ACCEPTABLE - Laisser tel quel

Minute 80-90: Résumé et Next Steps
  Prioriser: Frontend/Backend first (CRITICAL)
  Assigner: A lead per dependency breaker
  Planning: Quand commencer?

Fichier à Imprimer

Version Papier (A4)

Vous pouvez imprimer ce document et remplir à la main lors de l'atelier.

Optionnel: Une copie par paire d'équipes
          + Une copie au tableau pour la voir ensemble

Suggestions:
  - Marqueurs différentes couleurs per sévérité
  - Afficher les formulaires terminés au mur
  - Créer une "dependency map" visuellement

Version Digital

Alternatives:
  - Google Forms ou Typeform pour collection auto
  - Miro/Mural pour brainstorm collaboratif
  - Spreadsheet shared pour remplissage simultané

Interprétation des Résultats

Si CRITICAL (🔴)

Action: Dependency breaker dans le sprint PROCHAIN
Escalade: Mentionner à leadership - c'est un blocker
Effort: Allocation dédiée

Exemple:
  Frontend bloquée par Backend
  → Breaker: Organizational Alignment ou API Versioning
  → Impact: Debloque 5+ autres features
  → Priority: Highest

Si ÉLEVÉ (🟠)

Action: Plan dans 2-3 sprints
Escalade: Tracker avec equipe leads
Effort: Plan au calendar

Exemple:
  Catalog changes break 3 consumers
  → Breaker: API Versioning
  → Impact: Réduit les incidents
  → Priority: High

Si MOYEN (🟡)

Action: Ajouter à backlog, fixer si ressources
Escalade: Mentioner en planning meeting
Effort: When time permits

Exemple:
  Analytics batch sync est tard de 2h
  → Breaker: Événements Asynchrones
  → Impact: Nice to have
  → Priority: Medium

Si ACCEPTABLE (🟢)

Action: Documenter et laisser
Escalade: Aucune
Effort: Zéro

Exemple:
  Order et Billing collaboration bien définie
  → Pattern: Partnership
  → Impact: Fonctionné bien
  → Priority: None (accept as is)

Tableau de Synthèse (Remplir en Fin d’Atelier)

Pair          Pattern Actuel    Sévérité    Breaker Type    Next Step
──────────────────────────────────────────────────────────────────────
A ↔ B         Conformist        CRITICAL    Event-Driven    Sprint N+1
C → D         Partnership       ACCEPTABLE  -               Monitor
E ← F         Big Ball Of Mud   ÉLEVÉ       ACL+Strangler   Plan Q2

Ressources Complémentaires

Créé pour: Facilitateurs et équipes diagnostiquant les dépendances en atelier
Version: 1.0
Licence: CC-BY-SA