Développement web module 4 : accessible, rapide et en ligne

Jour 43 — Pourquoi l'accessibilité

Objectif : comprendre ce que l'accessibilité veut dire, pour qui, et pourquoi elle vous concerne.

Théorie (20 min)

L'accessibilité (a11y dans le jargon — « a », onze lettres, « y ») consiste à construire des pages utilisables par tous : les personnes aveugles ou malvoyantes qui naviguent avec un lecteur d'écran (un logiciel qui lit la page à voix haute), celles qui ne peuvent pas utiliser de souris et font tout au clavier, celles qui distinguent mal les contrastes, celles dont la connexion ou la machine est lente — et, un jour de fatigue ou de main en écharpe, vous.

Le chiffre qui change le regard : l'OMS estime à plus d'un milliard les personnes vivant avec un handicap. Mais l'accessibilité n'est pas une charité faite à une minorité : une page accessible est une page mieux construite — plus claire au clavier, mieux comprise des moteurs de recherche, plus lisible au soleil sur un téléphone. Les bonnes pratiques de ces six séances profitent à 100 % des visiteurs.

La bonne nouvelle : le HTML est accessible par défaut. Un titre est un titre, un bouton est un bouton, un label est relié à son champ — les lecteurs d'écran comprennent tout ça sans effort, parce que vous avez utilisé les bonnes balises depuis le jour 3. L'accessibilité se casse quand on détourne le HTML (un div qui fait semblant d'être un bouton) ou qu'on l'oublie (une image sans alt). Ce module est donc surtout un approfondissement de ce que vous faites déjà, pas une discipline nouvelle.

Les règles de référence sont les WCAG (Web Content Accessibility Guidelines), trois niveaux de conformité : A, AA, AAA. Visez AA : c'est le niveau que demandent la plupart des lois (en France, le RGAA pour le service public).

Pratique (30 min)

1. Faites l'expérience clavier : ouvrez votre page moi.html, posez la souris loin de vous, et naviguez avec Tab (élément suivant), Maj+Tab (précédent) et Entrée (activer). Critère de réussite : vous atteignez et activez chaque lien et chaque champ — et vous VOYEZ quel élément est actif (un cadre de focus).
2. Fermez les yeux et continuez trente secondes. Frustrant ? Bienvenue dans le quotidien d'un utilisateur de lecteur d'écran quand la page est mal construite.
3. Si votre système a un lecteur d'écran intégré (Narrateur sous Windows, VoiceOver sous macOS avec Cmd+F5), activez-le cinq minutes sur votre page et écoutez ce qu'il annonce : les titres, les repères, les labels de vos champs.
4. Au carnet : listez trois moments où l'expérience a accroché — ce sont vos premiers défauts d'accessibilité, vous les réparerez cette semaine.

Tips agent : « liste les problèmes d'accessibilité de ce HTML » donne une première passe honnête. Piège : il ne peut pas TESTER (pas de clavier, pas de lecteur d'écran) — il lit, il ne vit pas la page. Preuve : refaites le parcours clavier vous-même ; les problèmes qu'il cite doivent correspondre à ce que vous avez vécu.

Synthèse (10 min)

Trois lignes : ce qu'est un lecteur d'écran, pour qui l'accessibilité profite, ce que sont les WCAG. Puis refaites le parcours Tab sur une page que vous aimez, les yeux ouverts.

Jour 44 — HTML sémantique : les repères

Objectif : exploiter les repères (landmarks) et la hiérarchie des titres comme un plan lisible par une machine.

Théorie (20 min)

Jour 12, vous avez rencontré header, nav, main, footer et leurs cousines. Aujourd'hui, voyez ce qu'un lecteur d'écran en fait : il propose à l'utilisateur des raccourcis de navigation — « liste des repères » (aller directement au contenu principal, au menu), « liste des titres » (la table des matières), « liste des liens ». Un utilisateur voyant balaie la page des yeux en une seconde ; ces listes sont l'équivalent pour qui ne voit pas. Sans repères, il n'y a qu'un seul mode de lecture : tout, dans l'ordre, du début.

D'où trois règles concrètes :

• Un seul <main> par page, qui contient le contenu — pas le header global, pas le footer.
• Une hiérarchie de titres sans trou : h1 puis h2 puis h3, jamais h1 → h4 parce que « le h4 est plus joli » (la taille se règle en CSS ; la balise porte le sens).
• Si une page a plusieurs <nav> (menu principal + fil d'Ariane), nommez-les : <nav aria-label="Principal"> — le lecteur d'écran annoncera « navigation Principal » au lieu de deux « navigation » indiscernables.

Test maison, sans outil : relisez votre page en ne lisant QUE les titres. Si l'histoire se comprend, votre structure est bonne. C'est exactement ce qu'entend l'utilisateur du lecteur d'écran.

Pratique (30 min)

1. Ouvrez l'inspecteur sur votre page et vérifiez vos repères : un header, un nav, un seul main, un footer. Réparez ce qui manque.
2. Faites le test des titres : notez sur papier uniquement vos h1, h2, h3 dans l'ordre. Le plan tient-il debout ? Un niveau sauté ? Corrigez la balise, et ajustez la taille en CSS si le rendu change.
3. Critère de réussite : votre page a un h1 unique, aucun saut de niveau, et les quatre repères.
4. Si votre page a plusieurs nav, nommez-les avec aria-label.
5. Relancez le validateur W3C : zéro erreur.

Tips agent : « vérifie la hiérarchie des titres de cette page : [collez] » est fiable — c'est du texte, il sait lire. Piège : il peut confondre esthétique et structure (« mets un h4 ici, plus discret »). Preuve : le plan que VOUS avez noté sur papier doit rester cohérent après sa relecture.

Synthèse (10 min)

Trois lignes : ce que sont les raccourcis de navigation, les trois règles, le test des titres. Puis faites le test des titres sur un site d'actualités.

Jour 45 — Textes alternatifs et liens explicites

Objectif : écrire de bons alt et de bons textes de liens — les deux réflexes les plus rentables de l'accessibilité.

Théorie (20 min)

Le alt du jour 7 mérite une séance entière, car c'est le défaut le plus répandu du web. La méthode : demandez-vous ce que l'image apporte à cet endroit précis. Trois cas :

• Image d'information (photo de l'article, schéma) : décrivez l'information. « Un chat » est faible ; « un chat roux endormi sur un clavier rétroéclairé » porte la même chose que l'image.
• Image-lien ou image-bouton : le alt dit la DESTINATION ou l'ACTION, pas l'image : « Retour à l'accueil », pas « flèche bleue ».
• Image décorative : alt="" — vide, mais présent. Sans l'attribut du tout, certains lecteurs d'écran lisent le nom du fichier : « IMG underscore 4032 point jay pé gue ».

Interdits : commencer par « image de » ou « photo de » (le lecteur d'écran annonce déjà « image »), et les pavés : un alt dépasse rarement une phrase.

Même logique pour les liens : le texte du lien doit suffire, hors contexte. Test : un lecteur d'écran peut lister tous les liens d'une page. « En savoir plus », « cliquez ici », « lien » — la liste ne dit rien. « Lire le guide des contrastes » se suffit. Et n'englobez jamais un paragraphe entier dans un lien : une phrase est un maximum confortable.

Pratique (30 min)

1. Passez en revue chaque image de vos pages : pour chacune, classez-la (information / action / décorative) et réécrivez son alt selon la règle du cas.
2. Passez en revue chaque lien : lisez UNIQUEMENT les textes de liens de la page, à voix haute. Chacun doit annoncer sa destination. Corrigez les « cliquez ici ».
3. Critère de réussite : les deux tests passent — les alt décrivent l'apport, les liens décrivent la destination.
4. Exercice inverse : prenez trois images d'un site d'actualités, couvrez l'écran et faites-vous lire les alt par quelqu'un (ou lisez le code source). Lesquels seuls suffisent ?

Tips agent : « propose un alt pour chaque image de ce HTML, selon son contexte dans la page » — collez le HTML ET décrivez chaque image, il ne les voit pas. Piège : sans description, il écrit « photo illustrative ». Preuve : le test des yeux fermés du jour 7 reste votre juge.

Synthèse (10 min)

Trois lignes : les trois cas d'alt, les deux interdits, le test de la liste des liens. Puis réécrivez un mauvais alt de mémoire en bon alt.

Jour 46 — Formulaires accessibles et focus visible

Objectif : rendre vos formulaires annonçables par un lecteur d'écran et le focus toujours visible.

Théorie (20 min)

Vos formulaires ont déjà leurs labels reliés (jour 9) — c'est 80 % du travail. Ce qui reste :

• Le focus visible. Quand on navigue à Tab, l'élément actif porte un cadre (l'outline). Des années de design ont vu des feuilles de style faire outline: none parce que c'était « moche » — privant les utilisateurs clavier de tout repère. La règle moderne : ne supprimez jamais l'outline sans la remplacer ; mieux, embellissez-la avec :focus-visible, qui ne s'applique qu'à la navigation clavier : a:focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }.
• Les messages d'erreur en texte. Un champ en rouge ne suffit pas : qui ne distingue pas le rouge ne voit rien. L'erreur s'écrit : « Adresse invalide : il manque le @ », à côté du champ.
• Les instructions avant le champ. « 8 caractères minimum » se lit AVANT de taper, pas après l'erreur.
• required et type sont vos alliés : <input type="email" required> donne une validation native, annoncée, gratuitement.

Pratique (30 min)

1. Ajoutez la règle :focus-visible à votre CSS, rechargez, naviguez à Tab : critère de réussite : à chaque Tab, vous voyez nettement quel élément est actif, y compris vos boutons et votre bascule de mode sombre.
2. Dans votre formulaire, ajoutez required au champ prénom et un type="email" au champ email. Envoyez vide : le navigateur affiche un message natif, au bon endroit, dans la langue de l'utilisateur.
3. Ajoutez un message d'erreur textuel à la validation JavaScript du jour 38 : au lieu de ne rien faire quand le champ est vide, affichez « Le prénom est requis » dans un <p> à côté du champ (et videz ce message quand la saisie redevient bonne).
4. Testez l'ensemble au clavier uniquement : remplir, se tromper, lire l'erreur, corriger, envoyer.

Tips agent : « rends ce formulaire accessible : labels, erreurs en texte, focus visible » est un bon ordre. Piège : il peut remplacer l'outline par un subtil changement de couleur invisible au soleil. Preuve : le test Tab les yeux plissés — le focus doit sauter aux yeux.

Synthèse (10 min)

Trois lignes : pourquoi on ne supprime pas l'outline, ce qu'est un message d'erreur accessible, ce que donnent required et type. Puis testez le formulaire à Tab sans notes.

Jour 47 — Contrastes et navigation au clavier

Objectif : mesurer le contraste de vos couleurs et garantir que tout se fait au clavier.

Théorie (20 min)

Le contraste est le rapport de luminosité entre le texte et son fond, de 1:1 (invisible) à 21:1 (noir sur blanc). Les WCAG niveau AA exigent 4,5:1 pour le texte courant et 3:1 pour le grand texte (titres de 24 px et plus). Le gris moyen sur blanc, favori des maquettes, est presque toujours sous la barre — mesurez, ne devinez pas : l'inspecteur affiche le ratio quand vous cliquez un carré de couleur, et le vérificateur de contraste de WebAIM fait le calcul entre deux codes couleur.

Deuxième règle du jour : tout ce qui se fait à la souris se fait au clavier. Les éléments natifs y pourvoient : un <button> est atteignable à Tab et s'active à Entrée ET à Espace ; un <a> s'active à Entrée. Le piège est le div déguisé en bouton : un <div onclick=...> n'est ni atteignable ni activable au clavier, et muet pour le lecteur d'écran. La règle d'or : si ça se clique, c'est un button ou un a.

Et votre propre JavaScript peut casser le clavier : un menu qui ne s'ouvre qu'au survol de la souris est fermé à qui navigue à Tab. Vérifiez chaque interaction que vous ajoutez.

Pratique (30 min)

1. Mesurez vos couples de couleurs (texte/fond, accent/fond, texte/carte) dans WebAIM Contrast Checker, en mode clair ET en mode sombre — les deux thèmes se mesurent séparément.
2. Corrigez ce qui échoue en ajustant vos variables : assombrir un texte, éclaircir un fond. Critère de réussite : tous vos couples texte/fond passent AA.
3. Le grand test clavier de votre page complète : atteindre et activer chaque lien, bouton, champ, la bascule de thème, ajouter une tâche, en supprimer une — tout à Tab et Entrée.
4. Notez chaque interaction impossible au clavier et réparez-la (le coupable est presque toujours un div qui fait semblant d'être un bouton).

Tips agent : « ces deux couleurs passent-elles WCAG AA ? » est un calcul, pas une opinion — l'agent calcule un rapport, mais vérifiez-le sur WebAIM : il peut se tromper dans les multiplications. Preuve : le ratio mesuré par l'outil, pas celui annoncé.

Synthèse (10 min)

Trois lignes : les seuils 4,5 et 3, la règle du div-bouton, ce qu'il faut tester à Tab. Puis re-mesurez une couleur corrigée de mémoire du seuil.

Jour 48 — ARIA : quand (ne pas) l'utiliser

Objectif : savoir ce qu'est ARIA, et surtout quand s'en passer.

Théorie (20 min)

ARIA (Accessible Rich Internet Applications) est un jeu d'attributs HTML qui décrivent aux technologies d'assistance ce que le HTML ne peut pas exprimer. Exemples : aria-label (un nom pour un élément sans texte, comme un bouton « × »), aria-expanded="true" (ce panneau est ouvert), aria-current="page" (ce lien est la page courante dans le menu).

La première règle d'ARIA, officielle et à retenir par cœur : « N'utilisez pas ARIA si une balise HTML native fait le travail. » Un <button> est un bouton ; un <div role="button" tabindex="0"> essaie de le réinventer et oubliera toujours quelque chose (le clavier, le focus, l'annonce). ARIA ajoute des informations ; il n'ajoute JAMAIS de comportement — role="button" ne rend pas un div cliquable au clavier, il ne fait que le décrire.

Trois usages légitimes à votre niveau :

• aria-label sur un bouton dont le seul contenu est un symbole (« × », une icône) : <button aria-label="Fermer">×</button> ;
• aria-current="page" sur le lien du menu qui pointe la page en cours ;
• nommer un repère quand il y en a plusieurs (jour 44).

Le reste (arborescences, onglets, boîtes de dialogue) vous attendra quand vous construirez des composants complexes — et là, des bibliothèques testées font mieux que du ARIA maison.

Pratique (30 min)

1. Ajoutez aria-current="page" au lien de navigation qui correspond à la page en cours, sur chacune de vos pages (et un peu de CSS : [aria-current="page"] { font-weight: bold; } — l'attribut sert aussi de sélecteur).
2. Si votre todo list a des boutons « × », donnez-leur un aria-label="Supprimer cette tâche" — généré dans le JavaScript, au moment du createElement.
3. Critère de réussite : inspectez vos boutons : chaque bouton sans texte lisible a un aria-label, et chaque page marque son lien courant.
4. Chasse au div-bouton : relisez votre code, tout élément qui réagit au clic est-il un vrai <button> ou <a> ? Sinon, convertissez — c'est presque toujours plus court que l'imitation ARIA.

Tips agent : « ajoute l'ARIA nécessaire à ce composant » est un ordre dangereux : les modèles saupoudrent. Piège : trois attributs ARIA là où une balise native suffit. Preuve : exigez la justification de CHAQUE attribut — « quelle balise native aurait fait ça ? » ; si la réponse en nomme une, utilisez-la.

Synthèse (10 min)

Trois lignes : la première règle d'ARIA, les trois usages légitimes, pourquoi role ne suffit pas. Puis ajoutez aria-current de mémoire sur une page neuve.

Jour 49 — Performance : les images

Objectif : mesurer le poids d'une page et réduire celui des images, premier poste de poids du web.

Théorie (20 min)

La performance se mesure en octets et en secondes. Chaque visiteur télécharge votre page entière — et les images pèsent en général plus que tout le reste réuni : une photo de smartphone fait 3 à 8 Mo, là où une page HTML complète avec CSS et JS tient en quelques dizaines de ko. Sur une connexion mobile moyenne, 5 Mo, c'est plusieurs secondes d'écran blanc, et la moitié des visiteurs partis.

Trois gestes suffisent à votre échelle :

• Redimensionner : afficher une image de 400 px de large ? Enregistrez-la à 400 px de large (ou 800 pour les écrans denses), pas à 4000. L'explorateur de fichiers ou un outil gratuit comme Squoosh (dans le navigateur, rien à installer) redimensionne et compresse en glisser-déposer.
• Choisir le format : JPEG ou WebP pour les photos, PNG pour les images avec transparence ou du texte, SVG (vectoriel, poids minuscule) pour les logos et icônes.
• Le chargement différé : <img loading="lazy"> dit au navigateur de ne télécharger l'image que quand elle approche de l'écran. Gratuit, natif, sur toutes les images qui ne sont pas visibles dès l'ouverture.

Mesurer avant et après, toujours : l'onglet Réseau des outils de dev affiche le poids total de la page en bas. C'est votre balance.

Pratique (30 min)

1. Ouvrez l'onglet Réseau, rechargez votre page, notez le poids total et celui de chaque image.
2. Passez votre plus grosse image dans Squoosh : redimensionnez à sa taille d'affichage réelle, convertissez en WebP, comparez les poids.
3. Remplacez le fichier, ajoutez loading="lazy" aux images qui ne sont pas en haut de page. Critère de réussite : rechargez avec l'onglet Réseau ouvert : le poids total a baissé, et les images du bas ne se chargent qu'au défilement (regardez les requêtes arriver au fur et à mesure).
4. Notez au carnet : poids avant / après. Ce réflexe mesure → corriger → re-mesurer est celui des pros.

Tips agent : « quelles optimisations d'images pour cette page ? » — collez le HTML et le poids de chaque image. Piège : il peut conseiller des outils compliqués (srcset, CDN) avant le simple redimensionnement. Preuve : la mesure avant/après dans VOTRE onglet Réseau, pas ses estimations.

Synthèse (10 min)

Trois lignes : les trois gestes, quel format pour quel usage, où lire le poids total. Puis compressez une autre image de mémoire.

Jour 50 — Performance : scripts et mesure

Objectif : comprendre ce qui ralentit le chargement et auditer une page avec Lighthouse.

Théorie (20 min)

Après les images, les scripts. Au jour 29, vous avez mis votre <script> en fin de body pour que le HTML existe avant lui. L'attribut defer permet de le remettre dans le head avec la même garantie : le navigateur télécharge le script en parallèle du HTML et ne l'exécute qu'une fois la page lue :

<script src="script.js" defer></script>

Les deux placements sont valables ; defer est la forme moderne. Ce qui compte : ne jamais bloquer l'affichage de la page en attendant un script.

Ensuite, mesurez plutôt que deviner. Lighthouse, l'audit intégré aux outils de développement de Chrome et Edge (onglet Lighthouse, ou Ctrl+Shift+P puis « Lighthouse »), note la page de 0 à 100 sur quatre familles : performance, accessibilité, bonnes pratiques, référencement — et surtout, il LISTE les problèmes précisément, avec la ligne ou le fichier en cause. Sous Firefox, l'onglet Réseau et l'inspecteur d'accessibilité couvrent l'essentiel.

Le réflexe professionnel : lancez l'audit AVANT de toucher au code (sinon vous ne saurez pas ce que votre correction a changé), lisez les problèmes dans l'ordre où il les donne, corrigez le premier, relancez.

Pratique (30 min)

1. Passez votre balise script dans le head avec defer, rechargez : tout doit fonctionner exactement pareil (sinon, cherchez pourquoi — en général un script qui suppose le body déjà lu).
2. Lancez Lighthouse sur votre page (navigation, mode par défaut). Critère de réussite : vous savez lire vos quatre notes et développer le premier problème listé.
3. Corrigez le premier problème de performance ET le premier d'accessibilité qu'il signale (souvent : un contraste, un alt, une image sans dimensions).
4. Relancez l'audit : les notes bougent. Notez avant/après au carnet.
5. Au carnet également : les notes changent un peu d'un audit à l'autre (réseau, machine) — on regarde l'ordre de grandeur, pas le dixième de point.

Tips agent : « voici mon rapport Lighthouse : [collez la liste des problèmes] — explique le premier et propose la correction minimale » marche bien. Piège : ne lui demandez pas de deviner la note, demandez-lui d'expliquer un problème MESURÉ. Preuve : relancez Lighthouse après la correction — la note bouge ou pas, elle ne ment pas.

Synthèse (10 min)

Trois lignes : ce que fait defer, les quatre familles de Lighthouse, le réflexe mesure-correction-mesure. Puis relancez un audit de tête : savez-vous où cliquer sans chercher ?

Jour 51 — Git : photographier son travail

Objectif : initialiser un dépôt Git et enregistrer vos premières versions (commits).

Théorie (20 min)

Git est un logiciel qui photographie votre dossier de travail à des moments choisis, et garde toutes les photos : vous pouvez revenir à n'importe laquelle, comparer, comprendre ce qui a changé. Chaque photo s'appelle un commit, avec un message qui dit pourquoi (« ajoute la page contact »). Le dossier suivi par Git s'appelle un dépôt (repository).

C'est l'assurance-vie du développeur : casser quelque chose n'est plus grave, la photo d'avant existe. Et c'est la porte vers la publication : GitHub, demain, est un serveur qui héberge des dépôts Git.

Trois commandes font 90 % du quotidien (à taper dans le terminal, dans le dossier du projet) :

git init                          # transforme le dossier en dépôt (une fois)
git add .                         # prépare tous les fichiers pour la photo
git commit -m "première page"     # prend la photo, avec son message

git status montre à tout moment ce qui a changé depuis la dernière photo ; git log --oneline liste les photos. Le terminal est au programme aujourd'hui : « Terminal » ou « Invite de commandes » sous Windows, « Terminal » sous macOS et Linux — et la commande cd pour se placer dans le dossier (cd Documents/devweb).

Pratique (30 min)

1. Installez Git si besoin (git-scm.com/downloads), puis vérifiez : git --version.
2. Présentez-vous à Git (une fois pour toutes) : git config --global user.name "Votre Nom" et git config --global user.email "votre@email" — le nom signera chaque commit.
3. Dans le terminal, placez-vous dans un dossier capstone fraîchement créé (il accueillera votre projet final) et faites git init.
4. Copiez-y vos pages, puis git add . et git commit -m "premiers fichiers du site". Critère de réussite : git log --oneline affiche votre commit.
5. Modifiez un fichier, faites git status (il voit le changement), git add ., un second commit. git log en montre deux. Changez encore, et cette fois ne commitez pas : git diff montre les lignes modifiées depuis la dernière photo.

Tips agent : « explique ce que git status me dit : [collez la sortie] » est un bon réflexe au début. Piège : ne laissez jamais un agent taper git à votre place ce mois-ci — le geste doit entrer par VOS mains. Preuve : git log montre VOS commits, dans VOTRE terminal.

Synthèse (10 min)

Trois lignes : ce qu'est un dépôt, un commit, la différence add/commit. Puis faites un troisième commit sans notes.

Jour 52 — GitHub : publier son dépôt

Objectif : créer un compte GitHub, y créer un dépôt, et y envoyer votre code.

Théorie (20 min)

Git est local : vos photos vivent dans votre dossier. GitHub est un serveur qui héberge des dépôts Git : sauvegarde en ligne, accès depuis n'importe où, et — demain — hébergement gratuit de site statique. Le compte gratuit suffit à tout ce parcours.

Le vocabulaire : pousser (push) envoie vos commits locaux vers GitHub ; tirer (pull) récupère ce qui est en ligne. Un dépôt GitHub public est lisible par tout le monde — on n'y met jamais ni mot de passe, ni clé, ni donnée personnelle. Votre site statique ne contient de toute façon que du HTML, du CSS et du JS, publics par nature.

Pour pousser, GitHub doit savoir que c'est vous : le mot de passe du site ne suffit plus pour Git. Deux chemins simples : créer un personal access token (dans les réglages GitHub : Settings → Developer settings → Personal access tokens → Tokens (classic), cochez la portée « repo »), que Git vous demandera à la place du mot de passe ; ou installer GitHub CLI (gh), dont la commande gh auth login fait la poignée de main dans le navigateur. La marche détaillée est dans la documentation GitHub (en français) — gardez-la sous la main, les écrans évoluent.

Pratique (30 min)

1. Créez votre compte sur github.com (gratuit).
2. Créez un dépôt vide, sans rien cocher (pas de README : vous poussez un dépôt déjà commencé). Nom suggéré : mon-site.
3. Reliez votre dossier au dépôt : git remote add origin https://github.com/VOTRE-NOM/mon-site.git puis git push -u origin main (si votre branche s'appelle master : git branch -M main d'abord).
4. Critère de réussite : rafraîchissez la page GitHub du dépôt : vos fichiers y sont, avec votre message de commit.
5. Faites une modification, committez, poussez à nouveau (un simple git push suffit désormais) : GitHub affiche le nouveau commit.

Tips agent : « mon push est refusé avec cette erreur : [collez] » — les erreurs d'authentification GitHub sont ses classiques. Piège : ne collez JAMAIS votre token dans un prompt, même à un agent local : collez le message d'erreur seul. Preuve : le push réussit chez VOUS, le token reste dans votre gestionnaire de mots de passe.

Synthèse (10 min)

Trois lignes : local vs distant, push et pull, ce qu'on ne met jamais dans un dépôt public. Puis refaites un commit + push sans notes.

Jour 53 — GitHub Pages : le site en ligne

Objectif : publier votre site sur une vraie URL avec GitHub Pages.

Théorie (20 min)

GitHub Pages est l'hébergement gratuit de sites statiques de GitHub : il prend les fichiers d'un dépôt et les sert en HTTP. « Statique » veut dire : pas de serveur qui calcule — des fichiers HTML, CSS, JS servis tels quels. C'est exactement ce que vous écrivez depuis le jour 2.

La mise en ligne : dans la page du dépôt, Settings → Pages → « Deploy from a branch », choisissez la branche main, dossier / (root), Save. Une à deux minutes plus tard, votre site est en ligne à l'adresse https://VOTRE-NOM.github.io/mon-site/. Chaque git push suivant met le site à jour tout seul — c'est votre premier déploiement continu.

Deux détails d'importance : le fichier d'accueil DOIT s'appeler index.html à la racine (c'est ce que le serveur sert pour l'adresse du dossier) ; et vos liens internes doivent être relatifs (href="contact.html", jamais href="file:///home/..." ni un chemin qui commence par / — votre site vit dans le sous-dossier /mon-site/ de l'adresse). C'est pour ça qu'on a appris les liens relatifs au jour 6.

Pratique (30 min)

1. Assurez-vous que votre page d'accueil s'appelle index.html et que vos liens internes sont relatifs. Committez, poussez.
2. Activez Pages comme ci-dessus, attendez une minute, ouvrez l'adresse. Critère de réussite : votre site s'affiche à son adresse publique, styles et images compris, et la navigation entre pages fonctionne en ligne.
3. Si le style manque : l'onglet Réseau montrera une 404 sur style.css — presque toujours un chemin absolu ou une faute de casse (Style.css vs style.css : un serveur Linux distingue les majuscules, votre Windows peut-être pas).
4. Modifiez un titre, committez, poussez, attendez une minute, rechargez avec Ctrl+F5 (rechargement sans cache) : la modification est en ligne.
5. Partagez l'adresse à quelqu'un. Votre travail est sur le web.

Tips agent : « ma page GitHub Pages affiche le HTML sans style » — l'agent répondra « chemin ou casse », et il aura raison neuf fois sur dix. Piège : il peut suggérer de tout réécrire avec des chemins absolus — ça casserait /mon-site/. Preuve : l'onglet Réseau, la 404 citée, la casse du fichier sur GitHub.

Synthèse (10 min)

Trois lignes : ce qu'est un site statique, le rôle d'index.html, pourquoi des liens relatifs. Puis notez l'URL de votre site dans le carnet, en haut.

Jour 54 — Finitions : favicon, meta, 404

Objectif : ajouter les détails qui font un site fini : icône d'onglet, description pour les moteurs, page 404.

Théorie (20 min)

Trois détails séparent « un fichier qui marche » d'un site soigné :

• Le favicon, la petite icône de l'onglet : un fichier favicon.ico (ou un PNG/SVG déclaré) à la racine : <link rel="icon" href="favicon.svg" type="image/svg+xml">. Le SVG fait une icône nette en quelques octets — un simple emoji ou initiale dans un carré coloré suffit.
• La meta description : la phrase que les moteurs de recherche et les aperçus de partage affichent sous votre titre : <meta name="description" content="Portfolio de …, développeuse web débutante : projets, parcours, contact.">. Une phrase honnête, unique par page.
• La page 404 : GitHub Pages sert un fichier 404.html à la racine quand l'adresse demandée n'existe pas. Une page d'erreur à votre main (« cette page n'existe pas — retour à l'accueil ») vaut mieux que l'écran brut du serveur.

Pendant qu'on est dans le <head> : vérifiez que chaque page a son propre <title> — c'est le nom de l'onglet, le titre du résultat de recherche, et la première chose qu'annonce un lecteur d'écran.

Pratique (30 min)

1. Créez un favicon.svg simple (un carré de votre couleur d'accent avec votre initiale en texte SVG), déclarez-le dans le head de chaque page.
2. Ajoutez la meta description à chaque page, avec une phrase propre à chacune.
3. Créez 404.html : même structure que vos pages, un message clair, un lien vers l'accueil.
4. Committez, poussez. Critère de réussite : l'icône apparaît dans l'onglet en ligne, et une adresse fausse de votre site affiche votre 404.
5. Relisez chaque page : un title unique, une description unique, la favicon. La finition est une question de liste, pas de talent.

Tips agent : « génère un favicon.svg simple : carré #1e5fa8, lettre A blanche centrée » — l'agent écrit du SVG lisible. Piège : vérifiez qu'il n'a pas mis un <script> dedans. Preuve : ouvrez le SVG dans le navigateur — vous devez voir l'icône, et son contenu doit tenir en quelques lignes lisibles.

Synthèse (10 min)

Trois lignes : les trois détails, où vit chacun, ce que GitHub Pages fait d'un 404.html. Puis ajoutez une meta description de mémoire.

Jour 55 — Capstone 1 : le plan du site

Objectif : concevoir votre projet final : un site personnel de trois pages, sur le papier d'abord.

Théorie (20 min)

Le capstone (projet de fin de parcours) : un site personnel de trois pages — Accueil, Projets, Contact — construit en réunissant tout le parcours. C'est le site que vous montrerez ; il remplacera ou enrichira ce que vous avez déjà en ligne.

Aujourd'hui, on n'écrit pas une ligne de code : on conçoit. Un projet qui démarre au clavier sans plan finit en impasse ; un projet qui démarre au crayon finit.

Le livrable du jour, sur papier ou dans votre carnet numérique :

1. Le plan des pages : pour chacune des trois pages, ses sections et leur ordre (ex. Accueil : présentation courte, trois projets en avant, appel à contact).
2. La maquette fil de fer : chaque page dessinée en rectangles étiquetés — un rectangle par section, pas de couleur, pas de texte réel. Le fil de fer (wireframe) fige la STRUCTURE avant le style.
3. La liste des composants réutilisables : le header/nav et le footer seront IDENTIQUES sur les trois pages — copiez-les, ne les réinventez pas ; la carte « projet » se répètera trois fois.
4. La fonctionnalité JavaScript : UNE, choisie : menu qui s'ouvre/se ferme sur mobile, filtre des projets par étiquette, ou la bascule sombre/clair. Une seule, bien faite.

Pratique (30 min)

1. Écrivez le plan des trois pages et dessinez les trois fils de fer.
2. Listez les fichiers à créer : index.html, projets.html, contact.html, style.css, script.js, les images.
3. Listez les critères du site fini : trois pages reliées, responsive (lisible au téléphone), accessible (Titres hiérarchisés, alt, focus visible, contrastes AA), la fonctionnalité JS, en ligne sur GitHub Pages, avec un README.
4. Critère de réussite : vous pouvez expliquer votre site en deux minutes à quelqu'un, plans en main.

Tips agent : « voici mon plan de site en trois pages : [collez] — qu'est-ce qui manque, qu'est-ce qui est trop ambitieux pour trois jours ? » est un excellent usage : un regard extérieur sur VOTRE plan. Piège : il proposera d'ajouter des pages et des animations. Preuve : tenez votre périmètre — trois pages, une fonctionnalité.

Synthèse (10 min)

Trois lignes : pourquoi le plan avant le code, ce qu'est un fil de fer, votre fonctionnalité JS choisie. Dormez dessus ; demain on construit.

Jour 56 — Capstone 2 : construire les pages

Objectif : construire les trois pages : structure sémantique commune, contenu, styles.

Théorie (20 min)

La méthode du jour : d'abord la charpente, ensuite le contenu, ensuite le style. En détail :

1. La page modèle : construisez UNE page complète — le squelette, le header/nav, le footer, le CSS branché, les variables, la police, la grille. C'est votre gabarit.
2. Dupliquez-la en index.html, projets.html, contact.html, puis adaptez le main de chacune. Header et footer identiques au caractère près : la navigation doit être au même endroit sur toutes les pages, c'est une règle d'accessibilité autant que de confort.
3. Le contenu d'abord laid : remplissez les trois pages de texte et d'images sans fignoler. Un site laid avec son vrai contenu se corrige ; un beau site vide n'avance pas.
4. Le style ensuite : cartes pour les projets, grille responsive, formulaire de contact accessible.

Committez après chaque étape qui marche (gabarit, trois pages, contenu, style) : quatre points de retour en arrière valent mieux qu'un.

Pratique (30 min)

1. Construisez la page modèle dans votre dossier capstone, dupliquez-la en trois pages.
2. Remplissez chaque main selon votre plan d'hier.
3. Appliquez le style : la grille de cartes projets, le formulaire accessible avec labels et erreurs en texte.
4. Critère de réussite : les trois pages se visitent en local par leurs liens, se lisent au téléphone (mode appareil), et le validateur W3C ne signale aucune erreur sur aucune.
5. Committez à chaque étape — vérifiez avec git log --oneline : au moins trois commits aujourd'hui.

Tips agent : ne déléguez pas la construction, c'est l'examen. En revanche : « relis cette page et liste les écarts avec les bonnes pratiques vues (sémantique, alt, contrastes) » en fin de séance. Piège : il re-corrigera ce qui n'est pas cassé. Preuve : n'acceptez que les défauts cités avec leur ligne.

Synthèse (10 min)

Trois lignes : la méthode gabarit-duplication, pourquoi le contenu avant le style, vos commits du jour. Demain : la page réagit.

Jour 57 — Capstone 3 : la fonctionnalité JavaScript

Objectif : ajouter la fonctionnalité interactive choisie au plan, accessible au clavier.

Théorie (20 min)

Une seule fonctionnalité, bien faite, et qui respecte tout le parcours. Trois options, trois mécaniques déjà apprises :

• Le menu mobile : un bouton « Menu » (un vrai <button> avec aria-expanded) qui affiche/masque la navigation sous 600 px. Mécanique : classList.toggle sur le nav + une classe CSS qui le masque. Piège d'accessibilité : le menu fermé doit aussi être atteignable — un menu masqué par display: none sort de la navigation clavier, c'est justement ce qu'on veut ici, mais le bouton doit rester visible et annoncer son état.
• Le filtre de projets : des boutons d'étiquettes (« site », « script », « design ») qui n'affichent que les cartes portant l'étiquette. Mécanique : chaque carte a un data-etiquette, le filtre parcourt les cartes et masque celles qui ne correspondent pas.
• La bascule sombre/clair avec localStorage (jour 41).

Les attributs data-* méritent un mot : ce sont des attributs libres, inventés par vous, pour coller de l'information à un élément : <article class="carte" data-etiquette="site">. JavaScript les lit avec element.dataset.etiquette. C'est le pont propre entre HTML et JS.

Pratique (30 min)

1. Construisez la fonctionnalité choisie, étape par étape, en testant dans le navigateur entre chaque.
2. Pour le filtre : trois cartes minimum, deux étiquettes minimum, un bouton « Tout » qui réaffiche tout.
3. Critère de réussite : la fonctionnalité marche à la souris ET au clavier (Tab jusqu'au bouton, Entrée, le résultat s'affiche), sans rechargement de page.
4. Committez quand ça marche, puis relisez : votre gestion d'état ressemble à la todo list — modifier les données, ré-afficher.
5. Si vous avez pris du retard, rappelez-vous la règle d'or : rognez ici, jamais sur le déploiement ni sur l'audit de demain.

Tips agent : si vous bloquez : « voici mon HTML et mon JS, le filtre ne masque rien, qu'est-ce qui cloche ? » — collez les deux fichiers. Piège : la réécriture complète proposée. Preuve : demandez « la plus petite correction possible, ligne citée ».

Synthèse (10 min)

Trois lignes : votre fonctionnalité, son mécanisme, ce que data-* vous a permis. Puis testez-la une dernière fois au clavier.

Jour 58 — Capstone 4 : l'audit

Objectif : auditer le site complet : accessibilité, responsive, performance, avant la mise en ligne.

Théorie (20 min)

Avant de publier, on audite — comme on relit un texte avant de l'envoyer. La grille, entièrement issue de votre parcours :

1. Validation : chaque page au validateur W3C, zéro erreur.
2. Structure : un h1 par page, pas de saut de niveau, les repères en place.
3. Clavier : chaque page entièrement utilisable à Tab/Entrée, focus visible partout.
4. Alt et liens : chaque image a son alt juste, chaque lien se comprend seul.
5. Contrastes : AA en mode clair ET sombre.
6. Responsive : mode appareil, trois tailles (téléphone, tablette, écran), aucun défilement horizontal.
7. Performance : Lighthouse sur chaque page ; images redimensionnées, lazy sur les images basses.

Travaillez page par page, un problème corrigé à la fois, en re-mesurant après chaque correction. Tenez la liste au carnet : chaque défaut trouvé est une compétence de plus, pas une faute.

Pratique (30 min)

1. Passez les sept points sur vos trois pages, dans l'ordre, au carnet : point par point, OK ou le défaut noté.
2. Corrigez tous les défauts trouvés, en commençant par les blocages (clavier, contrastes) avant les conforts.
3. Critère de réussite : les sept points passent sur les trois pages, et Lighthouse affiche 90+ en accessibilité sur chacune.
4. Dernier test, le plus dur : faites naviguer quelqu'un qui n'a jamais vu le site. Observez sans aider. Notez chaque hésitation : ce sont vos derniers défauts.
5. Committez : « audit : contrastes corrigés, alt complétés, focus visible ».

Tips agent : « voici mon rapport Lighthouse et ma checklist, dans quel ordre corriger ? » — bon usage de tri. Piège : l'agent classera par facilité technique, pas par impact. Preuve : la règle de tri est la vôtre — les blocages (clavier, contrastes) d'abord.

Synthèse (10 min)

Trois lignes : les sept points, l'ordre de correction, ce que le test utilisateur a révélé. Demain : le monde.

Jour 59 — Capstone 5 : déployer, documenter, bilan

Objectif : publier le site final, écrire son README, et faire le bilan du parcours.

Théorie (20 min)

Dernier jour : deux gestes professionnels, puis le bilan.

Le README : le fichier README.md à la racine du dépôt est la première chose qu'on lit sur GitHub. Le format Markdown est du texte avec quelques conventions (# Titre, ## Section, - liste, [texte](url)). Un README honnête pour un premier site : ce que c'est, l'adresse en ligne, les technologies (HTML, CSS, JavaScript — sans framework, et c'est une fierté), comment le lancer en local (ouvrir index.html), ce que vous avez appris. Cinq lignes bien écrites valent mieux qu'un pavé.

Le déploiement est déjà appris : poussez, Pages sert. La dernière vérification se fait EN LIGNE, pas en local : l'audit de la veille sur l'URL publique, avec le téléphone dans l'autre main.

Et le bilan : vous êtes parti d'une page vide. Vous savez comment le web transporte une page, comment HTML la structure, comment CSS l'habille, comment JavaScript la fait réagir, comment la rendre utilisable par tous, comment la mesurer, la versionner et la publier. La suite logique : refaire un petit projet sans guide, ou reprendre le parcours Python de ce site pour apprendre à automatiser.

Pratique (30 min)

1. Écrivez le README.md, committez, poussez, vérifiez qu'il s'affiche sur la page du dépôt.
2. Ouvrez l'URL publique et repassez l'audit éclair : trois pages, navigation, fonctionnalité JS, mode appareil, une fausse adresse pour la 404.
3. Critère de réussite final : votre site est en ligne, les trois pages s'y enchaînent, il passe les sept points de l'audit, et le README dit ce qu'il est.
4. Cochez la check-list de la page d'accueil du parcours, en entier, sans tricher.
5. Partagez l'adresse. Puis dans le carnet : la séance la plus dure, celle dont vous êtes le plus fier, ce que vous construirez le mois prochain.

Tips agent : « relis ce README comme quelqu'un qui découvre le dépôt : que manque-t-il pour comprendre et lancer le projet ? » est la délégation idéale du dernier jour. Piège : il écrira un README pompeux à votre place. Preuve : donnez le lien à quelqu'un — s'il comprend et ouvre le site, le README est bon.

Synthèse (10 min)

Trois lignes : ce qu'est un README, la différence entre tester en local et en ligne, votre prochain projet. Le parcours est fini — le site, lui, est en ligne.