# PROJECT BRIEF — HistoMétéo ## 1) Vision Offrir un outil web simple et accessible permettant à n'importe quel utilisateur de retrouver les conditions météorologiques passées, heure par heure, pour n'importe quelle commune de France. Le projet répond à un besoin récurrent mais mal couvert : consulter la météo d'un jour précis dans le passé (mariage, événement sportif, voyage, etc.) sans devoir naviguer dans des interfaces complexes ou des bases de données scientifiques. L'ambition est de produire un MVP fonctionnel rapidement, en s'appuyant exclusivement sur des sources de données publiques et gratuites. --- ## 2) Problème identifié **Douleur principale :** il est aujourd'hui difficile pour un particulier de retrouver simplement la météo passée d'une commune française à une heure précise. - Les outils existants sont soit trop techniques (données brutes de stations), soit trop vagues (résumés journaliers sans granularité horaire). - Aucun service grand public ne propose une recherche par commune française avec auto-complétion et affichage horaire clair. - Les données existent pourtant (réanalyses météo, APIs ouvertes) mais restent inaccessibles au non-initié. **Pourquoi le résoudre :** la curiosité météo est un besoin universel et fréquent. Un outil simple, gratuit et rapide comble un vide réel dans l'écosystème francophone. --- ## 3) Cible **Utilisateur principal :** particulier curieux souhaitant retrouver la météo d'un jour précis dans le passé. **Utilisateurs secondaires :** - Journalistes ou rédacteurs cherchant à documenter les conditions météo d'un événement. - Sportifs analysant les conditions d'une course ou compétition passée. - Passionnés de météo souhaitant explorer l'historique climatique local. **Contexte d'utilisation :** usage ponctuel, sur desktop ou mobile, sans inscription ni configuration. L'utilisateur arrive avec une commune et une date en tête, et veut une réponse immédiate. --- ## 4) Proposition de valeur - **Simplicité :** une seule page, trois actions (chercher une commune, choisir des dates, afficher). - **Granularité :** données heure par heure, pas seulement un résumé journalier. - **Localisation précise :** recherche par commune française avec auto-complétion. - **Lisibilité :** données présentées dans un tableau clair, en fuseau horaire français. - **Accessibilité :** gratuit, sans inscription, responsive desktop/mobile. --- ## 5) Périmètre initial (Scope v1) - Recherche d'une commune française avec auto-complétion (nom, département). - Sélection d'une période passée (date début / date fin, maximum 31 jours). - Affichage d'un tableau météo horaire : température, précipitations, humidité, vent, description des conditions. - Toutes les données affichées en fuseau horaire Europe/Paris. - Affichage clair de la plage de dates disponibles (limite historique de l'API météo) pour guider l'utilisateur dans sa sélection de période. - Inclusion des communes d'outre-mer (DOM-TOM) si couvertes par l'API météo utilisée. - Note de transparence visible expliquant honnêtement le concept de réanalyse météo : les données ne proviennent pas d'une station locale mais d'une reconstitution par modèle, et ce que cela implique en termes de précision. - Messages d'erreur explicites en cas d'indisponibilité d'une API ou de requête invalide (pas de message générique, l'utilisateur doit comprendre ce qui se passe). - Interface responsive (desktop + mobile). - Page unique, sans navigation complexe. --- ## 6) Hors périmètre initial - Graphiques (température, précipitations). - Résumés journaliers (min/max/cumuls). - URLs partageables avec paramètres pré-remplis. - Comparaison entre deux périodes ou deux années. - Export des données (CSV, JSON). - Gestion de comptes utilisateurs. - Historique des recherches. - Couverture des communes d'outre-mer non couvertes par l'API météo. - Nom de domaine dédié (pas encore prévu). --- ## 7) Contraintes connues - **Sources de données :** le projet repose intégralement sur deux APIs publiques gratuites (geo.api.gouv.fr pour les communes, Open-Meteo pour la météo historique). Aucune donnée propre n'est stockée. - **Précision et transparence :** les données météo proviennent de réanalyses météorologiques (reconstitution du climat passé par modèle numérique à partir de multiples sources d'observation). Ce ne sont pas des mesures directes d'une station située dans la commune. Le produit doit expliquer honnêtement ce concept à l'utilisateur, sans jargon excessif, afin de fixer des attentes réalistes. - **Période :** limitation à 31 jours maximum par requête pour éviter les surcharges. - **Budget :** zéro coût d'API. L'hébergement doit rester minimal ou gratuit. - **Hébergement :** auto-hébergé dans un premier temps, puis migration vers Vercel envisagée. - **Performance :** des mécanismes de cache côté serveur sont nécessaires pour limiter les appels API et garantir la réactivité. --- ## 8) Risques ou inconnues majeures - **Disponibilité des APIs :** les APIs gratuites peuvent imposer des limites de requêtes (rate limiting) ou connaître des indisponibilités temporaires. Aucun SLA n'est garanti. - **Couverture temporelle :** la profondeur historique disponible via Open-Meteo doit être vérifiée (jusqu'à quelle date dans le passé les données sont-elles accessibles ?). - **Précision perçue :** les utilisateurs pourraient attendre des données exactes de station météo locale. Le décalage entre données modélisées et réalité terrain peut générer des déceptions. - **Évolution des APIs :** les endpoints ou formats de réponse peuvent changer sans préavis. --- ## 9) Hypothèses initiales - L'API geo.api.gouv.fr fournit des coordonnées (latitude/longitude) suffisamment précises pour chaque commune. - L'API Open-Meteo Historical couvre la France métropolitaine (et potentiellement les DOM-TOM) avec une granularité horaire et une profondeur historique d'au moins plusieurs décennies. - Un MVP mono-page sans backend lourd est suffisant pour valider l'intérêt utilisateur. - Le volume d'utilisation initial sera faible, donc les limites des APIs gratuites ne seront pas atteintes. - L'affichage sous forme de tableau est le format le plus adapté pour un MVP (les graphiques viendront en V2). --- ## 10) Décisions actées 1. **Profondeur historique :** la limite de dates disponibles sera détectée et affichée clairement à l'utilisateur pour guider sa sélection. 2. **Transparence sur les données :** le site expliquera honnêtement le concept de réanalyse météo — reconstitution par modèle numérique, pas mesure de station locale — de manière accessible et sans jargon. 3. **Gestion des erreurs :** messages d'erreur explicites et compréhensibles en cas d'indisponibilité API ou de requête invalide. 4. **DOM-TOM :** inclus dans le MVP si l'API météo couvre ces territoires. À vérifier lors de la phase technique. 5. **Hébergement :** auto-hébergé pour le MVP, avec migration Vercel prévue ensuite. 6. **Nom de domaine :** pas encore prévu. Le MVP sera accessible via l'URL d'hébergement. --- ## 11) Questions ouvertes restantes 1. **Couverture DOM-TOM effective :** à valider techniquement — quelles communes d'outre-mer sont réellement couvertes par Open-Meteo ? 2. **Profondeur historique exacte :** quelle est la date la plus ancienne disponible ? Varie-t-elle selon les territoires ? 3. **Formulation de la note de transparence :** quel ton adopter (encart informatif, tooltip, page dédiée) ?