Pragmatisme et simplicité

Le biais de l’agent : la sur-ingénierie par défaut

Un agent de code aime ajouter des pièces. Demande-lui un petit service, et il te rendra volontiers une interface, une factory, une couche d’abstraction et un pattern ou deux — même quand rien ne les réclame. Ce n’est pas de la malveillance : il a vu des milliers de codebases « propres » et reproduit leurs structures, y compris là où elles ne paient pas.

Le résultat est du code qui a l’air sérieux mais qui multiplie les indirections : plus de fichiers à ouvrir, plus de sauts pour suivre un appel, plus de surface à maintenir. La sur-ingénierie est le travers que tu auras le plus souvent à corriger chez un agent.

Point clé : par défaut, l’agent tend à en faire trop. Ton rôle n’est pas d’ajouter de la structure, mais d’en retirer. La question utile : « quel besoin présent cette pièce résout-elle ? »

Attention — une interface à une seule implémentation, une factory pour un seul objet, un Repository générique au-dessus d’un ORM déjà abstrait : ce sont les signatures les plus fréquentes de la sur-ingénierie générée. Elles se justifient parfois, mais jamais « par principe ».

YAGNI : tu n’en auras pas besoin

YAGNI (« You Aren’t Gonna Need It ») dit de n’écrire du code que pour un besoin avéré, jamais pour un besoin hypothétique. On n’ajoute pas une abstraction « au cas où » : la majorité de ces cas n’arrivent jamais, et le code spéculatif reste à porter pour rien.

Anticiper les évolutions futures paraît prudent, mais c’est exactement ce que YAGNI combat. Le code spéculatif vieillit mal : quand le vrai besoin apparaît, il est rarement celui qu’on avait imaginé, et l’abstraction prématurée doit de toute façon être défaite.

Point clé : la bonne abstraction est celle qu’on extrait après avoir vu le besoin se répéter, pas celle qu’on devine avant. Attends le deuxième ou le troisième cas réel.

Simplicité n’est pas facilité

Ces deux mots sont souvent confondus, et la confusion coûte cher. Ils ne mesurent pas la même chose.

Le piège : ce qui est facile maintenant fabrique souvent de la complexité plus tard. Un raccourci commode aujourd’hui se paie en pièces enchevêtrées demain. On vise le simple, même quand il demande un peu plus de réflexion sur le moment.

Attention — « rapide à écrire » n’est pas « simple ». L’agent excelle à produire du code facile (vite généré) qui n’est pas simple (peu de pièces). Juge la structure, pas la vitesse de génération.

Une abstraction ne se justifie que quand elle paie son coût

Un design pattern, une interface, une couche supplémentaire : tout cela a un bénéfice et un coût. Le coût est l’indirection, la maintenance, la charge de lecture. Le bénéfice n’existe que face à un besoin concret : substituer une implémentation, isoler un domaine riche, tester un point précis.

« C’est une bonne pratique » ne suffit pas à prouver qu’une abstraction est rentable ici. La seule question valable : le bénéfice présent dépasse-t-il le coût présent ? Si la réponse est « pas encore », on s’abstient.

Point clé : une abstraction se mérite. Tant qu’il n’y a qu’une implémentation et aucun besoin de substitution, l’interface n’achète rien — elle ne fait qu’ajouter un saut.

// Sur-conception : interface + factory pour un seul calcul
public interface ITaxCalculator { decimal Compute(decimal amount); }
public class TaxCalculatorFactory { /* ... */ }

// Simple : la logique, directement, jusqu'a preuve d'un vrai besoin
public static class Tax
{
    public static decimal Compute(decimal amount) => amount * 0.20m;
}

Le modèle anémique et la sur-modélisation comme symptômes

Deux excès opposés trahissent le même manque de jugement. Le modèle anémique : l’agent produit des classes de getters/setters et range toute la logique dans des services à côté. Sur un domaine à vraies règles, le modèle ne protège plus ses invariants et la logique se disperse. La sur-modélisation : tout devient aggregate, value object et event, même un CRUD sans règle métier.

La posture saine n’est ni l’un ni l’autre dogme. C’est le jugement au cas par cas : modèle riche là où il y a de la complexité métier réelle, simplicité partout ailleurs. Un DTO reste un DTO.

Attention — corriger l’anémie en sur-modélisant tout est aussi faux que l’anémie elle-même. On remplace alors un excès par un autre. La simplicité, ce n’est pas « zéro structure », c’est « la juste structure ».

Guider l’agent vers la simplicité

Le biais de sur-ingénierie vient du contexte que l’agent perçoit, pas de la puissance brute du modèle. On le corrige donc là où l’agent regarde : ses instructions persistantes et les exemples de code existants qu’il prend comme patron.

Inscrire une règle de pragmatisme dans le CLAUDE.md (YAGNI, pas d’interface à une seule implémentation sauf besoin réel) et l’ancrer par du code simple déjà présent dans le projet oriente ses générations bien plus durablement qu’une correction manuelle répétée. C’est la même pédagogie qu’avec un junior : la convention et l’exemple, pas le reproche.

Point clé : avant d’orchestrer cinq agents, vérifie qu’un seul, bien briefé, ne suffit pas. La complexité a un coût — côté code comme côté orchestration.