Développement Web

Guide : Héberger gratuitement votre site sur GitHub Pages

12 دقائق للقراءة

Prérequis

  • Niveau : savoir créer un compte GitHub, bases HTML/CSS, notions Git utiles (cf. Git et GitHub).
  • Outils : compte GitHub gratuit, Git installé localement (optionnel pour la version graphique).
  • Temps estimé : 30 min à 1 h.

Pourquoi GitHub Pages ?

GitHub Pages est gratuit, fiable et inclut HTTPS automatique. Idéal pour les portfolios, documentations open source, blogs Jekyll, et tout site statique. Si vous avez besoin d’un peu plus (formulaires, fonctions serverless), regardez aussi Netlify ou Cloudflare Pages — gratuits et plus puissants.

Pourquoi GitHub Pages ?

GitHub Pages est un service 100% gratuit qui héberge vos sites web directement depuis un dépôt GitHub. Parfait pour les portfolios, documentations, blogs et sites vitrines. Pas de serveur à gérer, pas de frais d’hébergement.

✅ Ce que vous pouvez héberger gratuitement

  • Sites statiques (HTML, CSS, JavaScript)
  • Sites générés avec Jekyll, Hugo, Gatsby
  • Portfolios et CV en ligne
  • Documentation de projets
  • Blogs personnels

Limites : 1 Go de stockage, 100 Go de bande passante/mois, pas de code serveur (PHP, Node.js côté serveur).

Étape 1 : Créer un compte GitHub

  1. Allez sur github.com et cliquez sur « Sign up »
  2. Choisissez un nom d’utilisateur (ce sera dans votre URL : votrenom.github.io)
  3. Confirmez votre email

Étape 2 : Créer le dépôt pour votre site

Cliquez sur « New repository » et nommez-le exactement :

votrenom.github.io

Remplacez votrenom par votre nom d’utilisateur GitHub. Cochez « Add a README file », puis cliquez sur « Create repository ».

Étape 3 : Ajouter votre site

Cliquez sur « Add file » → « Create new file ». Nommez-le index.html et collez :

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Mon Site - Hébergé sur GitHub Pages</title>
    <style>
        * { margin: 0; padding: 0; box-sizing: border-box; }
        body { font-family: 'Segoe UI', sans-serif; background: linear-gradient(135deg, #667eea, #764ba2); min-height: 100vh; display: flex; align-items: center; justify-content: center; }
        .card { background: white; padding: 40px; border-radius: 20px; box-shadow: 0 20px 60px rgba(0,0,0,0.3); text-align: center; max-width: 500px; }
        h1 { color: #333; margin-bottom: 15px; }
        p { color: #666; line-height: 1.8; }
        .btn { display: inline-block; margin-top: 20px; padding: 12px 30px; background: #667eea; color: white; text-decoration: none; border-radius: 25px; }
    </style>
</head>
<body>
    <div class="card">
        <h1>🎉 Mon site est en ligne !</h1>
        <p>Ce site est hébergé gratuitement sur GitHub Pages.</p>
        <a href="#" class="btn">Découvrir</a>
    </div>
</body>
</html>

Cliquez sur « Commit changes ». Attendez 1-2 minutes, puis visitez https://votrenom.github.io.

Étape 4 : Activer GitHub Pages (pour d’autres dépôts)

Pour tout autre dépôt :

  1. Allez dans Settings → Pages
  2. Sous « Source », sélectionnez main et / (root)
  3. Cliquez sur Save
  4. Votre site sera à : votrenom.github.io/nom-du-depot

Ajouter un nom de domaine personnalisé

Pour utiliser votre propre domaine (ex: monsite.sn) :

  1. Dans Settings → Pages → Custom domain, entrez votre domaine
  2. Chez votre registrar DNS, ajoutez ces enregistrements :
    Type A :
    185.199.108.153
    185.199.109.153
    185.199.110.153
    185.199.111.153
    
    Type CNAME : www → votrenom.github.io
  3. Cochez « Enforce HTTPS » (certificat SSL gratuit)

Déployer avec Git en ligne de commande

Voici la mise en pratique pour Déployer avec Git en ligne de commande. Le bloc ci-dessous est copiable directement dans votre projet, lisible ligne par ligne. Lisez-le une première fois en survol pour repérer la structure générale, puis adaptez les noms de variables, identifiants et valeurs à votre contexte avant de l’exécuter en local.

# Cloner votre dépôt
git clone https://github.com/votrenom/votrenom.github.io.git
cd votrenom.github.io

# Créer vos fichiers
# ... éditez index.html, style.css, script.js

# Pousser les modifications
git add .
git commit -m "Mise à jour du site"
git push origin main
# Le site se met à jour automatiquement en 1-2 minutes

Utiliser un générateur de site statique

🔥 Jekyll (intégré à GitHub Pages)

GitHub Pages supporte Jekyll nativement. Créez un fichier _config.yml :

title: Mon Blog
description: Blog tech depuis Dakar
theme: minima
plugins:
  - jekyll-feed
  - jekyll-seo-tag

Ajoutez vos articles dans un dossier _posts/ au format 2026-01-15-mon-article.md.

Erreurs fréquentes

« 404 Page Not Found » après push

Cause : branche source mal configurée, ou pas de fichier index.html à la racine.
Solution : dans Settings → Pages, vérifiez que la source est bien main + / (root). Patientez 1-2 min après chaque push.

HTTPS non disponible avec un domaine custom

Cause : propagation DNS incomplète, ou enregistrement CNAME/A absent.
Solution : attendez 24 h après la configuration DNS, puis cochez « Enforce HTTPS » dans Settings → Pages.

Jekyll ignore mon thème custom

Cause : dans _config.yml, la clé doit s’écrire theme (anglais). thème avec accent n’est PAS reconnu par Jekyll.
Solution : écrivez theme: minima. Pour les thèmes hors liste blanche GitHub Pages, utilisez remote_theme.

Limites GitHub Pages dépassées

Cause : vous dépassez 1 Go de stockage, 100 Go de bande passante par mois, ou 10 builds/heure.
Solution : migrez vers Netlify (100 Go/mois gratuit + plus de builds) ou Cloudflare Pages (illimité en bande passante gratuit).

Exercice pratique

🎯 Défi : Mettez votre portfolio en ligne en 15 minutes

  1. Créez un dépôt votrenom.github.io
  2. Ajoutez une page d’accueil avec votre photo, bio et compétences
  3. Ajoutez une page projets.html avec 3 projets
  4. Ajoutez une page contact.html avec un formulaire (utilisez Formspree.io pour le traitement)
  5. Partagez le lien dans les commentaires !

Résumé des commandes essentielles

Action Commande / Étape
Créer le dépôt votrenom.github.io
Activer Pages Settings → Pages → main
Domaine custom CNAME + enregistrements A
Déployer git push origin main
HTTPS gratuit Enforce HTTPS dans Settings

Étape 2 : Créer le repository et pousser votre site

Le compte créé, ouvrez New repository et donnez-lui le nom votre-pseudo.github.io si vous voulez l’URL racine, sinon n’importe quel nom. Cochez Public.

git init
git add . && git commit -m 'Premier déploiement'
git branch -M main
git remote add origin https://github.com/votre-pseudo/votre-pseudo.github.io.git
git push -u origin main

Étape 3 : Activer GitHub Pages dans les paramètres

Allez dans Settings > Pages. Sous « Build and deployment », sélectionnez « Deploy from a branch », choisissez main et / (root), puis Save. Au bout d’une minute, l’URL publique apparaît.

Étape 4 : Domaine personnalisé et HTTPS automatique

  1. Chez votre registrar (NIC Sénégal, Namecheap), ajoutez quatre enregistrements A pointant vers : 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153.
  2. Ajoutez un CNAME sur www pointant vers votre-pseudo.github.io.
  3. Dans Settings > Pages > Custom domain, saisissez votre domaine.
  4. Attendez la propagation (15 min à 24 h). Vérifiez avec dig votreentreprise.sn.
  5. Une fois validé, cochez Enforce HTTPS. Let’s Encrypt est provisionné automatiquement.

Étape 5 : Workflow GitHub Actions pour les sites buildés

Voici la mise en pratique pour Étape 5 : Workflow GitHub Actions pour les sites buildés. Le bloc ci-dessous est copiable directement dans votre projet, lisible ligne par ligne. Lisez-le une première fois en survol pour repérer la structure générale, puis adaptez les noms de variables, identifiants et valeurs à votre contexte avant de l’exécuter en local.

name: Deploy to Pages
on:
  push: { branches: [main] }
permissions: { contents: read, pages: write, id-token: write }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22' }
      - run: npm ci
      - run: npm run build
      - uses: actions/configure-pages@v5
      - uses: actions/upload-pages-artifact@v3
        with: { path: ./dist }
  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: { name: github-pages }
    steps:
      - uses: actions/deploy-pages@v4

Limites du plan gratuit

Limite Valeur
Taille du site 1 Go
Bande passante mensuelle 100 Go (soft)
Builds par heure 10 (soft)
Code serveur (PHP, Node SSR) Non supporté
Bases de données Non

Pour un portfolio à Niamey ou un blog Jekyll, ces limites ne posent aucun problème. Pour un site e-commerce avec checkout serveur, il faut une plateforme adaptée (Vercel, Netlify, ou un VPS chez OVH ~2 100 FCFA/mois).

Étape 6 : Sécuriser et monitorer

  • Branch protection sur main : exiger une revue de PR avant merge.
  • Dependabot activé pour alertes vulnérabilités.
  • UptimeRobot (gratuit jusqu’à 50 moniteurs, ping 5 min).

Comparaison : GitHub Pages, Netlify, Cloudflare Pages

Critère GitHub Pages Netlify Cloudflare Pages
Bande passante gratuite 100 Go/mois 100 Go/mois Illimitée
Build minutes 2000/mois (Actions) 300 min/mois 500 builds/mois
Functions serverless Non 125k req/mois 100k req/jour
CDN global Fastly Bon Excellent (PoP Lagos)

Pour un visiteur depuis Ouagadougou ou Conakry, Cloudflare Pages a l’avantage du PoP de Lagos qui réduit la latence de 80 à 30 ms.

Dépannage

Symptôme Cause Solution
404 sur l’URL racine Pas d’index.html Vérifier nom et casse
CSS non chargé Chemin absolu /style.css Utiliser ./style.css
HTTPS bloqué Mixed content (assets http://) Tout passer en https:// ou //

Pour étoffer le tableau sur les patterns frontend modernes adaptés au contexte ouest-africain, voir aussi le guide événements JavaScript et le guide media queries responsive. Tester systématiquement sur Galaxy A03 ou équivalent à 200 EUR avec 4G locale dégradée reste le seul juge fiable de la performance perçue par la majorité des visiteurs locaux.

Pour explorer plus loin sur les patterns frontend modernes adaptés au contexte ouest-africain, voir aussi le guide événements JavaScript et le guide media queries responsive. Tester systématiquement sur Galaxy A03 ou équivalent à 200 EUR avec 4G locale dégradée reste le seul juge fiable de la performance perçue par la majorité des visiteurs locaux.

À lire ensuite sur les patterns frontend modernes adaptés au contexte ouest-africain, voir aussi le guide événements JavaScript et le guide media queries responsive. Tester systématiquement sur Galaxy A03 ou équivalent à 200 EUR avec 4G locale dégradée reste le seul juge fiable de la performance perçue par la majorité des visiteurs locaux.

Lectures complémentaires sur les patterns frontend modernes adaptés au contexte ouest-africain, voir aussi le guide événements JavaScript et le guide media queries responsive. Tester systématiquement sur Galaxy A03 ou équivalent à 200 EUR avec 4G locale dégradée reste le seul juge fiable de la performance perçue par la majorité des visiteurs locaux.

Adaptation au contexte ouest-africain : performance, équipe, marché

Pour un développeur basé à Dakar, Abidjan, Bamako, Cotonou, Lomé, Ouagadougou, Niamey ou Conakry qui livre des sites web ou applications custom à des PME locales, trois adaptations pèsent sur le succès des projets. Premièrement, la connectivité 4G inégale impose de réduire le poids des pages au strict nécessaire — un site qui charge en 6 secondes perd 40 % de ses visiteurs avant l’affichage. Deuxièmement, le profil typique des développeurs disponibles sur le marché local est majoritairement formé sur du JavaScript moderne et du PHP, avec une expertise variable sur les outils plus avancés (TypeScript, frameworks edge, design systems). Adapter la pile technique au profil d’équipe disponible sur place évite la dette technique liée au turn-over.

Troisièmement, le coût en FCFA des services cloud doit être anticipé dans le budget. Hetzner CX22 à 4 500 FCFA/mois reste imbattable pour un démarrage, Cloudflare Pages gratuit pour les sites statiques, Backblaze B2 à 6 USD/TB/mois pour les sauvegardes. Pour les projets B2C qui exigent une latence faible, héberger sur un CDN avec PoP africain (Cloudflare Lagos, Africa Data Centres) divise par trois la latence perçue par rapport à un déploiement européen sans CDN.

Tester sur appareils réels avant la mise en production

Plus important que tous les outils synthétiques, tester son site sur un Android d’entrée de gamme avec une connexion 4G locale dégradée donne le seul verdict qui compte. Galaxy A03 à 200 EUR neuf, Tecno Spark, Itel A60 sont les appareils dominants chez les visiteurs ouest-africains. Sur ces téléphones, un site qui semble rapide sur DevTools peut être laggy en réalité. Trois conseils pratiques. Premièrement, garder un appareil de test physique à portée de main pour vérifier chaque livraison majeure. Deuxièmement, profiler avec Chrome DevTools en mode Slow 4G + 4x CPU slowdown pour simuler ces conditions. Troisièmement, mesurer en conditions réelles avec PageSpeed Insights qui agrège les données du Chrome User Experience Report sur 28 jours — la donnée terrain qui compte vraiment.

Erreurs courantes en développement web à éviter

Trois patterns reviennent dans les projets web mal exécutés et coûtent cher à corriger plus tard. Premier pattern : copier-coller de code Stack Overflow sans comprendre le contexte d’origine. Une solution qui marche pour un cas particulier devient un bug subtil dans un autre — toujours adapter au contexte de votre projet. Deuxième pattern : ignorer les warnings de la console. Chaque warning est un signal qui mérite d’être lu et compris. Une console pleine de warnings finit par cacher les vrais problèmes. Troisième pattern : ne pas tester sur de vrais appareils. DevTools simule mais ne remplace pas un test physique sur un Android d’entrée de gamme avec une 4G dégradée — c’est le contexte réel d’usage de la majorité des visiteurs locaux.

Pour étoffer le tableau sur les bonnes pratiques de développement web modernes adaptées au contexte ouest-africain, voir aussi le guide responsive design et le guide Bootstrap 5. Documenter chaque décision technique majeure dans un fichier ADR (Architecture Decision Record) prend dix minutes et fait gagner des heures lors d’un incident ou d’un audit.

Lectures complémentaires

مشاركة