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, retournez au tableau de bord pour inspecter un déploiement, et ouvrez d’autres outils quand le DNS, les logs ou les ressources serveur demandent de l’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 des ressources d’hébergement prises en charge sans quitter votre éditeur.

Ça semble pratique. Mais cela soulève 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 workflow depuis l’installation jusqu’au déploiement en production. J’ai aussi testé les redéploiements répétés, les enregistrements 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égrer Hostinger avec les apps et services que vous utilisez déjà pour automatiser des tâches, améliorer les workflows et gérer votre site web plus efficacement.

Visitez Hostinger

Avantages et inconvénients de Hostinger Connector

Répartition de la note

Voici comment j’ai noté Hostinger Connector dans les domaines qui comptent le plus pour un développeur qui décide s’il veut l’utiliser : le coût, l’éventail de fonctionnalités, l’usage au quotidien, la précision d’exécution des vraies tâches, et le support derrière quand quelque chose tourne mal. Chaque score reflète ce que j’ai réellement trouvé pendant les tests, pas la page marketing.

Plans et tarifs de Hostinger Connector

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

Cependant, « gratuit » a besoin de contexte. Connector gère des ressources Hostinger ; il ne les remplace pas. Vous devez toujours disposer d’un hébergement, cloud, VPS, domaine, e-mail ou autre service Hostinger éligible pour les tâches que vous voulez lui faire exécuter.

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

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

Info sur les tarifs : N’achetez pas un plan plus élevé uniquement pour accéder à Connector. Choisissez le plan selon le nombre de sites web et de web apps dont vous avez besoin, les ressources qu’ils exigent et le niveau de support que vous voulez. 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 éligibles. Il n’existe pas de politique de remboursement séparée pour Connector, car Connector ne comporte pas de frais autonomes.

Hostinger Connector Plans with Hostinger

Intégrer Hostinger avec les apps et services que vous utilisez déjà pour automatiser des tâches, améliorer les workflows et gérer votre site web plus efficacement.

Visitez Hostinger

Fonctionnalités

• Déploiement d’application Node.js
• Déploiement PHP et HTML
• Gestion de site web WordPress
• Workflows Website Builder et Horizons
• Déploiements connectés à GitHub
• Connexion et organisation des domaines
• Inspection et mises à jour DNS
• SSL et diagnostics du site web
• Gestion de base de données
• Configuration et administration VPS
• Déploiement de projet Docker
• Surveillance du CPU et de la mémoire
• Vérifications de la bande passante et du disque
• Redémarrages des services et des conteneurs
• Analyse de logiciels malveillants
• Restauration de sauvegarde
• Configuration de campagnes e-mail
• Inspection des déploiements et des builds

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 limite de débit renvoyées dans les en-têtes de réponse.

Ces limites sont généreuses pour une utilisation interactive, même si les workflows 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 bien l’hébergement, il fallait d’abord savoir ce qu’il faut pour le faire fonctionner.

Un outil conçu pour rester dans l’éditeur perd vite de son intérêt si la configuration exige d’éditer des fichiers de config, de générer des jetons API, ou de répéter des authentifications. Cette section couvre uniquement la configuration. Les tests pratiques des tâches arrivent juste après.

Installation de l’extension

J’ai installé Hostinger Connector depuis le 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 fonctionné du premier coup en moins de deux minutes.

Cette dernière ligne mérite une réserve. Cinq étoiles semblent solides, 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 la revue.

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 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 se trouve derrière.

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

Ce que l’installation n’a pas exigé :

• Une clé API
• Un jeton copié depuis hPanel
• L’édition 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 piège est une dépendance que Hostinger ne met pas vraiment en avant : l’extension a besoin d’un agent IA actif dans votre éditeur pour faire quoi que ce soit.

Avec 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 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 intitulé hostinger-mcp.

Après avoir cliqué sur Allow, je suis retourné dans VS Code avec l’affichage « Connected via OAuth ».

L’écran d’autorisation m’indiquait que le 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 permission par permission. 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é une partie de ce contrôle, c’est un panneau séparé dans l’extension qui liste chaque catégorie d’outils et permet de l’activer ou de la désactiver individuellement :

Cela fait 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 quelle part d’accès au compte confier à 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 changer votre mot de passe Hostinger ni 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 de permissions est large plutôt que granulaire. Les contrôles d’outils au niveau des catégories dans l’extension font plus pour limiter le risque réel que l’écran OAuth.

Éditeurs pris en charge

Hostinger liste la prise en charge des clients suivants, relevée depuis l’écran d’onboarding de l’extension :

J’ai utilisé VS Code avec GitHub Copilot comme environnement principal de test.

La configuration m’a montré que Connector est facile à atteindre. Elle ne m’a encore rien dit sur sa capacité réelle à faire le travail une fois connecté, ce qui est la question plus difficile que j’ai abordée ensuite.

2. Hostinger Connector en action

Installer et connecter une extension est la partie facile. Ce qui compte vraiment, c’est de savoir si elle fait correctement le vrai travail d’hébergement, donc j’ai construit une petite application Express.js appelée PulseWatch et j’ai soumis Connector au même chemin 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 un échec que j’avais provoqué volontairement.

PulseWatch était volontairement simple : un serveur Express, une page d’accueil, un script de démarrage package.json et un endpoint /api/health renvoyant du JSON. Cet endpoint de santé s’est révélé important plus tard.

Une plateforme d’hébergement peut signaler un build terminé alors que l’application échoue au démarrage. Un endpoint 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é par des prompts en lecture seule avant de laisser l’assistant s’approcher des changements actifs. S’il ne pouvait pas décrire mon compte avec précision, je n’avais aucune bonne raison 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 :

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

Mon compte contenait en réalité davantage que cela. hPanel montrait 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 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.

Pour être juste envers le Connector, quand j’ai contesté et signalé 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 une meilleure façon d’échouer que de s’obstiner, mais cela signifie que la première réponse à une question sur le compte ne doit pas être prise au pied de la lettre.

L’accès en lecture seule a fonctionné, mais la première réponse à toute question à l’échelle du compte était incomplète. Il s’est corrigé une fois contesté, ce qui compte, mais je n’aurais pas dû avoir à le contester.

Ce manque de visibilité sur le compte s’est révélé être un avant-goût d’un problème plus gros. Le vrai test de son importance est arrivé ensuite, quand j’ai demandé au Connector de trouver un site web qu’on ne lui avait jamais donné par son nom.

Hostinger Connector Plans with Hostinger

Intégrer Hostinger avec les apps et services que vous utilisez déjà pour automatiser des tâches, améliorer les workflows et gérer votre site web plus efficacement.

Visitez Hostinger

Recherche d’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 site web Node.js nouvellement créé sans que je donne 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 qui peut agir sur un compte actif, 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 racine : les deux IDs qu’il a utilisés étaient des IDs de ressource de domaine, pas des IDs de commande d’hébergement. Il n’a jamais confirmé la distinction avant d’appeler un outil de création de site actif avec eux.

Quand je lui ai demandé de s’expliquer, l’assistant a fini par donner un compte rendu exact : il avait un outil fonctionnel de liste des sites web disponible tout le temps, mais ne l’a jamais rappelé après avoir créé un nouveau site via hPanel, alors il a rempli le vide avec un domaine non vérifié au lieu de rafraîchir ses données.

Quand je lui ai demandé directement de relancer cet outil de liste et de vérifier s’il y avait un nouvel enregistrement, il a à la place appelé trois outils sans rapport de recherche de déploiement et a rapporté qu’« aucun nouveau site web n’apparaissait », une conclusion que les appels d’outils qu’il a réellement effectués ne pouvaient pas soutenir.

Rien de tout cela n’a créé de site web parasite dans mon compte. Les appels échoués n’ont rien laissé derrière eux. Mais le schéma mérite d’être nommé clairement. Face à des données incomplètes, l’assistant a comblé le vide avec une hypothèse plausible, a traité un signal faible comme une preuve forte, et a agi sur un compte actif avant que cette hypothèse ne soit vérifiée.

C’est la découverte la plus importante de cette section. Le Connector va deviner une cible et agir sur cette supposition au lieu de s’arrêter et de demander. Il a échoué de manière sûre ici, mais l’habitude de traiter un signal faible comme une preuve est ce qu’il faut surveiller dans votre propre compte.

Comme le Connector n’arrivait pas à localiser la cible tout seul, il ne me restait qu’une option : créer la cible moi-même et voir si cela changeait quelque chose.

Finalisation de la configuration dans hPanel

Puisque le Connector ne pouvait pas localiser de manière fiable la nouvelle cible tout seul, j’ai terminé la configuration initiale manuellement via hPanel pour voir ce que Hostinger prépare avant qu’un déploiement via Connector soit possible.

Le chemin était : Créer un nouveau site → application web Node.js → domaine temporaire → Hostinger a sélectionné automatiquement un centre de données au Royaume-Uni avec une latence estimée à 147ms → trois méthodes de déploiement au choix.

Ce troisième écran mérite d’être signalé à part. Hostinger propose « Build with Hostinger Connector » comme méthode de déploiement, juste à côté de l’import GitHub et de l’upload 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 de Connector elle-même, que j’avais déjà terminée. C’est un vrai manque dans l’onboarding. L’option présentée comme un chemin natif de Connector n’a en réalité rien provisionné.

Je suis revenu en arrière et j’ai choisi l’upload manuel des fichiers à la place. Hostinger a accepté mon archive de projet (11.46 KB, avec node_modules exclu), et l’écran des paramètres a montré une détection automatique correcte :

• Framework preset : 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 chemin manuel a fonctionné sans friction une fois que j’ai arrêté 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 production

Avec un vrai site confirmé en place, je suis retourné vers Connector et lui ai demandé d’inspecter ce domaine exact. 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 qu’il en existe déjà un.

Ensuite, j’ai testé la fonctionnalité que Hostinger met le plus en avant : faire un changement de code en local et le publier sans ouvrir hPanel.

J’ai demandé à l’assistant de changer une ligne du texte de la page d’accueil, de « Monitor Every Service. Catch Every Issue. » à « Monitor Every Service. Resolve Issues Faster. »

L’opération complète 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 le traitement.

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

Les logs 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 workflow que Hostinger promet. Modifier, vérifier localement, envoyer, 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 dit que le happy path fonctionne. Pour savoir ce que Connector fait réellement sous pression, j’ai cassé l’application volontairement.

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

Un outil ne mérite la confiance que lorsqu’il survit à un vrai échec, pas seulement à une démo propre. J’ai volontairement cassé l’application pour voir si le rapport d’état et les logs de Connector pouvaient réellement m’aider à diagnostiquer le problème.

Avant tout changement, l’assistant a sauvegardé package.json dans package.json.bak, une bonne habitude en soi.

Je lui ai ensuite demandé de modifier le script de démarrage de “start”: “node server.js” à “start”: “node missing-server.js”, un fichier qui n’existe pas.

L’exécution locale 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.

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

La récupération s’est faite sans problème. L’assistant a restauré package.json à partir de sa sauvegarde, a vérifié l’application localement, a redéployé, et a confirmé la correction en appelant directement l’endpoint /api/health en production plutôt qu’en faisant confiance uniquement au statut du déploiement.

Cet endpoint a renvoyé une réponse opérationnelle, qui était la seule preuve dans tout le test montrant réellement que l’application tournait.

C’est le deuxième constat majeur. Un statut terminé ne prouve pas qu’une application fonctionne, et les logs de Connector eux-mêmes ne vous le diront pas. La récupération elle-même a bien fonctionné une fois que je savais 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 où d’autre la confiance du Connector pouvait dépasser ses capacités réelles. Les variables d’environnement étaient le test suivant.

Tentative de configuration des variables d’environnement

J’ai demandé à l’assistant d’ajouter une variable d’environnement sans danger, de confirmer que le réglage existait comme 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 de faire le moindre changement de code ou de 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 n’en conclurais pas que Hostinger Connector ne prend en charge aucune variable d’environnement dans tout son ensemble d’outils, seulement qu’aucune action de ce type 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 :

• Lire des enregistrements de déploiement connus
• Modifier un fichier précis
• Exécuter des commandes locales
• Empaqueter un projet
• Déployer vers un site web connu
• Vérifier l’état du build
• Récupérer les logs disponibles
• Restaurer et redéployer une version connue comme bonne

Il était plus faible quand la tâche demandait une interprétation à travers des données de compte incomplètes :

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

Ce schéma est utile pour décider combien d’autonomie donner à l’assistant.

Utilisez des prompts larges pour les inspections à 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 :

utilisez :

Le deuxième prompt réduit la marge de supposition de l’assistant.

Verdict global sur la facilité d’utilisation

Obtenir Hostinger Connector opérationnel a été facile, sans la friction habituelle de configuration, et les contrôles granulaires 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 fait le travail : une modification de texte sur une seule ligne est passée de l’édition au live en environ une minute, avec des logs de build utiles à l’appui.

Le problème est apparu plus tôt dans le processus, pas plus tard. Face à une nouvelle cible qu’il ne pouvait pas trouver, le Connector a inventé un domaine et a agi dessus avant de vérifier. Il a aussi marqué un déploiement cassé comme « completed » alors que l’application était en panne, sans erreur runtime dans ses propres logs. Cela ne rend pas l’outil peu fiable pour les sites établis, mais cela veut dire que les nouveaux déploiements et l’état post-déploiement nécessitent un second regard avant d’avoir confiance.

Hostinger Connector Plans with Hostinger

Intégrer Hostinger avec les apps et services que vous utilisez déjà pour automatiser des tâches, améliorer les workflows et gérer votre site web plus efficacement.

Visitez Hostinger

Niveau de support

Hostinger organise son support autour du chat en direct et de l’auto-assistance plutôt que des appels téléphoniques, donc j’ai concentré mes tests là où la plupart des utilisateurs arriveront réellement : l’assistant IA intégré à hPanel, l’escalade humaine derrière, et la base de connaissances à laquelle un développeur se tournerait avant d’ouvrir un chat.

Canaux de support

Étant donné que le live chat est le canal que Hostinger recommande aux développeurs pour tout ce qui est urgent, et celui qui est le plus susceptible d’être utilisé en plein débogage d’un déploiement, je l’ai testé directement plutôt que de déposer un ticket par e-mail.

Live chat : Kodee et le passage à un humain

J’ai ouvert le live chat via « Ask AI » dans hPanel et j’ai demandé à Kodee une question avec une réponse réelle à se tromper : si un statut de build terminé sur un déploiement Node.js garantit que l’application est vraiment en cours d’exécution, 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 crash au runtime, vérifiez les logs de runtime : dans hPanel allez à Websites → Dashboard → Deployments pour les logs 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é dans laquelle mon test de récupération après échec s’est retrouvé plus tôt dans cette revue. Kodee a nommé un vrai fichier de logs, le bon dossier, et a tracé la bonne frontière entre succès du build et santé au runtime.

Cependant, je voulais aussi voir si je pouvais accéder à un vrai agent humain, alors j’ai dit à Kodee que j’aimerais confirmer cela directement avec un ingénieur support.

Mais obtenir un humain au bout de la ligne a été plus dur que prévu. J’ai demandé directement un agent en direct et j’ai été redirigé vers Kodee deux fois, à chaque fois présenté comme 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 logs runtime ici même, ce qui est généralement le moyen le plus rapide de trouver le problème.

Avant de mettre en attente 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 « connectez-moi à un humain ». Kodee a expliqué le modèle réel très clairement :

J’ai partagé votre demande avec un spécialiste de notre équipe qui examinera personnellement notre chat 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 le transcript en arrière-plan et Kodee relaie la réponse une fois qu’elle arrive. Cette distinction compte pour les lecteurs qui décident s’ils doivent escalader, car « agent humain » ici ne signifie pas qu’une nouvelle personne rejoint la fenêtre de chat comme ce serait le cas sur la plupart des systèmes de live chat.

J’ai poussé la même ligne technique plus loin en attendant, en demandant à Kodee de confirmer le chemin exact du log et si stderr.log est toujours renseigné. Il a donné une bonne réponse tout seul, notant correctement que le log peut être vide si l’application n’a jamais vraiment démarré ou si elle a écrit son erreur ailleurs.

L’examen du spécialiste est arrivé en environ 3 minutes, attribué 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 le bon emplacement. Il n’est pas toujours généré ou renseigné. Vous n’y verrez des entrées que lorsque l’application écrit sur stderr, comme pour des exceptions non capturées ou des 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 aussi ajouté deux vérifications de secours que Kodee n’avait pas mentionnées : vérifier stdout.log pour 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é.

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 de trouver le bon article a été de chercher directement « Hostinger Connector », ce qui a renvoyé cinq résultats, pour 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 de Connector s’intitule « How to Set Up Web Hosting MCP on Local IDEs », classé sous Features → General Information.

La recherche avec le nom marketing réel du produit l’a trouvé, mais un lecteur parcourant les catégories ou cherchant « MCP » sans connaître le branding de Hostinger pourrait le manquer tout aussi facilement, et l’écart entre le nom marketing et le nom de la documentation mérite d’être connu avant d’aller le 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 :

• La configuration recommandée en un clic via OAuth avec l’extension
• Un chemin de configuration manuel utilisant 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 JSON complets de configuration
• Un prompt 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 saisie manuelle de configuration

Ce dernier point correspondait à quelque chose que j’ai rencontré directement pendant le test : Devin Desktop est détecté automatiquement, tandis que OpenAI Codex nécessite la méthode manuelle. L’article se trompe pas sur cette distinction.

Verdict global sur le support

La première réponse de Kodee à une question technique difficile était exacte et précise, ce que tous les assistants de support IA n’arrivent pas à faire. L’article de la base de connaissances qui la soutient est à jour et détaillé une fois qu’on le trouve, 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 humaine. Kodee m’a renvoyé vers lui-même deux fois avant de respecter une demande directe de parler à une personne, et même alors, « agent humain » signifie un examen asynchrone relayé via le même chat plutôt qu’un transfert en direct. Une fois qu’un humain a regardé, 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 à lui seul vous donnera une réponse exacte rapidement. Si vous voulez vraiment qu’une personne vérifie la réponse, attendez-vous à devoir demander plus d’une fois, et à attendre un court délai pour une réponse relayée plutôt qu’une conversation en direct.

Hostinger Connector Plans with Hostinger

Intégrer Hostinger avec les apps et services que vous utilisez déjà pour automatiser des tâches, améliorer les workflows et gérer votre site web plus efficacement.

Visitez Hostinger

Verdict final : Hostinger Connector vaut-il le coup ?

Oui, pour les développeurs qui hébergent déjà chez Hostinger et veulent gérer les déploiements de routine depuis l’éditeur. La configuration a pris quelques minutes, l’OAuth a évité toute clé API, et une fois qu’un site web existait avec un domaine connu, le Connector a livré une mise à jour en production en environ une minute avec des logs à l’appui. Les réponses du support de Kodee étaient assez bonnes pour résoudre une vraie question technique dès la première fois.

La réserve 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 dessus avant de vérifier.

Il a aussi marqué un déploiement cassé comme « completed » alors que l’application était en panne, sans erreur runtime 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 le site en direct vous-même après tout déploiement important.

Hostinger

5.0

2,471 user reviews

16 MAD /mo

Prix de départ

Visitez Hostinger

Rating based on expert review

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