Manuel : Mes builds, votre bibliothèque de produits

Je cherchais un build mardi dernier et je ne me souvenais plus comment j'avais nommé le chat — « landing page v2 », peut-être, ou quelque chose d'aussi peu utile six semaines plus tard. C'est généralement à ce moment-là que Mes builds cesse d'être un simple plus et devient l'outil vers lequel on se tourne vraiment. Passé la troisième ou quatrième application générée, faire défiler une liste de chats pour retrouver ce qu'on a créé est plus lent que ça ne devrait l'être, et la bibliothèque comble exactement ce manque. J'ai d'abord tapé « admin » dans la barre de recherche, par habitude, puis j'ai abandonné et utilisé les filtres à la place : Type restreint à application web, Catégorie puis affiné entre outils internes et outils destinés aux clients, et voilà — trois cartes plus loin, un badge de version indiquant v3. J'avais oublié être retourné deux fois dans ce chat. La bibliothèque ne me montrait pas des doublons ; elle me montrait l'historique. Les v1 et v2 n'avaient pas disparu, elles étaient simplement sorties de la vue par défaut, et cela s'est révélé important environ dix minutes plus tard quand le client d'un autre projet a détesté un changement de navigation que j'avais livré en v4. J'ai ouvert l'ancienne carte v3, parcouru son arborescence de fichiers sur place, récupéré les deux fichiers pertinents, et redéployé. Aucun nouveau prompt, aucune fouille dans une transcription de chat pour reconstituer à quoi ressemblait l'ancienne mise en page. C'est la partie de l'anatomie des cartes qui fait ses preuves avant même qu'on ouvre quoi que ce soit : une vraie capture d'écran comme vignette, prise après vérification, pour que ce que vous voyez soit vraiment ce qui s'est affiché plutôt qu'un build techniquement terminé mais en erreur au chargement. En dessous, des badges de type et de catégorie, un numéro de version, un horodatage relatif. De quoi trier sans avoir à cliquer. Et une fois qu'on clique, les choix se distinguent clairement —

Aperçu ouvre directement le build en direct, sans téléchargement, sans serveur local. Pour un site web, c'est l'expérience déployée ; pour un build desktop ou mobile, c'est ce qui se rapproche le plus de l'exécution réelle sans installation.
Code est l'arborescence de fichiers, consultable directement sur place. Je l'utilise constamment pour une vérification rapide de trente secondes — a-t-il vraiment utilisé la bibliothèque que j'ai demandée — avant de me lancer dans un téléchargement.
Le menu d'actions couvre le téléchargement, la publication, les installateurs natifs pour tout ce qui les prend en charge, l'envoi vers un store lorsque cela est éligible, et l'enregistrement comme modèle.

Rien de tout cela ne nécessite de rouvrir la conversation. Je ne suis retourné dans le chat d'origine qu'une seule fois ce jour-là, et c'était pour demander un vrai changement, la seule chose que la bibliothèque ne peut vraiment pas faire à votre place — les changements ont besoin de contexte, et le contexte vit dans le fil de discussion. Tout le reste, la bibliothèque le gère seule, en parallèle du chat plutôt que comme un simple raccourci vers celui-ci. Publiez quelque chose depuis la carte, et le chat le reflète la prochaine fois que vous ouvrez ce fil ; publiez-le depuis le chat, et la carte se met aussi à jour. Même build, deux portes d'accès. Plus tard dans l'après-midi, une collègue m'a demandé un lien vers quelque chose que j'avais construit la semaine précédente, et j'ai remarqué que je ne l'ai pas orientée vers la conversation — je lui ai envoyé la carte, et honnêtement je lui aurais envoyé l'URL publiée directement depuis la carte si elle avait déjà été en ligne. Personne n'a envie de fouiller dans l'historique de chat d'une autre personne pour retrouver un fichier. Dès qu'une équipe compte plus de deux ou trois builds par personne, la séparation se fait naturellement : le chat reste votre atelier privé, la bibliothèque devient ce que les autres consultent réellement. J'avais aussi un jeu qui traînait là depuis un projet de week-end, ce qui m'a rappelé que la bibliothèque n'est pas la seule vue sur ces mêmes données. Les jeux apparaissent dans Mes builds comme n'importe quoi d'autre, mais ils vivent aussi dans Mes jeux, filtrés par mode de jeu et statut de publication, et si les jeux constituent l'essentiel de ce que vous créez, c'est la meilleure vue au quotidien. La même logique s'applique à Publié, qui affiche l'état actuel en direct pour tout ce qui dispose d'une URL ou est en file d'attente pour un store, et Publié, qui suit le statut de validation en boutique d'applications ou d'extensions. Des questions différentes posées aux mêmes cartes — « qu'est-ce qui est en ligne actuellement » contre « qu'ai-je construit sur tel sujet » — pas des systèmes séparés assemblés tant bien que mal. Une chose m'a surpris la première fois : publier un build ne le fige pas. Je suis retourné dans le chat de ce panneau d'administration plus tard, j'ai demandé un changement, obtenu une v4 — et la version publiée en direct a continué à servir la v3 jusqu'à ce que je redéploie explicitement. Logique une fois qu'on y réfléchit. Si chaque prompt lancé au hasard contre un chat en direct pouvait casser un site en production, plus personne n'oserait toucher un build publié. L'autre chose que j'ai faite cette semaine-là, presque en passant, c'est d'enregistrer le panneau d'administration comme modèle. C'était le troisième outil interne que je construisais avec essentiellement la même ossature — même mise en page, même socle d'authentification, mêmes composants de tableau, juste des données différentes en dessous. Enregistrer comme modèle a repris la structure et le style, pas le contenu spécifique, et démarrer le quatrième build à partir de là a transformé ce qui aurait été vingt minutes de discussion de planification en environ cinq minutes. Le hic, c'est qu'un modèle est figé au moment où on l'enregistre — mes conventions ont évolué depuis, et l'ancien modèle n'en sait rien. Très bien pour un point de départ dont on va de toute façon s'éloigner ; si vous voulez une réutilisation qui reste réellement synchronisée, mieux vaut référencer des fichiers d'un build à l'autre plutôt que d'en faire un modèle.

Rien n'expire. Cette v1 vieille de six semaines, toujours présente sous la v3 dans l'historique — toujours prévisualisable, téléchargeable, publiable, exactement aussi accessible que ce que j'ai construit ce matin. Aucune purge automatique en arrière-plan. La bibliothèque est une archive depuis laquelle on peut déployer, pas une page d'historique contre laquelle on court.

Guide

PartagerX LinkedIn Facebook Reddit Quora WhatsApp Telegram E-mail

← Tous les articles

Manuel : Mes builds, votre bibliothèque de produits

Articles connexes

Le manuel BuildMidas : une carte de la plateforme

Écrire des prompts qui construisent bien

Lire le plan (et le modifier)