Collecte de données météo : sources, API et implémentations

La météo est l'un de ces blocs qui augmentent discrètement la valeur d'un site : l'utilisateur reste plus longtemps sur la page, revient plus souvent, et le contenu paraît « vivant ». C'est pourquoi les widgets et blocs météo sont si fréquents sur les portails de villes et de tourisme, dans les services de réservation et sur les sites d'immobilier à l'étranger. Dans cet article, nous voyons où trouver les données météo, quelles API sont populaires en 2026, en quoi le parsing HTML diffère du travail via API, et nous montrons des implémentations prêtes en Python, JavaScript, PHP et Go.

Qu'est-ce que la « collecte de données météo » et quelles sont les approches

Sous « collecte de données météo » se cachent en réalité deux tâches de nature différente :

1. Le travail via une API officielle. Le service fournit des données structurées (le plus souvent en JSON), vous faites une requête HTTP et recevez des champs prêts : température, humidité, vitesse du vent, code du phénomène météo. C'est la voie fiable, légale et prévisible.
2. Le parsing de pages HTML (web scraping). Quand la source n'a pas d'API ou qu'elle est payante, les développeurs extraient les données directement du balisage du site. Ça fonctionne, mais c'est fragile : au moindre changement du HTML le parseur casse, et l'approche viole souvent les conditions d'utilisation de la source.

La conclusion pratique est simple : chaque fois qu'une API existe, utilisez l'API. Gardez le parsing pour les cas où il n'y a réellement pas d'autre source, et vérifiez systématiquement robots.txt et les conditions d'utilisation.

Sources de données et API populaires

Open-Meteo — gratuit et sans clé

Open-Meteo est l'une des options les plus commodes pour démarrer. L'API n'exige pas de clé pour un usage non commercial, renvoie du JSON et agrège les prévisions des services météo nationaux avec une résolution de 1 à 11 km. Pour les projets commerciaux, il existe des forfaits payants avec des limites mensuelles de requêtes. Idéal pour les prototypes, les widgets et les projets open source.

OpenWeatherMap — le classique au généreux palier gratuit

OpenWeatherMap reste le service le plus repris dans les tutoriels. En 2026, il conserve une voie gratuite fonctionnelle, mais il faut bien comprendre quel produit vous appelez. Les endpoints classiques (météo actuelle, prévision par tranches de 3 heures, pollution de l'air, cartes météo, géocodage) sont gratuits avec une limite de 60 requêtes par minute et jusqu'à 1 000 000 de requêtes par mois. Les produits de la famille One Call (3.0 / 4.0) sont des abonnements distincts facturés à l'appel, avec les 1000 premières requêtes quotidiennes gratuites. Avant la mise en production, pensez à poser un plafond de dépenses pour ne pas franchir le seuil gratuit par accident.

WeatherAPI.com — un forfait gratuit généreux

WeatherAPI.com fournit la météo actuelle, les prévisions horaires et journalières, les données historiques, l'astronomie et la géolocalisation en JSON et XML. Un choix commode quand il faut un seul fournisseur « pour tout » avec une limite gratuite claire.

Visual Crossing — des données historiques solides

Visual Crossing est souvent cité parmi les meilleurs rapports capacités/prix : une API unique pour la météo actuelle, les prévisions, les alertes et surtout les longues séries historiques. Clé gratuite disponible et Query Builder pour assembler les requêtes avec export en JSON ou CSV. Une bonne option pour l'analytique et les tableaux de bord.

Les plateformes pour le business : Tomorrow.io, Weatherbit, Meteomatics, meteoblue

S'il vous faut des paramètres très spécialisés (environ 500 chez Tomorrow.io, plus de 1800 chez Meteomatics, des séries historiques depuis 1940), regardez du côté des plateformes d'entreprise. Elles offrent une grande précision et un immense jeu de paramètres, mais exigent presque toujours un abonnement payant pour l'usage commercial.

Sources régionales du marché russophone : Yandex.Météo et Gismeteo

• Yandex.Météo. L'API vise aujourd'hui d'abord le B2B et fonctionne via GraphQL (v3), avec accès par clé de test et période d'essai de 7 jours. Il existe aussi un forfait REST « météo pour votre site » avec le point d'accès « informers » https://api.weather.yandex.ru/v2/informers et l'autorisation par en-tête X-Yandex-Weather-Key. La technologie Meteum agrège radars météo, satellites, modèles globaux et stations au sol.
• Gismeteo. Propose des widgets météo et un service de données fermé ; l'intégration passe en général par un accord préalable avec le service.

Services publics et officiels

Pour les États-Unis, il existe l'API gratuite et sans clé du service météo national (NWS, weather.gov) — un excellent choix pour les projets civils et publics dans le pays. Pour la France, Météo-France ouvre ses données publiques via son portail d'API (modèles AROME et ARPEGE, observations, climatologie) — la source officielle de référence pour l'Hexagone. Les sources publiques sont gratuites et faisant autorité, mais généralement limitées à un territoire précis.

Comparaison selon les critères clés

Implémentations dans différents langages

Tous les exemples ci-dessous utilisent Open-Meteo, car il n'exige pas de clé — le code se lance immédiatement. Les coordonnées des exemples : Paris (48.86, 2.35). Pour passer à un autre fournisseur, il suffit en général de changer l'URL, d'ajouter la clé et d'ajuster la lecture du JSON.

Python (requests)

import requests

def get_weather(lat: float, lon: float) -> dict:
    url = "https://api.open-meteo.com/v1/forecast"
    params = {
        "latitude": lat,
        "longitude": lon,
        "current": "temperature_2m,relative_humidity_2m,wind_speed_10m,weather_code",
        "timezone": "auto",
    }
    response = requests.get(url, params=params, timeout=10)
    response.raise_for_status()
    return response.json()

data = get_weather(48.86, 2.35)
current = data["current"]
print(f"Température : {current['temperature_2m']}°C")
print(f"Humidité : {current['relative_humidity_2m']}%")
print(f"Vent : {current['wind_speed_10m']} km/h")

Version pour OpenWeatherMap avec clé et localisation française :

import requests

API_KEY = "VOTRE_CLE"

def get_weather_owm(city: str) -> dict:
    url = "https://api.openweathermap.org/data/2.5/weather"
    params = {"q": city, "units": "metric", "lang": "fr", "appid": API_KEY}
    response = requests.get(url, params=params, timeout=10)
    response.raise_for_status()
    d = response.json()
    return {
        "ville": d["name"],
        "température": d["main"]["temp"],
        "ressenti": d["main"]["feels_like"],
        "description": d["weather"][0]["description"],
    }

print(get_weather_owm("Paris"))

JavaScript / Node.js (fetch natif)

Dans Node.js 18+, fetch est disponible d'origine — aucune dépendance externe.

async function getWeather(lat, lon) {
  const url = new URL("https://api.open-meteo.com/v1/forecast");
  url.searchParams.set("latitude", lat);
  url.searchParams.set("longitude", lon);
  url.searchParams.set("current", "temperature_2m,wind_speed_10m,weather_code");
  url.searchParams.set("timezone", "auto");

  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`Erreur HTTP : ${response.status}`);
  }
  return response.json();
}

getWeather(48.86, 2.35)
  .then((data) => {
    const c = data.current;
    console.log(`Température : ${c.temperature_2m}°C, vent : ${c.wind_speed_10m} km/h`);
  })
  .catch((err) => console.error("Impossible de récupérer la météo :", err.message));

PHP (cURL)

<?php
function getWeather(float $lat, float $lon): ?array
{
    $query = http_build_query([
        'latitude'  => $lat,
        'longitude' => $lon,
        'current'   => 'temperature_2m,wind_speed_10m,weather_code',
        'timezone'  => 'auto',
    ]);
    $url = "https://api.open-meteo.com/v1/forecast?{$query}";

    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT        => 10,
        CURLOPT_USERAGENT      => 'WeatherWidget/1.0',
    ]);
    $body = curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($body === false || $code !== 200) {
        return null;
    }
    return json_decode($body, true);
}

$data = getWeather(48.86, 2.35);
if ($data !== null) {
    echo "Température : " . $data['current']['temperature_2m'] . "°C\n";
}

Go

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
    "time"
)

type WeatherResponse struct {
    Current struct {
        Temperature float64 `json:"temperature_2m"`
        WindSpeed   float64 `json:"wind_speed_10m"`
        WeatherCode int     `json:"weather_code"`
    } `json:"current"`
}

func main() {
    url := "https://api.open-meteo.com/v1/forecast" +
        "?latitude=48.86&longitude=2.35" +
        "&current=temperature_2m,wind_speed_10m,weather_code&timezone=auto"

    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get(url)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    var data WeatherResponse
    if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
        panic(err)
    }
    fmt.Printf("Température : %.1f°C, vent : %.1f km/h\n",
        data.Current.Temperature, data.Current.WindSpeed)
}

Requête à l'API Yandex.Météo (API REST)

curl -H "X-Yandex-Weather-Key: VOTRE_CLE" \
  "https://api.weather.yandex.ru/v2/informers?lat=55.75&lon=37.62&lang=ru_RU"

Le parsing HTML comme solution de repli (Python + BeautifulSoup)

Quand l'API est inaccessible, les données peuvent être extraites du balisage. L'approche fonctionne, mais elle est fragile : au changement du HTML, les sélecteurs cessent de marcher, et elle n'est admissible que si elle ne contredit pas les conditions de la source.

import requests
from bs4 import BeautifulSoup

def scrape_weather(url: str) -> str:
    headers = {"User-Agent": "Mozilla/5.0"}
    html = requests.get(url, headers=headers, timeout=10).text
    soup = BeautifulSoup(html, "html.parser")
    # Le sélecteur s'ajuste à la page-source concrète
    temp = soup.select_one(".temperature")
    return temp.get_text(strip=True) if temp else "non trouvé"

Le décodage du weather_code d'Open-Meteo suit le standard WMO : par exemple, 0 — ciel clair, 2 — partiellement nuageux, 61 — pluie faible, 71 — neige faible. Gardez la table complète des codes sous forme de dictionnaire de correspondance pour afficher à l'utilisateur une description lisible.

Cache, limites et aspects juridiques

Quelques règles qui économisent argent et nerfs en production :

• Mettez les réponses en cache. La météo n'a presque jamais besoin de se rafraîchir à chaque affichage de page. Cachez par coordonnées, ville ou code postal, et actualisez les conditions courantes toutes les 5–15 minutes. Pour les applications mobiles, faites passer les requêtes par votre backend plutôt que depuis chaque client directement.
• Gardez les clés côté serveur. Une clé d'API ne doit pas être incrustée dans le code client — elle est facile à voler. Les requêtes doivent transiter par votre proxy backend.
• Surveillez les limites. Prévoyez le traitement des réponses 401 (clé invalide), 429 (limite dépassée) et des alertes en cas de croissance brutale du nombre d'appels.
• Vérifiez la licence. La plupart des forfaits gratuits n'autorisent que l'usage non commercial. Certains services (Visual Crossing, OpenWeatherMap) admettent un usage commercial limité avec mention de la source. Pour le parsing, vérifiez toujours robots.txt et les conditions d'utilisation.

Où cela s'applique : portails, tourisme et immobilier

Le bloc météo est la « fonctionnalité » type des projets liés à la géographie et au mode de vie de l'utilisateur :

• Les portails de villes affichent la météo actuelle et la prévision en page d'accueil — cela retient l'audience et fait du site un point d'entrée quotidien.
• Les portails touristiques et services de réservation ajoutent la météo à la fiche de destination : le voyageur veut savoir ce qui l'attend sur place.
• Les sites d'immobilier à l'étranger utilisent la météo comme argument de « vente du climat » : journées ensoleillées, hiver doux et température agréable pèsent dans le choix d'un logement au bord de la mer ou à la montagne.

Fait intéressant : techniquement, la collecte de données météo se range aux côtés d'une autre tâche phare de ces projets — la collecte et l'agrégation d'annonces. Si la météo rend la fiche de destination « vivante », le remplissage du catalogue d'objets est assuré par l'extraction d'annonces immobilières : collecte automatique des offres sur les plateformes-sources, normalisation des prix et des caractéristiques, mise à jour de la base. Ces deux modules travaillent souvent côte à côte — l'un s'occupe du contenu de l'objet, l'autre du contexte qui l'entoure.

Conclusion

Pour la plupart des besoins, commencez par Open-Meteo (démarrage rapide sans clé) ou OpenWeatherMap (généreux palier gratuit et écosystème mûr). Si les données historiques comptent — regardez Visual Crossing ; pour des données officielles françaises — le portail open data de Météo-France ; pour le marché russophone et le B2B — Yandex.Météo. Techniquement, l'intégration tient en quelques lignes dans n'importe quel langage : requête HTTP, lecture du JSON, cache. Et un bloc météo bien intégré augmente sensiblement l'engagement sur les portails de villes, de tourisme et d'immobilier — là où l'utilisateur s'intéresse non seulement à l'objet, mais aussi au contexte qui l'entoure.