De l'idée à l'expédition : comment un fondateur technique construit avec le code Claude et le contexte complet

L'opérateur

Un fondateur technique qui construit deux produits SaaS tout en travaillant sur quatre projets clients exécute une opération de changement de contexte autant qu'une opération logicielle. Chaque produit a sa propre feuille de route, son carnet de commandes et son ensemble de conversations avec les parties prenantes. Chaque projet client a son propre dépôt, son propre fil de communication dans Slack ou par courrier électronique, et ses propres attentes concernant ce qui est construit et quand. Le fondateur est à la fois l'équipe d'ingénierie et le responsable de compte, ce qui signifie que chaque changement de contexte entraîne une réelle surcharge : revenir au bon modèle mental avant de pouvoir écrire une seule ligne de code.

Les outils existent déjà pour bien construire le logiciel — Claude Code gère l'implémentation, les tests et l'itération à un niveau qui aurait nécessité une petite équipe il y a quelques années. La lacune ne vient pas du cerveau qui fait le travail ; c'est dans ce que le cerveau sait quand il démarre. Chaque session de travail commence par les mêmes questions : qu'est-ce que j'étais en train de construire, où ai-je arrêté, qu'est-ce qui a changé dans les conversations avec les parties prenantes depuis la dernière session et qui a besoin de savoir quand cela sera livré.

Le point de rupture

Les frais généraux s’accumulent par petites quantités qui ne semblent pas constituer un problème structurel jusqu’à ce qu’ils soient additionnés. Le fondateur passe les trente premières minutes de la plupart des sessions à relire les fils de discussion et les e-mails de Slack pour reconstruire clairement le contexte de spécification qu'il a tenu pour la dernière fois il y a deux jours. Une fonctionnalité qu'ils ont livrée la semaine dernière a généré une question des parties prenantes à laquelle ils n'ont pas encore répondu, non pas parce qu'ils l'ont manquée, mais parce qu'elle est arrivée dans le mauvais onglet. Un jalon d'un projet client qui a été convenu dans un e-mail n'a été intégré à aucune tâche ou calendrier car il n'y avait aucun moment pour l'arrêter et l'enregistrer.

Le problème le plus profond est que Claude Code, aussi puissant soit-il, démarre chaque session sans rien savoir. Le fondateur colle le contexte - la spécification, le fil de discussion pertinent, l'état actuel du problème de base de code - et la session est alors productive. Mais l’étape de collage est manuelle, avec perte et jamais tout à fait complète. Le modèle raisonne avec brio quel que soit le contexte qu’il reçoit ; la contrainte est que l'assemblage de ce contexte prend du temps et du jugement humain avant que le véritable travail ne commence.

Lorsque quelque chose est expédié, l’étape de communication tombe au bas de la pile prioritaire. La fonctionnalité est terminée ; le dire aux bonnes personnes est une source de friction. Une partie prenante qui attendait un livrable le découvre quelques jours plus tard, non pas parce que le fondateur les a oubliés, mais parce qu'il n'existait aucun système permettant de transformer une tâche terminée en notification sortante.

La configuration

Le fondateur technique connecte Gmail pour les fils de communication avec les clients et Google Drive pour les spécifications, les documents de conception et les résumés de projet. Chaque produit et chaque engagement client a sa propre organisation et son propre projet au sein de Lodestar : deux organisations de produits avec leurs propres projets de feuille de route, quatre organisations clientes chacune avec un projet de livraison. Le serveur MCP est connecté à Claude Code afin que chaque session de terminal puisse atteindre l'image de fonctionnement complète sans passer par un onglet de navigateur.

Lodestar ingère les fils de discussion de courrier électronique et les documents Drive existants et commence à extraire les éléments d'action avec des preuves, chacun étant lié au devis ou au fichier exact dont il provient. En une journée, les éléments ouverts dans les six contextes sont visibles en un seul endroit, organisés par projet, avec des dates d'échéance déduites là où ils apparaissent dans le matériel source. Le fondateur n’a rien saisi manuellement ; cela a fait surface à partir de l’histoire des communications qui existait déjà.

Le flux de travail

Une session de travail typique commence par une invite en langage naturel adressée à Claude Code : quel est l'état actuel de la journée. A partir de là, la session s'exécute entièrement dans l'éditeur. Pas de changement d'onglet, pas d'assemblage de contexte manuel, pas d'étape de communication séparée à la fin.

• ·Sense — Claude Code appelle `dashboard_today` via le MCP pour obtenir l'image quotidienne classée. La réponse montre trois éléments d'action attendus dans les six contextes : un bloquant une version de produit, un un livrable client, un une réponse d'une partie prenante qui était en attente.
• ·Sens — Le fondateur dit : implémentez l'élément de blocage. Claude Code appelle « action_items_retrieve » sur l'ID de cet élément pour obtenir l'enregistrement structuré complet : le fragment de spécification à partir duquel il a été extrait, le document Drive lié, le fil de discussion de courrier électronique dans lequel la partie prenante a pesé pour la dernière fois et le contexte de base de code associé.
• ·Sense — Claude Code appelle `knowledge_search` et `files_content` pour extraire les spécifications actuelles et toutes les décisions de conception antérieures enregistrées dans Drive. Il appelle « context_resume » pour faire apparaître ce qui a été décidé en dernier lieu dans le fil de discussion des parties prenantes. Tout cela arrive dans la session sans que le fondateur n'ouvre un seul onglet de navigateur.
• ·Décider — Une fois le contexte complet assemblé, Claude Code planifie la mise en œuvre : quoi construire, dans quel ordre, comment le tester. Le fondateur examine le plan, confirme ou ajuste l'approche et la session de mise en œuvre commence.
• ·Agir — Claude Code écrit le code, exécute des tests et itère. Lorsque la mise en œuvre est prête, le fondateur dit : expédiez-la et bouclez la boucle. Claude Code appelle `action_items_partial_update` pour marquer l'élément terminé, puis `timeline_events_create` pour enregistrer l'achèvement par rapport à la chronologie du projet.
• ·Fermer — Claude Code appelle `emails_reply_link` pour rédiger une notification aux parties prenantes — fondée sur l'élément exact qui a été complété, faisant référence à la demande originale du fil de discussion. Le brouillon s'ouvre dans la fenêtre de rédaction du fondateur ; ils l'examinent et cliquent sur envoyer. Claude Code appelle `milestones_partial_update` pour avancer le jalon du projet si l'achèvement en déclenche un.
• ·Le même schéma se répète pour le livrable client : récupérer le contexte, implémenter, fermer, notifier. L'intégralité de la session (assemblage du contexte, mise en œuvre, mise à jour du statut, notification des parties prenantes) reste dans l'éditeur.

Quels changements

L'étape de collage disparaît. Claude Code arrive à chaque session avec les spécifications, l'historique des threads, les décisions antérieures et les engagements ouverts déjà dans la portée, car Lodestar les conserve sous une forme structurée et le MCP les présente à la demande. Les frictions avant le début du véritable travail vont d'un exercice de reconstruction d'une demi-heure à quelques secondes de récupération du modèle.

La communication avec les parties prenantes devient un sous-produit de l'expédition plutôt qu'une tâche distincte. Lorsqu'un élément se ferme, le brouillon de notification est généré à partir du contexte d'achèvement réel, et non à partir de la mémoire. Le fondateur révise et envoie au lieu de composer à partir de zéro. L’écart entre quelque chose expédié et la bonne personne qui en est informée s’effondre.

L’image opérationnelle dans six contextes reste à jour sans maintenance manuelle. Les éléments d’action apparaissent automatiquement à partir des fils de communication. Les étapes avancent lorsque les preuves arrivent. La chronologie reflète ce qui s'est réellement passé, construite à partir du même matériel source que Claude Code a utilisé pour créer le logiciel.