Partie 1 : D'un site statique à un serveur Python

Octobre 2025

Le point de départ : 4 pages HTML statiques

Tout a commencé très simplement. J'avais :

• 4 pages HTML : index.html, presentation.html, services.html, galerie.html
• 1 fichier CSS : style.css
• 1 fichier JavaScript : script.js pour le menu et la lightbox
• Des images dans un dossier images/

Le site home-fonta.fr était un site de test basique avec une galerie photos, une présentation et des services. Il était hébergé... nulle part en fait. Juste des fichiers statiques sur ma raspberry-pi.

Structure initiale

home-fonta/
├── index.html
├── presentation.html
├── services.html
├── galerie.html
├── menu.html
├── style.css
├── script.js
└── images/
    ├── aigle.jpg
    ├── Bust.jpg
    ├── fleur.jpg
    └── ...

Le problème des chemins absolus

Premier problème rencontré : mes fichiers HTML utilisaient des chemins absolus !

<!-- Dans index.html -->
<link rel="stylesheet" href="/style.css">
<script src="/script.js"></script>

<!-- Dans le JavaScript -->
fetch("/menu.html")

Ça fonctionnait en local avec file://, mais impossible à déployer sur un serveur dans un sous-dossier /home-fonta/.

Étape 1 : Migration vers un serveur Python simple

Ma première question : "J'ai 4 pages HTML, un CSS et un JavaScript, est-ce que je peux les adapter sur un serveur web Python ?"

J'hésitais entre Flask et http.server. Ne connaissant pas Flask, j'ai choisi la simplicité : http.server.

Le premier serveur Python

#!/usr/bin/env python3
"""
Serveur Web Python pour Home-Fonta.fr
Utilise le module http.server intégré à Python
"""

import http.server
import socketserver
import sys
import os

DEFAULT_PORT = 8000
DIRECTORY = "."

class CustomHTTPRequestHandler(http.server.SimpleHTTPRequestHandler):
    """Handler personnalisé avec logs"""
    def __init__(self, *args, **kwargs):
        super().__init__(*args, directory=DIRECTORY, **kwargs)

def main():
    port = int(sys.argv[1]) if len(sys.argv) > 1 else DEFAULT_PORT
    
    with socketserver.TCPServer(("", port), CustomHTTPRequestHandler) as httpd:
        print(f" Serveur démarré sur http://localhost:{port}")
        print(f" Servant le dossier : {os.path.abspath(DIRECTORY)}")
        httpd.serve_forever()

if __name__ == "__main__":
    main()

Correction des chemins

J'ai créé un script Python pour corriger automatiquement tous les chemins :

# fix_paths.py
def fix_html_paths(file_path):
    with open(file_path, 'r', encoding='utf-8') as f:
        content = f.read()
    
    # Remplacer les chemins absolus par des chemins relatifs
    replacements = [
        ('href="/style.css"', 'href="./style.css"'),
        ('src="/script.js"', 'src="./script.js"'),
        ('href="/images/', 'href="./images/'),
        ('fetch("/menu.html")', 'fetch("./menu.html")')
    ]
    
    for old, new in replacements:
        content = content.replace(old, new)
    
    # Sauvegarder avec backup
    shutil.copy2(file_path, f"{file_path}.backup")
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)

Configuration avec systemd

Pour que le serveur Python démarre automatiquement :

# /etc/systemd/system/home-fonta.service
[Unit]
Description=Home-Fonta.fr Python Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/html/home-fonta
ExecStart=/usr/bin/python3 /var/www/html/home-fonta/server.py 8000
Restart=always

[Install]
WantedBy=multi-user.target

Nginx en reverse proxy

# /etc/nginx/sites-available/home-fonta
server {
    listen 80;
    server_name home-fonta.fr;

    location /home-fonta/ {
        proxy_pass http://127.0.0.1:8000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Résultat de cette première migration

Site accessible sur http://home-fonta.fr/home-fonta/
Service systemd qui démarre automatiquement
Nginx comme reverse proxy
Mais... http.server n'est pas fait pour la production !

Les limitations de http.server

Après quelques jours, les problèmes sont apparus :

• Lenteur sur les gros fichiers
• Pas de gestion de cache
• Pas de compression gzip
• Single-threaded : une requête à la fois !
• Sécurité limitée

La décision : Il faut du vrai Python de production

Je me suis demandé : "Est-ce qu'il ne serait temps d'aller vers flask ?"
Alors j'ai fait des recherches sur les avantages de flask où Gunicorn était souvent mentionné.

La réponse était claire : Flask + Gunicorn serait bien meilleur pour la production. Mais avant ça, j'avais une autre idée...

"J'aimerais mettre le site sous Docker, je le fait dans une deuxième étape ? Ou c'est mieux de le faire en même temps ?"

Mais il ne faut pas se précipiter, je suis là pour apprendre : faire les choses progressivement. D'abord Docker avec le serveur Python simple, puis migrer vers Flask.

📝 Leçons apprises à ce stade

1. http.server = développement uniquement
2. Les chemins absolus sont un piège
3. systemd est pratique mais pas portable
4. Nginx en reverse proxy = bonne pratique
5. Toujours faire des backups avant de modifier

🎯 Bilan de cette première étape

Le site fonctionnait, mais c'était fragile. Il était temps de passer à l'étape suivante : Docker !

Suite : Partie 2 - La containerisation avec Docker