Hébergement d’applications : Node.js, Python, Docker

Certains liens de cette page sont des liens d'affiliation : si vous souscrivez après avoir cliqué, nous percevons une commission, sans surcoût pour vous. Cela ne change ni notre classement ni nos réserves, qui reposent sur les caractéristiques réelles des offres. En savoir plus

Dès qu'un projet sort du couple PHP-MySQL, l'hébergement mutualisé classique devient inadapté : il faut un processus qui tourne en continu, un gestionnaire de dépendances, souvent un conteneur.

Trois familles de solutions : le VPS que vous administrez, la plateforme applicative (PaaS) qui exécute votre code sans que vous gériez de serveur, et le cloud avec ses services managés.

Pourquoi le mutualisé ne convient plus

L'hébergement mutualisé a été conçu pour un modèle précis : un serveur web reçoit une requête, exécute un script, renvoie une page, et oublie tout. Ce fonctionnement convient parfaitement à PHP et aux CMS traditionnels.

Une application Node.js, Python ou Go fonctionne autrement : un processus démarre et reste en mémoire, gère lui-même les connexions entrantes et conserve un état entre les requêtes. Ce modèle est incompatible avec le cloisonnement d'un mutualisé, qui n'autorise pas de processus permanent.

• Pas de processus en tâche de fond, donc pas de serveur applicatif
• Pas de gestionnaire de dépendances ni de compilation
• Pas de services annexes comme un cache mémoire, une file d'attente ou un moteur de recherche
• Pas de conteneurs, ni de contrôle sur les versions de langage

Quelques hébergeurs proposent un support limité de Node.js ou Python en mutualisé. Cela dépanne pour un prototype, mais les contraintes se font sentir dès que le projet devient sérieux.

Trois familles de solutions

L'arbitrage se résume à une question : le temps que vous passeriez à construire et maintenir la chaîne de déploiement vaut-il plus ou moins que l'écart de prix avec une plateforme qui la fournit ?

Pour une équipe de développement sans administrateur système dédié, la réponse penche presque toujours vers la plateforme applicative. Pour un projet personnel ou un développeur à l'aise en administration, le VPS reste imbattable économiquement.

Les alternatives françaises et européennes

Le marché des plateformes applicatives n'est pas exclusivement américain, ce que l'on oublie souvent. Plusieurs acteurs français hébergent les données en France, offrent un support francophone et proposent des certifications adaptées aux données sensibles.

Cela compte pour trois catégories de projets : ceux du secteur public, ceux qui traitent des données de santé ou d'autres données sensibles, et ceux dont les clients posent la question de la souveraineté dans leurs appels d'offres.

Ces plateformes facturent généralement à l'usage, sans grille publique lisible : il faut passer par leur estimateur pour obtenir un ordre de grandeur sur votre charge réelle.

Bases de données : managées ou auto-hébergées

C'est la décision qui a le plus d'impact sur la fiabilité, et elle est souvent prise par défaut plutôt que par choix.

Installer une base sur le même serveur que l'application ne coûte rien de plus et fonctionne parfaitement en développement. En production, cela signifie que vous êtes responsable des sauvegardes, des mises à jour, de la réplication et de la restauration après incident.

Une base managée coûte davantage, mais apporte sauvegardes automatiques avec restauration à un instant donné, mises à jour appliquées, et souvent réplication. Sur un projet de production, l'écart de prix se justifie généralement dès le premier incident évité.

• En développement et en test : base locale ou sur le même serveur, sans hésitation.
• En production sans équipe d'exploitation : base managée, le surcoût est une assurance.
• En production avec des compétences internes : l'arbitrage dépend du temps disponible et du niveau de service attendu.

Ce qu’il faut prévoir dès le départ

Quatre éléments coûtent peu à mettre en place au démarrage et très cher à rattraper ensuite.

• La séparation des environnements. Un environnement de production distinct du développement, avec des données et des accès séparés. Travailler directement en production finit toujours mal.
• Les variables d'environnement. Aucun secret, mot de passe ou clé d'API dans le dépôt de code. C'est la première chose que cherchent les robots qui scannent les dépôts publics.
• Les journaux applicatifs. Sans journaux exploitables, diagnostiquer un incident en production relève de la divination.
• Une supervision minimale. Une vérification externe qui alerte quand le service ne répond plus, pour ne pas l'apprendre par un utilisateur.

À qui cela s'adresse

• Applications Node.js, Python, Ruby, Go
• Projets conteneurisés
• API et services back-end

À éviter dans ces cas

• Sites vitrines statiques
• Projets WordPress classiques