Comment Claude Code fonctionne dans les grandes bases de code : bonnes pratiques et points de départ

• Claude Code lit directement une base de code active via l’exploration du système de fichiers sur la machine du développeur, ainsi qu’avec grep et le suivi des références, sans téléverser d’index
• Les performances dépendent fortement non seulement du modèle, mais aussi du harness constitué de CLAUDE.md, hooks, skills, plugins et serveurs MCP, ainsi que de l’ordre dans lequel ils sont mis en place
• Dans les grands dépôts, des CLAUDE.md légers et hiérarchiques, un démarrage depuis des sous-répertoires, des tests/lint ciblés et des règles d’exclusion améliorent l’efficacité de l’exploration
• L’intégration LSP fournit un suivi des définitions et références basé sur les symboles plutôt que sur la recherche de chaînes, ce qui réduit les erreurs d’exploration dans les bases de code multilingues et à grande échelle
• Une adoption réussie nécessite de revoir la configuration tous les 3 à 6 mois, ainsi qu’un DRI ou agent manager chargé de gérer plugins, permissions et règles

---

Comment Claude Code explore les grandes bases de code

• Claude Code parcourt le système de fichiers comme le ferait un ingénieur logiciel : il lit les fichiers, utilise grep pour trouver ce qu’il cherche et suit les références dans l’ensemble de la base de code
• Il fonctionne en local sur la machine du développeur, sans avoir besoin de construire, maintenir ou téléverser un index de la base de code vers un serveur
• Les outils de code assistés par IA fondés sur le RAG embarquent toute la base de code et récupèrent les fragments pertinents au moment de la requête, mais dans les grands environnements, le pipeline d’embedding peut ne pas suivre le rythme d’un développement très actif
• Si un index reflète l’état du code d’il y a plusieurs semaines, jours ou heures, il peut renvoyer une fonction déjà renommée ou un module supprimé lors du sprint précédent, sans indiquer que l’information est obsolète
• La recherche agentique de Claude Code permet à chaque instance développeur de travailler sur une base de code vivante, sans pipeline d’embedding ni index centralisé
• Il y a aussi un inconvénient : Claude fonctionne mieux lorsqu’il dispose d’un contexte de départ suffisant pour savoir où regarder
• Si on lui demande de trouver toutes les occurrences d’un motif ambigu dans une base de code d’un milliard de lignes, il peut atteindre les limites de sa fenêtre de contexte avant même de vraiment commencer
• Les équipes qui structurent bien leur base de code et hiérarchisent le contexte avec des fichiers CLAUDE.md et des skills obtiennent de meilleurs résultats

Un harness aussi important que le modèle

• Les performances de Claude Code dépendent fortement du harness construit autour du modèle, parfois davantage que du modèle lui-même
• Ce harness se compose de cinq points d’extension : CLAUDE.md, hooks, skills, plugins et serveurs MCP
• Chaque couche s’ajoute à la précédente, donc l’ordre dans lequel l’équipe les met en place compte aussi
• L’intégration LSP et les subagents agissent comme des capacités complémentaires à cette configuration

• Fichiers CLAUDE.md

  • CLAUDE.md est un fichier de contexte que Claude lit automatiquement au début de chaque session
  • Le fichier racine contient la vue d’ensemble, tandis que les fichiers des sous-répertoires portent les règles locales
  • Comme il est chargé dans toutes les sessions, il faut se concentrer sur ce qui s’applique largement afin d’éviter une baisse de performances

• Hooks

  • Les Hooks ne servent pas seulement à empêcher Claude d’avoir de mauvais comportements : ils ont encore plus de valeur pour améliorer continuellement la configuration
  • Un stop hook peut revenir sur ce qui s’est passé pendant la session et proposer des mises à jour de CLAUDE.md tant que le contexte est encore frais
  • Un start hook peut charger dynamiquement un contexte propre à l’équipe, afin qu’un développeur reçoive la configuration adaptée à son module sans réglage manuel
  • Pour des vérifications automatiques comme le linting ou le formatting, les hooks donnent des résultats plus cohérents lorsqu’ils appliquent les règles de manière déterministe, plutôt que de compter sur Claude pour se souvenir des consignes

• Skills

  • Les Skills permettent de conserver l’expertise nécessaire à la demande, sans alourdir toutes les sessions
  • Une grande base de code peut comporter des dizaines de types de tâches, mais toute cette expertise n’a pas besoin d’être présente dans chaque session
  • Grâce à la divulgation progressive (progressive disclosure), les Skills gardent hors de l’espace de contexte les workflows spécialisés et la connaissance métier, et ne les chargent qu’en cas de besoin
  • Un skill de revue de sécurité se charge lorsque Claude évalue des vulnérabilités, tandis qu’un skill de traitement documentaire se charge lorsqu’il faut mettre à jour la documentation après une modification du code
  • Les Skills peuvent être limités à certains chemins : par exemple, un skill de déploiement pour l’équipe du service de paiement peut être lié uniquement à ce répertoire et ne pas se charger automatiquement ailleurs dans le monorepo

• Plugins

  • Les Plugins servent à diffuser une configuration efficace pour qu’elle ne reste pas un savoir tacite
  • Un plugin regroupe skills, hooks et configuration MCP dans un paquet installable
  • Si un nouvel ingénieur installe le plugin dès son premier jour, il obtient immédiatement le même contexte et les mêmes capacités que ceux qui utilisent déjà Claude
  • Les mises à jour de plugin peuvent être déployées à l’échelle de l’organisation via des managed marketplaces
  • Une grande organisation du retail a créé un skill connectant Claude à sa plateforme analytique interne, permettant aux analystes métier de récupérer des données de performance sans quitter leur workflow, puis l’a diffusé sous forme de plugin avant un déploiement plus large

• Intégration Language Server Protocol

  • L’intégration du Language Server Protocol (LSP) donne à Claude des capacités de navigation dans le code comparables à celles de l’IDE du développeur
  • La plupart des IDE pour grandes bases de code exécutent déjà un LSP qui alimente “go to definition” et “find all references”
  • En l’exposant à Claude, on lui donne une précision au niveau des symboles : suivre un appel de fonction jusqu’à sa définition, tracer les références à travers les fichiers et distinguer des fonctions de même nom dans des langages différents
  • Sans LSP, Claude s’appuie sur l’appariement de motifs textuels et peut aboutir au mauvais symbole
  • Une entreprise de logiciels a déployé l’intégration LSP à l’échelle de l’organisation avant le rollout de Claude Code afin de stabiliser l’exploration de code C et C++ dans un environnement de grande taille
  • C’est l’un des investissements les plus utiles dans une base de code multilingue

• Serveurs MCP

  • Les serveurs MCP sont le moyen de connecter Claude à des outils internes, sources de données et API auxquels il ne peut pas accéder directement
  • Les équipes les plus matures construisent des serveurs MCP qui exposent une recherche structurée comme un outil que Claude peut appeler directement
  • D’autres équipes relient Claude à leur documentation interne, à leur système de tickets ou à leur plateforme analytique

• Subagents

  • Les Subagents séparent l’exploration de l’édition
  • Un subagent est une instance isolée de Claude avec sa propre fenêtre de contexte : il reçoit une tâche, l’exécute, puis ne renvoie au parent que le résultat final
  • Une fois le harness en place, certaines équipes lancent des subagents en lecture seule pour cartographier des sous-systèmes et écrire les résultats dans des fichiers, puis laissent l’agent principal éditer avec cette vue d’ensemble

• Rôle de chaque composant et confusions fréquentes

  • CLAUDE.md : fichier de contexte lu automatiquement par Claude et chargé dans toutes les sessions. Adapté aux règles propres au projet et à la connaissance de la base de code, mais on y met facilement une expertise réutilisable qui devrait aller dans un skill
  • Hooks : scripts exécutés à des moments clés et déclenchés par des événements. Adaptés à l’automatisation de comportements cohérents et à la capture des apprentissages de session, mais on traite facilement par prompt ce qui devrait s’exécuter automatiquement
  • Skills : instructions packagées pour un type de tâche précis, chargées à la demande lorsqu’elles sont pertinentes. Adaptés à l’expertise réutilisée à travers les sessions et projets, mais on met facilement tout dans CLAUDE.md
  • Plugins : bundles de skills, hooks et configuration MCP, toujours disponibles une fois configurés. Adaptés au déploiement d’une configuration efficace à l’échelle d’une organisation, mais cette bonne configuration risque autrement de rester du savoir tacite
  • LSP : intelligence de code en temps réel via des serveurs propres à chaque langage, toujours disponible une fois configurée. Adapté à l’exploration au niveau des symboles dans les langages typés et à la détection automatique d’erreurs, mais on suppose facilement que cela fonctionne automatiquement
  • Serveurs MCP : connexions à des outils et données externes, toujours disponibles une fois configurées. Adaptés à l’accès à des outils internes auxquels Claude ne peut pas accéder directement, mais on est tenté de construire ces connexions avant même que la base fonctionne correctement
  • Subagents : instances séparées de Claude pour des tâches spécifiques, exécutées à l’appel. Adaptés à la séparation entre exploration et édition ainsi qu’au travail parallèle, mais on tente facilement de faire les deux dans la même session
  • Le LSP est accessible via la couche plugin, tandis que les subagents ne sont pas un point d’extension configuré mais une capacité de délégation

Trois schémas de configuration récurrents dans les déploiements réussis

• Rendre la base de code explorable, même à grande échelle

  • La capacité de Claude à être utile dans une grande base de code est limitée par son aptitude à trouver le bon contexte
  • Charger trop de contexte dans chaque session dégrade les performances ; en charger trop peu oblige Claude à explorer à l’aveugle
  • Les déploiements efficaces investissent tôt dans une base de code plus facile à lire pour Claude

  • Garder les fichiers CLAUDE.md légers et hiérarchiques

    • Claude charge de façon additive les fichiers CLAUDE.md à mesure qu’il se déplace dans la base de code
    • Le fichier racine porte la vue d’ensemble, les fichiers des sous-répertoires portent les règles locales
    • Le fichier racine ne devrait contenir que des pointeurs et des avertissements critiques ; le reste devient vite du bruit

  • Démarrer depuis un sous-répertoire plutôt que depuis la racine du dépôt

    • Claude fonctionne mieux quand son périmètre est limité à la partie de la base de code réellement liée à la tâche
    • Cela peut sembler contre-intuitif dans un monorepo, où les outils supposent souvent un accès par la racine
    • Claude remonte automatiquement l’arborescence et charge tous les fichiers CLAUDE.md qu’il trouve, donc le contexte au niveau racine n’est pas perdu

  • Cibler les commandes de test et de lint par sous-répertoire

    • Si Claude ne modifie qu’un service mais exécute toute la suite de tests, il risque le timeout et gaspille du contexte dans une sortie non pertinente
    • Les fichiers CLAUDE.md des sous-répertoires doivent préciser les commandes applicables à cette partie de la base de code
    • Cela fonctionne bien dans les bases de code orientées services, où chaque répertoire possède ses propres commandes de test et de build
    • Dans les monorepos de langages compilés avec de fortes dépendances entre répertoires, ce ciblage par sous-répertoire est plus difficile et peut exiger une configuration de build propre au projet

  • Exclure les fichiers générés, artefacts de build et code tiers avec les fichiers .ignore

    • En committant des règles permissions.deny dans .claude/settings.json, les règles d’exclusion sont versionnées
    • Tous les développeurs de l’équipe bénéficient de la même réduction du bruit sans configuration séparée
    • Dans certaines bases de code, les fichiers générés eux-mêmes peuvent être une cible de développement
    • Les développeurs qui travaillent sur un générateur de code peuvent surcharger localement les règles d’exclusion du projet sans affecter le reste de l’équipe

  • Construire une carte de la base de code si l’arborescence ne suffit pas

    • Dans les organisations où le code n’est pas structuré selon une arborescence classique, un petit fichier Markdown à la racine peut aider
    • Une ligne de description pour chaque dossier de premier niveau et son contenu crée une table des matières que Claude peut parcourir avant d’ouvrir des fichiers
    • S’il existe des centaines de dossiers de premier niveau, l’approche hiérarchique fonctionne le mieux : le fichier racine décrit seulement la structure générale, et les CLAUDE.md des sous-répertoires fournissent à la demande le niveau de détail suivant
    • Dans les cas plus simples, mentionner avec @ les fichiers ou répertoires spécifiques que Claude doit consulter peut jouer le même rôle

  • Utiliser les serveurs LSP pour chercher par symbole, pas par chaîne

    • Dans les grandes bases de code, un grep sur un nom de fonction courant peut renvoyer des milliers de résultats, et Claude consomme alors du contexte à ouvrir des fichiers pour déterminer ce qui compte
    • Le LSP ne renvoie que les références au même symbole ; le filtrage a donc lieu avant même que Claude ne lise quoi que ce soit
    • Pour le configurer, il faut installer le code intelligence plugin du langage concerné ainsi que le binaire du language server correspondant
    • La documentation de Claude Code inclut la liste des plugins disponibles et les méthodes de dépannage

  • Exceptions

    • Même l’approche hiérarchique basée sur CLAUDE.md a ses cas limites
    • C’est notamment le cas des bases de code comportant des centaines de milliers de dossiers et des millions de fichiers, ou des systèmes legacy utilisant un gestionnaire de versions autre que Git

• Maintenir les fichiers CLAUDE.md au rythme de l’évolution de l’intelligence du modèle

  • À mesure que le modèle progresse, des consignes écrites pour le modèle actuel peuvent devenir un frein pour les versions futures
  • Des règles CLAUDE.md conçues pour guider Claude sur des schémas autrefois difficiles peuvent devenir inutiles, voire restrictives, avec un nouveau modèle
  • Par exemple, une règle imposant de découper toute refactorisation en modifications d’un seul fichier pouvait aider un ancien modèle à garder le fil, mais empêcher un nouveau modèle de bien gérer des éditions coordonnées sur plusieurs fichiers
  • Les skills et hooks créés pour compenser des limites précises du raisonnement du modèle ou des outils de Claude Code deviennent du surcoût lorsque ces limites disparaissent
  • Un hook qui interceptait l’écriture des fichiers pour forcer p4 edit dans une base de code Perforce devient redondant après l’ajout d’un mode Perforce natif dans Claude Code
  • Les équipes doivent s’attendre à une vraie revue de configuration tous les 3 à 6 mois
  • Cela vaut aussi la peine de revoir la configuration lorsqu’après une sortie majeure de modèle, les performances semblent stagner

• Désigner un responsable pour l’administration et l’adoption de Claude Code

  • La seule configuration technique ne suffit pas à déclencher l’adoption
  • Les rollouts les plus rapides ont été précédés d’un investissement dans l’infrastructure avant l’ouverture large des accès
  • Une petite équipe, parfois une seule personne, a connecté les outils pour que, dès le premier contact avec Claude, les développeurs aient déjà une expérience adaptée à leur workflow
  • Dans une entreprise, quelques ingénieurs ont construit un ensemble de plugins et de MCP prêt à l’emploi dès le premier jour
  • Dans une autre, une équipe dédiée à l’administration des outils de code IA a préparé l’infrastructure avant le rollout
  • Ce travail relève généralement d’une organisation developer experience ou developer productivity, qui prend aussi en charge l’onboarding des nouveaux ingénieurs et la construction des outils développeur
  • Dans plusieurs organisations apparaît un rôle hybride PM/ingénieur d’agent manager, chargé de piloter l’écosystème Claude Code
  • En l’absence d’équipe dédiée, la forme minimale viable est une personne DRI
  • Ce DRI doit porter la responsabilité de la configuration Claude Code, des arbitrages de paramétrage, des politiques de permissions, du plugin marketplace et des règles CLAUDE.md, ainsi que de leur mise à jour
  • Une adoption bottom-up crée de l’enthousiasme, mais sans personne pour centraliser ce qui fonctionne, elle peut se fragmenter
  • Il faut une personne ou une équipe pour collecter et diffuser les conventions Claude Code, comme une hiérarchie CLAUDE.md standardisée ou une sélection de skills et plugins
  • Sans ce travail, la connaissance reste tacite et l’adoption stagne

Gouvernance et rollout

• Dans les grandes organisations, en particulier les secteurs réglementés, les questions de gouvernance apparaissent tôt
• Les principaux enjeux sont : qui contrôle les skills et plugins autorisés, comment éviter que des milliers d’ingénieurs recréent indépendamment la même chose, et comment faire en sorte que le code généré par IA passe par les mêmes procédures de revue que le code écrit par des humains
• Au départ, il est recommandé d’adopter une approche avec un ensemble défini de skills approuvés, des procédures obligatoires de code review et un accès initial limité, puis d’élargir à mesure que la confiance s’installe
• Les déploiements les plus fluides viennent d’organisations qui ont mis en place dès le début un groupe de travail transverse réunissant ingénierie, sécurité de l’information et gouvernance, afin de définir ensemble les exigences et la feuille de route du rollout

Hypothèses et limites lors de l’application dans une organisation

• Claude Code est conçu avant tout pour des environnements traditionnels d’ingénierie logicielle, où les ingénieurs sont les principaux contributeurs à la base de code, où le dépôt utilise Git et où le code suit une arborescence standard
• La plupart des grandes bases de code correspondent à ce cadre, mais les moteurs de jeu avec de gros assets binaires, les environnements de gestion de versions non traditionnels ou ceux où des non-ingénieurs contribuent à la base de code exigent un travail de configuration supplémentaire
• Les schémas présentés supposent une configuration traditionnelle et ont fonctionné dans plusieurs environnements clients
• La complexité restante doit être évaluée en fonction de la base de code, des outils et de la structure organisationnelle de chaque entreprise
• L’équipe Applied AI d’Anthropic collabore directement avec les équipes d’ingénierie pour traduire ces schémas en besoins concrets propres à chaque organisation

[GN⁺]

Commentaires Hacker News

• La formule selon laquelle Claude « explore la base de code comme un ingénieur logiciel » semble en décalage avec la conclusion
  L’autocomplétion et le LSP sont toujours utiles et utilisés, et ce sont eux aussi une forme d’indexation, non ?
  On peut aussi se demander pourquoi Claude ne peut pas s’appuyer là-dessus
  Les ingénieurs logiciels mémorisent aussi la base de code, ce qui se rapproche en pratique du RAG, et beaucoup ont aussi une mémoire musculaire pour retrouver les fichiers nécessaires avec un CMD+P en autocomplétion
  Pas besoin d’être en temps réel sur toute une base de code modifiée simultanément par des milliers d’ingénieurs ; il suffit surtout de bien voir la branche sur laquelle je travaille
  Parcourir le système de fichiers depuis le début pour explorer une base de code est rare, en général on ne fait ça que sur une nouvelle base de code, et même dans ce cas il est difficile d’appeler ça l’expérience optimale

  • C’est exactement comme ça que je travaille
    J’ai appris à naviguer dans de grosses bases de code avant l’existence du LSP, et en utilisant vim pendant longtemps je trouvais les fichiers pertinents avec grep
    Quand j’ai essayé Claude Code pour la première fois l’an dernier, ma réaction a été : « mais oui, il fait exactement ce que j’allais faire »
  • La réponse est dans l’introduction de l’article
    Claude Code part du principe qu’il opère sur des monorepos de plusieurs millions de lignes, des systèmes legacy vieux de plusieurs décennies et des architectures distribuées réparties sur des dizaines de dépôts
    Il est donc optimisé pour le cas général consistant à utiliser des outils robustes qui fonctionnent partout, surtout dans les grosses bases de code désordonnées
    Cela dit, il est aussi juste de dire que sur un petit dépôt bien organisé, on peut et on doit utiliser de meilleurs outils
    Au moins, Codex fonctionne de cette manière et, par exemple, utilise d’abord go doc avant de faire un grep
  • Sur des bases de code vraiment énormes, grep et find expirent
    Quand on travaille à cette échelle, on se rend vite compte que Claude n’utilise pas les outils mis en place pour rendre la recherche possible
  • Il y a beaucoup de tournures plausibles dans un court paragraphe, mais au fond cela ressemble à une affirmation pleine d’espoir
    Dire « comme un ingénieur logiciel » n’est vrai qu’en partie
    Les humains utilisent aussi la recherche de symboles, mais ils cherchent des symboles dont ils se souviennent dans un contexte de travail précis
    La manière dont Claude Code explore les symboles à l’aveugle aujourd’hui ne correspond pas à la façon dont les ingénieurs travaillent
    Une simple faute de frappe peut amener l’agent à conclure qu’il faut réimplémenter quelque chose, et même s’il lit le bon fichier par chance, il peut facilement halluciner
    Ce n’est pas non plus ainsi qu’on travaille sur une grande base de code
    La partie « on trouve exactement ce qu’il faut avec grep » me gêne particulièrement
    Pour faire un grep, il faut déjà savoir quoi chercher, et si on obtient des milliers de résultats, il faut tous les examiner
    Quand cela arrive, un humain cherche plutôt à restreindre la sortie qu’à la parcourir bêtement
    L’approche de l’article ressemble moins à une recommandation solide qu’à une justification de l’approche actuelle
    Dire qu’« il n’y a pas besoin d’indexer la base de code » est peut-être vrai, mais cela revient seulement à dire qu’en faisant grep-read-grep et en gonflant progressivement le contexte, on finira un jour par trouver la réponse
    Cela sonne un peu comme : « puisque les développeurs pourraient l’implémenter eux-mêmes sans Claude Code, alors Claude Code n’est pas nécessaire »
    Je trouve ce message du « pas nécessaire » trompeur parce qu’il présente une décision comme un absolu à la communauté
    Globalement, le texte est honnête sur les coûts organisationnels
    Dans plusieurs organisations, on voit apparaître des rôles de « gestionnaire d’agents », mélange de PM et d’ingénieur, pour administrer l’écosystème Claude Code, et les équipes doivent revoir des configurations importantes tous les 3 à 6 mois
    Cela décrit avec justesse la réalité d’un usage de Claude Code à grande échelle sans couche d’intelligence de code préconstruite
    La direction prise semble correcte, mais une fois la lecture terminée, il reste une impression de « nous n’avons pas résolu le problème, et voici notre limite »
  • Même si l’on explore une partie de la base de code depuis zéro, certaines zones ne changent pratiquement jamais, et les réexplorer à chaque fois représente un énorme gaspillage de tokens
    L’un des points sur lesquels je me dispute souvent avec Claude est précisément de le pousser à beaucoup moins explorer
    Je connais mieux et plus vite les éléments qui changent à peine que sa manière lente et coûteuse de les survoler
    Pourtant, il retombe à chaque fois dans le même type de terrier de lapin

• Petite anecdote : je concevais un projet d’onboarding et d’orchestration pour LLM, et Claude a choisi de ne lire que les 40 premières lignes de chaque fichier
  Plus tard, dans une autre session, alors qu’il cherchait la cause d’une mauvaise qualité, Claude a identifié ce défaut et modifié le code pour effectuer une analyse AST prenant en entrée les lignes de documentation et les entrées/sorties des signatures de fonctions
  Son approche initiale était vraiment mauvaise
  Je me demande jusqu’à quel point Claude Code doit être corrigé et revu pour devenir bon, et s’il peut produire du bon code dès le départ
  En généralisant, Claude sait corriger de mauvaises décisions locales et identifiables, comme « lire seulement les 40 premières lignes »
  Parce que le défaut est isolé et traçable à un morceau de code
  Mais dans la vraie vie, les problèmes de qualité logicielle viennent souvent d’une accumulation de petites décisions raisonnables prises séparément qui mènent à un mauvais résultat
  Dans ce cas, aucune d’entre elles n’est clairement un « défaut », donc un outil qui génère morceau par morceau des composants de faible qualité peut ne pas converger vers du bon code, puisque chaque morceau pris isolément paraît acceptable

  • On dirait qu’il a été entraîné à regarder le code source par un trou étroit afin de préserver le contexte
    Dans ce type de situation, une logique sous-jacente ou des sous-agents complets peuvent bien convenir
    Par exemple, on peut demander à un sous-agent : « parcours ce fichier, résume-le et marque ce qui concerne X et Y ; ensuite je regarderai ça dans le contexte principal »
    On pourrait aussi le laisser observer périodiquement le flux de travail principal et intervenir s’il juge qu’un élément du fichier qu’il examine est lié à la tâche en cours ou pourrait en changer l’orientation

• Comment Claude Code fonctionne-t-il sur de grosses bases de code ? C’est simple
  Même sur de petits projets, il peut consommer 35 % de la limite d’utilisation de 5 heures dès le premier prompt, et s’il ne répond pas vite dans les 5 minutes, le cache disparaît, donc il faut encore payer 12 à 15 % au prompt suivant

  • L’article lié explique comment éviter cela
    Si on le lâche naïvement sur une grosse base de code, il est effectivement normal qu’il brûle beaucoup de tokens pendant la recherche

• Pourquoi Claude Code n’inspecterait-il pas la base de code pour générer automatiquement un harnais efficace ?
  J’ai défini CLAUDE.md, AGENTS.md, des skills et des plugins, mais je n’obtiens pas l’effet dont parlent les autres
  Par exemple, même avec un plugin LSP, Claude Code n’utilise pas le renommage de symboles du LSP et modifie lentement les fichiers un par un ; ou bien, même si le prompt précise d’appeler un skill en présence de certains indices, il ne l’appelle pas
  Est-ce que je m’y prends mal ? Je serais curieux de voir des exemples de harnais robustes qu’on pourrait reprendre tels quels

  • C’est un point de douleur depuis des années, et ce n’est toujours pas résolu du tout
    On a beau dire « si A, fais X. Fais B, C, D. Fais A », il n’utilise tout simplement pas X
    Parce qu’il « l’oublie »
    On ne peut pas croire que le temps passé à écrire des règles sera réellement récompensé ; en revanche, on peut croire qu’un jour cela échouera
    Le RAG, les harnais et les skills ont tous prétendu résoudre ça, mais en pratique ils n’y sont pas parvenus
  • J’ai arrêté d’utiliser /init et de garder un fichier CLAUDE.md ou AGENTS.md décrivant la base de code
    Je n’y ai laissé que la manière d’explorer la base de code et l’instruction d’utiliser git log pendant l’enquête, mais c’est probablement redondant aussi
    Je ne connais pas non plus la réponse
    La base de code sur laquelle je travaille fait environ 100 000 lignes, donc je ne sais pas si ça compte comme gros, mais personnellement c’est le plus grand dépôt sur lequel j’ai travaillé
  • Dans certains cas, les hooks auxquels on attache des scripts semblent efficaces pour injecter des informations dans la fenêtre de contexte
    Pour limiter le contexte, j’ai dû retirer certains messages de linter inutiles
    Les linters ou vérificateurs spécifiques à un langage qu’on peut installer depuis le dépôt de paquets du système d’exploitation et appeler depuis des scripts aident aussi
    La combinaison entre le modèle et le contexte des skills peut également faire une différence
    Un skill qui « fonctionnait » en 4.6 peut moins bien coller en 4.7 ; la 4.7 demande des instructions plus explicites mais reste relativement plus stable que la 4.6
    Mettre à jour les skills peut aussi aider, et il faut comparer les tests et l’exécution avant et après
    Claude Code met aussi dans le contexte des appels d’outils inutiles, donc par exemple si vous aimez beads, il faudra peut-être freiner son usage

• Je ne suis pas d’accord avec les affirmations sur l’indexation de la base de code
  Dans PHPStorm ou d’autres IDE JetBrains, l’indexation fonctionne plutôt bien

  • L’indexation de PHPStorm est formidable
    Elle a été corrompue très rarement, mais cela se répare facilement, et je n’ai jamais eu de résultats obsolètes
    Si vous avez essayé l’outil de recherche de Claude, il ne vous surprendra pas que cette équipe ne connaisse rien à l’indexation
    Qu’une entreprise dont le produit principal est un chat textuel rende difficile pour les utilisateurs la recherche textuelle dans ce chat, c’est incompréhensible
  • Claude Code peut utiliser cette indexation via le MCP de JetBrains
  • C’est une affirmation étrange
    C’est un article poubelle généré par IA ? GitHub Copilot a lui aussi une assez bonne indexation locale
    Mettre le code dans une base de données vectorielle n’est pas un problème si difficile

• Cet article a clairement été écrit par Claude
  Il y a beaucoup de remplissage et peu de substance réelle

• Je trouve étrange la formulation selon laquelle cela inclut aussi des langages comme C, C++, C#, Java et PHP, que les équipes n’associent pas spontanément aux outils de codage IA
  Pourquoi devrait-on s’attendre à ce que Claude Code fonctionne moins bien sur ces langages ? À quels langages est-on censé penser, Python et JavaScript ?

• Dans un secteur où la donne change en quelques mois, voire quelques semaines, il est intéressant qu’il y ait déjà eu assez de temps pour voir émerger des schémas clairs, et que ces schémas aient été couronnés de succès sur de grosses bases de code
  Quel est le critère de succès ? Ne pas avoir supprimé la base de données de production ? Avoir accéléré les équipes ? Allongé la durée de vie de la base de code ? Rendu les équipes ops plus heureuses ?

  • Si des outils d’IA ont fait disparaître une base de données de production, je continuerai à dire que c’est l’échec de la personne et de l’organisation qui ont donné aux développeurs des droits de production permettant de supprimer des ressources de production
    Je n’ai jamais travaillé dans une entreprise où on recevait un tel niveau d’accès illimité

• En ce moment, tout mon stress vient du fait que Claude Code ne suit pas les instructions, et plus la base de code grossit, pire c’est
  Qu’on me comprenne bien : Claude est impressionnant et je l’aime beaucoup
  Mais il est totalement impossible d’embaucher uniquement Claude Code pour maintenir une base de code ou y ajouter des fonctionnalités
  Je continue d’ajouter des éléments de mémoire sur les erreurs passées, mais le problème d’ignorer des instructions importantes se produit toujours avec une probabilité d’environ 90 %
  La seule manière de l’éviter est de surveiller chaque tâche de près et de revoir massivement les résultats
  Claude Code est excellent pour la documentation ou pour comprendre de grosses bases de code, mais faible dès qu’un changement exige de comprendre l’ensemble
  Par exemple, il existe dans toute la base environ 10 patterns de registre utilisés pour plusieurs entités ; malgré une règle explicite disant « utilise ce seul pattern de registre », Claude Code a quand même implémenté 4 registres distincts, un par entité
  J’ai passé une demi-journée à presque crier sur Claude Code pour qu’il réussisse cette tâche simple, puis j’ai fini par corriger moi-même pour gagner du temps et du stress

• On ne m’explique même pas en termes concrets ce que chaque fichier CLAUDE.md doit contenir exactement, donc j’ignore à quel point ces fichiers sont réellement importants

  • Le poisson : on peut lire ça ici https://code.claude.com/docs/en/best-practices#write-an-effe...
    La canne à pêche : 1) installer le skill-creator officiel 2) utiliser le lien ci-dessus pour créer claude-md-improver 3) lui faire étudier dans la documentation officielle le sujet progressive-disclosure afin d’améliorer le skill 4) appliquer le nouveau skill au fichier CLAUDE.md et accepter les changements