Ce que des semaines intensives avec Claude Code m'ont appris

Après plusieurs semaines d’usage intensif de Claude Code comme outil principal, voici ce que j’ai retenu — et ce n’est que la partie émergée de l’iceberg :

Un agent sans système, c’est un stagiaire qui recommence à zéro chaque matin.

Il y seulement quelques mois, j’étais convaincu que la clef était le prompting. J’avais tort. La clef c’est l’infrastructure que l’on construit autour des modèles.

Voici les 7 leviers qui ont tout changé pour moi :

La mémoire c’est le socle indispensable. Pas la mémoire de la conversation — celle-là, l’IA la gère. Je parle de la mémoire structurée : qui je suis, comment je travaille, les décisions passées, les erreurs à ne pas répéter. Un agent qui se souvient de vos préférences, de vos patterns, de votre contexte métier, c’est un agent qui accélère au lieu de reposer les mêmes questions.
L’architecture en “peau d’oignon”. Les instructions d’un agent doivent s’empiler en couches : exemple: instructions globales → instructions projet → skills spécialisées → contexte de conversation. Chaque couche apporte de la précision sans rigidité. C’est ce qui permet à un même agent de travailler sur une migration technique Angular le matin et faire une étude marché l’après-midi — avec le bon niveau de spécialisation à chaque fois.
L’auto-amélioration continue. Le vrai pouvoir : l’agent améliore ses propres skills. Un workflow échoue ? L’agent corrige la skill. Un output n’est pas au niveau ? On ajuste les instructions. Cross-model assessment, feedback loops, itérations sur les prompts — l’agent devient meilleur à chaque interaction, pas juste au fil de la conversation, mais d’une session à l’autre.
Le branchement des outils entre eux. C’est là que ça devient puissant, vertigineux même. Imaginez une dizaine de vos outils préférés — connectés ensemble. L’agent ne “sait pas coder”. Il sait orchestrer un système, apporter sa valeur ajoutée à chaque étage de la fusée, et vous laisser de la place pour la vôtre, aux points critiques de décision.
Deux types de mémoire, deux objectifs. C’est là une de mes plus belles découvertes : après plusieurs échanges et itérations, j’ai établi un système de convention avec mes agents pour mieux structurer la gestion de la mémoire : il y a celle pour l’IA (context technique, patterns de code, conventions, caractère des agents, etc.) et la mémoire pour moi (décisions, recherches, insights, objectifs, etc.). Séparer les deux a été un game-changer. La danse entre Claude/Gemini et Obsidian s’apparente au rôle d’hippocampe dans cet écosystème.
Des guidelines IA dans chaque projet. Chaque repo a son fichier d’instructions IA. Les conventions, les patterns à suivre, les erreurs à éviter, le contexte métier — tout est versionné à la fois dans les projets concernés, mais aussi en tant que repository indépendant, commun à tous les projets.
Les tests E2E comme filet de sécurité indispensable. Plus on donne d’autonomie à l’agent, plus les tests end-to-end deviennent critiques. L’IA code vite, refactorise vite, touche à beaucoup de fichiers en une seule passe. Sans une suite E2E solide, on avance vite… dans le mur. Avec elle, une team d’agents peut itérer agressivement, casser, corriger, re-tester — en boucle. Le test E2E n’est pas un nice-to-have, c’est ce qui rend l’autonomie agentique viable. Bonus: les interactions specs ↔ tests E2E sont en plus une superbe opportunité de créer un cercle vertueux.

Bonus — Osez les “hacks” contre-intuitifs

L’écosystème IA évolue tellement vite que la méthode “standard” n’est pas toujours la bonne.

Un exemple concret : pour capturer des pages web et interagir avec un navigateur, l’approche évidente est d’utiliser un MCP Chrome DevTools. En pratique ? Connexions instables, limitations, timeouts. La solution qui marche mieux : coder un petit script Playwright from scratch — plus léger, plus fiable, moins cher en tokens.

Le takeaway ?

Un agent IA c’est sympa, mais sans système ça ne vaut rien. La valeur ne vient pas du modèle — elle vient de l’écosystème que vous mettez en place autour.