Déployer une application Django en production avec Gunicorn et Nginx

Du projet fonctionnel à l’application en ligne

Au fil des neuf épisodes précédents, nous avons construit une application complète d’entretien d’embauche basée sur l’IA : analyse de documents, pipeline d’agents, traitement en arrière-plan, voix et évaluation. Dans la partie 9, elle fonctionnait de bout en bout sur un ordinateur portable. Cette dernière partie s’attaque à l’étape que la plupart des tutoriels négligent : la mettre en ligne de manière fiable, afin que de vrais utilisateurs puissent y accéder. Cela signifie déployer une application Django en production avec Gunicorn et Nginx, mais aussi configurer le SSL, les journaux et une procédure de déploiement reproductible.

Ce guide part du principe qu’un élément est déjà en place : une base de données de production. SQLite ne convient pas à un véritable déploiement. Avant de commencer, vous devrez donc disposer d’un serveur de base de données adapté : PostgreSQL ou MySQL, chacun faisant l’objet de son propre guide. Une fois cette base prête, le reste de ce tutoriel met l’application elle-même en ligne.

L’architecture est standard et éprouvée : Nginx se place en première ligne pour gérer le HTTPS et les fichiers statiques, puis transmet les requêtes dynamiques via un socket local à Gunicorn, qui exécute réellement Django. Rien d’exotique : chaque outil se charge simplement de la tâche pour laquelle il est conçu.

Exécuter Gunicorn comme service systemd

Gunicorn est le serveur d’application qui exécute Django en production. Plutôt que de le lancer manuellement, nous laissons systemd le gérer : il démarre au démarrage du système, redémarre en cas de plantage et se contrôle comme n’importe quel autre service. Cette configuration utilise deux unités : un socket et un service.

L’unité socket crée le socket Unix auquel Nginx se connectera :

# /etc/systemd/system/aiinterviewer.socket
[Unit]
Description=aiinterviewer gunicorn socket

[Socket]
ListenStream=/run/aiinterviewer.sock

[Install]
WantedBy=sockets.target

L’unité de service exécute Gunicorn lui-même, en l’attachant à ce socket :

# /etc/systemd/system/aiinterviewer.service
[Unit]
Description=aiinterviewer gunicorn daemon
Requires=aiinterviewer.socket
After=network.target

[Service]
Group=www-data
WorkingDirectory=/var/www/ai_interviewer
ExecStart=/var/www/ai_interviewer/venv/bin/gunicorn \
    --workers 3 \
    --timeout 180 \
    --log-level info \
    --capture-output \
    --bind unix:/run/aiinterviewer.sock \
    --access-logfile /var/www/ai_interviewer/media/log/gunicorn/access.log \
    --error-logfile /var/www/ai_interviewer/media/log/gunicorn/error.log \
    ai_interviewer.wsgi:application

[Install]
WantedBy=multi-user.target

Quelques options de Gunicorn méritent d’être expliquées. --workers 3 lance trois processus workers afin de traiter les requêtes en parallèle : pour commencer, on utilise souvent environ deux fois le nombre de cœurs du processeur, plus un. --timeout 180 est volontairement généreux ici : cette application effectue des appels d’IA lents, et la valeur par défaut, plus stricte, interromprait les requêtes longues. Consultez la documentation des paramètres de Gunicorn pour obtenir la liste complète.

Une fois les unités créées, rechargez systemd et démarrez le socket : Gunicorn se lance automatiquement dès qu’une première requête lui est adressée :

sudo systemctl daemon-reload
sudo systemctl start aiinterviewer.socket
sudo systemctl enable aiinterviewer.socket

# verify the socket exists and responds
sudo systemctl status aiinterviewer.socket
curl --unix-socket /run/aiinterviewer.sock localhost

Nginx comme proxy inverse

Nginx est la porte d’entrée publique de l’application. Il sert directement les fichiers statiques (rapidement, sans faire intervenir Python) et transmet tout le reste à Gunicorn via le socket :

# /etc/nginx/sites-available/aiinterviewer
server {
    listen 80;
    server_name ai-interviewer.tech www.ai-interviewer.tech;

    location = /favicon.ico { access_log off; log_not_found off; }

    location /static/ {
        root /var/www/ai_interviewer;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/aiinterviewer.sock;
    }
}

Activez le site, testez la configuration avant de recharger Nginx (une erreur de syntaxe pourrait sinon mettre le serveur hors service), puis redémarrez-le :

sudo ln -s /etc/nginx/sites-available/aiinterviewer /etc/nginx/sites-enabled
sudo nginx -t          # always test before reloading
sudo systemctl restart nginx

Servir les fichiers statiques depuis Nginx plutôt que depuis Django est essentiel : Nginx est conçu pour cela, et vos workers Python restent ainsi disponibles pour traiter les requêtes qui en ont réellement besoin.

HTTPS avec Certbot

Une application de production n’a aucune raison de fonctionner en HTTP simple, surtout lorsqu’elle traite des CV. Certbot obtient gratuitement un certificat Let's Encrypt et reconfigure Nginx pour le HTTPS en une seule commande :

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d ai-interviewer.tech -d www.ai-interviewer.tech

Certbot modifie la configuration de Nginx pour servir le HTTPS, met en place la redirection de HTTP vers HTTPS et installe un minuteur chargé de renouveler automatiquement le certificat avant son expiration. C’est l’un des rares moments de l’administration système où tout fonctionne presque immédiatement.

Pare-feu, rotation des journaux et déploiements reproductibles

Trois dernières étapes transforment un serveur fonctionnel en serveur réellement exploitable.

Un pare-feu, afin que seuls les ports nécessaires soient accessibles : SSH et le trafic web, rien d’autre :

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

La rotation des journaux, pour éviter que les journaux d’accès et d’erreurs de Gunicorn ne remplissent discrètement le disque. Cette configuration conserve 90 jours de journaux compressés :

# /etc/logrotate.d/aiinterviewer
/var/www/ai_interviewer/media/log/gunicorn/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

L’option copytruncate est particulièrement importante pour Gunicorn : elle permet de faire tourner les journaux sans devoir envoyer un signal au processus ni le redémarrer. Sans gestion adaptée, les journaux sont l’une des causes les plus fréquentes de saturation du disque d’un petit serveur après quelques mois.

Un script de déploiement, afin qu’une mise à jour se résume à une commande plutôt qu’à une suite d’étapes à retenir :

# build.sh
#!/bin/bash
git pull origin master
source venv/bin/activate
python manage.py migrate --noinput
python manage.py collectstatic --noinput
sudo systemctl restart aiinterviewer
echo "Build completed!"

Chaque déploiement exécute désormais les mêmes étapes dans le même ordre : récupérer le code, appliquer les migrations, collecter les fichiers statiques, puis redémarrer. Automatiser cette procédure n’est pas qu’une question de confort : cela évite d’oublier une étape à deux heures du matin, moment où les déploiements ont souvent lieu.

L’application est en ligne : la série touche à sa fin

Voilà le parcours complet : d’un projet Django vide à une application d’entretien d’embauche basée sur l’IA, accessible sur un véritable domaine et protégée par HTTPS, qui analyse des CV, mène un entretien vocal piloté par des agents, évalue les réponses et génère un compte rendu. Chaque étape correspond à une fonctionnalité réelle, construite et déployée, et non à un simple projet de démonstration.

Vous pouvez essayer gratuitement le produit final, sans inscription, à l’adresse ai-interviewer.tech. Si vous préférez partir directement du code complet, prêt pour la production, plutôt que de reconstruire vous-même les dix parties — prompts optimisés, composants renforcés et déploiement complet inclus — il est proposé dans l’AI Mock Interview SaaS Starter Kit. Que vous le développiez vous-même ou que vous partiez de cette base, vous savez désormais précisément ce qui entre dans la conception d’un véritable produit d’IA, de bout en bout.