Garder le code simple

Le problème : l'IA en fait toujours trop

Vous demandez à l'IA une fonction qui additionne deux nombres. Vous récupérez une classe Calculator avec une interface OperationStrategy, un système de plugins, une gestion d'erreurs pour le cas où l'un des arguments serait un objet exotique, et un fichier de config YAML « au cas où ». Vous vouliez a + b.

C'est le défaut numéro un de l'IA : la sur-ingénierie. Elle a vu des millions de bases de code « entreprise » bourrées d'abstractions, alors elle pense qu'un bon code, c'est un code compliqué. Elle ajoute des couches, anticipe des besoins imaginaires, gère des cas impossibles. Plus c'est gros, plus elle se croit utile.

Or, dans la vraie vie, le code simple gagne presque toujours. Il est plus rapide à lire, plus facile à corriger, et il casse moins. Votre travail de pilote de l'IA, c'est de la ramener vers la simplicité : parce qu'elle n'y va jamais seule.

Trois acronymes, une boussole

Trois principes vieux comme le métier suffisent à recadrer une IA trop ambitieuse :

• KISS : Keep It Simple, Stupid. La solution la plus simple qui résout le problème est presque toujours la bonne. Pas la plus impressionnante : la plus simple.
• DRY : Don't Repeat Yourself. Ne dupliquez pas la logique métier. Mais attention : trois lignes presque identiques valent mieux qu'une mauvaise abstraction qui les force à tenir dans le même moule. On abstrait quand le pattern est clair, pas avant.
• YAGNI : You Aren't Gonna Need It. N'écrivez pas de code pour un futur hypothétique. Pas de paramètre « au cas où », pas de fonctionnalité « pour plus tard ». Quand le besoin arrivera vraiment, vous l'ajouterez.

DRY est le plus mal compris des trois. « Ne te répète pas » ne veut pas dire « abstrais tout ». Une abstraction prématurée, choisie avant de comprendre le pattern, coûte plus cher que la duplication qu'elle prétend éviter. La règle pratique : attendez la troisième occurrence avant de factoriser.

Avant / après : l'IA dorée vs la simple

Voici ce que l'IA produit spontanément quand on lui demande de valider qu'un nombre est positif :

// AVANT : sur-ingénierie typique de l'IA
class NumberValidator {
    constructor(options = {}) {
        this.strict = options.strict ?? true;
        this.allowZero = options.allowZero ?? false;
        this.rules = options.rules || [];
    }

    validate(value) {
        if (typeof value !== 'number' || Number.isNaN(value)) {
            throw new ValidationError('Not a number', { value });
        }
        for (const rule of this.rules) {
            if (!rule(value)) return false;
        }
        return this.allowZero ? value >= 0 : value > 0;
    }
}

const validator = new NumberValidator({ allowZero: false });
const ok = validator.validate(amount);

Et voici la même chose, ramenée à ce dont le projet a réellement besoin :

// APRÈS : la solution la plus simple qui marche
function isPositive(value) {
    return value > 0;
}

const ok = isPositive(amount);

La version « après » se lit en une seconde, ne casse jamais, et fait exactement le travail demandé. Le système de règles, les options de config et la classe d'erreur custom répondaient à des besoins que personne n'avait. Le jour où il faudra autoriser zéro, on ajoutera >= 0 : pas avant.

Prompter pour la simplicité

La simplicité ne vient pas toute seule : il faut l'exiger explicitement. Glissez ces consignes dans vos prompts (ou directement dans votre CLAUDE.md) :

• « Donne-moi la solution la plus simple qui marche. »
• « Pas d'abstraction prématurée. »
• « Ne gère que les cas réels, pas les cas hypothétiques. »
• « Pas de config ni de paramètre dont je n'ai pas besoin maintenant. »

Et quand l'IA en a quand même trop fait (ce qui arrivera) n'hésitez pas à lui demander de couper : « C'est trop compliqué pour le besoin. Simplifie, retire tout ce qui ne sert pas le cas réel. » L'IA est très douée pour dégraisser son propre code quand on le lui ordonne. Elle ne le fera juste jamais d'elle-même.