YAGNI : pourquoi le code que vous n'écrivez pas est souvent le meilleur

YAGNI est un acronyme qui vient de l'anglais You Aren't Gonna Need It, ce qui se traduit par "vous n'en aurez pas besoin". Le principe est simple à formuler : n'implémentez une fonctionnalité que lorsqu'elle est réellement nécessaire, pas parce que vous pensez qu'elle pourrait l'être un jour.

Ce principe est issu de l'Extreme Programming (XP), popularisé par Kent Beck à la fin des années 90. Mais en 2026, il reste l'un des principes les moins appliqués dans les équipes de développement, toutes tailles confondues. Pas parce que les développeurs ne le connaissent pas. Plutôt parce qu'il va à l'encontre d'un réflexe naturel : anticiper.

Cet article ne va pas vous expliquer la définition de YAGNI en vingt paragraphes. Il va vous montrer pourquoi vous le violez probablement chaque semaine, ce que ça vous coûte vraiment, et comment changer concrètement cette habitude.

Le vrai problème : vous construisez pour un futur hypothétique

Imaginez ce scénario. Votre client vous demande un formulaire de contact. Vous commencez à coder, et au bout de dix minutes vous vous dites : "Et si demain ils veulent plusieurs types de formulaires ? Je vais faire un système générique avec des champs configurables dynamiquement."

Résultat : au lieu d'une heure de travail, vous en passez six. Vous livrez un formulaire de contact qui gère des cas d'usage qui n'existent pas. Le client, lui, attendait son formulaire depuis hier.

Ce n'est pas de la malveillance. C'est de l'optimisme mal placé. Les développeurs aiment résoudre des problèmes complexes, c'est dans leur nature. YAGNI ne cherche pas à supprimer cette capacité d'abstraction. Il cherche à la diriger vers des problèmes réels.

Le coût de cette anticipation est rarement mesuré. Pourtant, il est concret : temps de développement multiplié, surface de code à maintenir élargie, dette technique accumulée sur des fonctionnalités que personne n'utilisera jamais, et parfois une architecture qui devient difficile à faire évoluer parce qu'elle a été conçue pour un produit imaginaire.

"Always implement things when you actually need them, never when you just foresee that you need them."

Ron Jeffries, co-créateur de l'Extreme Programming

Trois situations concrètes où YAGNI est violé

1. L'abstraction prématurée

Vous avez deux endpoints API qui font des choses similaires. Plutôt que de les laisser tels quels, vous créez une couche d'abstraction générique qui pourrait gérer n'importe quel endpoint. Sauf que cette couche est maintenant couplée à des hypothèses sur des cas qui n'existent pas encore, et quand le troisième endpoint arrive, il ne rentre pas dans le moule que vous avez créé. Vous passez plus de temps à contourner votre propre abstraction qu'à écrire du code utile.

La règle de trois est un bon garde-fou ici : refactorisez quand vous avez un troisième cas réel, pas avant.

2. Les paramètres de configuration fantômes

Vous créez une fonction qui prend un paramètre options avec douze clés possibles, dont neuf ne sont jamais utilisées. Chaque clé représente une heure de conception, parfois une heure de test. Et si ce comportement change un jour, vous devrez maintenir de la logique pour des chemins de code que personne n'a jamais emprunté.

Le signe révélateur : si vous écrivez un paramètre et que vous ne pouvez pas citer un ticket, une story ou un besoin utilisateur précis qui le justifie, supprimez-le.

3. L'internationalisation "au cas où"

Votre application cible exclusivement le marché français. Votre client est une PME à Lyon. Mais vous passez deux jours à mettre en place un système i18n complet parce que "qui sait, peut-être qu'un jour ils voudront se développer en Espagne". Deux ans plus tard, l'application n'a toujours qu'une seule langue, et les fichiers de traduction sont devenus un obstacle à chaque modification d'interface.

Si l'internationalisation devient réellement nécessaire, l'ajouter à ce moment-là sera moins coûteux que de maintenir pendant deux ans une infrastructure dont personne ne se sert.

Ce que YAGNI n'est pas

YAGNI est souvent mal compris comme une invitation à écrire du code bâclé ou à ignorer la conception. Ce n'est pas le cas. Il y a une différence entre ne pas anticiper des fonctionnalités hypothétiques et ne pas se donner les moyens d'évoluer proprement.

YAGNI fonctionne main dans la main avec deux autres principes : KISS (Keep It Simple, Stupid) et DRY (Don't Repeat Yourself). Mais il a une priorité temporelle différente. DRY dit "ne répète pas ce qui existe". YAGNI dit "ne crée pas ce qui n'existe pas encore".

Pourquoi c'est difficile à appliquer en pratique

Il y a plusieurs raisons pour lesquelles même les développeurs qui connaissent YAGNI continuent à le violer.

La peur du refactoring futur

Beaucoup de développeurs anticipent parce qu'ils ont peur de devoir retoucher du code qui fonctionne. "Si je le fais bien dès maintenant, je n'aurai pas à y revenir." Sauf que "bien" selon vos hypothèses d'aujourd'hui et "bien" selon les besoins de demain sont souvent deux choses différentes. Le code qui a été sur-conçu pour un cas hypothétique est parfois plus difficile à modifier que du code simple.

La pression implicite de "faire les choses bien"

Dans certaines cultures d'équipe, ajouter une abstraction est perçu comme une preuve de maturité technique. Livrer quelque chose de simple peut être mal interprété comme un manque d'expérience. C'est un problème de culture autant que de technique. Un développeur senior qui comprend YAGNI livre souvent moins de code, pas plus.

Le biais de la familiarité

Si vous venez de passer trois jours à apprendre un nouveau pattern d'architecture, vous allez avoir envie de l'utiliser sur votre prochain projet, même si un fichier plat aurait suffi. C'est humain. La solution est de séparer l'apprentissage de l'application : apprenez les patterns, mais attendez que le problème se manifeste avant de les sortir.

Comment appliquer YAGNI concrètement au quotidien

YAGNI dans le contexte des projets avec IA en 2026

Avec la montée des outils de génération de code assistée par IA, YAGNI devient encore plus pertinent. Ces outils sont particulièrement doués pour produire des structures complètes, des abstractions élaborées, des systèmes configurables à souhait. En quelques secondes, vous pouvez obtenir un code qui "couvre tous les cas".

Le problème : le code généré par l'IA souffre souvent d'un excès d'anticipation par défaut. Il est conçu pour être générique et réutilisable, ce qui va à l'encontre de YAGNI. Ce n'est pas un défaut de l'outil, c'est un comportement à corriger côté humain : guidez les prompts vers le minimum viable, pas vers la solution universelle.

Si vous utilisez GitHub Copilot, Cursor ou un assistant similaire au quotidien, prenez l'habitude de revoir ce qui est généré sous cet angle. Supprimez les paramètres optionnels non utilisés. Simplifiez les classes qui contiennent des méthodes que personne n'appelle. Le gain de productivité offert par ces outils est réel, mais il peut se retourner contre vous si vous acceptez tout ce qu'ils produisent sans filtre.

Un exemple de refactoring guidé par YAGNI

Voici un exemple typique de code qui viole YAGNI :

class UserNotifier {
  constructor(options = {}) {
    this.channel = options.channel || 'email';
    this.template = options.template || 'default';
    this.locale = options.locale || 'fr';
    this.retryCount = options.retryCount || 3;
    this.batchSize = options.batchSize || 100;
    this.priority = options.priority || 'normal';
  }

  notify(user, message) {
    // Logique complexe tenant compte de tous les paramètres
  }
}

Si votre application n'envoie que des emails en français avec un template fixe, voici ce que YAGNI recommande :

class UserNotifier {
  notify(user, message) {
    sendEmail(user.email, message);
  }
}

Si dans trois mois vous devez ajouter les notifications SMS, vous l'ajouterez à ce moment-là. Avec une base simple, ce changement prendra une heure. Avec la version sur-conçue, vous passerez la matinée à comprendre comment le code existant gère les cas que vous n'aviez pas prévus.

Ce que vous gagnez vraiment à appliquer YAGNI

Les bénéfices de YAGNI ne sont pas abstraits. Ils se mesurent concrètement :

Ces gains ne sont pas automatiques. Ils dépendent d'une application cohérente et disciplinée, soutenue par des tests et de bonnes pratiques de base. YAGNI sans tests, c'est de la négligence. YAGNI avec tests, c'est de l'efficacité.

FAQ