Héberger « Fake Images Please » sur un mutualisé o2switch : retour d’expérience et guide technique

Lorsque l’on développe des sites web, disposer d’un générateur d’images placeholder fiable est un confort indispensable. Pendant longtemps, fakeimg.pl a rempli ce rôle. Le site n’étant plus maintenu, j’ai choisi d’auto-héberger le projet open source : Fake Images Please.

Le défi ?
Déployer une application Flask moderne sur un hébergement mutualisé o2switch, sans Docker, sans Gunicorn, et sans compromettre ni la sécurité ni la performance.

Cet article documente la démarche complète, les choix techniques effectués et les bonnes pratiques à retenir.

Pourquoi « Fake Images Please » ?

« Fake Images Please » est un générateur d’images placeholder open source, simple, rapide et suffisamment flexible pour couvrir la majorité des cas d’usage :

• tests d’intégration front-end
• maquettes UX
• environnements de staging
• prototypage rapide

L’objectif était clair : reprendre le contrôle de l’outil, garantir sa pérennité et l’héberger sur une infrastructure accessible aux projets de mes clients.

Contraintes de départ : l’hébergement mutualisé

Sur un mutualisé o2switch, plusieurs limites structurantes s’imposent :

• ❌ pas de Docker
• ❌ pas de démon long-running personnalisé
• ❌ pas de contrôle sur les dépendances système
• ✅ support Python via Passenger WSGI

Il fallait donc adapter le projet pour respecter ces contraintes, sans dégrader l’architecture logicielle.

Mise en place de l’environnement

Création du sous-domaine

L’application est isolée sur un sous-domaine dédié (fakeimg.domaine.tld), ce qui permet :

• une meilleure lisibilité d’infrastructure
• une séparation claire des responsabilités
• une gestion SSL indépendante

Le certificat Let’s Encrypt est généré directement depuis cPanel, avec redirection HTTPS forcée.

Audit de sécurité préalable

Avant tout déploiement, un audit rapide du code source s’impose.

Points rassurants

• validation stricte des dimensions (protection anti-DoS)
• taille maximale des images limitée à 4000px
• aucune exécution de code arbitraire
• chemins de polices contrôlés
• headers HTTP cohérents

Point de vigilance

• le paramètre text n’est pas validé côté serveur

Dans le contexte d’un générateur d’images sans stockage ni exécution dynamique, le risque reste maîtrisé.
Conclusion : application compatible avec un mutualisé, sous réserve d’un usage raisonnable.

Adaptation de l’architecture Flask

Le projet original est pensé pour être lancé via Gunicorn, ce qui n’est pas exploitable ici.
La solution consiste à exposer une application WSGI standard, compatible avec Passenger.

Séparation claire des responsabilités

• app.py : point d’entrée applicatif
• passenger_wsgi.py : point d’accroche pour le serveur

Cette approche respecte les standards WSGI et garantit :

• portabilité
• maintenabilité
• compatibilité future avec d’autres hébergeurs

Configuration Python dans cPanel

L’application est déclarée via Setup Python App, avec les paramètres suivants :

• Python 3.9.23
• entry point : application
• startup file : passenger_wsgi.py

Pourquoi Python 3.9 ?

• compatibilité optimale avec Pillow
• version maintenue et sécurisée
• stabilité éprouvée en production
• support des fonctionnalités modernes du langage

Dépendances et installation

Les dépendances sont installées dans l’environnement virtuel fourni par o2switch :

• Flask 3.x
• Pillow 10.x
• Jinja2
• Werkzeug
• pilmoji / emoji

Bien que Gunicorn ne soit plus utilisé, il est conservé dans les dépendances pour rester aligné avec le projet upstream.

Mise en production et validation

Une fois l’application redémarrée depuis cPanel, les tests sont immédiats :

• page d’accueil
• génération d’images simples
• couleurs personnalisées
• texte dynamique
• paramètres avancés (retina, fonts, etc.)

Le comportement est conforme à l’instance officielle, avec des temps de réponse satisfaisants pour un mutualisé.

Performance et sécurité en conditions réelles

Performance

• limitation de taille intégrée
• génération d’images à la volée
• headers de cache correctement définis
• support PNG et WebP

Sécurité

• aucune écriture disque persistante
• aucune donnée utilisateur stockée
• surface d’attaque réduite
• consommation CPU maîtrisée

Dans un contexte d’usage raisonnable, la solution est parfaitement viable.

Limites connues et alternative VPS

Certaines contraintes restent inhérentes au mutualisé :

• dépendances système non maîtrisables
• montée en charge limitée
• personnalisation avancée impossible

Pour un usage intensif ou public, un VPS avec Docker reste la meilleure option.
Dans ce cas, le déploiement devient trivial et hautement scalable.

Conclusion

Auto-héberger « Fake Images Please » sur un mutualisé o2switch est non seulement possible, mais proprement réalisable, à condition de respecter les standards WSGI et d’adapter intelligemment l’architecture.

Cette approche démontre qu’avec un minimum de rigueur :

• un mutualisé peut héberger autre chose que du PHP
• Python et Flask restent des options crédibles
• sécurité et pédagogie ne sont pas incompatibles

Un bon rappel qu’en technique, les contraintes ne sont pas des blocages, mais des cadres de conception.