Travailler avec l’IA et progresser par effet composé

• Guide pratique structuré autour de cinq principes de collaboration avec l’IA : fournir du contexte, encoder ses préférences, automatiser la validation, élargir la délégation et boucler la boucle de feedback
• Tous les livrables (code, documents, analyses, décisions) s’accumulent comme contexte pour la session suivante, et les corrections sont réinjectées dans la configuration pour réduire les erreurs futures selon une logique d’effet composé
• Présente des méthodes concrètes pour gérer le comportement du modèle et les workflows comme du code à l’aide de CLAUDE.md, de fichiers de skills, de guides, etc.
• Inclut des stratégies de délégation pour augmenter le débit de travail via l’exécution de sessions en parallèle, la validation croisée entre modèles et le contrôle à distance
• Ces principes constituent un cadre générique applicable non seulement à l’IA, mais aussi à la collaboration entre humains au sein d’une équipe

---

Construire le contexte comme une infrastructure

• En rangeant tout le code dans ~/src et le travail de connaissance dans ~/vault (projects/, notes/, kb/, etc.), il devient plus facile pour le modèle de rechercher du contexte avec grep ou glob
• Il est possible de connecter au modèle le contexte de l’organisation (Slack, Drive, Mail, etc.) via MCP (Model Context Protocol)
  • Maintenir un INDEX.md par projet, en notant pour chaque entrée l’URL, le responsable et une description du contenu sous forme de commentaires
  • Une simple liste d’URL oblige le modèle à ouvrir tous les liens ; ajouter des commentaires permet donc d’éviter de gaspiller du contexte
• Comme le modèle repart de zéro à chaque nouvelle session, il faut rédiger un CLAUDE.md par projet comme un document d’onboarding pour un nouvel arrivant
  • Y inclure un glossaire des acronymes, les noms de code du projet, les distinctions entre homonymes, etc.
  • Définir un ordre de lecture du type INDEX.md → TODOS.md → notes thématiques spécifiques
• Séparer la couche mémoire en deux niveaux
  • ~/vault : stockage des informations factuelles (facts) comme l’état du projet, les livrables ou les connaissances métier
  • ~/.claude (CLAUDE.md, skills/, guides/) : stockage de la configuration comme les préférences, les workflows ou les goûts personnels

Encoder ses préférences dans la configuration

• Utiliser ~/.claude/CLAUDE.md

  • Sert de contrat de comportement lu par Claude au début de chaque session
  • Peut inclure des règles de comportement : parler directement, contredire en cas de désaccord, dire honnêtement quand quelque chose est incertain, en cas d’échec rechercher la cause racine avant de réessayer, ne pas reformater en dehors du périmètre de la tâche, etc.
  • On peut aussi y définir une section teaching qui explique en 1 à 2 phrases les termes clés d’un nouveau système ou domaine

• Distinguer la portée selon le répertoire

  • Global (~/.claude/CLAUDE.md) : comportements, objectifs de long terme, préférences d’apprentissage et autres réglages applicables partout
  • Racine du dépôt : règles propres au repo comme le linting, les conventions de nommage ou de PR
  • Répertoire du projet : contexte spécifique au projet, comme la structure des dossiers ou la connaissance métier
  • Claude Code, lorsqu’il démarre dans un sous-répertoire, remonte l’arborescence et charge chaque CLAUDE.md

• Stratégie de découpage quand CLAUDE.md devient trop long

  • Un CLAUDE.md trop long devient une taxe de contexte puisqu’il est entièrement chargé à chaque session
  • Au lieu d’utiliser @import, on peut simplement indiquer dans CLAUDE.md les chemins vers les fichiers de guide à lire si nécessaire, pour mettre en place un chargement paresseux (lazy loading)
  • Exemple : ~/.claude/guides/writing.md pour l’écriture, ~/.claude/guides/evals.md pour les tâches d’évaluation

• Transformer en skills les tâches répétées au moins une fois par semaine

  • Un skill est un fichier de workflow en Markdown contenant un nom, des déclencheurs et une procédure
  • /polish : examiner le diff d’un artefact, lancer un eval s’il existe des métriques, vérifier avec Chrome s’il s’agit d’un rendu navigateur, sinon exécuter le code puis vérifier sorties/erreurs → itérer puis rédiger un brouillon de PR
  • /write : entretien pour définir le plan → création d’un sous-agent de recherche → rédaction d’un brouillon → feedback d’un critique hostile → itération
  • /daily : lire le calendrier, Slack, les PR et le journal de la veille pour écrire les priorités du jour
  • SKILL.md doit se concentrer sur le workflow et le routage ; les connaissances comme les templates ou scripts sont séparées dans d’autres fichiers pour n’être chargées qu’en cas de besoin

• Méthode de bootstrapping des skills

  • Exécuter d’abord la tâche une fois de manière interactive, puis demander au modèle d’en faire un skill
  • Lancer ensuite le skill sur une tâche identique ou similaire, et corriger la sortie dans la même session
  • Demander au modèle de mettre à jour le skill à partir des corrections et du feedback
  • Il est aussi possible de fournir des exemples du résultat souhaité pour qu’il en extraie les motifs (structure du code, structure et ton du document)

• Améliorer les skills grâce aux transcripts

  • Il est normal que la première version soit surapprise (overfit) sur la session d’origine
  • Plutôt que d’éditer directement SKILL.md, il vaut mieux corriger dans la session afin que des paires before-and-after s’accumulent dans le transcript
  • Quand la sortie devient satisfaisante, demander au modèle de fusionner le feedback dans le skill → après plusieurs tours, le skill converge

• Tout ce contexte n’est pas nécessaire pour toutes les tâches

  • Pour le brainstorming, l’exploration ou la rédaction d’ébauches, utiliser le mode simple (CLAUDE_CODE_SIMPLE=1 claude)
  • CLAUDE.md est toujours chargé, mais le harnais d’agent (hooks, skills, boucle d’outils) est désactivé, ce qui permet de penser plus directement avec le modèle

Valider pour gagner en autonomie

• Déplacer la validation vers l’amont (shift left)

  • Organiser la validation en structure d’échelle : en bas, des étapes peu coûteuses et déterministes ; en haut, des étapes plus coûteuses qui demandent du jugement
  • Au niveau le plus bas : un hook post-édition qui exécute ruff format et ruff check --fix sur les fichiers modifiés par le modèle → déterministe et sans coût en tokens
  • Aux niveaux supérieurs : tests, evals, revue par LLM, etc.

• Permettre au modèle de valider lui-même son travail

  • Si le système produit des métriques, le modèle peut lancer lui-même l’eval et optimiser en fonction
  • Si la sortie concerne un rendu navigateur, il peut l’inspecter via Claude in Chrome
  • Lors d’un build d’image Docker, il peut lire les erreurs, corriger le Dockerfile, puis relancer le build
  • Lors de la création d’un dashboard, il peut vérifier dans Chrome le rendu des tooltips, le chevauchement des labels et la cohérence entre chiffres et narration

• Pour les tâches longues, faire surveiller un modèle par un autre

  • Les longues sessions accumulent les erreurs et peuvent provoquer une dérive
  • Solution : lancer une seconde session avec un contexte vierge pour comparer le cahier des charges initial et les derniers tours de la session principale
  • Configuration en deux panneaux tmux : l’un pour le développement principal, l’autre pour le pair programmer
  • Ajouter l’instruction initiale et les prompts de suivi dans un fichier partagé, puis laisser le pair programmer vérifier périodiquement
  • Dérive d’exécution (execution drift) : le modèle exécute-t-il correctement la tâche ? — ignore-t-il des erreurs, reporte-t-il de mauvaises métriques, s’écarte-t-il de la spec ? → contrôle tactique à faire souvent
  • Dérive de direction (direction drift) : le modèle est-il en train de faire la bonne chose ? — a-t-il mal compris l’intention initiale et produit-il quelque chose d’inadapté ? → problème stratégique à vérifier de temps à autre

Passer à l’échelle par la délégation

• Déléguer des unités de travail de plus en plus grandes

  • Le mode pair programming avec tâches courtes et feedback rapide convient bien aux itérations rapides, aux analyses exploratoires et au prototypage
  • Avec un modèle plus puissant, il faut lui expliquer en amont l’intention, les contraintes et les critères de succès, puis lui déléguer une exécution end-to-end
  • On ne peut pas déléguer ce qu’on ne peut pas valider ; il faut donc définir d’abord les critères de succès et les métriques
  • Exemple : « construire un conteneur isolé pour chaque suite d’evals et lancer un smoke test → exécution complète → journalisation des métriques et transcripts → vérification de l’exactitude via un sous-agent → répétition n fois pour calculer un intervalle de confiance → génération d’un rapport puis envoi du résultat dans Slack »

• Exploiter des sessions parallèles et identifier les goulots d’étranglement

  • En déléguant de gros chantiers, on peut faire tourner 3 à 6 sessions en parallèle
  • Le goulot d’étranglement se déplace de « l’exécution du travail » vers « la rédaction d’une spec claire et la revue rapide des sorties » ; l’étape intermédiaire tend alors à disparaître
  • Si plusieurs sessions partagent le même repo, utiliser des git worktrees pour que chacune dispose de son propre checkout isolé

• Rendre les sessions faciles à observer

  • stop hook : jouer un son quand une session se termine (sur macOS, lecture de Glass.aiff avec afplay)
  • Titres de fenêtres tmux : chaque panneau est identifié par un emoji d’état (⏳ en cours, 🟢 terminé) et un court libellé généré par Haiku
  • Barre d’état Claude Code : affiche l’utilisation du contexte et le mode en cours

• Pouvoir faire des check-ins même en étant AFK

  • Grâce à la fonction /remote-control de Claude Code, on peut vérifier l’état d’exécution dans l’onglet code de l’app Claude pendant un déplacement, et fournir du contexte supplémentaire ou de nouvelles instructions à une session bloquée
  • Cela évite qu’une session reste inactive pendant des heures, tout en réservant l’usage aux cas vraiment urgents

Boucler la boucle de feedback

• Travailler de manière visible pour enrichir le contexte

  • Travailler dans des documents, dépôts ou canaux partagés permet à tous les membres de l’équipe, y compris le modèle, d’exploiter le contexte
  • Test simple : « Un nouveau membre de l’équipe peut-il reproduire le travail de la semaine dernière en s’appuyant uniquement sur le contexte partagé ? » — sinon, cela signifie qu’un contexte important est resté uniquement dans les têtes
  • Indiquer dans CLAUDE.md de publier automatiquement dans le canal de worklog une courte mise à jour et un lien vers les artefacts lorsqu’un travail concret est terminé

• Extraire des enseignements des transcripts pour mettre à jour la configuration

  • Faire relire au modèle les transcripts de sessions passées permet d’identifier des lacunes
  • Après avoir passé en revue environ 2 500 tours utilisateur anciens, une part notable contenait des formulations comme « can you also… », « did you check… », « still wrong »
  • Cela suggère soit que le modèle aurait dû accomplir spontanément certaines actions, soit qu’une étape de validation était absente ou défaillante
  • Les corrections doivent être effectuées dans la session pour que le transcript serve ensuite de donnée d’entrée aux mises à jour de CLAUDE.md ou des skills

• Refactorer et nettoyer périodiquement

  • Quand la configuration grossit, certaines règles peuvent se recouper ou entrer en conflit
  • Si le modèle ignore une règle, cela peut venir d’une contradiction avec une autre ; il faut donc refactorer pour que chaque règle ou préférence n’existe qu’à un seul endroit (les instructions critiques pouvant être répétées dans le CLAUDE.md principal)
  • Regrouper les settings.json éparpillés dans différents répertoires en les consolidant dans ~/.claude

Conclusion

• Les réglages concrets peuvent évoluer avec les progrès des modèles, mais les principes de bon contexte, encodage des préférences, validation peu coûteuse, délégation accrue et boucle de feedback fermée restent valables
• Au fond, ce processus consiste à former progressivement un collaborateur, un feedback à la fois, et il s’applique tout autant à la collaboration avec une équipe humaine
• Ces principes ne se limitent pas aux outils personnels : ils s’appliquent aussi à la conception du harnais d’agent, à la définition des normes d’équipe et à la construction de l’infrastructure organisationnelle

[xguru]

Le parcours de cette personne est intéressant :
de diplômé en psychologie à une formation via le cours de data science de Coursera
Il a rejoint Lazada à ses débuts, alors considéré comme l’Amazon de l’Asie du Sud-Est, et a été promu jusqu’au poste de VP.
Lazada a ensuite été racheté par Alibaba.
Après cela, il est passé chez Amazon comme principal scientist en recommandation/LLM.
Il fait actuellement partie du personnel technique d’Anthropic