Freelance, disponible dès maintenant Paris, remote ou hybride
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.
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.
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.
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
État
Critère de fin
1
Session d’agent
Tenue
Une vraie session suivie en direct, interrompue pendant un appel d’outil, puis reprise
2
État et file
Tenue
Tuer la tour au milieu d’un run puis la relancer ne perd ni ne double rien
3
Worker isolé
En partie
Deux lots en parallèle, chacun avec sa base, sans collision
4
Réseau et secrets
À venir
Un run réel sans aucun secret dans le conteneur ; un hôte non autorisé est refusé et journalisé
5
Git et merge
En partie
Trois lots enchaînés et mergés sans intervention
6
Vérification
En partie
Un lot piégé (test modifié, fichier réservé touché) est bloqué avec la bonne raison
7
Humain dans la boucle
À venir
Un blocage réel répondu depuis le téléphone
8
Providers et coûts
Préparée
Un même lot lancé sur deux providers, coûts et durées comparés
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.
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
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.