Une boutique de mode, de la maquette validée à la première commande.
Lune dessine et vend des vêtements en petites séries. Elle voulait vendre en ligne sans quitter WordPress, qu’elle connaît déjà. Voici comment une petite équipe et ses agents ont conçu, construit, recetté et mis en ligne sa boutique dans Nexus — étape par étape, et qui a fait quoi.
Le point de départ
Jusqu’ici, Lune vendait par Instagram et par messages privés. Les tailles s’épuisaient sans que personne le sache, chaque commande se notait à la main, et la collection d’été approchait.
Ce qu’il fallait
Une boutique que l’équipe de Lune tienne seule : ajouter une pièce, changer un prix, suivre une commande, sans développeur. Des fiches produit par taille et par couleur, le paiement par carte, des e-mails de commande à ses couleurs, et un site qui se lise d’abord sur téléphone.
Les contraintes
Rester sur WordPress, que l’équipe connaît déjà. Garder l’hébergeur actuel. Importer le catalogue depuis le tableur existant. Et n’envoyer aucun e-mail à une vraie cliente avant la mise en ligne.
Huit étapes, du brief à la première commande.
Chaque étape dit dans quel mode elle se passe, ce qu’elle emploie dans Nexus, et qui tient la main : un agent, une personne, ou les deux. Les gestes qui engagent — trancher, valider, recetter, mettre en ligne — restent aux personnes.
-
01
Studio
Le brief et la direction
L’agent lit le brief et les demandes de la cliente, puis compose une planche d’ambiance à partir des photos de la collection. Le designer tranche entre deux directions ; la retenue devient le territoire de la boutique.
Dans NexusDemandes du clientPlanche d’ambianceTerritoire de marqueQuiAgentDesigner -
02
Studio
Les six écrans clés
Accueil, catégorie, fiche produit, panier, paiement, compte : six écrans, bureau et mobile dans le même fichier. Le designer désigne ce qui ne va pas — un titre, une grille, un bouton — et l’agent ne reprend que cela.
Dans NexusMaquette HTML1440 · 390 pxZones désignéesVersionsQuiAgentDesigner -
03
Studio
Les retours de la cliente
La cliente reçoit un lien d’aperçu animé, sans compte. Ses commentaires épinglés reviennent dans le projet et se traitent un par un. La cheffe de projet valide : la maquette fait désormais autorité.
Dans NexusAperçu clientCommentaires épinglésValidationQuiClienteCheffe de projet -
04
Dev
La mise en place
Une tâche, une branche à elle. Le .env est généré depuis le coffre, sans qu’aucune valeur ne passe par la conversation, avec un SMTP de développement qui capture les e-mails au lieu de les envoyer.
Dans NexusTâcheBranche par tâcheCoffreCourriels capturésQuiCheffe de projetAgent -
05
Dev
Le thème et les fiches produit
L’agent exporte les tokens du Studio dans le thème enfant, intègre les six écrans, gère les variantes taille et couleur, puis compare son rendu à la maquette validée, aux deux tailles, et liste ce qui diffère encore.
Dans NexusTokens exportésPassage au codeRendu comparéQuiAgent -
06
Dev
Le catalogue et le paiement
Le tableur de Lune est importé par WP-CLI sur la préproduction. Stripe est posé en mode test ; les e-mails de commande sont écrits aux couleurs de la marque, et lus dans l’onglet Courriels.
Dans NexusCommande serveurStripe · mode testCourriels capturésQuiAgent -
07
Recette
La recette en préproduction
L’agent pousse sa branche et déploie la préproduction. La cliente passe de vraies commandes de test, sur son téléphone ; chaque remarque redevient une tâche, et repart par le même chemin.
Dans NexusPréproductionDemandes du clientTâchesQuiAgentCliente -
08
Production
La mise en ligne, puis la suite
La cheffe de projet met en ligne d’un clic ; le journal dit qui, et quand. Ensuite : sondes et sauvegardes, mises à jour essayées en préproduction, correctifs repartis du commit en ligne.
Dans NexusDéploiement · un clicSurveillanceSauvegardesDossier de repriseQuiCheffe de projetAgent
Les agents produisent. Les personnes décident.
Sur ce projet, deux agents ont écrit l’essentiel des maquettes et du code. Aucun n’a validé, recetté ni mis en ligne : ces gestes-là sont restés à ceux qui en répondent.
Les agents
Claude Code et Codex, pilotés par Nexus
- Lit le brief et les demandesAvant le premier trait, et avant la première ligne de code.
- Dessine les six écransBureau et mobile, repris zone par zone à la demande du designer.
- Intègre le thème enfantÀ partir de la maquette validée et des tokens exportés, jamais d’une piste.
- Importe le cataloguePar WP-CLI, sur la préproduction, avec les accès du coffre.
- Pose le paiement et les e-mailsStripe en mode test, e-mails capturés : rien ne part chez une vraie cliente.
- Déploie la préproductionEt compare son rendu à la maquette, en disant ce qui diffère encore.
- Veille après la mise en ligneMises à jour essayées d’abord, correctifs repartis du commit en ligne.
Les personnes
L’agence et sa cliente
- La cheffe de projetCrée les tâches, arbitre, valide la maquette, et met en ligne d’un clic.
- Le designerTranche la direction, désigne les zones à reprendre, retouche lui-même un détail.
- La clienteCommente l’aperçu animé, puis passe ses commandes de test en préproduction.
- Tous les troisVoient chaque écriture de l’agent, chaque version, chaque déploiement, dans le journal.
Une tâche, vue de l’intérieur.
La tâche 142 — les variantes de la fiche produit — telle que l’équipe l’a suivie : l’agent sur sa branche, les commandes lancées sur la préproduction avec les accès du coffre, le rendu comparé à la maquette, puis la demande de fusion. Et l’e-mail de commande, capturé, jamais envoyé.
# tâche 142 · Fiche produit : variantes taille et couleur
$ git switch -c tache-142-fiche-produit
✓ .env généré depuis le coffre — 9 clés, aucune affichée
✓ SMTP de développement posé : les e-mails sont capturés
→ préproduction · lune-preprod · accès SSH du coffre
$ wp wc product_attribute list --format=table
pa_taille XS, S, M, L, XL
pa_couleur écru, pivoine, encre
$ wp wc product create --type=variable --name="Robe longue fleurie" …
✓ 15 variantes créées, stock repris du tableur
→ rendu comparé à la maquette v01.00.09
✓ 1440 px : conforme
! 390 px : 2 écarts — sélecteur de taille trop serré, prix sous la photo
$ git commit -m "[tache 142] Fiche produit : variantes taille et couleur"
$ git push -u origin HEAD:refs/heads/tache-142-fiche-produit
✓ poussé · demande de fusion ouverte · préproduction déployée
✉ capturé : « Votre commande n° 1042 est confirmée » — non envoyé
$
- De
- Lune <commandes@lune.example>
- À
- cliente-test@lune.example
- Objet
- Votre commande n° 1042 est confirmée
Votre commande est confirmée. Nous la préparons à l’atelier et vous écrivons dès son départ.
Robe longue fleurieTaille S · pivoine189 €
Demande de fusion
[tache 142]Fiche produit : variantes taille et couleur[tache 142]Sélecteur de taille élargi en mobile[tache 142]Prix remonté au-dessus de la photo en 390 px
Ce qui est livré, et ce qui reste après.
Une boutique en ligne, bien sûr. Mais aussi tout ce qu’il faut pour que l’équipe suivante — ou l’agent de la prochaine session — reprenne sans rien redemander.
La même boutique, sur une autre techno.
Lune voulait WordPress ; votre client voudra peut-être autre chose. Le parcours ne change pas — Studio, branche, préproduction, recette, un clic. Seules changent les commandes lancées en route.
Le thème s’écrit en Liquid et les réglages passent par l’API ; l’agent essaie ses changements sur un thème non publié avant de le publier.
Un thème et un module ; même préproduction, mêmes accès du coffre, les commandes passent par la console de PrestaShop.
Un thème et des modules ; l’agent lance les commandes de Magento sur la préproduction, compilation et cache compris.
Le commerce est du code Symfony : les mêmes branches, les mêmes tests, le même passage en préproduction.
Le moteur et la vitrine séparés : deux dépôts, un seul projet, et la maquette validée commune aux deux.
Les questions sur ce cas.
Celles que posent les agences qui veulent faire la même chose pour leurs clients.
Pourquoi WordPress, et pas Shopify ?
Parce que l’équipe de Lune le connaissait et voulait tenir sa boutique seule. Nexus ne choisit pas la techno à votre place : il travaille dans celle du projet.
La cliente a-t-elle reçu de vrais e-mails pendant les essais ?
Non. Le .env généré par Nexus pose un SMTP de développement qui capture les messages : ils se lisent dans l’onglet Courriels du projet, et aucun ne part. Les vrais réglages ne vont qu’en production.
L’agent a-t-il vu les mots de passe ?
Il s’est servi des accès du coffre pour lancer ses commandes, sans que les secrets passent par la conversation. Le .env est généré depuis le coffre, et aucune de ses valeurs n’est recopiée.
Et si un bug apparaît après la mise en ligne ?
Le correctif part du commit en ligne, pas de la branche principale ; il passe par la préproduction, puis par le clic d’une personne. Le dossier de reprise dit ce qui est en ligne et ce qui ne l’est pas encore.
Combien de personnes faut-il pour un projet comme celui-ci ?
Ici, deux : une cheffe de projet et un designer, avec deux agents. Nexus ne remplace pas les décisions ; il fait le travail qui les sépare.
D’autres cas, dans la même famille
Paiement unique, en plusieurs fois ou par abonnement, éprouvé en mode test avant d’encaisser.
StripePayPalMollieBientôt Catalogue B2B et devisPrix par client, commande rapide, demandes de devis qui arrivent directement dans le CRM.
SyliusMagentoOdooBientôt Maintenance et mises à jourCœur, extensions et dépendances à jour, essayés en préproduction avant la production.
WP-CLIComposernpmBientôtVotre prochaine boutique, dans le même projet que sa maquette.
Nexus s’installe sur votre poste ; vos créations, vos accès et votre code restent rangés au même endroit.