Hostinger a construit Web Apps Hosting autour d’un pitch simple : poussez votre code depuis GitHub, un fichier ZIP, ou votre agent de codage IA, et obtenez une app live, prête pour la prod, en environ une minute, sans serveur à gérer. Je voulais voir combien de ça tient vraiment quand c’est vous qui cliquez sur déployer, alors voilà ce que j’ai trouvé.

Déployez vos web apps plus vite avec Hostinger

Déployez des applications web modernes sur Hostinger avec des builds automatisés, une infrastructure managée, un CDN global, SSL, des outils de sécurité, et une garantie satisfait ou remboursé de 30 jours.

Visitez Hostinger

Avantages et inconvénients

Répartition de la note

Pour noter Hostinger Web Apps Hosting, j’ai appliqué la méthodologie de notation de HostAdvice, la même approche standardisée utilisée pour chaque avis sur le site, afin que les notes restent fondées sur des tests réels plutôt que sur du langage marketing. Voilà comment ça a été noté sur chaque paramètre.

Hébergez vos web apps sans la galère DevOps

Déployez des applications web modernes sur un hébergement entièrement managé avec déploiements automatisés, SSL managé, CDN global, et sécurité intégrée.

Visitez Hostinger

Offres et tarifs

Hostinger vend Web Apps Hosting en deux niveaux, Business et Cloud Startup, tous deux conçus spécifiquement pour déployer des apps Node.js et des applications JavaScript modernes plutôt que pour créer des sites web traditionnels.

Cloud Startup, le niveau que j’ai testé, double le nombre d’apps autorisées et les cœurs CPU par rapport à Business, et les deux offres incluent directement au moment du paiement un domaine gratuit, un email pro gratuit, et un SSL managé pour la première année.

Quelques points à savoir avant de commander :

• Garantie satisfait ou remboursé : Web Apps Hosting tombe sous les conditions standard de remboursement de Hostinger, une fenêtre simple de 30 jours à partir de la date d’achat. C’est nettement plus simple que ce qui s’applique aux offres VPS de Hostinger, qui ont en plus un délai de refroidissement de 180 jours entre deux demandes de remboursement. Aucun délai de ce type ne s’applique ici.
• Essai gratuit : Je n’ai trouvé aucun essai gratuit dédié. La garantie satisfait ou remboursé de 30 jours est votre période d’évaluation à la place.
• Moyens de paiement : Le paiement affichait la carte comme méthode par défaut, avec les logos Visa, Mastercard, Amex, et Discover, plus une option pour ajouter un autre moyen de paiement pendant le checkout.
• Ce qui est inclus : Un domaine gratuit pendant un an, des boîtes mail gratuites pendant un an, et un SSL managé sont tous inclus sans coût supplémentaire en plus du prix de l’offre, donc le prix affiché est très proche du coût réel pour mettre en ligne un déploiement complètement fonctionnel et sécurisé.
• L’unique upsell : Hostinger Reach, un add-on de marketing par email, apparaît dans le panier dans son propre encadré mis en avant avec un prix mensuel séparé. C’est facile à ignorer et ce n’est pas inclus ni pré-sélectionné par défaut.

Si vous annulez une offre Web Apps Hosting dans les 30 jours, la politique de remboursement de Hostinger confirme qu’elle entre dans les conditions standard plutôt que dans la liste des exclusions, donc une annulation simple dans cette fenêtre devrait donner droit à un remboursement sans les conditions supplémentaires attachées aux offres VPS ou aux achats de domaines.

Fonctionnalités

• Détection automatique du framework et de la version de Node
• Outils de création de base de données MySQL managée
• CDN global activé par défaut
• Protection WAF et DDoS incluse
• Sauvegardes quotidiennes et à la demande
• Scanner de malware et analyse des vulnérabilités
• Intégration GitHub avec auto-déploiement
• Domaine, email et SSL gratuits
• Accès SSH pour les utilisateurs avancés

Du code à l’app live avec Hostinger

Connectez votre dépôt GitHub ou téléversez votre projet et mettez-le en ligne avec une infrastructure managée, des déploiements automatiques, et des sauvegardes quotidiennes.

Visitez Hostinger

Performance

Comme Web Apps Hosting est entièrement managé, vous n’avez jamais accès au shell d’un serveur, donc il n’y a pas de CPU, de RAM, ou de disque à benchmarker directement comme dans un avis sur VPS.

Ce que vous pouvez mesurer, c’est la vitesse de chargement et de réponse de l’app déployée elle-même, depuis de vraies localisations partout dans le monde. J’ai testé ça depuis quatre angles différents : GTmetrix depuis deux continents, un check de cohérence globale de plus de 50 points, et l’outil de vitesse intégré de Hostinger pour le desktop et le mobile.

L’app testée est le déploiement Next.js couvert dans la section Facilité d’utilisation ci-dessous, en ligne sur ivory-llama-856835.hostingersite.com, tournant sur l’offre Cloud Startup (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), avec le CDN actif par défaut.

1. GTmetrix, testé depuis deux continents

J’ai lancé GTmetrix deux fois depuis différentes parties du monde pour voir si le résultat tenait la route de façon constante ou s’il avait juste l’air bon depuis un seul point de vue chanceux.

Les deux tests ont obtenu un 100% parfait en Performance et en Structure, avec zéro décalage de mise en page et zéro temps de blocage dans les deux emplacements, ce qui veut dire que rien sur la page n’a concurrencé l’attention du navigateur ou sauté pendant le chargement.

Le détail vraiment intéressant, c’est que Francfort a en fait battu Chicago sur toutes les métriques de timing, alors que j’avais délibérément choisi une localisation de serveur aux USA pour cette app. Ce résultat n’a de sens qu’à la lumière du CDN.

Une fois qu’un CDN est actif, comme c’était le cas ici par défaut, votre visiteur ne se connecte pas forcément directement au serveur d’origine.

Il se connecte au nœud edge mis en cache le plus proche, donc un point de test européen peut finir plus rapide qu’un point américain même si le vrai serveur se trouve aux USA. C’est une confirmation réelle et pratique que le CDN activé par défaut de Hostinger fait bien son travail au lieu de rester un simple bouton décoché.

2. Cohérence globale (Check-Host)

J’ai lancé un check HTTP sur l’URL live depuis tous les points de contrôle proposés par Check-Host, 54 localisations réparties sur six continents. Le tableau complet :

Chaque check réussi a renvoyé un 200 OK propre, sans erreur, sans échec partiel, sans redirection inattendue.

Les temps de réponse montraient clairement comment le cache du CDN se comporte à distance réelle :

Les points de contrôle européens ont renvoyé de façon constante les temps les plus rapides, plusieurs sous les 50 millisecondes, tandis que les points les plus éloignés physiquement de n’importe quel nœud edge, Tokyo, Singapour, Ho Chi Minh-Ville, renvoyaient quand même des réponses 200 valides, juste plus lentes, dans la plage de 0.3 à 0.8 seconde.

C’est la forme attendue pour un déploiement épaulé par un CDN : rapide près des edges, toujours pleinement fonctionnel loin d’eux.

Les quatre timeouts, Kazakhstan, Roumanie, et deux des quatre points de contrôle russes, ne sont pas quelque chose que j’interpréterais comme un problème de l’infrastructure de Hostinger.

D’autres points de contrôle dans les mêmes pays ont réussi (Saint-Pétersbourg est revenu propre à 0.063s alors que deux points de contrôle de Moscou ont expiré), ce qui pointe vers un filtrage réseau régional du côté du point de contrôle plutôt que vers un souci du côté de l’app déployée.

3. Outil de vitesse de Hostinger, desktop et mobile

Hostinger exécute son propre test Page Speed directement dans le dashboard de l’app, donc j’ai comparé ses chiffres aux résultats indépendants de GTmetrix au lieu de prendre l’un ou l’autre pour argent comptant.

Les deux types d’appareil ont obtenu un 100 parfait, et les chiffres desktop correspondent de près à ce que GTmetrix a mesuré indépendamment, ce qui est le vrai point d’exécuter les deux. Deux outils différents, deux méthodologies différentes, et ils sont d’accord entre eux.

Le mobile est arrivé plus lent sur toutes les métriques de timing, comme prévu sur une connexion simulée plus lente et un processeur plus faible, mais c’est quand même assez rapide pour qu’un score de 100 reflète une vraie bonne performance mobile, et pas juste une grille de notation généreuse.

Une incohérence dans l’outil lui-même. Même si la note est un 100 propre sur les deux appareils, le panneau Diagnostics en dessous signale quand même quelques éléments avec un score littéral de 0, network dependency tree, document request latency, et avoiding multiple redirects, ainsi que deux éléments notés 50, unused JavaScript et legacy JavaScript.

Aucun de ces sous-scores faibles n’a fait baisser la note principale, donc considérez-les comme de petites opportunités d’optimisation bien réelles plutôt que comme un problème du déploiement.

À part ça, les “liens utiles” que Hostinger affiche à côté de ces diagnostics sont tous rédigés pour WordPress, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, alors qu’il s’agit ici d’une app Node.js sans WordPress nulle part dans la stack. C’est un reste d’un modèle de diagnostics partagé plutôt qu’un contenu conçu pour ce produit.

Verdict global sur la performance

Hébergement Web App managé par Hostinger

Concentrez-vous sur la création de votre app pendant que Hostinger gère le déploiement, l’infrastructure, la sécurité, le SSL, les sauvegardes, et la diffusion mondiale.

Visitez Hostinger

Facilité d’utilisation

J’ai testé Web Apps Hosting de Hostinger depuis la page d’accueil jusqu’au checkout, puis depuis un compte tout neuf jusqu’à un déploiement Node.js entièrement en ligne et fonctionnel.

Ça couvrait le choix d’une offre, le paiement, le choix de la méthode de build, la connexion à GitHub, et le suivi du build en temps réel. Voilà à quoi ce processus ressemblait vraiment.

1. Inscription

J’ai commencé sur la landing page Web Apps Hosting, qui met en avant une seule call to action : Start deploying.

Cliquer dessus n’ouvre pas un formulaire d’inscription. Ça vous fait descendre directement jusqu’à la section tarifs, donc la première vraie décision que vous prenez est quelle offre acheter, pas quels identifiants de compte remplir.

Deux offres étaient affichées côte à côte :

J’ai choisi Cloud Startup pour avoir le double de capacité d’apps et plus de marge CPU que l’offre d’entrée de gamme. Un petit point d’incohérence à signaler ici : la page de tarifs l’appelle “Cloud Startup”, mais une fois dans le panier, la même offre est étiquetée “Startup plan”. Pas de souci fonctionnel, juste un décalage de nom entre deux écrans du même checkout.

Le panier était propre. Il listait la durée de 48 mois, les économies, un domaine gratuit pendant un an, et des boîtes mail gratuites, puis proposait un seul upsell, Hostinger Reach email marketing, dans son propre encadré mis en avant plutôt que présélectionné.

Je l’ai ignoré et j’ai cliqué sur Continuer sans friction.

Si vous êtes un nouveau client plutôt qu’un client existant, le checkout ajoute ici une étape de création de compte avant d’arriver à la page d’adresse de facturation et de paiement.

Ensuite, vous ajoutez une adresse de facturation, choisissez un moyen de paiement, carte, PayPal, ou l’une des autres options, puis vous validez. J’ai reçu un email de confirmation d’achat quelques instants après avoir cliqué sur Submit payment, puis j’ai atterri directement dans hPanel avec l’offre déjà provisionnée.

Mon avis : Le checkout est court et l’upsell est facile à refuser sans devoir chercher un lien de passage caché. Le décalage de nom entre la page de tarifs et le panier est un petit détail, mais c’est le genre de truc qui fait hésiter un premier acheteur et lui fait revérifier qu’il a bien choisi la bonne offre.

2. Tableau de bord

Une fois le paiement validé, vous arrivez dans hPanel, le panneau de contrôle maison de Hostinger, conçu pour gérer tous les produits qu’il vend, pas une page spécialement pensée pour votre nouvelle Web App.

La page d’accueil que vous voyez en premier est Home, et elle est construite autour d’une barre de prompt IA en haut : “Hi, [your name]! How can I help you today?” avec un champ de texte en dessous et six boutons de raccourci : Get domain, Create website, Get email, Migrate site, Get VPS, et Try email marketing.

En descendant, vous trouverez :

• Des tuiles de promotion de fonctionnalités pour AI Builder, l’outil boutique en ligne, la promesse d’un email pro gratuit, les agents IA, une app d’automatisation, et la promesse d’un domaine gratuit
• Une checklist de tâches qui vous pousse vers des étapes de configuration, terminer la config de Reach, réclamer votre email gratuit, réclamer votre domaine gratuit
• Your business, une liste en cours de tous les sites, apps, et instances VPS liés à votre compte, chacun avec son propre bouton Manage site
• VPS, un tableau séparé plus bas qui liste les éventuelles instances VPS par adresse IP, statut, et date d’expiration

Un panneau Agent reste aussi en permanence en haut à droite de chaque page hPanel, pas seulement sur Home. C’est le même assistant Kodee utilisé pour le support, mais placé ici comme outil d’action général avec des prompts prêts à l’emploi comme “Deploy my Node.js app” ou “Harden VPS updates” que vous pouvez lancer sans taper une question complète.

Home est vraiment utile une fois que votre app existe déjà, tout ce qui est dans Your business renvoie directement vers elle. Mais ce n’est pas là que vous allez pour créer une nouvelle Web App ou trouver le bouton Setup. Pour ça, il faut passer par un autre chemin dans la barre latérale :

1. Cliquez sur Websites dans la barre latérale de gauche
2. Un sous-menu s’ouvre en dessous : WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Cliquez sur Web Apps

Ce clic vous emmène vers un écran complètement différent de Home, organisé autour de vos offres d’hébergement réelles plutôt que d’une barre de prompt.

Ici, chaque offre que vous possédez a sa propre carte. Sur mon compte, ça donnait trois cartes empilées verticalement :

La carte Business avait aussi déjà une app live listée en dessous, orange-walrus-700988.hostingersite.com, avec ses propres boutons Tools et Dashboard.

C’est utile à noter en soi. Une fois qu’une Web App existe, sa carte ajoute une ligne comme ça qui montre directement le site live, exactement comme votre carte Cloud Startup ressemblera une fois la configuration terminée.

Puisque Cloud Startup était l’offre que je venais d’acheter et que je n’avais pas encore configurée, sa carte affichait seulement un bouton Setup. C’est ce bouton qui lance réellement l’assistant de création de Web App, et il n’apparaît qu’ici, sous Websites → Web Apps, pas depuis l’écran Home sur lequel vous arrivez par défaut.

Mon avis : hPanel est clair une fois qu’on a trouvé le bon écran, mais Web Apps Hosting n’a pas de porte d’entrée évidente. Arriver sur Home vous donne une barre de prompt et des raccourcis, pas un chemin pour créer une app, il faut savoir cliquer sur Websites, puis Web Apps, avant même de voir apparaître Setup. Ça fait quelques clics de plus pour un produit vendu comme “live in a minute”. Une fois là, en revanche, les cartes des offres sont propres et honnêtes sur le statut, et une offre avec une app déjà en ligne l’affiche directement sur la carte.

3. Déploiement de l’app

Cliquer sur Setup sur la carte de l’offre a ouvert un court flux d’onboarding : Where would you like to start? avec trois options, Create a new site, Migrate an existing site, ou I hired someone to build my site. J’ai choisi Create a new site.

Ça a mené à How do you want to build your website?, séparé entre deux options pour débutants en haut, Hostinger AI Builder et WordPress + AI, et deux options sous un sous-titre séparé “for advanced users” en dessous : Node.js web app et PHP/HTML website. Sélectionner Node.js web app est ce qui vous met réellement sur le produit Web Apps Hosting lui-même.

C’est une vraie précision structurelle pour toute personne qui compare les produits : Web Apps Hosting n’a pas son propre flux d’inscription dédié.

C’est une branche parmi les autres dans le même assistant général de création de site utilisé pour AI Builder et WordPress.

J’ai cliqué sur le cercle à côté de Node.js web app, puis j’ai cliqué sur Next.

Ensuite :

• Écran du domaine : j’ai choisi Use temporary domain au lieu de lier un vrai domaine, puisque c’était un déploiement de test.

• Écran de localisation du serveur : Hostinger a présélectionné la France, la région la plus proche de mon pays de facturation, et affichait 167ms de latence. En faisant défiler jusqu’à l’option United States, j’ai vu 364ms, soit plus du double.

J’ai quand même choisi United States, Massachusetts, et c’est exactement la leçon que l’écran de localisation enseigne sur chaque produit Hostinger : choisissez selon l’endroit où se trouvent vos vrais visiteurs, pas selon le plus petit nombre affiché dans la liste.

L’audience prévue pour mon app de test est basée aux USA, donc un serveur aux USA la servira réellement plus vite qu’un serveur en France, quel que soit le chiffre qu’il m’affichait depuis ma propre position. Le nombre à l’écran vous dit à quelle vitesse le serveur répond au test de Hostinger, pas à quelle vitesse il répondra aux personnes qui utiliseront vraiment votre site.

• Écran de méthode de déploiement : deux options principales, Import Git repository (marquée Recommended) ou Upload your files, plus un encart en dessous pour déployer directement depuis Claude Code, Cursor, ou VS Code via le Hostinger Connector. J’ai choisi Import Git repository et j’ai cliqué sur Connect with GitHub.

Ça a ouvert une vraie fenêtre de connexion GitHub si vous n’étiez pas déjà connecté, puis un écran d’autorisations intitulé Install & Authorize Hostinger, demandant de choisir entre :

• Installer sur all repositories que vous possédez, y compris les futurs, avec accès en lecture seule aux dépôts publics
• Installer uniquement sur only select repositories que vous choisissez individuellement et listant les permissions exactes accordées : accès en lecture à actions, metadata, et repository hooks, et accès en lecture-écriture à administration, code, et pull requests. Une fois que vous cliquez sur Install & Authorize, GitHub vous redirige automatiquement vers hPanel.

Vous arrivez sur Select Git repository to import, une liste déroulante de tous les dépôts liés à votre compte GitHub, chacun avec son propre bouton Deploy à côté. J’ai trouvé le dépôt de test que j’avais poussé auparavant, hostadvice-webapps-test, et j’ai cliqué sur Deploy à côté.

À partir du clic sur ce bouton, il s’est écoulé près de 30 secondes sans indicateur de progression à l’écran avant que la page suivante ne se charge, assez longtemps pour que vous vous demandiez si le clic avait été pris en compte.

La page qui se charge enfin s’intitule Review build settings, et elle vous dit exactement où votre app va vivre avant que vous ne validiez quoi que ce soit : “Deploys to ivory-llama-856835.hostingersite.com.” En dessous, sans que vous touchiez un seul champ, il avait déjà détecté automatiquement :

Chacune de ces cinq lignes a son propre bouton Change ou Add à côté, donc rien ici n’est verrouillé si la détection se trompe.

J’ai cliqué sur Add à côté de Environment variables et j’ai défini une paire clé-valeur pour vérifier qu’elle arriverait bien plus tard dans l’app en production, puis j’ai cliqué sur Finish dans cette fenêtre, puis sur le bouton principal Deploy en bas de la page.

Suivi du build

L’écran passe à une vue Deploying… avec une barre de progression étiquetée, “Deployment from GitHub,” qui avance par étapes réelles, je l’ai vue passer à 28%, puis 51%, avant d’aller jusqu’à la fin. Sous la barre de progression se trouve un panneau repliable Build logs, et l’ouvrir affiche une vraie sortie terminal en direct pendant qu’elle se produit, pas un spinner factice :

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Déploiement terminé

Une fois le build fini, vous arrivez sur un écran Deployment completed! avec un aperçu miniature en direct de votre vraie app affiché directement dans la carte, à côté d’un résumé montrant le nom du dépôt et l’URL live attribuée.

Depuis cette page, vous pouvez cliquer directement sur Go to dashboard, qui est l’endroit où vous gérez l’app par la suite.

Mon avis : La détection automatique est le point fort ici. Le framework, la branche, et la version de Node sont tous revenus corrects sans un seul champ manuel, et le log de build en direct rend l’attente transparente plutôt qu’opaque. Le seul point un peu faible, c’est ce pause de 30 secondes avant même d’atteindre l’écran des réglages, assez longue pour faire penser que quelque chose bloque avant que le processus ne démarre visiblement.

4. Vérification du déploiement live

Avant d’explorer les outils de gestion, je voulais confirmer que l’app avait vraiment été déployée et fonctionnait, pas juste marquée “Completed” à l’écran.

Depuis la page Deployment completed, j’ai cliqué directement vers l’URL live, ivory-llama-856835.hostingersite.com, plutôt que de me fier uniquement à la miniature de prévisualisation du dashboard.

La page live s’est chargée et a affiché exactement ce que l’app était censée montrer :

• Server build time, un horodatage live confirmant que la page venait d’être construite, pas servie depuis un vieux cache
• Environment variable check, montrant la variable personnalisée que j’avais définie pendant l’écran de déploiement, confirmée correctement sur le vrai site live, pas seulement dans l’aperçu du dashboard

J’ai ensuite cliqué sur le bouton Ping the API route de l’app, qui appelle un endpoint backend en direct plutôt que d’afficher seulement du contenu statique. Il a renvoyé une réponse JSON propre :

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

Cette réponse compte plus qu’on ne le croit. Une page qui se charge correctement prouve seulement que les fichiers statiques ont été téléversés.

Un appel API qui fonctionne prouve que le vrai serveur Node.js tourne derrière et répond à de vraies requêtes, la partie de l’hébergement “Node.js web app” qu’il est facile de simuler avec un fichier statique et difficile de simuler avec un horodatage live du serveur généré exactement au moment où vous cliquez sur un bouton.

Mon avis : C’est le check que je vous recommanderais avant de faire confiance à n’importe quel déploiement sur cette plateforme, ou sur une autre similaire. Un statut vert “Completed” et une miniature d’aperçu vous disent que le build est terminé. Cliquer jusqu’à l’URL live et déclencher quelque chose de dynamique, un appel API, une lecture de base de données, n’importe quoi qui ne peut pas être imité par une page statique mise en cache, vous dit que le serveur est vraiment vivant et fait ce que vous avez construit.

5. Gestion de la Web App

Une fois l’app live confirmée et fonctionnelle, je suis retourné dans hPanel et j’ai exploré le dashboard de gestion de l’app de bout en bout, la vraie couche de gestion serveur de ce produit, séparée de l’écran général Home déjà couvert plus haut.

Aperçu du dashboard. Dès que vous arrivez ici, quatre badges de statut vous donnent l’état d’un coup d’œil :

Les quatre étaient verts par défaut, sans rien que j’aie eu à activer manuellement. En dessous se trouve une carte Last deployment qui confirme l’état, le dépôt, l’auteur, le commit, l’heure de déploiement, la stack détectée, et la version de Node, tout ce que vous voulez vérifier d’un coup sans fouiller dans les logs.

Un Page Speed test automatique avait déjà été lancé tout seul sur le site live et affichait un score Desktop de 99/100 sans que je l’aie déclenché moi-même, à côté d’un panneau Essentials avec des liens rapides vers la connexion à la base de données, les sauvegardes, le gestionnaire de fichiers, les logs d’exécution, et le cache.

Déploiements, variables d’environnement, et logs. Trois pages séparées couvrent ça :

• Deployments gardait un historique complet du push, de l’auteur, de la branche, du hash du commit, et du statut de fin, un vrai historique plutôt que juste le plus récent
• Environment variables listait correctement celle que j’avais définie pendant le déploiement, confirmant qu’elle était bien stockée et appliquée, pas juste affichée une fois pendant la configuration puis oubliée
• Runtime logs diffusait en direct la sortie du serveur au fur et à mesure, lignes de démarrage Next.js, timestamps de ready, et un compteur en cours des issues et errors, qui est resté à zéro et zéro pendant tout le temps où j’ai regardé

Sécurité. Le Malware Scanner a renvoyé un résultat propre, “Your website is safe”, avec une précision dite clairement plutôt que cachée dans les petites lignes : il ne vérifie que les fichiers du site, pas le contenu de la base de données, et une option payante de nettoyage existe si vous voulez un scan plus poussé qui inclut la base de données. Le scan Vulnerabilities est aussi revenu propre.

Bases de données. C’est ici que le marketing du produit crée un vrai écart que vous devez comprendre avant d’acheter. L’offre annonce un MySQL managé comme fonctionnalité phare, mais rien n’est provisionné automatiquement pour vous.

La section Databases s’ouvre sur un formulaire manuel Create a New MySQL Database And Database User, ce qui veut dire que vous nommez et créez vous-même la base de données avant que votre app puisse en utiliser une. J’ai confirmé ça directement avec Kodee, comme expliqué dans la section Support plus bas, et la réponse était claire : managé veut dire que Hostinger gère l’infrastructure de la base de données en coulisses, pas qu’une base est créée pour vous dès que votre app est en ligne.

Accès avancé. L’accès SSH existe sous Advanced, avec IP, port, et username, mais il est Inactive par défaut et demande un clic manuel Enable avant que vous puissiez l’utiliser. File Manager propose un choix entre parcourir seulement les fichiers de cette app ou tous les fichiers de toute l’offre d’hébergement.

Mon avis : Le dashboard du quotidien est complet et bien organisé. La sécurité et l’historique de déploiement, en particulier, sont faciles à trouver et vraiment informatifs, et le runtime log à zéro erreur avec un scan de malware propre m’a donné une vraie confiance dans le fait que l’app allait bien, pas seulement qu’elle était en ligne.

Le seul endroit où l’interface survend un peu, c’est la section base de données, où “managed MySQL” donne l’impression sur la page de l’offre de quelque chose de prêt dès que votre app se met en ligne, alors qu’en pratique vous avez un formulaire de création manuel, simple à utiliser, mais une étape à faire vous-même.

Verdict global sur la facilité d’utilisation

Construisez, déployez, et scalez avec Hostinger

Hébergez des web apps modernes avec intégration GitHub, MySQL managé, CDN global, bande passante illimitée, et outils de sécurité intégrés.

Visitez Hostinger

Niveau de support

J’ai testé le support de Hostinger pour Web Apps Hosting via Kodee, l’assistant IA intégré à hPanel, puis j’ai parcouru la base de connaissances pour voir combien de terrain elle couvre sans avoir besoin de demander à quelqu’un. Kodee apparaît à deux endroits qu’il faut distinguer : comme Ask AI sur le site marketing public, et comme panneau Agent disponible depuis n’importe quelle page dans hPanel lui-même, y compris directement sur le dashboard propre à la Web App.

1. Support IA (Kodee)

J’ai posé deux questions construites autour de vraies zones d’ombre que j’avais trouvées pendant les tests, pas des recherches génériques auxquelles Kodee pourrait répondre en copiant depuis la documentation.

Question 1 testait le comportement en cas d’échec de déploiement et le timing des variables d’environnement, deux vraies préoccupations de prod pour n’importe qui qui envoie quelque chose sur cette plateforme :

Si le build de mon app échoue en plein milieu d’un déploiement GitHub, l’app revient-elle automatiquement à la dernière version réussie, ou bien tombe-t-elle jusqu’à ce que je corrige et redéploie ? Et puis-je définir des variables d’environnement personnalisées avant le premier déploiement, ou seulement après ?

Kodee a répondu directement et correctement sur les deux points. Un build qui échoue ne remplace pas une app qui tourne déjà, s’il y a eu un déploiement précédent réussi, l’app continue de servir cette dernière version fonctionnelle. Si c’est le tout premier déploiement et qu’il n’y a rien à restaurer, l’app reste hors ligne jusqu’à ce que le build soit corrigé et redéployé, une réponse claire et honnête plutôt qu’une vague assurance.

Sur les variables d’environnement, il a confirmé que vous pouvez les définir avant le premier déploiement dans les paramètres de déploiement, et pour une app déjà en ligne, il a détaillé les trois étapes exactes : ouvrir Settings et Redeploy, ajouter ou modifier les variables sous Environment variables, enregistrer et redéployer.

Question 2 a poussé sur les deux points qui m’avaient moi-même sauté aux yeux dans le dashboard, la formulation “managed MySQL” face au formulaire manuel de création, et le SSH affiché comme inactif par défaut :

Cette offre annonce un MySQL managé, mais le dashboard affiche un formulaire manuel ‘Create a New MySQL Database’ au lieu d’une base de données provisionnée automatiquement. Une base est-elle créée par défaut pour chaque Web App, ou seulement si j’en crée une moi-même ? Et puis, l’accès SSH est listé comme disponible mais apparaît comme Inactive par défaut. Si je ne l’active jamais, est-ce que ça change quelque chose à la façon dont mon app fonctionne réellement, ou est-ce que SSH est simplement un extra optionnel pour les utilisateurs avancés ?

La réponse de Kodee a confirmé exactement ce que j’avais trouvé dans l’interface, pas une version adoucie. Une base de données n’est pas créée automatiquement pour chaque Web App, “managed” veut dire que Hostinger gère le service et l’infrastructure de la base de données, tandis que la création et la configuration d’une vraie base sont à votre charge, via le même écran Create a New MySQL Database que j’avais déjà vu, puis vous devez ajouter vous-même ses informations de connexion dans les variables d’environnement de votre app.

Pour SSH, il a confirmé que le laisser inactif ne change rien à la façon dont l’app fonctionne, se déploie, ou se connecte à une base de données. Il est présenté purement comme un outil optionnel pour des commandes CLI, des migrations, ou le débogage direct de fichiers, pas comme quelque chose sur lequel la plateforme dépend discrètement en arrière-plan.

Mon avis : Les deux réponses correspondaient à ce que j’avais déjà vérifié moi-même dans le dashboard au lieu de le contredire ou de l’adoucir, ce qui est le signe d’un outil de support qui vérifie vraiment l’état du produit plutôt que de réciter un script. Aucune des deux questions ne pouvait être résolue en copiant-collant une FAQ générique, et Kodee a géré les deux avec des réponses spécifiques, structurées, en deux parties, en environ une minute chacune.

2. Base de connaissances

La base de connaissances de Hostinger s’ouvre sur une grille catégorisée, 20 catégories au total, chacune affichant un nombre d’articles. Parmi les plus grosses : AI Builder compte 330 articles, VPS en compte 276, Email 127, et Website 103.

Web Apps Hosting n’a pas sa propre catégorie dédiée. Son contenu est dispersé entre Getting Started, hPanel, et Website, ce qui est un vrai constat pour toute personne qui s’attend à un point d’entrée unique, comme VPS ou Email en ont un.

Une recherche sur “Web Apps” a renvoyé 71 résultats sur 8 pages. Les premiers résultats étaient un mélange de contenus vraiment pertinents et d’autres à peine liés :

• How to deploy apps built with Codex on Hostinger, directement pertinent
• Hostinger AI Builder: How to create a web app in agentic mode, proche mais pour un autre produit
• How to add a Node.js Web App in Hostinger, directement pertinent
• How to install Flutter Web on a VPS at Hostinger, un autre produit complètement différent
• Plusieurs articles Website Builder sur les moyens de paiement (PayPal, WeChat Pay, BLIK), sans rapport à part partager les mots “web” et “app” quelque part dans le texte

J’ai ouvert un des premiers résultats, How to deploy apps built with Codex on Hostinger, pour voir sa profondeur. Il s’est avéré être un guide très complet et bien structuré, avec les frameworks pris en charge listés dès le départ, des captures pas à pas pour les chemins d’import GitHub et d’upload ZIP, une section sur la configuration des paramètres de build avec des commandes d’exemple, un aperçu détaillé de la structure des fichiers après déploiement, un walkthrough du wizard de connexion à la base de données, une section sur la surveillance des vulnérabilités, et un bloc FAQ de fin.

Même s’il est cadré autour de Codex, la plateforme sous-jacente est la même que celle du produit Node.js Web App général, donc la plupart de son contenu s’applique directement.

Mon avis : Le nombre d’articles dans la recherche a l’air solide sur le papier, 71 résultats pour un seul terme, mais une part significative de ce volume est du bruit provenant de produits sans rapport qui partagent un vocabulaire similaire. L’article que j’ai ouvert en entier tenait bien la route en qualité une fois dedans, étapes claires, vraies captures, et vraie section FAQ, mais le trouver demandait de faire défiler des résultats qui n’avaient rien à voir avec ce que j’essayais réellement de déployer.

Verdict global sur le support client

Hébergement simple pour les web apps modernes

Déployez React, Next.js, Vue, Node.js, et d’autres applications modernes sans gérer de serveurs ni d’infrastructure complexe.

Visitez Hostinger

Recommande-t-on Hostinger Web Apps Hosting ?

Oui. Le processus de déploiement est le point fort de ce produit : détection automatique correcte de ma stack, de ma branche, et de ma version de Node, vrai log de build en streaming au lieu d’un spinner, et une app live qui a passé tous les tests de performance que je lui ai fait subir, des scores GTmetrix parfaits depuis deux continents différents, un check de cohérence globale propre sur 54 points, et des scores 100/100 concordants dans l’outil de Hostinger sur desktop et mobile. Kodee a renforcé ça avec des réponses exactes et précises à de vraies questions techniques plutôt qu’avec des réponses génériques de script.

Les petits défauts sont mineurs mais bons à connaître avant d’acheter. “Managed MySQL” donne l’impression sur la page de l’offre de quelque chose de prêt dès que votre app est en ligne, et en pratique ça veut dire un formulaire de création manuel. Le dashboard ne donne pas non plus à Web Apps Hosting de point d’entrée dédié depuis l’écran principal Home, il faut savoir aller dans Websites d’abord.

Pour un développeur qui veut un déploiement rapide et agnostique vis-à-vis du framework sur une infrastructure qui benchmarke aussi bien, c’est une recommandation facile. Pour quelqu’un qui s’attend à ce que chaque fonctionnalité annoncée soit activée dès la fin du checkout, prévoyez quelques minutes de plus pour configurer la base de données vous-même.

Hostinger

5.0

2,473 user reviews

16 MAD /mo

Prix de départ

Visitez Hostinger

Rating based on expert review

• Convivialité
  4.9
• Assistance
  4.9
• Caractéristiques
  4.8
• Fiabilité
  4.7
• Tarif
  4.5