Un an avec des agents
16 juin 2026
En mai 2025, je sors de l'opérationnel d'une startup après trois ans, et je me pose une question : est-ce que je peux sortir une app tout seul, sans développeurs ? Un an plus tard, je ne code pas mieux qu'avant.
En mai 2025, je sors de l'opérationnel de la startup où je bossais depuis trois ans. Midnight Club continue de livrer des sites à côté, mais ce que je veux garder, c'est le produit : des apps, des webapps, c'est ça qui m'excite. J'ai du temps devant moi. C'est le bon moment pour creuser l'IA pour de vrai, et voir ce que je peux produire avec, entièrement seul. Le meilleur moyen de se former, c'est un vrai projet.
J'en ai un sous la main : diaradio.live, une radio associative qu'on gère à plusieurs, avec le Collectif Moï Moï. Le projet s'essouffle, on n'a pas les moyens de développer les outils dont on aurait besoin. Je veux des outils du niveau de nts.live, pour relancer la radio, et pourquoi pas la rentabiliser un jour. Et surtout un système qui encaisse plus d'émissions et plus de résidents sans qu'on soit plus nombreux à les gérer.
La question que je me pose en la lançant : est-ce que je peux sortir une app tout seul, sans faire appel à des développeurs ? Application iOS et Android, backend, site web. Juste moi en product, et ChatGPT. Au pire j'y passe quelques mois et je me serai formé. Let's go, advienne que pourra.
Si la question se pose, c'est que je ne suis pas développeur full stack. Je transforme une maquette en code, je sais lire une décision technique, parler à des devs, monter une infra simple. Écrire une API, tenir un backend : non.
Un iPad et des vacances
Je pars d'abord en vacances, sans ordinateur. Tout commence dans l'app ChatGPT sur un iPad : exploration, définition du scope, choix de stack, inventaire de ce qui est possible. En essayant de faire la part des choses, parce que ChatGPT est enthousiaste par nature. Je peux importer mes milliers d'archives Soundcloud ? Oui, pas de problème. Tout transférer dans un CMS, tout relier, faire un player qui lit depuis Soundcloud ? Oui, pas de problème. Une app crossplatform ? Un player natif, avec les contrôles sur l'écran verrouillé de l'iPhone et la reprise du playback après un coup de fil ? Oui, pas de problème.
Il disait oui à tout. Je ne mesurais pas encore ce que ça allait me coûter.
Je suis le moyen de transport
Je rentre de vacances surexcité. Les bases sont posées, les technos choisies, un scope de MVP (qui n'a évidemment pas arrêté de bouger ensuite). J'avais fait un premier commit avant de partir, pour lancer officiellement le projet : « Initial commit – Dia Radio SPA », le 22 mai. Le vrai travail commence au retour.
Le process tient en une phrase : je discute, il écrit, je colle. ChatGPT me donne des commandes de terminal pour installer Vue, me dit crée tel fichier, nomme-le comme ça, et me sort le code que je copie dedans. Je teste, je reviens avec l'erreur de la console. Le code passait par mes mains pour aller d'une fenêtre à l'autre.
Et j'étais bluffé. Assez rapidement, on arrive à un proto fonctionnel de webapp avec un player audio qui marche. L'interface en Vue, j'aurais pu la faire seul, moins vite, mais j'y serais arrivé. Le player en JS, non : là on dépassait les limites de mes connaissances. Et le player marche ! Sans avoir fait appel à un développeur.
Je suis la mémoire
Le problème suivant est arrivé vite : ChatGPT dans le navigateur sature à mesure que la conversation s'allonge. Ça rame, et il faut en recréer une nouvelle, en perdant tout l'historique de ce qu'on a fait. J'ai fini par installer un plugin Chrome qui exportait la conversation en markdown, pour la réinjecter dans la suivante. Un cauchemar. Je passais mes journées à déplacer de la mémoire à la main.
C'est là que mon organisation a pris la forme qui allait durer. J'ai ouvert plusieurs chats. Un pour la gestion : l'organisation, les conseils, les choix techniques, avec des rôles définis, senior dev, devops, product manager. C'est lui qui gardait la vue d'ensemble, les décisions et les raisons. Et d'autres, orientés sessions de code, où je continuais à copier-coller dans VS Code, tester, rapporter les erreurs. Long et fastidieux, vu d'aujourd'hui. Sur le moment, ça marchait.
Sans le décider vraiment, je venais de dessiner l'architecture qui allait tenir toute l'année : un cerveau qui dirige, des exécutants qui produisent, et moi entre les deux. Tout ce qui allait changer ensuite, c'est qui occupe chaque chaise.
Je venais aussi de rencontrer le problème majeur du travail avec des LLM : la mémoire. Ma solution de l'époque, c'étaient des exports markdown, et moi qui fais la navette.
Le festival
La deadline, c'était notre festival, en août. Je me mettais la pression tout seul, je ne faisais que ça. L'app n'était pas prête, et elle ne sortira sur l'App Store qu'en mars. Mais il y avait une démo : le live, une partie des archives, la recherche, les favoris, un compte. Très bien reçue par l'équipe de la radio.
En relisant l'historique de ces semaines-là, un commit du 15 août m'a fait sourire : « Backup before playback control fixes ». Un backup manuel, committé, avant d'oser toucher au player. C'est exactement où en était ma confiance.
Je suis le traducteur
Cursor était dans mon viseur depuis des semaines. Un pote m'en parlait tout le temps : tu devrais tester. Mais j'avais un process qui marchait, j'avançais, et je n'arrivais pas à m'arrêter pour essayer un nouvel outil.
Quand je l'ai enfin installé : énorme claque. Cursor a accès à tout le code. Il écrit plusieurs fichiers d'un coup pour faire marcher une feature, il voit comment les fichiers sont reliés entre eux. Dix mille fois plus efficace que de demander du code à ChatGPT. Adopté immédiatement.
Dans l'architecture, Cursor venait de prendre la chaise de l'exécutant. Le chat de gestion restait chef de projet et senior dev : on décide ensemble de ce qu'on fait, et on fait exécuter. Moi, je ne transportais plus du code d'une fenêtre à l'autre. Je transportais des audits, des briefs et des instructions.
Prudemment, d'abord. Parce qu'au début, Cursor est con. Une demande pas assez cadrée le lance dans une frénésie de création de code qu'il faut arrêter en vol. Un bug, et il patch, sur-patch, re-patch, parfois un bug qu'il vient lui-même de créer en allant trop vite. Le nombre de fois où j'ai dû l'arrêter et revenir en arrière avec git.
Donc j'ai cherché comment le driver, et j'ai fini par formaliser un mode que j'avais appelé cursor prompt architect. Expliquer ce qu'on veut, demander un audit à Cursor, relire l'audit avec ChatGPT, décider, faire proposer des modifications, les relire, et seulement là, exécuter.
J'ai retrouvé les instructions de l'époque. Les voici :
Cursor Prompt Architect Mode – Parameters
Roles:
- Product Owner (you): Defines objectives and approves prompts.
- Strategist & QC (me): Clarifies scope, ensures safe and
high-quality prompts, assesses risks.
- Coder (Cursor): Executes the prompts and handles audits
and code changes.
Process:
1. You describe the goal or problem.
2. I clarify scope and constraints, and propose options
if needed.
3. I draft a precise prompt for Cursor (atomic, safe, and
explicit). These prompts are provided in a single,
copy/paste-friendly code block.
4. I assign a risk/impact level (Low / Medium / High).
5. You approve or modify the prompt.
6. Cursor executes the prompt.
Safeguards:
- I do not write or directly apply code/changes myself.
- I do not audit files myself. Cursor handles all audits.
- Prompts must be well-scoped and justified (avoid vague
instructions like "fix it").
- Break down large or risky changes into smaller,
manageable steps.
- Do not write prompts unless requested or approved by you.
- Do not propose diffs unless revising an existing Cursor
suggestion. La difficulté principale : garder chaque outil dans son rôle. ChatGPT ne pouvait pas s'empêcher de sortir du code (« cursor is the coder, you are not! stop outputting code for god sake »), et Cursor se lançait dans de grands chantiers quand on lui demandait un audit.
Trois semaines contre un plugin
Depuis le début du projet, je savais que le gros morceau serait le player audio natif iOS. Les contrôles sur l'écran verrouillé, la reprise après un coup de fil, le changement de sortie audio : le téléphone, les écouteurs Bluetooth, la voiture, une enceinte AirPlay. Je le repoussais en finissant le reste. On était en septembre, trois mois de travail actif, il fallait y aller.
Et là, c'est la merde.
Je laisse ChatGPT chercher des plugins Capacitor. Rien de fou, un candidat qui a l'air pas mal. On part dessus. Le commit d'intégration du 4 septembre dit, sans ironie à l'époque : « by-the-book @mediagrid/capacitor-native-audio integration ».
Les trois semaines qui suivent se lisent dans les messages de commit comme dans un journal de bord qui tourne mal : nil player crashes, RCC crash, un scrubber qui fait le yo-yo, « deterministic seek (1 retry + revert) », « kill spinner loops », « revert-to-last-good on failure ». Au début ça a l'air de marcher, puis le playback s'arrête au bout de vingt minutes, puis un truc vraiment bloquant. On cherche, on patch, on sur-patch, et mon plugin devient un monstre. Il y a des petites avancées, juste assez pour continuer. ChatGPT me balance des carottes : ah, c'est ça le problème, on a trouvé, patch comme ça et c'est bon. Et ce n'est jamais bon. Je ne dors plus, je ne fais que ça, je deviens agressif avec mes IA, je leur parle mal. En fait, je sature complètement.
À un moment, je dis stop. Je demande à ChatGPT de revérifier les plugins, et surtout d'aller lire correctement les docs audio natives d'Apple. Ce qu'on n'avait jamais fait. Je m'attendais à ce qu'il le fasse de lui-même ; à l'époque, il ne le faisait pas. Il inventait des solutions et affirmait qu'on n'avait pas le choix. Sa réponse après lecture : ah oui, je n'avais pas toutes ces infos, je comprends mieux.
Sa nouvelle recherche de plugin ne donne rien. Je cherche moi-même, je trouve très vite un bon candidat, je file le repo à ChatGPT, il confirme. On nettoie l'app du mauvais plugin, on planifie proprement à partir des docs Apple et de la codebase du nouveau, une série de prompts bien sentis à Cursor.
Migration committée le 29 septembre. Le 30 : « Merge iOS native playback », la reprise après coup de fil qui marche, et dix builds dans la journée. En vingt-quatre heures, ça marche. Après trois semaines à me taper la tête contre un mur.
La faute n'est pas à l'outil : j'ai validé un choix structurant sans le vérifier, en faisant confiance à ChatGPT pour lire des docs qu'il ne lisait pas. Ça m'a coûté un mois. Cette erreur-là, je ne peux plus la refaire aujourd'hui : la vérification est passée dans le process. Aucun choix structurant ne part sans qu'on ait lu les docs et challengé le plan, et ce n'est plus moi qui dois y penser. Mais j'anticipe. Sur le moment, j'ai appris deux ou trois trucs, et on est devenus plus efficaces. Je dis « on », parce qu'il y a vraiment une logique d'équipe là-dedans.
Je fais circuler le plan
De septembre à novembre, on avance grave. Je vérifie mieux les choix en amont, le prompt architect tourne bien. Son seul défaut : les allers-retours permanents entre ChatGPT et Cursor. Demander l'audit, coller le résultat, re-audit, instructions, rapport, test.
En novembre, Cursor sort le plan mode. Ce que je faisais à coups d'allers-retours entre deux fenêtres, l'outil le fait maintenant tout seul, au même endroit. On décide avec ChatGPT de ce qu'on fait, Cursor sort un plan, le plan repart chez ChatGPT, corrections, quelques tours, et on laisse Cursor exécuter. Cette fois, aucune résistance à l'adoption : j'ai vu l'update, testé, adopté dans la journée. L'outil rejoignait exactement le workflow que je m'étais construit : auditer, planifier, vérifier, puis seulement exécuter.
Mon rôle change encore : je ne transmets plus des instructions, je fais circuler un plan jusqu'à ce qu'il tienne la route. Et ça se met à marcher du premier coup, sur des choses plus complexes, avec plus de fichiers créés ou modifiés d'un coup. Les plans, on les commit dans le repo pour mémoire, à côté des changelogs, buglogs et backlogs que je faisais déjà tenir à Cursor depuis le mois d'août. Le repo devenait la mémoire du projet. Je ne l'avais pas décidé, je m'en suis rendu compte après.
Les chaises fusionnent
Claude Code explosait depuis des mois et je l'avais dans le coin de l'œil, en me disant : à un moment, faut que je teste. Même résistance qu'avant Cursor. J'avais un workflow super efficace, l'app allait sortir, la nouvelle saison de la radio était à préparer, et j'avais peur de perdre du temps à adopter une techno de plus.
Entre-temps, la logique de documentation s'était épaissie. En mars, un manuel .ai/ par projet : architecture, domaine, flux, règles, recettes. Pour arrêter de tout réexpliquer. L'infra en place, l'agent savait quoi faire sur le serveur, comment le redémarrer sans couper le stream, les crons, le fonctionnement de tout. Les MCP, testés fin 2025, connectaient déjà les agents à mes services : le CMS, l'analytics, Gmail, GitHub, les DNS.
Puis je teste Claude Code, en ouvrant mon dossier de prod DIA. Ce qui m'a scié, ce sont les skills : un processus écrit une fois, rejoué à l'identique. Celles des autres d'abord, puis les nôtres, et toute tâche répétitive devient une skill.
Mais le vrai basculement, c'est l'ensemble. Un CLAUDE.md court qui renvoie vers le .ai/, les connecteurs, les skills, et le workspace que j'ai commencé à organiser autour. On ouvre une session : rien qu'en lisant la doc et l'historique git, l'agent sait ce qu'on fait et où on en est.
Conséquence que je n'avais pas anticipée : je ne me sers plus de Cursor, et je ne me sers plus de ChatGPT. Le cerveau qui dirige et l'exécutant qui produit, les deux chaises de 2025, tiennent maintenant dans un même chat, qui envoie des agents et des sous-agents en parallèle quand la tâche le demande. Et le contradicteur existe toujours, mais ce n'est plus moi qui fais la navette : un modèle Claude écrit le plan, Codex, chez OpenAI, le relit dans un bac à sable en lecture seule avec pour consigne de le démolir, et on boucle jusqu'à ce que ça passe. Le même geste que le prompt architect. C'est juste une skill qui s'en charge à ma place.
Et à peu près au même moment, le second brain. Il vit à la racine du workspace, je l'alimente, il regarde les git des projets. Un jour, je lance une session dans un dossier quelconque et je me rends compte que Claude sait. Il sait ce qu'on fait, où on en est, et quand je demande quelque chose, il fait référence à d'autres projets, à des problèmes qu'on a déjà rencontrés, à des solutions qu'on a déjà trouvées. Là, je suis sur le cul. Si je demande « crée-moi un nouveau client, projet site vitrine », il crée le dossier client, le dossier de travail, il sait déjà qu'on fait de l'Astro avec Sanity. Il demande quand même, dans le doute.
Aujourd'hui
Une journée type. J'ouvre une session dans le dossier d'un projet, elle démarre par un état des lieux : où on en est, ce qui a bougé, et ça dépasse le code, la session lit aussi mes mails. On priorise, on répond à deux trois messages, on va chercher les infos du prochain truc à développer. Puis comme avant : ok, on fait ça. Petit plan, on le challenge, et Claude exécute. En parallèle, je lance d'autres sessions sur d'autres projets. J'en gère plusieurs en même temps, et on me prévient quand une décision m'attend.
Je passe mes journées à discuter avec mon équipe, en fait. Je ne fais que ça.
Et je fais confiance. « On a tel bug sur diaradio.live, check ce qui déconne et règle-le » : total confiance, ça marche. Pas parce que les modèles seraient devenus infaillibles, mais parce qu'il y a les process, la doc, l'historique, les design systems, et que Claude comme moi savons maintenant quand s'arrêter pour vérifier. La confiance de septembre 2025, celle qui m'a coûté un mois sur un plugin, n'était pas justifiée. Celle d'aujourd'hui l'est.
Est-ce qu'un profil non technique y arriverait ? Oui et non. Pour construire une app ou une webapp, il faut une logique : comprendre l'UX, l'infra, la structuration, ce qui rend un système scalable, anticiper les fonctionnalités futures. C'est moins une histoire de profil technique que de profil de builder. Et je suis convaincu qu'avec les bonnes infos et un système comme celui-là, workspace, docs, mémoire, à peu près n'importe qui peut produire beaucoup plus efficacement, même quand ce n'est pas du code. Une équipe marketing avec son brand book, son tone of voice et ses guidelines en markdown peut sortir ses présentations en un rien de temps. Mais une app avec du natif, des API partout et des données personnalisées à garder secure ? Je pense qu'il faut être un peu tech quand même.
Je suis un couteau suisse digital. Chef de projet, webdesigner, intégrateur front, product manager. Mais aujourd'hui, je suis product engineer.
Un an plus tard, je ne code pas mieux qu'avant. J'ai toujours besoin d'une équipe. Elle n'est simplement plus humaine.