Le parcours

Objectif : une page blanche qui s'affiche, avec les trois fichiers correctement reliés entre eux.

À faire

1. Crée ton dossier de travail et tes trois fichiers (.html, .css, .js). À toi de choisir les noms et l'organisation.
2. Écris le squelette HTML minimal, puis relie la feuille de style et le script.
3. Ouvre la page dans le navigateur, puis la console (F12).
4. Vérifie que les trois fichiers sont bien chargés : un texte visible dans le HTML, une couleur de fond dans le CSS, un console.log dans le JS.

Comment tu sais que c'est bon

• Je vois mon texte, ma couleur de fond et mon message dans la console.
• Si l'un des trois manquait, j'ai su trouver pourquoi dans l'onglet « Réseau » de la console.
• Je sais dire en une phrase à quoi sert chacun des trois fichiers.

Ressources

• Structure d'un document HTMLMDN
• console.log()MDN

Objectif : tout le HTML de l'application, sans une seule ligne de JavaScript.

À faire

Écris le HTML de : un titre, un formulaire de recherche (un champ texte et un bouton), et une zone vide destinée à recevoir le résultat.

Questions à te poser

Ce sont elles qui font la différence entre du HTML et du bon HTML.

• Pourquoi un <form> plutôt qu'un simple <input> et un <div> cliquable ?
• Comment un utilisateur qui n'a pas de souris valide-t-il ta recherche ?
• Un champ de saisie sans <label> : qu'est-ce que ça change pour quelqu'un qui utilise un lecteur d'écran ?
• Le navigateur peut-il refuser tout seul une saisie vide ou trop courte, sans JavaScript ?

Comment tu sais que c'est bon

• Je peux taper une ville et valider avec la touche Entrée uniquement, sans toucher la souris.
• Mon champ de saisie a un label correctement associé.
• La page se recharge quand je valide : je sais que c'est normal à ce stade et je le réglerai à l'étape 6.

Ressources

• L'élément <form>MDN
• L'élément <input> : regarde les attributs required, minlength, placeholderMDN
• L'élément <label>MDN
• Les titres <h1> à <h6>MDN
• Les formulaires : guide completMDN

Objectif : que ce soit propre et lisible. Pas beau. Propre.

À faire

Centre le contenu, donne-lui une largeur maximale, aère (marges, espacements), choisis une palette de trois ou quatre couleurs maximum, et prévois des styles pour les quatre états du résultat : accueil, chargement, erreur, succès.

Questions à te poser

• Comment centrer un bloc horizontalement dans la page ? (il y a plusieurs réponses, et elles ne se valent pas)
• Comment aligner ton champ et ton bouton côte à côte ?
• Est-ce que ton bouton a l'air cliquable au survol ?
• Voit-on clairement où est le focus quand on navigue au clavier ?

Comment tu sais que c'est bon

• Quelqu'un qui ne connaît pas mon projet comprend en un coup d'œil où taper et sur quoi cliquer.
• En naviguant à la touche Tab, je vois toujours où je suis.
• J'ai respecté les 45 minutes (ou je suis passé à la suite sans avoir fini).

Ressources

• Flexbox : pour aligner tes élémentsMDN
• Les variables CSS : pour ne pas répéter tes couleurs partoutMDN

Objectif : savoir exactement quelles données tu vas recevoir, et où elles se trouvent. Zéro ligne de code à cette étape.

Il te faut deux appels successifs : l'API météo ne comprend pas les noms de ville, elle ne parle qu'en coordonnées GPS.

À faire

1. Sur la doc du géocodage, construis l'URL qui cherche la ville « Rodez », limitée à 1 résultat, en français. Colle-la dans ton navigateur.
2. Sur la doc météo, la page génère une URL en bas quand tu coches des options. Coche les variables current : température à 2 m, code météo, vitesse du vent à 10 m, humidité relative. Récupère l'URL générée, remplace les coordonnées par celles de Rodez, colle-la dans ton navigateur.
3. Regarde les deux JSON obtenus. Ils n'ont pas du tout la même forme : l'un renvoie un tableau de résultats, l'autre un objet unique.
4. Écris noir sur blanc, dans ton journal, le chemin exact pour atteindre la latitude dans le premier JSON et la température dans le second. Quelque chose comme truc.machin[0].bidule.
5. Cherche dans la doc météo le tableau « WMO Weather interpretation codes ». La météo n'est pas renvoyée en toutes lettres mais sous forme d'un nombre : tu devras traduire ces nombres en texte et en pictogramme.

Comment tu sais que c'est bon

• Sans regarder, je peux dire : « pour avoir la température, je pars de la réponse et je vais chercher… »
• J'ai testé le géocodage avec name=zzzzzz et je sais ce que renvoie l'API : la réponse est plus piégeuse qu'elle n'en a l'air.
• J'ai noté les deux chemins d'accès dans mon journal de bord.

Ressources

• Qu'est-ce que le JSONMDN
• API de géocodageOpen-Meteo
• API météo et codes WMOOpen-Meteo

Objectif : une fonction qui prend un nom de ville et renvoie ses coordonnées : testée dans la console avant d'être branchée à la page.

À faire

Écris une fonction dédiée qui :

• construit l'URL avec ses paramètres ;
• appelle l'API ;
• vérifie que la réponse est bien un succès avant de l'exploiter ;
• transforme la réponse en objet JavaScript ;
• renvoie un objet simple et propre (nom, pays, latitude, longitude), ou une valeur signalant clairement « ville introuvable ».

Notions à aller chercher, dans cet ordre

• fetch() ne renvoie pas des données mais une promesse : comprends ce mot avant d'écrire quoi que ce soit.
• async / await : le moyen d'attendre une promesse sans s'arracher les cheveux.
• Il y a deux attentes successives dans un appel fetch : l'arrivée de la réponse, puis la lecture de son contenu. Beaucoup d'erreurs de débutant viennent d'en oublier une.
• Une réponse reçue n'est pas forcément une réponse réussie : une erreur 404 est une réponse parfaitement reçue.
• Pour construire ton URL, préfère l'objet URL à la concaténation de chaînes, et cherche pourquoi. Indice : « Saint-Étienne », et l'espace dans « Le Mans ».

Comment tu sais que c'est bon

Dans la console du navigateur, tu appelles ta fonction à la main :

• Avec une ville existante → un objet avec des coordonnées plausibles (vérifie sur une carte que tu n'es pas au milieu de l'Atlantique).
• Avec "zzzzzz" → ma valeur « introuvable », et non une erreur qui casse tout.
• Je sais pourquoi une fonction async appelée dans la console affiche Promise {…}, et comment en voir le contenu.

Ressources

• Utiliser fetchMDN
• Référence de fetch()MDN
• Les promessesMDN
• asyncMDN
• awaitMDN
• response.okMDN
• response.json()MDN
• Construire une URL proprementMDN
• Les paramètres d'URLMDN

Objectif : une deuxième fonction, qui prend une latitude et une longitude et renvoie les conditions actuelles.

C'est le même exercice que l'étape 4, en plus court. Si tu y passes une heure, c'est que l'étape 4 n'était pas comprise : relis-la plutôt que d'avancer.

Comment tu sais que c'est bon

• Dans la console, ma fonction appelée avec les coordonnées de Rodez renvoie une température cohérente avec n'importe quel site météo au même moment.
• Je peux justifier mon choix d'avoir mis (ou non) du code en commun entre mes deux fonctions.

Objectif : que ça marche pour de vrai, depuis la page.

À faire

Écoute la validation du formulaire, et enchaîne : afficher le chargement → chercher la ville → si elle n'existe pas, afficher l'erreur et s'arrêter là → sinon chercher la météo → afficher le résultat. Et prévois le cas où tout part en vrille : réseau coupé, API en panne.

Points d'attention

• Par défaut, valider un formulaire recharge la page. Il faut l'en empêcher.
• Pendant le chargement, un utilisateur impatient peut cliquer cinq fois. Que se passe-t-il ? Regarde l'onglet Réseau pendant que tu spammes le bouton.
• « La ville n'existe pas » et « le réseau est coupé » sont deux erreurs différentes et méritent deux messages différents. La première est prévisible et normale ; la seconde est accidentelle.
• L'utilisateur voit un message compréhensible ; toi, tu veux le détail technique en console pour déboguer. Les deux, pas l'un ou l'autre.

Comment tu sais que c'est bon

Teste les quatre cas, dans cet ordre :

• Une ville qui existe → la météo s'affiche.
• Une ville inventée (azerty) → message d'erreur clair, pas de plantage.
• Un champ vide ou d'une seule lettre → rien ne part en réseau.
• Wifi coupé → un message compréhensible s'affiche, et l'application redevient utilisable une fois le wifi rétabli.
• Les quatre donnent quatre affichages distincts, et la console reste propre (aucune erreur rouge non gérée).

Ressources

• addEventListener()MDN
• preventDefault()MDN
• getElementById()MDN
• try…catchMDN
• Si tu vois une erreur « CORS »MDN

Objectif : la carte météo, avec le bon pictogramme.

À faire

1. Construis ta table de correspondance entre les codes météo WMO et un couple « libellé en français + pictogramme ». Mets-en au moins une douzaine, en couvrant les cas courants : dégagé, nuageux, brouillard, pluie, neige, averses, orage.
2. Génère le HTML de la carte et injecte-le dans ta zone de résultat.
3. Prévois le cas où l'API renvoie un code que tu n'as pas dans ta table. Ça arrivera. L'application ne doit ni planter ni afficher « undefined ».

Questions à te poser

• La température brute ressemble à 18.7. Est-ce ce que tu veux afficher ?
• Ta zone de résultat contient déjà quelque chose (l'état précédent). Que devient-il quand tu écris le nouveau contenu ?

Comment tu sais que c'est bon

• Je cherche cinq villes dans des climats différents (Paris, Marrakech, Reykjavik, Singapour, Ushuaia) et à chaque fois le pictogramme et le texte correspondent à la météo réelle : vérifiée sur un site météo classique.
• Un code météo absent de ma table n'affiche jamais « undefined » et ne casse rien.
• Je sais expliquer avec mes mots le risque d'injection HTML, et ce que j'ai mis en place contre.

Ressources

• innerHTMLMDN
• textContentMDN
• XSS : l'injection de codeMDN
• Les littéraux de gabarit (backticks)MDN
• L'opérateur ?? (valeur par défaut)MDN
• L'opérateur ?. (accès sécurisé)MDN
• Math.round()MDN
• aria-live : annoncer les changements aux lecteurs d'écranMDN

Objectif : relire ton propre code comme si c'était celui de quelqu'un d'autre.

• Reste-t-il des console.log de débogage ? Du code commenté ? Des variables inutilisées ?
• Tes noms de variables et de fonctions se comprennent-ils sans lire leur contenu ? (data2, x, truc → à renommer)
• As-tu des morceaux copiés-collés à trois endroits ?
• Tes commentaires expliquent-ils pourquoi, ou juste ce que le code dit déjà ?
• Reprends tous les critères des étapes précédentes et refais-les une dernière fois : tu as beaucoup modifié depuis.

Comment tu sais que c'est bon

• Mon code est nettoyé : plus de logs de débogage, plus de code mort, des noms clairs.
• J'ai refait tous les tests des étapes précédentes après mes modifications.
• J'ai réussi le test des cinq lignes au hasard.
• J'ai rempli le bilan de fin de journée dans mon journal de bord.