--- title: "Une tâche n’est pas un projet" summary: "L’erreur élémentaire qui consiste à garder la découverte, les décisions, l’implémentation et la revue dans une seule tâche." slug: "une-tache-n-est-pas-un-projet" language: "fr" publishedAt: "2026-09-14" updatedAt: null tags: - "processus" - "taches" - "agents" - "bonnes-pratiques" translationOf: "pt/uma-tarefa-nao-e-um-projeto" translationStatus: "current" --- Une tâche n’est pas un projet. Cela paraît évident. Pourtant, c’est l’une des erreurs les plus courantes lorsqu’on travaille avec des agents. On commence par demander une analyse. Puis un plan. Puis une implémentation. Puis un changement de direction. Puis une revue. Le tout au même endroit. À la fin, la tâche est devenue un dépôt de décisions, d’exceptions et de demandes anciennes. L’agent perd ses repères. La personne aussi. ## Le problème n’est pas de continuer Continuer une tâche n’est pas toujours une erreur. Le problème commence lorsqu’elle n’a plus d’objectif clair. Une bonne tâche répond à trois questions : - qu’est-ce qui doit être résolu maintenant ; - qu’est-ce qui peut être modifié ; - comment saurons-nous qu’elle est terminée. Sans cela, chaque nouvelle demande peut changer le sens de tout ce qui précède. « Ajoute aussi l’authentification. » « D’abord, change l’architecture. » « Oublie le plan et fais-le tout de suite. » « Reviens à l’idée précédente. » Chaque phrase peut être légitime. Mais ensemble, sans nouvelle délimitation, elles produisent du bruit. ## De nombreuses itérations augmentent aussi le risque d’hallucination Un long chat ne conserve pas seulement des décisions. Il accumule des brouillons, des hypothèses, des erreurs corrigées, des instructions dépassées et des informations incomplètes. Après de nombreuses itérations, l’agent peut traiter une ancienne hypothèse comme un fait. Il peut citer une décision qui n’a jamais été approuvée. Il peut affirmer avoir validé quelque chose qui a seulement été discuté. Il peut combler une lacune avec une réponse plausible, mais fausse. C’est une hallucination. Elle ne survient pas seulement par manque de capacité. Elle survient aussi lorsque le contexte est devenu confus. Plus une tâche mélange les objectifs et les versions d’une même décision, plus il devient difficile de distinguer ce qui est actuel, ce qui a été abandonné et ce qui doit encore être confirmé. N’utilisez pas un long chat comme seule source de vérité. Les décisions importantes doivent sortir de la conversation et entrer dans les fichiers, les tests, les plans ou la documentation. ## Une tâche doit tenir en une phrase Si vous ne pouvez pas résumer une tâche en une phrase, elle est probablement trop grande. Mauvais exemple : ```txt Comprends le projet, définis l’architecture, construis le site, écris le contenu, révise le design et publie-le. ``` De meilleurs exemples : ```txt Analyse la structure actuelle du projet. Ne modifie aucun fichier. Liste les risques, les lacunes et les décisions en attente. ``` ```txt Crée un plan incrémental pour l’internationalisation. Ne l’implémente pas. Indique les fichiers probables, les dépendances et les validations. ``` ```txt Implémente uniquement le sélecteur de langue défini dans l’étape 1 du plan approuvé. ``` La différence n’est pas de la bureaucratie. C’est de la direction. ## Mélanger les phases crée de fausses certitudes Lorsque découverte, planification et implémentation se déroulent dans la même tâche, il est facile de confondre une hypothèse avec une décision. L’agent peut commencer à modifier avant de comprendre le problème. Il peut créer une solution pour une exigence qui va encore changer. Il peut suivre une ancienne décision abandonnée au milieu de la conversation. Le résultat semble progresser. Mais il accumule du travail à refaire. Séparer les phases ne ralentit pas le processus. Cela évite d’aller vite dans la mauvaise direction. ## Divisez selon le résultat, pas selon la taille de la demande Il ne suffit pas de découper une grande demande en parties aléatoires. La division doit avoir du sens. Une tâche de diagnostic produit une compréhension. Une tâche de planification produit une séquence approuvée. Une tâche d’implémentation produit un changement vérifiable. Une tâche de revue produit des problèmes, des risques ou des ajustements. Chacune a une sortie différente. ```txt Diagnostic → compréhension de l’état actuel Planification → un plan petit et vérifiable Implémentation → un changement validé Revue → une évaluation objective du résultat ``` Lorsque la sortie est claire, il est plus facile de savoir quand terminer. ## Le contexte doit survivre à la tâche Une tâche se termine. Les connaissances utiles ne peuvent pas se terminer avec elle. Les décisions importantes doivent aller dans les fichiers du projet : - `AGENTS.md` pour les règles durables ; - `README.md` pour le contexte général ; - `PLANS.md` pour les étapes approuvées ; - `docs/` pour les décisions, l’architecture et les risques ; - les tests et le code pour les comportements vérifiables. Cela réduit la dépendance à la mémoire d’une longue conversation. La tâche suivante n’a pas besoin de deviner ce qui s’est passé. Elle commence avec les bons enregistrements. ## Un flux simple Utilisez une tâche pour chaque moment. 1. Comprenez le problème. 2. Enregistrez ce qui a été décidé. 3. Planifiez une petite étape. 4. Implémentez uniquement cette étape. 5. Validez. 6. Ouvrez la tâche suivante avec le résultat précédent comme contexte. Il n’est pas nécessaire de créer une tâche pour chaque phrase. Il est nécessaire de créer une nouvelle tâche lorsque l’objectif change. C’est la frontière. ## Terminer est aussi un travail De nombreuses tâches restent ouvertes parce que personne n’a déclaré la fin. Lorsque vous avez terminé, enregistrez : - ce qui a été fait ; - les fichiers modifiés ; - les validations exécutées ; - les risques restants ; - la prochaine étape recommandée. Puis fermez-la. Une tâche fermée avec clarté est plus utile qu’une tâche interminable avec beaucoup d’historique. ## La règle élémentaire N’essayez pas de conduire un projet entier dans une seule tâche. Donnez à chaque tâche un objectif, une limite et une sortie. Enregistrez les décisions qui doivent survivre. Le vibe coding n’est pas une conversation sans fin. C’est une suite de décisions qui peuvent être comprises, revues et poursuivies.