Samuel Négrit · développeur senior fullstack TypeScript

Projets

Je construis des produits web en TypeScript, et les outils qui me permettent de développer avec des agents sans perdre le contrôle de ce qu’ils produisent.

ou touche P

  • 8 ans de web, dont 6 en freelance
  • Vue 3, Nuxt, React
  • NestJS, PostgreSQL
  • Kotlin / Spring en maintenance

01. Le pilote : un harness pour développer avec des agents

En usage Orchestrateur maison de sessions Claude Code

Un agent produit vite du code qu’on ne contrôle pas, et il peut « réussir » de travers : modifier un test au lieu de corriger le code. Le pilote enchaîne les sessions par lots et vérifie, sans faire confiance à l’agent, que rien n’a été contourné.

Comment il fonctionne

  • Tout part de la spec. J’écris avec Claude des specs qui posent les invariants fonctionnels et de sécurité. C’est là que je mets le plus de temps humain.
  • Un lot, quatre phases, quatre sessions vierges : exploration, plan, tests, implémentation. Un contexte qui s’allonge dégrade les décisions suivantes.
  • Les tests sont gelés une fois validés. Deux barrières déterministes, et aucune ne dépend de la bonne volonté de l’agent.
  • Seul le pilote autorise une exception, à partir de ma réponse à un blocage. Une session ne peut pas s’écrire d’autorisation.
  • En sortie : deux revues indépendantes, une PR, un merge sur la branche de dev uniquement. Les agents alimentent un backlog et proposent des évolutions du harness.
Spec avec invariantsfonctionnels et sécurité,challengés avec ClaudeDécoupage en lotsun fichier de changement par lotFile de lotsqui gère les dépendancesExplorationPlanTestsGel des testsempreinte stockéeImplémentationChaque phase tourne dans une session vierge.Barrière 1, pendantécriture sur un test gelé bloquéepar les hooks, sauf fichier de laliste ouverteBarrière 2, fin de lotchaque test gelé comparé à l’état dudépôt (HEAD)Blocage si écartle lot s’arrête, la décision meremonteAutorisationécrite par le pilote seul, depuis maréponse (chaîne attendue)le fichier rejoint la liste ouverteconforme2 revues indépendantesPR, puis mergesur la branche de dev, jamais enprodCapitalisationbacklog, évolutions du harness,décisions tracéesAvant chaque session, le pilote sauvegarde son état, les empreintes et la liste ouverte.
HumainAgent, en session viergeContrôle déterministeLivraison et capitalisation

Ce que ça coûte, mesuré sur mes lots

12,51 $
par lot en moyenne (médiane 12,19 $)
4 à 22 $
selon le lot (4,24 $ à 21,79 $)
1,8
session par lot en moyenne
45 min
d’exécution cumulée par lot

La revue par agent dans la CI coûte aussi : elle a consommé mon quota de CI en deux jours. Je la réserve aux lots qui la justifient.

Ses limites, telles que je les vois

  • Il dépend de mon Mac (veille, Docker Desktop, authentification locale).
  • Il ne connaît qu’un projet : ses conventions sont écrites en dur.
  • Il ne lance qu’un run à la fois, sur une base et des serveurs partagés.
  • On ne lui parle qu’entre deux sessions, par des réponses à la formulation exacte.
  • Les garde-fous attrapent les contournements que j’ai prévus, pas tous. Et il n’a pas encore été éprouvé en équipe.

Origine : chez Hopper, j’avais présenté à l’équipe mon workflow de l’époque. Un développeur l’a repris : bien meilleurs résultats qu’en promptant directement, mais une forte consommation de tokens.

02. Une plateforme edtech en couches

En production Depuis février 2022 · Vue 3, TypeScript, Pinia, Kotlin / Spring

Une plateforme e-learning déployée en classes réelles, construite en binôme : une application pour les élèves, pensée pour le mobile et le hors connexion, et une application d’administration pour les encadrants.

Les choix d’architecture

  • Front en architecture hexagonale, co-conçue en binôme. Le métier est isolé derrière des ports, un cas d’usage par classe, et les vues ne connaissent jamais le client HTTP.
  • Un compromis assumé. J’ai contesté le coût d’une migration complète : à deux, il fallait continuer à livrer. On a gardé le principe de séparation sans viser l’architecture parfaite d’un coup.
  • Back Kotlin / Spring en Clean Architecture, que je maintiens et fais évoluer. Les couches sont imposées au build par un checker Gradle.
  • Un design system partagé entre les deux applications, construit sur une librairie de composants avec une couche de tokens au-dessus.
  • Une synchronisation hors connexion, pour tenir en classe avec un réseau instable.
Front Vue 3 (deux applications)Vues, stores Pinia, adaptateurs API (Zod)Cas d’usageDomaineentités et portsles vues ne connaissent jamais le client HTTPBack Kotlin / SpringContrôleurs, configuration, adaptateurs DBCas d’usageDomaineentités et portscouches vérifiées au build par un checker Gradledépendancesvers le centre

Ce que j’améliorerais aujourd’hui

  • Côté front, des cas d’usage souvent passe-plats.
  • La validation des données rangée dans l’infrastructure plutôt que dans le domaine.
  • Aucun contrôle automatique des couches côté front : le respect repose sur la revue.

03. La tour de contrôle des pilotes

En construction · 2 briques sur 8 tenues, 3 en partie Vision écrite le 30 septembre 2026 · état au 8 octobre 2026

La suite du pilote : suivre et piloter, depuis un seul endroit en ligne, les runs de plusieurs projets, de l’idée jusqu’au merge. La tour décide et montre, des workers exécutent chaque run dans un environnement jetable, et les décisions qui engagent restent humaines.

Déjà levé par rapport au pilote : elle ne code plus rien en dur pour un projet, et les lots tournent en parallèle, chacun avec son worktree et ses ports.

Tour de contrôledécide et montre : projets,file de lots, suivi en direct,blocages, coûtsordresévénementsWorker (VPS), un environnement jetable par runSession d’agentClaude Code, suivie en directPile Docker du projetbase, API, front propres au runProxy sortantinjecte les secrets, refuse le resteGitHubbranche, PR, CI, file demerge vers developMoi, aux portes : valider le changement, répondre aux blocages, passer sur main

Les principes

  • Isolation : un run ne voit ni la base, ni les serveurs, ni les fichiers d’un autre run.
  • Pas de secret dans le conteneur : un proxy les injecte à la sortie, le reste du réseau est fermé.
  • Un seul écrivain par ressource : le worker d’un run est seul sur sa branche, la file de merge est seule à merger.
  • Un manifeste versionné par dépôt : la tour ne code rien en dur pour un projet.
  • Des agents interchangeables : un port Agent, Claude Code d’abord, d’autres agents ensuite par adaptateur.
  • Mesurer avant d’augmenter : lots mergés par semaine, taux de reprise, temps de revue, coût par lot. Deux ou trois runs simultanés au départ.

Construire pour comprendre

Je la construis brique par brique, d’abord en version simple, puis je compare avec les projets existants. Chaque brique remplace une part du pilote quand elle fait mieux.

N°BriqueÉtatCritère de fin
1Session d’agentTenueUne vraie session suivie en direct, interrompue pendant un appel d’outil, puis reprise
2État et fileTenueTuer la tour au milieu d’un run puis la relancer ne perd ni ne double rien
3Worker isoléEn partieDeux lots en parallèle, chacun avec sa base, sans collision
4Réseau et secretsÀ venirUn run réel sans aucun secret dans le conteneur ; un hôte non autorisé est refusé et journalisé
5Git et mergeEn partieTrois lots enchaînés et mergés sans intervention
6VérificationEn partieUn lot piégé (test modifié, fichier réservé touché) est bloqué avec la bonne raison
7Humain dans la boucleÀ venirUn blocage réel répondu depuis le téléphone
8Providers et coûtsPréparéeUn même lot lancé sur deux providers, coûts et durées comparés

04. Deux SaaS cofondés

Arrêtés 2021 à 2022 · Vue 2, Nuxt, NestJS, TypeORM, PostgreSQL, Docker

Deux produits menés de l’idée à la production, de bout en bout : conception, développement, lancement, relation avec les utilisateurs. Même socle pour les deux : une application Vue, une API NestJS sur PostgreSQL, un site vitrine Nuxt, le tout conteneurisé et déployé par une CI GitLab, avec staging et production séparés.

Tableau de bord d’Analytics4Notion : menu des statistiques et courbe des utilisateurs et nouveaux utilisateurs sur quatre jours.

Analytics4Notion

Des statistiques d’audience pour les espaces Notion : pages consultées, lecteurs, localisation, présence en temps réel, carte visuelle de l’espace. Branché sur l’API Notion, installé en moins d’une minute.

3ᵉ produit du jour sur Product Hunt.

  • Vue 2
  • NestJS
  • API Notion
  • PostgreSQL
Éditeur d’espace de Toolzgather : plan des sections à gauche, sections Juridique et Les outils avec leurs documents.

Toolzgather

Un outil collaboratif pour créer et partager des supports digitaux, pensé pour intégrer des collaborateurs et livrer aux clients : espaces, tableaux, modèles, membres et rôles, abonnements.

Plusieurs centaines d’utilisateurs.

  • Vue 2
  • NestJS
  • Stripe
  • S3
  • PostgreSQL

© 2026 Samuel Négrit. TIGREN EURL, SIREN 982 661 613, La Roche-sur-Yon.

Mentions légales