Netlify et publication web
Netlify est un exemple d’hébergement. La méthode de contrôle s’applique aussi à d’autres hébergeurs ou à une simulation locale ; aucune publication réelle n’est requise pour réaliser le laboratoire facultatif.
Chapitres, TP et corrigés consultables ; les TP sont principalement à réaliser hors de la page. Trois questions d’entraînement interactif facultatif sont proposées dans ce module, sans note ni validation automatique. Le manuel de formation est également consultable depuis le lien en haut de page. Les durées sont des repères pour organiser le parcours ; les lectures, activités, travaux pratiques et évaluations ne doivent pas être additionnés deux fois.
Dans ce module — Accès rapide
MODULE 8 — Netlify et publication web (8 heures)
Bloc B — Développer et publier | Prérequis : modules 1 à 7 | Projet fil rouge : mon-premier-projet. Les menus des services évoluent : vérifier les intitulés et les possibilités disponibles au moment de l’exercice.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Un fichier index.html sur votre ordinateur est local. Une archive de site envoyée à un hébergeur peut devenir accessible par URL publique. Préparer un ZIP n’est pas publier.
J’essaie — petit geste : Créez une archive ZIP de votre dossier et vérifiez son contenu sans la téléverser. Notez ce qui resterait à autoriser avant publication.
Je vérifie — si cela ne fonctionne pas : N’effectuez aucun déploiement réel sans décision explicite ; conservez une version stable pour revenir en arrière.
Comprendre et essayer — exemple guidé
Je vois : Le déploiement rend accessibles dans un navigateur les fichiers préparés dans un projet.
J’essaie : Dessinez la chaîne fichiers → dépôt → déploiement → navigateur.
Je vérifie : Les quatre maillons sont présents dans l’ordre et aucun déploiement n’est confondu avec un dépôt.
Autre façon de faire : Attribuez à quatre cartes « fichiers », « dépôt », « déploiement » et « navigateur » le rôle de chaque étape ; expliquez pourquoi déposer n’est pas publier.
Pour reprendre plus tard : Conservez le schéma annoté et indiquez quel lien ou quelle étape doit encore être confirmé lors d’un essai.
1. Objectifs et critères de réussite
• Expliquer la différence entre fichiers locaux, dépôt GitHub, hébergement, URL et domaine.
• Publier une version stable du site HTML/CSS/JavaScript avec Netlify.
• Distinguer publication manuelle et déploiement lié à GitHub, sans mélanger les deux procédures.
• Identifier le statut d’un déploiement et diagnostiquer une erreur simple.
• Expliquer le rôle de HTTPS et du DNS sans confondre chiffrement et fiabilité du contenu.
• Retrouver un déploiement antérieur et choisir une stratégie de restauration contrôlée.
2. Découpage horaire
Séquence 1 — Comprendre hébergement, URL, domaine et DNS (1 h).
Séquence 2 — Vérifier le projet et créer un site Netlify (1 h).
Séquence 3 — Déployer depuis GitHub (1 h 30).
Séquence 4 — Contrôler le déploiement, les liens et HTTPS (1 h).
Séquence 5 — Domaine personnalisé et configuration DNS (1 h).
Séquence 6 — Historique, restauration et diagnostic (1 h).
Séquence 7 — TP autonome et évaluation (1 h 30).
Comprendre et essayer — exemple guidé
Je vois : Préparer, publier et vérifier sont trois étapes différentes d'une mise en ligne.
J’essaie : Répartissez les huit heures entre préparation, publication et contrôle.
Je vérifie : Les trois phases disposent d’une durée et le contrôle après publication n’est pas omis.
Autre façon de faire : Imaginez qu’un contrôle après publication échoue : reprenez votre planning et réservez un créneau de correction et de nouveau test.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
3. Les notions fondamentales
Le navigateur affiche une page demandée à une adresse (URL). Le dépôt GitHub conserve le code et son historique ; Netlify distribue les fichiers publiés. Un déploiement est une version du site mise à disposition. Un domaine personnalisé est un nom que l’on possède et configure ; un sous-domaine fourni par Netlify suffit pour ce cours. Le DNS relie les noms aux services selon les enregistrements configurés. HTTPS protège les échanges avec le site, mais ne garantit ni la justesse du contenu ni l’absence de bugs.
Pour notre site statique, index.html est le point d’entrée. Aucune compilation n’est nécessaire : la commande de build peut rester vide et le répertoire de publication est celui contenant index.html (souvent la racine du dépôt). Pour d’autres frameworks, ces réglages peuvent différer.
Comprendre et essayer — exemple guidé
Je vois : L'hébergement stocke les fichiers ; le domaine fournit une adresse ; le déploiement transfère une version.
J’essaie : Distinguez hébergement, domaine et déploiement dans une adresse fictive.
Je vérifie : Hébergement, domaine et déploiement sont définis par trois fonctions différentes.
Autre façon de faire : Sur un scénario fictif, distinguez le nom de domaine, le service qui héberge les fichiers et l’opération de déploiement. Le nom de domaine seul ne révèle pas nécessairement l’hébergeur.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
4. Préparer le dépôt avant publication
□ Ouvrir index.html localement et vérifier le bouton, le message et la mise en page.
□ Confirmer que les chemins vers style.css et script.js sont relatifs et corrects.
□ Lire git status et vérifier que les changements utiles sont enregistrés et poussés sur GitHub.
□ Vérifier qu’aucune donnée personnelle, clé secrète ou fichier temporaire n’est public.
□ Identifier la branche stable, généralement main, et relever le dernier commit.
git status
git log --oneline -3Faire défiler horizontalement pour voir les lignes longues.
git remote -v
Ces commandes permettent de lire l’état et l’origine du dépôt ; elles ne publient rien. La présence du dernier commit sur GitHub doit aussi être vérifiée dans l’interface.
Comprendre et essayer — exemple guidé
Je vois : Un dossier de publication incomplet peut produire une page sans images ni styles.
J’essaie : Vérifiez que la page d’accueil et les ressources sont présentes dans le dossier à publier.
Je vérifie : index.html et les fichiers appelés par ses liens sont présents dans le dossier à publier.
Autre façon de faire : Contrôlez le dossier local à publier : index.html et ressources attendues.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
5. Deux modes de publication à distinguer
Mode A — Déploiement manuel : importer le dossier contenant index.html dans l’interface Netlify. Utile pour une démonstration, mais une modification sur GitHub ne met pas automatiquement à jour ce déploiement manuel.
Mode B — Déploiement continu : dans Netlify, choisir l’ajout d’un nouveau projet depuis un fournisseur Git, autoriser uniquement les dépôts nécessaires, sélectionner le dépôt pédagogique et la branche stable. Pour ce projet statique : commande de build vide ; dossier de publication « . » si index.html se trouve à la racine. Vérifier les paramètres avant de lancer le déploiement.
La procédure recommandée pour le projet fil rouge est le mode B. L’interface et les quotas peuvent varier selon le compte et la période.
Comprendre et essayer — exemple guidé
Je vois : Un dépôt connecté automatise des publications ; un dépôt manuel demande une action explicite.
J’essaie : Comparez dépôt connecté et dépôt manuel sans les confondre.
Je vérifie : Les deux modes sont décrits sans présenter un dépôt connecté comme un simple transfert manuel.
Autre façon de faire : Choisissez deux scénarios fictifs, avec ou sans dépôt connecté, puis indiquez pour chacun comment une nouvelle version arrive chez l’hébergeur.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
6. Première publication pas à pas
Étape 1 — Se connecter à Netlify et sélectionner la création d’un projet à partir d’un dépôt Git.
Étape 2 — Connecter GitHub après lecture des permissions demandées ; sélectionner mon-premier-projet.
Étape 3 — Contrôler la branche de publication, la commande de build (aucune) et le répertoire publié (racine).
Étape 4 — Lancer le déploiement puis attendre un statut de réussite, sans déduire la réussite du seul clic.
Étape 5 — Ouvrir l’URL fournie par Netlify dans un navigateur privé et tester le site.
Étape 6 — Noter dans une fiche : URL, date, branche, identifiant de commit et résultat des tests.
Comprendre et essayer — exemple guidé
Je vois : Simuler une publication permet d'ordonner les opérations, sans prouver que le site fonctionne en ligne.
J’essaie : Simulez les étapes d’une publication sur papier avant toute mise en ligne.
Je vérifie : La simulation comporte préparation, lancement, contrôle et possibilité de retour arrière.
Autre façon de faire : À partir d’une liste de fichiers fictifs, repérez ce qui manquerait à la publication et préparez une liste de contrôle avant mise en ligne.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
7. Vérifier un site publié
□ L’URL s’ouvre sur ordinateur et sur téléphone.
□ Le titre, les styles CSS et les interactions JavaScript sont présents.
□ Les liens ne conduisent pas vers des chemins locaux du type C:\Utilisateurs\...
□ Le bouton fonctionne avec la souris et au clavier (Tab, Entrée/Espace).
□ Le site ne présente pas de défilement horizontal inattendu.
□ L’adresse utilise https:// et le navigateur ne signale pas d’erreur de certificat.
□ La console et les requêtes réseau ne signalent pas de ressources essentielles manquantes.
Comprendre et essayer — exemple guidé
Je vois : Une publication réussie doit être contrôlée à partir de ses URL publiques.
J’essaie : Établissez une liste de trois pages et liens à ouvrir après publication.
Je vérifie : La liste comprend au moins une page interne et un lien vers une ressource effectivement accessible.
Autre façon de faire : Préparez trois URL et le résultat attendu pour les tests après publication.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
8. Domaine personnalisé : comprendre avant de modifier
Un domaine personnalisé est facultatif. Si l’apprenant en possède un, l’ajouter dans les paramètres de domaines Netlify puis appliquer exactement les enregistrements DNS indiqués pour sa configuration. Selon le cas, cela implique des enregistrements CNAME, A ou d’autres réglages. Ne pas recopier d’adresse IP ou de valeur DNS générique depuis un cours : elles peuvent changer. Les changements DNS peuvent demander un délai de propagation. Attendre la validation du domaine et du certificat HTTPS avant de communiquer l’adresse.
Ne pas modifier le DNS d’un site réel de production pour un TP. Utiliser un domaine de test ou rester sur le sous-domaine Netlify.
Comprendre et essayer — exemple guidé
Je vois : Un domaine personnalisé change l'adresse d'accès, pas nécessairement le contenu des fichiers.
J’essaie : Repérez ce qui change lorsqu’un domaine personnalisé est ajouté.
Je vérifie : Le domaine change l’adresse d’accès sans modifier à lui seul le contenu publié.
Autre façon de faire : Dessinez l’URL avant/après l’ajout d’un domaine ; vérifiez la configuration réelle plus tard.
Pour reprendre plus tard : Conservez votre production de l’activité 8, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
9. Comprendre les déploiements et les retours arrière
Dans l’historique des déploiements Netlify, consulter le statut, la source Git et les journaux. Si une nouvelle version est défectueuse, conserver les informations sur le problème et examiner les options de restauration disponibles dans l’interface. Selon le type de déploiement et les réglages, un déploiement antérieur peut être republié ; sur un site relié à Git, il faut aussi corriger ou annuler le commit responsable pour éviter qu’une prochaine publication ne réintroduise le défaut.
Privilégier une correction Git traçable, par exemple git revert sur un commit identifié, après vérification. Ne jamais réécrire l’historique partagé sans comprendre les conséquences.
Comprendre et essayer — exemple guidé
Je vois : Revenir à un déploiement antérieur peut restaurer un site sans supprimer les sources.
J’essaie : Dessinez deux versions déployées et choisissez celle vers laquelle revenir en cas d’erreur.
Je vérifie : Une version antérieure identifiable est conservée et la marche arrière ne supprime pas les sources.
Autre façon de faire : Schématisez deux versions et indiquez la procédure de retour à la précédente.
Pour reprendre plus tard : Conservez le schéma annoté et indiquez quel lien ou quelle étape doit encore être confirmé lors d’un essai.
10. Dépannage : quatre cas fréquents
Page introuvable
Cause possible : Le répertoire publié ne contient pas index.html à l’endroit attendu.
Vérification : Vérifier l’arborescence, la casse des noms et le répertoire de publication.
Page sans styles
Cause possible : Chemin CSS incorrect ou fichier absent du dépôt.
Vérification : Ouvrir les outils réseau du navigateur et vérifier href et nom du fichier.
Bouton inactif
Cause possible : script.js non chargé ou erreur JavaScript.
Vérification : Contrôler la console, l’attribut defer et les identifiants HTML.
Nouvelle version non visible
Cause possible : Déploiement non déclenché, échoué, branche incorrecte ou cache.
Vérification : Comparer commit GitHub et source du déploiement ; vérifier le statut puis actualiser.
11. Travaux pratiques
TP1 — Schématiser le trajet
Consigne : Dessiner ordinateur → GitHub → Netlify → navigateur et expliquer chaque flèche.
Livrable : Schéma légendé.
Corrigé commenté et approfondissement — à consulter après votre essai
Durée indicative : 20–30 min (estimation non mesurée).
Critères de réussite : Le schéma distingue les fichiers locaux, la version publiée et le navigateur ; chaque flèche a une action et non seulement un nom.
Corrigé commenté — comparer après réalisation
Un schéma complet identifie : ordinateur (modification et tests), GitHub (version et dépôt), Netlify (récupération de la version et déploiement), navigateur (consultation). Indiquer qu’un changement local non enregistré dans le dépôt ne modifie pas automatiquement le site. Si la publication est manuelle par glisser-déposer, le passage par GitHub est facultatif.
Comprendre et essayer — exemple guidé
Je vois : Une copie locale, un dépôt et un site hébergé peuvent correspondre à trois versions différentes.
J’essaie : Schématisez les trois lieux où existe le site : local, dépôt, hébergement.
Je vérifie : Les trois copies sont nommées et leur rôle distinct est correctement expliqué.
Autre façon de faire : Dessinez les trois copies du site et les échanges entre elles.
Pour reprendre plus tard : Conservez le schéma annoté et indiquez quel lien ou quelle étape doit encore être confirmé lors d’un essai.
TP2 — Préparer le site
Consigne : Examiner les trois fichiers, tester localement et rédiger une checklist.
Livrable : Checklist datée.
Corrigé commenté et approfondissement — à consulter après votre essai
Durée indicative : 25–40 min (estimation non mesurée).
Critères de réussite : La checklist comporte au moins six contrôles réalisés, leur résultat et une date ; les fichiers privés sont exclus.
Corrigé commenté — comparer après réalisation
Exemple de checklist : index.html à la racine du dossier publié ; style.css et script.js aux chemins réellement utilisés ; liens internes vérifiés ; page lisible sur petit écran ; aucune clé, donnée personnelle ou fichier secret ; copie locale conservée. Vérifier que la page fonctionne sans dépendre d’un chemin absolu propre à votre ordinateur.
Comprendre et essayer — exemple guidé
Je vois : Les chemins relatifs doivent rester valides dans le dossier réellement publié.
J’essaie : Contrôlez index.html et les chemins relatifs d’une copie de projet.
Je vérifie : Les liens relatifs se résolvent depuis index.html vers des fichiers réellement présents.
Autre façon de faire : Ouvrez une copie locale et contrôlez les chemins relatifs dans le navigateur.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP3 — Publier
Consigne : Si un compte Netlify et les autorisations nécessaires sont disponibles, connecter le dépôt pédagogique et publier sans commande de build. Sinon, effectuer la simulation de publication à partir d’une capture ou d’une fiche de paramètres fictifs, sans prétendre qu’un site est réellement publié.
Livrable : URL et commit réellement relevés en cas de publication ; sinon, fiche de simulation explicitement identifiée comme telle.
Corrigé commenté et approfondissement — à consulter après votre essai
Durée indicative : 30–60 min (estimation non mesurée).
Critères de réussite : Le livrable permet de distinguer sans ambiguïté une publication vérifiée d’une simulation ; aucune donnée d’accès n’est publiée.
Corrigé commenté — comparer après réalisation
Parcours réel : conserver une capture ou une note de la configuration et relever l’URL de déploiement, le commit si le dépôt est connecté et les résultats de vérification. Parcours simulé : écrire « SIMULATION — aucune publication effectuée », décrire le dossier à publier, la branche envisagée, l’absence de build pour ce site statique, les contrôles prévus et les éléments qui resteraient inconnus (URL réelle, état du déploiement). Ne jamais inventer une URL ou un commit.
Comprendre et essayer — exemple guidé
Je vois : Une liste de contrôle distingue préparation technique et vérification après publication.
J’essaie : Préparez une liste de contrôle pour une publication fictive sans créer de compte.
Je vérifie : La checklist couvre fichiers, liens, version et contrôle post-publication sans exiger de compte.
Autre façon de faire : Rédigez une checklist de publication fictive et marquez les étapes non testées.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
TP4 — Diagnostiquer
Consigne : Dans une copie d’exercice, casser le chemin vers style.css, constater le problème puis corriger.
Livrable : Cause, correction et nouveau test.
Corrigé commenté et approfondissement — à consulter après votre essai
Durée indicative : 25–40 min (estimation non mesurée).
Critères de réussite : Le journal contient symptôme, hypothèse, preuve, correction et nouveau résultat, sans toucher au site public.
Corrigé commenté — comparer après réalisation
Exemple : index.html contient <link rel="stylesheet" href="styles.css"> mais le fichier s’appelle style.css. Symptôme : le HTML apparaît sans mise en forme ; hypothèse : chemin incorrect ; preuve : erreur 404 dans les outils du navigateur ou absence du fichier ciblé ; correction : href="style.css" ; retest : styles visibles et plus d’erreur sur cette ressource. Tester sur une copie.
Comprendre et essayer — exemple guidé
Je vois : Un lien cassé peut venir d'un chemin incorrect ou d'un fichier absent du déploiement.
J’essaie : À partir d’un lien cassé fictif, recherchez si l’erreur vient du chemin ou du déploiement.
Je vérifie : La cause probable est étayée par le chemin demandé et la présence du fichier déployé.
Autre façon de faire : Sur un cas fictif, comparez le chemin demandé aux fichiers réellement prévus dans le dossier publié. Si le chemin est correct, notez les contrôles de déploiement à effectuer sans prétendre avoir diagnostiqué le serveur.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP5 — Revenir à une version saine
Consigne : Créer une modification réversible sur une branche de test, examiner l’historique et expliquer le retour arrière.
Livrable : Note de décision sans perte de travail.
Corrigé commenté et approfondissement — à consulter après votre essai
Durée indicative : 25–45 min (estimation non mesurée).
Critères de réussite : La décision est réversible et argumentée ; la version saine est identifiable ; la distinction entre restauration locale et publication est explicite.
Corrigé commenté — comparer après réalisation
Exemple de note : version A fonctionnelle, version B présentant un défaut. Comparer les deux changements ; conserver B dans l’historique ; choisir de republier A ou de corriger B dans un nouveau commit ; vérifier que le site de test pointe bien vers la version choisie. Une action de retour arrière n’efface pas nécessairement l’historique Git. Sans accès : réaliser la comparaison sur deux copies locales datées et préciser qu’aucun déploiement n’a eu lieu.
Comprendre et essayer — exemple guidé
Je vois : L'historique des publications aide à retrouver une version antérieure vérifiée.
J’essaie : Décrivez comment retrouver une version publiée antérieure sans effacer les sources.
Je vérifie : La procédure distingue réactivation d’un déploiement ancien et suppression des sources.
Autre façon de faire : Sur une chronologie fictive de trois versions, indiquez laquelle restaurer et comment conserver les fichiers de travail actuels.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
12. Étude de cas — Récits Vivants
Pour une page de découverte accessible par QR code, une URL stable est importante : modifier la page sans changer l’adresse publique évite de rendre obsolètes des supports imprimés. Vérifier les images, les chemins, les métadonnées et la page sur téléphone. Distinguer une erreur de contenu, une erreur de déploiement et une erreur d’indexation : elles n’ont pas les mêmes causes ni les mêmes solutions.
Comprendre et essayer — exemple guidé
Je vois : Le QR code encode une destination qui doit correspondre à la page voulue.
J’essaie : Reliez une page Récits Vivants à son QR code et vérifiez l’URL de destination.
Je vérifie : L’URL décodée du QR code correspond exactement à la page de destination prévue.
Autre façon de faire : Comparez l’URL imprimée à celle du QR code avec un lecteur gratuit ; sinon notez « non testé ».
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
Entraînement interactif facultatif — V0.6.0
Ces questions complémentaires ne constituent ni une note ni une validation de compétence. Aucune réponse n’est enregistrée.
13. Autoévaluation corrigée
Afficher le corrigé
1. GitHub héberge-t-il automatiquement le site sur Netlify ?
Corrigé : Non, il faut configurer un déploiement ou importer les fichiers.
Pourquoi cette réponse ? Un dépôt GitHub ne déclenche pas à lui seul une publication Netlify : il faut configurer le lien de déploiement ou importer les fichiers.
Exemple ou vérification autonome Vérifiez dans un projet fictif quelle source et quel dossier sont configurés pour le déploiement.
Afficher le corrigé
2. Qu’est-ce qu’un déploiement ?
Corrigé : Une version du site rendue accessible sur un hébergement.
Pourquoi cette réponse ? Déployer signifie rendre une version accessible sur un hébergement ; ce n’est pas simplement enregistrer un fichier local.
Exemple ou vérification autonome Comparez l’ouverture locale d’index.html avec l’URL d’une version réellement publiée.
Afficher le corrigé
3. Faut-il un build pour notre HTML statique ?
Corrigé : Non, pas pour ces trois fichiers simples.
Pourquoi cette réponse ? Un site HTML/CSS/JS simple peut être publié directement ; une étape de build n’est utile que si les outils du projet l’exigent.
Exemple ou vérification autonome Vérifiez que les trois fichiers statiques sont présents dans le dossier de publication.
Afficher le corrigé
4. Où doit se trouver index.html ?
Corrigé : Dans le dossier effectivement publié.
Pourquoi cette réponse ? L’hébergeur doit trouver index.html dans le répertoire effectivement servi ; un mauvais dossier peut produire une page introuvable.
Exemple ou vérification autonome Inspectez l’arborescence du dossier à publier et localisez index.html.
Afficher le corrigé
5. À quoi sert HTTPS ?
Corrigé : À chiffrer et authentifier la connexion selon le certificat.
Pourquoi cette réponse ? HTTPS chiffre les échanges et authentifie le serveur selon le certificat ; il ne garantit pas la véracité du contenu du site.
Exemple ou vérification autonome Ouvrez une URL HTTPS et inspectez les informations de connexion du navigateur.
Afficher le corrigé
6. Le domaine personnalisé est-il obligatoire ?
Corrigé : Non, le sous-domaine Netlify convient.
Pourquoi cette réponse ? Un sous-domaine fourni par l’hébergeur peut suffire ; acheter un domaine personnalisé est un choix, pas un prérequis pédagogique.
Exemple ou vérification autonome Identifiez l’URL de test fournie par l’hébergeur sans configurer de domaine payant.
Afficher le corrigé
7. Pourquoi consulter les journaux ?
Corrigé : Pour identifier la cause d’un déploiement échoué.
Pourquoi cette réponse ? Les journaux de déploiement décrivent les étapes et erreurs du processus, utiles pour identifier une panne.
Exemple ou vérification autonome Sur un journal d’exemple, relevez la première erreur et le fichier ou l’étape concernés.
Afficher le corrigé
8. Pourquoi tester sur mobile ?
Corrigé : Pour détecter les défauts responsive et d’interaction.
Pourquoi cette réponse ? Le rendu et les interactions peuvent changer sur petit écran : la seule vérification sur ordinateur est insuffisante.
Exemple ou vérification autonome Testez une page à 375 px, puis vérifiez le menu, les boutons et les débordements.
Afficher le corrigé
9. Pourquoi relever le commit publié ?
Corrigé : Pour relier précisément la version visible au code source.
Pourquoi cette réponse ? Le commit identifie le code correspondant à la version visible ; sans cette référence, un retour arrière est plus incertain.
Exemple ou vérification autonome Notez l’identifiant du commit et l’URL de la version publiée dans un journal de recette.
Afficher le corrigé
10. Un rollback Netlify suffit-il toujours ?
Corrigé : Non, une prochaine publication Git peut réintroduire le problème.
Pourquoi cette réponse ? Un retour arrière sur l’hébergement n’empêche pas un futur déploiement de réintroduire le défaut depuis la branche source.
Exemple ou vérification autonome Après rollback, indiquez aussi quel changement doit être corrigé dans le dépôt.
14. Épreuve d’autonomie — 90 minutes
Sans assistance de l’IA, deux parcours équivalents sont proposés selon les accès disponibles. Parcours A (compte et autorisations disponibles) : publier le projet depuis GitHub sur un site de test ; relever l’URL et le commit réellement publiés ; vérifier cinq comportements ; identifier une erreur de chemin simulée ; expliquer comment revenir à une version saine. Parcours B (sans compte ou autorisation) : à partir d’une fiche de paramètres fictifs et du projet local, décrire la configuration GitHub–Netlify, produire une checklist de cinq tests avec résultats locaux réellement observés, diagnostiquer une erreur de chemin dans une copie et expliquer le retour arrière ; inscrire explicitement « simulation — aucune publication réalisée », sans inventer d’URL ni de commit publié. Barème commun /20 : compréhension (4), configuration réelle ou simulée correctement identifiée (5), tests réels locaux ou publiés (5), diagnostic (3), retour arrière et traçabilité (3). Seuil conseillé : 14/20 et aucune exposition de secrets. La publication réelle n’est attestée que pour le parcours A.
Comprendre et essayer — exemple guidé
Je vois : Le procès-verbal de recette relie chaque résultat à une preuve et à une décision.
J’essaie : Rédigez un procès-verbal de recette avec preuves et décision de publication.
Je vérifie : Le procès-verbal contient test, attendu, constat, anomalie et décision motivée.
Autre façon de faire : Relisez un procès-verbal fictif incomplet et ajoutez la preuve manquante avant de décider GO ou NO GO.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
15. Bilan et transition
L’apprenant peut expliquer la chaîne de publication et ne confond plus « code enregistré » et « site en ligne ». Module 9 : plugins, connecteurs, permissions et outils d’intégration ; la connexion à un service ne remplace jamais le contrôle des actions autorisées.
Comprendre et essayer — exemple guidé
Je vois : Conserver la version, les fichiers et les anomalies facilite la prochaine publication.
J’essaie : Indiquez ce qu’il faudra conserver pour la prochaine version du site.
Je vérifie : La version, les fichiers source et au moins une preuve de recette sont identifiés pour la reprise.
Autre façon de faire : Préparez la liste des sources, versions et anomalies à transmettre.
Pour reprendre plus tard : Conservez votre production de l’activité 17, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Atelier d’approfondissement — parcours guidé
Ce parcours complète les travaux pratiques du module. Il peut être réalisé sans abonnement payant et ne constitue pas une évaluation certifiante.
Ce que vous allez apprendre — Préparer une publication vérifiable sans publier le site.
Matériel nécessaire — Ordinateur et projet HTML local ; compte Netlify non nécessaire.
Organisation sur deux écrans — Vous pouvez lire ce cours sur téléphone et effectuer les manipulations sur ordinateur. Gardez les deux appareils à portée de vue ; aucun transfert de données entre eux n’est obligatoire.
Préparer un déploiement sans le lancer
Comment procéder concrètement
- Ouvrez le dossier de votre site et repérez index.html à la racine.
- Vérifiez que les fichiers référencés dans HTML existent au bon emplacement.
- Ouvrez la page localement et testez les liens et les interactions.
- Créez une archive ZIP contenant les fichiers du site, sans dossier parent superflu.
- Remplissez la checklist du corrigé et identifiez la copie qui servirait au retour arrière. Ne déployez rien dans cet exercice.
Si vous n’avez qu’un téléphone — Sur téléphone, relisez la checklist ; la préparation de l’archive et l’inspection de sa structure sont recommandées sur ordinateur.
Repères pratiques — Vérifier la racine du ZIP
À réaliser concrètement : Ouvrez l’archive ZIP sans la publier. Dès son ouverture, vous devez voir index.html et les ressources attendues, pas uniquement un dossier parent. Si un dossier parent apparaît, créez une nouvelle archive à partir du contenu du dossier du site. La publication réelle est exclue de cet exercice.
Si vous êtes bloqué : Si index.html n’est pas à la racine, vérifiez le contenu du ZIP avant tout déploiement. Une page locale fonctionnelle ne prouve pas que la publication fonctionnera.
Essai autonome, sans recopier le modèle : Préparez une deuxième archive après avoir renommé un fichier CSS ; détectez le chemin cassé avant toute publication.
Étape 1 — Vérifier les fichiers
À faire : Listez les éléments nécessaires à la page.
Exemple ou résultat modèle : index.html, style.css, app.js et les ressources réellement référencées.
Vérification : Aucun fichier indispensable n’est absent.
Étape 2 — Contrôler les chemins
À faire : Ouvrez la copie locale et activez les liens.
Exemple ou résultat modèle : href="style.css" fonctionne si style.css est au même niveau que index.html.
Vérification : Pas de lien cassé dans la copie préparée.
Étape 3 — Établir la checklist
À faire : Séparez préparation, publication et contrôle après publication.
Exemple ou résultat modèle : Préparation : liens testés ; publication : action autorisée ; après : page ouverte, retour arrière disponible.
Vérification : Aucune publication réelle n’est faite dans cet exercice.
Si cela ne fonctionne pas : pistes de dépannage
Une image manque : vérifiez son chemin et la casse du nom. La page d’accueil est absente de la racine : corrigez la structure de l’archive avant toute publication.
Afficher le corrigé commenté
Corrigé modèle : une archive de publication doit ouvrir directement index.html à sa racine. La vérification locale ne garantit pas à elle seule le résultat en ligne.
Exemple complet à reproduire
Fichier ou livrable modèle : checklist-prepublication.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
ARCHIVE ATTENDUE (à la racine) :
index.html
style.css
app.js
AVANT PUBLICATION :
[ ] index.html s'ouvre en local.
[ ] Les liens internes fonctionnent.
[ ] Aucun secret ni donnée personnelle dans les fichiers.
[ ] Les fichiers CSS et JS sont correctement référencés.
[ ] Une copie de la dernière version stable est disponible.
PUBLICATION : non exécutée dans cet exercice.
APRÈS PUBLICATION (si autorisée ultérieurement) :
[ ] Ouvrir l'URL réelle sur ordinateur et téléphone.
[ ] Vérifier CSS, JavaScript, navigation et liens.
[ ] Documenter le retour à la version stable.Pourquoi ce corrigé est valable
Le dossier racine doit contenir index.html ; une archive contenant un dossier supplémentaire peut changer le point d'entrée attendu. La recette locale et la recette sur l'URL publique sont deux vérifications distinctes.
Preuve de vérification attendue
Après réalisation, conservez le fichier produit et une note indiquant la manipulation testée, le résultat réellement observé et les éventuelles limites. Ne cochez pas un test non effectué.
Bilan personnel : notez ce qui fonctionne, ce qui reste à vérifier et une amélioration possible. Aucun résultat de cet atelier n’est envoyé au site.
Complément de corrigé TP — exemple de vérification et diagnostic
Préparation de publication — Contrôler la racine de l’archive, index.html, les liens et les ressources ; distinguer simulation et mise en ligne réelle. Ne publier qu’avec accord explicite.
Variante autonome : changer un seul élément de votre réalisation, prévoir le résultat, effectuer le test et consigner ce qui a réellement été observé. Plusieurs solutions sont acceptables si elles satisfont les critères du TP.
Laboratoire ludique facultatif — Avant de publier : GO ou NO GO ?
Examine quatre anomalies d’un site fictif, corrige-les, relance les contrôles simulés et justifie ta décision de publication. Aucune publication réelle, sans compte ni score.
Ouvrir le laboratoire M08 — Publication fictive et décision GO / NO GO →