Étape 5 · Mettre en ligne

`/pulse:deploy`

Mettre l'appli en ligne et la mettre à jour automatiquement à chaque envoi, puis passer en mode production (variables, services, retour arrière ; les contrôles automatiques se mettent en place avec /pulse:cicd).

Description

Cette commande met votre appli en ligne, chez l'hébergeur choisi avec /pulse:tech. La première fois, elle relie votre projet à un dépôt en ligne, puis vous guide pas à pas chez l'hébergeur. Ensuite, c'est comme un document partagé qui se met à jour tout seul : chaque fois que vous envoyez une nouvelle version, le site se met à jour en quelques minutes.

Avant chaque envoi, Pulse vérifie que tout est enregistré, que vos clés restent hors du code, et que les tests et la construction passent. Après la publication, il prouve que le site répond vraiment et qu'il reste visible pour Google. Le mode production prépare enfin le site « pour de vrai » : les variables secrètes chez l'hébergeur, les services connectés, une surveillance et un plan de retour arrière.

Mise en ligne :
  Contrôles    ✅ secrets · tests · construction
  Envoi        ✅ version envoyée au dépôt distant
  Site         ✅ https://carnet-coiffure.example répond
  Google       ✅ le site reste visible

➡️ Votre nouveauté est en ligne : ouvrez l'adresse pour la voir.

Les preuves que /pulse:deploy donne à la fin d'une mise à jour.

Vous acceptez l'envoi de votre travail vers le dépôt distant. Les contrôles automatiques vérifient le projet, puis l'hébergeur construit et publie la nouvelle version. Pulse vérifie que le site répond. Si quelque chose ne va pas, l'hébergeur peut remettre en ligne la version précédente.

Pourquoi l'utiliser

Votre site est en ligne dès la première fois. Un guidage écran par écran chez l'hébergeur, une étape à la fois.
Chaque envoi met le site à jour tout seul. Vous enregistrez, vous envoyez : quelques minutes plus tard, la nouveauté est visible.
Une mise en ligne est prouvée, pas supposée. Pulse vérifie que le site répond et qu'il reste ouvert à Google.
Tout reste réparable. Le mode production écrit le chemin du retour arrière, pour le site puis pour les données.

Quand l'utiliser

1 Démarrer
2 Décrire
3 Préparer
4 Construire
5 Mettre en ligne
6 Être trouvé
7 À tout moment

La première fois, une fois l'hébergeur choisi avec /pulse:tech et le travail enregistré.
À chaque nouvelle version à publier, après /pulse:commit.
Quand le site sert de vrais clients, ou stocke des données, ou utilise des clés : /pulse:deploy production.
Après la première mise en ligne, Pulse propose /pulse:security, puis /pulse:seo lancer si le site doit être trouvé sur Google.

Comment la lancer

/pulse:deploy [premiere | production]

Entre crochets [ ] : facultatif. Entre chevrons < > : à remplacer par votre valeur. La barre | sépare les choix possibles. Détecté automatiquement si vide.

Sans argument : Pulse choisit tout seul. Pas encore de dépôt distant : première mise en ligne. Sinon : mise à jour. Un projet avec des données ou des clés mais sans contrôle avant mise en ligne passe aussi par le mode production.
premiere : la première mise en ligne, avec le dépôt distant, le guidage chez l'hébergeur et un contrôle rapide de sécurité avant.
production : le mode « pour de vrai » : contrôle avant chaque mise en ligne, variables chez l'hébergeur, services connectés, surveillance, retour arrière.

/pulse:deploy

/pulse:deploy production

Ce qu'elle produit

Fichier ou lieu	Ce qui change
Chez l'hébergeur	Votre site en ligne, mis à jour à chaque envoi.
`CLAUDE.md`, `README.md`	L'adresse du dépôt et celle du site, dans la section « Adresses ».
`docs/technical.md`	Les lignes « Site en ligne » et « Surveillance », et la section « Retour arrière ».
Fichier de configuration de l'hébergeur	Seulement si sa documentation l'exige ; montré avant d'être écrit.
`docs/performance.md`	Facultatif : la première mesure de vitesse de l'accueil, point de départ.
Le plan en cours	La tâche « Mettre en ligne… » cochée, avec une ligne dans son journal.

Risques et précautions

Chaque envoi passe par votre accord. Claude Code vous le demande : c'est ce qui met votre travail sur le dépôt distant, d'où l'hébergeur le publie.
Une erreur bloque l'envoi. Un test en échec, une clé trouvée dans le code ou une construction ratée arrêtent tout avant la mise en ligne.
La première mise en ligne passe un contrôle rapide de sécurité. Un point « à corriger tout de suite » la bloque ; une clé exposée se traite avec /pulse:secrets fuite.
Vos clés ne passent jamais par la conversation. Elles vont de votre éditeur à .env, puis à l'hébergeur, ou vous les saisissez vous-même dans ses réglages.
Les actions chez l'hébergeur et chez le service de surveillance se font par vous, guidé d'après leur documentation officielle.

Problèmes et solutions

« Il faut d'abord choisir où mettre l'appli en ligne »

L'hébergeur ou le dépôt distant ne sont pas encore choisis dans docs/technical.md. Lancez /pulse:tech, puis revenez à /pulse:deploy.

Un test ou la construction échoue avant l'envoi

L'envoi attend que tout passe. Corrigez avec /pulse:fix ou /pulse:auto-fix, puis relancez /pulse:deploy.

Le site ne répond pas après la publication

Pulse lit la cause donnée par sa vérification et vous l'explique : souvent un réglage de construction chez l'hébergeur, ou une variable manquante. Vous corrigez ensemble, puis il vérifie à nouveau.

« Mise en ligne à corriger : Google ne peut pas voir le site »

Le garde-fou de référencement a trouvé un blocage grave, par exemple une page publique marquée « à ne pas indexer » ou une adresse officielle qui pointe vers votre ordinateur. Pulse explique la conséquence, corrige, remet en ligne et vérifie à nouveau.

Ma branche s'appelle master

Pulse propose de la renommer main, le nom de la version publiée par les hébergeurs.

Exemples

/pulse:deploy

Contrôles : ✅ tout est enregistré · ✅ aucune clé dans le code · ✅ tests et construction · ✅ contrôle rapide de sécurité. Pas encore de dépôt distant : je vous guide pour en créer un.

Claude Code va vous demander l'accord pour envoyer : c'est ce qui met votre travail sur le dépôt distant, d'où l'hébergeur le publie. Maintenant, chez l'hébergeur : connectez-vous avec votre compte du dépôt, puis créez un nouveau projet à partir du dépôt carnet-reservations. Dites-moi quand c'est fait.

C'est en ligne : https://carnet-coiffure.example

pulse-aidd sonder https://carnet-coiffure.example --texte "Carnet de réservations" pulse-aidd seo https://carnet-coiffure.example --essentiel

✅ Le site répond et affiche « Carnet de réservations ». ✅ Google peut le voir. Mesurer la vitesse de la page d'accueil maintenant (2 minutes, point de départ) ? (Recommandé) · Plus tard

/pulse:deploy production

Avant chaque mise en ligne, un contrôle qualité automatique vérifiera le projet. S'il échoue, l'ancienne version reste en ligne à la place de la nouvelle, défectueuse.

pulse-aidd secrets inventaire

Une variable manque en production : SMTP_PASSWORD, le mot de passe d'envoi des e-mails de confirmation. Je prépare la ligne vide dans votre fichier ; collez-y la valeur dans votre éditeur, enregistrez, fermez l'onglet, puis dites-moi « c'est fait ». Je ne lirai jamais cette valeur : elle part directement chez l'hébergeur, après votre accord.

Dernière étape : une sonde de disponibilité, qui vous prévient par e-mail si le site ne répond plus. Puis je vous montre le retour arrière : tout reste réparable.

Commandes liées

/pulse:cicd : les contrôles automatiques, qui complètent la mise en ligne automatique.
/pulse:secrets : l'inventaire de vos clés, et que faire si l'une a fuité.
/pulse:security : l'audit complet, une fois le site ouvert à tous.
/pulse:seo : être trouvé sur Google, une fois le site sur son adresse définitive.
/pulse:perf : mesurer la vitesse vécue par vos visiteurs.
/pulse:pr : tester une nouveauté sur une adresse de prévisualisation avant de la publier.