Hostinger a bâti l’hébergement d’applications Web autour d’un argument simple : poussez votre code depuis GitHub, un fichier ZIP ou votre agent de codage IA, et obtenez une application en direct, prête pour la production, en environ une minute, sans serveur à gérer de votre côté. Je voulais savoir quelle part de cette promesse tenait vraiment la route une fois que c’était vous qui cliquiez sur déployer, alors voici ce que j’ai constaté.

Déployez des applications Web plus rapidement avec Hostinger

Déployez des applications Web modernes sur Hostinger avec des compilations automatisées, une infrastructure gérée, un CDN mondial, SSL, des outils de sécurité et une garantie de remboursement de 30 jours.

Visitez Hostinger

Avantages et inconvénients

Répartition des notes

Pour évaluer l’hébergement d’applications Web de Hostinger, j’ai appliqué la méthodologie d’évaluation de HostAdvice, la même approche normalisée utilisée pour chaque critique sur le site, afin que les notes restent ancrées dans des tests réels plutôt que dans le langage marketing. Voici comment cela s’est noté selon chaque paramètre.

Hébergez vos applications Web sans le casse-tête DevOps

Déployez des applications Web modernes sur un hébergement entièrement géré avec des déploiements automatisés, SSL géré, CDN mondial et sécurité intégrée.

Visitez Hostinger

Forfaits et tarification

Hostinger vend l’hébergement d’applications Web 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 la création de sites Web traditionnels.

Cloud Startup, le niveau que j’ai testé, double l’allocation d’applications et le nombre de cœurs CPU par rapport à Business, et les deux forfaits incluent un domaine gratuit, un courriel professionnel gratuit et un SSL géré pour la première année directement au moment du paiement.

Quelques points à savoir avant de commander :

• Garantie de remboursement : L’hébergement d’applications Web est couvert par les conditions de remboursement standard de Hostinger, soit une fenêtre simple de 30 jours à partir de la date d’achat. C’est nettement plus simple que pour les forfaits VPS de Hostinger, qui comportent une période de refroidissement supplémentaire de 180 jours entre deux demandes de remboursement. Aucune période 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 plutôt votre période d’évaluation.
• Modes 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 un autre mode de paiement pendant le paiement.
• Ce qui est inclus : Un domaine gratuit pour un an, des boîtes aux lettres gratuites pour un an et un SSL géré sont tous inclus sans frais supplémentaires par rapport au prix du forfait, donc le prix affiché est assez proche du coût réel pour mettre en ligne un déploiement entièrement fonctionnel et sécurisé.
• Le seul ajout en option : Hostinger Reach, un module complémentaire de marketing par courriel, apparaît dans le panier comme un encadré distinct avec son propre prix mensuel. Il est facile de l’ignorer et il n’est pas inclus ni présélectionné par défaut.

Si vous annulez un forfait d’hébergement d’applications Web dans les 30 jours, la politique de remboursement de Hostinger confirme qu’il relève des conditions standard plutôt que de la liste des exclusions, donc une annulation simple dans ce délai devrait être admissible à un remboursement sans les conditions supplémentaires qui s’appliquent aux achats VPS ou de domaine.

Fonctionnalités

• Détection automatique du framework et de la version de Node
• Outils de création de base de données MySQL gérés
• CDN mondial activé par défaut
• WAF et protection contre les attaques DDoS inclus
• Sauvegardes quotidiennes et à la demande
• Scanner de logiciels malveillants et analyse des vulnérabilités
• Intégration GitHub avec déploiement automatique
• Domaine, courriel et SSL gratuits
• Accès SSH pour les utilisateurs avancés

Du code à l’application en direct avec Hostinger

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

Visitez Hostinger

Performance

Comme l’hébergement d’applications Web est entièrement géré, vous n’obtenez jamais d’accès au shell d’un serveur, donc il n’y a ni CPU, ni RAM, ni disque à mesurer directement comme dans une critique de VPS.

Ce qu’on peut mesurer, c’est la rapidité avec laquelle l’application déployée se charge et répond, à partir de vraies localisations partout dans le monde. J’ai testé cela sous quatre angles distincts : GTmetrix depuis deux continents, une vérification de cohérence mondiale de plus de 50 points et l’outil de vitesse intégré de Hostinger pour le bureau 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, exécutée sur le forfait Cloud Startup (4 cœurs CPU, 4096 MB RAM, 100 GB de stockage NVMe), avec le CDN activé par défaut.

1. GTmetrix, testé depuis deux continents

J’ai exécuté GTmetrix deux fois depuis différentes parties du monde pour voir si le résultat restait constant ou s’il n’avait été bon que depuis un seul point d’observation chanceux.

Les deux tests ont obtenu un 100 % parfait à la fois pour Performance et Structure, avec zéro décalage de mise en page et zéro temps de blocage dans les deux emplacements, ce qui signifie que rien sur la page n’entrait en concurrence avec l’attention du navigateur ni ne bougeait pendant le chargement.

Le détail vraiment intéressant, c’est que Frankfurt a en fait battu Chicago sur tous les paramètres de temps, même si j’ai délibérément choisi un emplacement de serveur américain pour cette application. 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 n’atteint pas nécessairement directement le serveur d’origine.

Il atteint plutôt le nœud périphérique mis en cache le plus proche, de sorte qu’un point de test européen peut finir plus rapide qu’un point américain, même si le serveur réel se trouve aux USA. C’est une confirmation concrète et pratique que le CDN activé par défaut par Hostinger fait bel et bien un travail utile au lieu de n’être qu’une case de marketing.

2. Cohérence mondiale (Check-Host)

J’ai lancé une vérification HTTP sur l’URL en direct depuis chaque point de contrôle offert par Check-Host, 54 emplacements répartis sur six continents. Le portrait complet :

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

Les temps de réponse ont raconté une histoire claire sur la façon dont la mise en cache CDN se comporte à des distances réelles :

Les points de contrôle européens ont constamment renvoyé les temps les plus rapides, plusieurs sous les 50 millisecondes, tandis que les points de contrôle physiquement les plus éloignés de tout nœud périphérique, Tokyo, Singapore, Ho Chi Minh City, renvoyaient tout de même 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 un CDN : rapide près des bords, toujours pleinement fonctionnel loin d’eux.

Les quatre expirations, Kazakhstan, Romania et deux des quatre points de contrôle russes, ne sont pas quelque chose que j’interpréterais comme un problème d’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 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 avec l’application déployée.

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

Hostinger exécute son propre test Page Speed directement dans le tableau de bord de l’application, alors j’ai comparé ses chiffres aux résultats indépendants de GTmetrix plutôt que de prendre l’un ou l’autre pour argent comptant.

Les deux types d’appareils ont obtenu un 100 parfait, et les chiffres sur ordinateur concordent étroitement avec ce que GTmetrix a mesuré indépendamment, ce qui est le vrai intérêt de faire les deux tests. Deux outils différents, deux méthodologies différentes, et ils sont d’accord.

Le mobile a été plus lent sur tous les paramètres de temps, comme prévu sur une connexion simulée plus lente et un processeur moins puissant, mais il restait assez rapide pour qu’un score de 100 reflète une réelle performance mobile solide, et non simplement une grille de notation indulgente.

Une incohérence dans l’outil lui-même. Même si la note est un 100 net sur les deux appareils, le panneau Diagnostics en dessous signale encore quelques éléments avec une note littérale 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.

Aucune de ces sous-notes faibles n’a fait baisser la note globale, alors considérez-les comme de petites possibilités d’optimisation réellement présentes plutôt que comme un problème du déploiement.

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

Verdict global sur la performance

Hébergement d’applications Web géré par Hostinger

Concentrez-vous sur la création de votre application pendant que Hostinger s’occupe du déploiement, de l’infrastructure, de la sécurité, du SSL, des sauvegardes et de la livraison mondiale.

Visitez Hostinger

Facilité d’utilisation

J’ai testé l’hébergement d’applications Web de Hostinger depuis la page d’accueil jusqu’au paiement, puis depuis un compte vierge jusqu’à un déploiement Node.js pleinement fonctionnel et en ligne.

J’ai donc couvert le choix d’un forfait, le paiement, la façon de construire, la connexion à GitHub et l’observation de la compilation se terminer en temps réel. Voici à quoi ce processus ressemblait réellement.

1. Inscription

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

Cliquer dessus n’ouvre pas un formulaire d’inscription. La page défile directement jusqu’à la section des prix, donc la première vraie décision consiste à choisir quel forfait acheter, pas quels renseignements de compte remplir.

Deux forfaits étaient côte à côte :

J’ai choisi Cloud Startup pour avoir le double de la limite d’applications et plus de marge CPU que le niveau d’entrée. Un petit écart à signaler ici : la page de tarification l’appelle « Cloud Startup », mais une fois dans le panier, le même forfait est étiqueté « Startup plan ». Rien de fonctionnel, juste une incohérence de nom entre deux écrans du même parcours d’achat.

Le panier était propre. Il affichait la durée de 48 mois, les économies, un domaine gratuit pendant un an et des boîtes aux lettres gratuites, puis proposait un seul ajout en option, Hostinger Reach marketing par courriel, dans son propre encadré en surbrillance 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 paiement insère 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 un mode de paiement, carte, PayPal ou l’une des autres options, puis soumettez. J’ai reçu un courriel de confirmation d’achat presque immédiatement après avoir cliqué sur Soumettre le paiement, puis je suis arrivé directement dans hPanel avec le forfait déjà provisionné.

Ce que j’ai pensé : Le paiement est court et l’ajout en option est facile à refuser sans devoir chercher un lien de refus caché. Le décalage de nom entre la page de tarification et le panier est un petit détail, mais c’est le genre de chose qui fait hésiter un premier acheteur et le pousse à revérifier qu’il a choisi le bon niveau.

2. Tableau de bord

Une fois votre paiement passé, vous arrivez dans hPanel, le panneau de contrôle interne de Hostinger qu’il a conçu pour gérer tous ses produits, pas une page bâtie spécifiquement autour de votre nouvelle application Web.

La page sur laquelle vous arrivez d’abord est Home, et elle est centrée sur 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 défilant plus bas, vous trouverez :

• Des tuiles promotionnelles de fonctionnalités pour AI Builder, l’outil de boutique en ligne, affirmant un courriel professionnel gratuit, des agents IA, une application d’automatisation et la possibilité de réclamer un domaine gratuit
• Une liste de tâches vous poussant vers des étapes de configuration, terminer la configuration de Reach, réclamer votre courriel gratuit, réclamer votre domaine gratuit
• Your business, une liste en cours de tous les sites, applications et instances VPS liés à votre compte, chacun avec son propre bouton Manage site
• VPS, un tableau distinct plus bas listant toute instance VPS par adresse IP, état et date d’expiration

Un panneau Agent se trouve aussi en permanence dans le coin supérieur droit de chaque page de hPanel, pas seulement sur Home. C’est le même assistant Kodee utilisé pour le soutien, mais placé ici comme 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 mène 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 cela, il faut passer par 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 amène à un écran complètement différent de Home, organisé autour de vos forfaits d’hébergement réels plutôt que d’une barre de saisie.

Ici, chaque forfait que vous possédez reçoit sa propre carte. Sur mon compte, cela signifiait trois cartes empilées verticalement :

La carte Business contenait déjà aussi une application en ligne issue d’un test antérieur, orange-walrus-700988.hostingersite.com, avec ses propres boutons Tools et Dashboard.

C’est un détail utile à remarquer en soi. Une fois qu’une Web App existe, sa carte ajoute une ligne comme celle-ci montrant 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 le forfait que je venais d’acheter et que je n’avais pas encore configuré, sa carte affichait plutôt un seul 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.

Ce que j’ai pensé : hPanel est clair une fois qu’on a trouvé le bon écran, mais l’hébergement d’applications Web 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 que Setup n’apparaisse. C’est quelques clics de plus pour un produit vendu comme « en ligne en une minute ». Une fois là, cependant, les cartes de forfait sont nettes et honnêtes quant à l’état, et un forfait avec une application déjà en cours d’exécution l’affiche directement sur la carte.

3. Déploiement de l’application

Cliquer sur Setup sur la carte du forfait a ouvert un court parcours de démarrage : 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?, divisé en deux options pour débutants en haut, Hostinger AI Builder et WordPress + AI, puis deux options sous un 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 place réellement sur le produit Web Apps Hosting lui-même.

C’est une note structurelle importante pour toute personne qui compare les produits : l’hébergement d’applications Web n’a pas son propre parcours d’inscription dédié.

C’est une branche à l’intérieur du 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 l’emplacement du serveur : Hostinger a présélectionné France, la région la plus proche de mon pays de facturation, et l’a affichée avec une latence de 167ms. En faisant défiler jusqu’à l’option United States, j’ai vu 364ms, soit plus du double.

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

L’audience visée par mon application de test est basée aux USA, donc un serveur aux USA la servira réellement plus vite qu’un serveur en France, peu importe ce que le sélecteur m’a montré depuis ma propre position. Le chiffre à l’écran vous dit à 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 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 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 :

• Installer sur all repositories que vous possédez, y compris les futurs, avec un accès en lecture seule aux dépôts publics
• Installer uniquement sur les only select repositories que vous choisissez individuellement et listant les permissions exactes accordées : accès en lecture aux actions, aux métadonnées et aux hooks du dépôt, et accès en lecture-écriture à l’administration, au code et aux demandes de tirage. 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 envoyé auparavant, 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 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 finit par s’ouvrir s’intitule Review build settings, et elle vous indique exactement où votre application vivra avant que vous ne vous engagiez : « Deploys to ivory-llama-856835.hostingersite.com. » En dessous, sans que vous touchiez à un seul champ, elle 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 figé 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 confirmer qu’elle atteindrait bien l’application en cours d’exécution plus tard, puis j’ai cliqué sur Finish dans cette boîte de dialogue, puis sur le bouton principal Deploy au bas de la page.

Observation de la compilation

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 l’achèvement. Sous la barre de progression se trouve un panneau repliable Build logs, et l’ouvrir affiche une vraie sortie terminal en direct au fur et à mesure, pas un simple indicateur animé :

> 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 la compilation terminée, vous arrivez sur un écran Deployment completed! avec un aperçu miniature en direct de votre application réelle rendu 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’ai pensé : La détection automatique est ici l’élément phare. Framework, branche et version de Node étaient tous corrects sans qu’un seul champ manuel ne soit rempli, et le journal de compilation en direct rend l’attente transparente plutôt qu’opaque. Le seul point faible est ce délai de 30 secondes avant même d’atteindre l’écran des paramètres, assez long pour faire croire que quelque chose s’est bloqué avant que le processus ne démarre visiblement.

4. Confirmation du déploiement en direct

Avant d’explorer les outils de gestion, je voulais confirmer que l’application avait vraiment été déployée et fonctionnait, et pas seulement 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 me fier uniquement à la miniature d’aperçu du tableau de bord.

La page en direct s’est chargée et a montré exactement ce que l’application était programmée pour afficher :

• Server build time, un horodatage en direct confirmant que la page venait d’être compilée, et non servie depuis un ancien cache
• Environment variable check, montrant la variable personnalisée que j’avais définie pendant l’écran de déploiement, correctement confirmée sur le site en direct lui-même, 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 rendre 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’il n’y paraît. Une page qui se charge correctement prouve seulement que les fichiers statiques ont été téléversés.

Un appel API fonctionnel prouve que le vrai serveur Node.js tourne sous le capot 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 de serveur en direct généré au moment précis où vous cliquez sur un bouton.

Ce que j’ai pensé : C’est la vérification que je vous recommanderais avant de faire confiance à un déploiement sur cette plateforme, ou sur toute plateforme similaire. Un statut « Completed » en vert et une miniature d’aperçu vous disent que la compilation est terminée. Cliquer sur l’URL en direct 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 réellement vivant et fait ce que vous lui avez demandé de faire.

5. Gestion de la Web App

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

Vue d’ensemble du tableau de bord. Dès l’instant où vous arrivez ici, quatre badges d’état indiquent la situation d’un coup d’œil :

Les quatre étaient verts par défaut, sans rien à activer manuellement. En dessous se trouve une carte Last deployment confirmant l’état, le dépôt, l’auteur, le commit, l’heure de déploiement, la pile 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 s’était déjà exécuté sur le site en direct par lui-même et avait renvoyé une note Desktop de 99/100 sans que je le déclenche 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 cela :

• Deployments conservait un historique complet de l’envoi, de l’auteur, de la branche, du hachage du commit et de l’état d’achèvement, un véritable historique plutôt qu’une seule version récente
• Environment variables listait correctement celle que j’avais définie pendant le déploiement, confirmant qu’elle était stockée et appliquée, et non seulement affichée une fois pendant la configuration puis oubliée
• Runtime logs diffusaient en direct la sortie du serveur au fur et à mesure, les lignes de démarrage de Next.js, les horodatages de disponibilité et un compteur d’issues et d’erreurs, qui est resté à zéro et zéro tout le temps où j’ai regardé

Sécurité. Le Malware Scanner a renvoyé un résultat propre, « Your website is safe », avec une mise en garde formulée clairement plutôt que cachée dans les petits caractères : il vérifie uniquement les fichiers du site, pas le contenu de la base de données, et une option payante de nettoyage existe si vous voulez une vérification plus approfondie incluant la base de données. L’analyse des Vulnerabilities est revenue propre elle aussi.

Bases de données. C’est ici que le marketing du produit crée un vrai fossé que vous devriez comprendre avant d’acheter. Le forfait annonce MySQL géré 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 puisse en utiliser une. Je l’ai confirmé directement avec Kodee, comme je le couvre dans la section Soutien ci-dessous, et la réponse était directe : géré signifie que Hostinger exécute l’infrastructure de base de données en coulisses, pas qu’une base de données soit créée pour vous dès que votre application est mise en ligne.

Accès avancé. L’accès SSH existe sous Advanced, avec IP, port et nom d’utilisateur, mais il est Inactive par défaut et nécessite un clic manuel sur Enable avant que vous puissiez l’utiliser. File Manager offre le choix entre parcourir uniquement les fichiers de cette application ou tous les fichiers de l’ensemble du forfait d’hébergement.

Ce que j’ai pensé : Le tableau de bord 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 avec une analyse de logiciels malveillants propre m’a donné une vraie confiance que l’application était saine, pas seulement en ligne.

Là où l’interface en fait un peu trop est la section base de données, où « MySQL géré » donne, sur la page du forfait, l’impression de quelque chose qui vous attend dès que votre application est mise en ligne, alors qu’en pratique il s’agit d’un formulaire de création que vous devez remplir vous-même.

Verdict global sur la facilité d’utilisation

Construisez, déployez et mettez à l’échelle avec Hostinger

Hébergez des applications Web modernes avec intégration GitHub, MySQL géré, CDN mondial, bande passante illimitée et outils de sécurité intégrés.

Visitez Hostinger

Niveau de soutien

J’ai testé le soutien de Hostinger pour l’hébergement d’applications Web au moyen de 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 poser la question à quelqu’un. Kodee apparaît à deux endroits qu’il vaut la peine de distinguer : comme Ask AI sur le site marketing public, et comme panneau Agent disponible depuis n’importe quelle page à l’intérieur de hPanel, y compris directement sur le tableau de bord propre à la Web App.

1. Soutien IA (Kodee)

J’ai posé deux questions construites autour de vraies lacunes que j’avais relevées pendant les tests, pas des 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 où les variables d’environnement s’appliquent, deux préoccupations de production bien réelles pour quiconque livre sur cette plateforme :

Si la compilation de mon application échoue à mi-chemin d’un déploiement GitHub, l’application revient-elle automatiquement à la dernière version réussie, ou tombe-t-elle en panne 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. Une compilation échouée 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 tout premier déploiement et qu’il n’y a rien sur quoi revenir, l’application reste hors ligne jusqu’à ce que la compilation soit corrigée et redéployée, une réponse claire et honnête plutôt qu’une vague rassurance.

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 cours d’exécution, 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 lacunes que j’avais moi-même trouvées en explorant le tableau de bord, la formulation « MySQL géré » face au formulaire de création manuelle, et l’état inactif par défaut de SSH :

Ce forfait annonce un MySQL géré, mais le tableau de bord montre un formulaire manuel « Create a New MySQL Database » plutôt qu’une base de données provisionnée automatiquement. Une base de données est-elle créée pour chaque Web App par défaut, ou seulement si j’en crée une moi-même? Aussi, l’accès SSH est indiqué comme disponible mais apparaît Inactive par défaut. Si je ne l’active jamais, est-ce que cela change quoi que ce soit à la façon dont mon application fonctionne réellement, ou SSH est-il simplement un complément facultatif pour les utilisateurs avancés?

La réponse de Kodee a confirmé exactement ce que j’avais constaté dans l’interface, et non une version adoucie. Une base de données n’est pas créée automatiquement pour chaque Web App ; « géré » signifie que Hostinger gère le service et l’infrastructure de base de données, tandis que la création et la configuration d’une vraie base de données vous reviennent, à travers le même écran Create a New MySQL Database que j’avais déjà vu, puis en ajoutant vous-même ses informations de connexion dans les variables d’environnement de votre application.

Pour SSH, il a confirmé que le laisser inactif ne change rien au fonctionnement de l’application, aux déploiements ni à la connexion à une base de données. Il est présenté uniquement comme un outil facultatif pour des commandes CLI, des migrations ou le débogage direct de fichiers, pas comme quelque chose dont la plateforme dépend en coulisses.

Ce que j’ai pensé : Les deux réponses correspondaient à ce que j’avais déjà vérifié moi-même dans le tableau de bord plutôt que de le contredire ou de l’adoucir, ce qui est la marque d’un outil de soutien qui vérifie réellement l’état du produit plutôt que de réciter un script. Aucune des deux questions ne pouvait être répondue par un simple copier-coller d’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 grandes : AI Builder en compte 330, VPS en compte 276, Email en compte 127, et Website en compte 103.

L’hébergement d’applications Web n’a pas sa propre catégorie dédiée. Son contenu est disséminé entre Getting Started, hPanel et Website, ce qui est un vrai constat pour quiconque s’attend à un point d’ancrage 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 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 pour un produit différent
• 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 entièrement
• Plusieurs articles Website Builder sur les méthodes de paiement (PayPal, WeChat Pay, BLIK), non pertinents au-delà de la présence des 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 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 d’emblée, des captures d’écran étape par étape pour les chemins d’import GitHub et de téléversement ZIP, une section sur la configuration des paramètres de compilation avec des exemples de commandes, un aperçu de la structure des fichiers après le déploiement, un guide de connexion à la base de données, une section sur la surveillance des vulnérabilités et un bloc FAQ final.

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 plupart s’y applique directement.

Ce que j’ai pensé : Le nombre d’articles affiché dans la recherche est solide sur le papier, 71 résultats pour un terme, mais une part importante de ce volume est du bruit provenant de produits sans lien qui partagent une formulation semblable. L’article que j’ai ouvert en entier a tenu la route en matière de qualité une fois que j’y suis entré, avec des étapes claires, de vraies captures d’écran et une véritable section FAQ, mais le trouver m’a obligé à 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 soutien à la clientèle

Hébergement simple pour applications Web modernes

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

Visitez Hostinger

Recommandons-nous l’hébergement d’applications Web de Hostinger?

Oui. Le processus de déploiement est le point fort de ce produit : détection automatique correcte de ma pile, de ma branche et de ma version de Node, vrai journal de compilation en continu plutôt qu’un simple indicateur, et application en direct qui a passé tous les tests de performance que je lui ai fait subir, scores GTmetrix parfaits depuis deux continents distincts, vérification de cohérence mondiale propre sur 54 points et scores 100/100 concordants dans l’outil de Hostinger, tant sur ordinateur que sur mobile. Kodee a renforcé cela 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 méritent d’être connus avant l’achat. « MySQL géré » laisse entendre, sur la page du forfait, quelque chose de prêt dès que votre application est en ligne, alors qu’en pratique il faut créer la base manuellement. Le tableau de bord ne donne pas non plus à l’hébergement d’applications Web une entrée dédiée depuis l’écran Home principal ; il faut savoir aller dans Websites d’abord.

Pour un développeur qui veut un déploiement rapide et agnostique au framework sur une infrastructure qui affiche de telles performances, 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 de plus pour configurer vous-même la base de données.

Hostinger

5.0

2,473 user reviews

2,27 $ /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