République
Française
Administration+
cinq mois plus tard
En mai, j'avais refondu Administration+ avec Claude Code dans un terminal. Six mois après, le même dépôt se développe d'une tout autre façon.
Les outils, les agents, le chemin d'un ticket · et ce qui guide mes choix
Un dev, un service public, une refonte complète livrée en mai
Charles d'Oiron
- Full-stack depuis plus de dix ans, passé par le design
- Troisième mission chez beta.gouv.fr, après Recosanté et Toutes et tous connecté.e.s
- Seul développeur sur Administration+, avec une équipe produit
Administration+ · aplus.beta.gouv.fr
- Service public qui débloque les situations administratives complexes ou urgentes
- Des aidants signalent un cas, des opérateurs (CAF, CPAM, DGFIP…) y répondent
- Refonte complète d'une app Scala en Next.js + TypeScript, onze mois, livrée en mai 2026
9 ans
d'existence, lancé en décembre 2017 à Argenteuil
±150 000
signalements traités par an, un message toutes les 10 secondes
9 027
utilisateurs actifs : 5 977 aidants, 3 050 opérateurs, 9 opérateurs partenaires
79 %
des blocages résolus en moins de 7 jours
En mai, j'ai raconté cette refonte à d'autres développeurs. Ce talk commence là où celui-là s'arrêtait.
« 11 mois de refonte, un dev + Claude Code »
- Pourquoi et comment on a réécrit Administration+ de zéro
- Repartir du besoin, migrer les données, générer les tests
- Ma stack de l'époque : Cursor, Claude Code, trois MCP
Ce talk
- Le dépôt a grossi de moitié depuis, en production, avec la même équipe
- Comment je travaille dessus aujourd'hui : outils, agents, chemin d'un ticket
- Ce qui guide mes choix depuis mai
+1 M
de lignes migrées, neuf ans d'historique, rien de perdu
70 000
fichiers migrés d'un hébergeur à l'autre
15 000
comptes repris, cinq rôles, permissions conservées
< 20 min
de bascule en production, quasiment sans coupure
Le talk de mai est disponible sur demande. Ici, on part du dépôt tel qu'il était en mai, et on regarde comment il avance depuis.
30 minutes
Depuis mai, je ne pilote plus des terminaux, je pilote un système
01 · Depuis mai
Le même dépôt, le même dev, plus du tout la même journée
- Cursor + Claude Code dans le terminal, Opus 4.6 puis 4.7
- 2-3 terminaux ouverts, que je surveille
- Je lis le ticket, je prompte, je vérifie, j'ouvre la MR
- Rien ne se passe quand l'ordinateur est fermé
- T3 Code + Opus 5.5, sur le Mac et sur un VPS 24 h/24
- Des agents qui trient, codent, vérifient, rendent compte
- Chaque matin à 8 h, une MR par ticket prêt, à relire
- Les tickets viennent de l'équipe produit ou d'Alix, le tri est à Olga. Il me reste un geste : relire et fusionner
L'idée du talk : je délègue aux agents tout le chemin du ticket à la MR, et je ne garde que la décision. Ça tient parce que les règles vivent dans le code, pas dans mes consignes.
01 · Depuis mai
Le dépôt a grossi de moitié en cinq mois, et le ratio tests/code a tenu
| Mai 2026 · fin de refonte | Octobre 2026 | ||
|---|---|---|---|
| Lignes de code | 41 k | 65 k | +58 % |
| Lignes de tests | 46 k | 71 k | toujours plus de tests que de code |
| Cas de test | 1 838 | 3 156 | 269 fichiers .spec |
| Procédures tRPC | 81 · 10 routeurs | ~120 · 17 routeurs | chaque routeur a son spec |
| Pages | 28 | 38 | |
| Commits | 1 123 depuis mai 2025 | ||
Snapshot develop · octobre 2026 · périmètre src/ hors generated/
Un seul outil, deux machines, et un agent qui tient le serveur
02 · Le poste de pilotage
T3 Code sur le Mac et sur un VPS : les mêmes conversations, de partout
Mon Mac
T3 Code + Opus 5.5. Quand je suis au bureau, je travaille avec les agents en direct.
Un VPS Hetzner, allumé 24 h/24
T3 Code + Opus 5.5, les mêmes threads. Je lance une modification ou je suis un agent depuis n'importe où, téléphone compris.
Les tâches planifiées y tournent, Mac fermé : le tri du soir et le batch du matin.
T3 Code, c'est quoi
Un orchestrateur au-dessus de Claude Code : des threads, un worktree git par thread, des tâches planifiées, et un MCP pour que les agents se lancent entre eux. Je ne tape plus dans un terminal, je relis des conversations.
02 · Le poste de pilotage
Je ne fais pas d'administration système : Hermes s'en charge
Hermes est un agent dédié au serveur. Il ne touche jamais au code métier.
- Il installe, répare, surveille : dépendances, accès git, mémoire, services
- Un agent bloqué par l'environnement l'appelle :
hermes-ask "l'erreur exacte". Hermes agit, répond, l'agent reprend - Il surveille T3 et me prévient sur Telegram
Les règles du serveur, écrites une fois
Un CLAUDE.md global sur le VPS : tous les agents, tous les dépôts. Les hooks git y sont désactivés, la CI est le juge final.
Un agent bloqué n'attend pas que je sois là : il demande à Hermes.
Les agents ont les mêmes sources que moi, et une méthode écrite
03 · Les outils
Quatre MCP pour lire, quatre CLI pour agir : les trois MCP de mai, plus tout ce qui agit
| Outil | Ce que l'agent y fait | Depuis |
|---|---|---|
| MCP Notion | lit le ticket, les retours « À traiter », les priorités, les décisions | |
| MCP Figma | lit la maquette liée au ticket, en sort le markup DSFR | |
| MCP Sentry | lit les erreurs de production, remonte à la cause | |
| MCP t3-code | lance des threads, planifie des tâches, délègue à d'autres agents | |
glab | ouvre la MR, lit la CI, répond aux commentaires | |
olga-notion | écrit dans Notion sous l'identité d'Olga, jamais sous la mienne | |
agent-browser | pilote un vrai navigateur pour vérifier un parcours | |
hermes-ask | demande de l'aide sur l'environnement |
03 · Les outils
CLAUDE.md dit ce qui ne se lit pas dans le code, et rien d'autre
En mai : 9 sections, un guide complet. En octobre, il a maigri. Tout inventaire a été retiré : il pointe vers la source.
- Le dépôt est public : ce qu'on ne nomme jamais, ce qu'on ne publie jamais
- La prod ne se touche pas sans accord, même en lecture
- Le service, en un paragraphe, avec le vocabulaire du domaine
- tRPC : précharger puis hydrater, et l'anti-pattern à ne pas faire
- Les conventions :
function,interface, jamaisany - Prouver avant de dire que c'est fait
La règle qui l'a fait maigrir
« Pour tout inventaire, lire la source plutôt que ce fichier. » Les routeurs sont dans _app.ts, les utilitaires dans src/utils/, les factories dans src/test/mocks/.
Une liste dans CLAUDE.md est fausse au bout de deux semaines. Un pointeur ne l'est jamais.
03 · Les outils
pstack donne une méthode à l'agent, et choisit le modèle selon la tâche
pstack est le plugin Claude Code de Lauren Tan. À chaque session, il injecte une règle de tri :
- Tâche simple (un fichier, une question) : l'agent la fait, puis vérifie sur l'artefact réel
- Plusieurs fichiers, un choix de conception, un bug sans cause connue : il entre en poteto-mode et suit un playbook : bug, feature, refactoring, enquête, prototype
- Gros chantier : il conçoit sa propre démarche, avec un journal des décisions
Le modèle selon le rôle
Feature et refactoring : Opus. Bug, perf, décision dure : Fable. Mécanique triviale : un modèle rapide.
Décision contestée : quatre modèles en débat (Opus, Fable, Sonnet, Haiku), puis synthèse.
La règle que je préfère
Un agent ne compte jamais sa propre relecture comme une validation. Sans relecteur indépendant, la MR reste bloquée.
03 · Les outils
Sept skills dans le dépôt : des procédures que l'agent suit, versionnées avec le code
| Skill | Ce qu'elle fait |
|---|---|
| notion-issue | prend un ticket Notion : lit les retours, la maquette Figma, implémente, teste, vérifie dans le navigateur |
| verify-aplus | lance l'app, connecte un compte de test, rejoue le parcours dans un vrai navigateur, garde les captures |
| sync-verify-cards | chaque soir, détecte ce que les commits ont changé dans les parcours et prépare les corrections de la carte |
| sentry-issues | liste et analyse les erreurs de production |
| compare-branches | compare develop et main, écrit le changelog pour l'équipe |
| explain-to-pm | explique un bug ou un choix technique en langage produit |
| react-best-practices | les règles de performance de Vercel, versionnées pour que tout le monde les ait |
Une skill est un dossier Markdown plus des scripts, dans .claude/skills/. Elle part dans le dépôt public, donc elle est relue comme du code.
Quatre agents, chacun avec un rôle étroit, et un orchestrateur
04 · Les agents
Chaque agent fait une chose, sous son propre nom, pour qu'on sache toujours qui a fait quoi
Olga
Tâche planifiée. À 18 h elle trie le backlog. Après le batch elle rend compte sur chaque ticket. Elle écrit sous sa propre identité.
Hermes
Tient le serveur. Débloque les agents qui butent sur l'environnement. Me prévient sur Telegram.
CodeRabbit
Relit chaque MR, en français, avant moi. L'agent qui a écrit le code lui répond.
L'orchestrateur : Claude Code dans T3 Code
Celui qui écrit le code, un thread par ticket, un worktree par thread. T3 lance les threads, planifie Olga, et fait tourner les batchs. C'est lui qu'on suit dans la partie suivante.
Et en arrière-plan, Renovate propose les mises à jour de dépendances, sans jamais fusionner seul.
Un ticket devient une MR prête à relire entre deux journées de travail
05 · Le chemin d'un ticket
De Mattermost à la production, en huit étapes et 24 heures
| Quand | Étape | Qui | Ce qui se passe |
|---|---|---|---|
| En journée | 1 · Alix | Mattermost | L'équipe discute, Alix propose le ticket |
| 2 · Ticket | Notion | Créé au nom du demandeur, avec le contexte | |
| 18 h | 3 · Tri | Olga | Marque 🟢 les tickets prêts, sans relecture de ma part |
| 8 h | 4 · Batch | T3 Code | Une MR par ticket prêt, trois agents en parallèle |
| La matinée | 5 · Le code | Claude Code · pstack | Playbook selon la complexité, sous-agents, implémentation |
| 6 · La preuve | tests · verify-aplus | Tests ciblés, puis le parcours rejoué dans un vrai navigateur | |
| La journée | 7 · La MR | GitLab · CodeRabbit · Olga | CI, relecture automatique, compte rendu sur le ticket |
| 8 · Fusion | L'ingénieur · Scalingo | Je relis et je fusionne ; develop en recette, main en production |
La demande devient un ticket là où on discute, sans changer d'outil
Fil Mattermost · exemple 1 · exemple 2
- Les tickets viennent de l'équipe produit, directement dans Notion, ou d'une discussion dans Mattermost
- Dans un fil, quelqu'un décrit un problème ou une spec et demande un ticket à Alix
- Alix répond, va lire le code ou la base si besoin, et propose un ticket
- Le ticket est créé dans Notion au nom du demandeur, avec le contexte
Notion · le champ « Suivi auto »
Une machine à états que les agents lisent et écrivent :
🟢 prêt pour le batch · 🔍 MR à relire · ❓ question en attente
Plus les retours « À traiter », les priorités ⭐️, et le lien vers la maquette Figma.
À 18 h, Olga ne laisse entrer que les tickets assez clairs pour un agent
Un ticket est prêt si :
- l'attendu est vérifiable
- aucune décision n'est ouverte
- la maquette est là quand il en faut une
- ça tient en une MR relisable
- ça se fait avec du code
- personne n'est déjà dessus
Dans le doute, pas prêt.
Olga lit tout, ne commente rien. Sa seule écriture est le 🟢.
Elle garde une mémoire : elle ne repose jamais un 🟢 qu'on a retiré.
Personne ne relit son tri. Un ticket mal trié coûte une MR inutile, c'est pour ça que la règle est « dans le doute, pas prêt ».
À 8 h, le batch ouvre une MR par ticket, chacun dans sa copie du dépôt
Famille B
Les MR relues avec des « modifs à faire » : nouveaux commits sur la même MR.
Famille C
Les tickets dont la ❓ a reçu une réponse : ils reprennent là où ils s'étaient arrêtés.
Famille A
Les nouveaux 🟢, six au plus par matin.
Isolation
Un thread T3 par ticket, un git worktree par thread, une branche partie de develop. Deux agents ne peuvent pas se marcher dessus : ils n'ont rien en commun.
Débit
Trois threads en même temps, les autres font la queue. À la fin, un tableau : ticket · MR · CI · blocages.
Dans chaque thread, l'agent n'a pas fini tant qu'il n'a pas vu la page marcher
notion-issue: lit le ticket, les retours, la maquette Figmapstack: juge la complexité, choisit le playbook, lance ses sous-agents- Implémente selon CLAUDE.md et les skills
tsc,eslint,jestsur les fichiers touchés ; la suite complète, c'est le travail de la CIverify-aplus: la preuve dans un vrai navigateur
verify-aplus, la skill qui a tout changé
Elle lance l'app, se connecte avec un compte de test, rejoue le parcours avec agent-browser, et garde les captures comme preuve.
Sa carte features/README.md décrit chaque parcours : sélecteurs réels, pièges connus. Un changement de parcours met la fiche à jour dans le même commit, et un bot vérifie chaque soir qu'elle n'a pas dérivé.
Les machines relisent avant moi, et je suis le seul à pouvoir fusionner
GitLab CI
Typecheck, lint, tests avec couverture. Rouge : l'agent corrige avant de demander une relecture.
Sur main seulement : SAST, Semgrep, détection de secrets, audit des dépendances, SonarCloud.
CodeRabbit
Une relecture automatique en français. L'agent répond aux commentaires.
Olga
Un commentaire sur le ticket : ce qui a changé, la MR, les captures. 🟢 devient 🔍, ou ❓ si un point bloque.
Je suis le seul à pouvoir fusionner, et ce n'est pas une consigne
Dans la configuration des agents, glab mr merge, glab mr approve, le force-push, le push sur develop et --no-verify sont refusés. L'agent ne peut pas, même s'il le voulait.
Sur toute la chaîne, il me reste un geste, et la boucle se referme seule
Les tickets
L'équipe produit les écrit dans Notion, ou Alix les crée depuis un fil Mattermost quand on y trouve un problème ou une spec.
Le tri
Olga pose les 🟢 à 18 h. Personne ne repasse derrière.
Relire et fusionner
develop part en recette, main en production, sur Scalingo.
Les retours repartent d'eux-mêmes
Une relecture « modifs à faire » repart le lendemain en famille B. Une réponse à une ❓ repart en famille C. Une erreur Sentry redevient un ticket.
Ça tient parce que les règles vivent dans le code, pas dans mes consignes
06 · Ce qui guide mes choix
Avec des agents, le goulot n'est plus d'écrire le code mais de le vérifier
« Le débit vient de la confiance, pas du nombre d'agents ouverts. »
« Toujours choisir le chemin le plus court, parce que c’est le meilleur. »
- Formulations traduites, à confirmer sur ses publications
Ouvrir plus de terminaux ne m'a jamais fait avancer plus vite : je passais le temps gagné à relire. Ce qui augmente le débit, c'est de pouvoir ne pas relire ce que les machines ont déjà prouvé.
06 · Ce qui guide mes choix
Plus une règle est proche du code, moins j'ai besoin de la surveiller
| Où vit la règle | Ce qui se passe si on la viole | Exemples | |
|---|---|---|---|
| Le code | L'erreur ne compile pas | TypeScript strict, types dérivés de tRPC, Zod, refus durs dans les scripts | |
| Les machines | L'erreur casse la CI | lint, tests, CI, liste d'interdits des agents | |
| Les consignes | L'agent doit s'en souvenir | CLAUDE.md, skills, tri d'Olga | |
| L'ingénieur | Il faut que je la voie | relecture, fusion |
Mon travail, depuis mai : faire monter chaque règle d'un cran. Les choix rigides de la refonte (tout typé, tout testé) sont ce qui rend l'agent utile aujourd'hui.
06 · Ce qui guide mes choix
Plus il y a d'enfants dans la cour, moins les consignes suffisent : on aménage la cour
Des consignes à répéter
« Ne cours pas, ne monte pas là. » Ça marche avec deux enfants et un adulte qui regarde. Avec trente enfants, on passe la récré à crier, et ils n'écoutent plus.
Une cour où le chemin le plus court est le bon
Une barrière, un portail, un sol souple, des jeux là où on veut qu'ils aillent. Plus besoin de surveiller : le chemin naturel est le chemin sûr. Et ça tient avec trente enfants comme avec trois cents.
Avec des agents, c'est pareil. Une consigne dans CLAUDE.md se répète et s'oublie. Un type, un lint, un worktree, une liste d'interdits : l'agent prend le chemin le plus court, et ce chemin est le bon. Le dev passe moins de temps à crier, plus de temps à aménager la cour.
06 · Ce qui guide mes choix
Tout mon travail depuis mai : créer le maximum de confiance dans le système
Chaque problème que je fais disparaître, c'est une chose de moins à surveiller, donc une chose de plus que je peux confier aux agents sans relire. Le débit ne vient pas du nombre d'agents, il vient de la confiance que j'ai dans ce qu'ils rendent.
Pendant ce talk
Pendant ces 30 minutes, Administration+ a continué de tourner
—
signalements créés
—
messages postés par les opérateurs et les aidants
—
utilisateurs actifs sur la dernière heure
Relevé en direct par la commande Mattermost de l'équipe, au début et à la fin du talk.
Choisissez un problème et supprimez-le.
aplus.beta.gouv.fr
Charles d'Oiron