Notion · Pratique et outillage
Déploiement et localhost
Localhost, c’est votre ordinateur quand il fait tourner l’outil pour vous seul. Déployer, c’est le mettre en ligne pour que d’autres l’utilisent. Entre les deux, on teste.
Comment ça marche
Un outil se construit et se teste sur l’ordinateur de celui qui le fait : il tourne en localhost, visible de lui seul, avec des données de test. Quand il marche, il faut le mettre à disposition : c’est le déploiement. L’outil est installé sur un serveur accessible aux utilisateurs, avec une adresse, une sécurité, de vraies données. Entre les deux, souvent, un environnement de test où quelques personnes l’essaient avant tout le monde.
Le déploiement ajoute ce que le localhost n’avait pas besoin d’avoir : le HTTPS pour chiffrer, l’authentification pour limiter l’accès, les secrets rangés hors du code, la sauvegarde des données, un journal, et un moyen de mettre à jour sans tout casser. Pour un outil construit avec un agent, c’est l’étape qui sépare le prototype personnel de l’outil d’équipe. Elle n’est pas compliquée ; elle doit juste être faite, et pas sautée.
Un exemple concret
- Localhost : le directeur commercial a construit avec un agent un tableau de bord qui lit les exports du CRM. Il tourne sur son portable, et il est le seul à le voir. Deux semaines d’usage, trois corrections.
- Décision : l’équipe de huit personnes le veut. Les données sont internes, pas sensibles. Un hébergeur de sites convient.
- Préparation, avec l’agent : l’outil est mis sous Git ; les identifiants du CRM passent en secrets d’hébergement ; une authentification par identifiant d’entreprise est ajoutée ; les exports sont stockés avec sauvegarde quotidienne.
- Test : déployé sur une adresse de test, essayé par deux commerciaux pendant une semaine. Un bug sur les dates corrigé.
- Production : déployé sur l’adresse définitive, en HTTPS. Mise à jour en une commande. Un responsable nommé : le directeur commercial, avec le responsable informatique en appui.
Le passage du portable à l’équipe a pris trois jours. Sans ces trois jours, l’outil aurait circulé par copie du fichier, avec les identifiants du CRM dedans.
Ce que ça change pour une équipe
- Les outils personnels deviennent des outils d’équipe. Ce qui servait à une personne sert à tous, proprement.
- Les règles de sécurité s’appliquent. HTTPS, authentification, secrets, sauvegarde : le déploiement est le moment où elles entrent en jeu.
- Les mises à jour sont simples. Un outil déployé avec méthode se met à jour en une commande, sans peur.
- Il y a un responsable. Déployer, c’est aussi décider qui s’en occupe.
Les limites et les erreurs fréquentes
- Partager le prototype localhost par copie. Le fichier circule avec ses identifiants, sans mise à jour possible. Le déploiement existe pour ça.
- Déployer sans authentification. Un outil interne accessible à qui connaît l’adresse. L’authentification est dans la liste, dès le départ.
- Les secrets dans le code déployé. Ils finissent sur le serveur et dans Git. Variables d’environnement ou coffre de l’hébergeur.
- Pas de sauvegarde ni de surveillance. L’outil tombe, les données sont perdues, personne ne le sait. Le minimum : une sauvegarde et une alerte.
Pour aller plus loin
Un outil se développe et se teste en local, puis se déploie sur un hébergeur (Cloudflare, Vercel, un serveur). Le déploiement ajoute le nom de domaine, le HTTPS, les secrets, la sauvegarde et la surveillance.
Où ça se situe chez Opora
Programme 04 · Construire des agentsIngénierie agentique pour les équipes techniques
Faire passer un outil construit avec un agent de votre ordinateur à un service utilisable par l’équipe, proprement, c’est la dernière étape des projets du programme Construire des agents.
Questions fréquentes
Localhost, qu’est-ce que c’est exactement ?
Le nom que votre ordinateur se donne à lui-même. Quand un outil tourne en localhost, il est accessible dans votre navigateur, à une adresse comme localhost:3000, mais par personne d’autre. C’est l’environnement où l’on construit et teste avant de mettre en ligne.
Où déployer un outil interne ?
Plusieurs options selon le besoin : un hébergeur de sites et d’applications (Cloudflare, Vercel et d’autres) pour un outil web simple, un serveur de l’entreprise pour un outil qui touche à des données sensibles, ou une machine partagée en interne. Le choix se fait sur les données, le nombre d’utilisateurs et les compétences disponibles.
Que faut-il ajouter pour mettre en ligne ?
Un nom de domaine ou une adresse, le HTTPS, une authentification (qui a le droit d’utiliser l’outil), le stockage des secrets hors du code, une sauvegarde des données, et une surveillance minimale. Un agent de code fait l’essentiel sur consigne ; la liste doit être connue.