Mon processus de controle qualite avec Claude Code

Pourquoi se preoccuper du controle qualite en programmation IA ?

En utilisant Claude Code pour la programmation assistee par IA, j'ai constate un phenomene important : bien que Claude Code puisse multiplier la vitesse de developpement par 2 a 3, ce gain d'efficacite apporte egalement de nouveaux defis — le code genere par l'IA necessite des controles et un suivi qualite plus rigoureux.

Sans un processus de controle qualite adequat, ma productivite avec Claude Code diminuait en realite a cause du debogage et du refactoring frequents.

Cela m'a amene a un principe fondamental : les resultats de l'IA doivent etre verifies, et non acceptes aveuglement.

Apres six mois de pratique et d'optimisation, j'ai mis en place un systeme complet d'assurance qualite. Je vais maintenant partager mon processus de controle qualite — un processus en couches allant des verifications automatisees a la revue manuelle. Ce systeme est progressif — vous pouvez commencer par les bases et l'enrichir progressivement selon vos besoins.

Si vous n'etes pas encore familier avec les bases de Claude Code, consultez d'abord Les 10 meilleures pratiques pour Claude Code pour decouvrir le flux de travail fondamental.

Avant de commencer : deux preparations pour des verifications plus fluides

Avant d'entrer dans le processus de verification concret, deux preparations rendront les controles qualite ulterieurs bien plus efficaces.

Organiser le code par fonctionnalite

L'organisation du code d'un projet offre generalement deux approches : par couche technique (architecture en couches) ou par fonctionnalite metier (organisation par fonctionnalite). Dans le contexte de la programmation assistee par IA, j'ai opte pour la seconde :

Architecture en couches

src/
├── routers/        # 所有路由/API 端点
├── services/       # 所有业务逻辑
├── repositories/   # 所有数据访问
└── models/         # 所有数据模型

Architecture organisee par fonctionnalite

src/
├── user/
│   ├── __init__.py        # Python 包标识
│   ├── router.py          # FastAPI 路由定义
│   ├── service.py         # 业务逻辑
│   ├── models.py          # 数据库模型（SQLAlchemy）
│   ├── schemas.py         # Pydantic 数据验证
│   └── CLAUDE.md          # 模块特定规范
└── order/
    ├── __init__.py
    ├── router.py
    ├── service.py
    ├── models.py
    └── schemas.py

Pourquoi l'organisation par fonctionnalite est-elle plus adaptee a l'IA ?

Prenons un exemple : lorsque je demande a Claude de modifier la fonctionnalite d'avis, avec une architecture en couches, il doit lire separement routers/review.py, services/review_service.py, models/review_model.py, et possiblement schemas/review_schema.py — soit au moins 4 fichiers dans des repertoires differents. Avec une organisation par fonctionnalite, tous les fichiers pertinents se trouvent dans le repertoire src/review/, permettant a l'IA de comprendre l'ensemble du contexte du module en une seule fois.

De plus, chaque module peut disposer de son propre CLAUDE.md, definissant les regles et contraintes specifiques a ce module. Cela permet a l'IA de s'adapter automatiquement aux differentes conventions de developpement lorsqu'elle passe d'un module a l'autre.

Unifier les points d'entree avec les commandes Make

Pour chaque nouveau projet, la premiere chose que je fais est de creer un Makefile. Pourquoi ?

Lorsque l'IA vous aide a ecrire du code, elle a besoin de connaitre les "regles" du projet. Plutot que de dire a chaque fois a Claude "veuillez executer ruff check && mypy . && pytest", il suffit de dire "executez make check".

Voici mon modele de Makefile de base :

.PHONY: help setup dev run stop format check test clean

help: ## 显示帮助信息
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "  %-15s %s\n", $$1, $$2}'

setup: ## 初始化开发环境（安装依赖 + git hooks）
	@echo "📦 Installing dependencies..."
	uv sync
	@echo "🔧 Installing pre-commit hooks..."
	uv run pre-commit install

dev: ## 本地开发模式（支持热重载）
	@echo "🚀 Starting dev server with hot reload..."
	uvicorn main:app --reload --host 0.0.0.0 --port 8000

run: ## 生产模式（多 worker）
	@echo "🚀 Starting production server..."
	uvicorn main:app --workers 4 --host 0.0.0.0 --port 8000

stop: ## 停止后台运行的服务
	@echo "🛑 Stopping server..."
	# 停止服务的逻辑

format: ## 格式化代码
	@echo "🎨 Formatting code..."
	black .
	ruff check --fix .

check: ## 代码检查 + 类型检查 + 测试
	@echo "🔍 Checking code..."
	ruff check .
	mypy .
	pytest

test: ## 运行测试
	@echo "🧪 Running tests..."
	pytest

clean: ## 清理缓存文件
	@echo "🧹 Cleaning up..."
	find . -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null || true
	find . -type d -name ".pytest_cache" -exec rm -rf {} + 2>/dev/null || true

Pourquoi cette approche est-elle efficace ?

1. Une interface de commandes unifiee : quel que soit la pile technologique du projet, make format et make test fonctionnent toujours
2. Compatible avec l'IA : Claude retient et utilise plus facilement ces commandes concises
3. Normes imposees : les membres de l'equipe (ou votre futur vous-meme) savent quelles commandes executer

Cette standardisation simple reduit les communications repetitives et s'avere particulierement efficace pour le developpement assiste par IA.

Le processus complet de controle qualite en programmation IA

Premiere ligne de defense : verifications automatiques via les Hooks

Dans le processus de controle qualite de Claude Code, la brique la plus fondamentale est la verification automatisee.

Chaque fois que Claude termine l'ecriture du code, le Hook que j'ai configure execute automatiquement le formatage :

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "make format",
        "timeout": 60
      }]
    }]
  }
}

Cela garantit la coherence du style de code sans intervention manuelle.

Deuxieme ligne de defense : strategie de tests

Concernant le Mock, mon approche differe peut-etre de celle de beaucoup : j'evite le Mock autant que possible.

La raison est simple : le fait qu'un test avec Mock reussisse ne signifie pas que le code fonctionnera en environnement reel. J'ai rencontre cette situation a plusieurs reprises : tous les tests unitaires etaient au vert, puis des problemes apparaissaient des la mise en production, car les Mocks masquaient les veritables cas limites. Pour le code genere par l'IA, ce probleme est encore plus prononce : l'IA a tendance a "accompagner" son propre code lors de l'ecriture des tests — elle ecrit pour que les tests passent, plutot que pour verifier reellement les cas limites. Les tests d'integration sont plus efficaces pour detecter ce type de problemes.

Bien entendu, certains scenarios necessitent imperativement le Mock : les appels a des API payantes, la logique liee au temps, les services tiers instables. Mais en dehors de ces cas, je prefere ecrire des tests d'integration.

Quant a la couverture, mon objectif est de 80 % — couvrir la logique centrale suffit, il n'est pas necessaire de viser 100 %. Lors de la modification d'un module, executer pytest tests/user/ permet une verification rapide sans attendre l'ensemble des tests.

Pour que Claude suive cette strategie de tests, j'inscris clairement les exigences dans CLAUDE.md :

## 测试规范

- 实现新功能时，先写测试，确认测试失败，再写实现代码
- 每次修改后运行 `make test` 确保没有破坏现有功能
- 不要为了让测试通过而修改测试本身
- 外部 API、时间相关逻辑使用 Mock，其他场景优先使用真实依赖

Troisieme ligne de defense : AI Review locale

Pour les modifications importantes, j'utilise les Commands de Claude Code pour effectuer une revue de code. En general, je demande a Claude de revoir les modifications d'un repertoire specifique, par exemple "revoir les modifications de src/order/ cette fois-ci", pour un contexte plus cible.

# 使用专门的审查 Commands
/code-review:code-review

Quand l'utiliser ?

• Obligatoire : modifications architecturales, nouvelles fonctionnalites, aspects lies a la securite
• Recommande : modifications importantes de la logique metier
• Optionnel : corrections de bugs mineures, simples modifications de texte

En tant que developpeur independant, je demande egalement a Claude de proceder a une revue complete d'un module de temps en temps. Cela n'est pas tres realiste dans un contexte d'equipe — apres tout, le code est ecrit par differentes personnes, et un refactoring spontane risque d'empieter sur le travail des autres. Mais en developpement independant, ce n'est pas un souci : on peut ajuster immediatement des qu'un probleme est identifie.

Quatrieme ligne de defense : Pre-commit Hook

C'est l'etape la plus cruciale — si les verifications echouent, le code ne peut tout simplement pas etre commite.

Mon approche consiste a utiliser le framework pre-commit combine avec make check. La configuration est tres simple :

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: make-check
        name: Run make check
        entry: make check
        language: system
        pass_filenames: false

Toute la logique de verification est geree de maniere centralisee dans le Makefile ; pre-commit se contente de la declencher au moment du commit.

Ensuite, on ajoute une commande setup dans le Makefile :

setup: ## 初始化开发环境
    @uv sync
    @uv run pre-commit install

Apres avoir execute make setup, chaque git commit declenchera automatiquement make check.

Pour un developpeur independant, cette etape peut etre realisee manuellement. Mais je recommande tout de meme de configurer la commande setup : ainsi, lorsque vous changez d'ordinateur ou que vous clonez a nouveau le projet, il suffit d'executer make setup pour restaurer l'environnement de developpement, sans avoir a se souvenir de toutes les etapes ou a tout reconfigurer.

Ces taches de configuration peuvent elles-memes etre confiees a Claude Code — dites-lui "configure pre-commit pour moi, avec execution de make check au moment du commit", et il generera les fichiers de configuration et les installera pour vous.

Cinquieme ligne de defense : integration GitHub

Claude Code propose une fonctionnalite d'integration GitHub qui permet de declencher automatiquement une revue de code par IA a chaque Pull Request.

Dans Claude Code, executez /install-github-app et suivez les instructions pour completer le processus d'autorisation.

Une fois l'installation terminee, vous remarquerez qu'un repertoire .github/workflows a ete ajoute au projet, contenant la configuration du flux de travail de revue de Claude.

Desormais, a chaque soumission de PR, Claude examinera automatiquement le code et laissera des commentaires sur la PR. Si vous souhaitez ajuster son style de revue ou ses points d'attention, vous pouvez modifier directement la configuration du prompt dans les workflows.

C'est le dernier verrou qualite — le code passe une derniere revue par l'IA avant d'etre fusionne, garantissant qu'aucun probleme n'a ete neglige.

Vue d'ensemble du systeme de controle qualite

Ces cinq lignes de defense constituent un systeme complet d'assurance qualite :

Ce processus de controle qualite, de l'automatisation au manuel, du local au cloud, garantit la qualite du code genere par Claude Code.

Conclusion : un systeme de controle qualite pour l'ere de l'IA

L'ere de la programmation assistee par IA est arrivee, mais le controle qualite ne sera jamais demode.

Ce processus complet de controle qualite pour Claude Code relie cinq niveaux de controle qualite pour former un systeme d'assurance qualite solide et rigoureux. Quel que soit l'outil de programmation IA que vous utilisez, la philosophie de ce controle qualite est universelle.

J'espere que ce partage detaille d'experience sur le controle qualite en programmation IA vous aidera a mettre en place un systeme d'assurance qualite adapte a vos besoins. Si vous avez des questions ou souhaitez partager votre propre experience, n'hesitez pas a laisser un commentaire !

Lectures complementaires

• Analyse complete de l'architecture systeme de Claude — Comprendre le positionnement des Hooks, Skills et autres composants dans l'architecture
• D'Eclipse a Zed : l'evolution des editeurs d'un developpeur — L'evolution du flux de travail vers des editeurs legers et une utilisation intensive du terminal
• Analyse approfondie de GSD — Une autre approche de l'assurance qualite en programmation IA basee sur les specifications