§2 — Contraintes et exigences qualité

Fusion des sections arc42 §2 Constraints et §10 Quality requirements — elles se chevauchent trop à notre échelle pour justifier deux pages distinctes.

2.1 Contraintes techniques

Contrainte	Source	Implication
Stack TypeScript unique (pas de Python, pas de FastAPI, pas de modèle embarqué)	ADR-001, choix fondateur (2026-04)	Un seul langage côté code produit, une seule toolchain pnpm. Simplifie l'onboarding mais renonce à l'écosystème data science. La couche IA (ADR-012) respecte cette contrainte : le LLM est appelé par API, rien n'est entraîné ni exécuté localement.
Vue 3 + Vite + Tailwind	Choix fondateur, ADR-001	Pas de React/Svelte/Angular. Pinia comme store (ADR-010 pour le pattern façade).
Atomic Design ABEM strict	Choix fondateur, ADR-002	Préfixes a- / m- / o- / t- / p- sur 100 % des composants Vue. Vérifié manuellement lors des revues (pas de lint custom).
Fastify + Prisma côté backend	ADR-003, ADR-004	Monolithe API + cron ingestion dans le même runtime Node 20. Pas de microservices.
Pas de Vue Flow, pas de 3D, pas de photogrammétrie	Périmètre (§1.4)	Données tabulaires et séries temporelles uniquement. Vue Flow reporté backlog v2.
Lecture seule, pas d'authentification	§1 objectif de lisibilité, ADR-003	Aucune page protégée. Épopée admin (JWT + bcrypt + CRUD des seuils) explicitement hors scope v1.
Données publiques uniquement	ADR-007, ADR-013	Seul LINDAS est consommé (OFEV pour l'hydrologie, ElCom pour l'énergie, OFS pour les communes). Aucune donnée interne d'un exploitant ou d'un gestionnaire de réseau.

2.2 Contraintes organisationnelles

• Première phase en 13 jours (2026-04-18 → 2026-04-30) — ce calendrier court a calibré le périmètre initial : toute feature demandant plus de 2 jours de développement était mise en balance avec son apport. Les décisions de recentrage sont tracées dans le PRD d'origine (docs/_legacy/) et les ADR. Les extensions suivantes (couche IA, domaine énergie) sont additives et isolées.
• Monorepo pnpm workspaces — 3 workspaces : apps/web, apps/api, packages/shared (types + schémas Zod partagés). Un seul pnpm install à la racine.
• Self-hosting Coolify — pas de Vercel/Netlify/Fly. Infrastructure unique et sobre : VPS Hetzner + Coolify v4 + Traefik + Let's Encrypt.
• Conventional commits en anglais — les messages commit suivent type(scope): summary. Facilite la lecture git log par un relecteur. Règle d'engagement 6 de CLAUDE.md.
• Atomic commits obligatoires — un commit = un sous-livrable testable. Pas d'accumulation multi-phases dans le working tree.

2.3 Exigences qualité (quality tree arc42)

Priorité descendante. Chaque exigence a un critère vérifiable — pas d'adjectif sans mesure.

Priorité	Exigence	Critère vérifiable
1	Lisibilité < 30 s	Un relecteur technique sans brief ouvre alpimonitor.fr, identifie les domaines, les sources et la stack en moins de 30 s. README + hero page testés informellement le 2026-04-22.
2	Transparence factuelle	Chaque décision structurante a une ADR. Les stations dont le sourcing n'est pas publiquement vérifiable sont explicitement marquées ILLUSTRATIVE (ADR-008). Côté énergie, rien n'est estimé ni interpolé : une valeur non publiée s'affiche « donnée manquante » (ADR-013).
3	Stabilité prod	4 incidents rencontrés, 4 post-mortems écrits (§7). Couche IA en échec depuis le 2026-09-07, diagnostiquée mais non corrigée (constats de production).
4	Testabilité	436 tests (269 API + 167 web) ; en CI, sans base de données, 11 tests d'intégration API sont ignorés. Pyramide : fonctions pures → composables → intégration. Règle façade enforced par grep (ADR-010).
5	Performance	Lighthouse 12 en production le 2026-09-29 (perf/a11y/bonnes pratiques/SEO, médiane de 3 passages) : accueil / Mobile 81/100/100/100, Desktop 86/100/100/100 ; /hydrologie Mobile 65, Desktop 94 ; /energie Mobile 58, Desktop 75 ; /energie/regroupement Mobile 87, Desktop 99 — a11y, bonnes pratiques et SEO à 100 partout. JS transféré par route : 73 Ko (accueil) à 145 Ko (/hydrologie, Leaflet + D3). Écarts : /energie pénalisée par son décalage de mise en page (CLS 0,32 mobile, 0,73 desktop, §10.2) ; /hydrologie mobile par son LCP (4,2 s) ; forte dispersion sur l'accueil (mobile 67 à 88, desktop 83 à 99). Les mesures du 2026-04-22 (Desktop 96, Mobile 93) portaient sur l'ancienne page unique et ne sont pas comparables.
6	Accessibilité	WCAG AA contrastes validés sur sections sombres, focus visible, aria-label drawer, scroll-lock, Escape-fermeture. Lighthouse a11y 100 sur les quatre routes, Desktop et Mobile (production, 2026-09-29). Audit axe-core informel passé.
7	Sécurité	6 headers nginx (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, COOP). CORS allowlist. Container non-root. Zod sur tous les endpoints. Seul POST /api/v1/ask a un rate-limit applicatif (ADR-012) ; Helmet et rate-limit global de l'API reportés.
8	Observabilité minimale	Pino JSON stdout, /api/v1/health avec probe DB, /api/v1/status expose IngestionRun.lastRun + lastSuccessAt + compteurs journée ; LlmCallRun et /api/v1/ai/status pour la couche IA. Limites connues : pas d'APM ni de tracing distribué, pas d'IP réelle client côté API, détail des erreurs LLM non conservé (constats de production).

Les exigences 1 et 2 sont non-négociables ; 3-5 sont tenues en production, avec les écarts ci-dessus ; 6-8 sont tenues à un niveau défendable avec reste-à-faire tracé dans §10.

2.4 Règles d'engagement (résumé)

Les 8 règles absolues du projet, extraites de CLAUDE.md — voir §8 Conventions pour le détail opérationnel :

1. Lire les docs avant d'agir — jamais de code sans contexte.
2. YAGNI dur — ne pas implémenter ce qui n'est pas demandé.
3. ABEM strictement appliqué (préfixes + ADR-002).
4. Aucune dépendance ajoutée sans justification commit ou ADR.
5. Tests avant commit.
6. Conventional commits en anglais.
7. Pas de Python, pas d'IA embarquée, pas de Vue Flow en v1.
8. L'auteur humain doit pouvoir justifier chaque ligne en revue technique.

Ces règles cadrent toutes les décisions tracées dans les ADR et la doc architecturale. Elles sont citées pour référence uniquement — ne pas les dupliquer ailleurs.