Hostinger a construit Web Apps Hosting autour d’une promesse simple : poussez votre code depuis GitHub, un fichier ZIP ou votre agent de codage IA, et obtenez une application en production en ligne en environ une minute, sans serveur à gérer. Je voulais voir combien de cela tient réellement la route quand c’est vous qui cliquez sur déployer, alors voici ce que j’ai trouvé.

Deploy Web Apps Faster with Hostinger

Deploy modern web apps on Hostinger with automated builds, managed infrastructure, global CDN, SSL, security tools, and a 30-day money-back guarantee.

Visitez Hostinger

Avantages et inconvénients

Répartition des notes

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 scores restent ancrés dans de vrais tests plutôt que dans le langage marketing. Voici comment cela s’est noté selon chaque paramètre.

Host Your Web Apps Without the DevOps Hassle

Deploy modern web applications on fully managed hosting with automated deployments, managed SSL, global CDN, and built-in security.

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 applications Node.js et JavaScript modernes plutôt que pour créer des sites web traditionnels.

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

Quelques points à connaître avant de commander :

• Garantie de remboursement : Web Apps Hosting relève des conditions standard de remboursement d’Hostinger, soit une fenêtre simple de 30 jours à partir de la date d’achat. C’est nettement plus simple que pour les offres VPS d’Hostinger, qui comportent un délai de refroidissement supplémentaire 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 de remboursement de 30 jours est votre période d’évaluation à la place.
• Méthodes de paiement : Le paiement affichait la carte comme méthode par défaut, avec les logos Visa, Mastercard, Amex et Discover, ainsi qu’une option permettant d’ajouter une autre méthode de paiement pendant le processus de paiement.
• 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, de sorte que le prix affiché se rapproche du coût réel pour mettre en ligne un déploiement complètement fonctionnel et sécurisé.
• L’option supplémentaire : Hostinger Reach, un module complémentaire de marketing par e-mail, apparaît dans le panier dans son propre encadré mis en avant avec un prix mensuel distinct. Il est facile de l’ignorer et il 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 d’Hostinger confirme qu’elle relève des conditions standard plutôt que de la liste d’exclusion, donc une annulation simple dans ce délai 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 mondial 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 déploiement automatique
• Domaine, e-mail et SSL gratuits
• Accès SSH pour les utilisateurs avancés

From Code to Live App with Hostinger

Connect your GitHub repository or upload your project and get it online with managed infrastructure, automatic deployments, and daily backups.

Visitez Hostinger

Performances

Comme Web Apps Hosting est entièrement managé, vous n’obtenez jamais d’accès shell à un serveur, donc il n’y a ni CPU, ni RAM, ni disque à comparer directement comme on le ferait pour un avis sur un VPS.

Ce que vous pouvez mesurer, c’est la vitesse de chargement et de réponse de l’application déployée elle-même, depuis des emplacements réels dans le monde entier. J’ai testé cela sous quatre angles différents : GTmetrix depuis deux continents, une vérification 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’application testée est le déploiement Next.js couvert dans la section Facilité d’utilisation ci-dessous, en ligne à ivory-llama-856835.hostingersite.com, fonctionnant sur l’offre Cloud Startup (4 cœurs CPU, 4096 MB RAM, 100 GB NVMe storage), avec le CDN activé par défaut.

1. GTmetrix, testé depuis deux continents

J’ai lancé GTmetrix deux fois depuis différentes régions du monde pour voir si le résultat se maintenait de façon cohérente ou s’il ne paraissait bon que depuis un seul point de vue chanceux.

Les deux exécutions ont obtenu un score parfait de 100% à la fois en Performance et en Structure, avec zéro décalage de mise en page et zéro temps de blocage dans les deux localisations, ce qui signifie que rien sur la page n’a concurrencé l’attention du navigateur ni bougé pendant le chargement.

Le détail vraiment intéressant est que Francfort a en fait battu Chicago sur tous les indicateurs de temps, alors que j’avais délibérément choisi un emplacement de serveur aux USA pour cette application. Ce résultat ne prend 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 n’atteint pas nécessairement le serveur d’origine directement.

Il atteint le nœud de bord le plus proche en cache, donc un point de test européen peut finir plus rapide qu’un point américain même lorsque le serveur réel se trouve aux USA. C’est une confirmation réelle et mesurable que le CDN activé par défaut par Hostinger fait bien son travail au lieu de simplement exister comme un argument marketing.

2. Cohérence mondiale (Check-Host)

J’ai lancé une vérification HTTP sur l’URL en ligne depuis chaque point de contrôle offert par Check-Host, 54 emplacements sur six continents. Vue d’ensemble :

Chaque vérification réussie a renvoyé un 200 OK propre, sans erreur, sans échec partiel, sans redirection inattendue.

Les temps de réponse racontaient clairement comment fonctionne la mise en cache du CDN à travers de vraies distances :

Les points de contrôle européens ont systématiquement renvoyé les temps les plus rapides, plusieurs sous les 50 millisecondes, tandis que les points physiquement les plus éloignés de tout nœud de bord, Tokyo, Singapore, Ho Chi Minh City, renvoyaient toujours des réponses 200 valides, simplement plus lentes, dans la plage de 0.3 à 0.8 seconde.

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

Les quatre dépassements de délai, Kazakhstan, Romania, et deux des quatre points de contrôle russes, ne sont pas quelque chose que je lirais comme un problème de l’infrastructure de Hostinger.

D’autres points de contrôle dans les mêmes pays ont réussi (Saint Petersburg est revenu propre à 0.063s tandis que deux points de contrôle de Moscow 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 problème du déploiement lui-même.

3. L’outil de vitesse de Hostinger, desktop et mobile

Hostinger exécute son propre test Page Speed directement dans le tableau de bord de l’application, j’ai donc comparé ses chiffres aux résultats indépendants de GTmetrix plutôt que de me fier à l’un ou à l’autre seul.

Les deux types d’appareils ont obtenu un score parfait de 100, et les chiffres desktop correspondent de près à ce que GTmetrix a mesuré indépendamment, ce qui est le véritable intérêt de lancer les deux. Deux outils différents, deux méthodologies différentes, et ils concordent.

Le mobile était plus lent sur chaque métrique temporelle, comme prévu sur une connexion simulée plus lente et avec un processeur moins puissant, mais toujours assez rapide pour qu’un score de 100 reflète de véritables performances mobiles solides, et non pas simplement une notation indulgente.

Une incohérence dans l’outil lui-même. Même si le score est un 100 net sur les deux appareils, le panneau Diagnostics en dessous signale encore 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 globale, donc considérez-les comme de modestes possibilités d’optimisation réellement présentes plutôt que comme un problème du déploiement.

Par ailleurs, les « helpful links » qu’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 application Node.js sans aucun WordPress dans la pile. C’est un reliquat d’un modèle de diagnostic partagé plutôt qu’un contenu créé pour ce produit.

Verdict global sur les performances

Managed Web App Hosting by Hostinger

Focus on building your app while Hostinger takes care of deployment, infrastructure, security, SSL, backups, and global delivery.

Visitez Hostinger

Facilité d’utilisation

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

Cela couvrait le choix d’une offre, le paiement, la manière de construire, la connexion à GitHub et la surveillance de la fin du build en temps réel. Voici à quoi ce processus ressemblait en pratique.

1. Inscription

J’ai commencé sur la page d’accueil de Web Apps Hosting, qui met en avant un seul appel à l’action : Start deploying.

Cliquer dessus n’ouvre pas un formulaire d’inscription. Cela fait simplement défiler la page jusqu’à la section tarifs, donc la première vraie décision consiste à choisir quelle offre acheter, et non à remplir des informations de compte.

Deux offres étaient présentées côte à côte :

J’ai choisi Cloud Startup pour bénéficier du double de quota d’applications et de marge CPU par rapport au niveau d’entrée. Une petite incohérence à signaler ici : la page tarifaire l’appelle « Cloud Startup », mais une fois dans le panier, la même offre est intitulée « Startup plan ». Ce n’est pas un problème fonctionnel, juste un décalage de nom entre deux écrans du même parcours de paiement.

Le panier lui-même était propre. Il indiquait la durée de 48 mois, les économies, un domaine gratuit pendant un an et des boîtes mail gratuites, puis proposait une seule option supplémentaire, Hostinger Reach email marketing, dans son propre encadré mis en évidence plutôt que pré-sélectionné.

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

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

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

Ce que j’en ai pensé : Le paiement est court et l’option supplémentaire est facile à refuser sans devoir chercher un lien caché pour passer. Le décalage de nom entre la page tarifaire et le panier est un petit détail, mais c’est le genre de chose qui pousse un acheteur débutant à s’arrêter et à vérifier s’il a bien sélectionné la bonne offre.

2. Tableau de bord

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

La première page sur laquelle vous arrivez est Home, et elle est construite autour d’une barre de saisie 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 faisant défiler, vous trouverez :

• Des tuiles de promotion des fonctionnalités pour AI Builder, l’outil de boutique en ligne, promettant un e-mail professionnel gratuit, des agents IA, une application d’automatisation, et un domaine gratuit
• Une liste de tâches poussant vers des tâches de configuration, terminer la configuration de Reach, réclamer votre e-mail gratuit, réclamer votre domaine gratuit
• Your business, une liste en cours d’exécution de chaque site, application et instance VPS liée à votre compte, chacune avec son propre bouton Manage site
• VPS, un tableau séparé plus bas listant toutes les instances VPS par adresse IP, statut et date d’expiration

Un panneau Agent se trouve aussi en permanence dans le coin supérieur droit de chaque page hPanel, pas seulement sur Home. C’est le même assistant Kodee utilisé pour le support, mais présenté ici comme un outil d’action général avec des invites prêtes à 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 application existe déjà, tout ce qui se trouve dans Your business renvoie directement vers elle. Mais ce n’est pas là que l’on va pour créer une nouvelle Web App ou atteindre le bouton Setup. Pour cela, il faut emprunter un autre chemin dans la barre latérale :

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

Ce clic vous mène à un écran complètement différent de Home, organisé autour de vos plans d’hébergement réels plutôt que d’une barre de saisie.

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

La carte Business contenait également déjà une application en ligne issue de tests précédents, orange-walrus-700988.hostingersite.com, avec ses propres boutons Tools et Dashboard.

C’est une information utile en soi. Une fois qu’une Web App existe, sa carte se développe avec une ligne comme celle-ci affichant directement le site en ligne, ce qui est exactement à quoi ressemblera votre carte Cloud Startup une fois la configuration terminée.

Comme 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 sur l’écran Home sur lequel vous arrivez par défaut.

Ce que j’en ai pensé : hPanel est clair une fois que vous avez 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 saisie et des raccourcis, pas un chemin pour créer une application ; il faut savoir cliquer sur Websites, puis sur Web Apps, avant même que Setup apparaisse. Cela fait quelques clics de plus pour un produit vendu comme « live in a minute ». Une fois sur place, toutefois, les cartes des offres sont propres et honnêtes sur leur statut, et une offre avec une application déjà active l’affiche directement sur la carte.

3. Déploiement de l’application

Cliquer sur Setup sur la carte de l’offre a ouvert un court parcours d’intégration : 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.

Cela a mené à How do you want to build your website?, réparti entre deux options destinées aux débutants en haut, Hostinger AI Builder et WordPress + AI, et deux options sous un titre séparé « for advanced users » en bas : Node.js web app et PHP/HTML website. Sélectionner Node.js web app est ce qui vous amène réellement au produit Web Apps Hosting lui-même.

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

C’est une branche parmi d’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 sur Next.

À partir de là :

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

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

J’ai malgré tout choisi United States, Massachusetts, et c’est exactement la leçon que l’écran de localisation enseigne sur chaque produit Hostinger : choisissez en fonction de l’endroit où se trouvent vos visiteurs réels, pas du chiffre le plus bas de la liste.

L’audience visée par mon application de test est basée aux USA, donc un serveur aux USA leur servira en réalité plus vite qu’un serveur en France, quel que soit le chiffre affiché depuis ma propre position. Le nombre à l’écran vous indique à quelle vitesse le serveur répond au test de Hostinger, pas à quelle vitesse il répondra aux personnes qui utiliseront réellement votre site.

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

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

• L’installation sur all repositories que vous possédez, y compris les futurs, avec accès en lecture seule aux dépôts publics
• L’installation sur only select repositories que vous choisissez individuellement et listant exactement les autorisations accordées : accès en lecture aux actions, aux métadonnées et aux hooks du dépôt, et accès en lecture et écriture à l’administration, au code et aux 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éfilante 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é plus tôt, hostadvice-webapps-test, et j’ai cliqué sur Deploy à côté.

À partir du clic sur ce bouton, il a fallu près de 30 secondes sans aucun indicateur de progression à l’écran avant que la page suivante ne se charge, suffisamment pour vous faire penser que le clic n’avait peut-être pas été pris en compte.

La page qui finit par s’ouvrir s’intitule Review build settings, et elle vous indique exactement où votre application vivra avant que vous ne validiez quoi que ce soit : « Deploys to ivory-llama-856835.hostingersite.com. » En dessous, sans toucher à un seul champ, elle avait déjà détecté automatiquement :

Chacune de ces cinq lignes possède 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 atteindrait bien l’application en fonctionnement plus tard, puis j’ai cliqué sur Finish dans cette boîte de dialogue, puis sur le bouton principal Deploy en bas de la page.

Surveillance 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%, en route vers 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 terminé, vous arrivez sur un écran Deployment completed! avec un aperçu miniature en direct de votre application réellement en fonctionnement affiché directement dans la carte, à côté d’un résumé montrant le nom du dépôt et l’URL en ligne attribuée.

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

Ce que j’en ai pensé : La détection automatique est la véritable force ici. Framework, branche et version de Node étaient tous corrects sans un seul champ manuel, et le journal de build en direct rend l’attente transparente plutôt qu’opaque. Le seul point faible est cette pause de 30 secondes avant même d’atteindre l’écran des paramètres, assez longue pour faire croire qu’un blocage s’est produit avant que le processus ne démarre visiblement.

4. Vérification du déploiement en ligne

Avant d’explorer les outils de gestion, je voulais confirmer que l’application avait réellement été déployée et fonctionnait, et qu’elle ne se contentait pas d’être marquée « Completed » à l’écran.

Depuis la page Deployment completed, j’ai cliqué directement sur l’URL en ligne, ivory-llama-856835.hostingersite.com, plutôt que de faire confiance uniquement à l’aperçu miniature du tableau de bord.

La page en ligne s’est chargée et a affiché exactement ce que l’application était codée pour montrer :

• Server build time, un horodatage en direct confirmant que la page venait d’être reconstruite, et non servie depuis un vieux cache
• Environment variable check, affichant la variable personnalisée que j’avais définie pendant l’écran de déploiement, correctement confirmée sur le site en ligne réel, et pas seulement dans l’aperçu du tableau de bord

J’ai ensuite cliqué sur le bouton Ping the API route de l’application, qui appelle un point de terminaison backend en direct plutôt que de simplement afficher 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 davantage qu’il n’y paraît. Une page qui se charge correctement ne prouve que les fichiers statiques ont été transférés.

Un appel API fonctionnel prouve que le véritable serveur Node.js tourne en arrière-plan et répond aux vraies requêtes, la partie du « Node.js web app » qu’il est facile d’imiter avec un fichier statique et difficile d’imiter avec un horodatage serveur en direct généré exactement au moment où vous cliquez sur un bouton.

Ce que j’en ai pensé : C’est le contrôle que je vous recommanderais de faire avant de faire confiance à un déploiement sur cette plateforme, ou sur une plateforme similaire. Un statut vert « Completed » et une miniature d’aperçu vous disent que le build s’est terminé. Cliquer jusqu’à l’URL en ligne 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 falsifié par une page statique mise en cache, vous dit que le serveur est réellement vivant et fait ce que vous avez construit.

5. Gestion de l’application web

Une fois l’application en ligne confirmée comme fonctionnelle, je suis retourné dans hPanel et j’ai exploré le tableau de bord de gestion de l’application de bout en bout, la véritable couche de gestion du serveur de ce produit, distincte de l’écran général Home de hPanel évoqué plus haut.

Vue d’ensemble du tableau de bord. Dès votre arrivée ici, quatre badges d’état indiquent l’état général en un coup d’œil :

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

Un test automatique Page Speed avait déjà été exécuté sur le site en ligne lui-même et avait renvoyé un score Desktop de 99/100 sans que je le lance 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 journaux d’exécution et le cache.

Déploiements, variables d’environnement et journaux. Trois pages distinctes couvrent ces éléments :

• Deployments a conservé un historique complet du push, de l’auteur, de la branche, du hash du commit et du statut d’achèvement, un vrai historique plutôt qu’une simple dernière entrée
• Environment variables a correctement listé la variable que j’avais définie pendant le déploiement, confirmant qu’elle a bien été stockée et appliquée, et pas seulement affichée une fois durant la configuration puis oubliée
• Runtime logs a diffusé en direct la sortie serveur au fur et à mesure, les lignes de démarrage de Next.js, les horodatages de disponibilité et un compteur d’incidents et d’erreurs, qui sont restés à zéro et zéro tout le temps où je les ai observés

Sécurité. Le Malware Scanner a renvoyé un résultat propre, « Your website is safe », avec une réserve clairement indiquée plutôt que cachée dans les petites lignes : il vérifie uniquement les fichiers du site, pas le contenu de la base de données, et une option payante de nettoyage est disponible si vous voulez une analyse plus approfondie incluant la base de données. L’analyse des Vulnerabilities est également revenue propre.

Bases de données. C’est ici que le marketing du produit crée un vrai décalage que vous devriez comprendre avant d’acheter. L’offre annonce une base MySQL managée 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 signifie que vous nommez et créez vous-même la base de données avant que votre application ne puisse en utiliser une. Je l’ai confirmé directement avec Kodee, ce qui est détaillé dans la section Support ci-dessous, et la réponse était claire : managé signifie qu’Hostinger fait fonctionner l’infrastructure de la base de données en arrière-plan, pas qu’une base de données est créée pour vous dès que votre application est mise en ligne.

Accès avancé. L’accès SSH existe dans Advanced, avec IP, port et nom d’utilisateur, mais il est Inactive par défaut et doit être activé manuellement pour que vous puissiez l’utiliser. File Manager offre le choix entre parcourir uniquement les fichiers de cette application ou tous les fichiers de l’offre d’hébergement.

Ce que j’en ai pensé : Le tableau de bord au quotidien est complet et bien organisé. La sécurité et l’historique des déploiements, en particulier, sont faciles à trouver et réellement informatifs, et le journal d’exécution sans erreur accompagné d’une analyse antivirus propre m’a donné une vraie confiance dans le fait que l’application était saine, pas seulement en ligne.

Le seul endroit où l’interface survend les choses est la section base de données, où « managed MySQL » donne sur la page d’offre l’impression de quelque chose de prêt dès que votre application est en ligne, alors qu’en pratique cela signifie un formulaire de création manuel, simple à utiliser, mais une étape que vous devez effectuer vous-même.

Verdict global sur la facilité d’utilisation

Build, Deploy, and Scale with Hostinger

Host modern web apps with GitHub integration, managed MySQL, global CDN, unlimited bandwidth, and built-in security tools.

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 qu’il soit nécessaire de demander à quelqu’un. Kodee apparaît à deux endroits qu’il vaut la peine de distinguer : en tant que Ask AI sur le site marketing public, et en tant que panneau Agent disponible depuis n’importe quelle page dans hPanel, y compris directement sur le tableau de bord de la Web App elle-même.

1. Support IA (Kodee)

J’ai posé deux questions construites autour de vraies lacunes que j’avais relevées pendant les tests, et non de recherches génériques auxquelles Kodee pourrait répondre en copiant la documentation.

Question 1 testait le comportement en cas d’échec de déploiement et le moment de configuration des variables d’environnement, deux préoccupations réelles de production pour quiconque déploie sur cette plateforme :

Si le build de mon application échoue en cours de déploiement GitHub, l’application revient-elle automatiquement à la dernière version réussie, ou est-elle hors ligne 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 échoué ne remplace pas une application déjà en cours d’exécution ; si un déploiement précédent a réussi, l’application continue de servir cette dernière version fonctionnelle. S’il s’agit du premier déploiement et qu’il n’y a rien sur quoi revenir, l’application reste hors ligne jusqu’à ce que le build soit corrigé et redéployé, une réponse claire et honnête plutôt qu’un vague message rassurant.

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 application déjà en ligne, il a détaillé les trois étapes exactes : ouvrir Settings et Redeploy, ajouter ou modifier les variables dans Environment variables, enregistrer puis redéployer.

Question 2 insistait sur les deux écarts que j’avais trouvés moi-même dans le tableau de bord, la formulation « managed MySQL » face au formulaire de création manuelle, et le SSH indiqué comme inactif par défaut :

Cette offre annonce une base MySQL managée, mais le tableau de bord affiche un formulaire manuel « Create a New MySQL Database » plutôt qu’une base de données provisionnée automatiquement. Une base est-elle créée pour chaque Web App par défaut, ou seulement si j’en crée une moi-même ? De plus, l’accès SSH est indiqué comme disponible mais apparaît Inactive par défaut. Si je ne l’active jamais, cela change-t-il quelque chose à la manière dont mon application fonctionne réellement, ou SSH est-il 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, sans l’adoucir. Une base de données n’est pas créée automatiquement pour chaque Web App ; « managed » signifie qu’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 reviennent à l’utilisateur, via le même écran Create a New MySQL Database que j’avais déjà vu, puis en ajoutant soi-même ses informations de connexion dans les variables d’environnement de l’application.

Pour SSH, il a confirmé que le laisser inactif ne change rien au fonctionnement de l’application, au déploiement ou à la connexion à une base de données. Il est présenté uniquement comme un outil optionnel pour les commandes CLI, les migrations ou le débogage direct des fichiers, et non comme quelque chose dont la plateforme dépend en arrière-plan.

Ce que j’en ai pensé : Les deux réponses correspondaient à ce que j’avais déjà vérifié à la main dans le tableau de bord plutôt que de le contredire ou de l’adoucir, ce qui est le signe d’un outil de support qui vérifie réellement l’état du produit plutôt que de réciter un script. Aucune des deux questions n’aurait pu être résolue en copiant depuis une FAQ générique, et Kodee a traité les deux avec des réponses précises, structurées et en deux parties en une minute environ chacune.

2. Base de connaissances

La base de connaissances de Hostinger s’ouvre sur une grille de catégories, 20 catégories au total, chacune affichant un nombre d’articles. Parmi les plus importantes : AI Builder compte 330 articles, VPS en compte 276, Email en compte 127 et Website en compte 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 une vraie découverte pour quiconque s’attend à un point d’ancrage unique, comme en ont VPS ou Email.

Une recherche sur « Web Apps » a renvoyé 71 résultats sur 8 pages. Les meilleurs résultats mélangeaient des contenus directement pertinents et d’autres seulement vaguement 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, adjacent mais relevant d’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 produit différent
• Plusieurs articles de paiement du Website Builder (PayPal, WeChat Pay, BLIK), sans rapport au-delà du fait qu’ils partagent quelque part dans le texte les mots « web » et « app »

J’ai ouvert l’un des meilleurs résultats, How to deploy apps built with Codex on Hostinger, pour en vérifier la profondeur. Il s’est avéré être un guide complet et bien structuré, avec les frameworks pris en charge listés au début, des captures pas à pas pour les chemins d’import GitHub et de téléversement ZIP, une section sur la configuration des paramètres de build avec des commandes d’exemple, une description de la structure des fichiers après déploiement, un guide d’assistant pour la connexion à la base de données, une section sur la surveillance des vulnérabilités et un bloc FAQ de conclusion.

Même s’il est présenté autour de Codex en particulier, la plateforme sous-jacente est la même que celle du produit Node.js Web App général, donc la majeure partie s’applique directement.

Ce que j’en ai pensé : Le nombre d’articles affiché dans la recherche semble fort sur le papier, 71 résultats pour un seul terme, mais une part significative de ce volume est du bruit provenant de produits non pertinents partageant des formulations similaires. L’article que j’ai ouvert en entier était de bonne qualité une fois dedans, avec des étapes claires, de vraies captures d’écran et une vraie FAQ, mais il a fallu passer au crible des résultats qui n’avaient rien à voir avec ce que j’essayais réellement de déployer.

Verdict global sur le support client

Simple Hosting for Modern Web Apps

Deploy React, Next.js, Vue, Node.js, and other modern applications without managing servers or complex infrastructure.

Visitez Hostinger

Recommandons-nous Hostinger Web Apps Hosting ?

Oui. Le processus de déploiement est le meilleur aspect de ce produit : auto-détection correcte de ma stack, de ma branche et de la version de Node, un vrai journal de build en continu au lieu d’un spinner, et une application en ligne qui a réussi tous les tests de performance que je lui ai fait subir, scores GTmetrix parfaits depuis deux continents différents, vérification globale propre sur 54 points, et scores 100/100 identiques dans les outils de Hostinger sur desktop et mobile. Kodee a renforcé cela avec des réponses exactes et spécifiques à de vraies questions techniques plutôt qu’avec des réponses génériques de script.

Les imperfections sont mineures mais bonnes à connaître avant l’achat. « Managed MySQL » donne l’impression sur la page de l’offre de quelque chose de prêt dès que votre application est en ligne, alors qu’en pratique cela signifie une création manuelle. Le tableau de bord ne donne pas non plus à Web Apps Hosting de point d’entrée dédié depuis l’écran Home principal ; il faut savoir passer par Websites d’abord.

Pour un développeur qui veut un déploiement rapide et agnostique au framework sur une infrastructure qui affiche de si bons benchmarks, 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 paiement, prévoyez quelques minutes supplémentaires pour configurer la base de données vous-même.

Hostinger

5.0

2,471 user reviews

1,37 € /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