diff --git a/assets/sass/_custom.sass b/assets/sass/_custom.sass new file mode 100644 index 00000000..650cab2d --- /dev/null +++ b/assets/sass/_custom.sass @@ -0,0 +1,6 @@ +// Custom styles for blog.ogenki.io + +// Bluesky icon color +.bluesky + svg + fill: #0085ff diff --git a/config/_default/markup.toml b/config/_default/markup.toml index 2bb73d89..814c26d9 100644 --- a/config/_default/markup.toml +++ b/config/_default/markup.toml @@ -1,3 +1,7 @@ +[tableOfContents] +startLevel = 2 +endLevel = 2 + [goldmark] [goldmark.renderer] hardWraps = false diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/agentic-loop.png b/content/fr/post/series/agentic_ai/ai-coding-agent/agentic-loop.png new file mode 100644 index 00000000..6d7427cd Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/agentic-loop.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/chrome_karpenter.mp4 b/content/fr/post/series/agentic_ai/ai-coding-agent/chrome_karpenter.mp4 new file mode 100644 index 00000000..25385b01 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/chrome_karpenter.mp4 differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/cmd_context.png b/content/fr/post/series/agentic_ai/ai-coding-agent/cmd_context.png new file mode 100644 index 00000000..7795ce12 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/cmd_context.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/cursor+claude.png b/content/fr/post/series/agentic_ai/ai-coding-agent/cursor+claude.png new file mode 100644 index 00000000..e0b9b109 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/cursor+claude.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/dori_forgot.png b/content/fr/post/series/agentic_ai/ai-coding-agent/dori_forgot.png new file mode 100644 index 00000000..41d5eb18 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/dori_forgot.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/index-backup-20260117.md b/content/fr/post/series/agentic_ai/ai-coding-agent/index-backup-20260117.md new file mode 100644 index 00000000..916e8a86 --- /dev/null +++ b/content/fr/post/series/agentic_ai/ai-coding-agent/index-backup-20260117.md @@ -0,0 +1,788 @@ ++++ +author = "Smaine Kahlouch" +title = "Claude Code : Quand l'IA devient le copilote du Platform Engineer" +date = "2026-01-08" +summary = "Utilisation pratique d'un **coding agent** dans le quotidien du platform engineering. Au-delà du hype, des cas concrets qui démontrent comment cette nouvelle façon de travailler peut réellement **booster notre productivité**. Concepts, et retours d'expérience." +featured = true +codeMaxLines = 30 +usePageBundles = true +toc = true +tags = [ + "ai", + "devxp", + "tooling" +] +thumbnail = "thumbnail.png" ++++ + +{{% notice info "L'IA dans notre quotidien" %}} +Impossible d'y échapper : l'IA transforme nos métiers. Fin 2025, **65% des développeurs** utilisent des outils d'IA au moins une fois par semaine selon [Stack Overflow](https://stackoverflow.com/). Mais au-delà des annonces sensationnelles, qu'en est-il **concrètement** pour nous, platform engineers ? + +Dans cet article, je partage mon expérience avec Claude Code et vous montre, par des exemples réels, comment cet outil est devenu un allié précieux dans mes tâches quotidiennes. +{{% /notice %}} + +Nous le voyons bien, nous assistons à un réel bouleversement provoqué par l'utilisation de l'IA. Ce domaine évolue à une vitesse vertigineuse et, honnêtement, il est difficile de mesurer aujourd'hui l'impact sur tous les aspects de notre métier. Une chose est sûre cependant : dans la tech, c'est une **révolution** ! + +Je ne vais pas vous faire un énième tutoriel ChatGPT. Ici, je vais vous présenter une utilisation **pratique** dans le métier du platform engineering avec une exploration de l'utilisation d'un **coding agent** — pas un simple chatbot — dans certaines tâches communes de notre quotidien. + +Mais surtout, je vais tenter de vous démontrer par des cas concrets que cette nouvelle façon de travailler augmente **réellement** notre productivité. Si si ! + +## :dart: Objectifs de cet article + +* Comprendre ce qu'est un **coding agent** et pourquoi c'est différent d'un simple chatbot +* Découvrir les concepts clés : MCPs, subagents, skills, commands, hooks +* **Cas concrets** d'utilisation dans le platform engineering +* Optimiser son utilisation et maîtriser ses coûts +* Réflexions sur les limites et les pièges à éviter + +{{% notice tip "Le repo de référence" %}} + + + + + +
+Les exemples qui suivent sont issus de mon travail sur le repository Cloud Native Ref. Il s'agit d'une plateforme complète combinant EKS, Cilium, VictoriaMetrics, Crossplane, Flux et bien d'autres outils. +
+{{% /notice %}} + +--- + +## :brain: Comprendre les coding agents + +### Qu'est-ce qui différencie un agent d'un chatbot ? + +Vous utilisez probablement déjà ChatGPT ou Gemini pour poser des questions. C'est pratique, mais ça reste du **one-shot** : vous posez une question, vous obtenez une réponse, point final. + +Un **coding agent** fonctionne différemment. Il opère en boucle selon le pattern **ReAct** (Reasoning + Action) : + +
Boucle ReAct
+ +1. **Raisonnement** : L'agent analyse votre demande et planifie les étapes +2. **Action** : Il exécute une action (lire un fichier, exécuter une commande, chercher dans le code) +3. **Observation** : Il analyse le résultat de son action +4. **Itération** : Il décide si c'est suffisant ou s'il faut continuer + +{{% notice info "La définition selon Simon Willison" %}} +[Simon Willison](https://simonwillison.net/2025/Sep/30/designing-agentic-loops/), expert reconnu du domaine, définit un agent LLM comme : *"quelque chose qui exécute des outils en boucle pour atteindre un objectif"*. C'est simple, mais ça capture l'essentiel. +{{% /notice %}} + +Concrètement, si vous demandez à un chatbot classique *"Corrige le bug dans mon auth"*, il vous donnera des suggestions génériques. Un agent, lui, va : + +1. Chercher les fichiers liés à l'authentification +2. Lire le code concerné +3. Identifier le problème +4. Proposer une correction +5. L'appliquer si vous validez +6. Vérifier que ça compile/fonctionne + +C'est cette capacité à **agir** sur votre environnement qui fait toute la différence. + +### L'anatomie d'un agent + +On peut résumer un agent avec cette formule : + +``` +Agent = LLM + Tools + Memory + Planning +``` + +| Composant | Rôle | Exemple dans Claude Code | +|-----------|------|--------------------------| +| **LLM** | Le "cerveau" qui raisonne | Claude Opus 4.5 / Sonnet 4 | +| **Tools** | Les actions possibles | Read, Write, Bash, Grep, WebFetch | +| **Memory** | Le contexte conservé | CLAUDE.md, conversation history | +| **Planning** | La stratégie d'exécution | Décomposition en sous-tâches | + +### Le choix du modèle : une course effrénée + +Les nouvelles versions de modèles apparaissent à une vitesse folle. Impossible de suivre ! L'efficacité (qualité de code, hallucinations, context mis à jour) peut radicalement différer selon les modèles. + +Le benchmark [**SWE-bench Verified**](https://www.swebench.com/) est devenu la référence pour évaluer les capacités des modèles en développement logiciel. Il mesure la capacité à résoudre de vrais bugs issus de repositories GitHub. + +
Leaderboard SWE-bench Verified
+ +{{% notice warning "Ces chiffres évoluent très vite !" %}} +Consultez [swebench.com](https://www.swebench.com/) pour les derniers résultats. Au moment de la rédaction, les modèles frontier (Claude Opus 4.5, GPT-5.x, Gemini 3) se disputent la première place avec des scores autour de **75-80%**. +{{% /notice %}} + +La compétition est si féroce que la première place change régulièrement. En pratique, tous les modèles frontier sont suffisamment performants pour la plupart des tâches de platform engineering. + +### Pourquoi Claude Code ? + +Il existe de nombreuses options de coding agents : [Cursor](https://cursor.sh/), [Windsurf](https://codeium.com/windsurf), [GitHub Copilot](https://github.com/features/copilot), [Gemini CLI](https://github.com/google-gemini/gemini-cli)... Je ne suis clairement pas capable de toutes les évaluer en profondeur. + +J'ai utilisé Cursor dans un premier temps, puis je suis passé à Claude Code. La raison ? Mon **background de sysadmin** plutôt porté sur le terminal. Là où d'autres préfèrent travailler exclusivement dans leur IDE, je me sens plus à l'aise avec une CLI. + +| Outil | Type | Forces | Idéal pour | +|-------|------|--------|------------| +| **Claude Code** | Terminal | Context 200K, score SWE-bench le plus élevé | Refactoring large, DevOps, automation | +| **Cursor** | IDE | Workflow visuel, Composer mode | Développement applicatif, UI | +| **GitHub Copilot** | IDE Plugin | Intégration native, entreprise-ready | Équipes Microsoft/GitHub | +| **Windsurf** | IDE | Cascade mode, UX soignée | Prototypage rapide | + +{{% notice tip "Mon conseil" %}} +Beaucoup de développeurs utilisent **plusieurs outils** : Cursor pour écrire du code applicatif, Claude Code pour le refactoring et l'infrastructure. Ce n'est pas exclusif ! +{{% /notice %}} + +--- + +## :books: Les concepts essentiels de Claude Code + +Cette section présente les concepts fondamentaux pour tirer le meilleur parti de Claude Code. Pour l'installation et la configuration de base, de nombreux tutoriels existent — je vous recommande notamment la [documentation officielle](https://docs.anthropic.com/en/docs/claude-code) et l'excellent guide [How I Use Every Claude Code Feature](https://blog.sshh.io/p/how-i-use-every-claude-code-feature). + +### Tokens et fenêtre de contexte + +#### L'essentiel sur les tokens + +Un **token** est l'unité de base que le modèle traite — environ 4 caractères en anglais, 2-3 en français. Pourquoi c'est important ? Parce que **tout se paye en tokens** : input, output, et contexte. + +La **fenêtre de contexte** (200K tokens pour Claude) représente la "mémoire de travail" du modèle. Claude Code dispose d'un mécanisme d'**auto-compaction** qui résume automatiquement les conversations trop longues. + +```console +# Visualiser ce qui consomme votre contexte +/context +``` + +
Visualisation du contexte
+ +### Les MCPs : connecter Claude au monde extérieur + +Le **Model Context Protocol** (MCP) est un standard ouvert créé par Anthropic qui permet aux agents IA de se connecter à des sources de données et outils externes. Pensez-y comme une **prise USB-C pour l'IA** : un connecteur universel. + +{{% notice info "Un standard qui s'impose" %}} +En décembre 2025, Anthropic a [donné MCP à la Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) via l'Agentic AI Foundation. OpenAI, Google, Microsoft et AWS l'ont adopté. Avec **97 millions** de téléchargements mensuels et plus de **5,800 serveurs** disponibles, c'est devenu LE standard de facto. +{{% /notice %}} + +#### Mes MCPs indispensables pour le platform engineering + +| MCP | Catégorie | Usage | Intérêt pour PE | +|-----|-----------|-------|-----------------| +| **[context7](https://github.com/upstash/context7)** | Documentation | Doc à jour des libs | Évite les hallucinations d'API | +| **[flux](https://fluxcd.control-plane.io/mcp/)** | GitOps | Debug Flux, reconciliation | Troubleshooting pipelines | +| **[victoriametrics](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics)** | Métriques | Requêtes PromQL | Analyse cardinalité, alertes | +| **[victorialogs](https://github.com/VictoriaMetrics-Community/mcp-victorialogs)** | Logs | LogsQL | Root cause analysis | +| **[grafana](https://github.com/grafana/mcp-grafana)** | Visualisation | Dashboards, alertes | Création/modification dashboards | +| **[steampipe](https://github.com/turbot/steampipe-mcp)** | Cloud SQL | Requêtes infrastructure | Audit multi-cloud | + +{{% notice tip "Configuration globale ou locale?" %}} +Les MCPs peuvent être configurés globalement (`~/.claude/mcp.json`) ou par projet (`.mcp.json`). J'utilise `context7` globalement car je m'en sers quasi systématiquement, les autres au niveau du repo. +{{% /notice %}} + +{{% notice tip "Mon conseil sur Kubernetes" %}} +Pour Kubernetes, j'utilise directement `kubectl` via les commandes bash plutôt qu'un MCP dédié. La CLI consomme **moins de tokens** et Claude la maîtrise parfaitement. +{{% /notice %}} + +### Subagents : déléguer intelligemment + +Un **subagent** est une instance Claude séparée, lancée par l'agent principal pour effectuer une tâche spécifique. C'est comme déléguer à un "stagiaire spécialisé". + +| Avantage | Explication | +|----------|-------------| +| **Contexte isolé** | Le subagent a sa propre mémoire, il ne pollue pas la conversation principale | +| **Spécialisation** | Vous pouvez lui donner un "persona" (expert sécurité, expert Terraform...) | +| **Parallélisme** | Jusqu'à 10 subagents peuvent tourner simultanément | + +``` +> J'ai 50 fichiers Terraform à auditer pour des problèmes de sécurité. +> Utilise des subagents pour analyser chaque module en parallèle +> et donne-moi un rapport consolidé. +``` + +{{% notice warning "Limitations des subagents" %}} +- Les subagents **ne peuvent pas spawner d'autres subagents** (pas de récursion infinie) +- Pas de mode "thinking" interactif dans les subagents +- Maximum **10 agents en parallèle** (les suivants sont mis en queue) +{{% /notice %}} + +### Skills : étendre les connaissances de Claude + +{{% notice info "Skills et Slash Commands unifiés (v2.1+)" %}} +Depuis la version **2.1.3**, Skills et Slash Commands forment un **système unifié**. Chaque skill peut être invoqué automatiquement (Claude décide du contexte) **ou** explicitement via `/project:nom`. Cette simplification élimine la confusion entre les deux concepts. +{{% /notice %}} + +Les **Skills** sont des bases de connaissances que Claude charge quand c'est pertinent. C'est l'outil idéal pour injecter les conventions, patterns et procédures spécifiques à votre projet. + +Un fichier Markdown dans `.claude/skills/` ou `.claude/commands/` devient un skill Claude : + +```markdown + +--- +description: Audit sécurité des fichiers Terraform +allowed-tools: Read, Grep, Bash +disable-model-invocation: false # Peut être invoqué auto ou via /project:audit-terraform +--- + +Analyse tous les fichiers Terraform (*.tf) dans le répertoire courant. +Pour chaque fichier : +1. Vérifie les ressources exposées publiquement +2. Identifie les secrets en dur +3. Vérifie les tags obligatoires + +Génère un rapport markdown avec résumé par sévérité. +``` + +{{% notice tip "Progressive Disclosure" %}} +Pour les Skills complexes, utilisez une structure en dossier avec des fichiers `references/`. Claude charge d'abord le `SKILL.md` principal (~2000 mots max), puis les références détaillées uniquement si nécessaire. Cela optimise la consommation de tokens. +``` +.claude/skills/k8s-troubleshooter/ +├── SKILL.md # Essentiels (~1800 mots) +└── references/ + ├── patterns.md # Détails chargés à la demande + └── advanced.md +``` +{{% /notice %}} + +#### Skills pour le Platform Engineering + +Le repo **[cc-devops-skills](https://github.com/akin-ozer/cc-devops-skills)** propose une collection de 31 skills DevOps organisés par catégorie. Voici les patterns à retenir : + +| Catégorie | Skills | Pattern | +|-----------|--------|---------| +| **Infrastructure** | Terraform, Terragrunt, Ansible | Generator + Validator | +| **Containers/K8s** | Docker, Kubernetes, Helm | Manifest + Debug | +| **CI/CD** | GitHub Actions, GitLab CI, Jenkins | Pipeline + Lint | +| **Observabilité** | PromQL, LogQL, Fluent Bit | Query builder | + +**Le pattern Generator-Validator** : Chaque domaine a deux skills complémentaires. Le *generator* crée des ressources suivant les best practices, le *validator* vérifie la syntaxe et la sécurité. Ce workflow garantit une qualité constante : + +``` +Generator (best practices) → Validator (lint/security) → Fix → Output +``` + +**Exemple de skill PromQL pour le platform engineering :** +```markdown + +--- +description: Génère des requêtes PromQL optimisées pour VictoriaMetrics +--- + +## Contexte +Tu es expert en PromQL pour VictoriaMetrics/Prometheus. + +## Règles +- Utilise `rate()` sur 5m minimum pour les counters +- Préfère `topk()` pour limiter la cardinalité +- Ajoute toujours un label `job` dans les filtres +- Utilise `recording rules` pour les requêtes coûteuses + +## Patterns courants +### Latence P99 +histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) + +### Error rate +sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) +``` + +#### Agents personnalisés : processus autonomes + +Les **agents** restent un concept distinct : ce sont des **subprocess autonomes** capables de prendre des décisions intermédiaires. Idéal pour les tâches multi-étapes complexes. + +```markdown + +--- +name: k8s-security-reviewer +description: | + Use this agent when the user asks to "review Kubernetes manifests for security", + "audit K8s security", or when reviewing PRs containing K8s YAML files. +model: sonnet +--- + +## Rôle +Expert en sécurité Kubernetes qui audite les manifests. + +## Processus +1. **Scan** : Trouver tous les fichiers YAML K8s +2. **Analyse** : SecurityContext, NetworkPolicies, RBAC +3. **Scoring** : Attribuer un score de sécurité +4. **Remédiation** : Proposer des correctifs concrets +``` + +| Aspect | Skills/Commands unifiés | Agents | +|--------|------------------------|--------| +| **Exécution** | Contexte principal | Subprocess isolé | +| **Mémoire** | Partagée avec la conversation | Contexte propre | +| **Parallélisme** | Non | Jusqu'à 10 simultanés | +| **Cas d'usage** | Connaissances, actions ciblées | Tâches multi-étapes, audit parallèle | + +### Les Hooks : automatiser et être notifié + +Les **Hooks** permettent d'exécuter des commandes shell à des moments précis du cycle de vie de Claude Code : `PreToolUse`, `PostToolUse`, `Stop`, `SessionStart`. + +Le cas d'usage le plus pratique : **être notifié** quand Claude a fini une tâche longue. + +```json +// .claude/settings.json +{ + "hooks": { + "Stop": [ + { + "matcher": "", + "hooks": [ + { + "type": "command", + "command": "~/.local/bin/claude-notify.sh" + } + ] + } + ] + } +} +``` + +Les hooks permettent aussi la validation automatique (lint avant commit), le blocage d'actions dangereuses, et bien plus. Consultez la [documentation officielle](https://docs.anthropic.com/en/docs/claude-code/hooks) et [claude-code-hooks-mastery](https://github.com/disler/claude-code-hooks-mastery) pour des exemples avancés. + +--- + +## :rocket: Cas concrets de platform engineering + +Assez de théorie ! Passons à ce qui nous intéresse vraiment : comment Claude Code peut nous aider au quotidien. Je vais vous partager deux cas concrets et détaillés qui illustrent la puissance des MCPs et du workflow avec Claude. + +### :mag: Cas 1 : Troubleshooting complet d'une Network Policy + +Ce cas illustre un workflow de troubleshooting de bout en bout, en utilisant plusieurs MCPs pour identifier et résoudre un problème réseau. + +#### Le contexte + +Après un déploiement, une application ne peut plus communiquer avec un service dans un autre namespace. Les logs montrent des timeouts mais aucune erreur explicite. Une alerte VictoriaMetrics a été déclenchée. + +#### Étape 1 : Identifier les alertes actives + +Avec le **MCP VictoriaMetrics**, je demande à Claude d'analyser les alertes : + +``` +> Utilise le MCP VictoriaMetrics pour lister les alertes actives +> sur le namespace demo. Quelles sont les alertes de type réseau ? +``` + +Claude interroge l'API et trouve : + +``` +ALERTES ACTIVES - namespace demo + +| Alerte | Sévérité | Depuis | Description | +|--------|----------|--------|-------------| +| HTTPHighLatency | warning | 15min | Latence HTTP > 5s (service backend) | +| CiliumDropsHigh | critical | 12min | Drops réseau élevés (>100/min) | +| EndpointNotReady | warning | 15min | Endpoint postgres non atteignable | +``` + +#### Étape 2 : Analyser les logs avec VictoriaLogs + +Je demande à Claude de corréler avec les logs via le **MCP VictoriaLogs** : + +``` +> Utilise le MCP VictoriaLogs pour chercher les erreurs de connexion +> dans le namespace demo des 30 dernières minutes. +``` + +Claude identifie : les timeouts commencent exactement à 14:32, soit **2 minutes après un déploiement** d'une nouvelle NetworkPolicy. + +#### Étape 3 : Investigation et correction + +Claude trouve la policy problématique — il manque le selector de namespace : + +```yaml {hl_lines=[12]} +# Correction proposée +spec: + ingress: + - fromEndpoints: + - matchLabels: + k8s:io.kubernetes.pod.namespace: demo # ✅ Ajouté + app: backend +``` + +#### Étape 4 : Créer une VMRule de prévention + +Pour éviter que ce problème ne se reproduise, je demande une alerte préventive. Claude génère une `VMRule` qui alerte sur les drops Cilium vers les services database. + +#### Résumé du workflow + +| Étape | MCP utilisé | Action | +|-------|-------------|--------| +| 1 | VictoriaMetrics | Identifier les alertes | +| 2 | VictoriaLogs | Analyser les logs, corréler | +| 3 | kubectl | Lister et corriger les NetworkPolicies | +| 4 | — | Créer VMRule prévention | + +{{% notice tip "Ce qui a fait la différence" %}} +Avec les MCPs, Claude a fait tout cela en **5 minutes** au lieu de 45 minutes de navigation manuelle entre VMUI, les logs, et Grafana. +{{% /notice %}} + +--- + +### :building_construction: Cas 2 : Feature produit avec Spec-Driven Development + +{{% notice info "Qu'est-ce que le Spec-Driven Development (SDD) ?" %}} +Le **Spec-Driven Development** est un paradigme où les spécifications — et non le code — servent d'artefact principal. À l'ère de l'IA agentique, le SDD fournit les garde-fous nécessaires pour éviter le "Vibe Coding" (prompting non structuré) et garantir que les agents produisent du code maintenable. + +**Principes clés :** +- **Intent as Sovereign** : Si le code et la spec divergent, c'est le code qui est "buggy" +- **Specs exécutables** : Les agents traitent les specs comme des instructions de haut niveau +- **Human-in-the-Loop** : Vous validez la Spec et le Plan, l'IA gère l'implémentation + +**Le workflow type** : `Specify → Clarify → Tasks → Implement → Validate` + +**Les frameworks majeurs en 2026 :** + +| Framework | Force principale | Cas d'usage idéal | +|-----------|-----------------|-------------------| +| **[GitHub Spec Kit](https://github.com/github/spec-kit)** | Intégration native GitHub/Copilot | Projets greenfield, workflow structuré | +| **[BMAD](https://github.com/bmad-sim/bmad-method)** | Équipes multi-agents (PM, Architect, Dev) | Systèmes complexes multi-repos | +| **[OpenSpec](https://github.com/Fission-AI/OpenSpec)** | Léger, centré sur les changements | Projets brownfield, itération rapide | + +Pour cet article, j'utilise une variante inspirée de GitHub Spec Kit, adaptée au platform engineering. +{{% /notice %}} + +{{% notice warning "Alternative : la technique Ralph Wiggum (pour le vibe coding)" %}} +Le **[Ralph Wiggum](https://github.com/ghuntley/how-to-ralph-wiggum)** de [Geoff Huntley](https://ghuntley.com/ralph/) est une méthodologie orientée vers l'**autonomie maximale** — idéale pour le **vibe coding** et les projets **greenfield**. + +**Le principe** : une boucle bash qui relance Claude jusqu'à complétion, avec git comme mémoire. +```bash +while :; do cat PROMPT.md | claude --dangerously-skip-permissions; done +``` + +**Cas d'usage validés** : +- Une équipe YC a généré **6 MVPs complets** en une nuit avec Ralph +- Huntley a créé un **langage de programmation entier** (CURSED) via des boucles Ralph sur 3 mois +- Coût d'un MVP testé : ~300$ USD vs 50k$ en outsourcing traditionnel + +| Aspect | SDD (Platform Engineering) | Ralph (Vibe Coding) | +|--------|---------------------------|---------------------| +| **Cas idéal** | Infra existante, prod | Projets from scratch, MVPs | +| **Vérification** | Humain valide spec/plan | Tests automatisés, linters | +| **Contrôle** | Human-in-the-Loop | Autonomie totale | +| **Risque** | Faible (checkpoints) | Nécessite sandbox strict | + +**Mon avis** : Ralph brille pour le **développement applicatif from scratch** où les tests automatisés valident le résultat. Pour le platform engineering (Terraform, Kubernetes, cloud), je préfère le SDD — les erreurs d'infrastructure sont souvent irréversibles et coûteuses. +{{% /notice %}} + +Ce cas illustre comment utiliser Claude pour implémenter une vraie feature produit en suivant une approche SDD. + +#### Le contexte + +L'équipe produit veut pouvoir choisir entre **Kafka (Strimzi)** et **AWS SQS** pour le queuing de leurs applications. Actuellement, aucune abstraction n'existe. + +#### Étape 1 : Créer la spec avec `/specify` + +La commande `/specify` est le point d'entrée du SDD. Elle crée automatiquement l'issue GitHub et le fichier de spec : + +``` +> /specify composition "Queue composition for Kafka and SQS backends" +``` + +Claude exécute la commande qui : +1. Crée une **GitHub Issue** `[SPEC] Queue composition for Kafka and SQS backends` +2. Génère un fichier de spec `docs/specs/active/0002-#42-queue-kafka-sqs.md` +3. Pré-remplit avec le template approprié +4. Lit la **constitution** du projet pour les contraintes non-négociables + +``` +✅ Specification created! + +🔗 GitHub Issue: https://github.com/Smana/cloud-native-ref/issues/42 +📄 Spec File: docs/specs/active/0002-#42-queue-kafka-sqs.md + +## Review Personas (before implementation) +- [ ] PM: Problem clear? User stories valid? +- [ ] Platform Engineer: Patterns consistent? Implementation feasible? +- [ ] Security: Zero-trust? Least privilege? +- [ ] SRE: Observable? Recoverable? +``` + +#### Étape 2 : Clarifier avec `/clarify` + +Je complète la spec en ajoutant des marqueurs `[NEEDS CLARIFICATION]` pour les points à éclaircir : + +```markdown +[NEEDS CLARIFICATION: Faut-il supporter les FIFO queues pour SQS ?] +[NEEDS CLARIFICATION: Quelle version de Kafka par défaut ?] +``` + +Puis j'exécute `/clarify` — Claude trouve les marqueurs, me pose les questions, et remplace par `[CLARIFIED: ...]`. + +#### Étape 3 : Implémenter en suivant la spec + +Claude implémente en respectant la spec ET la constitution du projet (préfixe `xplane-*`, pas de mutation KCL, etc.). + +#### Étape 4 : Créer la PR avec `/create-pr` + +La commande `/create-pr` détecte automatiquement la spec active et génère un PR avec référence `Implements #42`. + +#### Résultat : l'API utilisateur finale + +Le développeur peut maintenant simplement déclarer : + +```yaml +apiVersion: cloud.ogenki.io/v1alpha1 +kind: Queue +metadata: + name: orders-queue + namespace: ecommerce +spec: + queue: + type: kafka + size: medium +``` + +{{% notice info "Pourquoi le modèle à deux documents ?" %}} +- **GitHub Issue** : Discoverabilité, discussion, ancre immuable +- **Spec File** : Design détaillé, checklists des 4 personas +- **Après merge** : Spec archivée dans `docs/specs/completed/` pour référence historique +{{% /notice %}} + +--- + +## :bulb: Optimiser son utilisation + +### Git Worktrees : paralléliser les sessions Claude + +Plutôt que de jongler avec des branches et du `stash`, utilisez les **git worktrees** pour travailler sur plusieurs features en parallèle avec des sessions Claude indépendantes. + +```console +# Créer des worktrees pour deux features +git worktree add ../worktrees/feature-a -b feat/feature-a +git worktree add ../worktrees/feature-b -b feat/feature-b + +# Lancer des sessions Claude séparées +cd ../worktrees/feature-a && claude # Terminal 1 +cd ../worktrees/feature-b && claude # Terminal 2 +``` + +Chaque session a son **propre contexte** et sa propre mémoire — aucune interférence entre les tâches. + +### Le workflow hybride Cursor + Claude Code + +C'est l'approche que je recommande : **Cursor** pour l'édition quotidienne, **Claude Code** pour les tâches agentiques. + +
Cursor + Claude Code
+ +| Besoin | Outil | Pourquoi | +|--------|-------|----------| +| Édition rapide, autocomplete | Cursor | Latence minimale, vous restez dans le flow | +| Refactoring, debugging multi-fichiers | Claude Code | Raisonnement profond, boucles autonomes | + +**Le vrai gain** : Claude modifie via le terminal, vous validez les diffs dans l'interface Cursor — bien plus lisible que `git diff`. + +### Économiser le contexte + +Le contexte est précieux (et coûteux). Quelques règles simples : + +1. **`/clear` entre les tâches** : Chaque nouvelle tâche devrait commencer par un `/clear` +2. **CLAUDE.md concis** : Chaque token est chargé à chaque conversation +3. **CLIs > MCPs** : Pour Kubernetes, `kubectl` consomme moins de tokens +4. **`/context` pour auditer** : Identifiez ce qui consomme et désactivez les MCPs non utilisés + +### Choisir le bon modèle + +C'est **LA** clé pour optimiser ses coûts : + +| Tâche | Modèle | Pourquoi | +|-------|--------|----------| +| Debugging complexe | **Opus 4.5** | Analyse profonde, corrélation | +| Génération YAML/Terraform | **Sonnet 4.5** | Suffisamment précis, moins cher | +| Commits, petites éditions | **Haiku** | Rapide et économique | + +```console +# Changer de modèle en cours de session +/model sonnet +``` + +{{% notice tip "Le conseil de Boris Cherny (créateur de Claude Code)" %}} +*"J'utilise Opus 4.5 avec thinking pour tout. Comme vous avez moins besoin de le guider, il est presque toujours plus rapide au final."* + +Mon avis : vrai pour les tâches complexes, mais Haiku reste plus économique pour les tâches simples. +{{% /notice %}} + +### Ce qui fonctionne bien vs ce qui nécessite vigilance + +| ✅ Claude excelle | ⚠️ Vigilance requise | +|-------------------|----------------------| +| Debugging avec contexte | Création from scratch | +| Conversion de formats | Sécurité/PKI | +| Refactoring répétitif | Ressources cloud coûteuses | +| Analyse de dépendances | Breaking changes | + +### Plugins recommandés + +Claude Code dispose d'un écosystème de plugins qui étendent ses capacités. Voici deux plugins particulièrement utiles : + +#### Code-Simplifier : nettoyer le code généré + +Le plugin **[code-simplifier](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier)** est développé par Anthropic et utilisé en interne par l'équipe Claude Code. Il nettoie automatiquement le code généré par l'IA tout en préservant la fonctionnalité. + +**Cas d'usage** : Après une longue session de coding où Claude a implémenté plusieurs features, lancez le code-simplifier pour éliminer le code dupliqué, simplifier les structures complexes et harmoniser le style. + +{{% notice tip "Mon workflow" %}} +J'utilise systématiquement le code-simplifier avant de créer une PR après une session intensive. Il tourne sur Opus et peut significativement réduire la dette technique introduite par le code IA. +{{% /notice %}} + +#### Claude-Mem : mémoire persistante entre sessions + +Le plugin **[claude-mem](https://github.com/thedotmack/claude-mem)** capture automatiquement le contexte de vos sessions et le réinjecte dans les sessions futures. Plus besoin de réexpliquer votre projet à chaque nouvelle conversation. + +**Fonctionnalités clés :** +- **Capture automatique** : Enregistre les actions Claude (tool usage, décisions) +- **Recherche sémantique** : Skill `mem-search` pour retrouver des informations passées +- **Interface web** : Dashboard sur `http://localhost:37777` +- **Workflow 3-layer** : Optimise la consommation de tokens (~10x d'économie) + +{{% notice warning "Considérations de confidentialité" %}} +Claude-mem stocke localement les données de session. Pour les projets sensibles, utilisez les tags `` pour exclure des informations de la capture. +{{% /notice %}} + +--- + +## :thought_balloon: Réflexions et mises en garde + +### Éviter la dépendance : continuer à apprendre + +C'est peut-être le point le plus important. Une [étude METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) a trouvé un résultat surprenant : les développeurs utilisant l'IA prennent **19% plus de temps** pour compléter des tâches ! Pourtant, ils *croient* avoir été plus rapides de 24%. + +**Comment maintenir ses compétences :** + +1. **Reviewer systématiquement** le code généré — comprendre *pourquoi* cette solution +2. **Se forcer à des sessions "sans IA"** — une fois par semaine, débugger à l'ancienne +3. **Enseigner aux autres** — expliquer le code généré force à le comprendre + +### Qualité du code et dette technique + +Selon une [étude Qodo](https://www.qodo.ai/reports/state-of-ai-code-quality/), le code IA génère **4× plus de code dupliqué** et la dette technique est la frustration n°1 des développeurs (62.4%). + +Mon conseil : demandez explicitement la solution la plus simple possible. + +### Hallucinations et contexte manquant + +Malgré les progrès, **25%** des développeurs estiment qu'1 suggestion sur 5 contient des erreurs. + +**Comment mitiger :** +```console +# Toujours spécifier les versions +> Utilise Terraform 1.11 et le provider AWS 6.x + +# Utiliser context7 pour la doc à jour +> use context7 pour la doc Cilium 1.15 +``` + +### Sécurité et confidentialité + +Un point crucial à comprendre : **ce que vous envoyez à Claude est utilisé différemment selon votre plan**. + +| Aspect | Free / Pro / Max | Team / Enterprise | +|--------|------------------|-------------------| +| **Training sur vos données** | Oui (par défaut) | **Non** | +| **Rétention données** | 30 jours | Configurable | +| **Zero Data Retention** | Non disponible | Option disponible | +| **SSO / Audit logs** | Non | Oui | + +{{% notice warning "Pour le code propriétaire" %}} +Si vous travaillez sur du code sensible ou propriétaire : +- Utilisez le plan **Team** ou **Enterprise** — vos données ne servent pas à l'entraînement +- Demandez l'option **Zero-Data-Retention** (ZDR) si nécessaire +- N'utilisez **jamais** le plan Free/Pro pour du code confidentiel + +Consultez la [documentation sur la confidentialité](https://www.anthropic.com/policies/privacy) pour plus de détails. +{{% /notice %}} + +### Mes règles personnelles + +1. **Jamais de merge sans review manuelle** — même si les tests passent +2. **Toujours comprendre avant d'appliquer** — si je ne comprends pas, je ne merge pas +3. **Une heure de "no-AI" par jour** — pour rester capable de travailler sans +4. **Vérifier les claims techniques** — consulter la doc officielle +5. **Documenter ce que Claude a fait** — pour moi-même dans 6 mois + +### Le risque du vendor locking + +C'est une préoccupation que je partage avec beaucoup de développeurs : **que se passe-t-il si Anthropic change les règles du jeu ?** + +Cette crainte s'est matérialisée début janvier 2026. Anthropic a [bloqué sans préavis](https://venturebeat.com/technology/anthropic-cracks-down-on-unauthorized-claude-usage-by-third-party-harnesses) l'accès à Claude via des outils tiers comme [OpenCode](https://github.com/opencode-ai/opencode). Des développeurs payant 200$/mois pour Max se sont retrouvés du jour au lendemain incapables d'utiliser leur abonnement avec leurs outils préférés. [DHH](https://twitter.com/dhh), le créateur de Ruby on Rails, a qualifié cette décision de "customer hostile". + +La justification officielle ? Éviter le "spoofing" et les bugs introduits par des wrappers non officiels. La réalité économique ? Un abonnement Max à 200$/mois offre des tokens illimités via Claude Code, alors que le même usage via l'API coûterait 1000$+. + +{{% notice warning "Alternatives open source à surveiller" %}} +Pour réduire la dépendance à un seul fournisseur, plusieurs alternatives méritent attention : + +| Outil | Type | Modèle | Particularité | +|-------|------|--------|---------------| +| **[Mistral Vibe](https://mistral.ai/news/devstral-2-vibe-cli)** | CLI | Devstral 2 (123B) | Open source, 72.2% SWE-bench | +| **[Aider](https://aider.chat/)** | CLI | Multi-modèles | Intégration Git native | +| **[Cline](https://cline.bot/)** | VS Code | Multi-modèles | Open source, support MCP | +| **[Continue.dev](https://continue.dev/)** | IDE | Multi-modèles | Modèles locaux via Ollama | + +J'ai pour objectif de tester **Devstral** et **Mistral Vibe** prochainement — le score SWE-bench est prometteur et l'approche open source plus rassurante sur le long terme. +{{% /notice %}} + +--- + +## :dart: Conclusion + +Les coding agents comme Claude Code ne sont pas un gadget, mais un **véritable changement de paradigme** dans notre façon de travailler. + +### Ce que j'ai appris + +| Aspect | Avant Claude Code | Avec Claude Code | +|--------|-------------------|------------------| +| Debugging Cilium | 2h de lecture de logs | 15 min avec contexte | +| Refactoring Terraform | Journée entière | 2h avec review | +| Écriture de doc | Procrastination | Généré + relu = 30 min | +| Onboarding nouveau repo | Plusieurs jours | Quelques heures | + +### Les clés du succès + +1. **Investir dans le contexte** : Un bon `CLAUDE.md` fait toute la différence +2. **Choisir le bon modèle** : Opus pour le complexe, Haiku pour le simple +3. **Maintenir l'esprit critique** : Review systématique, jamais d'acceptation aveugle +4. **Continuer à apprendre** : L'IA augmente, elle ne remplace pas + +### Et pour la suite ? + +Le domaine évolue à une vitesse folle. Mon conseil : **expérimentez maintenant**. Même si vous êtes sceptique, prenez une heure pour tester. + +{{% notice info "Rejoignez la discussion" %}} +J'aimerais beaucoup avoir vos retours d'expérience ! N'hésitez pas à me contacter ou à ouvrir une issue sur le [repo cloud-native-ref](https://github.com/Smana/cloud-native-ref). +{{% /notice %}} + +--- + +## :bookmark: Références + +### Documentation et guides +- [Claude Code Documentation](https://docs.anthropic.com/en/docs/claude-code) — Documentation officielle +- [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) — Anthropic Engineering +- [How I Use Every Claude Code Feature](https://blog.sshh.io/p/how-i-use-every-claude-code-feature) — Guide complet +- [Model Context Protocol](https://modelcontextprotocol.io/) — Spécification officielle +- [Claude Pricing](https://www.anthropic.com/pricing) — Tarification à jour + +### Spec-Driven Development et méthodologies +- [GitHub Spec Kit](https://github.com/github/spec-kit) — Toolkit SDD de GitHub +- [OpenSpec](https://github.com/Fission-AI/OpenSpec) — SDD léger pour projets brownfield +- [BMAD Method](https://github.com/bmad-sim/bmad-method) — Multi-agent SDD +- [Ralph Wiggum Technique](https://github.com/ghuntley/how-to-ralph-wiggum) — Boucle autonome (Geoff Huntley) +- [Ralph Playbook](https://github.com/ClaytonFarr/ralph-playbook) — Guide complet Ralph +- [Spec-driven development with AI](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) — GitHub Blog + +### Plugins et Skills +- [Claude Plugins Official](https://github.com/anthropics/claude-plugins-official) — Plugins officiels Anthropic +- [Code-Simplifier](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier) — Nettoyage de code IA +- [Claude-Mem](https://github.com/thedotmack/claude-mem) — Mémoire persistante entre sessions +- [CC-DevOps-Skills](https://github.com/akin-ozer/cc-devops-skills) — 31 skills DevOps prêts à l'emploi +- [Awesome Claude Code Plugins](https://github.com/ccplugins/awesome-claude-code-plugins) — Liste curatée de plugins + +### MCPs pour Platform Engineering +- [Context7 MCP](https://github.com/upstash/context7) — Documentation à jour (Upstash) +- [Flux MCP Server](https://fluxcd.control-plane.io/mcp/) — GitOps et Flux (ControlPlane) +- [VictoriaMetrics MCP](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics) — Métriques PromQL +- [VictoriaLogs MCP](https://github.com/VictoriaMetrics-Community/mcp-victorialogs) — Logs LogsQL +- [Grafana MCP](https://github.com/grafana/mcp-grafana) — Dashboards et alertes +- [Steampipe MCP](https://github.com/turbot/steampipe-mcp) — Requêtes SQL cloud (Turbot) + +### Articles et études +- [Opus 4.5 is going to change everything](https://burkeholland.github.io/posts/opus-4-5-change-everything/) — Burke Holland +- [METR Study on AI Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — Étude sur la productivité +- [State of AI Code Quality 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/) — Qodo +- [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — Anthropic Research + +### Outils et ressources +- [Cloud Native Ref](https://github.com/Smana/cloud-native-ref) — Mon repo de référence +- [Claude Code Hooks Mastery](https://github.com/disler/claude-code-hooks-mastery) — Exemples de hooks +- [SWE-bench Leaderboards](https://www.swebench.com/) — Benchmark de référence diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/index.md b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md new file mode 100644 index 00000000..774442cc --- /dev/null +++ b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md @@ -0,0 +1,553 @@ ++++ +author = "Smaine Kahlouch" +title = "`Agentic Coding` : concepts et cas concrets appliqués au Platform Engineering" +date = "2026-01-29" +summary = "Explorer l'**agentic coding** à travers `Claude Code` : des fondamentaux (tokens, MCPs, skills) aux cas pratiques, avec un regard enthousiaste mais lucide sur cette nouvelle façon de travailler." +featured = true +codeMaxLines = 30 +usePageBundles = true +toc = true +series = ["Agentic AI"] +tags = [ + "ai", + "devxp", + "tooling" +] +aliases = ["/fr/post/ai-coding-agent/"] +thumbnail = "thumbnail.png" ++++ + +Nous le voyons bien, nous assistons à un réel bouleversement provoqué par l'**utilisation de l'IA**. Ce domaine évolue à une telle vitesse qu'il devient presque impossible de suivre toutes les nouveautés. Quant à mesurer l'impact sur notre quotidien et notre façon de travailler, il est encore trop tôt pour le dire. Une chose est sûre cependant : dans la tech, c'est une **révolution** ! + +Ici, je vais vous présenter une utilisation pratique dans le métier du **"Platform Engineering"** avec une exploration de l'utilisation d'un "**coding agent**" dans certaines tâches communes de notre métier. + +Mais surtout, je vais tenter de vous démontrer par des cas concrets que cette nouvelle façon de travailler augmente **réellement** notre productivité. Si si ! + +## :dart: Objectifs de cet article + +* Comprendre ce qu'est un **coding agent** +* Découvrir les concepts clés : tokens, MCPs, skills, agents +* **Cas concrets** d'utilisation dans le platform engineering +* Réflexions sur les limites, pièges à éviter et alternatives +* Pour les tips d'optimisation avancés, consultez l'[article dédié](/fr/post/series/agentic_ai/ai-coding-tips/) + +{{% notice tip "Le repo de référence" %}} + + + + + +
+Les exemples qui suivent sont issus de mon travail sur le repository Cloud Native Ref. Il s'agit d'une plateforme complète combinant EKS, Cilium, VictoriaMetrics, Crossplane, Flux et bien d'autres outils. +
+{{% /notice %}} + +--- + +## :brain: L'intérêt des _Coding Agents_? + +### Qu'est-ce qui différencie un agent d'un chatbot ? + +Vous utilisez probablement déjà ChatGPT, LeChat ou Gemini pour poser des questions. C'est cool, mais ça reste du **one-shot** : vous posez une question, vous obtenez une réponse dont la pertinence dépendra de la qualité de votre prompt. + +Un **coding agent** fonctionne différemment. Il exécute des outils en boucle pour atteindre un objectif. C'est ce qu'on appelle une [**boucle agentique**](https://simonwillison.net/2025/Sep/30/designing-agentic-loops/). + +{{< img src="agentic-loop.png" alt="Agentic loop" width="580" >}} + +Le cycle est simple : **raisonner → agir → observer → répéter**. L'agent appelle un outil, analyse le résultat, puis décide de la prochaine action. Il est donc essentiel qu'il ait accès au **retour de chaque action** — une erreur de compilation, un test qui échoue, une sortie inattendue. Cette capacité à réagir et **itérer de manière autonome** sur notre environnement local est ce qui fait toute la différence avec un simple chatbot. + +Un coding agent combine plusieurs composants : + +* **LLM** : Le "cerveau" qui raisonne (Claude Opus 4.5, Gemini 3 Pro, Devstral 2...) +* **Tools** : Les actions possibles (lire/écrire des fichiers, exécuter des commandes, chercher sur le web...) +* **Memory** : Le contexte conservé (fichiers `CLAUDE.md`, `AGENTS.md`, `GEMINI.md`... selon l'outil, plus l'historique de conversation) +* **Planning** : La capacité à décomposer une tâche complexe en sous-étapes + +### Bien choisir son modèle, dur de suivre la cadence 🤯 + +De nouveaux modèles ainsi que de nouvelles versions apparaissent à une vitesse effrénée. Il faut cependant être vigilant dans le choix du modèle car l'efficacité (qualité de code, hallucinations, contexte à jour) peut **radicalement différer**. + +Le benchmark [**SWE-bench Verified**](https://www.swebench.com/) est devenu la référence pour évaluer les capacités des modèles en développement logiciel. Il mesure la capacité à résoudre de vrais bugs issus de repositories GitHub et permet de nous aider à faire notre choix. + +{{< img src="swe-bench-leaderboard.png" alt="Leaderboard SWE-bench Verified" width="900" >}} + +{{% notice warning "Ces chiffres évoluent très vite !" %}} +Consultez [swebench.com](https://www.swebench.com/) pour les derniers résultats. Au moment de la rédaction, Claude Opus 4.5 mène avec **74.4%**, talonné par Gemini 3 Pro (**74.2%**). +{{% /notice %}} + +En pratique, les meilleurs modèles actuels sont tous suffisamment performants pour la plupart des tâches de _Platform Engineering_. + +{{% notice info "L'importance du choix de modèle" %}} +Boris Cherny, créateur de Claude Code, [indiquait](https://x.com/bcherny/status/2007179832300581177) qu'il utilise exclusivement Opus 4.5 avec thinking — malgré sa lenteur par rapport à Sonnet, le fait de moins devoir le guider le rend plus productif au final. + +Mon expérience va dans le même sens : avec un modèle plus capable, on passe moins de temps à reformuler et corriger, ce qui compense largement la latence supplémentaire. +{{% /notice %}} + +### Pourquoi Claude Code ? + +Il existe de nombreuses options de coding agents, dont voici quelques exemples : + +| Outil | Type | Forces | +|-------|------|--------| +| [**Claude Code**](https://docs.anthropic.com/en/docs/claude-code) | Terminal | Context 200K, SWE-bench élevé, hooks & MCP | +| [**opencode**](https://opencode.ai/) | Terminal | **Open source**, multi-provider, modèles locaux (Ollama) | +| [**Cursor**](https://cursor.sh/) | IDE | Workflow visuel, Composer mode | +| [**Antigravity**](https://antigravity.google/) | IDE | Agents parallèles, Manager view | + +Nous pouvons aussi citer les alternatives suivantes (liste non exhaustive) : [Gemini CLI](https://github.com/google-gemini/gemini-cli), [Mistral Vibe](https://mistral.ai/news/devstral-2-vibe-cli), [GitHub Copilot](https://github.com/features/copilot)... + +J'ai utilisé Cursor dans un premier temps, puis je suis passé à Claude Code. Probablement en raison de mon **background de sysadmin** plutôt porté sur le terminal. Là où d'autres préfèrent travailler exclusivement dans leur IDE, je me sens plus à l'aise avec une CLI. + +--- + +## :books: Les concepts essentiels de Claude Code + +Cette section va droit à l'essentiel : **tokens, MCPs, Skills et Tasks**. Je passe sur la config initiale (la [doc officielle](https://docs.anthropic.com/en/docs/claude-code) fait ça très bien) et sur les subagents — c'est de la mécanique interne, ce qui compte c'est ce qu'on peut *construire* avec. La plupart de ces concepts **s'appliquent aussi à d'autres coding agents**. + +### Tokens et fenêtre de contexte + +#### L'essentiel sur les tokens + +Un **token** est l'unité de base que le modèle traite — environ 4 caractères en anglais, 2-3 en français. Pourquoi c'est important ? Parce que **tout se paye en tokens** : input, output, et contexte. + +La **fenêtre de contexte** (200K tokens pour Claude) représente la "mémoire de travail" du modèle. La commande `/context` permet de visualiser comment cet espace est utilisé : + +```console +/context +``` + +{{< img src="cmd_context.png" alt="Visualisation du contexte avec /context" width="650" >}} + +Cette vue détaille la répartition du contexte entre les différents composants : + +* **System prompt/tools** : Coût fixe de Claude Code (~10%) +* **MCP tools** : Définitions des MCPs activés +* **Memory files** : `CLAUDE.md`, `AGENTS.md`... +* **Messages** : Historique de conversation +* **Autocompact buffer** : Réservé pour la compression automatique +* **Free space** : Espace disponible pour continuer + + + + + + +
+Une fois la limite atteinte, les informations les plus anciennes sont tout simplement oubliées. Heureusement, Claude Code dispose d'un mécanisme d'auto-compaction : quand la conversation approche des 200K tokens, il compresse intelligemment l'historique en conservant les décisions importantes tout en éliminant les échanges verbeux. Ce mécanisme permet de travailler sur des sessions longues sans perdre le fil — mais une compaction fréquente dégrade la qualité du contexte. D'où l'intérêt d'utiliser /clear entre les tâches distinctes. +
+ +### Les MCPs : un langage universel + +Le **Model Context Protocol** (MCP) est un standard ouvert créé par Anthropic qui permet aux agents IA de se connecter à des sources de données et outils externes de manière standardisée. + +{{% notice info "Gouvernance ouverte" %}} +En décembre 2025, Anthropic a [confié MCP à la Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) via l'Agentic AI Foundation. OpenAI, Google, Microsoft et AWS font partie des membres fondateurs. +{{% /notice %}} + +Il existe une multitude de serveurs MCP. Voici ceux que j'utilise régulièrement pour interagir avec ma plateforme — **configuration, troubleshooting, analyse** : + +| MCP | À quoi ça sert | Exemple concret | +|-----|----------------|-----------------| +| **[context7](https://github.com/upstash/context7)** | Doc à jour des libs/frameworks | "Utilise context7 pour la doc Cilium 1.16" → évite les hallucinations sur des APIs qui ont changé | +| **[flux](https://fluxcd.control-plane.io/mcp/)** | Debug GitOps, état des reconciliations | "Pourquoi mon HelmRelease est stuck ?" → Claude inspecte directement l'état Flux | +| **[victoriametrics](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics)** | Requêtes PromQL, exploration métriques | "Quelles métriques Karpenter sont dispo ?" → liste et requête en direct | +| **[victorialogs](https://github.com/VictoriaMetrics-Community/mcp-victorialogs)** | Requêtes LogsQL, analyse logs | "Trouve les erreurs Crossplane des 2 dernières heures" → root cause analysis | +| **[grafana](https://github.com/grafana/mcp-grafana)** | Dashboards, alertes, annotations | "Crée un dashboard pour ces métriques" → génère et déploie le JSON | +| **[steampipe](https://github.com/turbot/steampipe-mcp)** | Requêtes SQL sur infra cloud | "Liste les buckets S3 publics" → audit multi-cloud en une question | + +{{% notice tip "Configuration globale ou locale?" %}} +Les MCPs peuvent être configurés globalement (`~/.claude/mcp.json`) ou par projet (`.mcp.json`). J'utilise `context7` globalement car je m'en sers quasi systématiquement, les autres au niveau du repo. +{{% /notice %}} + +### Skills : obtenir de nouveaux pouvoirs + +{{< img src="skill-acquired-notif.png" width="450" >}} + +C'est probablement la fonctionnalité qui suscite le plus d'enthousiasme dans la communauté — et à juste titre, elle permet vraiment d'étendre les capacités de l'agent ! Un **skill** est un fichier Markdown (`.claude/skills/*/SKILL.md`) qui permet d'injecter des **conventions**, **patterns** et **procédures** spécifiques à votre projet. + +Concrètement ? Vous définissez une fois comment créer une PR propre, comment valider une composition Crossplane, ou comment débugger un problème Cilium — et Claude applique ces règles à chaque situation. C'est du **savoir-faire encapsulé** que vous pouvez partager avec votre équipe. + +**Deux modes de chargement :** + +* **Automatique** : Claude analyse la description du skill et le charge quand c'est pertinent +* **Explicite** : Vous invoquez directement via `/nom-du-skill` + +{{% notice info "Un format qui se répand" %}} +Le format `SKILL.md` introduit par Anthropic est devenu une **convention de facto** : [GitHub Copilot](https://docs.github.com/en/copilot/concepts/agents/about-agent-skills), [Google Antigravity](https://codelabs.developers.google.com/getting-started-with-antigravity-skills), Cursor, OpenAI Codex et d'autres adoptent le même format (YAML frontmatter + Markdown). Seul le répertoire change (`.claude/skills/`, `.github/skills/`...). Les skills que vous créez sont donc **réutilisables d'un outil à l'autre**. +{{% /notice %}} + +#### Anatomie d'un skill + +Un skill se compose d'un **frontmatter YAML** (métadonnées) et d'un **contenu Markdown** (instructions). Voici le skill `/create-pr` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref/tree/main/.claude/skills) — il génère des PRs avec description structurée et diagramme Mermaid : + +```markdown + +--- +name: create-pr +description: Create Pull Requests with AI-generated descriptions and mermaid diagrams +allowed-tools: Bash(git:*), Bash(gh:*) +--- + +## Usage +/create-pr [base-branch] # Nouvelle PR (défaut: main) +/create-pr --update # Met à jour une PR existante + +## Workflow +1. Gather: git log, git diff --stat, git diff (en parallèle) +2. Detect: Type de changement (composition, infrastructure, security...) +3. Generate: Summary, diagramme Mermaid, table des fichiers +4. Create: git push + gh pr create +``` + +| Champ | Rôle | +|-------|------| +| `name` | Nom du skill et commande `/create-pr` | +| `description` | Aide Claude à décider quand charger automatiquement | +| `allowed-tools` | Outils autorisés sans confirmation (`git`, `gh`) | + +Cet exemple sur la création d'une pull request démontre comment nous pouvons cadrer le fonctionnement de l'agent pour atteindre un résultat qui nous convient — ici une PR structurée avec diagramme. Cela évite d'itérer sur les propositions de l'agent et permet de gagner en efficacité. + +### Tasks : ne jamais perdre le fil + +Les **Tasks** (v2.1.16+) résolvent un vrai problème des workflows autonomes : comment garder le fil sur une tâche complexe qui s'étale dans le temps ? + +Les Tasks remplacent l'ancien système de "Todos" et apportent trois améliorations clés : **persistance entre sessions**, **visibilité partagée entre agents**, et **tracking des dépendances**. + +Concrètement, quand Claude travaille sur une tâche longue, il peut : +- Décomposer le travail en Tasks avec dépendances +- Déléguer certaines Tasks en background +- Reprendre le travail après une interruption sans perte de contexte + +{{% notice tip "Commande /tasks" %}} +Utilisez `/tasks` pour voir l'état des tâches en cours. Pratique pour suivre où en est Claude sur un workflow complexe. +{{% /notice %}} + +--- + +## :rocket: Cas concrets pour le Platform Engineering/SRE + +Assez de théorie ! Passons à ce qui nous intéresse vraiment : comment Claude Code peut nous aider au quotidien. Je vais vous partager deux cas concrets et détaillés qui illustrent la puissance des MCPs et du workflow avec Claude. + +### :mag: Supervision complète de Karpenter avec les MCPs + +Ce cas illustre parfaitement la puissance de la **boucle agentique** présentée en introduction. Grâce aux MCPs, Claude dispose d'un contexte complet sur mon environnement (métriques, logs, documentation à jour, état du cluster) et peut **itérer de manière autonome** : créer des ressources, les déployer, valider visuellement le résultat, puis corriger si nécessaire. + +#### Le prompt + +La structuration du prompt est essentielle pour guider efficacement l'agent. Un prompt bien organisé — avec contexte, objectif, étapes et contraintes — permet à Claude de comprendre non seulement *quoi* faire, mais aussi *comment* le faire. Le [guide de prompt engineering d'Anthropic](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) détaille ces bonnes pratiques. + +Voici le prompt utilisé pour cette tâche : + +```markdown +## Contexte +Je gère un cluster Kubernetes avec Karpenter pour l'autoscaling. +MCPs disponibles : grafana, victoriametrics, victorialogs, context7, chrome. + +## Objectif +Créer un système d'observabilité complet pour Karpenter : alertes + dashboard unifié. + +## Étapes +1. **Documentation** : Via context7, consulte la doc récente de Grafana + (alerting, dashboards) et des datasources Victoria +2. **Alertes** : Crée des alertes pour : + - Erreurs de provisioning des nodes + - Échecs d'appels API AWS + - Dépassement de quotas +3. **Dashboard** : Crée un dashboard Grafana unifié intégrant : + - Métriques (temps de provisioning, coûts, capacity) + - Logs d'erreurs Karpenter + - Événements Kubernetes liés aux nodes +4. **Validation** : Déploie via kubectl, puis valide visuellement avec + les MCPs grafana et chrome +5. **Finalisation** : Si le rendu est correct, applique via l'opérateur + Grafana, commit et crée la PR + +## Contraintes +- Utilise les fonctionnalités récentes de Grafana (v11+) +- Suis les bonnes pratiques : variables de dashboard, annotations, + seuils d'alerte progressifs +``` + +#### Étape 1 : Planification et décomposition + +Claude analyse le prompt et génère automatiquement un **plan structuré** en sous-tâches. Cette décomposition permet de suivre la progression et garantit que chaque étape est complétée avant de passer à la suivante. + +{{< img src="karpenter_plan.png" alt="Plan généré par Claude Code" width="600" >}} + +On voit ici les 4 tâches identifiées : création des alertes VMRule, création du dashboard unifié, validation avec kubectl et Chrome, puis finalisation avec commit et PR. + +#### Étape 2 : Exploitation des MCPs pour le contexte + +C'est ici que nous constatons la **puissance des MCPs**. Claude en utilise **simultanément plusieurs** pour obtenir un contexte complet : + +{{< img src="karpenter_mcp.png" alt="Appels aux MCPs" width="1200" >}} + +- **context7** : Récupère la documentation Grafana v11+ pour les alerting rules et le format JSON des dashboards +- **victoriametrics** : Liste toutes les métriques `karpenter_*` disponibles dans mon cluster +- **victorialogs** : Analyse les logs de Karpenter pour identifier les événements de scaling, les erreurs de provisioning et les patterns de comportement + +Cette combinaison permet à Claude de générer du code **adapté à mon environnement réel** plutôt que des exemples génériques potentiellement obsolètes. + +#### Étape 3 : Validation visuelle avec Chrome MCP + +Une fois le dashboard déployé via `kubectl`, Claude utilise le **MCP Chrome** pour ouvrir Grafana et valider visuellement le rendu. Il peut ainsi vérifier que les panels s'affichent correctement, que les requêtes retournent des données, et ajuster si nécessaire. + +
+ +
+ +Il s'agit là d'un exemple concret de **boucle de rétroaction**: Claude **observe le résultat de ses actions** et peut itérer jusqu'à obtenir le résultat souhaité. + +#### Résultat : une observabilité complète + +À l'issue de ce workflow, Claude a créé une **PR complète** : 12 alertes VMRule (provisioning, API AWS, quotas, interruptions Spot) et un dashboard Grafana unifié combinant métriques, logs et événements Kubernetes. + +{{< img src="karpenter_summary.png" width="750" >}} + +Cette capacité à interagir avec ma plateforme, à identifier les erreurs et incohérences puis à apporter des ajustements automatiquement m'a vraiment **bluffé** 🤩. Plutôt que d'aller parser le JSON Grafana ou lister les métriques et logs via les différentes UIs VictoriaMetrics, je définis mon objectif et l'agent se charge de l'atteindre, tout en consultant la documentation à jour. Un **gain de productivité** non négligeable ! + +--- + +### :building_construction: La spec comme source de vérité — offrir un nouveau service + +J'ai pu aborder à plusieurs reprises dans mes précédents articles l'intérêt de Crossplane pour offrir le bon niveau d'abstraction aux utilisateurs de la plateforme. Ce deuxième cas met justement en pratique cette approche : créer une **composition Crossplane** avec l'aide de l'agent. C'est l'un des principes clés du **Platform Engineering** — proposer du self-service adapté au contexte, tout en gardant la maîtrise de l'infrastructure sous-jacente. + +{{% notice info "Qu'est-ce que le Spec-Driven Development (SDD) ?" %}} +Le **Spec-Driven Development** est un paradigme où les spécifications — et non le code — servent d'artefact principal. À l'ère de l'IA agentique, le SDD fournit les garde-fous nécessaires pour éviter le "Vibe Coding" (prompting non structuré) et garantir que les agents produisent du code maintenable. + +Pour ceux qui baignent dans Kubernetes, on peut faire un parallèle 😉 : la spec définit l'**état désiré**, et une fois validée par l'humain, l'agent IA se comporte un peu comme un *controller* — il itère en fonction des résultats (tests, validations) jusqu'à atteindre cet état. La différence : l'humain reste dans la boucle (**HITL**) pour valider la spec *avant* que l'agent ne se lance, et pour revoir le résultat final. + +**Les frameworks majeurs en 2026 :** + +| Framework | Force principale | Cas d'usage idéal | +|-----------|-----------------|-------------------| +| **[GitHub Spec Kit](https://github.com/github/spec-kit)** | Intégration native GitHub/Copilot | Projets greenfield, workflow structuré | +| **[BMAD](https://github.com/bmad-sim/bmad-method)** | Équipes multi-agents (PM, Architect, Dev) | Systèmes complexes multi-repos | +| **[OpenSpec](https://github.com/Fission-AI/OpenSpec)** | Léger, centré sur les changements | Projets brownfield, itération rapide | +{{% /notice %}} + +{{% notice tip "Ma variante SDD pour le Platform Engineering" %}} +Pour [cloud-native-ref](https://github.com/Smana/cloud-native-ref), j'ai créé une variante inspirée de GitHub Spec Kit que je fais évoluer progressivement. J'avoue que c'est assez expérimental pour le moment, mais les résultats sont déjà impressionnants. + +**🛡️ Platform Constitution** — Les principes non-négociables sont codifiés dans une [constitution](https://github.com/Smana/cloud-native-ref/blob/main/docs/specs/constitution.md) : préfixe `xplane-*` pour le scoping IAM, zero-trust networking obligatoire, secrets via External Secrets uniquement. Claude vérifie chaque spec et implémentation contre ces règles. + +**👥 4 personas de review** — Chaque spec passe par une checklist qui force à considérer plusieurs angles : + +| Persona | Focus | +|---------|-------| +| **PM** | Clarté du problème, user stories alignées aux besoins réels | +| **Platform Engineer** | Cohérence API, patterns KCL respectés | +| **Security** | Zero-trust, least privilege, secrets externalisés | +| **SRE** | Health probes, observabilité, modes de failure | + +**⚡ Skills Claude Code** — Le workflow est orchestré par des [skills](/fr/post/series/agentic_ai/ai-coding-agent/#skills--obtenir-de-nouveaux-pouvoirs) (voir section précédente) qui automatisent chaque étape : + +| Skill | Action | +|-------|--------| +| `/spec` | Crée l'issue GitHub + le fichier spec pré-rempli | +| `/clarify` | Résout les `[NEEDS CLARIFICATION]` avec options structurées | +| `/validate` | Vérifie la complétude avant implémentation | +| `/create-pr` | Crée la PR avec référence automatique à la spec | + +{{< img src="sdd_workflow.png" alt="Workflow SDD" width="700" >}} +{{% /notice %}} + +#### Pourquoi le SDD pour le Platform Engineering ? + +Créer une composition Crossplane n'est pas un simple script — c'est concevoir une **API pour nos utilisateurs**. Chaque décision a des implications durables : + +| Décision | Impact | +|----------|--------| +| Structure de l'API (XRD) | Contrat avec les équipes produit — difficile à changer après adoption | +| Ressources créées | Coûts cloud, surface de sécurité, dépendances opérationnelles | +| Valeurs par défaut | Ce que 80% des utilisateurs obtiendront sans y penser | +| Intégrations (IAM, Network, Secrets) | Conformité, isolation, auditabilité | + +Le SDD force à **réfléchir avant de coder** et à **documenter les décisions** — exactement ce dont on a besoin pour une API de plateforme. + +#### Notre objectif: proposer une composition Queue + +L'équipe produit a besoin d'un système de queuing pour leurs applications. Selon le contexte, ils veulent pouvoir choisir entre : +- **Kafka (via [Strimzi](https://strimzi.io/))** : pour les cas nécessitant du streaming, de la rétention longue, ou du replay +- **AWS SQS** : pour les cas simples, serverless, avec intégration native AWS + +Plutôt que de leur demander de configurer Strimzi ou SQS directement (dizaines de paramètres), on va leur exposer une **API simple et unifiée**. + +#### Étape 1 : Créer la spec avec `/spec` 📝 + +Le skill `/spec` est le point d'entrée du workflow. Il crée automatiquement : +- Une **GitHub Issue** avec le label `spec:draft` pour le suivi et les discussions +- Un **fichier de spec** dans `docs/specs/` pré-rempli avec le template du projet + +``` +/spec composition "Add queuing composition supporting Strimzi (Kafka) or SQS" +``` + +{{< img src="sdd_spec.png" width="950" >}} + +Claude analyse le contexte du projet (compositions existantes, constitution, ADRs) et pré-remplit la spec avec un **initial design**. Il identifie également les **points de clarification** — ici 3 questions clés sur le scope et l'authentification. + +L'issue GitHub sert de **point de référence centralisé** — c'est là que se déroulent les discussions et que l'on retrouve l'historique des décisions — tandis que le fichier spec, lui, évolue avec le design détaillé. + +#### Étape 2 : Clarifier les choix de design avec `/clarify` 🤔 + +La spec générée contient des marqueurs `[NEEDS CLARIFICATION]` pour les décisions que Claude ne peut pas prendre seul. Le skill `/clarify` les présente sous forme de **questions structurées avec options** : + +{{< img src="sdd_clarify_1.png" width="950" >}} + +Chaque question propose des options analysées selon **4 perspectives** (PM, Platform Engineer, Security, SRE) avec une recommandation. Il suffit de choisir en naviguant parmi les options proposées. + +Une fois toutes les clarifications résolues, Claude met à jour la spec avec un résumé des décisions : + +{{< img src="sdd_clarify_2.png" width="900" >}} + +Ces décisions sont **documentées dans la spec** — dans 6 mois, quand quelqu'un demandera "pourquoi pas de mTLS ?", la réponse sera là. + +#### Étape 3 : Valider et implémenter ⚙️ + +Avant de commencer l'implémentation, le skill `/validate` vérifie la complétude de la spec : +- Toutes les sections requises sont présentes +- Tous les marqueurs `[NEEDS CLARIFICATION]` sont résolus +- L'issue GitHub est liée +- La constitution du projet est référencée + +Une fois validée, je peux lancer l’implémentation. Claude entre en **plan mode** et lance des agents d'exploration **en parallèle** pour comprendre les patterns existants : + +{{< img src="sdd_implement_1.png" width="1100" >}} + +Claude explore les compositions existantes (`SQLInstance`, `EKS Pod Identity`, la configuration Strimzi) pour comprendre les conventions du projet **avant d'écrire une seule ligne de code**. + +L'implémentation génère les ressources appropriées selon le backend choisi : + +{{< img src="sdd_implement_summary.png" width="450" >}} + +Pour **chaque backend**, la composition crée les ressources nécessaires tout en respectant les conventions du projet : +- Préfixe `xplane-*` pour toutes les ressources (convention IAM) +- `CiliumNetworkPolicy` pour le zero-trust networking +- `ExternalSecret` pour les credentials (pas de secrets en dur) +- `VMServiceScrape` pour l'observabilité + +#### Étape 4 : Validation finale 🛂 + +Le skill `/validate` vérifie non seulement la spec mais aussi l'**implémentation** : + +{{< img src="sdd_validation.png" width="800" >}} + +La validation couvre : +- **Spec** : Sections présentes, clarifications résolues, issue liée +- **Implémentation** : Phases complétées, exemples créés, CI passing +- **Review checklist** : Les 4 personas (PM, Platform Engineer, Security, SRE) + +Les items "N/A" (tests E2E, documentation, failure modes) sont clairement identifiés comme optionnels pour ce type de composition. + +#### Résultat : l'API utilisateur finale 🎉 + +Le développeur peut maintenant déclarer son besoin en quelques lignes : + +```yaml +apiVersion: cloud.ogenki.io/v1alpha1 +kind: Queue +metadata: + name: orders-queue + namespace: ecommerce +spec: + # Kafka pour le streaming avec rétention + type: kafka + clusterRef: + name: main-kafka + config: + partitions: 6 + retentionDays: 7 +``` + +Ou pour SQS : + +```yaml +apiVersion: cloud.ogenki.io/v1alpha1 +kind: Queue +metadata: + name: notifications-queue + namespace: notifications +spec: + # SQS pour les cas simples + type: sqs + config: + visibilityTimeout: 30 + enableDLQ: true +``` + +Dans les deux cas, la plateforme gère automatiquement : +- La création des ressources (topics Kafka ou queues SQS) +- L'authentification (SASL/SCRAM ou IAM) +- Le monitoring (métriques exportées vers VictoriaMetrics) +- La sécurité réseau (CiliumNetworkPolicy) +- L'injection des credentials dans le namespace de l'application + +Sans le SDD, je me serais probablement lancé directement dans l'écriture de la composition Crossplane, sans prendre le recul nécessaire pour adopter une **véritable approche produit** ni **approfondir les spécifications**. Et malgré cela, la mise à disposition de ce nouveau service m'aurait pris bien plus de temps. + +En structurant la réflexion en amont, **chaque décision est documentée** et justifiée avant la première ligne de code. Les quatre perspectives (PM, Platform, Security, SRE) garantissent qu'aucun angle n'est oublié, et la PR finale référence la spec : le reviewer a tout le contexte nécessaire. + + +## :thought_balloon: Dernières remarques + +Nous avons pu explorer grâce à cet article l'IA agentique et comment ses principes peuvent être utiles au quotidien. Un agent ayant accès à un contexte enrichi (`CLAUDE.md`, skills, MCPs...) peut **vraiment** être très efficace : qualité au rendez-vous et surtout, une rapidité impressionnante ! Le workflow SDD permet également, pour les projets plus complexes, de formaliser son intention et de mieux cadrer l'agent. + +### Points de vigilance + +Cela dit, aussi impressionnants soient les résultats, il est important de garder un **regard lucide**. Voici quelques leçons que j'en tire après plusieurs mois d'utilisation : + +* **Éviter la dépendance et continuer à apprendre** — reviewer systématiquement les specs et le code généré, comprendre *pourquoi* cette solution +* **Se forcer à travailler sans IA** — je m'impose un rythme d'au moins 2 sessions par semaine "à l'ancienne" +* **Utiliser l'IA comme professeur** — lui demander d'expliquer son raisonnement et ses choix, c'est un excellent moyen d'apprendre + +{{% notice warning "Confidentialité et code propriétaire" %}} +Si vous travaillez sur du code sensible ou propriétaire : +- Utilisez le plan **Team** ou **Enterprise** — vos données ne servent pas à l'entraînement +- Demandez l'option **Zero-Data-Retention** (ZDR) si nécessaire +- N'utilisez **jamais** le plan Free/Pro pour du code confidentiel + +Consultez la [documentation sur la confidentialité](https://www.anthropic.com/policies/privacy) pour plus de détails. +{{% /notice %}} + +### :bulb: Optimiser son utilisation + +{{% notice info "Article dédié" %}} +Les tips d'optimisation (CLAUDE.md, hooks, gestion du contexte, worktrees, plugins...) ont été regroupés dans un article dédié : [Claude Code : Optimisation et bonnes pratiques](/fr/post/series/agentic_ai/ai-coding-tips/). +{{% /notice %}} + +### Mes prochaines étapes + +C'est une préoccupation que je partage avec beaucoup de développeurs : **que se passe-t-il si Anthropic change les règles du jeu ?** Cette crainte s'est d'ailleurs matérialisée début janvier 2026, lorsqu'Anthropic a [bloqué sans préavis](https://venturebeat.com/technology/anthropic-cracks-down-on-unauthorized-claude-usage-by-third-party-harnesses) l'accès à Claude via des outils tiers comme [OpenCode](https://github.com/opencode-ai/opencode). + +De par ma sensibilité pour l'open source, j'envisage d'explorer les alternatives ouvertes: **[Mistral Vibe](https://mistral.ai/news/devstral-2-vibe-cli)** avec Devstral 2 (72.2% SWE-bench) et **[OpenCode](https://opencode.ai/)** (multi-provider, modèles locaux via Ollama) par exemple. + +--- + +## :bookmark: Références + +### Guides et best practices +- [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) — Anthropic Engineering +- [How I Use Every Claude Code Feature](https://blog.sshh.io/p/how-i-use-every-claude-code-feature) — Guide complet par sshh + +### Spec-Driven Development +- [GitHub Spec Kit](https://github.com/github/spec-kit) — Toolkit SDD de GitHub +- [OpenSpec](https://github.com/Fission-AI/OpenSpec) — SDD léger pour projets brownfield +- [BMAD Method](https://github.com/bmad-sim/bmad-method) — Multi-agent SDD + +### Plugins, Skills et MCPs +- [Code-Simplifier](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier) — Nettoyage de code IA +- [Claude-Mem](https://github.com/thedotmack/claude-mem) — Mémoire persistante entre sessions +- [CC-DevOps-Skills](https://github.com/akin-ozer/cc-devops-skills) — 31 skills DevOps prêts à l'emploi +- [Awesome Claude Code Plugins](https://github.com/ccplugins/awesome-claude-code-plugins) — Liste curatée + +### Études citées +- [METR Study on AI Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — Étude sur la productivité +- [State of AI Code Quality 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/) — Qodo +- [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — Anthropic Research + +### Ressources +- [Cloud Native Ref](https://github.com/Smana/cloud-native-ref) — Mon repo de référence +- [SWE-bench Leaderboards](https://www.swebench.com/) — Benchmark de référence diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/index.md.backup-v1 b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md.backup-v1 new file mode 100644 index 00000000..4fd7e425 --- /dev/null +++ b/content/fr/post/series/agentic_ai/ai-coding-agent/index.md.backup-v1 @@ -0,0 +1,1927 @@ ++++ +author = "Smaine Kahlouch" +title = "Claude Code : Quand l'IA devient le copilote du Platform Engineer" +date = "2026-01-08" +summary = "Utilisation pratique d'un **coding agent** dans le quotidien du platform engineering. Au-delà du hype, des cas concrets qui démontrent comment cette nouvelle façon de travailler peut réellement **booster notre productivité**. Concepts, configuration, et retours d'expérience." +featured = true +codeMaxLines = 30 +usePageBundles = true +toc = true +tags = [ + "ai", + "devxp", + "tooling" +] +thumbnail = "thumbnail.png" ++++ + +{{% notice info "L'IA dans notre quotidien" %}} +Impossible d'y échapper : l'IA transforme nos métiers. Fin 2025, **65% des développeurs** utilisent des outils d'IA au moins une fois par semaine selon [Stack Overflow](https://stackoverflow.com/). Mais au-delà des annonces sensationnelles, qu'en est-il **concrètement** pour nous, platform engineers ? + +Dans cet article, je partage mon expérience avec Claude Code et vous montre, par des exemples réels, comment cet outil est devenu un allié précieux dans mes tâches quotidiennes. +{{% /notice %}} + +Nous le voyons bien, nous assistons à un réel bouleversement provoqué par l'utilisation de l'IA. Ce domaine évolue à une vitesse vertigineuse et, honnêtement, il est difficile de mesurer aujourd'hui l'impact sur tous les aspects de notre métier. Une chose est sûre cependant : dans la tech, c'est une **révolution** ! + +Je ne vais pas vous faire un énième tutoriel ChatGPT. Ici, je vais vous présenter une utilisation **pratique** dans le métier du platform engineering avec une exploration de l'utilisation d'un **coding agent** — pas un simple chatbot — dans certaines tâches communes de notre quotidien. + +Mais surtout, je vais tenter de vous démontrer par des cas concrets que cette nouvelle façon de travailler augmente **réellement** notre productivité. Si si ! + +## :dart: Objectifs de cet article + +* Comprendre ce qu'est un **coding agent** et pourquoi c'est différent d'un simple chatbot +* Découvrir les concepts clés : tokens, contexte, MCPs, subagents, agents personnalisés +* Installer et configurer Claude Code efficacement +* **Cas concrets** d'utilisation dans le platform engineering +* Maîtriser les coûts et optimiser son utilisation +* Réflexions sur les limites et les pièges à éviter + +{{% notice tip "Le repo de référence" %}} + + + + + +
+Les exemples qui suivent sont issus de mon travail sur le repository Cloud Native Ref. Il s'agit d'une plateforme complète combinant EKS, Cilium, VictoriaMetrics, Crossplane, Flux et bien d'autres outils. +
+{{% /notice %}} + +--- + +## :brain: Comprendre les coding agents + +### Qu'est-ce qui différencie un agent d'un chatbot ? + +Vous utilisez probablement déjà ChatGPT ou Gemini pour poser des questions. C'est pratique, mais ça reste du **one-shot** : vous posez une question, vous obtenez une réponse, point final. + +Un **coding agent** fonctionne différemment. Il opère en boucle selon le pattern **ReAct** (Reasoning + Action) : + +
Boucle ReAct
+ +1. **Raisonnement** : L'agent analyse votre demande et planifie les étapes +2. **Action** : Il exécute une action (lire un fichier, exécuter une commande, chercher dans le code) +3. **Observation** : Il analyse le résultat de son action +4. **Itération** : Il décide si c'est suffisant ou s'il faut continuer + +{{% notice info "La définition selon Simon Willison" %}} +[Simon Willison](https://simonwillison.net/2025/Sep/30/designing-agentic-loops/), expert reconnu du domaine, définit un agent LLM comme : *"quelque chose qui exécute des outils en boucle pour atteindre un objectif"*. C'est simple, mais ça capture l'essentiel. +{{% /notice %}} + +Concrètement, si vous demandez à un chatbot classique *"Corrige le bug dans mon auth"*, il vous donnera des suggestions génériques. Un agent, lui, va : + +1. Chercher les fichiers liés à l'authentification +2. Lire le code concerné +3. Identifier le problème +4. Proposer une correction +5. L'appliquer si vous validez +6. Vérifier que ça compile/fonctionne + +C'est cette capacité à **agir** sur votre environnement qui fait toute la différence. + +### L'anatomie d'un agent + +On peut résumer un agent avec cette formule : + +``` +Agent = LLM + Tools + Memory + Planning +``` + +| Composant | Rôle | Exemple dans Claude Code | +|-----------|------|--------------------------| +| **LLM** | Le "cerveau" qui raisonne | Claude Opus 4.5 / Sonnet 4 | +| **Tools** | Les actions possibles | Read, Write, Bash, Grep, WebFetch | +| **Memory** | Le contexte conservé | CLAUDE.md, conversation history | +| **Planning** | La stratégie d'exécution | Décomposition en sous-tâches | + +### Le choix du modèle : une course effrénée + +Les nouvelles versions de modèles apparaissent à une vitesse folle. Impossible de suivre ! L'efficacité (qualité de code, hallucinations, context mis à jour) peut radicalement différer selon les modèles. + +Le benchmark [**SWE-bench Verified**](https://www.swebench.com/) est devenu la référence pour évaluer les capacités des modèles en développement logiciel. Il mesure la capacité à résoudre de vrais bugs issus de repositories GitHub. + +
Leaderboard SWE-bench Verified
+ +{{% notice warning "Ces chiffres évoluent très vite !" %}} +Consultez [swebench.com](https://www.swebench.com/) pour les derniers résultats. Au moment de la rédaction, les modèles frontier (Claude Opus 4.5, GPT-5.x, Gemini 3) se disputent la première place avec des scores autour de **75-80%**. +{{% /notice %}} + +**Points clés à retenir sur SWE-bench :** + +| Aspect | Impact | +|--------|--------| +| **Scaffold/Agent** | Les scores varient selon l'agent utilisé avec le modèle | +| **SWE-bench Pro** | Benchmark plus difficile (~20-25% pour les meilleurs) | +| **Parité au sommet** | Le choix dépend aussi du coût, de la latence et du context window | + +La compétition est si féroce que la première place change régulièrement. En pratique, tous les modèles frontier sont suffisamment performants pour la plupart des tâches de platform engineering. + +### Pourquoi Claude Code ? + +Il existe de nombreuses options de coding agents : [Cursor](https://cursor.sh/), [Windsurf](https://codeium.com/windsurf), [GitHub Copilot](https://github.com/features/copilot), [Gemini CLI](https://github.com/google-gemini/gemini-cli)... Je ne suis clairement pas capable de toutes les évaluer en profondeur. + +J'ai utilisé Cursor dans un premier temps, puis je suis passé à Claude Code. La raison ? Mon **background de sysadmin** plutôt porté sur le terminal. Là où d'autres préfèrent travailler exclusivement dans leur IDE, je me sens plus à l'aise avec une CLI. + +Selon [Artificial Analysis](https://artificialanalysis.ai/insights/coding-agents-comparison), voici comment se positionnent les outils : + +| Outil | Type | Forces | Idéal pour | +|-------|------|--------|------------| +| **Claude Code** | Terminal | Context 200K, score SWE-bench le plus élevé | Refactoring large, DevOps, automation | +| **Cursor** | IDE | Workflow visuel, Composer mode | Développement applicatif, UI | +| **GitHub Copilot** | IDE Plugin | Intégration native, entreprise-ready | Équipes Microsoft/GitHub | +| **Windsurf** | IDE | Cascade mode, UX soignée | Prototypage rapide | + +{{% notice tip "Mon conseil" %}} +Beaucoup de développeurs utilisent **plusieurs outils** : Cursor pour écrire du code applicatif, Claude Code pour le refactoring et l'infrastructure. Ce n'est pas exclusif ! +{{% /notice %}} + +--- + +## :books: Les concepts essentiels + +Avant de plonger dans l'utilisation concrète, il est important de comprendre quelques concepts clés. Pas de panique, je vais rester pragmatique ! + +### Tokens et fenêtre de contexte + +#### Qu'est-ce qu'un token ? + +Un **token** est l'unité de base que le modèle traite. Ce n'est pas exactement un mot — c'est plutôt un "morceau" de texte. En règle générale : + +- 1 token ≈ 4 caractères en anglais +- 1 token ≈ 2-3 caractères en français (les accents comptent !) +- 100 tokens ≈ 75 mots + +Pourquoi c'est important ? Parce que **tout se paye en tokens** : ce que vous envoyez (input), ce que Claude génère (output), et le contexte qu'il maintient. + +#### La fenêtre de contexte + +La **fenêtre de contexte** (context window) représente la quantité maximale de tokens que le modèle peut "voir" à un instant donné. Pensez-y comme sa **mémoire de travail**. + +| Modèle | Context Window | Équivalent | +|--------|----------------|------------| +| Claude Opus 4.5 | 200K tokens | ~150K mots / ~300 pages | +| Claude Sonnet 4.5 | 200K tokens | ~150K mots / ~300 pages | +| Claude Sonnet 4.5 (beta) | 1M tokens | ~750K mots / ~1500 pages | +| GPT-4o | 128K tokens | ~96K mots / ~200 pages | + +{{% notice note "Attention à la saturation !" %}} +Lorsque le contexte approche de sa limite, les performances se dégradent. Les recherches montrent qu'il vaut mieux **privilégier la qualité du contexte à la quantité**. C'est pour cela que Claude Code dispose d'un mécanisme d'**auto-compaction** qui résume automatiquement les conversations trop longues. +{{% /notice %}} + +#### Visualiser son contexte + +Claude Code fournit une commande très utile pour comprendre ce qui consomme votre contexte : + +```console +/context +``` + +
Visualisation du contexte
+ +Cette vue montre : +- Tokens utilisés par le système et les outils +- Tokens des fichiers CLAUDE.md (mémoire) +- Tokens de la conversation +- Espace libre disponible + +### Les MCPs : connecter Claude au monde extérieur + +#### En quelques mots + +Le **Model Context Protocol** (MCP) est un standard ouvert créé par Anthropic qui permet aux agents IA de se connecter à des sources de données et outils externes. Pensez-y comme une **prise USB-C pour l'IA** : un connecteur universel. + +{{% notice info "Un standard qui s'impose" %}} +En décembre 2025, Anthropic a [donné MCP à la Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) via l'Agentic AI Foundation. OpenAI, Google, Microsoft et AWS l'ont adopté. Avec **97 millions** de téléchargements mensuels et plus de **5,800 serveurs** disponibles, c'est devenu LE standard de facto. +{{% /notice %}} + +#### Architecture MCP + +``` +┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ +│ Claude Code │────▶│ MCP Client │────▶│ MCP Server │ +│ (l'agent) │ │ (intégré) │ │ (externe) │ +└─────────────────┘ └─────────────────┘ └─────────────────┘ + │ + ▼ + ┌─────────────────┐ + │ GitHub, K8s, │ + │ Prometheus... │ + └─────────────────┘ +``` + +#### Mes MCPs indispensables pour le platform engineering + +Voici les MCPs que j'utilise au quotidien et qui constituent mon toolkit essentiel : + +| MCP | Catégorie | Usage | Intérêt pour PE | +|-----|-----------|-------|-----------------| +| **[context7](https://github.com/upstash/context7)** | Documentation | Doc à jour des libs | Évite les hallucinations d'API | +| **[flux](https://fluxcd.control-plane.io/mcp/)** | GitOps | Debug Flux, reconciliation | Troubleshooting pipelines | +| **[victoriametrics](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics)** | Métriques | Requêtes PromQL | Analyse cardinalité, alertes | +| **[victorialogs](https://github.com/VictoriaMetrics-Community/mcp-victorialogs)** | Logs | LogsQL | Root cause analysis | +| **[grafana](https://github.com/grafana/mcp-grafana)** | Visualisation | Dashboards, alertes | Création/modification dashboards | +| **[steampipe](https://github.com/turbot/steampipe-mcp)** | Cloud SQL | Requêtes infrastructure | Audit multi-cloud | + +--- + +{{% notice tip "Configuration globale ou locale?" %}} + +Il est possible de configurer les MCPs de manière globale ou locale. Par exemple, j'utilise quasi systématiquement `context7`, j'ai donc décidé de l'ajouter au fichier global `~/.claude/mcp.json`, ce qui m'évite de le définir pour chacun de mes projets. +Les autres MCPs sont définis au niveau du repo. + +❯ /mcp + +──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── + Manage MCP servers + 5 servers + + Project MCPs (/home/smana/Sources/cloud-native-ref/.mcp.json) + ❯ flux-operator-mcp · ✔ connected + victorialogs · ✔ connected + victoriametrics · ✔ connected + + User MCPs (/home/smana/.claude.json) + context7 · ✔ connected + + Built-in MCPs (always available) + claude-in-chrome · ✔ connected + +{{% /notice %}} + +#### Context7 : la documentation à jour + +[Context7](https://github.com/upstash/context7) (Upstash) résout un problème majeur : les **hallucinations d'API**. Quand Claude génère du code, il peut inventer des fonctions ou utiliser des syntaxes deprecated. + +Context7 injecte la documentation **versionnée** directement dans le contexte de Claude. Plus besoin de copier-coller la doc ! + +```console +# Installation +claude mcp add context7 -- npx -y @upstash/context7-mcp + +# Ou avec une API key pour des rate limits plus élevés +claude mcp add context7 -- npx -y @upstash/context7-mcp --api-key YOUR_API_KEY +``` + +**Utilisation** : Ajoutez simplement "use context7" dans votre prompt : + +``` +> use context7 pour la doc Cilium 1.16 +> Comment configurer une CiliumNetworkPolicy pour autoriser le traffic cross-namespace ? +``` + +--- + +#### Flux GitOps : debug des pipelines + +Le [Flux MCP Server](https://fluxcd.control-plane.io/mcp/) (ControlPlane) connecte Claude directement à vos clusters Kubernetes via Flux Operator. + +**Capacités :** +- Debug end-to-end des pipelines GitOps +- Root cause analysis des déploiements échoués +- Visualisation des dépendances (génère des diagrammes) +- Trigger reconciliations, suspend/resume + +```console +# Installation +claude mcp add-json "flux-operator" '{"command":"npx","args":["-y","@controlplane/flux-mcp-server"]}' +``` + +**Exemple concret** : + +``` +> Mes Kustomizations sont bloquées. Analyse les dépendances +> et identifie pourquoi infrastructure reste en "Not Ready" +``` + +Claude va interroger le cluster, tracer les dépendances, et identifier les blocages (dépendances circulaires, secrets manquants, etc.). + +--- + +#### VictoriaMetrics : analyse des métriques + +Le [MCP VictoriaMetrics](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics) donne à Claude un accès **read-only** à toutes les APIs VM : +- Requêtes PromQL +- Exploration de métriques, labels, séries +- Analyse de cardinalité +- Test des alerting rules + +```console +# Installation (nécessite Go 1.24+) +go install github.com/VictoriaMetrics-Community/mcp-victoriametrics/cmd/mcp-victoriametrics@latest + +# Configuration +claude mcp add-json "victoriametrics" '{ + "command": "/path/to/mcp-victoriametrics", + "env": { + "VM_INSTANCE_ENTRYPOINT": "https://vmselect.monitoring.svc:8481", + "VM_INSTANCE_TYPE": "cluster" + } +}' +``` + +**Variables d'environnement :** +- `VM_INSTANCE_ENTRYPOINT` : URL de votre instance VM +- `VM_INSTANCE_TYPE` : `single` ou `cluster` +- `VM_INSTANCE_BEARER_TOKEN` : Token d'authentification (optionnel) + +--- + +#### VictoriaLogs : analyse des logs + +Le [MCP VictoriaLogs](https://github.com/VictoriaMetrics-Community/mcp-victorialogs) permet à Claude d'interroger vos logs avec **LogsQL** pour le troubleshooting et la root cause analysis. + +```console +# Installation via Smithery +npx -y @smithery/cli install @VictoriaMetrics-Community/mcp-victorialogs --client claude + +# Ou manuellement +claude mcp add-json "victorialogs" '{ + "command": "/path/to/mcp-victorialogs", + "env": { + "VL_INSTANCE_ENTRYPOINT": "https://victorialogs.monitoring.svc:9428" + } +}' +``` + +**Combiné avec VictoriaMetrics**, vous pouvez demander : + +``` +> Une alerte CPU élevée est déclenchée sur le namespace demo. +> Analyse les métriques des dernières 30 minutes puis corrèle avec les logs +> pour identifier la root cause. +``` + +--- + +#### Grafana : dashboards et alertes + +Le [MCP Grafana](https://github.com/grafana/mcp-grafana) permet à Claude de rechercher, lire et **créer** des dashboards. + +**Capacités :** +- Recherche de dashboards par titre ou metadata +- Récupération des détails d'un dashboard +- Gestion des alertes et incidents +- Accès aux datasources + +```console +# Installation +claude mcp add-json "grafana" '{ + "command": "npx", + "args": ["-y", "@grafana/mcp-server"], + "env": { + "GRAFANA_URL": "https://grafana.example.com", + "GRAFANA_API_KEY": "${GRAFANA_API_KEY}" + } +}' +``` + +{{% notice info "Grafana 9.0+ requis" %}} +Certaines fonctionnalités nécessitent Grafana 9.0 ou supérieur pour un accès complet aux APIs. +{{% /notice %}} + +--- + +#### Steampipe : requêtes SQL sur le cloud + +powerpipe mod install github.com/turbot/steampipe-mod-aws-insights github.com/turbot/steampipe-mod-aws-compliance github.com/turbot/steampipe-mod-aws-top-10 github.com/turbot/steampipe-mod-kubernetes-compliance github.com/turbot/steampipe-mod-kubernetes-insights + +[Steampipe MCP](https://github.com/turbot/steampipe-mcp) (Turbot) permet à Claude d'interroger **100+ services cloud** avec du SQL : +- AWS, Azure, GCP +- Kubernetes, GitHub, Microsoft 365 +- Plus de 2000 tables documentées + +```console +# Installation (nécessite Steampipe local) +steampipe service start +claude mcp add steampipe -- npx -y @turbot/steampipe-mcp + +# Ou avec Turbot Pipes (cloud) +claude mcp add steampipe -- npx -y @turbot/steampipe-mcp \ + "postgresql://user:pass@workspace.usea1.db.pipes.turbot.com:9193/db" +``` + +**Exemple :** + +``` +> Liste toutes les instances EC2 sans tags Environment +> dans les régions eu-west-* +``` + +Claude génère et exécute : + +```sql +SELECT instance_id, region, tags +FROM aws_ec2_instance +WHERE region LIKE 'eu-west-%' + AND tags->>'Environment' IS NULL; +``` + +--- + +#### Configuration complète : exemple de mcp.json + +Voici un exemple complet de configuration pour un environment de platform engineering. Ce fichier peut être placé dans `.claude/mcp.json` à la racine de votre projet : + +```json +{ + "mcpServers": { + "context7": { + "command": "npx", + "args": ["-y", "@upstash/context7-mcp"], + "env": { + "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}" + } + }, + "flux-operator": { + "command": "npx", + "args": ["-y", "@controlplane/flux-mcp-server"], + "env": { + "KUBECONFIG": "${HOME}/.kube/config" + } + }, + "victoriametrics": { + "command": "${HOME}/go/bin/mcp-victoriametrics", + "env": { + "VM_INSTANCE_ENTRYPOINT": "https://vmselect.monitoring.svc:8481", + "VM_INSTANCE_TYPE": "cluster", + "VM_INSTANCE_BEARER_TOKEN": "${VM_BEARER_TOKEN}" + } + }, + "victorialogs": { + "command": "${HOME}/go/bin/mcp-victorialogs", + "env": { + "VL_INSTANCE_ENTRYPOINT": "https://victorialogs.monitoring.svc:9428" + } + }, + "grafana": { + "command": "npx", + "args": ["-y", "@grafana/mcp-server"], + "env": { + "GRAFANA_URL": "https://grafana.example.com", + "GRAFANA_API_KEY": "${GRAFANA_API_KEY}" + } + }, + "steampipe": { + "command": "npx", + "args": ["-y", "@turbot/steampipe-mcp"] + } + } +} +``` + +**Scopes de configuration :** + +| Scope | Emplacement | Usage | +|-------|-------------|-------| +| **local** | `.claude/mcp.json` | Uniquement pour vous, ce projet | +| **project** | Committé dans le repo | Partagé avec l'équipe | +| **user** | `~/.claude/mcp.json` | Tous vos projets | + +**Commandes utiles :** + +```console +# Vérifier les MCPs configurés +claude mcp list + +# Vérifier le statut dans une session +/mcp + +# Voir les détails d'un MCP +claude mcp get victoriametrics +``` + +{{% notice tip "Mon conseil sur Kubernetes" %}} +Pour Kubernetes, j'utilise directement `kubectl` via les commandes bash plutôt qu'un MCP dédié. La CLI consomme **moins de tokens** et Claude la maîtrise parfaitement. Les MCPs Kubernetes existants sont utiles pour des cas avancés, mais `kubectl` suffit dans 90% des cas. +{{% /notice %}} + +:warning: **Attention** : Chaque MCP ajouté consomme des tokens pour ses définitions d'outils. Utilisez `/context` pour identifier la consommation et désactivez les MCPs non nécessaires pour la tâche en cours avec `--disable-mcp`. + +### Les subagents : déléguer intelligemment + +#### Qu'est-ce qu'un subagent ? + +Un **subagent** est une instance Claude séparée, lancée par l'agent principal pour effectuer une tâche spécifique. C'est comme déléguer à un "stagiaire spécialisé". + +**Pourquoi c'est puissant :** + +| Avantage | Explication | +|----------|-------------| +| **Contexte isolé** | Le subagent a sa propre mémoire, il ne pollue pas la conversation principale | +| **Spécialisation** | Vous pouvez lui donner un "persona" (expert sécurité, expert Terraform...) | +| **Parallélisme** | Jusqu'à 10 subagents peuvent tourner simultanément | + +#### Cas d'usage concret + +``` +> J'ai 50 fichiers Terraform à auditer pour des problèmes de sécurité. +> Utilise des subagents pour analyser chaque module en parallèle +> et donne-moi un rapport consolidé. +``` + +Claude va alors : +1. Identifier les modules à analyser +2. Lancer un subagent par module (en parallèle) +3. Collecter les résultats +4. Synthétiser dans un rapport + +{{% notice warning "Limitations des subagents" %}} +- Les subagents **ne peuvent pas spawner d'autres subagents** (pas de récursion infinie) +- Pas de mode "thinking" interactif dans les subagents +- Maximum **10 agents en parallèle** (les suivants sont mis en queue) +{{% /notice %}} + +#### Déclencher manuellement un subagent + +Vous pouvez explicitement demander l'utilisation d'un subagent : + +``` +> Utilise un subagent pour parcourir tous les fichiers dans /src/components +> et vérifier s'ils utilisent les derniers design tokens. +> Donne-moi juste un résumé de ceux qui doivent être corrigés. +``` + +### Agents personnalisés : créer vos propres spécialistes + +#### Au-delà des subagents intégrés + +Les subagents décrits précédemment sont gérés automatiquement par Claude Code. Mais vous pouvez aller plus loin en créant vos **propres agents spécialisés** — des processus autonomes avec leur propre persona, leurs propres instructions, et leurs propres critères d'activation. + +Un agent personnalisé est un fichier Markdown (ou JSON) placé dans `.claude/agents/` qui définit : + +| Élément | Rôle | +|---------|------| +| **Identifiant** | Nom unique de l'agent | +| **Description** | Conditions de déclenchement (quand l'utiliser) | +| **System Prompt** | Persona, méthodologie, format de sortie | +| **Modèle** | Optionnel : sonnet, opus, haiku | + +#### Quand créer un agent plutôt qu'une commande ou un skill ? + +La confusion est fréquente entre ces trois mécanismes d'extension. Voici comment trancher : + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Que dois-je créer ? │ +└─────────────────────────────────────────────────────────────┘ + │ + ┌──────────────────┼──────────────────┐ + ▼ ▼ ▼ + Action manuelle? Connaissances? Tâche autonome + (ex: /deploy) (ex: best complexe? + │ practices) │ + ▼ ▼ ▼ + COMMANDE SKILL AGENT +``` + +| Critère | Commande | Skill | Agent | +|---------|----------|-------|-------| +| **Déclenchement** | Explicite (`/xxx`) | Automatique (contexte) | Automatique ou via Task | +| **Exécution** | Contexte principal | Injection de connaissances | **Subprocess autonome** | +| **Durée typique** | Ponctuel | Enrichissement continu | Multi-étapes, long | +| **Complexité** | Tâches simples | Expertise domaine | Workflows complexes | +| **Contrôle** | Total (vous décidez) | Délégué à Claude | Autonomie maximale | + +**En résumé :** +- **Commande** → Raccourci pour une action que vous invoquez explicitement +- **Skill** → Base de connaissances que Claude charge automatiquement quand c'est pertinent +- **Agent** → Processus autonome capable d'explorer, décider et agir sur plusieurs étapes + +#### Exemple : Agent de review sécurité Kubernetes + +Voici un agent spécialisé pour auditer les manifests Kubernetes : + +```markdown + +--- +name: k8s-security-reviewer +description: | + Use this agent when the user asks to "review Kubernetes manifests for security", + "audit K8s security", "check RBAC permissions", or when reviewing pull requests + containing Kubernetes YAML files. +model: sonnet +--- + +## Rôle + +Expert en sécurité Kubernetes qui audite les manifests selon les bonnes pratiques. + +## Processus + +1. **Scan des manifests** : Trouver tous les fichiers YAML K8s +2. **Analyse de sécurité** : + - SecurityContext (runAsNonRoot, readOnlyRootFilesystem, capabilities) + - NetworkPolicies présentes ? + - Secrets en clair vs External Secrets + - RBAC : principe du moindre privilège + - PodSecurityStandards/PSP +3. **Scoring** : Attribuer un score de sécurité +4. **Remédiation** : Proposer des correctifs concrets + +## Output + +Rapport structuré avec : +- Score global +- Findings critiques/majeurs/mineurs +- Code de remédiation prêt à commit +``` + +Claude activera automatiquement cet agent quand vous mentionnerez un audit de sécurité K8s, ou vous pouvez le déclencher explicitement. + +#### Exemple : Agent de troubleshooting Flux + +```markdown + +--- +name: flux-troubleshooter +description: | + Use this agent when the user mentions "Flux not syncing", "HelmRelease stuck", + "Kustomization failed", "flux reconcile error", or asks to "debug GitOps issues". + This agent should be used PROACTIVELY when Flux errors appear in logs. +model: sonnet +--- + +## Rôle + +Expert FluxCD qui diagnostique et résout les problèmes de réconciliation. + +## Processus autonome + +1. **État global** : `flux get all -A` pour vue d'ensemble +2. **Identifier les ressources en échec** : statut != Ready +3. **Pour chaque échec** : + - Récupérer les events : `kubectl describe` + - Logs du controller concerné + - Vérifier les dépendances (sources, secrets) +4. **Diagnostic** : Identifier la root cause +5. **Résolution** : Proposer la commande ou le fix +``` + +{{% notice tip "Déclenchement proactif" %}} +Notez la mention "PROACTIVELY" dans la description. Cela indique à Claude qu'il doit activer cet agent de lui-même quand il détecte des erreurs Flux, sans attendre que vous le demandiez explicitement. +{{% /notice %}} + +#### La puissance des agents : autonomie et parallélisme + +Ce qui distingue vraiment les agents des commandes : + +1. **Autonomie** : L'agent peut prendre des décisions intermédiaires sans vous consulter +2. **Contexte isolé** : Il a sa propre mémoire, ne pollue pas la conversation principale +3. **Parallélisme** : Jusqu'à 10 agents peuvent tourner simultanément via le Task tool +4. **Background** : Ils peuvent tourner en arrière-plan pendant que vous continuez à travailler + +``` +> Audite la sécurité de tous les modules Terraform en parallèle +> et génère un rapport consolidé +``` + +Claude va lancer un agent par module, collecter les résultats, et vous présenter une synthèse. + +--- + +## :hammer_and_wrench: Mise en place et configuration + +### Installation + +L'installation de Claude Code est simple. Vous avez besoin de Node.js 18+ : + +```console +# Installation globale via npm +npm install -g @anthropic-ai/claude-code + +# Vérifier l'installation +claude --version +``` + +Ensuite, configurez votre clé API : + +```console +# Via variable d'environnement +export ANTHROPIC_API_KEY="sk-ant-..." + +# Ou lors du premier lancement +claude +# Claude vous demandera votre clé +``` + +{{% notice tip "Avec asdf" %}} +Si vous utilisez [asdf](https://blog.ogenki.io/post/asdf/asdf/) comme moi : +```console +asdf plugin add claude-code +asdf install claude-code latest +asdf global claude-code latest +``` +{{% /notice %}} + +### Premiers pas + +```console +# Lancer une session interactive +claude + +# Mode one-shot (une seule commande) +claude -p "Liste les fichiers Terraform dans ce projet" + +# Reprendre la dernière session +claude --resume + +# Afficher l'aide +claude --help +``` + +Les actions de bases: +* modes de fonctionnement (permissions): plan, accept edit. Normal mode asking for editing +* multi modal, paste images +* thinking level +* Referencing files +* /resume +* /tasks +* keep feeding, no need to wait for the output for adding information + +### Le fichier CLAUDE.md : votre contexte personnalisé + +Le fichier `CLAUDE.md` est **crucial**. C'est un fichier de configuration spécial que Claude lit automatiquement au démarrage de chaque session. Il lui permet de comprendre votre projet et de fournir une assistance adaptée. + +#### Où le placer ? + +| Emplacement | Portée | Cas d'usage | +|-------------|--------|-------------| +| `~/.claude/CLAUDE.md` | Global (toutes les sessions) | Préférences personnelles | +| `./CLAUDE.md` | Projet (racine du repo) | Instructions spécifiques au projet | +| `./CLAUDE.local.md` | Local (gitignore) | Config personnelle non partagée | + +#### Que mettre dedans ? + +Selon les [best practices Anthropic](https://www.anthropic.com/engineering/claude-code-best-practices), gardez-le **concis et lisible** : + +```markdown +# CLAUDE.md + +## Projet +Cloud Native Ref - Plateforme Kubernetes de référence sur AWS + +## Stack technique +- Infrastructure: OpenTofu + Terramate +- Kubernetes: EKS avec Cilium (sans kube-proxy) +- GitOps: Flux v2 +- Observabilité: VictoriaMetrics, VictoriaLogs, Grafana +- Secrets: OpenBao (fork Vault) + +## Commandes courantes +# Déployer l'infrastructure +terramate run -- tofu apply + +# Vérifier Flux +flux get ks -A + +# Valider les compositions KCL +./scripts/validate-kcl-compositions.sh + +## Conventions +- Utiliser KCL pour les compositions Crossplane (pas YAML) +- Ne JAMAIS muter un dictionnaire après création en KCL +- Préfixer les branches: feat/, fix/, docs/ + +## Points d'attention +- Les secrets sensibles sont dans OpenBao, pas dans Git +- Toujours valider avec `terramate run -- tofu plan` avant apply +``` + +{{% notice info "Initialisation automatique" %}} +La commande `/init` analyse votre projet et génère un `CLAUDE.md` initial. C'est un excellent point de départ que vous pouvez ensuite personnaliser. +```console +claude +> /init +``` +{{% /notice %}} + +### Les commandes slash + +Claude Code dispose de commandes intégrées accessibles via `/` : + +| Commande | Description | +|----------|-------------| +| `/help` | Affiche l'aide | +| `/clear` | Efface la conversation (libère le contexte) | +| `/context` | Visualise l'utilisation du contexte | +| `/init` | Initialise CLAUDE.md pour le projet | +| `/permissions` | Gère les permissions des outils | +| `/config` | Accède à la configuration | +| `/doctor` | Diagnostique les problèmes | +| `/cost` | Affiche les coûts de la session | + +### Slash commands personnalisées + +Vous pouvez créer vos propres commandes slash pour des tâches récurrentes. Un fichier Markdown dans `.claude/commands/` devient une commande invocable. + +#### Créer une commande + +```markdown + +# Audit de sécurité Terraform + +Analyse tous les fichiers Terraform (*.tf) dans le répertoire courant et ses sous-répertoires. + +Pour chaque fichier : +1. Vérifie les ressources exposées publiquement +2. Identifie les secrets en dur +3. Vérifie les tags obligatoires (Environment, Owner, Project) +4. Signale les instances sans encryption + +Génère un rapport markdown avec : +- Résumé des problèmes par sévérité (Critical, High, Medium, Low) +- Détail par fichier +- Recommandations de correction +``` + +#### Utiliser la commande + +```console +claude +> /project:audit-terraform +``` + +{{% notice tip "Commandes utiles pour platform engineering" %}} +Quelques idées : +- `/project:flux-status` - Rapport détaillé de l'état Flux +- `/project:cost-review` - Analyse des ressources coûteuses +- `/project:security-scan` - Audit sécurité complet +- `/project:migration-check` - Vérification pré-migration +{{% /notice %}} + +--- + +### Skills : capacités auto-découvertes + +Les **Skills** sont différents des slash commands. Ce sont des capacités que Claude **découvre et utilise automatiquement** quand elles sont pertinentes, plutôt que d'être invoquées manuellement. + +#### Structure d'un Skill + +Un skill est un **dossier** (pas un simple fichier) dans `.claude/skills/` : + +``` +.claude/skills/k8s-troubleshooter/ +├── SKILL.md # Description pour Claude (obligatoire) +├── common-errors.md # Base de connaissances +├── runbooks/ # Procédures de diagnostic +│ ├── crashloop.md +│ └── network.md +└── scripts/ # Scripts de support + └── diagnostic.sh +``` + +#### Le fichier SKILL.md + +C'est la "carte d'identité" du skill. Claude le lit pour décider s'il doit l'activer : + +```markdown +# Kubernetes Troubleshooter + +## Description +Skill pour diagnostiquer les problèmes Kubernetes courants. +S'active automatiquement lors d'erreurs de pods, services ou déploiements. + +## Activation +Ce skill s'active quand : +- L'utilisateur mentionne des erreurs Kubernetes +- Des logs de pods sont analysés +- Des problèmes de réseau sont détectés + +## Capabilities +- Analyse des événements Kubernetes +- Diagnostic des CrashLoopBackOff +- Vérification des NetworkPolicies +- Recommandations basées sur les runbooks +``` + +#### Chargement lazy + +Contrairement aux slash commands (chargées immédiatement), les skills utilisent un **chargement lazy** : +1. Seule la description (`SKILL.md`) est lue au démarrage +2. Le contenu complet n'est chargé que si Claude décide d'activer le skill +3. Économie de tokens quand le skill n'est pas pertinent + +--- + +### Récapitulatif : Commands vs Skills vs Agents + +Claude Code propose trois mécanismes d'extension souvent confondus. Voici un récapitulatif complet (voir aussi la section [Agents personnalisés](#agents-personnalisés--créer-vos-propres-spécialistes) pour les détails) : + +| Aspect | Slash Commands | Skills | Agents | +|--------|----------------|--------|--------| +| **Invocation** | Manuelle (`/project:xxx`) | Automatique (contexte) | Automatique ou Task tool | +| **Emplacement** | `.claude/commands/` | `.claude/skills/` | `.claude/agents/` | +| **Structure** | Un fichier Markdown | Dossier avec `SKILL.md` | Fichier `.md` ou `.json` | +| **Exécution** | Contexte principal | Injection de connaissances | **Subprocess isolé** | +| **Chargement** | Immédiat | Lazy (description puis contenu) | À la demande | +| **Durée typique** | Ponctuel | Enrichissement continu | Multi-étapes, long | +| **Parallélisme** | Non | Non | Jusqu'à 10 simultanés | +| **Contrôle** | Total (vous décidez) | Délégué à Claude | Autonomie maximale | + +#### Quand utiliser quoi ? + +| Besoin | Solution | Exemple | +|--------|----------|---------| +| Raccourci pour tâche répétitive | **Slash Command** | `/project:flux-status` | +| Base de connaissances domaine | **Skill** | Bonnes pratiques Cilium | +| Tâche autonome multi-étapes | **Agent** | Audit sécurité complet | +| Accès à une API externe | **MCP** | VictoriaMetrics, Grafana | +| Script de validation | **Hook** | Lint avant commit | + +#### Exemples concrets + +**Slash Command** `/project:flux-status` → Rapport Flux immédiat, vous l'invoquez quand vous voulez. + +**Skill** `k8s-troubleshooter` → Vous dites "Mon déploiement est bloqué", Claude charge automatiquement les runbooks et diagnostique. + +**Agent** `k8s-security-reviewer` → Vous demandez un audit sécurité, l'agent parcourt tous les manifests, analyse, score et génère un rapport consolidé — en parallèle si plusieurs modules. + +{{% notice info "Coexistence" %}} +Ces trois mécanismes coexistent parfaitement. Utilisez des **slash commands** pour les actions explicites, des **skills** pour l'enrichissement contextuel, et des **agents** pour les tâches complexes nécessitant autonomie et parallélisme. +{{% /notice %}} + +### Les Hooks : être notifié quand Claude a terminé + +Les **Hooks** permettent d'exécuter des commandes shell à des moments précis du cycle de vie de Claude Code. Le cas d'usage le plus pratique : **être notifié** quand Claude a fini une tâche longue. + +#### Configuration de notification sonore + +Ajoutez dans `.claude/settings.json` : + +```json +{ + "hooks": { + "Stop": [ + { + "matcher": "", + "hooks": [ + { + "type": "command", + "command": "~/.local/bin/claude-notify.sh" + } + ] + } + ] + } +} +``` + +#### Script de notification (Linux) + +```bash +#!/bin/bash +# ~/.local/bin/claude-notify.sh + +# Jouer un son +paplay /usr/share/sounds/freedesktop/stereo/complete.oga 2>/dev/null || \ + aplay /usr/share/sounds/sound-icons/finish 2>/dev/null + +# Notification desktop +notify-send "Claude Code" "Tâche terminée !" \ + --icon=dialog-information \ + --urgency=normal +``` + +#### Script de notification (macOS) + +```bash +#!/bin/bash +# ~/.local/bin/claude-notify.sh + +osascript -e 'display notification "Tâche terminée" with title "Claude Code" sound name "Glass"' +``` + +N'oubliez pas de rendre le script exécutable : + +```console +chmod +x ~/.local/bin/claude-notify.sh +``` + +{{% notice tip "Ressources pour aller plus loin" %}} +- [claude-sounds](https://daveschumaker.net/claude-sounds-better-notifications-for-claude-code/) - Sons aléatoires pour plus de variété +- [claude-code-hooks-mastery](https://github.com/disler/claude-code-hooks-mastery) - Exemples avancés de hooks + +Les hooks permettent aussi le formatage automatique, le blocage d'actions, et bien plus. Consultez la [documentation officielle](https://code.claude.com/docs/en/hooks) pour les cas avancés. +{{% /notice %}} + +--- + +## :rocket: Cas concrets de platform engineering + +Assez de théorie ! Passons à ce qui nous intéresse vraiment : comment Claude Code peut nous aider au quotidien. Je vais vous partager deux cas concrets et détaillés qui illustrent la puissance des MCPs et du workflow avec Claude. + +### :mag: Cas 1 : Troubleshooting complet d'une Network Policy + +Ce cas illustre un workflow de troubleshooting de bout en bout, en utilisant plusieurs MCPs pour identifier et résoudre un problème réseau. + +#### Le contexte + +Après un déploiement, une application ne peut plus communiquer avec un service dans un autre namespace. Les logs montrent des timeouts mais aucune erreur explicite. Une alerte VictoriaMetrics a été déclenchée. + +#### Étape 1 : Identifier les alertes actives + +Avec le **MCP VictoriaMetrics**, je demande à Claude d'analyser les alertes : + +``` +> Utilise le MCP VictoriaMetrics pour lister les alertes actives +> sur le namespace demo. Quelles sont les alertes de type réseau ? +``` + +Claude interroge l'API et trouve : + +``` +ALERTES ACTIVES - namespace demo + +| Alerte | Sévérité | Depuis | Description | +|--------|----------|--------|-------------| +| HTTPHighLatency | warning | 15min | Latence HTTP > 5s (service backend) | +| CiliumDropsHigh | critical | 12min | Drops réseau élevés (>100/min) | +| EndpointNotReady | warning | 15min | Endpoint postgres non atteignable | +``` + +#### Étape 2 : Analyser les logs avec VictoriaLogs + +Je demande à Claude de corréler avec les logs via le **MCP VictoriaLogs** : + +``` +> Utilise le MCP VictoriaLogs pour chercher les erreurs de connexion +> dans le namespace demo des 30 dernières minutes. +> Filtre sur "connection refused" ou "timeout". +``` + +Claude exécute la requête LogsQL et trouve : + +``` +2026-01-08 14:32:15 [backend-7d4f9...] dial tcp 10.0.45.67:5432: i/o timeout +2026-01-08 14:32:20 [backend-7d4f9...] dial tcp 10.0.45.67:5432: i/o timeout +2026-01-08 14:32:25 [backend-7d4f9...] dial tcp 10.0.45.67:5432: i/o timeout +``` + +Claude identifie : les timeouts commencent exactement à 14:32, soit **2 minutes après un déploiement** d'une nouvelle NetworkPolicy. + +#### Étape 3 : Investigation des NetworkPolicies + +``` +> Liste les CiliumNetworkPolicy et NetworkPolicy qui affectent +> la communication entre le namespace demo et le namespace database. +``` + +Claude trouve la policy problématique : + +```yaml +# PROBLÈME IDENTIFIÉ +apiVersion: cilium.io/v2 +kind: CiliumNetworkPolicy +metadata: + name: postgres-access + namespace: database +spec: + endpointSelector: + matchLabels: + app: postgres + ingress: + - fromEndpoints: + - matchLabels: + app: backend + # ❌ MANQUANT : le selector de namespace ! + toPorts: + - ports: + - port: "5432" + protocol: TCP +``` + +#### Étape 4 : Correction et application + +Claude propose la correction : + +```yaml {hl_lines=[12]} +apiVersion: cilium.io/v2 +kind: CiliumNetworkPolicy +metadata: + name: postgres-access + namespace: database +spec: + endpointSelector: + matchLabels: + app: postgres + ingress: + - fromEndpoints: + - matchLabels: + k8s:io.kubernetes.pod.namespace: demo # ✅ Ajouté + app: backend + toPorts: + - ports: + - port: "5432" + protocol: TCP +``` + +Je valide et Claude applique la modification : + +```console +kubectl apply -f security/base/network-policies/postgres-access.yaml +``` + +#### Étape 5 : Créer une VMRule de prévention + +Pour éviter que ce problème ne se reproduise silencieusement, je demande à Claude de créer une alerte : + +``` +> Crée une VMRule qui alerte quand Cilium drop du traffic +> vers des services de type database. Utilise cilium_drop_count_total. +``` + +Claude génère : + +```yaml +apiVersion: operator.victoriametrics.com/v1beta1 +kind: VMRule +metadata: + name: cilium-database-drops + namespace: observability +spec: + groups: + - name: cilium-network + rules: + - alert: CiliumDatabaseConnectionDropped + expr: | + sum(rate(cilium_drop_count_total{ + reason="POLICY_DENIED", + direction="INGRESS" + }[5m])) by (destination_namespace) + * on(destination_namespace) group_left + kube_namespace_labels{label_type="database"} > 0 + for: 2m + labels: + severity: critical + annotations: + summary: "Traffic vers database droppé par Cilium" + description: "Policy réseau bloque le traffic vers {{ $labels.destination_namespace }}" +``` + +#### Étape 6 : Créer un dashboard Grafana + +Avec le **MCP Grafana**, je demande la création d'un dashboard de monitoring : + +``` +> Utilise le MCP Grafana pour créer un dashboard "Network Policies Monitoring" +> avec : +> - Panel 1: Drops Cilium par namespace (time series) +> - Panel 2: Top 10 policies avec le plus de drops (table) +> - Panel 3: Latence inter-namespace (heatmap) +``` + +Claude utilise le MCP pour créer le dashboard. Je peux ensuite le tester visuellement. + +{{% notice info "Chrome Integration (beta)" %}} +Avec la nouvelle extension Chrome de Claude, vous pouvez demander à Claude de **vérifier visuellement** que le dashboard s'affiche correctement. Claude peut interagir avec votre navigateur pour valider l'affichage. +{{% /notice %}} + +#### Résumé du workflow + +| Étape | MCP utilisé | Action | +|-------|-------------|--------| +| 1 | VictoriaMetrics | Identifier les alertes | +| 2 | VictoriaLogs | Analyser les logs, corréler | +| 3 | kubectl | Lister les NetworkPolicies | +| 4 | kubectl | Appliquer la correction | +| 5 | — | Créer VMRule prévention | +| 6 | Grafana | Créer dashboard monitoring | + +{{% notice tip "Ce qui a fait la différence" %}} +Sans les MCPs, j'aurais dû : +- Ouvrir VMUI manuellement et copier les résultats +- Exécuter des requêtes LogsQL et reformater les logs +- Naviguer dans Grafana pour créer le dashboard + +Avec les MCPs, Claude a fait tout cela en **5 minutes** au lieu de 45 minutes. +{{% /notice %}} + +--- + +### :building_construction: Cas 2 : Feature produit avec Spec-Driven Development + +Ce cas illustre comment utiliser Claude pour implémenter une vraie feature produit en suivant le framework **Spec-Driven Development** (SDD) du repository [cloud-native-ref](https://github.com/Smana/cloud-native-ref). + +#### Le contexte + +L'équipe produit veut pouvoir choisir entre **Kafka (Strimzi)** et **AWS SQS** pour le queuing de leurs applications. Actuellement, aucune abstraction n'existe. + +#### Le workflow SDD en un coup d'œil + +Le SDD de cloud-native-ref utilise un **modèle à deux documents** : + +| Document | Rôle | Contenu | +|----------|------|---------| +| **GitHub Issue** | Ancre immuable | Discussion, "quoi/pourquoi" | +| **Spec File** | Design détaillé | Checklist, "comment" | + +Le workflow complet : **Specify → Clarify → Tasks → Implement → Validate** + +#### Étape 1 : Créer la spec avec `/specify` + +La commande `/specify` est le point d'entrée du SDD. Elle crée automatiquement l'issue GitHub et le fichier de spec : + +``` +> /specify composition "Queue composition for Kafka and SQS backends" +``` + +Claude exécute la commande qui : +1. Crée une **GitHub Issue** `[SPEC] Queue composition for Kafka and SQS backends` +2. Génère un fichier de spec `docs/specs/active/0002-#42-queue-kafka-sqs.md` +3. Pré-remplit avec le template `spec-crossplane-composition.md` +4. Lit la **constitution** pour les contraintes non-négociables + +``` +✅ Specification created! + +🔗 GitHub Issue: https://github.com/Smana/cloud-native-ref/issues/42 +📄 Spec File: docs/specs/active/0002-#42-queue-kafka-sqs.md +📋 Type: composition + +## Review Personas +Before implementation, self-review as: +- [ ] PM: Problem clear? User stories valid? Scope defined? +- [ ] Platform Engineer: Patterns consistent? Implementation feasible? +- [ ] Security & Compliance: Zero-trust? Least privilege? Secrets managed? +- [ ] SRE: Observable? Recoverable? Failure modes documented? +``` + +#### Étape 2 : Compléter la spec et clarifier + +Je complète les sections du template, en ajoutant des marqueurs `[NEEDS CLARIFICATION]` pour les points à éclaircir : + +```markdown +## User Stories + +### US-001: Kafka Queue (P1) +**Given** une application dans le namespace `ecommerce` +**When** je déclare `queue: { enabled: true, type: kafka, size: medium }` +**Then** un cluster Kafka 3 replicas est créé avec credentials injectés + +### US-002: SQS Queue (P1) +**Given** une application serverless +**When** je déclare `queue: { type: sqs }` +**Then** une queue SQS est créée avec IAM via EKS Pod Identity + +[NEEDS CLARIFICATION: Faut-il supporter les FIFO queues pour SQS ?] +[NEEDS CLARIFICATION: Quelle version de Kafka par défaut ?] +``` + +Puis j'exécute `/clarify` pour résoudre les incertitudes interactivement : + +``` +> /clarify +``` + +Claude trouve les marqueurs et me pose les questions. Après mes réponses : + +```markdown +[CLARIFIED: Non, FIFO queues hors scope pour v1 - à ajouter si demandé] +[CLARIFIED: Kafka 3.7.0 par défaut, configurable via spec.queue.kafka.version] +``` + +#### Étape 3 : Générer le breakdown de tâches (optionnel) + +``` +> /tasks +``` + +Claude génère un plan de tâches avec dépendances : + +```markdown +## Task Breakdown - SPEC-0002 + +### Phase 1: Setup +| ID | Task | Dependencies | +|----|------|--------------| +| T1 | Créer le module KCL queue/main.k | - | +| T2 | Définir le XRD xqueues.cloud.ogenki.io | - | + +### Phase 2: Implementation [P] +| T3 | Implémenter le backend Kafka (Strimzi) | T1 | +| T4 | Implémenter le backend SQS | T1 | +| T5 | Ajouter CiliumNetworkPolicy | T3, T4 | + +### Phase 3: Validation +| T6 | Écrire les exemples (basic + complete) | T3, T4 | +| T7 | Valider avec crossplane render | T2, T6 | +``` + +#### Étape 4 : Implémenter en suivant la spec + +Maintenant Claude peut implémenter en respectant la spec ET la constitution : + +``` +> Implémente la composition Queue en suivant la spec 0002 +> et les règles de la constitution (préfixe xplane-*, pas de mutation) +``` + +Claude génère le code KCL (extrait) : + +```python +# infrastructure/base/crossplane/configuration/kcl/queue/main.k + +oxr = option("params").oxr +_name = oxr.metadata.name +_queueType = oxr.spec.queue.type or "kafka" +_size = oxr.spec.queue.size or "small" + +# Mapping tailles vers ressources (constitution: pas de mutation) +_sizePresets = { + kafka = { + small = { replicas = 1, storage = "10Gi" } + medium = { replicas = 3, storage = "50Gi" } + } + sqs = { + small = { visibilityTimeout = 30 } + medium = { visibilityTimeout = 120 } + } +} + +# Constitution: préfixe xplane-* obligatoire +_kafkaCluster = { + metadata.name = "xplane-${_name}-kafka" + # ... +} +``` + +#### Étape 5 : Valider et créer la PR + +Claude exécute les validations de la constitution : + +```console +kcl fmt infrastructure/base/crossplane/configuration/kcl/queue/ +kcl run -Y settings-example.yaml +crossplane render examples/queue-kafka.yaml composition.yaml functions.yaml +``` + +Puis crée la PR avec référence automatique à la spec : + +``` +> /create-pr +``` + +La commande `/create-pr` détecte automatiquement la spec et génère : + +```markdown +## Summary +Implements #42 + +Adds Queue composition supporting Kafka (Strimzi) and AWS SQS backends. + +## Changes +- New KCL module: `queue/main.k` +- XRD: `xqueues.cloud.ogenki.io` +- Examples: basic and complete usage +``` + +#### Résultat : l'API utilisateur finale + +Le développeur peut maintenant simplement déclarer : + +```yaml +apiVersion: cloud.ogenki.io/v1alpha1 +kind: Queue +metadata: + name: orders-queue + namespace: ecommerce +spec: + queue: + type: kafka + size: medium +``` + +#### Résumé du workflow SDD + +| Commande | Action | Résultat | +|----------|--------|----------| +| `/specify composition` | Créer spec | Issue GitHub + fichier spec | +| `/clarify` | Résoudre incertitudes | Marqueurs [CLARIFIED] | +| `/tasks` | Planifier | Breakdown avec dépendances | +| (implémentation) | Coder selon spec | Code conforme à la constitution | +| `/create-pr` | Créer PR | Lien automatique "Implements #XX" | + +{{% notice info "Pourquoi le modèle à deux documents ?" %}} +- **GitHub Issue** : Discoverabilité, discussion, mentions, ancre immuable +- **Spec File** : Design détaillé, checklists des 4 personas (PM, PE, Security, SRE) +- **Après merge** : Spec archivée dans `docs/specs/completed/` pour référence +{{% /notice %}} + +--- + +## :bulb: Tips pour optimiser son usage + +### Git Worktrees : paralléliser les sessions Claude + +Plutôt que de jongler avec des branches et du `stash`, utilisez les **git worktrees** pour travailler sur plusieurs features en parallèle avec des sessions Claude indépendantes. + +```console +# Créer des worktrees pour deux features +git worktree add ../worktrees/feature-a -b feat/feature-a +git worktree add ../worktrees/feature-b -b feat/feature-b + +# Lancer des sessions Claude séparées +cd ../worktrees/feature-a && claude # Terminal 1 +cd ../worktrees/feature-b && claude # Terminal 2 +``` + +**Pourquoi c'est puissant :** +- Chaque session a son **propre contexte** et sa propre mémoire +- Aucune interférence entre les tâches +- Merge indépendant quand c'est prêt + +| Commande | Usage | +|----------|-------| +| `git worktree list` | Voir tous les worktrees actifs | +| `git worktree add -b ` | Créer un worktree + branche | +| `git worktree remove ` | Supprimer un worktree | + +--- + +### Ma recommandation : le workflow hybride Cursor + Claude Code + +Plutôt que de choisir entre IDE et terminal, combinez les deux. C'est l'approche que je recommande : **Cursor** (même en version gratuite) pour l'édition quotidienne, **Claude Code** pour les tâches agentiques. + +| Besoin | Outil | Pourquoi | +|--------|-------|----------| +| Édition rapide, autocomplete | Cursor | Latence minimale, vous restez dans le flow | +| Refactoring, debugging multi-fichiers | Claude Code | Raisonnement profond, boucles autonomes | + +**Les vrais gains de ce setup :** + +- **Review visuelle des changements** : Claude modifie via le terminal, vous validez les diffs dans l'interface Cursor — bien plus lisible que `git diff` +- **Contexte enrichi** : L'indexation locale de Cursor complète le contexte de Claude +- **Coût maîtrisé** : Un seul abonnement (Anthropic) suffit pour la puissance agentique + +{{% notice tip "En pratique" %}} +Je lance Cursor pour naviguer et éditer. Quand une tâche devient complexe (refactoring, debugging, génération de code), je bascule sur Claude Code dans le terminal intégré. Les modifications apparaissent en temps réel dans Cursor. +{{% /notice %}} + +--- + +### Optimiser le contexte + +Le contexte est précieux (et coûteux). Voici comment l'économiser : + +**1. Utilisez `/clear` régulièrement** + +Chaque nouvelle tâche devrait commencer par un `/clear`. Vous n'avez pas besoin de l'historique d'une conversation de debugging pour écrire de la documentation. + +**2. Gardez CLAUDE.md concis** + +Chaque token dans `CLAUDE.md` est chargé à **chaque conversation**. Gardez-le minimal et pertinent. + +```markdown +# BON - concis et actionnable +## Commandes +make test, make lint + +## Conventions +- Branches: feat/, fix/, docs/ +- Pas de mutation KCL +``` + +**3. Préférez les CLIs aux MCPs quand possible** + +Pour Kubernetes, `kubectl` consomme moins de tokens que le MCP Kubernetes. Claude connaît déjà parfaitement les CLIs. + +**4. Utilisez `/context` pour auditer** + +```console +/context +``` + +Cette commande montre ce qui consomme votre contexte. Désactivez les MCPs non utilisés pour la tâche en cours. + +--- + +### Écrire du code "AI-readable" + +Burke Holland, dans son article ["Opus 4.5 is going to change everything"](https://burkeholland.github.io/posts/opus-4-5-change-everything/), propose un paradigme intéressant : optimiser le code pour la **lisibilité par l'IA**, pas seulement humaine. + +**Principes :** + +| Principe | Explication | +|----------|-------------| +| **Noms descriptifs** | Variables et fonctions auto-documentées | +| **Flux linéaire** | Éviter les abstractions complexes | +| **Couplage minimal** | Permettre la régénération de fichiers entiers | +| **Structure prévisible** | Grouper par features, pas par types | + +Cette approche facilite le travail de l'agent car il peut régénérer des portions de code sans casser le reste du système. + +--- + +### Ce qui fonctionne bien vs ce qui nécessite vigilance + +| ✅ Claude excelle | ⚠️ Vigilance requise | +|-------------------|----------------------| +| Debugging avec contexte | Création from scratch | +| Conversion de formats | Sécurité/PKI | +| Refactoring répétitif | Ressources cloud coûteuses | +| Analyse de dépendances | Breaking changes | + +--- + +### Mon workflow type + +``` +1. Décrire le problème clairement (contexte, erreur, objectif) +2. Pointer vers les fichiers pertinents +3. Demander une analyse AVANT une solution +4. Valider la proposition +5. Appliquer par étapes (pas tout d'un coup) +6. Tester et itérer +``` + +{{% notice warning "Ne pas oublier" %}} +Claude est un **outil**, pas un remplaçant. J'ai appris autant en lisant ses explications qu'en appliquant ses solutions. Si vous faites juste copier-coller sans comprendre, vous perdez l'opportunité d'apprendre et vous risquez d'introduire des erreurs. +{{% /notice %}} + +--- + +## :moneybag: Coûts et optimisation + +Parlons argent. Claude Code peut vite devenir coûteux si on ne fait pas attention. Voici comment maîtriser ses dépenses. + +### Comprendre le pricing + +#### Les plans disponibles + +| Plan | Prix | Inclut | Idéal pour | +|------|------|--------|------------| +| **Free** | 0€ | Messages limités (variable) | Découverte | +| **Pro** | 20$/mois | Usage standard | Usage personnel régulier | +| **Max 5x** | 100$/mois | 5× l'usage Pro | Power users | +| **Max 20x** | 200$/mois | 20× l'usage Pro | Usage intensif | +| **Team** | 30$/user/mois | Collaboration, admin | Petites équipes | +| **Enterprise** | Sur devis | SSO, audit, compliance | Grandes organisations | + +{{% notice info "Claude Code inclus !" %}} +Depuis 2025, Claude Code est [inclus dans les plans Team et Enterprise](https://devops.com/enterprise-ai-development-gets-a-major-upgrade-claude-code-now-bundled-with-team-and-enterprise-plans/). Vous n'avez plus à choisir entre innovation et gouvernance. +{{% /notice %}} + +#### Coût API (pay-per-use) + +Si vous utilisez l'API directement (hors forfait) : + +| Modèle | Input (par M tokens) | Output (par M tokens) | +|--------|---------------------|----------------------| +| **Opus 4.5** | 5.00$ | 25.00$ | +| **Sonnet 4.5** | 3.00$ | 15.00$ | +| **Haiku** | 1.00$ | 5.00$ | + +**Prompt Caching** (réduction significative) : +- Cache read : **0.1×** le prix input (90% de réduction !) +- Cache write (5 min) : 1.25× le prix input +- Cache write (1 heure) : 2× le prix input + +### Choisir le bon modèle selon la tâche + +C'est **LA** clé pour optimiser ses coûts. Tous les modèles ne sont pas égaux, et Opus n'est pas toujours nécessaire. + +| Tâche | Modèle recommandé | Pourquoi | +|-------|-------------------|----------| +| Debugging complexe (ex: Cilium) | **Opus 4.5** | Analyse profonde, corrélation multi-sources | +| Refactoring multi-fichiers | **Opus 4.5** | Garde le contexte complet | +| Génération Terraform/YAML | **Sonnet 4.5** | Suffisamment précis, 40% moins cher | +| Commits, petites éditions | **Haiku** | Rapide et économique | +| Lecture/synthèse de docs | **Sonnet 4.5** | Bon compromis | +| Résolution de problèmes nouveaux | **Opus 4.5** | Meilleur raisonnement | + +```console +# Changer de modèle en cours de session +/model sonnet + +# Ou au lancement +claude --model haiku +``` + +{{% notice tip "Le conseil de Boris Cherny (créateur de Claude Code)" %}} +*"J'utilise Opus 4.5 avec thinking pour tout. C'est le meilleur modèle de code que j'ai utilisé, et même s'il est plus gros et plus lent que Sonnet, comme vous avez moins besoin de le guider et qu'il est meilleur en tool use, il est presque toujours plus rapide au final."* + +Mon avis : c'est vrai pour les tâches complexes, mais pour les tâches simples, Haiku reste plus économique. +{{% /notice %}} + +### Surveiller sa consommation + +#### Pendant la session + +```console +# Voir le coût de la session actuelle +/cost + +# Voir l'utilisation du contexte +/context +``` + +#### Historique + +```console +# Statistiques d'utilisation +/stats +``` + +### Optimisations pratiques + +#### 1. Utiliser `/clear` souvent + +Chaque nouvelle tâche devrait commencer par un `/clear`. Vous n'avez pas besoin de l'historique d'une conversation de debugging pour écrire de la documentation. + +```console +> /clear +Contexte effacé. Nouvelle conversation. +``` + +#### 2. Préférer les CLIs aux MCPs quand possible + +Les MCPs ajoutent des définitions d'outils au contexte. Pour Kubernetes par exemple : + +```console +# Via MCP Kubernetes (consomme des tokens pour les définitions) +> utilise le MCP k8s pour lister les pods + +# Via kubectl (Claude connaît déjà la CLI) +> exécute kubectl get pods -n production +``` + +#### 3. Désactiver l'auto-compact si possible + +L'auto-compaction résume automatiquement les conversations longues, mais elle consomme des tokens. Pour des sessions courtes et ciblées, vous pouvez la désactiver : + +```console +claude --no-auto-compact +``` + +#### 4. Fichiers CLAUDE.md concis + +Chaque token dans `CLAUDE.md` est chargé à **chaque conversation**. Gardez-le minimal et pertinent. + +#### 5. Utiliser les worktrees pour paralléliser + +Au lieu d'une longue session avec beaucoup de context switching, utilisez des worktrees Git pour des sessions parallèles et ciblées : + +```console +# Créer des worktrees séparés +git worktree add ../wt-feature-a -b feat/feature-a +git worktree add ../wt-feature-b -b feat/feature-b + +# Sessions Claude indépendantes +cd ../wt-feature-a && claude # Session 1 +cd ../wt-feature-b && claude # Session 2 +``` + +### Rate Limits + +Depuis août 2025, Anthropic applique des **limites hebdomadaires** pour les utilisateurs intensifs : + +- Affecte moins de 5% des utilisateurs +- Cible principalement l'utilisation 24/7 continue +- Les abonnés Max peuvent acheter de l'usage supplémentaire au tarif API + +{{% notice warning "Si vous atteignez les limites" %}} +- Utilisez Haiku pour les tâches simples +- Évitez de laisser Claude "tourner" sans supervision +- Répartissez votre usage sur la semaine +{{% /notice %}} + +--- + +## :thought_balloon: Réflexions et mises en garde + +C'est le moment d'être honnête. Claude Code est un outil formidable, mais il n'est pas parfait. Voici mes retours après plusieurs mois d'utilisation intensive. + +### Éviter la dépendance : continuer à apprendre + +#### Le risque d'atrophie des compétences + +C'est peut-être le point le plus important de cet article. Une [étude de Stanford](https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/) a révélé que l'emploi des développeurs de 22-25 ans a chuté de **20%** entre 2022 et 2025, coïncidant avec l'essor des outils d'IA. + +Les risques identifiés : +- **Capacité de résolution de problèmes** qui s'atrophie quand on ne l'exerce plus +- Difficulté à travailler **sans assistance IA** +- Transfert de connaissances aux juniors **compromis** quand les seniors délèguent tout + +{{% notice warning "Le paradoxe de la productivité" %}} +Une [étude METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) a trouvé un résultat surprenant : les développeurs utilisant l'IA prennent **19% plus de temps** pour compléter des tâches ! Pourtant, ils *croient* avoir été plus rapides de 24%. L'écart entre perception et réalité est frappant. +{{% /notice %}} + +#### Comment maintenir ses compétences ? + +1. **Reviewer systématiquement** le code généré + - Ne pas juste accepter aveuglément + - Comprendre *pourquoi* cette solution + - Être capable de la reproduire manuellement + +2. **Se forcer à des sessions "sans IA"** + - Une fois par semaine, débugger à l'ancienne + - Pratiquer la lecture de code sans assistance + +3. **Enseigner aux autres** + - Expliquer le code généré force à le comprendre + - Le pair programming reste essentiel + +``` +Mon workflow de review : +1. Claude génère une solution +2. Je lis TOUT le code modifié +3. Je me demande : "Aurais-je fait pareil ?" +4. Si non, pourquoi ? Qu'est-ce que j'apprends ? +5. Seulement alors, je valide +``` + +### Qualité du code et dette technique + +Les chiffres sont parlants. Selon une [étude Qodo](https://www.qodo.ai/reports/state-of-ai-code-quality/) sur la qualité du code IA : + +| Métrique | Code IA | Code humain | +|----------|---------|-------------| +| Problèmes par PR | 10.83 | 6.45 | +| Code dupliqué | **4× plus** | Baseline | +| Top frustration dev | Dette technique (62.4%) | — | + +{{% notice info "Mon observation personnelle" %}} +Claude est excellent pour le **premier jet**, mais il a tendance à : +- Sur-ingénier les solutions simples +- Ajouter du code défensif inutile +- Créer des abstractions prématurées + +Mon conseil : demandez explicitement la solution la plus simple possible. +{{% /notice %}} + +### Hallucinations et contexte manquant + +Malgré les progrès, les hallucinations persistent : +- **25%** des développeurs estiment qu'1 suggestion sur 5 contient des erreurs +- **65%** signalent que l'assistant "manque du contexte pertinent" pour le refactoring + +**Cas typiques :** +- Référence à des packages qui n'existent pas +- API deprecated ou incorrecte +- Configuration incompatible avec votre version + +**Comment mitiger :** +```console +# Toujours spécifier les versions +> Utilise Terraform 1.11 et le provider AWS 6.x + +# Demander les sources +> Montre-moi la doc officielle qui confirme cette approche + +# Utiliser context7 pour la doc à jour +> use context7 pour la doc Cilium 1.15 +``` + +### Sécurité et confidentialité + +#### Ce qui est envoyé aux serveurs + +Soyons clairs sur ce que Claude Code envoie : + +| Données | Envoyées ? | Notes | +|---------|------------|-------| +| Fichiers lus explicitement | Oui | Uniquement ceux que Claude lit | +| Autres fichiers du projet | Non | Restent locaux | +| Variables d'environnement | Non | Sauf si vous les partagez | +| Historique bash | Non | — | + +#### Plan Enterprise vs API + +| Aspect | API Standard | Enterprise | +|--------|--------------|------------| +| Rétention données | 7 jours | Configurable | +| Training sur vos données | Non | Non | +| Zero Data Retention | Option payante | Disponible | +| SSO / Audit logs | Non | Oui | +| Compliance SOC2 | Oui | Oui | + +{{% notice tip "Pour les entreprises" %}} +Si vous travaillez sur du code sensible : +- Utilisez le plan **Enterprise** ou **Team** +- Demandez l'addendum **Zero-Data-Retention** (ZDR) +- Configurez des hooks pour bloquer l'envoi de fichiers sensibles +- N'utilisez **jamais** le plan Free/Consumer pour du code propriétaire +{{% /notice %}} + +### Les sceptiques ont-ils tort ? + +J'entends souvent des collègues dire : *"Je ne fais pas confiance à l'IA pour coder"*. Ont-ils tort ? + +**Arguments des sceptiques :** +- "Je préfère comprendre mon code" +- "L'IA ne connaît pas mon contexte métier" +- "Les juniors ne vont plus apprendre" +- "C'est juste du hype" + +**Ma réponse nuancée :** + +Ces préoccupations sont **légitimes**. L'IA n'est pas une solution magique. Mais refuser d'utiliser ces outils, c'est comme refuser d'utiliser un IDE parce que "vim suffit". + +La vraie question n'est pas *"Faut-il utiliser l'IA ?"* mais *"Comment l'utiliser intelligemment ?"* + +| Utilisation | Risque | Bénéfice | +|-------------|--------|----------| +| Copier-coller aveugle | Élevé | Faible | +| Délégation avec review | Modéré | Élevé | +| Collaboration (pair programming IA) | Faible | Très élevé | + +{{% notice info "Le point de vue de Burke Holland" %}} +Dans son article ["Opus 4.5 is going to change everything"](https://burkeholland.github.io/posts/opus-4-5-change-everything/), Burke Holland — qui était lui-même sceptique — admet que *"les agents IA peuvent absolument remplacer les développeurs"* pour certaines tâches. Mais il nuance immédiatement : son approche fonctionne *"50% du temps"* selon ses propres termes. + +L'IA est un **amplificateur**, pas un remplacement. Un développeur médiocre avec l'IA restera médiocre. Un excellent développeur avec l'IA sera encore meilleur. +{{% /notice %}} + +### Mes règles personnelles + +Après plusieurs mois d'utilisation, voici les règles que je me suis fixées : + +1. **Jamais de merge sans review manuelle** + - Même si Claude dit que "ça marche" + - Même si les tests passent + +2. **Toujours comprendre avant d'appliquer** + - Si je ne comprends pas, je ne merge pas + - Je demande à Claude d'expliquer + +3. **Une heure de "no-AI" par jour** + - Pour garder la main + - Pour rester capable de travailler sans + +4. **Vérifier les claims techniques** + - Consulter la doc officielle + - Tester dans un environnement isolé + +5. **Documenter ce que Claude a fait** + - Pour les collègues + - Pour moi-même dans 6 mois + +--- + +## :dart: Conclusion + +Au terme de cet article, j'espère vous avoir convaincu que les coding agents comme Claude Code ne sont pas un gadget, mais un **véritable changement de paradigme** dans notre façon de travailler. + +### Ce que j'ai appris + +| Aspect | Avant Claude Code | Avec Claude Code | +|--------|-------------------|------------------| +| Debugging Cilium | 2h de lecture de logs | 15 min avec contexte | +| Refactoring Terraform | Journée entière | 2h avec review | +| Écriture de doc | Procrastination | Généré + relu = 30 min | +| Onboarding nouveau repo | Plusieurs jours | Quelques heures | + +### Les clés du succès + +1. **Investir dans le contexte** : Un bon `CLAUDE.md` fait toute la différence +2. **Choisir le bon modèle** : Opus pour le complexe, Haiku pour le simple +3. **Maintenir l'esprit critique** : Review systématique, jamais d'acceptation aveugle +4. **Continuer à apprendre** : L'IA augmente, elle ne remplace pas + +### Et pour la suite ? + +Le domaine évolue à une vitesse folle. Dans 6 mois, cet article sera probablement en partie obsolète. Les MCPs vont se multiplier, les modèles vont s'améliorer, et de nouvelles pratiques vont émerger. + +Mon conseil : **expérimentez maintenant**. Même si vous êtes sceptique, prenez une heure pour tester. Vous pourriez être surpris. + +{{% notice info "Rejoignez la discussion" %}} +J'aimerais beaucoup avoir vos retours d'expérience ! N'hésitez pas à me contacter ou à ouvrir une issue sur le [repo cloud-native-ref](https://github.com/Smana/cloud-native-ref). +{{% /notice %}} + +--- + +## :bookmark: Références + +### Documentation officielle +- [Claude Code Documentation](https://code.claude.com/docs/) +- [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - Anthropic Engineering +- [Model Context Protocol](https://modelcontextprotocol.io/) - Spécification officielle +- [Claude Code Hooks Reference](https://code.claude.com/docs/en/hooks) - Documentation des hooks +- [Claude Code Skills](https://code.claude.com/docs/en/skills) - Documentation des skills +- [Claude Pricing](https://claude.com/pricing) - Tarification à jour + +### Benchmarks et comparatifs +- [SWE-bench Leaderboards](https://www.swebench.com/) - Benchmark de référence +- [SWE-bench Pro](https://scale.com/leaderboard/swe_bench_pro_public) - Benchmark plus difficile (Scale AI) +- [Artificial Analysis - Coding Agents](https://artificialanalysis.ai/insights/coding-agents-comparison) - Comparatif des agents +- [State of AI Code Quality 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/) - Qodo + +### MCPs pour Platform Engineering +- [Context7 MCP](https://github.com/upstash/context7) - Documentation à jour pour LLMs (Upstash) +- [Flux MCP Server](https://fluxcd.control-plane.io/mcp/) - GitOps et Flux (ControlPlane) +- [VictoriaMetrics MCP](https://github.com/VictoriaMetrics-Community/mcp-victoriametrics) - Métriques PromQL +- [VictoriaLogs MCP](https://github.com/VictoriaMetrics-Community/mcp-victorialogs) - Logs LogsQL +- [Grafana MCP](https://github.com/grafana/mcp-grafana) - Dashboards et alertes +- [Steampipe MCP](https://github.com/turbot/steampipe-mcp) - Requêtes SQL cloud (Turbot) +- [Awesome DevOps MCP Servers](https://github.com/rohitg00/awesome-devops-mcp-servers) - Liste curatée + +### Articles et études +- [Opus 4.5 is going to change everything](https://burkeholland.github.io/posts/opus-4-5-change-everything/) - Burke Holland +- [AI Coding Is Everywhere](https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/) - MIT Technology Review +- [METR Study on AI Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) - Étude sur la productivité +- [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) - Anthropic Research +- [How I Use Every Claude Code Feature](https://blog.sshh.io/p/how-i-use-every-claude-code-feature) - Guide complet + +### Outils et ressources +- [Cloud Native Ref](https://github.com/Smana/cloud-native-ref) - Mon repo de référence +- [Claude Code Hooks Mastery](https://github.com/disler/claude-code-hooks-mastery) - Exemples de hooks +- [claude-sounds](https://daveschumaker.net/claude-sounds-better-notifications-for-claude-code/) - Notifications sonores +- [ClaudeLog](https://claudelog.com/) - Guides et tutoriels communautaires diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_mcp.png b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_mcp.png new file mode 100644 index 00000000..8cc38077 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_mcp.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_plan.png b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_plan.png new file mode 100644 index 00000000..5309078e Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_plan.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_summary.png b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_summary.png new file mode 100644 index 00000000..7a2bf5b6 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/karpenter_summary.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/repo_gift.png b/content/fr/post/series/agentic_ai/ai-coding-agent/repo_gift.png new file mode 100644 index 00000000..f30bff2a Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/repo_gift.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_1.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_1.png new file mode 100644 index 00000000..bc524a5d Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_1.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_2.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_2.png new file mode 100644 index 00000000..d45c2606 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_clarify_2.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_1.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_1.png new file mode 100644 index 00000000..90f640a5 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_1.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_summary.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_summary.png new file mode 100644 index 00000000..7e54d698 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_implement_summary.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_spec.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_spec.png new file mode 100644 index 00000000..f5a3756b Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_spec.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_validation.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_validation.png new file mode 100644 index 00000000..65103b2d Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_validation.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_workflow.png b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_workflow.png new file mode 100644 index 00000000..11a9c62d Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/sdd_workflow.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/skill-acquired-notif.png b/content/fr/post/series/agentic_ai/ai-coding-agent/skill-acquired-notif.png new file mode 100644 index 00000000..2ca8a558 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/skill-acquired-notif.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/swe-bench-leaderboard.png b/content/fr/post/series/agentic_ai/ai-coding-agent/swe-bench-leaderboard.png new file mode 100644 index 00000000..c991ef1a Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/swe-bench-leaderboard.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/tasks_notif.png b/content/fr/post/series/agentic_ai/ai-coding-agent/tasks_notif.png new file mode 100644 index 00000000..93107fcb Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/tasks_notif.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-agent/thumbnail.png b/content/fr/post/series/agentic_ai/ai-coding-agent/thumbnail.png new file mode 100644 index 00000000..457c541d Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-agent/thumbnail.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-tips/cursor+claude.png b/content/fr/post/series/agentic_ai/ai-coding-tips/cursor+claude.png new file mode 100644 index 00000000..e0b9b109 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-tips/cursor+claude.png differ diff --git a/content/fr/post/series/agentic_ai/ai-coding-tips/index.md b/content/fr/post/series/agentic_ai/ai-coding-tips/index.md new file mode 100644 index 00000000..acf49cac --- /dev/null +++ b/content/fr/post/series/agentic_ai/ai-coding-tips/index.md @@ -0,0 +1,390 @@ ++++ +author = "Smaine Kahlouch" +title = "`Claude Code` : Optimisation et bonnes pratiques pour le Platform Engineer" +date = "2026-01-28" +summary = "Tips avancés pour tirer le meilleur de Claude Code : CLAUDE.md, hooks, gestion du contexte, workflows multi-sessions, plugins, anti-patterns à éviter et intégration CI/CD." +featured = true +codeMaxLines = 30 +usePageBundles = true +toc = true +series = ["Agentic AI"] +aliases = ["/fr/post/ai-coding-tips/"] +tags = ["ai", "devxp", "tooling"] +thumbnail = "thumbnail.png" ++++ + +{{% notice info "Série Agentic AI — Partie 2" %}} +Cet article fait suite à [Agentic Coding : concepts et cas concrets](/fr/post/series/agentic_ai/ai-coding-agent/), où nous avons exploré les fondamentaux de l'IA agentique — tokens, MCPs, Skills, Tasks — et deux cas pratiques détaillés. **Ici, on passe à la pratique avancée** : comment tirer le maximum de Claude Code au quotidien. +{{% /notice %}} + +Après plusieurs mois d'utilisation intensive de Claude Code, certains patterns se dégagent clairement. Entre les sessions perdues faute de contexte, les hooks qui auraient pu tout automatiser, et les mauvaises habitudes qui font perdre un temps fou — voici les **tips et workflows qui ont transformé ma façon de travailler**. + +--- + +## :scroll: CLAUDE.md : le cerveau persistant + +Le fichier `CLAUDE.md` est le **premier levier d'optimisation**. C'est de la mémoire persistante : des instructions injectées automatiquement dans chaque conversation. Si vous n'en avez pas encore, c'est la première chose à mettre en place. + +### Hiérarchie de chargement + +Claude Code charge les fichiers `CLAUDE.md` selon une hiérarchie précise : + +| Emplacement | Portée | Cas d'usage | +|-------------|--------|-------------| +| `~/.claude/CLAUDE.md` | Toutes les sessions, tous les projets | Préférences globales (langue, style de commit) | +| `./CLAUDE.md` | Projet (partagé via git) | Conventions d'équipe, commandes de build/test | +| `./CLAUDE.local.md` | Projet (non versionné) | Préférences personnelles sur ce projet | +| `./sous-dossier/CLAUDE.md` | Sous-arborescence | Instructions spécifiques à un module | + +Les fichiers sont **cumulatifs** : Claude les charge tous du plus global au plus local. En cas de conflit, le plus local l'emporte. + +### Ce que je mets dans le mien + +Voici ce que contient le `CLAUDE.md` de [cloud-native-ref](https://github.com/Smana/cloud-native-ref), concrètement : + +- **Commandes de build/test/lint** — les premières lignes, pour que Claude sache comment valider son travail +- **Conventions du projet** — préfixe `xplane-*` pour l'IAM, structure des compositions Crossplane, patterns KCL +- **Architecture résumée** — structure des dossiers clés, pas un roman +- **Erreurs fréquentes** — les pièges que Claude retombe dedans si on ne le prévient pas (ex: mauvais namespace par défaut, format des labels) + +Ce que je n'y mets **pas** : la documentation exhaustive (c'est le rôle des [Skills](/fr/post/series/agentic_ai/ai-coding-agent/#skills--obtenir-de-nouveaux-pouvoirs)), les exemples de code longs (je référence les fichiers existants), et les instructions évidentes que Claude connaît déjà. + +{{% notice warning "Règle des ~500 lignes" %}} +Chaque token de `CLAUDE.md` est chargé à **chaque conversation**. Un fichier trop long gaspille du contexte précieux. Visez ~500 lignes maximum et déplacez les instructions spécialisées vers des **Skills** qui ne se chargent qu'à la demande. +{{% /notice %}} + +### Itérer sur CLAUDE.md + +Traitez `CLAUDE.md` comme un **prompt de production** : itérez dessus régulièrement. Le raccourci `#` permet de demander à Claude lui-même de suggérer des améliorations à votre fichier. Vous pouvez aussi utiliser le [prompt improver](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/prompt-improver) d'Anthropic pour affiner les instructions. + +--- + +## :hook: Hooks : mon premier automatisme + +Les **hooks** sont des commandes shell exécutées automatiquement en réponse à des événements Claude Code. La différence clé avec `CLAUDE.md` : les instructions du CLAUDE.md sont *consultatives* (Claude peut les ignorer), les hooks sont **déterministes** — ils s'exécutent systématiquement. + +### La notification quand Claude attend + +Le premier hook que j'ai configuré — et celui que je recommande à tout le monde — c'est la **notification desktop**. Quand Claude termine une tâche ou attend votre validation, vous recevez une notification système. Fini de checker le terminal toutes les 30 secondes. + +Configuration dans `~/.claude/settings.json` : + +```json +{ + "hooks": { + "Notification": [ + { + "matcher": "", + "hooks": [ + { + "type": "command", + "command": "notify-send 'Claude Code' \"$CLAUDE_NOTIFICATION\" --icon=dialog-information" + } + ] + } + ] + } +} +``` + +Sous Linux, `notify-send` est fourni par le paquet `libnotify`. Sur macOS, remplacez par `osascript -e 'display notification "..."'`. + +### Les autres possibilités + +Les hooks couvrent plusieurs événements (`PreToolUse`, `PostToolUse`, `Notification`, `Stop`, `SessionStart`) et permettent par exemple : + +- **Auto-format** après chaque édition (ex: `gofmt` sur les fichiers Go) +- **Protection de fichiers sensibles** — un hook `PreToolUse` qui bloque l'écriture dans les `.env`, `.pem`, `.key` (exit code 2 = action bloquée) +- **Audit** des commandes exécutées dans un fichier de log + +Je ne détaille pas ici chaque variante — la [doc officielle des hooks](https://docs.anthropic.com/en/docs/claude-code/hooks) est très bien faite. L'essentiel c'est de comprendre que les hooks sont votre filet de sécurité **déterministe** là où `CLAUDE.md` n'est qu'un conseil. + +--- + +## :brain: Maîtriser la fenêtre de contexte + +La fenêtre de contexte (200K tokens) est **la ressource la plus critique**. Une fois saturée, les informations anciennes sont compressées et la qualité se dégrade. C'est LE sujet qui fait la différence entre un utilisateur efficace et quelqu'un qui "perd" Claude au bout de 20 minutes. + +### `/compact` avec instructions custom + +La commande `/compact` compresse l'historique de conversation tout en préservant les décisions clés. L'astuce : vous pouvez passer des **instructions de focus** pour garder ce qui compte : + +``` +/compact focus on the Crossplane composition decisions and ignore the debugging steps +``` + +C'est particulièrement utile après une longue session de debugging où 80% du contexte est du bruit (tentatives échouées, stack traces). + +### Stratégie `/clear` + +La commande `/clear` remet le contexte à zéro. Quand l'utiliser ? + +- **Toujours** entre deux tâches distinctes — c'est la règle la plus importante +- Quand Claude commence à **halluciner** ou à répéter des erreurs +- Après une longue session de debugging (le contexte est pollué par les tentatives échouées) +- Quand `/context` montre un espace libre < 20% + +J'ai pris l'habitude de commencer chaque nouvelle tâche par un `/clear`. Ça semble contre-intuitif (on perd le contexte), mais en pratique c'est bien plus efficace qu'un contexte pollué. + +### Tool Search : quand les MCPs bouffent le contexte + +Le problème : chaque MCP activé injecte ses **définitions d'outils** dans le contexte. Avec 6-7 MCPs configurés (ce qui est courant en platform engineering), ça peut représenter plus de **10% de votre fenêtre** — consommé avant même de commencer à travailler. + +La solution : activer le **Tool Search** : + +```bash +export ENABLE_TOOL_SEARCH=auto:10 +``` + +Avec cette option, Claude ne charge les définitions d'outils que **quand il en a besoin**, plutôt que de toutes les garder en mémoire. Le `10` est le seuil (en pourcentage du contexte) à partir duquel le mécanisme s'active. + +### Délégation aux subagents + +Pour les tâches d'exploration volumineuses (parcourir un codebase, chercher dans les logs), Claude peut déléguer à des **subagents** qui ont leur propre contexte isolé. Le résultat condensé est renvoyé à la session principale — économisant ainsi de précieux tokens. + +En pratique, Claude le fait automatiquement quand il juge que c'est pertinent (exploration de fichiers, recherches larges). Mais vous pouvez aussi le guider explicitement : *"utilise un subagent pour explorer la structure du module networking"*. + +### Quelques règles simples + +1. **`/clear` entre les tâches** : Chaque nouvelle tâche devrait commencer par un `/clear` +2. **CLAUDE.md concis** : Chaque token est chargé à chaque conversation +3. **CLIs > MCPs** : Pour les outils matures (`kubectl`, `git`, `gh`...), préférez la CLI directe — les LLMs les maîtrisent parfaitement et ça évite de charger un MCP +4. **`/context` pour auditer** : Identifiez ce qui consomme et désactivez les MCPs non utilisés + +--- + +## :arrows_counterclockwise: Workflows multi-sessions + +### Git Worktrees : paralléliser les sessions + +Plutôt que de jongler avec des branches et du `stash`, j'utilise les **git worktrees** pour travailler sur plusieurs features en parallèle avec des sessions Claude indépendantes. + +```console +# Créer deux features en parallèle +git worktree add ../worktrees/feature-a -b feat/feature-a +git worktree add ../worktrees/feature-b -b feat/feature-b + +# Lancer deux sessions Claude distinctes +cd ../worktrees/feature-a && claude # Terminal 1 +cd ../worktrees/feature-b && claude # Terminal 2 +``` + +Chaque session a son **propre contexte** et sa propre mémoire — aucune interférence entre les tâches. + +{{% notice tip "Worktree vs copie du repo" %}} +Contrairement à un `git clone` séparé : +- **Historique partagé** : Un seul `.git`, les commits sont immédiatement visibles partout +- **Espace disque** : ~90% d'économie (pas de duplication des objets git) +- **Branches synchronisées** : `git fetch` dans un worktree met à jour tous les autres +{{% /notice %}} + +Lorsque le changement est terminé (PR mergée), il suffit de retourner dans le repo principal et de faire le ménage. + +```console +cd +git worktree remove ../worktrees/feature-a +git branch -d feat/feature-a # après merge de la PR +``` + +**Commandes utiles :** + +```console +git worktree list # Voir tous les worktrees actifs +git worktree prune # Nettoyer les références orphelines +``` + +### Pattern Writer/Reviewer + +Un pattern que j'utilise de plus en plus consiste à lancer **deux sessions en parallèle** : + +| Session | Rôle | Prompt | +|---------|------|--------| +| **Writer** | Implémente le code | "Implémente la feature X selon la spec" | +| **Reviewer** | Review le code | "Review les changements sur la branche feat/X, vérifie la sécurité et les edge cases" | + +Le reviewer travaille sur le même repo (via worktree ou en lecture seule) et fournit un feedback indépendant, sans le biais de l'auteur. C'est particulièrement efficace pour les changements d'infrastructure où une erreur peut coûter cher. + +### Fan-out avec `-p` + +Le flag `-p` (prompt non-interactif) permet d'exécuter Claude en mode **headless** et de paralléliser les tâches : + +```bash +# Lancer 3 tâches en parallèle +claude -p "Ajoute des tests unitaires pour le module auth" & +claude -p "Documente l'API REST du service orders" & +claude -p "Refactore le module billing pour utiliser le nouveau SDK" & +wait +``` + +Chaque instance a son propre contexte. C'est idéal pour les tâches indépendantes qui ne nécessitent pas d'interaction. + +--- + +## :desktop_computer: Workflow hybride IDE + Claude Code + +C'est l'approche que j'utilise au quotidien : **Cursor** pour l'édition et la visualisation, **Claude Code** pour les tâches agentiques dans le terminal. + +{{< img src="cursor+claude.png" alt="Cursor + Claude Code" width="1000" >}} + +| Besoin | Outil | Pourquoi | +|--------|-------|----------| +| Édition rapide, autocomplete | Cursor | Latence minimale, vous restez dans le flow | +| Refactoring, debugging multi-fichiers | Claude Code | Raisonnement profond, boucles autonomes | + +**Le vrai gain** : Claude modifie via le terminal, et je valide les diffs dans l'interface Cursor — bien plus lisible que `git diff`. Les changements apparaissent en temps réel dans l'éditeur, ce qui permet de suivre ce que Claude fait et d'intervenir rapidement si quelque chose ne va pas. + +--- + +## :electric_plug: Plugins + +Claude Code dispose d'un écosystème de **plugins** qui étendent ses capacités. Voici les deux que j'utilise au quotidien : + +### Code-Simplifier : nettoyer le code généré + +Le plugin **[code-simplifier](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier)** est développé par Anthropic et utilisé en interne par l'équipe Claude Code. Il nettoie automatiquement le code généré par l'IA tout en préservant la fonctionnalité. + +J'utilise systématiquement le code-simplifier **avant de créer une PR** après une session intensive. Il tourne sur Opus et peut significativement réduire la dette technique introduite par le code IA — code dupliqué, structures inutilement complexes, style incohérent. + +### Claude-Mem : mémoire persistante entre sessions + +Le plugin **[claude-mem](https://github.com/thedotmack/claude-mem)** capture automatiquement le contexte de vos sessions et le réinjecte dans les sessions futures. Plus besoin de réexpliquer votre projet à chaque nouvelle conversation. + +**Ce que j'apprécie particulièrement :** +- **Capture automatique** : Enregistre les actions Claude (tool usage, décisions) +- **Recherche sémantique** : Skill `mem-search` pour retrouver des informations passées +- **Interface web** : Dashboard sur `http://localhost:37777` +- **Workflow 3-layer** : Optimise la consommation de tokens (~10x d'économie) + +Exemples d'utilisation : + + - "Search my memories for when I debugged Karpenter" + - "Find what I learned about OpenBao PKI last week" + - "Look up my previous work on the App composition" + +{{% notice warning "Considérations de confidentialité" %}} +Claude-mem stocke localement les données de session. Pour les projets sensibles, utilisez les tags `` pour exclure des informations de la capture. +{{% /notice %}} + +--- + +## :warning: Anti-patterns + +Après plusieurs mois d'utilisation, voici les pièges dans lesquels je suis tombé — et que j'ai appris à éviter : + +| Anti-pattern | Symptôme | Solution | +|--------------|----------|----------| +| **Kitchen sink session** | Mélanger debugging, feature, refactoring dans une même session | `/clear` entre chaque tâche distincte | +| **Spirale de corrections** | Claude corrige un bug, en crée un autre, boucle sans fin | Arrêter, `/clear`, reformuler avec plus de contexte | +| **CLAUDE.md obèse** | Context consommé dès le départ, réponses dégradées | Viser ~500 lignes, déplacer le reste vers les Skills | +| **Trust-then-verify gap** | Accepter le code sans review, découvrir les bugs en prod | Toujours lire le diff avant de commit | +| **Exploration infinie** | Claude parcourt tout le codebase au lieu d'agir | Donner des fichiers/chemins précis dans le prompt | + +{{% notice tip "Le piège le plus insidieux" %}} +La **spirale de corrections** est de loin le plus dangereux. Quand Claude boucle sur un même problème après 2-3 tentatives, c'est le signe qu'il lui manque du contexte. J'ai appris à mes dépens que mieux vaut `/clear` et reformuler avec les informations manquantes plutôt que de le laisser tourner. Le coût en tokens (et en frustration) est exponentiel. +{{% /notice %}} + +--- + +## :bulb: Ce qui fonctionne bien vs vigilance + +| Ce que Claude fait bien | Vigilance requise | Pourquoi | +|------------------------|--------------------|---------:| +| Debugging avec contexte | Création from scratch | Sans contexte existant, les hallucinations augmentent | +| Conversion de formats | Sécurité / PKI | Les erreurs crypto sont silencieuses et critiques | +| Refactoring répétitif | Ressources cloud coûteuses | Un `apply` mal placé peut coûter cher | +| Analyse de dépendances | Breaking changes | Claude ne connaît pas vos contrats implicites | +| Génération de tests | Tests de performance | Les benchmarks nécessitent une validation humaine | +| Documentation technique | Choix d'architecture | Les décisions structurantes méritent un HITL | + +--- + +## :gear: Intégration CI/CD + +Claude Code s'intègre dans les pipelines CI/CD grâce au mode headless et à l'action GitHub officielle. C'est là que l'investissement dans les Skills et CLAUDE.md paye : les mêmes conventions que vous utilisez en local sont appliquées automatiquement en CI. + +### GitHub Actions : `claude-code-action` + +L'action [claude-code-action](https://github.com/anthropics/claude-code-action) permet d'automatiser des workflows directement dans GitHub : + +```yaml +name: Claude Code Review +on: + pull_request: + types: [opened, synchronize] + +jobs: + review: + runs-on: ubuntu-latest + steps: + - uses: anthropics/claude-code-action@v1 + with: + anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} + prompt: | + Review this PR for: + - Security vulnerabilities + - Performance issues + - Kubernetes best practices + Post your findings as PR comments. +``` + +### Mode headless pour scripts custom + +Le flag `-p` combiné avec `--output-format json` permet d'intégrer Claude dans n'importe quel script : + +```bash +# Exemple : review automatique de PR +PR_DIFF=$(gh pr diff $PR_NUMBER) +REVIEW=$(claude -p "Review ce diff pour les problèmes de sécurité : $PR_DIFF" \ + --output-format json \ + --max-turns 5) +echo "$REVIEW" | jq -r '.result' | gh pr comment $PR_NUMBER --body - +``` + +### Workflows automatisables + +| Workflow | Déclencheur | Prompt type | +|----------|-------------|-------------| +| **PR Review** | `pull_request.opened` | "Review for security, performance, K8s best practices" | +| **Issue Triage** | `issues.opened` | "Classify this issue, suggest labels and priority" | +| **Release Notes** | `release.created` | "Generate changelog from commits since last release" | +| **Security Audit** | `schedule` (cron) | "Scan for outdated dependencies and known CVEs" | + +--- + +## :checkered_flag: Conclusion + +Si je devais résumer les tips essentiels de cet article : + +- **`CLAUDE.md` concis et itéré** — c'est votre levier #1, traitez-le comme un prompt de production +- **Un hook notification** — le minimum vital pour ne pas perdre du temps à attendre +- **`/clear` entre les tâches** — la règle la plus simple et la plus impactante +- **Tool Search activé** — indispensable dès que vous avez plusieurs MCPs +- **Worktrees pour paralléliser** — une branche = une session = un contexte propre +- **Toujours lire le diff** — même quand "ça a l'air bon" + +L'IA agentique est un outil puissant, mais comme tout outil, c'est la maîtrise des bonnes pratiques qui fait la différence entre un gain réel de productivité et une perte de temps déguisée. + +{{% notice info "Retour à l'article 1" %}} +Pour revoir les fondamentaux (boucle agentique, tokens, MCPs, Skills, Tasks) et les cas concrets de Platform Engineering, consultez [Agentic Coding : concepts et cas concrets](/fr/post/series/agentic_ai/ai-coding-agent/). +{{% /notice %}} + +--- + +## :bookmark: Références + +### Documentation officielle +- [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) — Anthropic Engineering +- [Claude Code Documentation](https://docs.anthropic.com/en/docs/claude-code) — Guide officiel +- [Hooks Documentation](https://docs.anthropic.com/en/docs/claude-code/hooks) — Configuration des hooks + +### Guides communautaires +- [How I Use Every Claude Code Feature](https://blog.sshh.io/p/how-i-use-every-claude-code-feature) — Guide complet par sshh +- [CC-DevOps-Skills](https://github.com/akin-ozer/cc-devops-skills) — 31 skills DevOps + +### Plugins et outils +- [Code-Simplifier](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier) — Nettoyage de code IA (Anthropic) +- [Claude-Mem](https://github.com/thedotmack/claude-mem) — Mémoire persistante entre sessions +- [claude-code-action](https://github.com/anthropics/claude-code-action) — GitHub Actions officielle + +### Article précédent +- [Agentic Coding : concepts et cas concrets](/fr/post/series/agentic_ai/ai-coding-agent/) — Partie 1 de la série Agentic AI diff --git a/content/fr/post/series/agentic_ai/ai-coding-tips/thumbnail.png b/content/fr/post/series/agentic_ai/ai-coding-tips/thumbnail.png new file mode 100644 index 00000000..703c8d70 Binary files /dev/null and b/content/fr/post/series/agentic_ai/ai-coding-tips/thumbnail.png differ diff --git a/layouts/partials/share.html b/layouts/partials/share.html new file mode 100644 index 00000000..ce7898d5 --- /dev/null +++ b/layouts/partials/share.html @@ -0,0 +1,16 @@ + {{- $s := T "share_on" }} +
+ {{ $s }}: + + {{ partial "sprite" (dict "icon" "bluesky") }} + + + + {{ partial "sprite" (dict "icon" "linkedin") }} + + + {{ partial "sprite" (dict "icon" "copy") }} + +
diff --git a/layouts/shortcodes/img.html b/layouts/shortcodes/img.html new file mode 100644 index 00000000..ec020f3e --- /dev/null +++ b/layouts/shortcodes/img.html @@ -0,0 +1,35 @@ +{{- $src := .Get "src" -}} +{{- $alt := .Get "alt" | default "" -}} +{{- $width := .Get "width" -}} +{{- $cap := .Get "caption" -}} + +{{- /* Get the image resource for proper figure/picture structure */ -}} +{{- $image := "" -}} +{{- if .Page.Resources -}} + {{- $image = .Page.Resources.GetMatch $src -}} +{{- end -}} + +
+ + {{ $alt }} + + {{- with $cap }} +
{{ . | markdownify }}
+ {{- end }} +
diff --git a/themes/hugo-clarity b/themes/hugo-clarity index 174a5e63..ea273fa2 160000 --- a/themes/hugo-clarity +++ b/themes/hugo-clarity @@ -1 +1 @@ -Subproject commit 174a5e638704181c744934b75c327c665844ab04 +Subproject commit ea273fa2d87ca56c9b2a62be3b4482df952b5f21