lukaszbadowski/gérer-projets-logiciels-ia

Gérer des projets logiciels avec l'IA

Transformez un travail de livraison assisté par IA, souvent vague, en un système d'exécution contrôlé pour un seul opérateur humain. Suscitez le cadre, obtenez une approbation consciente de la décomposition en récits, exécutez via une petite file d'attente de tâches routées dans des fichiers durables, vérifiez avec des preuves, et ne clôturez qu'après que chaque critère de succès ait passé sa vérification de bout en bout.

Gardez l'état durable du projet neutre vis-à-vis des fournisseurs. Le passage entre Codex, Claude Code ou un autre agent compatible ne doit pas nécessiter la conversion des fichiers pm/.

Démarrage rapide

1. Inspectez l'espace de travail. Si pm/ existe, lisez pm/STATE.md, puis pm/TASKS.md ; comblez les lacunes au lieu de régénérer le système.
2. Si aucun système de projet n'existe, exécutez CP1 : posez les questions d'élicitation et rédigez le cadre dans pm/PLAN.md.
3. Créez les quatre fichiers canoniques à partir de references/file-templates.md.
4. Pilotez le travail via la décomposition CP2, la file d'attente CP3, la boucle d'exécution et l'acceptation finale CP4.

Protocole de point de contrôle opérateur

Co-créez la décomposition avec l'opérateur. Enregistrez chaque approbation avec une date dans pm/PLAN.md ou pm/TASKS.md.

• CP1 — Cadre. Suscitez et obtenez l'approbation de l'objectif, des critères de succès, des vérifications finales, du périmètre, des contraintes et des hypothèses structurelles.
• CP2 — Décomposition. Présentez les récits dans le langage de l'opérateur. Donnez à chaque récit des critères d'acceptation et reliez-les aux critères de succès qu'ils servent. Résolvez les décisions structurelles ouvertes avec l'opérateur.
• CP3 — File d'attente. Présentez la file d'attente ordonnée des tâches avec les niveaux de routage avant le début de l'exécution.
• CP4 — Acceptation finale. Réexécutez chaque vérification finale CP1 de bout en bout, liez les preuves, présentez le rapport d'acceptation et obtenez la validation de clôture. Les tâches terminées seules ne signifient pas que le projet est fini.

Utilisez ces règles permanentes :

• Comblez les petites lacunes dans un cadre approuvé avec des hypothèses consignées dans pm/DECISIONS.md.
• Renvoyez les changements structurels — périmètre, récits, critères de succès ou niveau d'acceptation — au point de contrôle correspondant et enregistrez le compromis.
• Demandez au CP1 : Quel résultat doit exister, et pour qui ? Comment l'opérateur le vérifiera-t-il personnellement ? Qu'est-ce qui est hors périmètre ? Quelles contraintes sont fixes ? Qu'est-ce qui existe déjà ? Qu'est-ce qui est le plus risqué ou peu clair ? Quel niveau de révision l'opérateur souhaite-t-il ?
• En mode sauvetage, reconstruisez le cadre et la décomposition implicites à partir de l'espace de travail, présentez-les pour confirmation, puis reconstruisez la file d'attente.

Fichiers de projet canoniques

Maintenez quatre fichiers sous pm/ :

• pm/PLAN.md — objectif, critères de succès, périmètre, récits, traçabilité, approbations
• pm/TASKS.md — file d'attente ordonnée des tâches, IDs stables, routage, vérification, preuves
• pm/STATE.md — état courant, notes de passage de relais, journal de session
• pm/DECISIONS.md — décisions, hypothèses, risques, problèmes, journal des modifications

Ne créez pas plus de fichiers de contrôle par défaut. Ajoutez pm/CONSTRAINTS.md, pm/RELEASE.md ou pm/RESEARCH.md seulement lorsque la branche correspondante est active.

Gardez le fichier d'entrée spécifique au produit — tel que AGENTS.md ou CLAUDE.md — court et navigationnel : pointez vers pm/STATE.md, puis pm/TASKS.md, avec pm/PLAN.md comme périmètre approuvé. Reflétez les informations durables des outils de planification locaux de session dans pm/TASKS.md et pm/STATE.md.

Router le travail par capacité

Attribuez un niveau Route: neutre vis-à-vis du fournisseur lorsque chaque tâche entre dans la file d'attente :

Niveau	Utilisation pour
heavy	planification, décomposition, architecture, débogage ambigu, refontes transversales, révision risquée, acceptation finale
standard	implémentation bornée, tests, modifications de complexité moyenne
light	recherche dans le dépôt, résumés, modifications mécaniques, documentation, formatage, tri des logs

Routez chaque tâche vers le niveau le moins coûteux qui peut la réaliser de manière fiable :

• Gardez le thread principal suffisamment capable pour diriger : rédiger des briefs, router le travail, juger les preuves et signer.
• Passez à un niveau supérieur après deux tentatives échouées ou un résultat de faible confiance sur la même tâche ; enregistrez l'escalade.
• Exigez que le niveau du relecteur soit au moins celui du rédacteur. Donnez aux changements risqués ou transversaux une revue heavy dans un nouveau contexte. Ne laissez jamais un travailleur light s'auto-approuver.
• Gardez les noms de modèles hors de pm/ ; les alias et prix des produits changent tandis que les niveaux de capacité restent utiles.
• Lisez references/agent-routing.md avant de configurer les travailleurs pour Codex, Claude Code ou un autre agent.

Construire d'abord le contexte

• Extrayez l'objectif réel, les utilisateurs, le niveau d'acceptation, les dépendances et les attentes de livraison.
• Traitez les dates, budgets, approbations, calendriers fournisseurs ou fenêtres de lancement comme des entrées de première classe uniquement lorsqu'ils sont explicites.
• Cherchez les fichiers pm/ existants, briefs de tâches, backlogs, conceptions, ADRs, stratégies de test, runbooks, journaux de risques et fichiers d'instructions d'agent avant d'inventer de nouveaux artefacts.
• En travail de sauvetage, évaluez la clarté de l'objectif, le périmètre, les dépendances, la qualité de l'acceptation, l'hygiène des risques, la lisibilité du contexte, les permissions et la préparation à la livraison.

Choisir le mode de contrôle le plus petit

• Par défaut, utilisez solo-operator : un opérateur dirigeant les agents IA.
• Ajoutez external-constraint pour une date fixe réelle, une porte de conformité, une approbation, une dépendance fournisseur, un quota ou une fenêtre de lancement.
• Ajoutez feedback-heavy lorsque la découverte, l'apprentissage utilisateur ou l'itération UX domine.
• Ajoutez release-safety lorsque la livraison nécessite une coupure, un rollback, une surveillance ou des notes d'exploitation.

Dimensionner les unités d'exécution

• Utilisez des récits pour la valeur visible par l'utilisateur et l'acceptation. Utilisez des jalons uniquement pour grouper le travail. Exécutez via des tâches.
• Faites en sorte que chaque tâche tienne en une seule exécution d'agent ciblée et une seule révision rapide de l'opérateur : un sous-système, une interface, un document ou une surface de test, et un diff révisable.
• Donnez à chaque tâche un ID stable, une référence de récit, un niveau de routage, un périmètre, une dépendance, une condition de fin, une vérification exacte, un champ de preuve et un point d'arrêt explicite.
• Divisez avant l'exécution lorsqu'une tâche couvre des zones non liées ou plusieurs validations indépendantes. Gardez l'historique : les tâches enfants reçoivent de nouveaux IDs ; les tâches remplacées deviennent superseded.
• Après avoir terminé une tâche, remplissez ses preuves et mettez à jour pm/STATE.md dans la même exécution.

Maintenir la traçabilité

• Mappez chaque critère de succès à au moins un récit et chaque récit à au moins une tâche.
• Marquez un récit comme terminé uniquement après que toutes ses tâches et critères d'acceptation sont vérifiés avec des preuves.
• Marquez le projet comme terminé uniquement après que CP4 re-vérifie chaque critère de succès de bout en bout.

Exécuter une boucle qualité d'abord

• Définissez la plus petite preuve crédible avant l'implémentation : reproduction d'échec, test automatisé, résultat attendu, comparaison de captures d'écran, vérification de contrat ou procédure manuelle exacte.
• Utilisez explorer -> planifier -> implémenter -> vérifier -> réviser -> documenter.
• Enregistrez les commandes, résultats, captures d'écran, métriques et notes de révision plutôt que les seules conclusions.
• Définissez des budgets de changement pour les tâches risquées : fichiers autorisés, interfaces stables, sécurité des données, rollback et déclencheurs d'escalade.
• Pilotez les changements répétitifs ou automatisés sur un échantillon représentatif restreint avant de passer à l'échelle.
• Après deux échecs identiques, arrêtez et améliorez l'environnement, la documentation, la règle ou le validateur ; redémarrez avec un contexte propre.
• Traitez les échecs répétés des agents comme un retour système. Améliorez le processus, pas seulement la réponse actuelle.

Déléguer en toute sécurité

• Déléguez uniquement un travail borné, prêt pour l'autonomie. Gardez les objectifs, la décomposition, la synthèse et la validation de clôture dans le thread principal.
• Donnez à chaque travailleur un brief écrit : ID de tâche, objectif, périmètre, contraintes, commandes de vérification, preuves attendues, point d'arrêt, déclencheur d'escalade et niveau de routage.
• Gardez le travail minuscule, étroitement couplé ou hautement interactif dans le thread principal lorsque les frais généraux de délégation dépassent ses avantages.
• Privilégiez les validateurs déterministes pour les règles sans exception telles que les tests requis, les restrictions de chemin, le formatage ou le scan de secrets.
• Appliquez le moindre privilège, les limites de confiance, les règles de gestion des secrets et l'approbation explicite de l'opérateur pour les actions risquées.

Références

• Lisez references/file-templates.md lors de la création ou de la réparation de pm/.
• Lisez references/worked-example.md pour un exemple complet et compact.
• Lisez references/project-rulebook.md lors de l'audit ou du sauvetage d'un projet.
• Lisez references/external-constraints.md uniquement pour les contraintes externes réelles ou le risque de livraison en production.
• Lisez references/ai-agent-practices.md pour des conseils approfondis sur la mémoire durable, le contexte, la délégation, les évaluations et les garde-fous.
• Lisez references/agent-routing.md lors du mappage des niveaux aux capacités actuelles d'un produit.
• Lisez references/source-anchors.md lorsque la provenance ou les conseils volatils du fournisseur sont importants.
• Chargez uniquement la plus petite référence pertinente.

Normes de sortie

• Rédigez des artefacts concrets, prêts pour la décision, sous forme impérative.
• Rapportez d'abord le statut du point de contrôle, puis les IDs de tâche avant le statut en prose.
• Formatez les tâches comme suit : Task ID, Task, Story, Route, Scope, Depends on, Done when, Verify with, Evidence, Stop after, Status.
• Privilégiez un diff révisable par tâche.
• Gardez les noms de modèles hors des fichiers de projet durables.
• N'ajoutez pas de plans de dates, budgets, workflows d'approbation, cérémonies récurrentes ou portes d'étape à moins que le projet n'en ait vraiment besoin.
• Vérifiez les affirmations actuelles concernant le modèle, les benchmarks, les prix ou les workflows fournisseur auprès de sources primaires avant de les utiliser.