Sommaire
J'utilise Claude Code comme outil principal dans mon travail quotidien : développement, rédaction, automatisation. L'objectif n'est pas d'utiliser l'IA "quand ça arrange", mais de construire une méthodologie structurée, reproductible, et transposable à n'importe quel environnement technique. Ce projet documente comment je configure, utilise et contrôle l'IA dans mes projets.
La plupart des développeurs utilisent l'IA en mode question-réponse ponctuel. Ça donne des résultats moyens, inconstants, et surtout impossibles à reproduire. Andrej Karpathy a nommé ça le "vibe coding" : on prompte, on accepte, on ne lit pas vraiment ce que l'IA produit. C'est rapide, mais c'est fragile. Le problème va plus loin que la qualité du code. Addy Osmani parle du "problème des 70%" : les développeurs se disent massivement plus productifs avec l'IA, mais la qualité des logiciels qu'on utilise au quotidien ne s'améliore pas pour autant. Parce que les vrais problèmes — comprendre un besoin, concevoir un système maintenable, gérer les cas limites — restent entièrement humains. L'IA accélère la frappe, pas le jugement. Et il y a un coût invisible. Des études avec monitoring EEG ont montré une réduction significative de l'activité cérébrale (attention, mémoire, créativité) chez les développeurs qui délèguent trop à l'IA. Un essai randomisé du METR a mesuré que les développeurs utilisant des outils IA étaient en réalité 19% plus lents que ceux qui s'en passaient, alors qu'ils se croyaient 20% plus rapides. Le cerveau se met en veille, on accepte les suggestions sans les lire, et on perd progressivement la capacité de juger ce qui est bon ou mauvais dans le code qu'on livre. Sans méthode, l'IA ne rend pas meilleur. Elle rend paresseux.
Simon Willison a proposé une distinction utile. Si un LLM a écrit chaque ligne de ton code, mais que tu as tout relu, tout testé et tout compris, ce n'est pas du vibe coding. C'est utiliser un LLM comme assistant de frappe. Il appelle ça le "vibe engineering" : un usage responsable, en production, par des professionnels qui gardent la main. C'est exactement ma position. Kent Beck parle d'"augmented coding" dans le même esprit : l'IA fait le gros du typage, mais le développeur reste responsable d'un code propre, testé, et maintenable. Ce qui change dans le quotidien, c'est qu'on prend plus de décisions conséquentes par heure et moins de décisions triviales. Les compétences qui montent en valeur : la vision, le découpage de tâches, la stratégie, les boucles de feedback. Celles qui baissent : l'expertise syntaxique pure. Le rôle se transforme. On passe de "celui qui tape le code" à architecte, reviewer, superviseur. L'IA gère la génération. Le développeur gère la conception, la qualité et le contrôle.
Chaque projet Claude Code démarre avec un fichier CLAUDE.md qui cadre le comportement de l'IA : conventions de code, stack technique, règles métier, et liens vers ma base de connaissances Obsidian pour le contexte étendu. Quand je développe, Claude Code a accès au codebase complet dans l'IDE. Je valide chaque interaction, pas de mode autonome. Je vois les modifications proposées en temps réel, j'accepte ou je refuse, et je garde la main sur le versioning. Le résultat est constant d'une session à l'autre. Ensuite j'utilise différents Skills et surtout Obsidian pour garder une mémoire long terme concernant de gros projets.
Usage quotidien : Développement, rédaction, debug. Claude Code est ouvert en permanence dans le terminal. Je l'utilise pour naviguer dans le codebase, éditer des fichiers, lancer des commandes, rédiger du contenu et débugger. Chaque action passe par une validation et l'ajout d'informations dans sa structure en local. Configuration projet : CLAUDE.md, mémoire, Obsidian. Chaque projet a son fichier CLAUDE.md qui définit le contexte : stack, conventions, structure des dossiers, et liens vers les notes Obsidian pertinentes. La mémoire persistante accumule les retours d'une session à l'autre. Le découpage dans Obsidian est essentiel pour éviter de saturer le contexte avec l'ensemble de la conversation. Les hooks déclenchent des vérifications automatiques. Intégration technique : API, MCP, skills custom. Connexion de l'API Anthropic dans des applications back-end. Configuration de serveurs MCP pour connecter Claude à des outils externes comme Notion, Airtable ou des bases de données. Création de skills réutilisables pour automatiser des workflows récurrents : génération de contenu formaté, revue de code, déploiement.
Le terme "prompt engineering" est devenu insuffisant. Ce qui compte vraiment, c'est le context engineering : traiter le contexte donné à l'IA comme un système à part entière, avec son architecture, son cycle de vie et ses contraintes. En pratique, ça repose sur quatre mécanismes. Écrire le contexte : persister l'information en dehors de la fenêtre de conversation, via des fichiers comme CLAUDE.md, la mémoire projet, ou des scratchpads. Sélectionner le contexte : ne fournir que l'information pertinente pour la tâche en cours, plutôt que tout déverser d'un coup. Compresser le contexte : résumer ou élaguer pour économiser l'espace disponible. Isoler le contexte : séparer les préoccupations via des systèmes multi-agents ou des sandboxes. Il y a un piège non évident. Le système prompt de Claude Code consomme déjà environ 50 instructions avant même que le fichier CLAUDE.md ne soit chargé. Les modèles actuels suivent de manière fiable entre 150 et 200 instructions au total. Un tiers de la capacité est déjà consommé avant que ton propre contexte n'entre en jeu. Un CLAUDE.md trop long dégrade la performance. Chaque ligne doit mériter sa place, et si Claude fait déjà quelque chose correctement sans qu'on le lui dise, l'instruction est inutile, voire nuisible. Plutôt que de tout entasser dans un seul fichier, j'utilise la divulgation progressive : des fichiers markdown séparés dans des répertoires dédiés, avec des noms descriptifs. L'agent lit ce qui est pertinent quand il en a besoin, au lieu de charger tout le contexte en permanence.
Utiliser l'IA au quotidien ne dispense pas de rigueur. Au contraire, ça en demande plus. Les LLM ont des biais récurrents : ils font des suppositions sans les vérifier, ils sur-complexifient le code, ils touchent à des fichiers qui n'ont rien à voir avec la demande, et ils ajoutent des abstractions dont personne n'a besoin. Reconnaître ces biais, c'est la première étape pour les neutraliser. Réfléchir avant de coder. Avant chaque implémentation, je formule mes hypothèses explicitement. S'il y a une ambiguïté, je ne laisse pas l'IA choisir à ma place, je clarifie. S'il existe une approche plus simple, je la privilégie. Et quand quelque chose n'est pas clair, j'arrête. Je nomme ce qui me gêne et je pose la question. L'IA excelle quand on lui donne un cadre précis. Sans cadre, elle produit du bruit. Simplicité d'abord. Le bon code, c'est le minimum qui résout le problème. Pas de fonctionnalités spéculatives, pas d'abstractions pour du code qu'on n'utilisera qu'une fois, pas de "flexibilité" qu'on n'a pas demandée. Si une solution fait 200 lignes et qu'elle pourrait en faire 50, c'est qu'elle est mauvaise. Le test que j'applique : est-ce qu'un développeur senior trouverait ça sur-compliqué ? Si oui, on simplifie. Changements chirurgicaux. Quand je modifie du code existant, je ne touche que ce qui est nécessaire. Pas d'amélioration opportuniste du code voisin, pas de refactoring non demandé, pas de reformatage de ce qui marchait déjà. Si l'IA repère du code mort qui n'a rien à voir avec ma tâche, je le note mais je ne le supprime pas. Chaque ligne modifiée dans un diff doit pouvoir être rattachée directement à la demande initiale. Amazon a fait les frais de l'approche inverse : des incidents "high blast radius" directement liés à des changements générés par IA qui débordaient du périmètre demandé. Exécution orientée résultat. Plutôt que de donner des instructions vagues à l'IA, je transforme chaque tâche en objectif vérifiable. "Ajouter de la validation" devient "écrire les tests pour les entrées invalides, puis les faire passer". "Corriger le bug" devient "écrire un test qui le reproduit, puis le résoudre". Pour les tâches en plusieurs étapes, chaque étape a son critère de vérification. L'IA est excellente pour itérer vers un objectif précis. Elle est médiocre quand l'objectif est flou.
Contrôle humain permanent. Chaque modification proposée par Claude est visible dans l'IDE avant d'être appliquée. Pas de mode YOLO. Je valide chaque interaction, je lis chaque diff. L'IA propose, je dispose. Kent Beck identifie trois signaux d'alerte quand ce contrôle se relâche : des boucles inattendues qui apparaissent, des fonctionnalités non demandées qui se glissent dans le code, et l'IA qui désactive ou supprime des tests pour les faire passer. Revue de code systématique. J'utilise les skills de revue intégrées à Claude Code pour scanner le code produit : détection de failles de sécurité, erreurs logiques, incohérences avec les conventions du projet. La revue IA complète ma relecture manuelle, elle ne la remplace pas. Utiliser la même IA pour générer et relire du code, c'est comme demander à quelqu'un de corriger sa propre copie. Pour les décisions critiques, je croise les modèles : un modèle génère, un autre critique. Hygiène des fichiers générés. Claude Code génère des fichiers de configuration, de mémoire et de cache. Je contrôle systématiquement ce qui est créé, je limite les fichiers accordés, et je maintiens un .gitignore strict pour que rien de lié à l'IA ne pollue le dépôt. La provenance de chaque fichier dans le repo est traçable. Exécution locale. Tout tourne en local. Le code reste sur ma machine, les commandes s'exécutent dans mon terminal, les fichiers ne quittent pas mon environnement. Les seuls appels distants sont les requêtes API vers Claude. Le reste est maîtrisé. Coder sans IA régulièrement. Pour contrer l'érosion cognitive, je code régulièrement sans assistance. C'est le même principe qu'en sport : si on ne s'entraîne qu'avec des aides, on perd les fondamentaux. Addy Osmani le résume bien : le développeur dans le duo développeur+IA doit tenir sa part. L'IA amplifie les compétences existantes, elle ne les crée pas. Reproductible dans n'importe quel contexte. La méthode ne dépend pas d'un projet ou d'une stack spécifique. Le même setup (CLAUDE.md, mémoire, hooks, skills) se transpose sur un projet Next.js, un backend Python, un repo Terraform ou un pipeline data. Ce qui change, c'est le contenu du fichier de contexte, pas la méthode.
L'IA repose sur Claude (Opus, Sonnet, Haiku), l'API Anthropic, et Claude Code en CLI comme en IDE. La configuration de chaque projet passe par CLAUDE.md, la mémoire persistante, les hooks et les skills custom. Ma base de connaissances vit dans Obsidian, avec des notes liées et du contexte projet étendu. L'intégration technique s'appuie sur les serveurs MCP (Notion, Airtable, etc.) et l'Anthropic SDK en Python et TypeScript. Côté sécurité : revue de code automatisée, .gitignore strict, exécution locale au maximum. L'environnement de travail, c'est le terminal, VS Code et Git.