🚫
methodologie

YAGNI

Principe "You Aren't Gonna Need It" : ne pas implementer une fonctionnalite tant qu'elle n'est pas necessaire.

Qu'est-ce que le principe YAGNI ?

YAGNI (You Aren't Gonna Need It) est un principe de l'Extreme Programming (XP) qui stipule qu'un developpeur ne devrait pas ajouter de fonctionnalite tant qu'elle n'est pas reellement necessaire. Le principe s'oppose a la tendance naturelle des developpeurs a anticiper les besoins futurs et a construire des solutions generiques "au cas ou". L'experience montre que les fonctionnalites anticipees sont rarement necessaires telles qu'imaginees.

Pourquoi YAGNI est important

Les fonctionnalites speculatives ont un cout : temps de developpement (ecrire du code qui ne sera peut-etre jamais utilise), complexite (chaque abstraction supplementaire rend le code plus difficile a comprendre), maintenance (le code inutilise doit quand meme etre maintenu, teste et mis a jour), et rigidite (une abstraction prematuree contraint les choix futurs dans la mauvaise direction). Des etudes suggerent que jusqu'a 64% des fonctionnalites logicielles sont rarement ou jamais utilisees.

Application pratique

YAGNI ne signifie pas "ne jamais penser au futur". Il signifie : implementez la solution la plus simple qui fonctionne aujourd'hui. Si un besoin se presente demain, refactorisez. Exemples : ne pas creer une classe abstraite avant d'avoir au moins deux implementations concretes, ne pas ajouter de parametres de configuration pour des valeurs qui ne changent jamais, ne pas implementer un systeme de plugins avant d'avoir le premier plugin reel, ne pas construire une API RESTful si un simple rendu serveur suffit.

YAGNI et dette technique

Il y a une tension apparente entre YAGNI et la prevention de la dette technique. YAGNI dit "ne pas sur-construire", la dette technique dit "construire proprement". La resolution : ecrire du code simple, propre et bien teste qui resout le probleme actuel. Ce n'est pas la meme chose que du code bacle. Un code simple et bien structure est plus facile a refactorer plus tard qu'un code sur-ingenierie. La bonne architecture emerge progressivement du refactoring, pas de la speculation.

Relations avec d'autres principes

YAGNI est complementaire de KISS (privilegier la simplicite), DRY (mais sans abstraction prematuree), et TDD (les tests guident vers le code necessaire, pas plus). Le Lean Software Development partage la meme philosophie : eliminer le gaspillage (fonctionnalites inutiles, code mort). L'approche agile favorise les iterations courtes et le feedback rapide, ce qui rend YAGNI naturel : on livre le minimum viable, on observe, on ajuste.

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

YAGNI ne risque-t-il pas de produire un code de mauvaise qualite ?
Non, YAGNI concerne les fonctionnalites et abstractions inutiles, pas la qualite du code. Ecrire du code simple, lisible et teste est tout a fait compatible avec YAGNI. La qualite du code (nommage, structure, tests) n'est jamais du gaspillage. Ce qui est du gaspillage, c'est une architecture de plugins pour une application qui n'aura jamais de plugin.
Comment distinguer une anticipation utile d'une violation de YAGNI ?
Posez-vous la question : "ai-je un besoin concret et immediat pour cette fonctionnalite ?" Si oui, implementez-la. Si c'est "au cas ou" ou "on en aura probablement besoin", c'est YAGNI. Les exceptions : les decisions difficiles a changer (choix de base de donnees, API publique) meritent plus de reflexion en amont. Les decisions faciles a changer (structure du code, abstractions internes) peuvent etre differees.

Pages liees

Chaque semaine, le meilleur de la tech francaise

Tendances, salaires, outils et opportunites — directement dans votre boite mail.

Gratuit. Desabonnement en un clic. Pas de spam.