Hébergement Python
« Ça marchait chez moi » est un problème d’hébergement
Une application Python se déploie bien à condition que son environnement soit reproductible. C’est le premier point que nous regardons — avant la mémoire, avant la charge.
- Environnement isolé et reproductible, versions figées
- Serveur ASGI pour FastAPI, WSGI pour Django
- Ouvriers de tâches de fond supervisés
- Serveur privé ou conteneur, infogéré, en France
Le principe
Trois choses à régler, dans cet ordre
L’environnement, d’abord
C’est la particularité de Python en exploitation, et la cause la plus fréquente des mises en production qui se passent mal. Une application dépend d’une version précise de l’interpréteur et d’un jeu de bibliothèques dont les versions comptent — y compris celles que vos dépendances installent sans que vous les ayez demandées.
Nous figeons donc l’ensemble : un environnement isolé, des versions explicitement fixées, et une installation reproductible à l’identique. Le même jeu de dépendances en recette et en production, reconstructible dans six mois comme aujourd’hui. Sans cela, un serveur remonté après incident n’exécute plus tout à fait la même application.
Le bon serveur devant l’application
Python ne sert pas les requêtes tout seul. Il faut un serveur d’application devant, et il n’est pas le même selon l’outil :
- FastAPI repose sur les standards ASGI pour l’asynchronisme : c’est un serveur ASGI qu’il lui faut, faute de quoi tout l’intérêt de l’architecture asynchrone disparaît — c’est une erreur de configuration silencieuse et coûteuse.
- Django fonctionne classiquement en WSGI, avec plusieurs ouvriers en parallèle.
Dans les deux cas, un reverse proxy est placé devant : il porte le certificat SSL, le nom de domaine, la compression et sert les fichiers statiques — que Python n’a aucune raison de servir lui-même.
Ce qui tourne en dehors des requêtes
Beaucoup d’applications Python font aussi des choses sans qu’on les sollicite : imports, envois, traitements planifiés, consommation de files de messages. Ces ouvriers tournent en permanence ; ils doivent être supervisés et relancés automatiquement, exactement comme l’application elle-même.
C’est le point qu’on découvre tard : une file dont le consommateur est mort continue d’accepter des travaux que plus rien ne traite, et rien ne le signale.
Serveur privé ou conteneur
Une application Python ne peut pas vivre sur une plateforme mutualisée : c’est un programme permanent. Le serveur privé est le plus simple. Le conteneur se justifie quand vous déployez souvent ou quand plusieurs environnements doivent être strictement identiques — l’image règle alors la question de la reproductibilité une fois pour toutes.
Le socle
Ce que nous mettons en place
-
Environnement figé
Interpréteur et bibliothèques en versions explicites, installation reproductible à l’identique. Le même jeu en recette qu’en production.
-
ASGI ou WSGI
Serveur ASGI pour FastAPI — sans quoi l’asynchronisme ne sert à rien — ou WSGI avec plusieurs ouvriers pour Django.
-
Reverse proxy
Certificat SSL automatique, nom de domaine, compression, et service des fichiers statiques que Python n’a pas à servir lui-même.
-
Ouvriers supervisés
Tâches planifiées, imports, consommateurs de files : relancés automatiquement s’ils s’arrêtent, et l’incident remonte.
-
Base et cache
MariaDB, PostgreSQL ou une base spécialisée ; Redis, KeyDB ou Memcached pour les sessions, le cache et les files.
-
Exploitation complète
Mises à jour du système, sauvegarde répliquée hors site, correction automatique sur alerte et administrateur d’astreinte.
Questions fréquentes
Hébergement Python : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Puis-je héberger du Python sur votre mutualisé ?
Non : une application Python est un programme qui tourne en permanence, alors qu’une plateforme mutualisée exécute un script à l’arrivée d’une requête puis l’oublie. Il lui faut un serveur privé ou un conteneur.
Comment garantissez-vous que l’environnement est le bon ?
En figeant les versions de l’interpréteur et de toutes les bibliothèques — y compris celles installées indirectement — et en rendant l’installation reproductible à l’identique. C’est ce qui permet de remonter le serveur après un incident et d’obtenir exactement la même application.
Mon API FastAPI sera-t-elle vraiment asynchrone ?
Seulement si elle est servie par un serveur ASGI. C’est une erreur de configuration silencieuse et fréquente : l’application fonctionne, mais elle perd tout l’avantage de son architecture asynchrone, et cela ne se voit qu’en charge. Nous le vérifions à la mise en service.
Faut-il conteneuriser ?
Pas obligatoirement, mais c’est là que le conteneur apporte le plus : l’image fige l’environnement une fois pour toutes, ce qui règle la principale difficulté d’exploitation d’une application Python. À considérer si vous déployez souvent.
Savez-vous reconstruire votre environnement à l’identique ?
Si la réponse demande réflexion, c’est le premier point à traiter — avant la charge et avant le dimensionnement.