Avec Claude Code, on peut planifier un projet entier — architecture, taches, dependances — et obtenir un plan d'implementation precis. Mais une fois le plan ecrit, comment l'executer ? C'est la question que je me suis posee en construisant FamilySound.
Le contexte : FamilySound
FamilySound est une app iOS qui permet aux parents d'envoyer des sons aux telephones de leurs enfants via notification push. Vous appuyez sur un bouton, le telephone de votre enfant joue un son a volume maximum — meme s'il est en silencieux. C'est un "viens manger" digital.
L'app etait deja fonctionnelle a ~95% : authentification parent/enfant, enregistrement de sons, stockage Firebase, lecture locale. Mais il restait 20 taches reparties en 5 phases pour arriver a un produit publiable sur l'App Store :
- Phase 1 — Correctifs critiques — Permissions de notifications, synchronisation FCM fiable, correction d'une race condition dans le flow d'inscription, deploiement de la Cloud Function
- Phase 2 — Robustesse — Retry logic, optimisation des requetes Firestore (N+1), durcissement des regles de securite, gestion de la session audio
- Phase 3 — Role coparent — Nouveau role entre parent et enfant, flow d'inscription par email + code invite, permissions specifiques, mise a jour du backend
- Phase 4 — Tests — Protocols pour les services, tests unitaires des modeles, mocks, tests des ViewModels
- Phase 5 — Polish — Crashlytics, analytics, monitoring reseau, preparation TestFlight
20 taches, des fichiers interdependants, pas de suite de tests existante. La question n'etait plus quoi faire, mais comment le faire executer par l'IA sans que ca parte dans le mur.
Le probleme de l'execution
Quand on travaille avec Claude Code sur un projet de cette taille, le plan est la partie facile. L'IA analyse le code, identifie les manques, propose une sequence logique. Mais l'execution, c'est autre chose.
Deux risques principaux :
- L'effet cascade — Une erreur dans la tache 1 se propage dans la tache 2, qui la propage dans la 3. Au bout de 5 taches, le code est dans un etat incoherent difficile a demeler.
- La derive silencieuse — L'IA interprete mal une tache, produit du code qui "marche" mais ne correspond pas a ce qu'on voulait. Sans point de controle, on ne s'en rend compte qu'a la fin.
J'ai identifie deux approches possibles.
Approche A : Subagent-Driven
Principe
On reste dans la meme conversation Claude Code. Pour chaque tache, on lance un agent specialise (subagent). Entre chaque tache, on fait un point : je verifie le code, je valide ou je corrige, puis on passe a la suivante.
- Revue entre chaque tache — rien ne passe sans validation humaine
- Correction en temps reel — si ca deraille, on ajuste immediatement
- Commit intermediaire — chaque tache validee = un point de restauration Git
- Zero emballement — l'IA ne part jamais dans la mauvaise direction sans accord
L'inconvenient principal : c'est sequentiel et interactif. L'utilisateur doit etre present pour valider chaque etape. Et chaque agent repart sans le contexte des precedents — il faut bien rediger les prompts pour compenser.
Approche B : Session Parallele
Principe
On ouvre une nouvelle session Claude Code dans le meme repertoire. L'agent lit le plan d'implementation et execute les taches par batch — phase par phase — avec des checkpoints en fin de phase.
- Execution en continu — l'agent enchaine sans attendre de validation intermediaire
- Contexte frais — le plan ecrit est la source de verite, pas l'historique de conversation
- Parallelisable — les taches independantes (ex: Phase 2) peuvent tourner en parallele
- Session libre — pendant que l'agent travaille, vous pouvez faire autre chose
L'inconvenient : moins de controle. Les erreurs s'accumulent avant d'etre remarquees. Si une tache est mal interpretee, les suivantes heritent du probleme. Et l'agent ne peut pas poser de questions en cours de route.
Comparaison directe
| Critere | Subagent-Driven | Session Parallele |
|---|---|---|
| Controle | Total (validation par tache) | Partiel (revue par phase) |
| Vitesse | Plus lent (attente humaine) | Plus rapide (execution continue) |
| Risque de derive | Faible | Modere a eleve |
| Presence requise | Continue | Par phase uniquement |
| Filet de securite | Commits + revue humaine | Plan ecrit + tests (si existants) |
| Ideal pour | Fichiers interdependants | Taches independantes + tests |
Le choix pour FamilySound
1. Les fichiers sont interdependants
Les taches 1 a 3 de la Phase 1 touchent toutes les memes fichiers : AppDelegate, AuthService, FamilySoundApp. Si la tache 1 (permissions de notifications) modifie AppDelegate et que la tache 2 (synchronisation FCM) le modifie aussi, une erreur dans la premiere se propage instantanement dans la seconde.
Avec la revue intermediaire, on detecte le probleme avant qu'il ne contamine le reste.
2. La Phase 3 est complexe
Ajouter un role "coparent" implique de modifier les modeles Swift, les services d'authentification, les vues SwiftUI, les regles Firestore et la Cloud Function — en meme temps. C'est 5 taches qui touchent a la fois le frontend et le backend. Laisser l'IA faire ca sans checkpoint, c'est risquer de decouvrir un ensemble de problemes enchevêtres en fin de phase.
3. Pas de filet de securite
Le projet n'avait ni suite de tests ni historique Git propre. Pas de tests = pas de detection automatique des regressions. Pas de Git = pas de rollback facile. Chaque commit intermediaire (un par tache validee) cree manuellement le filet de securite qui n'existait pas.
Quand choisir l'autre approche ?
La Session Parallele n'est pas inferieure — elle est adaptee a d'autres contextes :
- Suite de tests existante — les regressions sont detectees automatiquement, pas besoin de revue humaine a chaque tache
- Historique Git propre — rollback facile si quelque chose deraille
- Taches independantes — quand les taches ne touchent pas les memes fichiers, la parallelisation est un vrai gain
- Temps limite — si vous ne pouvez pas rester present pour valider chaque etape, mieux vaut laisser l'IA avancer et revoir apres
Ce que j'en retiens
- Le plan ne suffit pas. Un plan d'implementation de 20 taches, aussi bien structure soit-il, ne garantit rien si la methode d'execution n'est pas reflechie. La question "comment on execute" est aussi importante que "qu'est-ce qu'on execute".
- L'IA a besoin de garde-fous. Pas parce qu'elle code mal — elle code souvent mieux que moi. Mais parce que sans point de controle, une mauvaise interpretation se transforme en dette technique invisible.
- Le commit intermediaire est votre meilleur outil. Chaque tache validee, commitee, c'est un point de restauration. C'est le filet de securite le plus simple et le plus fiable.
- Adaptez la methode au projet, pas l'inverse. FamilySound avait besoin de controle strict. Un projet avec une bonne couverture de tests aurait beneficie de la Session Parallele. Il n'y a pas de reponse universelle.