🚫
methodologie

YAGNI

Principe "You Aren't Gonna Need It" : ne pas implémenter une fonctionnalité tant qu'elle n'est pas nécessaire.

Qu'est-ce que le principe YAGNI ?

YAGNI (You Aren't Gonna Need It) est un principe de l'Extrême Programming (XP) qui stipule qu'un développeur ne devrait pas ajouter de fonctionnalité tant qu'elle n'est pas reellement nécessaire. Le principe s'oppose à la tendance naturelle des développeurs à anticiper les besoins futurs et à construire des solutions génériques "au cas ou". L'expérience montre que les fonctionnalités anticipees sont rarement nécessaires telles qu'imaginees.

Pourquoi YAGNI est important

Les fonctionnalités speculatives ont un coût : temps de développement (écrire du code qui ne sera peut-etre jamais utilise), complexité (chaque abstraction supplémentaire rend le code plus difficile à comprendre), maintenance (le code inutilise doit quand même être maintenu, teste et mis à jour), et rigidite (une abstraction prematuree contraint les choix futurs dans la mauvaise direction). Des études suggerent que jusqu'à 64% des fonctionnalités logicielles sont rarement ou jamais utilisees.

Application pratique

YAGNI ne signifie pas "ne jamais penser au futur". Il signifie : implémentez la solution la plus simple qui fonctionne aujourd'hui. Si un besoin se presente demain, refactorisez. Exemples : ne pas créer une classe abstraite avant d'avoir au moins deux implémentations concrètes, ne pas ajouter de paramètres de configuration pour des valeurs qui ne changent jamais, ne pas implémenter un système de plugins avant d'avoir le premier plugin réel, 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 prévention de la dette technique. YAGNI dit "ne pas sur-construire", la dette technique dit "construire proprement". La résolution : écrire du code simple, propre et bien teste qui résout le problème actuel. Ce n'est pas la même chose que du code bacle. Un code simple et bien structure est plus facile à 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 complémentaire de KISS (privilegier la simplicité), DRY (mais sans abstraction prematuree), et TDD (les tests guident vers le code nécessaire, pas plus). Le Lean Software Development partage la même philosophie : eliminer le gaspillage (fonctionnalités 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 fréquentes

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 liées

Chaque semaine, le meilleur de la tech française

Tendances, salaires, outils et opportunités — directement dans votre boîte mail.

Gratuit. Desabonnement en un clic. Pas de spam.