Comment mettre en ligne un site créé avec une IA : hébergeur, VPS et nom de domaine

C’est quoi un hébergeur, et pourquoi GitHub ne suffit pas ?

Votre formulaire a d’abord besoin d’un ordinateur conçu pour rester allumé et joignable en permanence. On appelle serveur une machine de ce genre, dont tout le travail consiste à répondre aux navigateurs qui lui demandent une page, et hébergeur l’entreprise qui en possède des milliers et vous en loue l’usage. Vous pourriez bien sûr laisser tourner un PC dans le salon en espérant que la box tienne jusqu’au matin, mais vos visiteurs n’ont pas à dépendre de la personne qui passe l’aspirateur près de la multiprise.

On déploie une version du code quand on la copie sur ce serveur et qu’on l’y lance. Votre code existe alors en trois endroits, qui n’ont pas le même rôle.

GitHub, lui, conserve vos fichiers et leur historique sans faire tourner le programme. Il sait publier des pages fixes, et si votre projet se résume à une plaquette, sans compte ni formulaire à enregistrer, cela suffit : vous pouvez refermer cet article et profiter de votre week-end. Un formulaire qui crée des comptes demande autre chose, c’est-à-dire un programme qui reçoive chaque inscription et la range quelque part. C’est ce cas que je traite ici, et il oblige à choisir où ce programme va tourner.

VPS ou Vercel : pourquoi je préfère le VPS ?

Deux grandes familles d’hébergement se présentent pour une application comme la vôtre (il en existe d’intermédiaires, que je laisse de côté pour ne pas transformer ce guide en catalogue). La première réunit des plateformes comme Vercel, qui font tourner votre code sur des serveurs que vous ne verrez jamais. La seconde consiste à louer une machine, dont la forme la plus abordable est le VPS, pour virtual private server, ou serveur privé virtuel : l’hébergeur découpe un gros ordinateur en machines virtuelles isolées, et la vôtre se comporte comme un ordinateur complet, sur lequel vous installez ce que vous voulez.

Je préfère le VPS, et j’ai pris le mien chez Hostinger. Le site que vous êtes en train de lire y tourne, sur une machine installée à Paris où cohabitent le site public, sa copie d’essai fermée par un mot de passe et les tâches planifiées de nos agents. Cette cohabitation est la raison de mon choix, car une application ne reste jamais longtemps seule : votre formulaire aura besoin d’une base de données pour ranger les comptes, bientôt d’une tâche planifiée qui trie les inscriptions pendant la nuit, puis d’un site d’essai pour vos modifications. Sur un VPS, tout cela loge dans la même machine, pour un forfait fixe, et je sais à tout moment où se trouvent le programme et les données. Ce forfait achète une quantité connue de calcul, de mémoire, de disque et de transfert. Si le site dépasse sa part de transfert ou de calcul, Hostinger annonce un ralentissement, pas une coupure.

Vercel répond à un autre besoin, celui de ne jamais s’occuper du serveur, et il le fait bien. Chaque envoi sur GitHub est déployé sans intervention, chaque modification proposée reçoit son adresse d’essai, le site est servi depuis des serveurs répartis dans le monde, et la plateforme sait elle aussi lancer des tâches planifiées. La base de données se crée depuis son tableau de bord, chez un partenaire dont la consommation rejoint la même facture. L’offre gratuite est réservée aux projets personnels non commerciaux, et l’offre Pro coûte 20 dollars hors taxes par mois, qui incluent 20 dollars de consommation ; ce qui dépasse est facturé à l’usage.

La différence tient donc moins à ce que chacun sait faire qu’à celui qui s’en occupe. Sur mon VPS, Hostinger entretient le matériel et le réseau, tandis que le système d’exploitation, sa sécurité et ses réglages me reviennent, mises à jour et surveillance comprises. J’ai mesuré ce que cela veut dire le jour où la préparation d’une nouvelle version a épuisé la mémoire de la machine et fait tomber avec elle les sites qui y tournaient. Le matériel de Hostinger, lui, fonctionnait parfaitement ; le reste était mon affaire. Votre agent IA peut se charger de l’essentiel de ce travail, sans être pour autant une équipe d’astreinte : si le site tombe un dimanche, c’est vous qui le remarquerez, ou vos clients, ce qui est une façon assez désagréable de l’apprendre. Un VPS n’est par nature ni plus rapide, ni plus sûr, ni même moins cher une fois compté le temps que vous y passez.

Si votre priorité est de publier vite une application sans jamais entretenir de machine, Vercel est un choix raisonnable. Si vous voulez réunir vos services au même endroit, choisir vos logiciels et lire une facture qui ne dépend pas du nombre de visiteurs, prenez un VPS, en sachant que vous signez aussi pour son administration. La suite de ce guide sert à ce que cette dernière phrase ne reste pas une formule.

Où sont rangés les comptes de vos utilisateurs ?

Sur cette machine, le déploiement installe le code du formulaire, et ce code reste le même, que vous ayez zéro ou trois cents inscrits. Les inscriptions sont en effet des données : elles naissent pendant que l’application tourne et ne figurent dans aucun fichier du projet. L’application les confie à une base de données, un logiciel distinct installé à côté d’elle sur le VPS. Lorsque quelqu’un s’inscrit, elle lui transmet les informations de son compte, et lorsqu’il revient se connecter, elle interroge la même base pour le retrouver.

Cette séparation a une conséquence : GitHub ne contient aucun de vos comptes clients, et un serveur perdu emporte donc les inscriptions même quand le code est intact ailleurs. Elle appelle aussi une précaution. Comme la base obéit à quiconque lui présente le bon mot de passe, elle ne doit recevoir d’ordres que de l’application, jamais d’un visiteur, et l’on s’en assure avec le pare-feu, le filtre qui décide quelles portes de la machine répondent au monde extérieur.

Hostinger permet de régler ce pare-feu depuis l’interface de votre compte. Demandez à votre agent de vérifier que la porte de la base reste fermée, et de ranger le mot de passe de cette base dans un fichier de réglages posé sur le serveur, à l’écart du dépôt GitHub.

Je suis connecté au compte de mon hébergeur. Ouvre la page de gestion de mon VPS et trouve son pare-feu, dans la rubrique consacrée à la sécurité. Ne modifie, n’active et ne supprime rien : cette consigne sert seulement à contrôler.

Liste les règles en place et dis-moi si un pare-feu est bien appliqué à ce serveur. Je veux que seuls les ports 22 (SSH), 80 (HTTP) et 443 (HTTPS) soient ouverts. Signale-moi toute autre ouverture, en particulier celle d’une base de données (5432 pour PostgreSQL, 3306 pour MySQL, 27017 pour MongoDB). Si une règle manque ou est en trop, indique-moi où cliquer pour la corriger moi-même, sans jamais retirer la règle SSH avant que les autres soient en place.

Nom de domaine, DNS, adresse IP : comment vos visiteurs trouvent-ils le serveur ?

L’application tourne et ses données sont derrière elle. Pour l’instant, on ne la joint que par l’adresse IP du serveur, une suite de chiffres comme 203.0.113.10 que l’hébergeur attribue à la machine. Cette adresse suffit techniquement, mais personne ne la retiendra, et elle changera sans doute le jour où vous changerez de serveur. Le nom de domaine, ici monsite.fr, est l’adresse lisible que vous louez pour la remplacer aux yeux du public.

Louer est le mot juste, puisque vous réservez ce nom pour une durée limitée, d’un à dix ans pour un .fr, avant de le renouveler. Si vous oubliez, le site et les adresses e-mail qui en dépendent cessent de fonctionner. Cette réservation se fait auprès d’un bureau d’enregistrement, qui peut être votre hébergeur ou une tout autre entreprise, car le nom et la machine font l’objet de deux contrats indépendants.

Ce qui relie l’un à l’autre est le DNS, l’annuaire d’Internet, que chaque navigateur consulte avant de s’adresser au serveur.

Le nom de domaine ne fait donc rien tourner : si le serveur est éteint, l’adresse la mieux choisie du monde conduit à une page d’erreur. Pour diriger le vôtre vers le VPS, vous modifiez sa zone DNS, un tableau de quelques lignes tenu par le prestataire qui gère votre nom. Deux lignes de type A suffisent, le type qui associe un nom à une adresse IP : l’une pour @, qui désigne le domaine seul, l’autre pour www.

Ce qui change d’un lecteur à l’autre, c’est l’état de la zone avant d’y toucher.

Un changement de DNS peut mettre jusqu’à vingt-quatre heures à être connu partout, et autant à être corrigé. Ne dirigez donc monsite.fr vers le VPS qu’une fois l’application installée et essayée dessus.

Je veux diriger mon nom de domaine vers mon VPS. Demande-moi d’abord le nom de domaine et l’adresse IP du VPS, sans les deviner. Je suis déjà connecté au compte du prestataire qui gère ce nom.

Ouvre la zone DNS du domaine et recopie-moi toutes ses lignes telles qu’elles sont, pour que j’en garde une copie. Classe-les ensuite : celles qui concernent le site (types A, AAAA et CNAME pour @ et www) et celles qui concernent les e-mails ou autre chose (MX, TXT et le reste), auxquelles tu ne touches pas.

Propose-moi les changements nécessaires pour que @ et www pointent vers l’adresse IP du VPS par deux lignes de type A, puis attends que je réponde « oui ». Si une ligne doit être supprimée, dis-moi laquelle et pourquoi : je la supprimerai moi-même. Une fois les changements enregistrés, relis la zone et montre-moi son état final.

Comment activer HTTPS sur un VPS ?

Le visiteur arrive désormais sur le serveur par son nom. Mes schémas le faisaient entrer directement dans l’application, alors qu’en pratique on installe devant elle un reverse proxy, un logiciel d’accueil comme Nginx ou Caddy, qui reçoit les demandes et les lui transmet. C’est lui qui assure le HTTPS, reconnaissable au https:// qui ouvre l’adresse : les échanges entre le navigateur et votre serveur sont alors chiffrés, à commencer par le mot de passe saisi dans votre formulaire.

Le reverse proxy présente pour cela un certificat, un document qui prouve au navigateur que le serveur répond bien pour monsite.fr. Let’s Encrypt le délivre gratuitement, pour une durée limitée et, en pratique, une fois le nom dirigé vers le VPS. Son renouvellement automatique fait partie de ce qu’il faut installer, là où une plateforme s’en charge sans vous en parler, ce qui est exactement ce qu’on lui demande.

Comment mettre le site à jour sans casser la production ?

Jusqu’ici, nous avons mis en ligne une version. Le lendemain, vous voudrez en publier une deuxième, et c’est généralement ce jour-là que l’on découvre l’intérêt d’avoir deux sites plutôt qu’un. Le reverse proxy permet en effet de loger sur la même machine la production, le site public, et une préproduction, sa copie réservée aux essais, à une adresse comme essai.monsite.fr qui reçoit sa propre ligne DNS, sa propre base remplie de comptes fictifs et un mot de passe à l’entrée. J’ai expliqué dans le guide sur GitHub pourquoi l’on essaie chaque modification avant ses clients, et voici le trajet qu’elle suit sur un VPS.

La première étape porte le nom de build lorsque le projet en demande un : le serveur récupère sur GitHub la version que vous avez validée, installe ce dont elle a besoin et la transforme en programme prêt à tourner. Faites écrire ce trajet par votre agent dans un script, un fichier qui rejoue ces étapes à l’identique, en lui demandant de conserver la version précédente pour pouvoir y revenir aussitôt et de ne rien publier en production qui ne soit passé par la préproduction. Vercel fournit tout cela d’office. Sur un VPS, vous le faites construire une fois, avec l’avantage de pouvoir en lire chaque étape, et rien ne vous oblige à l’avoir le premier jour, même si je vous déconseille d’attendre le premier incident pour le demander.

Que sauvegarde vraiment votre hébergeur ?

Remettre l’ancienne version en service ne vous rend aucune inscription. Or un disque peut lâcher, et un agent zélé peut vider la liste des comptes en croyant faire le ménage. Que retrouveriez-vous demain matin si la base disparaissait ce soir ? Mieux vaut connaître la réponse avant le premier vrai client.

Hostinger sauvegarde le VPS entier chaque semaine, et chaque jour si vous prenez l’option payante. C’est une protection réelle contre la panne complète, avec deux limites. Une sauvegarde hebdomadaire peut vous coûter jusqu’à sept jours d’inscriptions. La restauration, elle, remplace tout le contenu du serveur par son état d’alors, sans annulation possible, ce qui en fait un mauvais outil pour récupérer trois comptes effacés par erreur. D’où l’intérêt d’une seconde sauvegarde, limitée aux données et rangée ailleurs que sur le serveur.

L’export de chaque nuit, un simple fichier, se confie à une tâche planifiée. Encore faut-il recharger l’un de ces fichiers dans une base d’essai et vérifier que les comptes s’y trouvent : tant que vous n’avez jamais restauré une sauvegarde, vous ignorez si elle fonctionne.

Combien coûtent un VPS et un nom de domaine ?

Tout cela a un prix, et la facture se lit moins facilement que la page de vente. Prenons le VPS d’entrée de gamme de Hostinger, le KVM 1, avec un cœur de processeur virtuel, 4 Go de mémoire, 50 Go de disque et 4 To de transfert par mois. Il est affiché à 5,49 € par mois, mais ce prix est une division : les formules se paient d’avance, et celle-ci correspond à vingt-quatre mois, soit 131,76 € à régler le premier jour. Au terme de ces deux ans, le renouvellement est annoncé à 11,99 € par mois, soit 287,76 € pour la même durée.

Le nom de domaine suit la même logique. Un .fr est proposé à 0,01 € la première année, puis à 10,99 € par an, et c’est le second chiffre qui compte, puisque vous le paierez tant que le site existera. La page met d’ailleurs en avant une réservation de trois ans, quand mon exemple n’en compte qu’un. Quant au domaine offert un an avec le VPS, il se limite à quelques extensions comme .cloud ou .tech, dont ni le .fr ni le .com ne font partie. Tous ces prix s’entendent hors TVA.

Rapporté au mois, cet exemple revient à environ 6 € hors taxes et hors options pendant les deux premières années, puis à environ 13 € au tarif de renouvellement affiché aujourd’hui. Ne rapprochez pas trop vite ces montants des 20 dollars mensuels de Vercel, qui paient un service géré et non une machine réglée deux ans d’avance. Les prix de Hostinger ont été relevés le 9 octobre 2026 sur ses pages publiques, sans ouvrir de panier : lisez sur le vôtre le total à payer, la durée couverte et le prix de renouvellement avant de valider. La page annonce aussi un remboursement garanti pendant trente jours, sans rien promettre au-delà pour les mois déjà payés.

Je suis sur la page de commande de mon hébergeur, juste avant le paiement. Ne clique sur aucun bouton de paiement et ne saisis aucune information : je paierai moi-même.

Lis la page et fais-moi un tableau avec, pour chaque ligne de la commande : le produit, la durée couverte, le prix payé aujourd’hui, le prix de renouvellement et la date à laquelle il s’appliquera. Ajoute le total hors taxes, la TVA et le total à payer.

Signale-moi toute option ajoutée ou cochée sans que je l’aie demandée, et tout renouvellement automatique. Si une information manque sur la page, dis-le au lieu de la déduire.

Quelle consigne donner à votre agent pour la mise en ligne ?

Toutes ces étapes passent par des commandes, que vous n’aurez pas à taper si votre agent dispose d’un accès au serveur. On entre dans un VPS à distance, par une connexion appelée SSH que protège une clé, un fichier secret rangé sur votre ordinateur. Un agent de programmation comme Claude Code ou Codex, installé sur ce même ordinateur, peut emprunter cette connexion pour agir à votre place, alors qu’une IA de conversation ne peut que vous dicter les commandes à saisir dans le terminal que Hostinger propose depuis le navigateur.

Cet accès donne tous les droits sur une machine où une erreur peut effacer des comptes, ce qui mérite trois précautions. La clé ne se colle jamais dans une conversation ni dans le dépôt. L’agent propose, et vous validez vous-même toute commande qui supprime des données ou modifie les accès. Enfin, vous lui faites décrire son plan avant de le laisser toucher au serveur ou au DNS, ce que demande la consigne suivante.

Avant toute action, décris mon application : son langage, la façon de la lancer, les services dont elle a besoin (base de données, tâches planifiées, envoi d’e-mails) et les données qu’elle enregistre. Dis-moi si la plus petite formule de VPS lui suffit.

Propose ensuite un plan de mise en ligne sur un VPS : mises à jour du système, pare-feu, base de données inaccessible depuis Internet, reverse proxy avec HTTPS et renouvellement automatique du certificat, préproduction protégée par un mot de passe avec sa propre base, script de déploiement qui conserve la version précédente, alerte qui me prévient quand le site ne répond plus.

Prévois une sauvegarde quotidienne de la base vers un stockage extérieur au serveur, et montre-moi une restauration réussie dans une base d’essai. Les mots de passe et les clés d’API restent dans un fichier sur le serveur, hors du dépôt. Ma clé SSH ne quitte pas mon ordinateur.

N’exécute rien sur le serveur et ne modifie aucune ligne du DNS sans mon accord. Pour le DNS, indique-moi exactement quelles lignes ajouter ou changer, et lesquelles laisser intactes.

Commencez par la préproduction. Tant que la ligne DNS de monsite.fr ne pointe pas vers le VPS, vos clients ne risquent pas d’y arriver par leur adresse habituelle, et vous pouvez recommencer autant de fois qu’il le faut. Le serveur répond toutefois déjà à qui connaît son adresse IP ou celle de la préproduction, d’où le mot de passe à l’entrée de cette dernière. Demandez enfin à l’agent de consigner le plan retenu dans un fichier de consignes à la racine du dépôt, pour que le prochain agent sache comment ce serveur est construit.

Comment vérifier que votre site est vraiment en ligne ?

Quand votre agent vous annonce que tout est déployé, il vous décrit ce qu’il a exécuté, et il vous reste à constater ce qui fonctionne. Avant d’envoyer l’adresse à qui que ce soit, faites ces six essais, dont aucun ne demande de lire du code.

1. Ouvrez https://monsite.fr depuis un téléphone en 4G, hors de votre Wi-Fi : la page s’affiche sans avertissement de sécurité.
2. Créez un compte avec une adresse à vous, puis connectez-vous : l’inscription et la connexion aboutissent.
3. Demandez à l’agent de redémarrer le serveur : l’application repart seule, et votre compte est toujours là.
4. Faites-lui tenter une connexion à la base depuis l’extérieur du serveur : elle est refusée.
5. Ouvrez essai.monsite.fr : un mot de passe vous est demandé avant tout affichage.
6. Faites recharger la sauvegarde de la nuit dans une base d’essai : votre compte s’y trouve.

Si les six passent, votre site est en ligne. Vous n’êtes pas devenu administrateur système pour autant, mais vous savez quoi demander à votre agent, et surtout quoi vérifier derrière lui.