Issues (diagnostic)

L’Issues panel est un moteur de règles intégré au canvas qui analyse ta modélisation en temps réel et te remonte les problèmes potentiels : failles de sécurité, choix d’architecture risqués, incohérences sémantiques. Pratique pour valider une maquette avant de la partager, auditer un schéma existant, ou simplement comprendre les bonnes pratiques réseau.

💡 Le moteur tourne côté navigateur sur la modélisation courante. Pas besoin d’enregistrer pour voir les issues — elles se mettent à jour dès que tu modifies un node ou une connexion.

📷 [IMAGE — vue d’ensemble issues] (à venir)

1. Ouvrir le panneau Issues

Dans la toolbar du canvas, le bouton 🐞 Issues affiche en permanence l’état global :

✅ Bouclier vert + « Aucun problème » — modélisation propre.
⚠️ Triangle ambre — au moins un warning ou une info.
🛑 Cercle rouge — au moins une erreur.

Le bouton porte aussi un compteur + un récap (2 err. · 3 warn.) dans son tooltip. Clique pour ouvrir la modale « Issues du projet ».

📷 [IMAGE — bouton issues toolbar] (à venir)

2. Lecture du panneau

La modale « Issues du projet » présente :

Une barre de filtres par sévérité (en haut).
La liste des issues groupées par catégorie.
Le bouton « Voir / Masquer les bypassés » à droite (si pertinent).

┌──────────────────────────────────────────────┐
│  [ Tout (5) ] [ Erreurs (1) ] [ Warn (3) ]   │
│  [ Info (1) ]              Voir bypassés (2) │
├──────────────────────────────────────────────┤
│  SÉCURITÉ · 2                                │
│  🛑 « web-app » accède directement à DB...   │
│  ⚠️ TLS manquant sur reverse proxy public... │
│                                              │
│  ARCHITECTURE · 2                            │
│  ⚠️ SPOF : « pg-prod » a 5 consommateurs...  │
│  ℹ️ « legacy-cron » n'a aucune connexion     │
│                                              │
│  SÉMANTIQUE · 1                              │
│  🛑 Port 8080 en conflit sur 2 services      │
└──────────────────────────────────────────────┘

3. Niveaux de sévérité

Chaque issue est typée selon trois niveaux, du plus critique au moins critique :

Icône	Sévérité	Signification	Bypass possible ?
🛑	Erreur	Problème bloquant ou faille évidente. À corriger.	Selon la règle.
⚠️	Warning	Risque ou anti-pattern. À évaluer.	Oui (souvent).
ℹ️	Info	Indication ou suggestion d’amélioration.	Oui.

Le bouton 🐞 Issues de la toolbar prend la couleur de la sévérité dominante (erreur > warning > info).

4. Catégories

Les règles sont groupées en trois catégories :

🔒 Sécurité

Failles ou expositions risquées détectables sur la topologie.

🏗️ Architecture

Patterns d’architecture risqués (SPOF, manque de cache, exposition sans proxy…).

🧠 Sémantique

Incohérences logiques dans la modélisation (conflits de port, cycles…).

5. Catalogue des règles

💡 Le catalogue est versionné dans le code (lib/rules/catalog.ts). Cette section présente les règles actuelles, mais peut évoluer.

Règles Sécurité

ID	Libellé	Sévérité	Bypass	Description
`SEC-001`	Base de données exposée	🛑 Erreur	❌ Non	Un user-client ou external-service accède directement à une BDD (SQL/NoSQL).
`SEC-002`	TLS manquant sur reverse proxy public	⚠️ Warning	✅ Oui	Reverse proxy / LB / CDN exposé au public sans HTTPS, HTTP2/3, WSS ou chiffrement explicite.
`SEC-003`	Identifiants par défaut	🛑 Erreur	❌ Non	Champ contenant `password`, `secret`, `token`… avec une valeur connue (`admin`, `changeme`, `1234`…).
`SEC-004`	Port sensible exposé	⚠️ Warning	✅ Oui	Port 22, 23, 3389 ou 5900 ouvert depuis un external-service.

Règles Architecture

ID	Libellé	Sévérité	Bypass	Description
`ARCH-001`	SPOF BDD	⚠️ Warning	✅ Oui	Base sans réplication (`replication: none`) avec ≥ 1 consommateur.
`ARCH-002`	Service orphelin	ℹ️ Info	✅ Oui	Service (hors host, externe, custom) sans aucune connexion entrante ni sortante.
`ARCH-003`	Service public sans reverse proxy	⚠️ Warning	✅ Oui	API/web-app exposée directement à un external-service.
`ARCH-004`	Pas de cache devant la BDD	ℹ️ Info	✅ Oui	App/API → BDD sans node de cache (Redis, Memcached…) sur le chemin.
`ARCH-005`	BDD sans sauvegarde	⚠️ Warning	✅ Oui	BDD sans lien vers un storage ni champ contenant `backup`.

Règles Sémantique

ID	Libellé	Sévérité	Bypass	Description
`SEM-001`	Conflit de port sur un même host	🛑 Erreur	❌ Non	Deux services partageant le même host ont la même valeur de `port`.
`SEM-002`	Cycle de dépendances	⚠️ Warning	✅ Oui	Une chaîne de connexions unidirectionnelles forme une boucle.

6. Lire une issue

Chaque ligne dans la liste affiche :

Icône de sévérité (🛑 rouge, ⚠️ ambre, ℹ️ bleu).
Message contextuel — ex. « Port 8080 en conflit sur “auth-api”, “admin-api” ». Cite les services concernés par leur nom.
Identifiant de règle (SEC-001, ARCH-002…) en mono dans une pastille grise.
Libellé court de la règle (ex. « Base de données exposée »).
Mention « bypassable » si la règle peut être ignorée.

À droite :

Bouton « Voir » — sélectionne le premier élément concerné (node ou edge) sur le canvas et ferme la modale.
Bouton « Bypass » (si bypassable) — voir section 8.

📷 [IMAGE — ligne issue] (à venir)

7. Filtrer

Les filter pills en haut de la modale permettent de restreindre l’affichage :

Pill	Effet
Tout	Affiche toutes les issues actives (défaut).
Erreurs	Uniquement 🛑.
Warnings	Uniquement ⚠️.
Info	Uniquement ℹ️.

Les pills affichent le compteur de chaque sévérité. Un clic toggle la sélection. La liste reste groupée par catégorie quelle que soit la sélection.

8. Bypasser une issue

Certaines règles sont bypassables : tu peux décider de les ignorer explicitement, par exemple parce que le warning est attendu dans ton contexte (setup local, projet jouet, exception métier…).

Procédure

Sur la ligne d’une issue bypassable, clique sur « Bypass ».
Une zone de saisie apparaît : « Raison du bypass ».
Renseigne une raison courte (ex. « setup dev local »).
Valide avec Entrée ou clique sur Bypass.
- 💡 Échap annule la saisie.

Effet

L’issue disparaît de la liste principale.
Elle bascule dans la section « Bypassés », accessible par le bouton « Voir les bypassés (N) » à droite des filter pills.
Les erreurs non-bypassables (SEC-001, SEC-003, SEM-001) ne proposent pas le bouton.

📷 [IMAGE — modale de bypass] (à venir)

Persistance

Les bypasses sont persistés localement par projet (stockés dans le navigateur). Pour l’instant ils ne sont pas synchronisés entre collaborateurs : chaque utilisateur a sa propre liste de bypasses sur le même projet.

⚠️ Si tu changes de navigateur ou si tu vides le storage local, tes bypasses sont réinitialisés et les issues correspondantes réapparaissent.

9. Voir et réactiver les bypassés

Clique sur « Voir les bypassés (N) » (en haut à droite des filtres).
La section « Bypassés · N » apparaît en bas de la liste avec ses propres lignes, dim grisées.
Sur chaque ligne bypassée, la raison saisie est rappelée en italique.
Pour réactiver une issue : clique sur « Réactiver » (icône ↶). L’issue retourne dans la liste principale.

📷 [IMAGE — section bypassés] (à venir)

10. Naviguer vers les éléments concernés

Le bouton « Voir » à droite de chaque issue :

Sélectionne le premier node ou edge impacté.
Ferme la modale Issues.
Le panneau de sélection (NodePanel ou ConnectionPanel) s’ouvre automatiquement à droite, prêt à l’édition.

💡 Quand une issue concerne plusieurs éléments (ex. cycle de dépendances : 3 nodes), seul le premier est focalisé — tu peux ensuite naviguer manuellement.

11. État vide

Si aucune issue n’est détectée avec les filtres actuels :

✅ Aucun problème détecté Le moteur de règles n’a rien trouvé d’anormal sur la configuration courante.

Si la liste est vide après filtrage (mais il existe des issues d’autre sévérité), repasse sur Tout pour les voir.

12. Workflow recommandé

Toolbar : 🐞 Issues → ouvre la modale.
Traite d’abord les erreurs non-bypassables (sécurité critique).
Évalue les warnings : corrige ou bypass avec une raison claire.
Les infos sont des pistes d’amélioration — agis selon ton contexte.
Avant de partager un projet, vérifie qu’il est en état « Aucun problème » (ou que tous les warnings restants sont bypassés avec raison).

13. FAQ

Le bouton Issues reste rouge alors que je n’ai rien à corriger. Il reste une erreur active — ouvre la modale et filtre sur Erreurs pour la trouver. Si elle est non-bypassable, il faut la corriger réellement (changer la topologie, modifier les champs, etc.).

J’ai bypassé une issue mais elle est revenue. Tes bypasses sont stockés localement : tu changes de navigateur, de machine, ou tu vides le storage → tout est perdu. Une synchronisation serveur est prévue dans une version future.

Pourquoi ce conflit de port apparaît alors que mes ports sont différents dans deux environnements ? Les règles vérifient le champ port de base des nodes. Les overrides d’environnement ne sont pas (encore) pris en compte par le moteur de règles.

Puis-je ajouter mes propres règles ? Le moteur est extensible côté code (lib/rules/catalog.ts), mais pas encore exposé à l’utilisateur. Si tu veux proposer une nouvelle règle, ouvre un ticket avec le scénario à détecter.

Un membre de mon équipe a-t-il les mêmes issues que moi ? Oui pour la liste des issues (le calcul est déterministe sur la même modélisation). Non pour les bypasses (locaux à chaque utilisateur).