§1 — Introduction et objectifs¶
1.1 Aperçu¶
AlpiMonitor est une plateforme de démonstration technique sur les données ouvertes fédérales suisses, en deux domaines, tous deux consommés depuis LINDAS SPARQL, le service de données liées de la Confédération :
- Hydrologie — le Rhône valaisan et ses affluents (Valais, Suisse), avec un focus recherche sur le bassin de la Borgne, affluent rive gauche du Rhône drainant le Val d'Hérens. Cette dualité reflète la vérité des données : le réseau LIVE suivi en quasi temps réel porte sur le Rhône et ses affluents (10 stations fédérales BAFU), tandis que les 3 stations RESEARCH de la Borgne matérialisent le focus territorial CREALP / Val d'Hérens, marquées selon leur sourcing (ADR-008).
- Énergie — les tarifs d'électricité publiés par l'ElCom : positionnement d'un gestionnaire de réseau réel, SEDRE SA, face aux 536 gestionnaires suisses, selon une méthode à quatre bases de comparaison (ADR-013).
Le projet est développé depuis le 2026-04-18 ; la première version publiée date du 2026-04-22 (tag v1.0.0-crealp). Ce n'est pas un produit commercial ni un outil opérationnel : aucune prévision, aucune alerte officielle, et les données affichées ne remplacent pas leurs sources.
La prod tourne sur alpimonitor.fr (SPA : accueil sur /, hydrologie sur /hydrologie, énergie sur /energie) + api.alpimonitor.fr (API) + storybook.alpimonitor.fr (design system) + docs.alpimonitor.fr (cette documentation), auto-deploy sur push main via Coolify sur VPS Hetzner.
1.2 Objectifs¶
| # | Objectif | Critère vérifiable |
|---|---|---|
| G1 | Démontrer une stack web moderne de bout en bout (Vue 3 + Vite + TypeScript + Tailwind + Fastify + Prisma + tests) | 436 tests (269 API + 167 web), CI GitHub Actions verte sur push main, TypeScript strict sans any implicite |
| G2 | Restituer fidèlement deux domaines métier à partir de données publiques | Vocabulaire fidèle (§10 glossaire) ; hydrologie : distinction LIVE/RESEARCH, sourcing factuel tracé (ADR-008) ; énergie : 50 320 tarifs réconciliés sur 50 320, verdict seulement quand quatre bases concordent (ADR-013) |
| G3 | Appliquer des pratiques justifiables, décision par décision | Atomic Design ABEM (ADR-002), façades feature-grouped sur Pinia (ADR-010), 14 ADR documentant chaque décision structurante |
| G4 | Livrer et exploiter en production | URL HTTPS publique, auto-deploy Coolify, 4 post-mortems d'incident (§7), constats de production documentés (§10) |
La priorité est la lisibilité en moins de 30 s pour un relecteur technique, pas l'exhaustivité fonctionnelle. C'est pourquoi la plateforme tient en quatre pages reliées par une barre de navigation (ADR-014) — un accueil qui pose la méthode et donne un chiffre par domaine, l'hydrologie sur une page scrollable, l'énergie sur une page d'écrans et une page méthodologique — sans page par station, sans comparateur multi-stations, sans administration, sans authentification — voir §10 Non-scope.
1.3 Parties prenantes¶
Relecteur technique — vérifie la maîtrise de la stack, la rigueur architecturale, la justification de chaque décision. Le README, un survol des ADR et quelques minutes sur le code doivent suffire à se forger une opinion.
Lecteur métier (hydrologie ou énergie) — reconnaît son vocabulaire (bassin versant, débit, captages ; gestionnaire de réseau, catégories de consommation, composantes du tarif) et juge la fidélité aux données sources. Chaque écran identifie le territoire, la source et le millésime.
Auteur — doit pouvoir justifier chaque ligne. Code, commits et ADR racontent une histoire cohérente et vérifiable.
Ops futur(e) — reprend le déploiement sans onboarding long. README §Déploiement + §7 Vue de déploiement + post-mortems fournissent tout.
Curieux / public informé — comprend le débit de son cours d'eau dans son contexte (captages, glaciers), ou la place du tarif de son gestionnaire parmi les autres. Pages accessibles, lecture possible sans connaissance préalable.
Les deux premières parties prenantes définissent les critères qualité (§2). Les suivantes héritent de la plateforme sans en influencer directement le périmètre.
1.4 Ce que la plateforme n'est pas¶
Le périmètre se définit aussi par ce qu'AlpiMonitor ne cherche pas à faire :
- Pas de prévision — ni modèle de crue, ni projection tarifaire. AlpiMonitor consulte et met en contexte des données publiées ; il ne calcule rien qui ne soit traçable jusqu'à une observation source.
- Pas de plateforme opérationnelle — aucune alerte officielle, aucune diffusion vers des autorités. La détection d'anomalie (ADR-012, extension B) est statistique et étiquetée comme non calibrée par une expertise hydrologique.
- Pas de 3D ni de photogrammétrie — uniquement des données tabulaires et des séries temporelles.
- Pas de données internes — ni mesures non publiées des stations de recherche, ni topologie de réseau électrique : la page méthodologique énergie nomme précisément ce que les données ouvertes ne permettent pas de savoir.
Ce périmètre est ancré dans ADR-007 (pivot LINDAS), ADR-008 (transparence du sourcing) et ADR-013 (domaine énergie).