La gestion de l’hébergement interrompt généralement le développement. Vous écrivez du code dans un éditeur, ouvrez un tableau de bord d’hébergement pour créer un site web, basculez vers un terminal pour empaqueter ou déployer le projet, retournez au tableau de bord pour inspecter un déploiement, puis ouvrez d’autres outils lorsque le DNS, les journaux ou les ressources du serveur nécessitent votre attention.
Hostinger Connector réduit ce changement de contexte. Il connecte les services Hostinger aux outils de codage IA via le Model Context Protocol (MCP), ce qui vous permet de demander à un assistant IA d’inspecter ou de gérer les ressources d’hébergement prises en charge sans quitter votre éditeur.
Cela semble pratique. Cela soulève aussi une question plus importante : Pouvez-vous faire confiance à un assistant IA pour effectuer correctement de vraies tâches d’hébergement ?
Pour le savoir, j’ai testé Hostinger Connector avec VS Code et GitHub Copilot sur un véritable compte Hostinger. J’ai utilisé une petite application Express.js appelée PulseWatch et j’ai suivi le flux de travail depuis l’installation jusqu’au déploiement en production. J’ai également testé les redéploiements répétés, les enregistrements de build, les journaux, ainsi que la récupération après avoir délibérément cassé la commande de démarrage de l’application.
Voici comment j’ai noté Hostinger Connector dans les domaines qui comptent le plus pour un développeur qui décide de l’utiliser : le coût, l’étendue des fonctionnalités, la facilité d’utilisation au quotidien, la précision avec laquelle il exécute les tâches réelles, et le support qui l’accompagne en cas de problème. Chaque note reflète ce que j’ai réellement constaté pendant les tests, et non la page marketing.
| Paramètre | Note | Pourquoi cette note |
|---|---|---|
| Prix | 9.7/10 | Connector ne comporte aucun abonnement séparé et est inclus gratuitement dans tous les plans. Le seul coût est la ressource d’hébergement sous-jacente dont vous auriez besoin de toute façon. |
| Fonctionnalités | 9.5/10 | L’éventail des fonctionnalités va au-delà du déploiement pour couvrir les sites web, les domaines, le DNS, les bases de données, les campagnes e-mail, les ressources VPS, les journaux et les diagnostics, ce qui couvre plus de terrain qu’un outil de déploiement classique. |
| Facilité d’utilisation | 9.1/10 | L’installation et l’OAuth ont été rapides et n’ont nécessité aucune configuration manuelle, et les déploiements répétés ont été simples. La configuration initiale d’un site Node.js a nécessité hPanel après l’échec de l’IA à identifier une cible valide, le seul véritable manque dans une mise en place par ailleurs fluide. |
| Précision d’exécution | 8.5/10 | L’analyse du projet, l’édition du code, l’empaquetage, le déploiement et la récupération ont bien fonctionné. L’IA a réutilisé un domaine inventé et a surinterprété une vérification d’accessibilité avant que cette cible n’existe. |
| Support | 9.5/10 | Kodee a donné une réponse précise et spécifique à une vraie question technique du premier coup, et le suivi du spécialiste humain a été encore plus pointu. L’escalade a nécessité deux demandes directes, mais les réponses de l’IA et de l’humain étaient fiables une fois obtenues. |
| Global | 9.3/10 | Un outil de flux de travail précieux pour les utilisateurs Hostinger qui travaillent dans des éditeurs compatibles avec l’IA. Il ne coûte rien de plus, couvre un large éventail de fonctionnalités, et l’installation comme le support ont bien tenu pendant les tests. La précision d’exécution sur de nouvelles cibles de déploiement est le seul point à surveiller. |
Hostinger Connector n’est pas vendu comme un produit autonome. Hostinger indique que Connector est inclus gratuitement avec chaque plan, ce qui signifie qu’il n’y a aucun frais mensuel séparé pour Connector à ajouter à votre facture d’hébergement.
Cependant, « gratuit » demande un peu de contexte. Connector gère les ressources Hostinger ; il ne les remplace pas. Vous avez toujours besoin d’un hébergement, d’un cloud, d’un VPS, d’un domaine, d’un service e-mail ou d’un autre service Hostinger éligible pour les tâches que vous souhaitez lui faire accomplir.
Au moment de cet avis, la page d’accueil de Connector mettait en avant Business Web Hosting et Cloud Startup.
| Plan | Prix promotionnel | Durée initiale affichée | Prix de renouvellement | Applications web | Sites web |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
Les prix étaient affichés hors taxes applicables. Les prix promotionnels et les tarifs de renouvellement peuvent changer, alors vérifiez le total actuel lors du paiement plutôt que de vous fier uniquement au tarif mensuel annoncé.
Insight tarifaire : N’achetez pas un plan supérieur uniquement pour accéder à Connector. Choisissez le plan en fonction du nombre de sites web et d’applications web dont vous avez besoin, des ressources qu’ils exigent et du niveau de support que vous souhaitez. Connector est une couche de gestion incluse, et non le produit principal dont le prix est fixé.
Hostinger annonce une garantie de remboursement de 30 jours pour les achats d’hébergement éligibles. Il n’existe pas de politique de remboursement distincte pour Connector puisque Connector ne comporte pas de frais autonomes.
Les actions exactes disponibles dépendent des services Hostinger présents dans votre compte et des outils exposés au client IA connecté.
Hostinger documente aussi des limites de débit. Selon la FAQ de Connector, l’allocation par défaut est de 60 requêtes par minute et 1,000 requêtes par heure, avec les informations de limitation de débit renvoyées dans les en-têtes de réponse.
Ces limites sont généreuses pour une utilisation interactive, bien que les flux automatisés ou très répétitifs doivent tout de même éviter les appels dupliqués inutiles.
Avant de pouvoir juger si Hostinger Connector déploie et gère bien l’hébergement, j’avais besoin de savoir ce qu’il faut pour le faire fonctionner au départ.
Un outil conçu pour rester dans l’éditeur perd rapidement de son intérêt si la configuration implique de modifier des fichiers de configuration, de générer des jetons API ou de se réauthentifier à répétition. Cette section traite uniquement de l’installation. Les tests pratiques des tâches viennent juste après.
J’ai installé Hostinger Connector depuis le VS Code Marketplace. Il est apparu comme le premier résultat lorsque j’ai cherché « Hostinger », l’éditeur indiqué était Hostinger Official, et l’installation a réussi du premier coup en moins de deux minutes.
| Détail | Résultat |
|---|---|
| Recherche dans le Marketplace | Réussi, apparu immédiatement |
| Vérification de l’éditeur | Hostinger Official |
| Installation | Terminée en moins de deux minutes |
| Version de l’extension au moment du test | 1.3.1 |
| Installations sur le Marketplace | 8,140 |
| Note des utilisateurs | 5 étoiles, sur la base de deux notes |
Cette dernière ligne mérite une mise en garde. Cinq étoiles, cela semble solide, mais un échantillon de deux avis ne me dit presque rien sur l’expérience utilisateur typique. Je ne m’appuierais pas sur ce chiffre dans le texte de l’avis.
Une condition préalable m’a surpris : Hostinger Connector fournit les outils Hostinger, mais il a besoin d’un agent IA déjà actif dans l’éditeur pour pouvoir réellement les appeler.
L’extension seule n’a rien à quoi se connecter. Dans VS Code, cet agent est GitHub Copilot Chat, puisqu’il s’agit actuellement de l’interface IA exposée par VS Code pour les appels d’outils MCP. J’avais déjà Copilot actif, donc cela ne m’a pas ralenti, mais les lecteurs doivent savoir que Connector n’est utile que si un agent IA fonctionne derrière lui.
Sans un agent installé et connecté, il n’y a rien pour le brancher.
Ce que l’installation n’a pas exigé :
L’installation de l’extension elle-même a été l’une des parties les plus fluides de tout le test. Le seul véritable point à retenir est une dépendance qu’Hostinger ne met pas au premier plan : l’extension a besoin d’un agent IA actif dans votre éditeur pour faire quoi que ce soit.
Une fois l’extension en place, la prochaine question était de savoir si la connexion à un vrai compte serait tout aussi simple.
La connexion du compte utilisait OAuth via un bouton « 1-Click Connect ». VS Code a ouvert une page d’autorisation Hostinger dans mon navigateur, a détecté ma session Hostinger existante et m’a demandé d’approuver l’accès pour quelque chose nommé hostinger-mcp.
Après avoir cliqué sur Allow, j’ai été renvoyé vers VS Code affichant « Connected via OAuth ».
| Vérification | Résultat |
|---|---|
| Connexion en un clic | Réussi |
| Le navigateur s’est ouvert automatiquement | Réussi |
| Session Hostinger existante détectée | Réussi |
| Jeton API manuel requis | Non |
| Écran d’autorisation affiché | Oui |
| Autorisations expliquées | Oui, mais de manière générale |
| Retour réussi à VS Code | Réussi |
L’écran d’autorisation m’a indiqué que Connector pouvait gérer des sites web, l’hébergement, les domaines, les abonnements et d’autres services Hostinger.
C’est une liste de catégories, pas une répartition autorisation par autorisation. J’aurais aimé plus de granularité ici, car « gérer les abonnements » et « gérer les sites web » couvrent des niveaux de risque très différents.
Ce qui m’a donné un certain contrôle, en revanche, c’est un panneau distinct dans l’extension répertoriant chaque catégorie d’outils et me permettant d’activer ou de désactiver chacune d’elles individuellement :
| Catégorie d’outil | Outils disponibles | État par défaut |
|---|---|---|
| Sites web | 80 | Activé |
| Domaines | 26 | Activé |
| Abonnements et paiements | 7 | Activé |
| Marketing par e-mail | 12 | Activé |
| Ecommerce | 12 | Désactivé |
| VPS | 62 | Désactivé |
Cela représente 199 outils au total, dont 125 activés par défaut. J’ai laissé Ecommerce et VPS désactivés jusqu’à ce que je sois prêt à les tester directement, et l’extension a respecté cette limite tout au long des tests.
C’est le genre de détail de sécurité qui n’apparaît pas sur la page marketing de Hostinger mais qui compte pour toute personne décidant du niveau d’accès à accorder à un assistant IA. Je dirais que c’est un vrai point fort.
La déconnexion du compte est disponible depuis le même panneau, sans avoir besoin de modifier votre mot de passe Hostinger ni de rechercher un jeton stocké.
L’autorisation a été rapide et n’a pas nécessité que je gère moi-même un jeton, mais l’écran d’autorisations est large plutôt que granulaire. Les contrôles de catégorie d’outils dans l’extension font bien plus pour limiter le risque réel que l’écran OAuth.
Hostinger indique la prise en charge des clients suivants, relevés depuis l’écran d’accueil de l’extension :
| Éditeur ou client | Indiqué par Hostinger |
|---|---|
| VS Code | Oui |
| Cursor | Oui |
| Windsurf | Oui |
| Devin Desktop | Oui |
| Antigravity | Oui |
| Claude Code | Oui |
| OpenAI Codex CLI | Oui |
J’ai utilisé VS Code avec GitHub Copilot comme principal environnement de test.
La configuration m’a montré que Connector est facile à mettre en route. Elle ne disait encore rien sur sa capacité réelle à accomplir correctement le travail une fois connecté, ce qui est la question plus difficile que j’ai abordée ensuite.
Installer et connecter une extension, c’est la partie facile. Ce qui compte vraiment, c’est qu’elle fasse correctement le travail d’hébergement réel ; j’ai donc construit une petite application Express.js appelée PulseWatch et j’ai soumis Connector au même parcours qu’un développeur suivrait après l’installation : inspecter le compte, trouver une cible de déploiement, déployer le projet, le mettre à jour, inspecter les résultats et récupérer après une panne que j’avais provoquée volontairement.
| Test | Ce que je voulais apprendre |
|---|---|
| Lire les données du compte | Peut-il comprendre avec précision le compte d’hébergement ? |
| Trouver une cible de déploiement | Peut-il identifier le bon site web sans deviner ? |
| Analyser le projet Node.js | Comprend-il l’application avant d’y toucher ? |
| Déployer PulseWatch | Peut-il faire passer un vrai projet de l’éditeur à l’hébergement en direct ? |
| Publier une mise à jour de contenu | Est-il utile pour le travail de développement courant ? |
| Inspecter les builds et les journaux | Fournit-il des preuves utiles après un déploiement ? |
| Déployer une version cassée | Révèle-t-il un vrai échec de l’application ? |
| Récupérer l’application | Peut-il restaurer un état connu comme sain en toute sécurité ? |
PulseWatch était volontairement simple : un serveur Express, une page d’accueil, un script de démarrage package.json et un point de terminaison /api/health renvoyant du JSON. Ce point de santé s’est avéré important plus tard.
Une plateforme d’hébergement peut signaler un build terminé alors même que l’application échoue au démarrage. Un point de terminaison en direct m’a donné un moyen indépendant de vérifier si le processus déployé répondait réellement, plutôt que de faire confiance à un badge d’état.
J’ai commencé par des prompts en lecture seule avant d’autoriser l’assistant à faire le moindre changement en production. S’il ne pouvait pas décrire mon compte avec précision, j’aurais eu peu de raisons de lui faire confiance pour les déploiements, le DNS ou les actions VPS.
L’outil de liste des sites du Connector a renvoyé cinq sites :
Mon compte contenait en réalité davantage que cela. hPanel affichait des sites répartis sur les plans Premium, Business et Growth, y compris des sites WordPress, des sites PHP/HTML, des projets Website Builder et plusieurs domaines temporaires.
Sur un autre prompt demandant quels étaient mes plans d’hébergement actifs, l’assistant m’a dit que j’avais « one active hosting plan ». hPanel en montrait trois : Premium, Growth et Business.
| Vérification | Résultat |
|---|---|
| Sites web connus listés | Réussi |
| Tous les plans d’hébergement listés | Échoué |
| Détection du plan Business inutilisé | Échoué |
| A effectué des changements sur le compte | Non |
Pour être juste envers Connector, lorsque j’ai relevé l’écart et signalé la différence, il s’est corrigé, a clairement distingué ce qu’il avait vérifié de ce qu’il avait supposé, et n’a pas répété la mauvaise affirmation.
C’est un meilleur mode d’échec que de s’entêter, mais cela signifie que la première réponse à une question portant sur le compte ne devrait pas être prise au pied de la lettre.
L’accès en lecture seule a fonctionné, mais la première réponse à toute question portant sur le compte était incomplète. Il s’est corrigé une fois contesté, ce qui compte, mais je n’aurais pas dû avoir à le contester.
Cette lacune dans la visibilité du compte s’est révélée être un avant-goût d’un problème plus grand. Le vrai test pour savoir si cela importait est arrivé ensuite, quand j’ai demandé au Connector de trouver un site web qu’il n’avait jamais vu nommé auparavant.
C’est là que les tests ont révélé le plus de choses. J’ai demandé à l’assistant d’identifier un site web Node.js nouvellement créé sans que je nomme son domaine, et sans toucher à un site existant.
La sélection de la cible est une exigence de sécurité de base pour un outil capable d’agir sur un compte réel, alors je voulais voir comment il gérait l’incertitude plutôt qu’une réponse propre.
Voici ce qui s’est passé, dans l’ordre :
| Étape | Ce que le Connector a fait | Résultat |
|---|---|---|
| 1 | A réutilisé un nom de domaine d’une tentative précédente échouée : pulsewatch-temp-20260714.hostingersite.com | Ce domaine n’avait jamais été renvoyé par un appel de liste des sites |
| 2 | A exécuté une vérification d’accessibilité sur ce domaine | A renvoyé is_accessible: true |
| 3 | A pris ce résultat pour confirmation que le site web existait | Incorrect. L’accessibilité n’est pas la même chose qu’un enregistrement de site web existant et déployable |
| 4 | A tenté un déploiement à l’aide d’identifiants de ressource qu’il n’avait pas vérifiés comme étant des identifiants de commande d’hébergement | Hostinger a renvoyé [Hosting:9999] Not found, deux fois |
Le problème principal : les deux identifiants qu’il a utilisés étaient des identifiants de ressource de domaine, et non des identifiants de commande d’hébergement. Il n’a jamais confirmé la distinction avant d’appeler un outil de création de site web réel avec eux.
Lorsque je lui ai demandé de s’expliquer, l’assistant a finalement donné un compte rendu exact : il disposait tout le temps d’un outil de liste des sites web fonctionnel, mais ne l’avait plus appelé après que j’ai créé un nouveau site via hPanel, alors il a comblé le vide avec un domaine non vérifié au lieu d’actualiser ses données.
Quand je lui ai demandé directement de relancer cet outil de liste et de vérifier l’existence d’un nouvel enregistrement, il a appelé trois outils de recherche de déploiement sans rapport et a indiqué « no new website appeared », une conclusion que les appels d’outils qu’il a réellement effectués ne pouvaient pas étayer.
Rien de tout cela n’a créé de site web parasite dans mon compte. Les appels échoués n’ont laissé aucune trace. Mais le schéma mérite d’être nommé clairement. Face à des données incomplètes, l’assistant a comblé le manque par une supposition plausible, a pris un signal faible pour une preuve forte, et a agi sur un compte réel avant que cette supposition ne soit vérifiée.
C’est la constatation la plus importante de cette section. Le Connector devinera une cible et agira sur cette supposition plutôt que de s’arrêter pour demander. Il a échoué de manière sûre ici, mais cette habitude de traiter un signal faible comme une preuve est ce qu’il faut surveiller dans votre propre compte.
Le Connector étant incapable de localiser la cible par lui-même, il ne me restait qu’une option : créer la cible moi-même et voir si cela changeait quelque chose.
Comme le Connector ne pouvait pas localiser de manière fiable la nouvelle cible par lui-même, j’ai terminé la configuration initiale manuellement via hPanel pour voir ce que Hostinger prépare avant que le déploiement via Connector ne devienne possible.
Le parcours était : Créer un nouveau site → application web Node.js → domaine temporaire → Hostinger a automatiquement choisi un centre de données au Royaume-Uni avec une latence estimée à 147ms → choix de trois méthodes de déploiement.
Ce troisième écran mérite d’être signalé à lui seul. Hostinger propose « Build with Hostinger Connector » comme méthode de déploiement au même niveau que l’import depuis GitHub et le téléversement manuel de fichiers. Je l’ai sélectionné en m’attendant à ce qu’il termine la configuration du site.
À la place, il m’a redirigé vers la page d’installation propre à Connector, que j’avais déjà terminée. C’est une vraie lacune d’intégration. L’option présentée comme un parcours natif Connector n’a en réalité rien provisionné.
Je suis revenu en arrière et j’ai choisi à la place le téléversement manuel de fichiers. Hostinger a accepté l’archive de mon projet (11.46 KB, avec node_modules exclu), et l’écran de paramètres a montré une détection automatique précise :
J’ai cliqué sur Deploy. Le déploiement s’est terminé avec succès, et Hostinger a attribué un véritable domaine temporaire : orange-walrus-700988.hostingersite.com. C’est un domaine différent de celui qu’avait inventé Connector auparavant. J’ai ouvert manuellement la page d’accueil et /api/health et j’ai confirmé que les deux fonctionnaient.
Le parcours manuel a fonctionné sans friction une fois que j’ai cessé d’attendre que Connector trouve la cible. Le bouton « Build with Hostinger Connector » sur cet écran devrait être corrigé ou supprimé. Pour l’instant, il promet quelque chose qu’il ne fait pas.
Un site réel et confirmé existait maintenant. La prochaine question était de savoir si le Connector se comporterait différemment maintenant qu’il avait quelque chose de solide à trouver.
Avec un vrai site web confirmé en place, je suis retourné vers le Connector et lui ai demandé d’inspecter ce domaine exact. Cette fois, cela a fonctionné proprement.
| Vérification | Résultat |
|---|---|
| A reconnu le site comme une cible de déploiement Node.js | Réussi |
| A trouvé l’enregistrement de déploiement terminé | Réussi |
| A trouvé l’enregistrement de build Node.js correspondant | Réussi |
| Le déploiement et le build partageaient le même UUID | Réussi |
Cela a confirmé quelque chose d’important : les échecs précédents concernaient la localisation et la création d’une nouvelle cible, et non la capacité du Connector à travailler avec un site Node.js une fois qu’il existe.
J’ai ensuite testé la fonctionnalité que Hostinger met le plus en avant : modifier une ligne de code localement et la publier sans ouvrir hPanel.
J’ai demandé à l’assistant de modifier une ligne du texte de la page d’accueil, de « Monitor Every Service. Catch Every Issue. » à « Monitor Every Service. Resolve Issues Faster. »
| Étape | Résultat |
|---|---|
| A trouvé le texte existant | Réussi |
| N’a modifié que la ligne demandée | Réussi |
| A vérifié l’application localement avant de déployer | Réussi |
A empaqueté le projet, en excluant node_modules et .git | Réussi |
| A déployé vers le site confirmé existant | Réussi |
| A vérifié ensuite l’état du déploiement et du build | Réussi |
L’ensemble de la mise à jour a pris environ une minute. L’assistant a signalé le nouveau déploiement comme « pending » immédiatement après l’envoi, simplement parce qu’il a vérifié avant que Hostinger ait fini de le traiter.
Au moment où j’ai rafraîchi le site en direct moi-même, le nouveau titre était déjà en place.
Les journaux de build qu’il a récupérés ensuite étaient précis et utiles : 67 packages ajoutés, 68 audités, zéro vulnérabilité trouvée, aucune erreur.
Pour les sites établis, cela se rapproche du flux de travail promis par Hostinger. Modifier, vérifier localement, publier et confirmer, le tout sans quitter l’éditeur, en environ une minute. C’est le meilleur résultat de tout le test.
Un déploiement propre ne me dit pas tout sur le fonctionnement heureux du parcours. Pour voir ce que le Connector fait réellement sous pression, j’ai cassé l’application volontairement.
Un outil n’obtient la confiance que lorsqu’il survit au contact d’un vrai échec, et pas seulement à une démonstration propre. J’ai volontairement cassé l’application pour voir si le reporting d’état et les journaux du Connector pouvaient réellement m’aider à diagnostiquer le problème.
Avant toute modification, l’assistant a sauvegardé package.json dans package.json.bak, ce qui est déjà une bonne pratique en soi.
Je lui ai ensuite fait changer le script de démarrage de “start”: “node server.js” à “start”: “node missing-server.js”, un fichier qui n’existe pas.
Son exécution en local a confirmé un vrai échec reproductible : Error: Cannot find module ‘…/missing-server.js’.
J’ai déployé la version cassée quand même, volontairement, pour voir ce que Hostinger allait signaler.
| État affiché | Ce qu’il a confirmé | Ce qu’il n’a pas confirmé |
|---|---|---|
| Build : terminé | Les dépendances ont été installées, l’étape de build s’est terminée | L’application a réellement démarré |
| Déploiement : terminé | Hostinger a accepté et traité la version | Toutes les routes étaient saines |
Les journaux de build accessibles via le Connector montraient une installation réussie des dépendances et rien d’autre. L’erreur d’exécution liée au module manquant n’y apparaissait jamais. Un développeur qui ne verrait qu’un badge vert « completed » n’aurait aucune raison de soupçonner que le site était cassé.
La récupération s’est déroulée sans problème. L’assistant a restauré package.json à partir de sa sauvegarde, a vérifié l’application localement, a redéployé, puis a confirmé la correction en appelant directement le point de terminaison /api/health en production plutôt qu’en se fiant à l’état du déploiement seul.
Ce point de terminaison a renvoyé une réponse opérationnelle, qui était la seule preuve dans tout le test montrant réellement que l’application fonctionnait.
C’est la deuxième constatation majeure. Un état terminé ne prouve pas qu’une application fonctionne, et les journaux du Connector ne vous le diront pas non plus. La récupération elle-même a bien fonctionné une fois que j’ai su qu’il y avait un problème à récupérer.
Après un échec qu’un badge d’état ne pouvait pas révéler, je voulais savoir ailleurs où la confiance du Connector pouvait dépasser ses capacités réelles. Les variables d’environnement étaient le test suivant.
J’ai demandé à l’assistant d’ajouter une variable d’environnement inoffensive, de confirmer qu’il existait une capacité dédiée du Connector avant de toucher quoi que ce soit, et de s’arrêter si ce n’était pas le cas.
Il a recherché les outils disponibles, n’a trouvé aucune action dédiée à la gestion des variables d’environnement Node.js, et s’est arrêté avant d’apporter des modifications au code ou au déploiement.
C’est le comportement que je voulais voir partout ailleurs dans ce test. Confronté à une vraie limite, il s’est arrêté au lieu de deviner. Je ne conclurais pas que Hostinger Connector n’a aucun support des variables d’environnement ailleurs dans son ensemble d’outils, seulement qu’aucune action de ce type n’était exposée pendant ce test.
| Test | Résultat | Constat clé |
|---|---|---|
| Sauvegarder le manifeste fonctionnel | Réussi | Fichier de récupération créé avant modification |
| Introduire un point d’entrée manquant | Réussi | Échec contrôlé ajouté |
| Reproduire l’échec en local | Réussi | MODULE_NOT_FOUND confirmé |
| Déployer la version cassée | Réussi | Hostinger a accepté l’archive |
| L’état du build détecte l’échec | Échoué | Le build affichait toujours completed |
| Les journaux du build exposent l’erreur d’exécution | Échoué | L’erreur de module manquant n’apparaissait pas |
| Restaurer le manifeste fonctionnel | Réussi | Commande de démarrage d’origine récupérée |
| Redéployer la version fonctionnelle | Réussi | Déploiement terminé |
| Vérifier le point de terminaison de santé en production | Réussi | L’API a renvoyé un état opérationnel |
Hostinger Connector a bien exécuté les tâches déterministes de routine :
Il était plus faible lorsque la tâche nécessitait une interprétation à partir de données de compte incomplètes :
Ce schéma est utile pour décider du degré d’autonomie à accorder à l’assistant.
Utilisez des prompts larges pour l’inspection à faible risque. Utilisez des prompts précis et des exigences de confirmation explicites pour les actions qui modifient l’infrastructure en production.
Par exemple, au lieu de :
| Déployez cette application sur un nouveau site temporaire Hostinger. |
utilisez :
| Listez les sites web actuellement renvoyés par Hostinger. Identifiez un site web Node.js uniquement s’il apparaît dans ce résultat. Montrez-moi le domaine exact et la preuve avant de déployer. Ne générez, n’inférez et ne réutilisez aucun domaine qui n’a pas été renvoyé par Hostinger. |
Le second prompt réduit la marge d’erreur de l’assistant.
Mettre Hostinger Connector en route a été facile, sans les frictions habituelles de configuration, et les contrôles granulaires par catégorie d’outils m’ont donné un vrai pouvoir sur ce que l’IA pouvait toucher.
Une fois qu’un vrai site web existait avec un domaine connu, il a bien accompli la tâche : une modification d’une ligne est passée de l’édition au site en production en environ une minute, avec des journaux de build utiles à l’appui.
Le problème est apparu plus tôt dans le processus, pas plus tard. Face à un nouveau target qu’il ne pouvait pas trouver, le Connector a inventé un domaine et a agi sur cette supposition avant de vérifier. Il a aussi marqué un déploiement cassé comme « completed » alors que l’application était réellement hors ligne, sans erreur d’exécution dans ses propres journaux. Aucune de ces deux situations ne rend l’outil peu fiable pour des sites établis, mais elles signifient que les nouveaux déploiements et l’état après déploiement nécessitent un second regard avant de leur faire confiance.
Hostinger structure son support autour du chat en direct et de l’autonomie en libre-service plutôt que de l’assistance téléphonique, j’ai donc concentré mes tests là où la plupart des utilisateurs vont réellement atterrir : l’assistant IA intégré à hPanel, l’escalade humaine derrière lui, et la base de connaissances qu’un développeur consulterait avant d’ouvrir un chat.
| Canal | Disponibilité | Remarques |
|---|---|---|
| Chat en direct (Kodee, IA) | 24/7 | Accessible via « Ask AI » dans hPanel |
| Chat en direct (humain) | Sur escalade seulement | Pas de file directe, passage par Kodee |
| E-mail / ticket | support@hostinger.com | Délai de réponse annoncé d’un jour ouvré |
| Téléphone | Non proposé | Aucune ligne téléphonique publique pour le support général |
| Base de connaissances | Libre-service | support.hostinger.com |
| Tutoriels et Academy | Libre-service | Guides pas à pas et chaîne YouTube |
Comme le chat en direct est le canal que Hostinger recommande aux développeurs pour tout ce qui est urgent, et celui qui sera le plus probablement utilisé pendant le débogage d’un déploiement, j’ai testé ce chemin directement plutôt que de déposer un ticket par e-mail.
J’ai ouvert le chat en direct via « Ask AI » dans hPanel et ai posé à Kodee une question dont il était facile de se tromper : un état de build terminé sur un déploiement Node.js garantit-il que l’application fonctionne réellement, et où trouver la preuve du contraire ?
La première réponse de Kodee était précise et correcte :
« Completed » signifie généralement que l’étape de build s’est terminée avec succès ; cela ne garantit pas que l’application est saine après le lancement. Pour détecter une mauvaise commande de démarrage ou un autre plantage à l’exécution, consultez les journaux d’exécution : dans hPanel, allez dans Websites → Dashboard → Deployments pour les journaux de build, puis ouvrez le fichier stderr.log de votre application dans le dossier nodejs pour les erreurs de démarrage comme Port already in use ou Module not found.
Cette seule réponse aurait résolu exactement l’ambiguïté rencontrée plus tôt dans mon test de récupération après échec. Kodee a nommé un vrai fichier de journal, le bon dossier, et a tracé la bonne frontière entre succès du build et santé à l’exécution.
Cependant, je voulais aussi voir si je pouvais avoir accès à un véritable agent humain, alors j’ai dit à Kodee que j’aimerais confirmer cela directement avec un agent du support.
Mais obtenir un humain au bout du fil a été plus difficile que prévu. J’ai demandé directement un agent en direct et j’ai été redirigé deux fois vers Kodee, chaque fois en mettant en avant que c’était plus rapide que d’attendre :
Je comprends pourquoi vous voudriez cela. Je peux vous aider à vérifier le build, la commande de démarrage et les journaux d’exécution ici même, ce qui est généralement le moyen le plus rapide d’identifier le problème.
Avant de mettre un spécialiste en file d’attente. Je peux résoudre le problème et vous éviter l’attente.
| Tentative | Ma demande | Réponse de Kodee |
|---|---|---|
| 1 | « Pouvez-vous me mettre en relation avec un agent en direct ? » | A proposé de résoudre lui-même le problème |
| 2 | « J’aimerais quand même parler à un agent humain. Veuillez me mettre en relation. » | A de nouveau proposé son aide, en demandant le domaine et la commande de démarrage |
| 3 | A cliqué sur « Go to human » / a tapé « I want to continue with a human » | Escaladé |
Il a fallu deux demandes directes et explicites avant que Kodee cesse de me rediriger vers lui-même. Pour une question que je pouvais résoudre moi-même, cette friction est mineure. Pour quelqu’un en pleine panne qui veut parler à une personne, c’est une vraie source de frustration.
Ce qui s’est passé ensuite n’était pas un transfert en direct au sens habituel de « mettre en relation avec un humain ». Kodee a expliqué clairement le modèle réel :
J’ai transmis votre demande à un spécialiste de notre équipe qui examinera personnellement notre conversation et m’enverra sa réponse, que je vous transmettrai ensuite ici.
Il s’agit d’un examen asynchrone, pas d’un transfert en direct. Kodee reste l’interface ; un humain examine la transcription en arrière-plan et Kodee relaie la réponse lorsqu’elle arrive. Cette distinction est importante pour les lecteurs qui décident d’escalader, puisque « agent humain » ne signifie pas ici qu’une nouvelle personne rejoint la fenêtre de chat comme ce serait le cas sur la plupart des systèmes de chat en direct.
J’ai poussé la même ligne technique plus loin en attendant, en demandant à Kodee de confirmer le chemin exact du journal et de dire si stderr.log est toujours renseigné. Il a donné sa propre réponse correcte, en notant justement que le journal peut être vide si l’application n’a jamais complètement démarré ou a écrit son erreur ailleurs.
L’examen du spécialiste est arrivé en environ 3 minutes, crédité dans le chat à un collègue nommé Mayas, et il a amélioré la réponse de Kodee au lieu de simplement la répéter :
domains/[your-domain]/nodejs/stderr.log est l’emplacement correct. Il n’est pas toujours généré ni renseigné. Vous n’y verrez des entrées que lorsque l’application écrit sur stderr, par exemple en cas d’exceptions non interceptées ou de rejets non gérés. Si la commande de démarrage est incorrecte et que le processus se termine silencieusement, stderr.log peut être vide ou absent.
Mayas a également ajouté deux vérifications de repli que Kodee n’avait pas mentionnées : consulter stdout.log pour voir la dernière sortie avant un crash, et chercher une ligne de confirmation de démarrage manquante comme signe que l’application n’a jamais démarré du tout.
| Vérification | Résultat |
|---|---|
| Première réponse technique correcte | Oui |
| Escalade humaine disponible | Oui, mais résisté deux fois avant d’être accordé |
| Modèle d’escalade | Examen asynchrone et transmission, pas de transfert en direct |
| Répondant nommé | Mayas |
| Délai de réponse pour l’examen humain | Environ 3 minutes |
| Réponse humaine plus précise que la réponse IA | Oui |
La base de connaissances de Hostinger est organisée en grandes catégories de produits : Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel, et About Hostinger.
Aucune de ces catégories n’est dédiée à Hostinger Connector. Le seul moyen que j’ai trouvé pour localiser le bon article était de rechercher directement « Hostinger Connector », ce qui a renvoyé cinq résultats, dont la plupart n’étaient que vaguement liés, y compris un guide de plugin de marketing d’affiliation et un article général sur l’hébergement Node.js.
L’article qui documente réellement la configuration du Connector s’intitule « How to Set Up Web Hosting MCP on Local IDEs », classé sous Features → General Information.
La recherche avec le vrai nom marketing du produit l’a trouvé, mais un lecteur parcourant les catégories ou cherchant « MCP » sans connaître la marque Hostinger pourrait le manquer tout aussi facilement, et le décalage entre le nom marketing et le nom de la documentation mérite d’être connu avant de chercher.
L’article lui-même est solide une fois trouvé. Il a été mis à jour pour la dernière fois six jours avant mon test, et il couvre :
Ce dernier point correspondait à quelque chose que j’ai rencontré directement pendant les tests : Devin Desktop est détecté automatiquement, tandis qu’OpenAI Codex nécessite la méthode manuelle. L’article indique correctement cette distinction.
La première réponse de Kodee à une question technique difficile était exacte et spécifique, ce qui n’est pas le cas de tous les assistants de support IA. L’article de base de connaissances qui la soutient est actuel et détaillé une fois trouvé, même si le nom marketing du produit et le titre de sa documentation ne correspondent pas, donc la recherche est un chemin plus fiable que la navigation par catégories.
Le point plus faible est le parcours d’escalade vers un humain. Kodee m’a redirigé vers lui-même deux fois avant d’honorer une demande directe de parler à une personne, et même là, « agent humain » signifie un examen asynchrone relayé par le même chat plutôt qu’un transfert en direct. Une fois qu’un humain a effectivement examiné le dossier, la réponse était meilleure que celle de Kodee, plus précise et avec deux étapes de diagnostic supplémentaires que Kodee n’avait pas proposées.
Pour la plupart des questions, Kodee seul vous donnera rapidement une réponse exacte. Si vous voulez réellement qu’une personne vérifie la réponse, attendez-vous à devoir demander plus d’une fois, et attendez-vous à un court délai pour une réponse relayée plutôt qu’à une conversation en direct.
Oui, pour les développeurs qui hébergent déjà chez Hostinger et veulent gérer les déploiements courants depuis l’éditeur. La configuration a pris quelques minutes, l’OAuth a supprimé le besoin de clés API, et une fois qu’un site web existait avec un domaine connu, le Connector a publié une mise à jour en production en environ une minute avec des journaux à l’appui. Les réponses de support de Kodee étaient assez pointues pour résoudre du premier coup un vrai problème technique.
Le piège concerne la confiance, pas la commodité. Face à une nouvelle cible qu’il ne pouvait pas trouver, le Connector a inventé un domaine et a agi sur cette supposition avant de vérifier.
Il a également marqué un déploiement cassé comme « completed » alors que l’application était en réalité hors ligne, sans erreur d’exécution dans ses propres journaux. Utilisez-le pour accélérer le travail sur des sites qui existent déjà, vérifiez tout ce qu’il fait sur une toute nouvelle cible, et contrôlez vous-même le site en direct après tout déploiement important.
| Description | Expert Review |
|---|---|
| Hébergement économique avec des performances élevées et des outils de gestion fac... | Read Shared Hosting Review |
| hébergement WordPress rapide et sécurisé avec installation en un clic et fonctionn... | Read Wordpress Hosting Review |
| Hébergement VPS évolutif avec ressources dédiées et accès root. | Read VPS Review |
| Hébergement cloud rapide et flexible avec une excellente disponibilité et des resso... | Read Cloud Hosting Review |
| Solutions d’hébergement sécurisées et privées avec des centres de données offs... | Read Offshore Hosting Review |
| Hébergement de messagerie sécurisé et fiable avec des fonctionnalités de qualité... | Read Email Hosting Review |
| Hébergement Python fiable avec des environnements flexibles pour les développeurs. | Read Python Hosting Review |
| Hébergement PHP haute performance avec prise en charge complète des sites web et de... | Read PHP Hosting Review |
| Hébergement VPS Windows fiable avec un contrôle total et des options de personnalis... | Read Windows VPS Review |
| Hébergement rapide et flexible adapté aux applications Node.js avec des performance... | Read Nodejs Hosting Review |
| Hébergement optimisé pour les boutiques WooCommerce avec une grande rapidité et un... | Read Woocommerce Hosting Review |
| Hébergement de serveurs dédiés pour des expériences de jeu Minecraft fluides. | Read Minecraft Server Hosting Review |
| Solutions d’hébergement évolutives avec des fonctionnalités avancées pour les a... | Read Agency Hosting Review |
| Hébergement rapide et sécurisé optimisé pour les sites e-commerce Magento. | Read Magento Hosting Review |
| Hébergement Linux haute performance pour des opérations de site web stables et séc... | Read Linux Hosting Review |
| Solutions d'hébergement Java robustes pour des applications web dynamiques et des pr... | Read Java Hosting Review |
| Hébergement optimisé pour les sites e-commerce avec des performances sécurisées, ... | Read Ecommerce Hosting Review |
| Hébergement Django fiable avec des vitesses rapides et un environnement sécurisé. | Read Django Hosting Review |
| Hébergement cPanel facile à utiliser avec des performances robustes et un support f... | Read Cpanel Hosting Review |
| Hébergement puissant pour les entreprises avec des vitesses rapides, la sécurité e... | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| Hébergement dédié de serveur SMTP pour une livraison d’e-mails fiable et sécuri... | Read SMTP Server Review |
| Hébergement rapide et optimisé adapté aux applications web Ruby on Rails. | Read Ruby on Rails Review |
| Hébergement riche en fonctionnalités avec intégration OpenClaw pour créer et gér... | Read OpenClaw Review |
| Hébergement rapide et fiable avec des serveurs basés au Royaume-Uni pour des perfor... | Read UK Hosting Review |
| Hébergement abordable et fiable avec des serveurs basés en Inde pour un accès à f... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review |
Hostinger Connector est une intégration basée sur MCP qui connecte les environnements de codage IA pris en charge aux services Hostinger.
Elle permet à un assistant IA d’appeler les outils Hostinger pris en charge pour des tâches impliquant des sites web, des déploiements, des domaines, le DNS, des bases de données, l’e-mail et des ressources VPS.
Connector n’est pas une plateforme d’hébergement distincte et ne remplace pas hPanel. Il offre une autre façon d’interagir avec les ressources Hostinger.
Hostinger indique actuellement :
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger précise également que d’autres clients compatibles MCP peuvent être pris en charge. La configuration et le comportement des outils peuvent varier selon les clients.
L’extension Hostinger est gratuite à installer et incluse avec les forfaits Hostinger. Il n’existe aucun abonnement séparé à l’extension dans les tarifs affichés lors de cet examen. Vous devez tout de même payer pour le service Hostinger sous-jacent, comme l’hébergement web, l’hébergement cloud ou un VPS.
Non. Hostinger Connector utilise l’authentification OAuth. Lors de ma configuration dans VS Code, je me suis connecté via le flux d’autorisation de Hostinger basé sur le navigateur. Je n’ai pas généré de clé API, collé de jeton dans l’éditeur, ni stocké d’identifiants dans un fichier de configuration.
Non. Hostinger indique que les appels Connector API interagissent avec le compte en direct. Utilisez un site web, un domaine ou un VPS de test dédié lorsque vous apprenez le flux de travail. Ne supposez pas qu’une invite est simulée simplement parce qu’elle est émise via un chat IA.
Oui. La documentation de Hostinger indique des limites par défaut de :
– 60 requêtes par minute
– 1 000 requêtes par heure
Hostinger indique également que les détails de la limite de fréquence sont renvoyés dans les en-têtes de réponse.
Ces limites devraient être suffisantes pour une utilisation interactive normale. Évitez les appels répétés inutiles, surtout lorsqu’une réponse précédente contient déjà l’information requise.
Oui. J’ai déployé une application Express.js sur Hostinger et j’ai ensuite utilisé Connector pour publier une version mise à jour depuis VS Code. Hostinger a détecté Express, a sélectionné Node.js 22.x et a utilisé la racine du projet comme répertoire racine lors du déploiement initial dans hPanel. Une fois que le site web existait en tant que cible Node.js reconnue, le déploiement répété via Connector a fonctionné correctement.
Pas nécessairement. Dans mon test contrôlé, Hostinger a signalé une compilation terminée après que j’ai modifié le script de démarrage pour qu’il fasse référence à un fichier JavaScript manquant. Les journaux de compilation récupérés montraient une installation des dépendances réussie, mais n’exposaient pas l’échec du démarrage à l’exécution. Vérifiez toujours le site web en direct ou appelez un point de terminaison de santé après le déploiement.
Pas complètement. Connector peut réduire la fréquence à laquelle les développeurs doivent quitter leur éditeur, notamment pour les déploiements de routine et les vérifications de compte. hPanel reste utile pour la gestion visuelle du compte, la configuration initiale, les paramètres détaillés et les situations où l’IA ne peut pas découvrir ou exposer correctement la ressource requise.
Répondez à quelques questions simples et trouvez la solution parfaite pour vous !
Commencer la recherche d'hébergement
HostAdvice.com fournit des critiques professionnels d'hébergement web totalement indépendantes de toute autre entité. Nos avis sont impartiaux, honnêtes, et les mêmes critères d'évaluations sont appliqués à toutes les sociétés examinées.
Bien qu'une compensation financière soit reçue de la part de quelques hébergeurs apparaissant sur le site, la rémunération de services et de produits n'influence en aucun cas le sens et les conclusions de nos avis. Celle-ci n'affecte pas non plus le classement de certains hébergeurs.
Cette rémunération couvre les frais d'achats de compte, de tests et les droits d'auteur versés aux critiques.
