1 La météo de demain, en une phrase
Ce qu'on veut : vous écrivez /meteo, le bot répond
« Demain à Sion, 12 à 25 degrés, pas de pluie. »
vous /meteo
le bot ☁️ Demain à Sion · 12,0 à 25,4 °C · 0 mm de pluie
Les nœuds : Switch (une branche de plus) →
HTTP Request → Code → Telegram. Le moule, sans rien de plus.
L'adresse :
open-meteo.com · aucune clé
https://api.open-meteo.com/v1/forecast?latitude=46.2331&longitude=7.3606
&daily=temperature_2m_max,temperature_2m_min,precipitation_sum,weather_code
&timezone=Europe/Zurich&forecast_days=1
Les coordonnées sont celles de Sion. Mettez les vôtres, elles se trouvent d'un clic droit
sur n'importe quelle carte.
Le piège : la réponse n'est pas une liste de journées, c'est un
objet qui contient des listes. Même pour un seul jour, temperature_2m_max
reste un tableau. Il faut écrire daily.temperature_2m_max[0]. Sans le
[0], le champ arrive vide et on cherche l'erreur ailleurs pendant vingt
minutes. Second détail : weather_code est un nombre, pas un texte
(0 = ciel clair, 3 = couvert, 61 = pluie faible). Il vous faut une petite
table de correspondance dans le nœud Code.
Ce qu'on apprend : descendre dans une réponse JSON et en extraire
la bonne valeur. C'est le geste de base, et il resservira cinq fois.
2 Les pollens, le même geste sur un autre service
Ce qu'on veut : /pollens et le bot annonce les quatre
pollens qui gâchent le printemps valaisan. Même éditeur que l'exercice 1, autre hôte,
autre forme de réponse. C'est exactement pour ça qu'il vient en deuxième.
L'adresse :
air-quality-api.open-meteo.com · aucune clé
https://air-quality-api.open-meteo.com/v1/air-quality?latitude=46.2331
&longitude=7.3606¤t=grass_pollen,birch_pollen,alder_pollen,ragweed_pollen
&timezone=Europe/Zurich
Le piège : ici on demande current et non
daily, et les valeurs arrivent seules, sans tableau. Donc
current.grass_pollen se lit directement, sans [0]. Changer de
service, c'est d'abord changer de forme de réponse. Autre chose, vérifiée : hors
d'Europe, les champs existent toujours mais valent null. Le modèle de
prévision ne couvre que le continent, et il ne vous le dit pas.
Ce qu'on apprend : qu'un champ vide n'est pas forcément une faute
de votre part. Avant de corriger votre nœud, demandez-vous si le service a la donnée.
3 Le Rhône, et le mot qu'il ne faut pas écrire
Ce qu'on veut : /rhone et le bot donne le débit
mesuré, en mètres cubes par seconde. Utile en Valais quand il pleut trois jours d'affilée.
La source : les mesures viennent de l'Office fédéral de
l'environnement. Elles sont republiées par api.existenz.ch, tenu par une
association suisse. La station 2011, c'est le Rhône à Sion.
api.existenz.ch · aucune clé
https://api.existenz.ch/apiv1/hydro/latest?locations=2011
¶meters=flow,temperature&app=VOTRE_APP&version=1.0
Le paramètre app attend le nom de votre bot. Aucune clé, aucun contrôle : c'est une
politesse, qui permet à celui qui héberge de savoir qui l'appelle. Mettez un nom lisible plutôt que de le laisser tel quel.
Le piège, et il est joli : le paramètre s'appelle
flow. Si vous écrivez discharge, le mot qui vient
spontanément quand on cherche « débit » dans un dictionnaire technique, le
service répond quand même 200, avec "payload": []. Pas d'erreur, pas de
message d'aide, rien. On a appelé les deux pour en avoir le cœur net :
flow renvoie la valeur, discharge renvoie une liste vide.
Deuxième piège : la réponse est une liste plate d'objets
{timestamp, loc, par, val}. On demande deux paramètres, on peut n'en
recevoir qu'un : la station 2011 publie le débit mais pas la température de l'eau.
Cherchez donc l'élément dont par vaut flow. Ne prenez jamais
payload[0] en supposant que l'ordre suivra votre demande.
Ce qu'on apprend : qu'un code 200 ne prouve pas qu'on a posé la
bonne question. C'est la leçon la plus rentable de cette page, et elle vaut bien au-delà
des rivières.
4 Le prochain train, avec un paramètre qui vient de vous
Ce qu'on veut : /train Sion Lausanne et le bot répond
l'heure de départ, le quai et le retard éventuel. Cette fois, l'adresse dépend de ce que
vous avez écrit, et c'est toute la difficulté.
vous /train Sion Lausanne
le bot 🚆 11:39 · quai 3 · 1 min de retard · 2 h 06 de trajet
transport.opendata.ch · aucune clé
https://transport.opendata.ch/v1/connections?from=Sion&to=Lausanne&limit=1
Les nœuds : avant le HTTP Request, il faut découper le
texte de la commande pour isoler les deux gares. Un nœud Code, ou une
expression dans le champ, du genre
{{ $json.message.text.split(' ')[1] }}.
Le piège : les noms de gares contiennent des espaces, des traits
d'union et des accents. « Genève-Aéroport » collé tel quel dans l'adresse part
de travers. Plutôt que de bricoler la chaîne à la main, activez
Send Query Parameters dans le nœud HTTP Request et donnez
from et to comme deux paramètres séparés : n8n les encode
correctement pour vous. Testé avec Genève-Aéroport, ça passe.
Ce qu'on apprend : faire entrer proprement une donnée écrite par un
humain dans un appel extérieur. Bâclé, ce geste est la porte d'entrée des injections.
C'est la même prudence que pour les apostrophes dans le SQL du bot.
5 Les avions au-dessus de chez vous, et un vrai jeton
Ce qu'on veut : /avions et le bot compte les appareils
dans un carré de ciel autour de vous. Le service est OpenSky Network, une association
basée en Suisse.
opensky-network.org · accès anonyme limité
https://opensky-network.org/api/states/all?lamin=46.0&lomin=7.0
&lamax=46.5&lomax=7.6
Sans compte, l'appel fonctionne encore, avec un budget quotidien. Un en-tête
x-rate-limit-remaining vous dit ce qu'il vous reste. Pour un bot personnel
qui répond quand on l'interroge, c'est suffisant.
Le piège de débutant : quand le carré est vide, le champ states
vaut null au lieu de contenir une liste vide. Tout nœud qui compte une
longueur s'arrête là. Vérifié le même jour à la même minute : au-dessus du Valais,
null ; au-dessus de Zurich, 47 appareils. La différence n'était pas
dans le code.
Le piège sérieux, celui qui fait l'exercice : depuis mars 2026,
l'identifiant et le mot de passe posés sur l'appel ne servent plus à rien. Ils ne
provoquent même pas d'erreur, ils sont simplement ignorés et vous retombez dans le quota
anonyme sans vous en apercevoir. Pour un vrai quota, il faut passer par OAuth2 : on
demande un jeton à l'adresse d'authentification avec un identifiant client et un secret,
puis on présente ce jeton dans l'en-tête Authorization de chaque appel. Le
jeton expire, donc il faut savoir le redemander.
Les nœuds : deux HTTP Request au lieu d'un. Le premier
va chercher le jeton en POST, le second s'en sert. Beaucoup de tutoriels en ligne datent
d'avant ce changement ; c'est la raison pour laquelle ils ne marchent plus, et pas
vous qui vous y prenez mal.
Ce qu'on apprend : la différence entre une clé qu'on colle une fois
et un jeton qu'on renouvelle. Ce schéma en deux temps ouvre la porte de la plupart des
services professionnels.
6 MCP, ou comment arrêter d'écrire un nœud par service
Ce qu'on veut : ne plus refaire les cinq exercices précédents à
chaque nouvelle idée. MCP est un protocole par lequel un serveur publie une liste
d'outils, décrits de façon à ce qu'un modèle sache quand les utiliser. n8n sait s'y
brancher, et presque personne ne l'explique en français.
Le nœud : MCP Client Tool. Il ne se pose pas dans le
fil du workflow, il s'accroche sous un nœud Agent, comme un outil de plus.
Vous renseignez l'adresse du serveur dans Endpoint, vous choisissez
l'authentification (aucune, jeton porteur, en-tête, ou OAuth2 selon le serveur), et
l'agent découvre tout seul ce qu'il peut faire.
Le piège : les outils sont décrits au modèle à chaque tour de
conversation. Un serveur qui en publie trente, ce sont trente descriptions envoyées à
chaque message, et la facture qui suit. Le nœud prévoit Tools to Include et
Tools to Exclude pour n'exposer que ce dont vous avez besoin. Servez-vous-en dès
le premier essai, pas après la première facture.
La confusion à éviter : n8n a deux nœuds aux noms voisins.
MCP Client Tool va chercher des outils ailleurs pour votre bot.
MCP Server Trigger fait l'inverse : il expose les workflows de votre
n8n à un agent extérieur. Pour cet exercice, c'est le client. Le serveur, c'est l'étape
d'après, et elle est encore plus amusante : votre bot de tâches devient un outil que
d'autres assistants peuvent appeler.
Ce qu'on apprend : les cinq exercices précédents ajoutent un
service à la fois. Celui-ci en ajoute une famille entière. C'est le moment où votre bot
cesse d'être un exercice et devient une pièce d'un ensemble plus grand.