Avec Claude Code, on peut planifier un projet entier - architecture, tâches, dépendances - et obtenir un plan d'implémentation précis. Mais une fois le plan écrit, comment l'exécuter ? C'est la question que je me suis posée en construisant FamilySound.
Le contexte : FamilySound
FamilySound est une app iOS qui permet aux parents d'envoyer des sons aux téléphones de leurs enfants via notification push. Vous appuyez sur un bouton, le téléphone de votre enfant joue un son a volume maximum - même s'il est en silencieux. C'est un "viens manger" digital.
L'app était déjà fonctionnelle a ~95% : authentification parent/enfant, enregistrement de sons, stockage Firebase, lecture locale. Mais il restait 20 tâches reparties en 5 phases pour arriver à 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, déploiement de la Cloud Function
- Phase 2 - Robustesse - Retry logic, optimisation des requêtes Firestore (N+1), durcissement des règles de sécurité, gestion de la session audio
- Phase 3 - Rôle coparent - Nouveau rôle entre parent et enfant, flow d'inscription par email + code invite, permissions spécifiques, mise à jour du backend
- Phase 4 - Tests - Protocols pour les services, tests unitaires des modèles, mocks, tests des ViewModels
- Phase 5 - Polish - Crashlytics, analytics, monitoring réseau, préparation TestFlight
20 tâches, des fichiers interdépendants, pas de suite de tests existante. La question n'était plus quoi faire, mais comment le faire exécuter par l'IA sans que ça parte dans le mur.
Le problème de l'exécution
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 séquence logique. Mais l'exécution, c'est autre chose.
Deux risques principaux :
- L'effet cascade - Une erreur dans la tâche 1 se propage dans la tâche 2, qui la propage dans la 3. Au bout de 5 tâches, le code est dans un état incohérent difficile à démêler.
- La dérive silencieuse - L'IA interprète mal une tâche, produit du code qui "marche" mais ne correspond pas à ce qu'on voulait. Sans point de contrôle, on ne s'en rend compte qu'à la fin.
J'ai identifie deux approches possibles.
Approche A : Subagent-Driven
Principe
On reste dans la même conversation Claude Code. Pour chaque tâche, on lance un agent spécialisé (subagent). Entre chaque tâche, on fait un point : je vérifie le code, je valide ou je corrige, puis on passe à la suivante.
- Revue entre chaque tâche - rien ne passe sans validation humaine
- Correction en temps réel - si ça déraille, on ajuste immédiatement
- Commit intermédiaire - chaque tâche validée = un point de restauration Git
- ZĂ©ro emballement - l'IA ne part jamais dans la mauvaise direction sans accord
L'inconvénient principal : c'est séquentiel et interactif. L'utilisateur doit être présent pour valider chaque étape. Et chaque agent repart sans le contexte des précédents - il faut bien rédiger les prompts pour compenser.
Approche B : Session Parallèle
Principe
On ouvre une nouvelle session Claude Code dans le même répertoire. L'agent lit le plan d'implémentation et exécute les tâches par batch - phase par phase - avec des checkpoints en fin de phase.
- Exécution en continu - l'agent enchaîne sans attendre de validation intermédiaire
- Contexte frais - le plan écrit est la source de vérité, pas l'historique de conversation
- Parallelisable - les tâches indépendantes (ex: Phase 2) peuvent tourner en parallèle
- Session libre - pendant que l'agent travaille, vous pouvez faire autre chose
L'inconvénient : moins de contrôle. Les erreurs s'accumulent avant d'être remarquées. Si une tâche est mal interprétée, les suivantes héritent du problème. Et l'agent ne peut pas poser de questions en cours de route.
Comparaison directe
| Critère | Subagent-Driven | Session Parallèle |
|---|---|---|
| Contrôle | Total (validation par tâche) | Partiel (revue par phase) |
| Vitesse | Plus lent (attente humaine) | Plus rapide (exécution continue) |
| Risque de dérive | Faible | Modéré à élève |
| Présence requise | Continue | Par phase uniquement |
| Filet de sécurité | Commits + revue humaine | Plan écrit + tests (si existants) |
| Idéal pour | Fichiers interdépendants | Tâches indépendantes + tests |
Le choix pour FamilySound
1. Les fichiers sont interdépendants
Les tâches 1 a 3 de la Phase 1 touchent toutes les mêmes fichiers : AppDelegate, AuthService, FamilySoundApp. Si la tâche 1 (permissions de notifications) modifie AppDelegate et que la tâche 2 (synchronisation FCM) le modifie aussi, une erreur dans la première se propage instantanément dans la seconde.
Avec la revue intermédiaire, on détecte le problème avant qu'il ne contamine le reste.
2. La Phase 3 est complexe
Ajouter un rôle "coparent" implique de modifier les modèles Swift, les services d'authentification, les vues SwiftUI, les règles Firestore et la Cloud Function - en même temps. C'est 5 tâches qui touchent à la fois le frontend et le backend. Laisser l'IA faire ça sans checkpoint, c'est risquer de découvrir un ensemble de problèmes enchevêtres en fin de phase.
3. Pas de filet de sécurité
Le projet n'avait ni suite de tests ni historique Git propre. Pas de tests = pas de détection automatique des régressions. Pas de Git = pas de rollback facile. Chaque commit intermédiaire (un par tâche validée) crée manuellement le filet de sécurité qui n'existait pas.
Quand choisir l'autre approche ?
La Session Parallèle n'est pas inférieure - elle est adaptée à d'autres contextes :
- Suite de tests existante - les régressions sont détectées automatiquement, pas besoin de revue humaine à chaque tâche
- Historique Git propre - rollback facile si quelque chose déraille
- Tâches indépendantes - quand les tâches ne touchent pas les mêmes fichiers, la parallelisation est un vrai gain
- Temps limite - si vous ne pouvez pas rester présent pour valider chaque étape, mieux vaut laisser l'IA avancer et revoir après
Ce que j'en retiens
- Le plan ne suffit pas. Un plan d'implémentation de 20 tâches, aussi bien structure soit-il, ne garantit rien si la méthode d'exécution n'est pas réfléchie. La question "comment on exécute" est aussi importante que "qu'est-ce qu'on exécute".
- 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 contrôle, une mauvaise interprétation se transforme en dette technique invisible.
- Le commit intermédiaire est votre meilleur outil. Chaque tâche validée, commitee, c'est un point de restauration. C'est le filet de sécurité le plus simple et le plus fiable.
- Adaptez la méthode au projet, pas l'inverse. FamilySound avait besoin de contrôle strict. Un projet avec une bonne couverture de tests aurait bénéficie de la Session Parallèle. Il n'y a pas de réponse universelle.