GitHub Pages : créer, versionner et publier un site statique

PrérequisHTML/CSS de base

ObjectifDéployer un site versionné

RéférenceGitHub Docs

Objectifs d’apprentissage

comprendre ce que GitHub Pages peut et ne peut pas héberger ;
versionner un site avec Git avant publication ;
choisir entre publication depuis une branche et workflow GitHub Actions ;
éviter les erreurs de chemins relatifs et de fichiers manquants ;
configurer HTTPS et comprendre le rôle d’un domaine personnalisé ;
appliquer une checklist de qualité avant mise en ligne.

1. GitHub Pages héberge des sites statiques

Un site statique sert des fichiers déjà générés : HTML, CSS, JavaScript, images, JSON public, polices et autres ressources. Le navigateur reçoit ces fichiers puis les exécute côté client.

GitHub Pages ne remplace pas un serveur applicatif avec base de données privée, authentification serveur ou stockage de secrets. Pour ces besoins, on utilise un backend ou une plateforme adaptée.

Ne publie jamais mots de passe, clés privées, jetons d’API secrets, fichiers .env ou données personnelles sensibles dans le dépôt.

2. Structure minimale d’un site

mon-site/
├── index.html
├── about.html
├── styles/
│   └── main.css
├── js/
│   └── site.js
└── images/
    └── hero.jpg

Le fichier index.html sert généralement de point d’entrée. Les chemins doivent rester cohérents avec l’emplacement réel des fichiers.

3. Le workflow Git essentiel

git status
git add .
git commit -m "feat: improve portfolio"
git push

git status doit devenir un réflexe : il montre ce qui a changé avant d’enregistrer une version. Un commit doit idéalement représenter une modification cohérente et expliquée par son message.

Bonne pratiqueTeste localement avant de pousser. Un historique propre aide autant au débogage qu’à la collaboration.

4. Deux sources de publication

La documentation GitHub permet deux approches principales :

Depuis une branche

Simple pour un site déjà composé de fichiers prêts à être servis. Un push sur la branche choisie déclenche la publication.

Avec GitHub Actions

Utile lorsqu’un build doit produire le site avant publication ou lorsqu’on veut contrôler davantage le workflow.

Pour un portfolio HTML/CSS/JS sans étape de compilation, la publication depuis une branche est souvent suffisante.

5. Le piège des chemins

Une page située dans posts/post1.html ne résout pas images/photo.jpg de la même façon que index.html. Les chemins relatifs sont calculés depuis la page courante.

<!-- depuis index.html -->
<img src="images/photo.jpg" alt="...">

<!-- depuis posts/post1.html -->
<img src="../images/photo.jpg" alt="...">

Autre source fréquente d’erreurs : la casse. Sur un hébergement Linux, Logo.png et logo.png peuvent être considérés comme deux noms différents.

6. Quand utiliser GitHub Actions ?

Si ton projet utilise un générateur ou une étape de build, un workflow peut installer les dépendances, générer les fichiers puis publier l’artefact résultant. Cela sépare le code source de ce qui est réellement servi.

Le pipeline doit rester reproductible : mêmes sources + mêmes dépendances → même résultat attendu.

7. Domaine personnalisé et DNS

GitHub Pages accepte les domaines personnalisés. Un sous-domaine utilise généralement un enregistrement de type CNAME, tandis qu’un domaine racine peut nécessiter des enregistrements adaptés fournis par GitHub.

GitHub recommande de vérifier le domaine avant de l’associer afin de réduire le risque de mauvaise configuration ou de prise de contrôle d’un sous-domaine.

8. HTTPS

GitHub Pages prend en charge HTTPS, y compris avec un domaine personnalisé correctement configuré. L’option d’application HTTPS redirige le trafic HTTP vers HTTPS et protège le transport contre l’écoute ou la modification en transit.

Limite importante : GitHub indique que Pages ne doit pas être utilisé pour des transactions sensibles comme la collecte de mots de passe ou de numéros de carte bancaire.

9. Checklist avant publication

aucun secret dans le dépôt ;
tous les liens internes testés ;
images optimisées et attributs alt pertinents ;
titre et description uniques ;
mise en page testée sur mobile ;
navigation au clavier possible ;
aucune erreur importante dans la console ;
favicon, page 404 et URL canonique vérifiés si nécessaire ;
HTTPS activé sur le domaine final.

10. Dépanner méthodiquement

Symptôme	Vérification
Page 404	nom du fichier, casse, branche publiée, chemin URL
CSS absent	chemin relatif, casse, requête réseau dans DevTools
ancienne version visible	commit réellement poussé, source Pages, cache navigateur
HTTPS non disponible	DNS, domaine déclaré, délai de provisionnement du certificat
image cassée	nom exact, extension, chemin depuis la page courante

Mini-projet — publier une page portfolio

Crée index.html, styles/main.css et une image. Versionne le projet avec un commit initial, publie-le avec GitHub Pages, puis vérifie sur mobile : navigation, liens, console, HTTPS et temps de chargement. Ajoute ensuite une deuxième page et corrige les chemins relatifs.

Git, hébergement & HTTP · atelier progressif

Publier un site sans perdre le fil de son travail

Git suit les versions des fichiers dans un dépôt local ; GitHub héberge ce dépôt et permet de collaborer. Un hébergeur de site sert les fichiers HTML, CSS et JavaScript aux visiteurs. Ces trois éléments sont liés, mais distincts. Avant la publication, vérifie que les chemins vers les images et feuilles CSS sont corrects, que la page 404 fonctionne et qu’aucun secret ne figure dans le dépôt.

Pratique pas à pas

Crée un dossier de projet avec index.html et styles.css, puis ouvre un terminal à cet endroit.
Initialise Git, ajoute les fichiers et enregistre un premier commit descriptif. Analyse l’état du dépôt après chaque commande.
Crée ton dépôt distant sur GitHub, associe-le avec l’URL fournie par GitHub et publie. Active ensuite Pages dans les paramètres du dépôt si ce mode d’hébergement te convient.

Exemple à essayer

git init
git status
git add index.html styles.css
git commit -m "Premier site statique"
git status
# Après création du dépôt distant :
git remote add origin URL_DU_DEPOT
git branch -M main
git push -u origin main

Ce que tu dois observer : Après le commit, git status doit indiquer un arbre de travail propre si aucun fichier n’a été modifié. Les fichiers restent locaux tant que git push n’a pas envoyé les commits au dépôt distant.

Erreur fréquente : Publier un mot de passe, une clé API ou un fichier .env ; ou supposer que chaque hébergeur exécute automatiquement un backend Python/PHP.

Vérifie que tu as compris

Git et GitHub sont-ils identiques ?

Non : Git versionne localement et GitHub héberge des dépôts en ligne.

Pourquoi un chemin /images/logo.png peut-il échouer sur un site publié dans un sous-dossier ?

Le chemin absolu part de la racine du domaine ; pour une page de projet, un chemin relatif ou une base correctement configurée peut être nécessaire.

Ressources de référence

W3Schools — Git Tutorial GitHub Docs — GitHub Pages MDN — Comment fonctionne le Web

Une fois l’atelier réalisé et les questions comprises, valide cette étape dans ton parcours.

À retenir

GitHub Pages est excellent pour les sites statiques et documentations.
Git fournit l’historique ; Pages fournit la publication.
Les chemins relatifs et la casse expliquent beaucoup de pannes.
Un dépôt public ne doit jamais contenir de secrets.
HTTPS protège le transport, mais ne transforme pas un site statique en backend sécurisé.

Pause active

Teste ta compréhension

Quelle pratique aide le plus à publier sans perdre le contrôle ?

Publier un site, c’est aussi apprendre à versionner, tester et diagnostiquer.