40 points par GN⁺ 2025-09-08 | 1 commentaires | Partager sur WhatsApp
  • Les développeurs en sont désormais au stade où ils apprennent à collaborer avec l’IA, et Claude révèle toute sa valeur non pas comme simple chatbot, mais lorsqu’il est utilisé comme framework
  • Dans la communauté, les tentatives se multiplient pour définir comment configurer et exploiter Claude, au point que l’on parle de Claude Code Framework Wars tant les expérimentations sont actives
  • Cela fait émerger une nouvelle manière d’utiliser Claude dans des rôles variés comme chef de projet, architecte, développeur, relecteur et plus encore
  • Concevoir un framework suppose de prendre 8 décisions majeures autour de la gestion du travail, de la fourniture de consignes, de la collaboration entre agents, de l’exécution des sessions, de l’accès aux outils, du développement du code, de la livraison et de la préservation du contexte
  • La leçon essentielle est que l’IA ne remplace pas les développeurs, mais devient un coéquipier qui démultiplie la productivité grâce à des règles structurées et à des rôles bien définis

Introduction

  • Idée clé : considérer Claude non comme un simple outil conversationnel, mais comme un framework, capable de produire des résultats prévisibles et utiles grâce à des règles claires et à des flux de travail définis
    • Les développeurs se déplacent du codage vers des rôles à forte valeur ajoutée (gestion de projet, conception, architecture)
    • Le framework Claude Code fonctionne à partir de prompts structurés, sans écrire de code
  • Claude Code Framework Wars : la communauté des développeurs expérimente diverses approches pour un usage productif de l’IA
    • Des dizaines de projets open source rivalisent en définissant flux de travail et structures de rôles
    • Exemples : Agent OS, Claude-Flow

Principaux choix à considérer lors de la conception d’un framework

1. Où gérer le travail

  • Il faut définir une source de tâches à laquelle Claude peut se référer
    • Backlog en Markdown : gestion des tâches sous forme de liste de choses à faire en Markdown
    • Texte structuré : transformer les spécifications produit en tâches
    • Issues / tickets : stocker les spécifications dans GitHub Issues ou des tickets Jira, liés à la revue de code
  • L’essentiel : les tâches doivent être stockées dans un emplacement accessible à Claude et facile à suivre

2. Comment fournir des guides à Claude

  • Au lieu de prompts vagues, il faut donner des consignes à Claude via une structure claire
    • Bibliothèque de commandes : commandes slash prédéfinies comme /create-tasks, /review
    • Standards de code : préciser la stack technique et les règles de développement
    • Définition du terminé : encoder les critères d’achèvement d’une tâche
    • Hooks de validation déclenchés : imposer linting et tests pour toute modification
    • Claude relecteur : Claude assure à la fois le développement et la revue
  • L’essentiel : des règles claires et répétables améliorent la qualité du travail produit par Claude

3. Structure de collaboration entre agents

  • Quand plusieurs agents Claude sont utilisés, la coordination se fait par les rôles et la planification
    • Simulation de rôles : l’IA tient les rôles de PM, architecte, développeur, testeur
    • Traitement en essaim parallèle : exécution simultanée de plusieurs agents dans un flux structuré allant de la spécification → pseudo-code → code → tests
    • Artifacts natifs au dépôt : stocker tâches, journaux et décisions d’architecture (ADR) dans la codebase pour conserver la mémoire
  • L’essentiel : la coordination évite les conflits entre plusieurs travailleurs IA

4. Mode d’exécution des sessions

  • Pour éviter le chaos dans les sorties de l’IA, les sessions servent d’environnement de travail
    • Orchestration du terminal : Claude contrôle commandes, fenêtres et logs
    • Worktrees parallèles : exécuter plusieurs branches en parallèle avec Git Worktrees
    • Conteneurs parallèles : exécuter Claude dans des conteneurs isolés pour éviter les conflits
  • L’essentiel : le travail en parallèle maximise la productivité sans conflit

4. Mode de fonctionnement des sessions

  • Pour éviter le chaos dans les sorties de l’IA, les sessions servent d’environnement de travail
    • Orchestration du terminal : Claude contrôle commandes, fenêtres et logs
    • Worktrees parallèles : exécuter plusieurs branches en parallèle avec Git Worktrees
    • Conteneurs parallèles : exécuter Claude dans des conteneurs isolés pour éviter les conflits
  • L’essentiel : le travail en parallèle maximise la productivité sans conflit

5. L’accès de Claude aux outils

  • Configurer Claude pour qu’il exploite sa connaissance de l’ensemble de la stack technique
    • Intégration MCP : connexion au navigateur, à la base de données, au test runner et au framework d’automatisation UI
    • Bibliothèque d’outils personnalisés : construite avec des scripts shell et des commandes
    • Accesseur à la base de données : outil puissant d’accès aux bases de données
    • Hooks de test et de validation : lancer les tests avec Vitest, Jest, etc. avant de terminer une tâche
  • L’essentiel : l’intégration d’outils fait passer Claude du simple autocompléteur à un membre actif de l’équipe

6. Façon de développer le code

  • Claude peut tenir différents rôles selon les besoins
    • Chef de projet (PM) : transformer les spécifications produit en tâches et backlog
    • Architecte : concevoir la structure globale, définir les interfaces et fixer les règles avant le codage
    • Implémenteur : écrire le code conformément aux tests et aux standards
    • QA : examiner les problèmes dans les tâches
    • Relecteur : auditer la qualité des PR, la lisibilité et les risques
  • L’essentiel : utiliser l’IA sur l’ensemble du cycle de vie logiciel

7. Mode de livraison du code

  • Définir comment le code atteint le dépôt
    • Petites différences : l’IA traite un ticket et crée une petite PR, toujours relue
    • Expérimentation : déployer les changements derrière des feature flags
    • Scaffold d’application complet : construire et déployer une application entière à partir de prompts de haut niveau
  • L’essentiel : choisir entre des itérations sûres pour la production ou du scaffold pour le prototypage

8. Façon de préserver le contexte

  • Résoudre le problème d’oubli de Claude grâce à une mémoire de framework
    • Documents et journal : maintenir à jour CLAUDE.md, les notes d’architecture et le journal du projet
    • Mémoire persistante et points de contrôle : résumé des travaux récents, vérification de la santé du projet, conservation des décisions
  • L’essentiel : sans mémoire, l’IA répète les erreurs ; avec de la mémoire, la progression gagne en complexité

Comment les assembler

  • Considérer ces choix comme un menu, sans devoir tout configurer d’un coup
    • Configuration débutante : backlog Markdown + différences par ticket
    • Équipe structurée : spécifications produit + standards + simulation de rôles
    • Approche orientée expérimentation : artifacts de dépôt + sessions parallèles
    • Mode prototype : app builder + scaffold documentaire

Conclusion et implications

  • Leçon essentielle : Claude donne ses meilleurs résultats dans un environnement structuré
    • Il ne remplace pas le rôle du développeur ; il réduit le travail boilerplate et permet de se concentrer sur la définition des spécifications, la revue de conception et la définition de l’architecture
    • Si le travail est mal cadré, il peut très vite dérailler ; une gestion structurée est indispensable
  • Nous n’en sommes qu’aux débuts, mais les frameworks font converger l’IA non vers une boîte magique, mais vers un ensemble de coéquipiers pilotables
    • Plus on fournit de structure, plus la valeur retournée est grande
  • À travers des projets open source, la communauté expérimente divers frameworks et cherche des usages productifs de l’IA
  • Les développeurs peuvent utiliser Claude de manière systématique pour se concentrer sur des tâches à forte valeur ajoutée et intégrer l’IA comme membre de l’équipe afin de maximiser la productivité

1 commentaires

 
GN⁺ 2025-09-08
Avis Hacker News
  • J’ai essayé plusieurs « frameworks » pour Claude Code, mais objectivement je ne suis pas convaincu qu’ils améliorent vraiment les performances.
    J’ai l’impression qu’ils ajoutent surtout tout un rituel autour d’un processus complexe, sans qu’on sache vraiment pourquoi.
    Ce genre d’approche par framework ne me semble pas aligné avec l’objectif d’entraînement du modèle.
    En pratique, on balance au modèle des informations inutiles et on pollue le contexte de force pour le faire rentrer dans « le processus que j’ai défini ».
    Je pense qu’il est plus important d’éliminer cette pollution du contexte et d’améliorer progressivement les choses en ne fournissant que les informations réellement nécessaires à la tâche.
    Ce type de collaboration plus traditionnel me paraît mieux adapté s’il se déroule hors du contexte de l’agent, qui reste limité.

    • Cet article ne mentionne absolument pas les subagents, donc je me demande quand il a été écrit.
      Je délègue à des subagents des tâches comme « aller chercher dans la memory bank uniquement les informations pertinentes pour la tâche en cours » ou « lancer les tests et ne remonter que les échecs et la couverture ».
      Ça m’a permis d’éviter que le contexte de l’agent principal se remplisse trop vite.
      https://docs.anthropic.com/en/docs/claude-code/sub-agents

    • Depuis que j’ai adopté quelques pratiques concrètes comme les dev containers et les worktrees, la vie est devenue plus simple.
      J’ai même créé mon propre « framework » en shell script pour gérer les fichiers du projet et la création de worktrees, et ça m’a pris à peine deux jours.
      J’apprécie le fait de ne dépendre d’aucun outil particulier.
      Je suis d’accord sur le fait que la pollution du contexte est une vraie contrainte à prendre en compte.
      J’en ai particulièrement pris conscience en voyant que les définitions d’endpoints MCP occupaient une grande partie de mon contexte, environ 20 000 tokens, donc je tiens désormais compte de cet aspect quand je choisis un MCP.

    • J’ai eu l’impression que c’était très proche de la situation d’un vrai chef de projet.

  • Ce que j’aimerais, c’est que l’utilisation de Claude inclue dans la proposition une étape où il commence par poser des questions sur les zones floues.
    Si on donne à un vrai ingénieur uniquement les exigences et le résultat attendu, il va naturellement poser des questions complémentaires avant d’exécuter quoi que ce soit pour s’assurer d’avoir bien compris.
    J’espère que Claude pourra aussi automatiser cette phase de vérification.

    • Ça rappelle un peu le deep research tool d’OpenAI.
      Je constate souvent que le fait d’ignorer complètement les ambiguïtés dans la question provoque beaucoup d’erreurs.
  • Quand vous appliquez ce type de framework, je serais curieux de savoir quel niveau d’autonomie vous laissez réellement, et dans quel environnement vous l’utilisez, greenfield ou brownfield.
    J’aimerais aussi savoir si certains ont déjà obtenu des résultats en toute confiance avec Claude Code branché sur du logiciel d’entreprise.
    Dans mon entreprise, j’ai un accès assez libre à Claude Code, mais sur ma base de code, dès qu’il y a du frontend UI ou Playwright, les résultats deviennent irréguliers.
    Je serais intéressé par des retours concrets sur la quantité de code inutile laissée derrière, la fatigue de collaboration avec les collègues, la taille des pull requests, le coût d’inférence, la gestion de la parallélisation, etc.
    Les README me donnent parfois l’impression d’être des documents marketing plus que de la documentation, tant ils sont remplis de jargon système, d’emojis et de méthodes de rangement de toolbox excessivement personnalisées.
    Au final, je me dis qu’Anthropic finira peut-être par intégrer directement ce genre de fonctionnalités dans son propre CLI.
    Personnellement, j’utilise un modèle de reasoning avec une spec de 10 pages, des lint/type check/formatter/hook stricts, une checklist de travail et même du TDD red/green, puis je dis simplement « go » à GPT-5 pour qu’il produise automatiquement le résultat nécessaire.
    Avec les mêmes outils, n’importe qui peut facilement se construire son propre système.

    • Ça ne fait que trois semaines environ que j’utilise Claude Code, mais j’ai récemment obtenu des résultats impressionnants avec une structure basée sur les rôles, par exemple des personas, sur une grosse base de code Elixir/Phoenix de plus de 500 000 SLOC.
      J’utilise le plan Max à 200 $, donc le coût d’inférence est fixe.
      Les résultats ont été particulièrement nets dans les situations greenfield, par exemple pour l’ajout de nouvelles fonctionnalités.
      Pour les refactorings complexes ou les changements profonds du système, ça avance aussi pas mal s’il existe une bonne documentation de conception, mais là où la documentation manque, l’efficacité chute rapidement.
      Au début, j’obtenais souvent du « mauvais code » — avec des problèmes de style, de réutilisabilité ou de maintenabilité — mais depuis que j’ai renforcé le fichier CLAUDE.md et obligé la persona développeur à toujours utiliser le subagent elixir-code-reviewer, la qualité du code s’est nettement améliorée.
      Notre plateforme est open source, donc je partage ici notre configuration actuelle de commandes Claude et de subagents.
      https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
  • Le billet de blog avait un style très marqué LLM.
    Les informations sont utiles, mais c’est amusant d’apprendre des choses sur l’IA à partir d’une IA.

    • J’ai l’impression que beaucoup de contenus sur l’IA donnent cette sensation en ce moment.
      En pratique, sauf pour des tâches non spécialisées, il faut surveiller Claude Code de près et intervenir immédiatement s’il part dans la mauvaise direction.
      On ne peut pas lui donner trop de permissions pour des raisons de sécurité, ni cesser de vérifier quelles commandes il exécute réellement.
      Les « frameworks » actuels ont encore un long chemin à parcourir et, pour l’instant, le plus réaliste est sans doute de les considérer comme « un stagiaire junior qui crache du code à toute vitesse ».

    • Il est possible que l’auteur n’ait pas vraiment vérifié les repos, ou qu’il se soit basé sur une recherche limitée.
      Par exemple, superClaude n’est pas un serveur MCP, et metaGPT ne semble pas compatible avec Claude Code.

  • Je me suis toujours demandé pourquoi on ne laissait pas les agents gérer eux-mêmes leur propre contexte, comme des humains.
    Je ne comprends pas pourquoi tout l’historique des tâches précédentes est systématiquement réinjecté à chaque fois.
    Si on laissait l’agent décider quel contexte mérite d’être conservé et apprendre par lui-même les avantages et inconvénients de cette gestion, il me semble qu’il deviendrait meilleur dans l’exécution de chaque tâche.

  • Au fond, on retrouve encore ici la textbook « bitter lesson ».
    Les gens créent toutes sortes de « frameworks », mais la génération suivante de modèles finit par tout rendre obsolète.
    http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • J’ai été assez surpris que BMAD-method ne soit pas mentionné.
    D’après mon expérience, BMAD-method est le meilleur complément à Claude Code.

    • Je suis curieux de savoir ce qu’est BMAD-method.
      Je voudrais savoir si c’est simplement de l’ordre du système prompt, ou ce qui le rend si utile selon toi.
      https://github.com/bmad-code-org/BMAD-METHOD

    • Le système BMAD ressemble à AgentOS, présenté dans le billet.
      Ce type d’ingénierie du contexte a bien fonctionné pour moi, et j’ai directement demandé à Claude de générer des commandes et des agents, puis je les ai modifiés selon mes besoins.
      Dernièrement, j’utilise aussi activement JSON et Markdown pour partager le contexte.

    • taskmaster aussi, mais il n’est pas dans la liste.

  • La gestion du contexte me donne l’impression d’être face à de la programmation bas niveau.
    J’ai l’impression qu’il faut charger exactement les bonnes valeurs dans les registres du CPU pour obtenir les bonnes opérations.
    La différence, c’est que nous avons bien moins de contrôle sur les droits d’ajout ou de suppression de contexte selon la tâche.

  • J’ai essayé le framework B-MAD, et la différence d’efficacité a été telle que je ne peux plus travailler sans cet outil.
    J’espère qu’on verra encore plus de frameworks de ce genre à l’avenir.

  • Je me demande si certains ont réellement utilisé ce type de frameworks.
    J’aimerais savoir si ça apporte de vrais résultats ou si ce n’est qu’une hype passagère.

    • Quand on regarde parfois ces frameworks de près, ils sont souvent construits presque entièrement sur eux-mêmes.
      Le résultat est prévisible : des fonctionnalités qui débordent dans tous les sens, sans véritable validation, une documentation bancale, et un ensemble rempli de claude-isms.
      En pratique, on dirait surtout des outils utilisables uniquement sur quelques projets qui intéressent leur créateur.