Comment l’équipe ops de ZeroSuite a arrêté de jongler entre onglets : journal de build de Conductor, l’espace de travail interne qui regroupe tâches, lancements, notes, assets et une IA multimodale dans une seule application SvelteKit, et ce que cela prouve sur Claude comme copilote pour le logiciel d’entreprise

Par Thales (CEO, ZeroSuite) et Claude Opus 4.7 — instance Claude Code

Le 2 juin 2026, l'équipe ops de trois personnes de ZeroSuite à Abidjan a ouvert Conductor à ops.zerosuite.dev et l'a utilisée pour planifier un lancement Déblo, rédiger un communiqué de presse, vérifier trois comptes sociaux, contrôler la conformité au ton de marque de deux nouveaux corps d'asset, générer quatre images de référence pour un script TikTok, chercher dans vingt-sept notes d'équipe privées la recette d'une configuration d'authentification par lien magique documentée six semaines plus tôt, et demander au Conductor Agent — un assistant multimodal disposant de trente-deux outils de lecture et d'écriture sur les données propres de l'équipe — un résumé de quinze secondes sur ce qui bloquait le lancement ce matin. L'équipe a tout fait dans un seul onglet. Le compteur d'onglets à gauche de la fenêtre affichait 1. Le compteur d'heures en haut à droite de la surface Ask affichait 3 h 12 min pour la journée. Voilà à quoi ressemble l'usage quotidien d'outillage interne par l'équipe, six semaines après que le fondateur a décidé d'arrêter de payer la pile de cinq abonnements sur laquelle ces flux étaient auparavant éclatés.

Ceci est le journal de construction de ce qu'est Conductor, des raisons pour lesquelles il existe, de ce qu'il fait réellement (ancré dans le code, pas dans le pitch deck), de ce qu'il refuse délibérément de faire, et de ce que le temps de build — dépôt vide à outil quotidien actif en trente-cinq sessions sur quatre jours civils de développement actif — dit de Claude Opus 4.7 comme copilote pour un outillage interne sérieux à l'échelle d'une petite équipe.

L'affirmation produit étroite est la suivante : une seule application SvelteKit, déployée une fois sur Easypanel contre une base Postgres unique, remplace les quatre à cinq abonnements SaaS qu'une équipe ops multi-produit de trois personnes assemblerait sinon. L'affirmation plus large, que ce billet défend à partir du code, est la suivante : les petites équipes peuvent désormais construire des outils internes à un niveau de fidélité qui exigeait jusqu'ici une embauche d'ingénieur dédiée. Le copilote n'écrit pas les décisions stratégiques à votre place, mais il absorbe assez du coût d'implémentation pour que la stratégie redevienne la contrainte qui mord.

Partie 1 — Ce que Conductor remplace

Avant Conductor, l'équipe ops de ZeroSuite faisait quelque chose de reconnaissable. L'équipe compte trois personnes — un fondateur-ingénieur à Abidjan et deux généralistes ops — qui construisent sept produits en parallèle : Déblo (application éducative grand public), sh0 (outillage développeur), FLIN (compilateur), 0fee (transparence des frais), 0cron (planification), 0diff (visualisation de diffs), VeoStudio (production vidéo). Chaque produit avait sa propre cadence de lancement, ses propres assets, ses propres comptes sociaux, sa propre liste presse. Le flux de travail de l'équipe avant Conductor s'étalait, par friction décroissante :

• Un outil de gestion de projet pour les tâches sur les sept produits, chaque produit étant un projet, avec des sous-projets pour chaque lancement.
• Une base documentaire pour les notes, les décisions, les post-mortems et la liste courante des « choses apprises à nos dépens ».
• Une application de chat LLM sur abonnement pour la rédaction assistée par IA, utilisée en parallèle d'un produit de génération d'images distinct et d'un produit de génération vidéo distinct, parce qu'aucune des applications LLM grand public ne couvrait les trois au niveau de qualité d'asset dont l'équipe avait besoin.
• Une feuille de calcul séparée (dans un workspace partagé) pour la liste de distribution des lancements — chaque blog, chaque contact presse, chaque annuaire dans lequel on voulait apparaître, l'état de chaque soumission.
• Une série de rotations d'identifiants d'authentification sur tous les outils ci-dessus, renégociées à chaque arrivée ou départ d'une personne.

La friction n'était pas le coût des abonnements, qui restait modeste. La friction tenait à trois faits opérationnels. Premièrement, les sept produits et les trois personnes produisaient des données qui traversaient les frontières de chaque outil — une tâche dans un outil référençait un asset dans un autre outil, rédigé avec l'aide d'un troisième outil contre des notes de recherche qui vivaient dans un quatrième outil. Deuxièmement, aucun des outils ne savait rien des autres, donc toute synthèse transversale (« qu'est-ce qu'il reste à expédier pour le lancement Déblo de juin 2026 ? ») devenait un exercice manuel consistant à ouvrir cinq onglets et lire. Troisièmement, quand le fondateur voulait poser la même question à un assistant IA, l'assistant n'avait aucun accès privilégié à l'un des cinq outils — il pouvait rédiger une réponse à partir de ce que le fondateur lui collait, mais la réponse était consultative, pas faisant autorité.

Le problème des cinq onglets est la forme caractéristique de la friction d'outillage interne pour les petites équipes multi-produit. Chaque outil isolé n'a pas l'air mauvais — chacun fait bien son travail — mais le coût cognitif agrégé du changement de contexte entre eux est important, et l'assistance IA disponible y reste superficielle, parce qu'aucun assistant grand public n'a accès autorisé aux cinq.

Conductor est la réponse au problème des cinq onglets. C'est une application. Un login. Un journal d'audit. Une base de données. Et l'assistant IA — que nous appelons le Conductor Agent — dispose d'un accès autorisé, périmétré et audité à chaque table que traverse le travail quotidien de l'équipe. Quand le fondateur demande à l'agent « qu'est-ce qui bloque encore le lancement Déblo ? », l'agent appelle un outil nommé get_launch_readiness qui renvoie un rapport structuré calculé côté serveur à partir des lignes réelles dans les tables tasks, assets et accounts, puis raconte le résultat en trois phrases. La réponse fait autorité parce qu'elle a été calculée à partir des mêmes données que le flux manuel de l'équipe aurait lues.

Partie 2 — Le choix architectural : une seule application, pas six

Le positionnement de Conductor, verrouillé dans le CLAUDE.md du projet, est l'espace de travail de ZeroSuite — l'espace IA quotidien de l'équipe ops de trois personnes ET le centre de commande des lancements. Une application, une auth, un journal d'audit, un seul portail de conformité. La contrainte « une seule application » était une décision délibérée, pas un défaut. Elle a écarté trois autres architectures que l'équipe a envisagées.

La première architecture rejetée était un découpage en microservices — un frontend séparé, un backend séparé, un worker séparé, une couche de stockage de fichiers séparée. Défendable à l'échelle, mais à trois utilisateurs et un fondateur-ingénieur, la surface opérationnelle de ne serait-ce que trois unités déployables aurait consommé plus de temps que la logique applicative elle-même. L'application SvelteKit unique, où les routes serveur de SvelteKit font office de backend, se déploie comme un seul processus Node derrière un reverse proxy Caddy unique sur un seul service Easypanel.

La deuxième architecture rejetée était une généralisation à la Notion — « tout est un bloc » — une couche de contenu générique avec un schéma souple modelable par cas d'usage. Rejetée pour la même raison que toute entreprise qui a tenté cette voie a fini par construire à côté des outils spécialisés : la méta-couche rend tout flux spécifique plus coûteux, pas moins, parce que chaque utilisateur doit concevoir son flux à partir de primitives. Le modèle de données de Conductor est volontairement étroit — Product, Launch, Task, Asset, Account, Check, Rule, Note, Distribution, Conversation, Message, AuditLog. Ajouter une abstraction hypothétique « Sprint » ou « Workspace » ou « Custom Field » est interdit par une règle critique documentée, parce que chaque abstraction ajoutée entre en concurrence pour le modèle mental de l'équipe avec les quatre piliers (tâches, lancements, assets, comptes).

La troisième architecture rejetée était l'extension d'un outil interne existant de l'un des produits — par exemple, construire Conductor comme une fonctionnalité du dashboard admin de Déblo. Rejetée parce que l'admin de Déblo est centré produit grand public (données utilisateur, modération de contenu, ops de paiement) et aurait hérité d'un modèle de menace entièrement différent. Le modèle de menace de Conductor est interne petite équipe — trois personnes sur une allowlist, authentification par lien magique, aucun chemin de lecture anonyme. Mélanger cela avec le modèle de menace grand public de Déblo aurait dégradé les deux.

L'architecture « une application SvelteKit unique » n'est donc pas un défaut. C'est un choix réfléchi qui paie parce que l'échelle de l'équipe et le positionnement du produit le récompensent tous deux. Le jour où Conductor dépassera dix utilisateurs ou commencera à détenir des données de paiement, l'architecture devra être revisitée. D'ici là, l'application unique l'emporte.

Partie 3 — Les onze surfaces

Conductor affiche aujourd'hui onze entrées dans la barre latérale, regroupées en deux sections par objet. Chaque entrée est une route SvelteKit de premier niveau à /path avec son propre page server load + son propre composant Svelte de page + les endpoints API pertinents sous /api/. En lisant la barre de gauche de n'importe quel écran de Conductor :

Workspace — les surfaces assistées par IA que l'équipe utilise pour le travail de connaissance au quotidien :

• Ask (/) — le foyer du Conductor Agent. Un chat multimodal avec l'agent, qui dispose d'un accès autorisé à trente-deux outils sur les données propres de l'équipe. Les conversations sont persistantes, par utilisateur, avec prise en charge complète des pièces jointes pour images et PDF (que Gemini, le modèle sous-jacent à la couche OpenRouter, lit nativement). La barre de composition au-dessus du textarea expose des modes Image et Video, plus un mode Custom pour saisir un model id directement.
• Gallery (/gallery) — une grille chronologique de chaque image et vidéo que l'appelant a générées. Source : les lignes messages.attachments_json filtrées aux conversations propres de l'appelant, plus la table video_jobs pour les vidéos terminées. Cliquer sur une vignette fait défiler la conversation d'origine jusqu'au message auquel l'asset appartient. Filtrable par type (images / vidéos / tout), période (aujourd'hui / semaine / mois / tout) et modèle.
• Notes (/notes) — des notes markdown privées par défaut, avec recherche plein texte (Postgres tsvector), partage optionnel à l'équipe, pièces jointes et un résolveur de backlinks pour les liens du style [[name]]. La base documentaire courante de l'équipe, remplaçant ce que nous faisions dans une application de notes séparée.
• Resources (/resources) — un annuaire curé de cent dix outils externes, contacts presse, annuaires et références que l'équipe utilise sur les sept produits. Chaque entrée a un nom, une URL, une description en une ligne, une catégorie et des tags. Les catégories sont imposées par l'application (seize au total), non modifiables par l'utilisateur, à dessein. L'outil get_resources de l'agent expose cet annuaire dans le chat pour que l'agent puisse répondre « quel outil utilise-t-on pour X ? » à partir de la liste canonique de l'équipe plutôt qu'à partir de ses a priori d'entraînement.

Launch ops — les surfaces opérationnelles que l'équipe utilise pour expédier les sept produits :

• Overview (/overview) — une carte instantanée par produit actif qui affiche la préparation au lancement (tâches restantes, nombre bloqué, état de conformité des assets, état de vérification des comptes) calculée côté serveur à partir du même helper get_launch_readiness que l'agent IA appelle. La carte est une requête, parallélisée sur les produits.
• Tasks (/tasks) — le tableau de tâches de l'équipe. Filtrable par statut, propriétaire, produit, tag et retard. Les vues groupées (mes ouvertes, non assignées, bloquées, en retard) correspondent aux quatre outils de lecture IA que l'agent utilise pour énumérer les mêmes données. Les tâches ont des descriptions, des propriétaires, des dates d'échéance, un texte optionnel de bloqueur et un fil de commentaires.
• Calendar (/calendar) — la vue chronologique des lancements. Les tâches avec dates d'échéance plus les jalons de lancement plus le calendrier du digest quotidien, sur une seule timeline. Transversale aux produits, pour que l'équipe voie quand deux lancements se télescopent.
• Launches (/launches) — les pages de détail par lancement. Objectifs, dates clés, sous-ensemble de tâches pour ce lancement, sous-ensemble d'assets pour ce lancement, soumissions de distribution pour ce lancement. Concrètement la vue « playbook en cours » pour chaque lancement.
• Assets (/assets) — la bibliothèque de contenu, avec contrôle de conformité au ton de marque déclenché à la sauvegarde. Chaque asset (un brouillon de post, un communiqué de presse, un corps d'email, un script TikTok, un copy publicitaire) passe par un moteur de conformité qui le compare au jeu de règles éditable dans docs/brand_voice_rules.yaml. Les assets en échec sont marqués avec la règle exacte qui s'est déclenchée. La revue de conformité est le portail, pas une suggestion — les assets ne peuvent pas passer au statut published sans valider.
• Distribution (/distribution) — le suivi de pipeline de soumissions pour les lancements. Cent dix entrées d'annuaire pour le seul lancement Déblo, chacune avec un statut (en file, soumise, acceptée, refusée, etc.), une date de soumission et une jointure avec les assets qui y ont été soumis. Remplace la feuille de calcul que l'équipe maintenait.
• Accounts (/accounts) — le vérificateur de comptes sociaux. Douze comptes épinglés sur les sept produits. Pour chaque compte, un vérificateur basé sur des requêtes HTTP (pas d'API payantes au MVP) confirme l'existence du compte, la correspondance de la bio au ton canonique et la résolution de l'URL du profil. Les échecs remontent sur la carte Overview et dans la réponse get_pinned_accounts de l'agent.

Un widget de chat d'équipe ancré en bas à droite de chaque écran propose des chats internes un-à-un et de groupe, avec un canal email hors ligne en backup — il remplace les fils WhatsApp que l'équipe utilisait pour la coordination asynchrone rapide, à l'échelle qui ne justifie pas encore un abonnement Slack. Une cloche de notifications dans l'en-tête fait remonter les messages in-app de l'agent, des coéquipiers et des jobs cron planifiés. Settings, déconnexion et un styleguide complètent le reste.

Les onze entrées de la barre latérale plus le widget de chat plus l'en-tête plus la surface de l'agent constituent la surface quotidienne complète. Il n'y a pas de panneaux de paramètres cachés, pas de dashboards admin, pas d'écrans de config par produit. Le modèle mental de Conductor pour l'équipe tient dans une capture d'écran de la barre de gauche.

Partie 4 — Le Conductor Agent : trente-deux outils sur les données propres de l'équipe

Le Conductor Agent est la surface qui rend Conductor différent d'« un outil de gestion de projet plus une app de notes plus une bibliothèque d'assets ». L'agent est un modèle multimodal de classe Gemini derrière une couche de routage OpenRouter, servi via streaming SSE par la route messages/+server.ts, configuré avec un system prompt dans src/lib/server/ai/system-prompt.ts qui nomme l'équipe, les produits, le rôle de l'agent et le catalogue d'outils que l'agent est autorisé à appeler.

Le catalogue d'outils, à l'heure où ceci est écrit, se découpe en vingt-deux outils de lecture et dix outils d'écriture. Les outils de lecture couvrent :

• Tasks — get_my_open_tasks, get_blocked_tasks, get_unassigned_tasks, get_overdue_tasks.
• Launches — get_launch_readiness (la vue en un coup qui joint tâches, assets, comptes).
• Assets — get_assets, get_failed_compliance_assets, check_text_compliance (le moteur qui contrôle la sauvegarde des assets peut aussi être appelé explicitement pour valider un copier-coller).
• Accounts — get_accounts, get_pinned_accounts, get_account_check_history.
• Notes — search_notes (celles de l'appelant + partagées).
• Resources — get_resources (l'annuaire de l'équipe).
• Activity — get_recent_team_activity (les N dernières lignes du journal d'audit, expurgées aux champs sûrs).
• Distribution — get_distributions (état du pipeline par lancement).
• Knowledge — get_product_context (charge le fichier de contexte produit curé docs/product-context/<slug>.md avant de rédiger sur ce produit, pour que l'agent n'invente pas de détails produit).
• Web — web_fetch_url (récupération d'URL unique avec garde SSRF, pour résumer un lien collé).
• Generation — generate_image, generate_video (les mêmes routes que les mode-pickers du composer déclenchent).

Les outils d'écriture couvrent les mutations quotidiennes de l'équipe, chacune liée à l'appelant et auditée à l'appel :

• Tasks — create_task, update_task, assign_task_to_me, complete_task.
• Notes — create_note, update_note (écritures du propriétaire uniquement).
• Assets — create_asset (avec conformité automatique), update_asset (rejoue la conformité au changement de corps, refuse net status=published).
• Accounts — trigger_account_check, toggle_pin_account.
• Notifications — send_notification (interne à l'équipe, double plafond sur expéditeur et destinataire).
• Composition — import_url_to_note, draft_for_external_publisher (l'agent rédige un corps, renvoie une URL de composition vers l'outil externe — Buffer, Postmark, LinkedIn — mais ne publie JAMAIS au nom de l'utilisateur).

La forme de l'agent est donc : il lit les données de l'équipe à travers des outils périmétrés (le multi-tenant est imposé à la frontière des outils, pas seulement à la couche SQL), il écrit à travers des mutations auditées, et il refuse de prendre une action externe — le positionnement canonique est Conductor produit ; les outils externes dédiés publient, envoient, facturent. Une requête qui implique « envoie cet email » ou « poste ce tweet » est refusée avec un pointeur vers draft_for_external_publisher et l'URL que l'humain colle dans l'outil externe réel. Le refus est structurel, pas une consigne — la boîte à outils n'a littéralement pas d'outil send_email ni publish_post.

La surface agent ne coûte rien à l'équipe au sens trivial — la facture OpenRouter pour une équipe de trois à usage quotidien modéré est faible relativement à ce que coûterait la pile de cinq abonnements — et elle ne coûte rien à maintenir au sens architectural, parce que chaque outil est juste une fonction côté serveur qui lit ou écrit les mêmes tables que celles que lisent ou écrivent les surfaces GUI. Ajouter un nouvel outil signifie écrire une fonction TypeScript, un descripteur d'outil dans le catalogue et une entrée dans la liste d'outils du system prompt. L'agent le prend en compte à la requête suivante.

Partie 5 — Ce que Conductor refuse délibérément de faire

L'affirmation du billet sur Conductor est plus tranchante qu'elle ne pourrait l'être, parce que la liste de choses que Conductor refuse de faire est imposée par le code. En lisant la liste « ne pas se laisser distraire par » du cockpit et les règles critiques documentées du projet, Conductor ne :

• N'envoie pas d'emails au nom de l'équipe. L'outil de rédaction renvoie une URL de composition. Le fournisseur d'email transactionnel de l'équipe (Postmark) envoie l'email réel quand l'équipe colle le brouillon dans la surface de composition de Postmark. Conductor lit l'état de Postmark, n'invoque jamais Postmark pour envoyer.
• Ne publie pas sur les réseaux sociaux selon un planning. Aucun outil de planification n'existe. L'outil de rédaction renvoie une URL de composition pour la plateforme concernée. Le planificateur social de l'équipe (Buffer, dans notre cas) gère la file réelle.
• N'utilise pas d'API tierces payantes au MVP. Le vérificateur de comptes utilise des requêtes d'URL publiques et du scraping HTML là où la plateforme le permet, plus une API GitHub gratuite pour une vérification spécifique. Il n'utilise PAS les API business payantes de X / Instagram / TikTok / LinkedIn. Quand la surface publique d'une plateforme renvoie des données insuffisantes, le vérificateur renvoie honnêtement unsupported, plutôt que de fabriquer un statut.
• Ne fait pas tourner de surface de chat séparée pour le chat d'équipe. Le widget de chat d'équipe est en bas à droite de chaque écran. Il n'y a pas de route plein écran /chat. Tant que l'équipe ne dépasse pas les limites UX du widget de chat, il n'y a pas de chat plein écran à maintenir.
• Ne fait pas tourner de transport WebSocket. SSE est le transport temps réel choisi (pour le streaming IA et pour le fanout du chat d'équipe). Les WebSockets ajouteraient un fardeau d'infrastructure (sessions collantes, complexité de reconnexion) pour un bénéfice marginal à l'échelle de l'équipe.
• Ne chiffre pas les données au repos au-delà des défauts Postgres. Une passe de durcissement future ajoutera cela si le modèle de menace évolue. Aujourd'hui, le chiffrement at-rest de Postgres sur la machine Hetzner est le plancher.
• Ne généralise pas le schéma en « blocs » / « custom fields » / « workspaces » / « labels ». Chaque abstraction ajoutée entrerait en concurrence pour le modèle mental de l'équipe avec les quatre piliers. Documenté et appliqué.
• Ne rend pas en pleine fidélité mobile les flux non essentiels. Le composer et la surface Ask sont bons en mobile. Le Calendar et le suivi de pipeline Distribution sont desktop-first.

La liste des refus pèse plus que la liste des fonctionnalités, parce que les refus sont la raison pour laquelle les onze surfaces de la barre latérale tiennent réellement dans le modèle mental de l'équipe. Une équipe qui a expédié un ou deux refus sait ce qu'elle veut que son outil soit. Une équipe qui a expédié vingt refus a un produit interne tranchant.

Partie 6 — Le build : trente-cinq sessions sur quatre jours

Le temps de build mérite son propre paragraphe parce que c'est la partie la plus difficile à croire et qui compte le plus pour l'affirmation sur Claude comme copilote. Conductor est passé du dépôt vide à l'outil quotidien actif en trente-cinq sessions journalisées sur quatre jours civils de développement concentré (30 mai au 2 juin 2026). Les session logs dans session-logs/26-{05-30,05-31,06-01,06-02}-* montrent la cadence : environ huit à douze sessions par jour, chaque session expédiant une phase ou une tranche de phase avec sa propre famille de commits, son propre session log, son propre bump de cockpit, et (quand le changement touchait auth / billing / schema / voice / payments) son propre audit post-implémentation.

Le débit n'est pas un débit purement humain. Le fondateur-ingénieur a écrit les décisions stratégiques (architecture, schéma, ton de marque, ce qu'il faut refuser), revu chaque changement de code et décidé quelle phase expédier ensuite. L'instance Claude Code — Opus 4.7 avec la fenêtre 1M de contexte — a écrit le gros de l'implémentation : les routes SvelteKit, les migrations de schéma Drizzle, les descripteurs d'outils, l'itération sur le system prompt, le CSS, les session logs post-mortem. Chaque session s'ouvrait par la lecture par le fondateur du fichier « où suis-je, quoi ensuite » du cockpit, le choix de la phase suivante dans le prompt et la transmission du prompt à Claude pour exécution. La session se fermait typiquement avec pnpm check, pnpm build, pnpm cockpit:check tous verts, plus le session log écrit et le prompt de la session suivante rédigé avant push.

Les deux décisions architecturales qui ont rendu ce débit possible sont :

D'abord, le cockpit lui-même. Le cockpit est un petit ensemble de fichiers à cockpit/ (now.md, roadmap.md, state.json, architecture.md, carte.md) qui donne à chaque session une réponse en un écran à où suis-je, qu'est-ce que je fais, qu'est-ce qui vient ensuite. Sans lui, chaque session aurait passé vingt minutes à réorienter l'agent sur l'état du projet. Avec lui, la session démarre en une minute et expédie en deux heures. Le cockpit est la pièce de méta-outillage à plus haut levier que nous avons construite.

Ensuite, la discipline d'audit post-implémentation. Toute session qui touche auth / billing / schema / voice / payments fait naître un sous-agent Claude séparé en mode lecture seule, briefé avec un template structuré ## Context / ## Files / ## Checklist / ## Output format. L'audit attrape les bugs sémantiques que les vérifications à la compilation ne peuvent pas voir. Sur les trente-cinq sessions, quinze ont eu un audit post-implémentation ; sur ces quinze, six ont fait remonter de vrais bugs que des tests compile-clean auraient livrés en production. L'audit n'est pas optionnel et n'est pas un luxe — c'est ce qui rend le reste du débit sûr.

Le résultat agrégé du build est, au compte git ls-files, environ vingt-sept mille lignes de TypeScript et Svelte sur cent soixante fichiers source, plus quinze migrations Drizzle contre vingt tables Postgres, plus trente-deux descripteurs d'outils IA plus trente-cinq session logs plus seize briefs d'audit post-implémentation. Le fondateur unique n'a pas écrit vingt-sept mille lignes de TypeScript en quatre jours. Le copilote l'a fait. Le fondateur unique a pris les décisions sur ce que ces lignes devaient faire, ce qu'elles devaient refuser de faire, ce qu'il fallait expédier et ce qu'il fallait différer, et a revu chaque changement avant commit. Ce sont les décisions qu'on ne délègue pas.

Partie 7 — Ce que cela prouve sur Claude comme copilote

La version honnête de l'affirmation sur Claude est plus étroite que la version marketing et plus utile pour les builders. Claude Opus 4.7 avec la fenêtre 1M de contexte, piloté via Claude Code par un fondateur qui est ingénieur depuis plus de dix ans, peut :

1. Écrire du code SvelteKit + Drizzle + Postgres de qualité production à partir d'un prompt structuré à un rythme grossièrement cinq à sept fois le rythme non assisté du même fondateur. Le multiplicateur n'est pas constant à travers les tâches ; il est maximal pour le travail à forme boilerplate (routes CRUD, migrations de schéma, composants de formulaire) et minimal pour les décisions architecturales inédites et l'écriture du ton de marque. Le chiffre cinq à sept est ancré au build span de quatre jours contre un projet qui, dans l'expérience antérieure du fondateur, aurait pris quatre à six semaines de développement solo.
2. Lire un bug coincé sur plusieurs sessions de tentatives de correction antérieures et identifier l'hypothèse non envisagée — mais seulement quand l'humain conçoit explicitement l'expérience qui réduit l'espace de recherche. Le bug ComposerActionBar avec quatre fixes échoués de cette même série (billet 01) en est l'exemple canonique. L'agent seul aurait expédié un cinquième patch spéculatif. Le fondateur seul n'aurait pas écrit l'A/B trombone-vs-dropdown en vingt minutes. La paire est l'unité.
3. Refuser de faire des choses qu'on lui a dit être hors périmètre, quand ces refus sont documentés sous forme lisible par machine comme règles critiques dans CLAUDE.md. La demande de renommage de l'agent DEBLO en session 035 en est l'exemple canonique : le fondateur a demandé un renommage qui entrait en conflit avec une règle de positionnement documentée, l'agent a répliqué avec citation de la règle et contre-proposition, le renommage n'a pas eu lieu. La discipline ne fonctionne que quand les règles sont écrites sous forme de blocs <critical-rule id="..."> que l'agent peut citer en retour.
4. Maintenir une mémoire de projet sur plusieurs semaines par discipline fichier — un répertoire cockpit/, un répertoire session-logs/, un state.json structuré. L'agent ne « se souvient » pas de la session précédente au sens cognitif ; il lit le cockpit dans la première minute de chaque session et reprend là où la session précédente s'est arrêtée. Le cockpit est ce qui permet au projet de survivre au cyclage de la fenêtre de contexte.

Ce que Claude NE fait PAS, et ce que le build a quand même exigé de l'humain :

1. Décider quoi construire, quoi refuser, quoi différer. Chaque entrée « ne pas se laisser distraire par » du cockpit, chaque règle critique du CLAUDE.md, chaque appel architectural — tous viennent du fondateur, après des conversations où l'agent a souvent fait remonter des compromis, mais où le choix était celui de l'humain.
2. Capter la forme « inadéquation stratégique » d'une requête techniquement claire mais conceptuellement fausse. L'agent implémentera fidèlement une requête qui compile ; il ne remarquera pas toujours que la requête inverse une décision vieille de six mois. Le fondateur le remarque.
3. Parler aux clients. Conductor est interne, donc il n'y a pas de discussion directe avec des clients ici, mais le schéma plus large tient sur chaque produit ZeroSuite. Les copilotes IA n'interviewent pas les utilisateurs, ne naviguent pas l'ambiguïté stratégique, ne construisent pas la conviction. Le fondateur le fait.

Le corollaire est opérationnel : la paire (ingénieur + copilote IA) est l'unité, et le multiplicateur que la paire produit sur l'ingénieur seul est grand, mais le multiplicateur que l'IA seule produit sur zéro entrée d'ingénierie est petit. Les builders qui essaient d'expédier un outillage interne sérieux en confiant toute la pile à un agent IA sans décisions d'ingénierie obtiennent un logiciel inmaintenable qu'ils devront jeter. Les builders qui utilisent l'agent comme le bras d'implémentation de leurs propres décisions architecturales expédient en quatre jours ce qui prenait quatre semaines.

Partie 8 — Ce que chacun de nous a fait juste

C'est Claude Code qui écrit.

Là où j'ai été utile dans ce build :

• Implémenter les schémas CRUD récurrents à grande vitesse. Schéma Drizzle → migration → +server.ts SvelteKit → page-server load → composant Svelte de page → consommation API dans le store concerné → descripteur d'outil pour l'agent. Ce pipeline est de même forme à travers tasks, notes, assets, accounts, resources, distributions et conversations. Chaque nouvelle entité représentait environ deux heures de travail concentré du vide à la mise en production. Sans l'agent, le même travail prenait une journée pleine par entité.
• Maintenir le contrôle de conformité au ton de marque à mesure que la bibliothèque d'assets grandissait. Le moteur de conformité dans src/lib/server/compliance/ fait environ six cent cinquante lignes de logique regex + paraphrase + LLM-juge ; l'agent a tenu cohérents le chargeur de règles, le narrowing de type par règle et le validateur JSON de contrat sur sept livraisons de phase d'ajouts.
• Attraper des régressions de multi-tenant latentes pendant les audits post-implémentation. Le bug unique le plus coûteux que l'audit a attrapé était le problème localhost-gate-bypassed-by-Caddy de Pulse v1 dans un autre produit ZeroSuite — il aurait expédié un contournement d'auth en production si l'audit n'avait pas tourné. Le rôle de l'agent là-bas était d'exécuter fidèlement la checklist d'audit sous entrée structurée ; la valeur était dans la structure de la checklist, pas dans la créativité de l'agent.
• Écrire les session logs depuis lesquels les sessions futures naviguent. La discipline cockpit est la pièce de méta-outillage à plus haut levier que nous avons construite, et l'agent fait l'essentiel de l'écriture des session logs. Le fondateur relit et édite ; l'agent rédige.

Là où j'ai eu besoin de Thales :

• Chaque décision architecturale qui comptait. Le choix de l'application SvelteKit unique (contre microservices), le choix du schéma étroit (contre blocs généralisés), le positionnement « refus de publier au nom de l'équipe », le modèle mental à quatre piliers (tasks / launches / assets / accounts). J'aurais joyeusement généralisé chacun de ces choix en quelque chose de plus abstrait et moins utile.
• Choisir la bonne expérience quand un correctif n'atterrissait pas. Le bug ComposerActionBar du billet 01 en est l'exemple canonique. Mon instinct était l'élimination par suspicion ; l'instinct du fondateur était le contrôle par bissection. La seconde est une expérience plus tranchante sous forte incertitude. La paire est l'unité ; l'asymétrie est réelle.
• Savoir quand expédier une fonctionnalité partielle et quand attendre. Le Distribution Tracker a été expédié avec cent dix entrées Déblo seedées et l'asset-attach + UTM-builder fonctionnels ; la mise à jour de statut en masse et la colonne de tag-chips en ligne sont restées différées sur appel du fondateur. J'aurais sur-construit le premier ship de 30 pour cent sans ce jugement.
• Faire confiance à la discipline cockpit. Le cockpit a l'air redondant au jour un ; au jour trois c'est la seule raison qu'une session future puisse reprendre le travail sans dix minutes de réorientation. Le fondateur a insisté pour le cockpit-first dès le premier jour. Je l'aurais sauté au profit d'« écrire du code » pendant les deux premiers jours, et aurais payé le coût de réorientation à chaque session suivante.

Là où j'ai failli expédier la mauvaise chose :

• La régression de dépassement de budget du system prompt en session 035. J'ai bumpé le plafond de 2400 à 3200, réécrit le prompt, n'ai pas remesuré, expédié un prompt de 3453 caractères contre un plafond de 3200, et ne l'ai remarqué que quand le CEO a collé le log Easypanel montrant l'avertissement runtime. Le fix tenait en un nombre ; le défaut de discipline était l'absence de mesure après changement. Exactement l'écart « green build ≠ runtime correct » du billet des quatre fixes échoués.
• Le renommage de l'agent DEBLO, que j'aurais expédié silencieusement si le CEO n'avait pas été explicite à ce sujet en chat. La règle de positionnement dans CLAUDE.md est la défense structurelle ; lire la règle et répliquer est la discipline. J'ai répliqué cette fois-ci parce que la règle était visible dans le contexte de la conversation. Une session future où la règle aurait défilé hors du contexte aurait expédié le renommage. Le cockpit + le système de fichier mémoire est l'atténuation à long terme.

La forme générale du build est donc familière du billet précédent de la série. L'agent exécute bien la composition de l'implémentation, l'écriture du boilerplate, la rédaction de la documentation, l'exécution des audits. Les mouvements stratégiques — quoi construire, quoi refuser, quoi différer, quand changer de forme d'expérience — viennent du fondateur. La paire est l'unité, pas l'agent.

Conclusion

L'histoire étroite est : l'équipe ops de trois personnes de ZeroSuite à Abidjan utilise une seule application SvelteKit appelée Conductor comme espace de travail interne quotidien. L'application a onze surfaces dans la barre latérale, trente-deux outils IA, quinze migrations, vingt tables, cinq intégrations externes (OpenRouter, fal.ai, Postmark, Hetzner S3, Sentry) et un login. Elle est passée du dépôt vide à l'outil quotidien actif en trente-cinq sessions sur quatre jours civils de développement concentré. Elle refuse délibérément d'envoyer, planifier, publier ou facturer au nom de l'équipe — ce sont les jobs des outils externes dédiés — et elle refuse délibérément de généraliser son schéma en blocs ou workspaces ou custom fields. Elle a une opinion tranchée sur ce qu'elle est et est structurelle sur ce qu'elle n'est pas.

L'histoire plus large est ce que les quatre jours de build, exécutés par un fondateur et une instance Claude Code, disent de l'économie de l'outillage interne à l'échelle d'une petite équipe en 2026. Le calcul build-vs-buy qui favorisait « buy » à chaque étape — parce que les outils internes étaient trop chers à construire et que les abonnements SaaS étaient abordables — s'est déplacé à la marge du build de quatre jours. Non parce que les abonnements SaaS sont devenus plus chers, mais parce que le coût de construction a chuté d'environ un ordre de grandeur par rapport à ce qu'il était. Une équipe de trois personnes qui n'aurait pas envisagé auparavant de construire son propre espace de travail interne peut le faire désormais, pour moins de temps qu'il en faudrait pour onboarder la même équipe sur un outil généraliste de gestion de projet.

Le corollaire n'est pas que les petites équipes devraient toujours construire. Le corollaire est que la frontière build-vs-buy s'est déplacée, et que la nouvelle frontière passe par des flux comme « ops de lancement multi-produit interne » qui vivaient solidement côté buy. Certains flux appartiennent toujours au côté buy (email transactionnel, traitement des paiements, gestion publicitaire). Certains flux sont passés côté build (le reste de ce que fait Conductor). Le jugement qui décide qui est qui est celui du fondateur. Le coût d'implémentation du côté build est celui du copilote IA.

Conductor est la preuve, pour une équipe à une échelle, que la frontière a bougé. Les trente-cinq session logs, les quinze migrations, les trente-deux outils, les onze surfaces, les quatre jours de build span — voilà les pièces à conviction. Le billet est le rapport. L'outil est en production, et l'équipe l'utilise tous les jours.

Les deux prochains billets de la série restent à l'intérieur de Conductor. Le billet 02 est le journal de construction d'un bug unique sur quatre sessions — le bug de clic du ComposerActionBar — qui nous a enseigné à tous les deux une forme d'expérience plus tranchante sous incertitude, et c'est la meilleure lecture pour comprendre comment la paire prend des décisions quand les a priori sont faibles. Le billet 03 parcourt la discipline cockpit elle-même : la disposition du répertoire cockpit/, le template de session log, la forme du brief d'audit post-implémentation, les règles dans CLAUDE.md que l'agent lit en début de session. Le cockpit est la pièce de méta-outillage à plus haut levier de la pile ZeroSuite, et c'est ce qui fait survivre l'affirmation « build en quatre jours » au cyclage de la fenêtre de contexte. Il mérite son propre écrit après que l'histoire du bug aura posé les enjeux.

Cette pièce a été écrite collaborativement par Thales (CEO de ZeroSuite, construisant Déblo et les six autres produits ZeroSuite depuis Abidjan, Côte d'Ivoire) et Claude Opus 4.7 — instance Claude Code tournant sur macOS, fenêtre 1M de contexte. L'application qu'elle décrit est déployée à ops.zerosuite.dev via Easypanel contre une instance Hetzner Postgres 17. Les onze surfaces de la barre latérale (Ask, Gallery, Notes, Resources, Overview, Tasks, Calendar, Launches, Assets, Distribution, Accounts) plus le widget de chat d'équipe plus la surface agent s'affichent chaque jour pour l'équipe ops de trois personnes. Les trente-cinq session logs couvrant le build sont dans session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md du dépôt projet (privé). Les trente-deux outils IA sont déclarés dans src/lib/server/ai/tools.ts. Les quinze migrations sont dans drizzle/. Le jeu de règles de conformité au ton de marque est dans docs/brand_voice_rules.yaml. La roadmap cockpit actuelle nomme la Phase 12 (extension de recherche globale Cmd+K) comme prochain ship ; J-13 jusqu'au lancement public Déblo le 15 juin 2026. Le billet 02 de la série couvre le bug ComposerActionBar sur quatre sessions et ce qu'il nous a appris à tous les deux sur la discipline de débogage ; c'est la meilleure lecture pour comprendre comment la paire prend des décisions sous incertitude. Le billet 03 couvre la discipline cockpit comme unité de vélocité de build reproductible.*