Tâches atomiques (Décomposition atomique des tâches)

1. Vue d'ensemble du concept et problème systémique

Dans le développement classique, les tâches floues (« Implémenter l'authentification », « Réécrire le module de recherche ») sont la principale source de dépassement des délais et de retravail. À l'ère du développement assisté par des agents AI, le coût d'une mauvaise décomposition a augmenté de manière exponentielle.

Lorsqu'un ingénieur donne à un agent une instruction vague de haut niveau, ce dernier fait des suppositions sur des dizaines de détails non définis. Le résultat est un diff monolithique touchant 40 fichiers, mélangeant mise en page, schémas de base de données et règles métier. Vérifier un tel diff est pratiquement impossible : l'ingénieur subit une surcharge cognitive, clique sur « Accept », puis se retrouve confronté à des conflits insolubles une semaine plus tard.

Atomic Tasks (Tâches Atomiques) — c'est une discipline d'ingénierie qui structure le travail selon le principe d'indivisibilité :

• Chaque sous-tâche se concentre sur un seul changement de comportement ou de structure.
• Elle possède des paramètres d'entrée clairement définis et des invariants de sortie attendus.
• Elle peut être entièrement implémentée, testée et commitée indépendamment du reste du système.

Monolithe chaotique (Échec de l’agent) :
[Exigence : « Crée-moi une boutique en ligne »] ---> [Le LLM génère un brouillon de 30 fichiers avec des placeholders]

Décomposition atomique (Succès maîtrisé) :
[Exigence : « Processus de passation de commande »]
   |
   +---> Tâche 1 : Créer le schéma Drizzle pour la table Order + migration (Vérification : db:push)
   |
   +---> Tâche 2 : Écrire une fonction pure calculateTotal(items, discount) (Vérification : 5 tests unitaires)
   |
   +---> Tâche 3 : Implémenter POST /api/orders avec validation Zod (Vérification : curl / test API)
   |
   +---> Tâche 4 : Créer l’interface utilisateur du formulaire de commande (Vérification : composant dans le navigateur)

2. Taxonomie architecturale et modèle mental

Échelle des niveaux de granularité des tâches (Task Granularity Spectrum) :

1. Niveau Macro (System Feature / Epic) :
   • Objectif métier (par exemple, « Support multilingue du site »). Ne doit pas être transmis directement dans le chat de l'agent comme une seule commande.
2. Module Atomique (Feature Slice / Component) :
   • Tranche verticale de fonctionnalité (par exemple, « Routage des locales via middleware »).
3. Action Atomique (Atomic Micro-Task) :
   • Étape concrète modifiant une seule couche : « Créer le dictionnaire de traductions pour la page 404 au format JSON et ajouter des types stricts aux mots-clés ».
   • Temps d'exécution : 2–5 minutes.
   • Nombre de lignes modifiées : jusqu'à 50–100 lignes.

3. Pipeline technique et mécanique interne

Modèle de tâche atomique d'ingénierie (TASK_SPEC.md)

### Tâche : Création d'un dépôt pour la conservation des jetons de session

**Contexte des fichiers :**
- Fichier cible : `src/lib/auth/session-store.ts`
- Fichier de test : `src/lib/auth/__tests__/session-store.test.ts`
- Contrat de référence : `src/lib/auth/types.ts`

**Exigences :**
1. Implémenter la classe `RedisSessionStore`, qui implémente l'interface `SessionStore`.
2. La méthode `saveSession(token, data, ttlSeconds)` doit définir une clé avec un TTL en utilisant la commande Redis `SETEX`.
3. La méthode `getSession(token)` doit retourner un objet désérialisé ou `null` si la clé est absente.

**Critère d'achèvement (Definition of Done) :**
- La commande `npx vitest run src/lib/auth/__tests__/session-store.test.ts` retourne 100 % de tests réussis.
- Aucune erreur de typage : `npx tsc --noEmit` s'exécute avec 0 erreur.

Pipeline d'exécution d'une étape atomique :

1. L'ingénieur formule un TASK_SPEC avec un contexte clair et un test.
2. L'agent lit UNIQUEMENT les 2-3 fichiers spécifiés (fenêtre de contexte propre, zéro hallucination).
3. L'agent rédige l'implémentation.
4. Exécution du test automatisé -> feu vert.
5. L'ingénieur vérifie le diff compact (20 lignes) en 15 secondes.
6. Commit Git : `git commit -m "feat(auth): implement redis session store"`

4. Scénarios d'ingénierie pratiques en production

01. Migration sécurisée d'une base de données de 10 millions de lignes

Au lieu d'une migration complexe unique, l'équipe divise la tâche en 4 atomic tasks : 1) Ajouter une nouvelle colonne nullable ; 2) Écrire un script de synchronisation batch en arrière-plan traitant 1000 lignes à la fois ; 3) Basculer les écritures vers la nouvelle colonne ; 4) Ajouter la contrainte NOT NULL et supprimer l'ancien champ. Chaque étape est vérifiée et déployée séparément, éliminant le risque de verrouillage de table.

02. Sortir de l'impasse créative lors du debugging

Un ingénieur ne comprend pas pourquoi un algorithme complexe de calcul d'itinéraire retourne un résultat erroné. Au lieu d'analyser inutilement tout le fichier de 1000 lignes, il décompose l'algorithme en 5 sous-fonctions pures et écrit un test distinct pour chacune. L'erreur d'arrondi des fractions est identifiée à la 3e sous-fonction, et le bug est corrigé en 3 minutes.

03. Diriger des subagents en parallèle (Parallel Subagents)

Grâce à l'atomicité, l'architecte peut lancer 3 sessions de modèle simultanément : un agent écrit le parser XML, un second génère les rapports PDF, un troisième définit le schéma de la base de données. Puisque leurs contrats sont atomiques et n'interfèrent pas dans les fichiers partagés, aucun conflit de fusion (Merge Conflicts) ne survient.

5. Pièges, erreurs courantes et sécurité

1. Paralysie de la fragmentation (Micro-Task Hell) : Une décomposition excessive en 50 petites étapes de 30 secondes chacune crée une friction bureaucratique : le temps consacré à formuler le prompt et à attendre la réponse commence à dépasser le temps d'écriture du code. Maintenez une échelle saine : 1 tâche atomique doit représenter une étape significative de résolution du problème.
2. Perte de l'invariant global (Local Optimum Trap) : Chaque tâche atomique peut être exécutée parfaitement à son niveau, mais les modules peuvent ne pas s'intégrer correctement si un contrat d'interface commun n'a pas été fixé au préalable (Contract-First Design).
3. Accumulation de déchets non commités : Si vous ne faites pas git commit après chaque tâche atomique, après 5 itérations, l'arbre de travail devient un chaos de centaines de modifications obscures, et les avantages de l'atomicité sont totalement perdus.