Gérer 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, passez à un terminal pour empaqueter ou pousser le projet, revenez au tableau de bord pour inspecter un déploiement, et ouvrez encore d’autres outils lorsque le DNS, les journaux ou les ressources du serveur exigent votre attention.

Hostinger Connector réduit ces changements de contexte. Il connecte les services Hostinger aux outils de codage IA grâce au Model Context Protocol (MCP), ce qui vous permet de demander à un assistant IA d’inspecter ou de gérer des ressources d’hébergement prises en charge sans quitter votre éditeur.

Ça semble pratique. Cela soulève aussi une question plus importante : Pouvez-vous faire confiance à un assistant IA pour exécuter correctement de vraies tâches d’hébergement ?

Pour le savoir, j’ai testé Hostinger Connector avec VS Code et GitHub Copilot sur un vrai compte Hostinger. J’ai utilisé une petite application Express.js appelée PulseWatch et suivi le flux de travail, de l’installation au déploiement en ligne. J’ai aussi testé les redéploiements répétés, les journaux de build, les logs et la récupération après avoir volontairement cassé la commande de démarrage de l’application.

Hostinger Connector Plans with Hostinger

Intégrez Hostinger aux applications et services que vous utilisez déjà pour automatiser des tâches, améliorer les flux de travail et gérer votre site Web plus efficacement.

Visitez Hostinger

Avantages et inconvénients de Hostinger Connector

Répartition des notes

Voici comment j’ai évalué Hostinger Connector dans les domaines qui comptent le plus pour un développeur qui décide de l’utiliser : le coût, l’éventail des fonctionnalités, l’utilisabilité au quotidien, la précision avec laquelle il exécute les tâches réelles, et le soutien disponible quand quelque chose tourne mal. Chaque note reflète ce que j’ai réellement constaté lors des tests, pas la page marketing.

Forfaits et tarifs de Hostinger Connector

Hostinger Connector n’est pas vendu comme un produit autonome. Hostinger indique que Connector est inclus gratuitement avec chaque forfait, ce qui signifie qu’il n’y a pas de frais mensuels distincts pour Connector à ajouter à votre facture d’hébergement.

Cependant, « gratuit » nécessite du contexte. Connector gère des ressources Hostinger ; il ne les remplace pas. Vous avez toujours besoin d’un service d’hébergement, cloud, VPS, domaine, courriel ou autre service Hostinger admissible pour les tâches que vous souhaitez lui faire exécuter.

Au moment de cette évaluation, la page de destination de Connector mettait en avant Business Web Hosting et Cloud Startup.

Les prix étaient affichés avant les taxes applicables. Les prix promotionnels et les tarifs de renouvellement peuvent changer, alors vérifiez le total actuel au moment du paiement plutôt que de juger le forfait uniquement sur le prix mensuel annoncé.

Point de vue sur les prix : N’achetez pas un forfait supérieur uniquement pour accéder à Connector. Choisissez le forfait en fonction du nombre de sites Web et d’applications Web dont vous avez besoin, des ressources qu’ils exigent et du niveau de soutien que vous souhaitez. Connector est une couche de gestion incluse, pas le produit principal qui est tarifé.

Hostinger annonce une garantie de remboursement de 30 jours pour les achats d’hébergement admissibles. Il n’y a pas de politique de remboursement distincte pour Connector à évaluer puisque Connector n’a pas de frais autonomes.

Hostinger Connector Plans with Hostinger

Intégrez Hostinger aux applications et services que vous utilisez déjà pour automatiser des tâches, améliorer les flux de travail et gérer votre site Web plus efficacement.

Visitez Hostinger

Fonctionnalités

• Déploiement d’applications Node.js
• Déploiement PHP et HTML
• Gestion de sites Web WordPress
• Flux de travail pour Website Builder et Horizons
• Déploiements liés à GitHub
• Connexion et organisation de domaines
• Inspection et mises à jour DNS
• SSL et diagnostics de site Web
• Gestion de bases de données
• Configuration et administration VPS
• Déploiement de projets Docker
• Surveillance du CPU et de la mémoire
• Vérifications de bande passante et d’espace disque
• Redémarrages de services et de conteneurs
• Analyse des logiciels malveillants
• Restauration de sauvegarde
• Configuration de campagnes courriel
• Inspection des déploiements et des builds

Les actions exactes disponibles dépendent des services Hostinger 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 de 1 000 requêtes par heure, avec les renseignements sur les limites de débit renvoyés dans les en-têtes de réponse.

Ces limites sont généreuses pour une utilisation interactive, même si les flux de travail automatisés ou très répétitifs devraient quand même éviter les appels dupliqués inutiles.

Facilité d’utilisation

1. Installation et authentification

Avant de pouvoir juger si Hostinger Connector déploie et gère correctement l’hébergement, je devais savoir ce qu’il fallait pour le faire fonctionner au départ.

Un outil conçu pour rester dans l’éditeur perd vite de son attrait si la configuration exige de modifier des fichiers de config, de générer des jetons API ou de s’authentifier de façon répétée. Cette section couvre seulement la configuration. Les tests pratiques des tâches viennent juste après.

Installation de l’extension

J’ai installé Hostinger Connector depuis VS Code Marketplace. Il est apparu comme premier résultat quand j’ai cherché « Hostinger », l’éditeur était indiqué comme Hostinger Official, et l’installation a réussi du premier coup en moins de deux minutes.

Cette dernière ligne mérite une réserve. Cinq étoiles, ça semble solide, mais un échantillon de deux avis ne me dit presque rien sur l’expérience typique des utilisateurs. Je ne m’appuierais pas sur ce chiffre dans le texte de l’évaluation.

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 les appeler réellement.

L’extension elle-même n’a rien à quoi parler toute seule. Dans VS Code, cet agent est GitHub Copilot Chat, puisqu’il s’agit actuellement de l’interface IA que VS Code expose pour les appels d’outils MCP. J’avais déjà Copilot actif, donc cela ne m’a pas ralenti, mais les lecteurs devraient savoir que Connector n’est utile que dans la mesure où l’agent IA derrière lui l’est aussi.

Sans un agent installé et connecté, il n’y a rien à brancher.

Ce que l’installation n’exigeait pas :

• Une clé API
• Un jeton copié depuis hPanel
• La modification manuelle d’un fichier de configuration MCP
• Des identifiants stockés localement
• Une commande de serveur personnalisée

L’installation de l’extension elle-même a été l’une des parties les plus fluides de tout le test. Le seul vrai bémol est une dépendance qu’Hostinger ne met pas en avant : 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 question suivante était de savoir si la connecter à un vrai compte serait tout aussi simple.

Connexion du compte

La connexion du compte utilisait OAuth par l’intermédiaire d’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 ».

L’écran d’autorisation m’indiquait que Connector pouvait gérer les sites Web, l’hébergement, les domaines, les abonnements et d’autres services Hostinger.

C’est une liste de catégories, pas un détail autorisation par autorisation. J’aurais aimé plus de granularité ici, puisque « 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 peu de ce contrôle, c’est un panneau distinct dans l’extension qui répertoriait chaque catégorie d’outils et me permettait d’activer ou de désactiver chacune d’elles individuellement :

Cela représente 199 outils au total, dont 125 activés par défaut. J’ai laissé le commerce électronique 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 qui décide à quel point elle veut confier son compte à un assistant IA. Je considérerais cela comme une vraie force.

La déconnexion du compte est disponible depuis le même panneau, sans qu’il soit nécessaire de changer votre mot de passe Hostinger ou de chercher un jeton stocké.

L’autorisation a été rapide et n’a pas exigé que je gère moi-même un jeton, mais l’écran d’autorisation est large plutôt que granulaire. Les contrôles d’outils au niveau des catégories dans l’extension font beaucoup plus pour limiter le risque réel que l’écran OAuth lui-même.

Éditeurs pris en charge

Hostinger indique prendre en charge les clients suivants, d’après l’écran d’accueil de l’extension :

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 à faire le travail une fois connecté, qui est la question plus difficile à laquelle je me suis attaqué ensuite.

2. Hostinger Connector en action

Installer et connecter une extension, c’est la partie facile. Ce qui compte vraiment, c’est de savoir si elle fait correctement le vrai travail d’hébergement, alors j’ai 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 d’une panne que j’ai provoquée volontairement.

PulseWatch était volontairement simple : un serveur Express, une page d’accueil, un script start dans package.json  et un point de terminaison /api/health renvoyant du JSON. Ce point de terminaison 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 me donnait 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.

Lecture des données du compte

J’ai commencé avec des invites en lecture seule avant de laisser l’assistant s’approcher de modifications en direct. S’il ne pouvait pas décrire mon compte avec précision, j’aurais peu de raisons de lui faire confiance pour les déploiements, le DNS ou les actions VPS.

L’outil de liste des sites de Connector a renvoyé cinq sites :

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Mon compte contenait en réalité plus que cela. hPanel affichait des sites répartis sur les forfaits Premium, Business et Growth, y compris des sites WordPress, des sites PHP/HTML, des projets Website Builder et plusieurs domaines temporaires.

Lors d’une autre invite demandant mes forfaits d’hébergement actifs, l’assistant m’a dit que j’avais « one active hosting plan ». hPanel en montrait trois : Premium, Growth et Business.

Pour être juste envers Connector, quand j’ai contesté et souligné l’écart, il s’est corrigé, a clairement séparé ce qu’il avait vérifié de ce qu’il avait supposé, et n’a pas répété l’affirmation erronée.

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 doit pas être prise au pied de la lettre.

La lecture seule a fonctionné, mais la première réponse à toute question concernant 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 avérée être un avant-goût d’un problème plus important. Le vrai test pour savoir si cela avait de l’importance est venu ensuite, lorsque j’ai demandé au Connector de trouver un site Web qu’on ne lui avait jamais nommé.

Hostinger Connector Plans with Hostinger

Intégrez Hostinger aux applications et services que vous utilisez déjà pour automatiser des tâches, améliorer les flux de travail et gérer votre site Web plus efficacement.

Visitez Hostinger

Trouver une cible de déploiement

C’est là que les tests ont révélé le plus. J’ai demandé à l’assistant d’identifier un nouveau site Web Node.js sans lui nommer 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 en direct, donc 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 :

Le problème principal : les deux ID qu’il a utilisés étaient des ID de ressources de domaine, pas des ID de commande d’hébergement. Il n’a jamais confirmé la distinction avant d’appeler un outil de création de site Web en direct avec eux.

Quand je lui ai demandé de s’expliquer, l’assistant a fini par donner un compte rendu exact : il avait tout le temps un outil de liste des sites Web fonctionnel à disposition, mais ne l’a jamais rappelé après que j’ai créé un nouveau site via hPanel, donc il a rempli 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 la présence d’un nouvel enregistrement, il a plutôt appelé trois outils de recherche de déploiement sans rapport et a signalé « aucun nouveau site Web n’est apparu », une conclusion que les appels qu’il a réellement effectués ne pouvaient pas soutenir.

Rien de tout cela n’a créé un site Web parasite dans mon compte. Les appels ratés n’ont rien laissé derrière eux. Mais le schéma mérite d’être nommé franchement. Face à des données incomplètes, l’assistant a comblé les lacunes par une hypothèse plausible, a pris un signal faible pour une preuve forte, et a agi sur un compte en direct avant que cette hypothèse soit vérifiée.

C’est la découverte 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 façon sécuritaire ici, mais l’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 de lui-même, je n’avais plus qu’une option : créer moi-même la cible et voir si cela changeait quelque chose.

Finalisation de la configuration dans hPanel

Comme le Connector ne pouvait pas localiser de façon fiable la nouvelle cible par lui-même, j’ai terminé la configuration initiale manuellement dans hPanel pour voir ce que Hostinger prépare avant qu’un déploiement via Connector devienne possible.

Le parcours était : Créer un nouveau site → application Web Node.js → domaine temporaire → Hostinger a automatiquement sélectionné un centre de données au Royaume-Uni avec une latence estimée de 147ms → un 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 aux côtés de l’import GitHub et du téléversement manuel de fichiers. Je l’ai choisi en m’attendant à ce qu’il termine la configuration du site.

Au lieu de cela, il m’a redirigé vers la page d’installation de Connector, que j’avais déjà complétée. C’est une vraie lacune dans l’accueil. L’option présentée comme un chemin natif à Connector ne provisionnait en réalité rien du tout.

Je suis revenu en arrière et j’ai plutôt choisi le téléversement manuel de fichiers. Hostinger a accepté mon archive de projet (11.46 KB, avec node_modules exclus), et l’écran des paramètres a montré une auto-détection précise :

• Préréglage du framework : Express
• Version de Node : 22.x
• Répertoire racine : ./

J’ai cliqué sur Deploy. Cela s’est terminé avec succès, et Hostinger a attribué un vrai domaine temporaire : orange-walrus-700988.hostingersite.com. C’est un domaine différent de celui que le Connector avait inventé plus tôt. 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 le 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 vrai site Web confirmé existait maintenant. La question suivante était de savoir si le Connector se comporterait différemment maintenant qu’il avait quelque chose de concret à trouver.

Déploiement et mise à jour de l’application en direct

Avec un vrai site Web confirmé en place, je suis retourné vers Connector et je lui ai demandé d’inspecter exactement ce domaine. Cette fois, cela a fonctionné proprement.

Cela a confirmé quelque chose d’important : les échecs précédents concernaient la localisation et la création d’une nouvelle cible, pas la capacité du Connector à travailler avec un site Node.js une fois celui-ci existant.

J’ai ensuite testé la fonction que Hostinger met le plus en avant : faire une modification 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. »

Toute la mise à jour a pris environ une minute. L’assistant a signalé le nouveau déploiement comme « pending » immédiatement après l’avoir soumis, simplement parce qu’il a vérifié avant que Hostinger ait fini de le traiter.

Au moment où j’ai actualisé moi-même le site en direct, le nouveau titre y figurait déjà.

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, c’est très proche du flux de travail qu’Hostinger promet. 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 que le chemin heureux fonctionne. Pour savoir ce que Connector fait vraiment sous pression, j’ai cassé l’application volontairement.

Test de récupération après échec

Un outil ne gagne la confiance que lorsqu’il survit au contact d’une vraie panne, pas seulement à une démo propre. J’ai volontairement cassé l’application pour voir si les rapports d’état et les logs du Connector pouvaient réellement m’aider à diagnostiquer le problème.

Avant toute modification, l’assistant a sauvegardé package.json dans package.json.bak, une bonne habitude 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.

Le lancer localement 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 signalerait.

Les journaux de build accessibles via Connector montraient une installation réussie des dépendances et rien d’autre. L’erreur d’exécution de module manquant n’y apparaissait jamais. Un développeur qui jetterait un coup d’œil à un badge vert « completed » n’aurait aucune raison de soupçonner que le site était cassé.

La récupération s’est bien déroulée. L’assistant a restauré package.json à partir de sa sauvegarde, a vérifié l’application localement, l’a redéployée et a confirmé la correction en appelant directement le point de terminaison /api/health du site en direct plutôt qu’en se fiant à l’état du déploiement.

Ce point de terminaison a renvoyé une réponse opérationnelle, qui était la seule preuve dans tout le test que l’application fonctionnait réellement.

C’est la deuxième grande découverte. 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 je savais qu’il y avait une panne à corriger.

Après une panne qu’un badge d’état ne pouvait pas révéler, je voulais savoir où ailleurs la confiance du Connector pouvait dépasser ses capacités réelles. Les variables d’environnement étaient le test suivant.

Tentative de configuration d’une variable d’environnement

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 cherché dans les outils disponibles, n’a trouvé aucune action dédiée pour gérer les variables d’environnement Node.js, et s’est arrêté avant d’apporter le moindre changement au code ou au déploiement.

C’est le comportement que je voulais voir partout ailleurs dans ce test. Face à une vraie limite, il s’est arrêté au lieu de deviner. Je ne conclurais pas que Hostinger Connector n’a aucun soutien pour les variables d’environnement partout dans son ensemble d’outils, seulement qu’aucune telle action n’a été exposée pendant ce test. 

Résumé du test d’échec et de récupération

Ce que le test nous dit sur la fiabilité

Hostinger Connector a bien exécuté les tâches routinières et déterministes :

• Lecture des enregistrements de déploiement connus
• Modification d’un fichier précis
• Exécution de commandes locales
• Emballage d’un projet
• Déploiement vers un site Web connu
• Vérification de l’état du build
• Récupération des journaux disponibles
• Restauration et redéploiement d’une version connue comme bonne

Il était plus faible lorsque la tâche nécessitait une interprétation à partir de données de compte incomplètes :

• Identifier un site Web nouvellement créé
• Distinguer l’accessibilité d’un domaine de l’existence d’un site Web
• Déterminer si un build terminé signifiait que l’application était saine

Ce schéma est utile quand vous décidez combien d’autonomie accorder à l’assistant.

Utilisez des invites plus générales pour l’inspection à faible risque. Utilisez des invites précises et des exigences de confirmation explicites pour les actions qui modifient l’infrastructure en direct.

Par exemple, au lieu de :

utilisez :

La deuxième invite réduit la marge d’erreur de l’assistant.

Verdict global sur la facilité d’utilisation

La mise en route de Hostinger Connector a été facile, sans les frictions habituelles de configuration, et les contrôles granulaires au niveau des catégories 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 effectué la tâche : une modification d’une ligne du texte est passée de l’édition au direct 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. Confronté à un nouveau site qu’il ne pouvait pas trouver, le Connector a inventé un domaine et a agi sur cette base avant de vérifier. Il a aussi marqué un déploiement cassé comme « completed » alors que l’application était en réalité hors service, sans erreur d’exécution dans ses propres logs. Aucune de ces deux situations ne rend l’outil peu fiable pour les sites établis, mais elles signifient toutes deux que les nouveaux déploiements et l’état après déploiement doivent être revérifiés avant de lui faire confiance.

Hostinger Connector Plans with Hostinger

Intégrez Hostinger aux applications et services que vous utilisez déjà pour automatiser des tâches, améliorer les flux de travail et gérer votre site Web plus efficacement.

Visitez Hostinger

Niveau de soutien

Hostinger structure son soutien autour du clavardage en direct et du libre-service plutôt que du téléphone, alors j’ai concentré mes tests là où la plupart des utilisateurs aboutiront vraiment : 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.

Canaux de soutien

Comme le clavardage en direct est le canal vers lequel Hostinger oriente les développeurs pour tout ce qui est urgent, et celui qui a le plus de chances d’être réellement utilisé pendant le débogage d’un déploiement, j’ai testé ce chemin directement plutôt que de soumettre un courriel.

Clavardage en direct : Kodee et le relais humain

J’ai ouvert le clavardage en direct via « Ask AI » dans hPanel et j’ai posé à Kodee une question qu’il était facile de se tromper, avec une vraie réponse à trouver : si un état de build terminé sur un déploiement Node.js garantit réellement que l’application s’exécute, et où je trouverais une 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 à 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 log, le bon dossier et a tracé la bonne ligne entre le succès du build et la santé à l’exécution.

Cependant, je voulais aussi voir si je pouvais obtenir l’accès à un véritable agent humain, alors j’ai dit à Kodee que j’aimerais confirmer cela directement auprès d’un spécialiste du soutien.

Mais obtenir un humain en ligne a été plus difficile que prévu. J’ai demandé directement un agent en direct et j’ai été renvoyé vers Kodee deux fois, chaque fois en soulignant 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 de cerner le problème.

Avant de faire intervenir un spécialiste. Je peux résoudre le problème et vous éviter l’attente.

Il a fallu deux demandes directes et explicites avant que Kodee cesse de me renvoyer 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 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 « mettez-moi avec un humain ». Kodee a expliqué le modèle réel clairement :

J’ai transmis votre demande à un spécialiste de notre équipe qui examinera personnellement notre conversation et me transmettra sa réponse, que je vous relaierai 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 une fois qu’elle arrive. Cette distinction compte pour les lecteurs qui décident d’escalader, puisque « agent humain » ici ne signifie pas qu’une nouvelle personne rejoint la fenêtre de discussion comme ce serait le cas sur la plupart des systèmes de clavardage en direct.

J’ai poussé le même fil technique plus loin en attendant, en demandant à Kodee de confirmer le chemin exact du journal et si stderr.log est toujours rempli. Il a donné une bonne réponse par lui-même, en notant correctement que le journal peut être vide si l’application n’a jamais démarré complètement ou a écrit son erreur ailleurs.

L’examen du spécialiste est arrivé en environ 3 minutes, attribué dans le chat à un membre de l’équipe 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 rempli. Vous n’y verrez des entrées que lorsque l’application écrit sur stderr, comme pour des exceptions non interceptées ou des rejets non gérés. Si la commande de démarrage est erronée et que le processus se termine silencieusement, stderr.log  peut être vide ou absent.

Mayas a aussi ajouté deux vérifications de rechange que Kodee n’avait pas mentionnées : vérifier stdout.log pour la dernière sortie avant un plantage, et chercher l’absence d’une ligne de confirmation au démarrage comme signe que l’application n’a jamais démarré.

Base de connaissances

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. La seule façon que j’ai trouvée pour obtenir le bon article a été de chercher directement « Hostinger Connector », ce qui a renvoyé cinq résultats, la plupart seulement vaguement liés, notamment 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 commercial du produit l’a trouvé, mais un lecteur parcourant les catégories ou recherchant « MCP » sans connaître l’image de marque de Hostinger pourrait le manquer tout aussi facilement, et le décalage entre le nom commercial et le nom de la documentation mérite d’être connu avant de partir à sa recherche.

L’article lui-même est solide une fois trouvé. Il avait été mis à jour pour la dernière fois six jours avant mon test, et il couvre :

• La configuration recommandée en un clic via OAuth par l’extension
• Un chemin de configuration manuel à l’aide d’un jeton API, pour les IDE que l’extension ne prend pas directement en charge
• Les chemins exacts des fichiers de configuration pour Mac, Linux et Windows
• Des exemples complets de configuration JSON
• Une invite de vérification étape par étape pour confirmer que la connexion a fonctionné
• Quels clients pris en charge détectent automatiquement la connexion versus lesquels nécessitent une entrée de configuration manuelle

Ce dernier point correspondait à quelque chose que j’ai rencontré directement pendant le test : Devin Desktop est détecté automatiquement, tandis qu’OpenAI Codex exige la méthode manuelle. L’article a bien cette distinction.

Verdict global sur le soutien

La première réponse de Kodee à une question technique difficile était exacte et spécifique, ce qui n’est pas quelque chose que tous les assistants de soutien IA réussissent. L’article de la base de connaissances qui l’appuie est actuel et détaillé une fois qu’on l’a trouvé, même si le nom commercial 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 chemin d’escalade vers un humain. Kodee m’a renvoyé vers lui-même deux fois avant d’honorer une demande directe pour parler à une personne, et même alors, « agent humain » signifie un examen asynchrone relayé par le même chat plutôt qu’un transfert en direct. Une fois qu’un humain l’a examiné, la réponse était meilleure que celle de Kodee, plus précise et avec deux étapes diagnostiques 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 à attendre un peu pour une réponse relayée plutôt que pour une conversation en direct.

Hostinger Connector Plans with Hostinger

Intégrez Hostinger aux applications et services que vous utilisez déjà pour automatiser des tâches, améliorer les flux de travail et gérer votre site Web plus efficacement.

Visitez Hostinger

Verdict final : Hostinger Connector vaut-il la peine d’être utilisé ?

Oui, pour les développeurs qui hébergent déjà chez Hostinger et veulent que les déploiements de routine soient gérés depuis l’éditeur. La configuration a pris quelques minutes, OAuth a éliminé 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 direct en environ une minute avec des logs à l’appui. Les propres réponses du soutien Kodee étaient suffisamment précises pour résoudre dès la première tentative un vrai problème technique.

La réserve, c’est 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 base avant de vérifier.

Il a aussi marqué un déploiement cassé comme « completed » alors que l’application était en réalité hors service, sans erreur d’exécution dans ses propres logs. Utilisez-le pour accélérer le travail sur des sites qui existent déjà, vérifiez tout ce qu’il fait sur une nouvelle cible, et contrôlez vous-même le site en direct après tout déploiement qui compte.

Hostinger

5.0

2,471 user reviews

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