Claude Code et TDD .NET :
comment j'ai multiplié ma vélocité
sans sacrifier la qualité

Il y a 8 mois, j'étais sceptique. Pas sur l'IA en général — sur son utilisation dans un workflow TDD strict. La promesse "l'IA écrit votre code" me semblait fondamentalement incompatible avec le cycle Red/Green/Refactor. Aujourd'hui, Claude Code est intégré dans 100% de mes missions freelance. Voici pourquoi, et surtout comment.

Le malentendu fondamental sur l'IA et le TDD

La plupart des développeurs voient l'IA comme un générateur de code. Vous décrivez une fonctionnalité, l'IA produit le code, vous relisez. Résultat : du code sans tests, souvent fonctionnel en apparence, rarement correct sur les cas limites, et très difficile à maintenir six mois plus tard.

Ce modèle est effectivement incompatible avec le TDD. Mais ce n'est pas la seule façon d'utiliser Claude Code.

"L'IA n'est pas un remplaçant du développeur — c'est un multiplicateur. La question n'est pas 'que peut-elle faire à ma place ?' mais 'sur quoi puis-je me concentrer si elle gère la friction ?'"

Mon setup : CLAUDE.md comme contrat de travail

Tout commence par un fichier CLAUDE.md à la racine du projet. C'est le contrat que Claude Code signe avant de toucher une seule ligne. Les règles non-négociables :

## TDD — règles absolues
- Code-before-tests = delete (jamais de code prod sans test préalable)
- Cycle : Red → Green → Refactor, jamais court-circuité
- Préfixes de commit : red: | green: | refactor:
- Aucun mock par défaut — les tests d'intégration frappent une vraie base

## Code style
- if( pas if ( — accolades toujours obligatoires
- const/static readonly → PascalCase, champs instance → _camelCase

Avec ce contrat, Claude Code ne "génère" pas du code — il collabore selon un protocole défini. Si j'écris red: dans ma demande, il écrit des tests qui échouent. Si j'écris green:, il écrit uniquement le code minimal pour les faire passer. La discipline est structurelle, pas mémorielle.

Le flux concret sur une feature .NET

Exemple réel : l'ajout d'un endpoint POST /invoices/export dans une API ASP.NET Core. Voici le déroulé avec Claude Code :

Phase Red — les tests d'abord

Je décris le comportement attendu en langage naturel. Claude Code génère les tests xUnit qui couvrent :

// Tests générés — tous RED à ce stade
[Fact]
public async Task Handle_WhenValidRequest_ReturnsExcelFileBytes()
{
    // Arrange
    var command = new ExportInvoicesCommand(Month: 3, Year: 2026, ClientId: "CLI-001");

    // Act
    var result = await _handler.Handle(command, CancellationToken.None);

    // Assert
    result.Should().NotBeNull();
    result.FileBytes.Should().NotBeEmpty();
    result.FileName.Should().EndWith(".xlsx");
}

[Fact]
public async Task Handle_WhenNoInvoicesFound_ReturnsEmptyExcel()
{ ... }

[Fact]
public async Task Handle_WhenClientIdInvalid_ThrowsDomainException()
{ ... }

Phase Green — implémentation minimale

Claude Code implémente le handler, le service Excel et le repository — uniquement ce qui est nécessaire pour faire passer les tests. Pas de généralisation prématurée, pas de "peut-être qu'on aura besoin de X plus tard".

Phase Refactor — amélioration structurelle

C'est là que je reprends le lead. Claude Code propose des refactorings (extraction de méthode, renommage, suppression de duplication) mais c'est moi qui décide lesquels sont pertinents par rapport à la vision architecturale globale.

Ce que l'IA fait mieux que moi (honnêtement)

• Scaffolding de tests : générer les 8 cas de test d'une règle métier complexe en 30 secondes vs 20 minutes à la main
• Boilerplate infrastructure : configuration EF Core, setup de MassTransit, wiring des handlers MediatR — tout ce qui est mécanique et sans valeur cognitive
• Détection d'incohérences : Claude Code me signale quand mon test ne couvre pas le cas null, ou quand mon assertion est trop permissive
• Code review en temps réel : je lui soumets une PR imaginaire et il identifie les violations SOLID, les règles SonarQube, les patterns à risque

Ce que je ne délègue jamais à l'IA

• La modélisation du domaine : les agrégats, les value objects, les invariants — ça demande une compréhension métier que l'IA n'a pas
• Les décisions architecturales : monolithe vs microservices, synchrone vs événementiel — ces choix ont des conséquences à 3 ans
• La lecture des signaux faibles : un code qui "semble OK" mais va poser des problèmes de performance à scale — l'IA ne ressent pas ça

Résultats mesurés après 6 mois

Sur ma mission actuelle (plateforme enterprise .NET 9, équipe de 8 devs) :

• Réduction du temps de scaffolding d'environ 70% sur les features standard
• Couverture de tests maintenue à ≥85% sur les chemins critiques
• Zéro régression introduite sur les 4 derniers mois — les tests font leur travail
• Revues de code plus courtes et plus ciblées — l'IA attrape le bas niveau, je me concentre sur le haut niveau

"La vraie transformation n'est pas dans la vitesse d'écriture du code — c'est dans la qualité de l'attention. Je dépense mon énergie cognitive là où elle crée vraiment de la valeur."

Pour aller plus loin

Si vous voulez explorer cette approche sur votre propre stack .NET, les deux prérequis indispensables sont : un CLAUDE.md bien configuré avec vos conventions, et une discipline absolue sur le TDD strict avant d'introduire l'IA. L'outil amplifie vos pratiques — les bonnes comme les mauvaises.

Et si vous vous demandez comment structurer votre base de code pour que l'IA soit efficace, la réponse est invariablement : Clean Architecture. Des couches claires, des dépendances explicites, des boundaries bien définis — l'IA s'y retrouve autant que les humains.