Ça se passe souvent comme ça. Quelqu’un au marketing passe une soirée avec Claude ou ChatGPT et construit un petit outil : une page qui suit les salons de l’année, avec le budget et les contacts. Ça marche. C’est même joli. Le lendemain matin, message dans le canal de l’équipe :
Léa : J’ai créé un super outil pour suivre nos salons, tu veux voir ?
Marc : Oui, à fond !
Léa : Regarde :
http://localhost:3000
Et rien ne s’ouvre. Ni sur l’ordinateur du collègue, ni sur un téléphone, nulle part. L’outil existe, mais pour une seule personne.
Cet article explique pourquoi, avec des mots simples, et ce qu’il faut pour passer de « ça marche sur mon ordi » à une adresse que tout le monde peut ouvrir.
Ce que veut dire « localhost »
localhost, c’est le nom que chaque ordinateur se donne à lui-même. Quand votre IA dit « votre site tourne sur localhost:3000 », elle veut dire : un petit programme sur cet ordinateur affiche le site, et seul cet ordinateur peut le demander. Le nombre après les deux-points (3000, 5173, 8080) n’est qu’un numéro de porte sur la même machine.
Alors quand vous envoyez localhost:3000 à un collègue, son navigateur demande le site à son propre ordinateur. Qui n’en a jamais entendu parler. D’où le fameux « Ce site est inaccessible ».
Ce n’est pas un bug, et vous n’avez rien raté. Les outils d’IA construisent sur votre ordinateur parce que c’est le plus rapide pour essayer. Mettre le résultat en ligne, c’est un autre travail, et c’est celui que personne n’explique.
Pourquoi l’IA ne l’a pas simplement mis en ligne
La plupart des assistants savent écrire un site entier en quelques minutes. Ils s’arrêtent en général avant de le publier, et pour de bonnes raisons :
- Un site en ligne doit habiter quelque part. Sur un serveur allumé jour et nuit. Votre IA n’en a pas pour vous.
- Il lui faut une adresse. Quelque chose comme
salons.votre-entreprise.be, donc un domaine, ses réglages et un certificat de sécurité (le cadenas). - Il doit continuer à tourner. Quand vous fermez votre portable,
localhostdisparaît. Un site en ligne, non. - Quelqu’un doit décider. Publier, c’est visible par tout le monde. Laisser une IA mettre des choses en ligne toute seule, sans que personne ne regarde, ce n’est pas ce que veulent la plupart des entreprises.
Chacun de ces points se règle. Le problème, c’est que mis bout à bout, ils transforment une soirée amusante en projet technique.
Ce qu’il faut pour être en ligne « pour de vrai »
Voici la liste, dans l’ordre où vous allez la rencontrer.
1. Une vraie adresse
Il vous faut une adresse qui marche depuis n’importe quel ordinateur et n’importe quel téléphone. Deux choix courants :
| Option | Ressemble à | Bien pour |
|---|---|---|
| Une adresse gratuite chez un hébergeur | outil-salons.un-hebergeur.app |
Essayer, partager avec quelques collègues |
| Le domaine de votre entreprise | salons.votre-entreprise.be |
Tout ce que voient vos clients, candidats ou partenaires |
Un sous-domaine de votre entreprise inspire confiance et garde le lien stable pendant des années. Pour le mettre en place, on ajoute un ou deux enregistrements là où votre domaine est géré (souvent l’équipe informatique ou l’agence qui a fait le site principal). Quelques minutes, une fois qu’on sait lesquels.
2. Un certificat de sécurité
Les navigateurs avertissent les visiteurs quand un site n’a pas le cadenas (https). Le certificat doit être créé, puis renouvelé régulièrement. Un bon hébergement le fait pour vous, sans bruit. Si vous devez y penser, c’est que quelque chose ne va pas.
3. Des formulaires qui arrivent chez quelqu’un
La plupart des outils utiles ont un formulaire : une demande de contact, une candidature, une liste d’attente. Sur votre ordinateur, l’IA a peut-être rangé les envois dans un fichier, ou nulle part. En ligne, chaque envoi doit :
- être gardé en lieu sûr,
- prévenir la bonne personne (un e-mail à Julie, aux RH),
- et souvent arriver dans un outil que l’équipe utilise déjà : un CRM, un outil de recrutement, un tableur.
Les formulaires attirent aussi les robots. Sans protection, un formulaire public se remplit de spam en quelques jours. Des limites par expéditeur et un piège caché pour les robots règlent l’essentiel.
4. Des textes que l’équipe peut changer
Le lendemain du lancement, quelqu’un voudra corriger une faute, changer un prix ou ajouter une offre d’emploi. Si chaque modification oblige à rouvrir la conversation avec l’IA, l’outil va doucement se périmer. Une bonne installation donne à l’équipe un éditeur simple pour les textes et les images, avec un bouton clair pour mettre le site à jour quand elle est prête.
5. Des données qui restent
Si votre outil garde des informations (les salons, les contacts, les réservations), elles doivent vivre dans une vraie base de données, sauvegardée, séparée entre les tests et l’usage réel. Une liste gardée dans le navigateur de la personne qui a construit l’outil disparaît le jour où elle vide son historique.
6. Quelqu’un qui valide
Celui-là, on l’oublie facilement. Quand l’IA modifie le site, qui vérifie avant la mise en ligne ? Le bon réflexe :
- l’IA crée un aperçu : une copie privée avec la modification, à sa propre adresse ;
- une personne le regarde, sur ordinateur et sur téléphone ;
- cette personne valide, et c’est seulement là que ça part en ligne ;
- si quelque chose cloche quand même, la version d’avant revient en un clic.
C’est comme ça qu’on garde la vitesse de l’IA sans découvrir un matin une page carrières cassée.
7. Savoir que ça marche
Enfin : est-ce que des gens viennent ? Les formulaires arrivent-ils ? Quelque chose est-il cassé ? Un simple compte des visiteurs, et un moyen de voir les erreurs, suffisent pour la plupart des petits outils.
Les façons habituelles de s’en sortir
Il y a trois chemins classiques, chacun avec ses compromis.
Demander à un développeur. Ça marche, si vous en avez un sous la main. Ça veut aussi dire une file d’attente, et votre petit outil passe après le produit principal.
Assembler des services. Un hébergeur pour les pages, un service de formulaires, un de base de données, un de paiement, un registraire de domaine. Chacun est très bien. Ensemble, c’est cinq comptes, cinq factures, et des réglages que votre IA doit faire sans rien casser.
Utiliser une plateforme faite pour ça. Un seul endroit qui héberge ce que votre IA construit et fournit les briques (formulaires, données, comptes, domaines, validation) déjà branchées. C’est exactement le trou que Leaf vient combler.
Comment Leaf s’en occupe
Leaf se branche sur l’IA que vous utilisez déjà (Claude, ChatGPT, Mistral, Cursor et d’autres). Vous décrivez ce qu’il vous faut avec vos mots ; l’IA le construit directement sur Leaf, pas sur votre ordinateur. Il n’y a donc jamais de lien localhost à envoyer :
- chaque modification devient un aperçu privé avec sa propre adresse, à partager avec l’équipe ;
- une personne valide avant toute mise en ligne (c’est le réglage par défaut, pour chaque site) ;
- le site vit sur votre domaine, certificat compris ;
- les formulaires sont gardés, filtrés contre le spam, envoyés par e-mail, et peuvent arriver dans votre CRM ou votre outil RH ;
- votre équipe modifie textes et images dans un éditeur fait pour le site, puis clique sur « Mettre à jour le site » ;
- chaque version est gardée : revenir en arrière, c’est un clic.
Votre IA vérifie aussi son travail avant de vous le montrer : elle prend des captures sur téléphone et sur ordinateur, envoie les formulaires en mode test et lit les erreurs.
En résumé
localhost:3000, c’est l’adresse d’un brouillon sur un seul ordinateur. Pour en faire un vrai lien, il faut une adresse, un cadenas, des formulaires qui arrivent chez quelqu’un, des textes que l’équipe peut changer, des données qui restent, et une personne qui valide ce qui part en ligne. Rien de tout ça n’est difficile seul ; ensemble, c’est beaucoup pour un projet du soir.
La bonne nouvelle : le plus dur, avoir l’idée et la construire, c’est fait. Le reste peut être pris en charge pour vous.
Also in English: localhost:3000 is not a link