YAGNI dans le développement d'applications : ce que c'est, l'essence du principe et l'avantage pratique

Qu'est-ce que YAGNI ?

YAGNI (You Aren't Gonna Need It) — un principe de programmation extrême (XP) qui signifie « vous n'en aurez pas besoin ». La règle dit : n'implémentez jamais une fonctionnalité qui n'est pas requise par les user stories actuelles. Si une fonctionnalité n'est pas nécessaire aujourd'hui — ne la faites pas, même « au cas où ».

Le terme a été inventé par Ron Jeffries, l'un des co-auteurs de la méthodologie XP (avec Kent Beck). Jeffries déclarait : « Implémentez la chose la plus simple qui fonctionne, et n'ajoutez rien jusqu'à ce que ce soit nécessaire ». YAGNI n'est pas une interdiction de planifier, mais une interdiction d'implémentation prématurée.

Selon le Standish Group CHAOS Report (2023), 64% des fonctionnalités d'un produit logiciel moyen sont rarement ou jamais utilisées. En extrapolant à une application mobile — plus de la moitié du code écrit n'apporte pas de valeur à l'utilisateur. YAGNI empêche ce gaspillage de ressources.

Appliquez YAGNI comme un filtre strict : chaque fonctionnalité doit répondre à la question « quel problème spécifique d'utilisateur résout-elle maintenant ? » S'il n'y a pas de réponse — la fonctionnalité n'est pas nécessaire.

Différence entre YAGNI et la paresse ou les raccourcis

YAGNI n'est pas un rejet de l'architecture de qualité. YAGNI interdit d'écrire du code inutile, mais n'interdit pas d'écrire du code correct. Si une fonctionnalité actuelle a besoin d'une couche d'abstraction propre — créez-la. Si la couche n'est pas nécessaire — ne la créez pas. Différence clé : YAGNI concerne la fonctionnalité, pas la qualité.

Les développeurs confondent souvent YAGNI avec l'accumulation intentionnelle de dette technique (la dette technique est toujours un compromis, YAGNI est un principe d'efficacité). La différence est que la dette technique est reconnue et documentée, tandis que violer YAGNI est simplement du travail supplémentaire.

Demandez-vous : « Si je ne crée pas cette abstraction maintenant, combien de temps prendra le refactoring quand elle sera nécessaire ? » Si le temps de refactoring est inférieur au temps d'écriture maintenant — reportez-le.

Pourquoi YAGNI est-il crucial pour les projets mobiles ?

Le développement mobile est particulièrement sensible aux violations de YAGNI pour trois raisons : la taille de l'APK/IPA affecte directement le taux de conversion d'installation, le temps de compilation des projets mobiles croît linéairement avec le volume de code, et chaque fonctionnalité supplémentaire ajoute des points de défaillance. YAGNI n'est pas une question de paresse, mais de concentration.

Une étude de Google Play Console Data (2023) a montré : chaque 10 Mo de taille d'APK réduit la probabilité d'installation de 1,2%. Le code inutilisé n'est pas seulement un déchet dans le dépôt — c'est une perte financière directe. Les bibliothèques supplémentaires (pour des fonctionnalités qu'on « ajoutera peut-être plus tard ») sont la source la plus courante de gonflement de l'APK.

Selon le Gradle Build Performance Report (2024), chaque module supplémentaire dans un projet Android augmente le temps de construction complet de 3–7 secondes. Si vous ajoutez 5 modules « au cas où » — l'augmentation du temps de construction sera de 15–35 secondes par construction. Sur un an, une équipe de 5 développeurs perd jusqu'à 200 heures-homme à attendre la compilation.

Surveillez la taille du binaire dans l'IC : définissez une limite d'avertissement (par exemple, +500 Ko par commit). Si la taille a augmenté sans nouvelle fonctionnalité — c'est une violation de YAGNI qui doit être discutée en revue de code.

YAGNI vs le gold-plating : exemples pratiques

Gold-plating : animation prématurée

Le gold-plating — l'ajout de fonctionnalités au-delà des exigences pour « améliorer » le produit. Un exemple typique : un développeur ajoute une animation de transition complexe entre les écrans, alors que le design spécifie un simple fondu. L'animation prend 2 jours, l'utilisateur ne la remarque pas, et les bogues sur différents appareils poursuivent le projet pendant des années.

Selon le UX Collective Annual Report (2023), 78% des utilisateurs évaluent une application par sa vitesse et sa stabilité, pas par ses animations. YAGNI dit : si l'animation n'est pas spécifiée dans les exigences — ne l'implémentez pas. Le concepteur ajoutera l'animation quand elle sera réellement nécessaire pour résoudre un problème d'UX.

Implémentez seulement ce qui est dans les maquettes. Si le concepteur n'a pas dessiné d'animation — elle ne doit pas exister. Tout écart par rapport à la maquette est une violation de YAGNI.

Localisation prématurée en 20 langues

Une erreur courante des startups : intégrer immédiatement le support de 20+ langues « pour la future entrée sur le marché international ». YAGNI recommande : localisez uniquement dans la langue du marché actuel. L'ajout de chaque nouvelle langue nécessite du temps de traducteurs, des tests de troncature des chaînes et du débogage des dispositions RTL.

Selon le Deloitte Digital Globalization Survey (2022), 60% des applications mobiles ne quittent jamais leur premier marché. Si c'est votre cas — les ressources consacrées au support multilingue sont gaspillées. Approche YAGNI : anglais (base) + langue du marché cible. Les autres — au fur et à mesure que vous entrez réellement dans une région.

Utilisez YAGNI pour prioriser : si une fonctionnalité n'est pas dans la feuille de route des deux prochains trimestres — ne la commencez pas. La feuille de route doit être documentée et approuvée par le chef de produit.

Comment appliquer YAGNI dans Android et iOS ?

YAGNI dans Android : n'ajoutez pas de bibliothèques inutiles

Les projets Android souffrent d'inflation de bibliothèques. Les développeurs ajoutent Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — avant même d'avoir écrit la première ligne de logique métier. YAGNI recommande : ajoutez les bibliothèques selon les besoins réels, pas de manière préventive.

// Violation de YAGNI : inclusion préventive de bibliothèques
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Et l'application affiche simplement "Hello World"

Les bibliothèques sont des dépendances avec leur propre complexité. Chacune nécessite des mises à jour de version, une migration lors de changements cassants et augmente la taille de l'APK. Ajoutez une bibliothèque lorsqu'une tâche spécifique apparaît que cette bibliothèque résout. Commencez par OkHttp (client HTTP minimal), ajoutez Retrofit quand vous avez besoin d'un client REST, et ainsi de suite.

YAGNI dans iOS : ne forcez pas SwiftUI

SwiftUI est un framework puissant, mais son adoption doit être motivée par des besoins réels. Si un projet démarre avec iOS 14+ et que les exigences en composants d'interface personnalisés sont minimales — SwiftUI est un bon choix. Si un projet doit supporter iOS 13 ou nécessite des gestes personnalisés complexes — UIKit reste la solution appropriée. YAGNI est contre la migration vers SwiftUI « parce que c'est à la mode ».

// YAGNI : utilisez UIKit tant qu'il n'y a pas de bénéfice réel de SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// Si SwiftUI est nécessaire — intégrez-le via UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

L'analyse de Point-Free : « SwiftUI vs UIKit Decision Guide » (2024) recommande : ne migrez pas les écrans UIKit existants vers SwiftUI sans une raison métier claire (par exemple, le besoin de Live Preview pour le designer). Réécrire du code qui fonctionne est une violation directe de YAGNI. SwiftUI — pour les nouveaux écrans, UIKit — pour les existants.

Erreurs typiques en suivant YAGNI

YAGNI comme excuse pour une mauvaise architecture

L'erreur la plus dangereuse est d'utiliser YAGNI comme excuse pour une mauvaise architecture. « Nous ne créerons pas de couche de référentiel parce que YAGNI — nous écrirons la requête directement dans le ViewModel ». Ce n'est pas YAGNI, c'est accumuler de la dette technique. YAGNI interdit les fonctionnalités inutiles, pas l'intégrité architecturale.

L'architecture est un investissement dans la maintenabilité. Si vous écrivez plus de 3 écrans — une couche architecturale de base (MVVM, référentiel) est déjà justifiée. Si c'est 1 écran — vous pouvez vous permettre une approche plus simple. La clé : déterminez le minimum architectural nécessaire pour les fonctionnalités actuelles, et n'ajoutez pas plus.

Séparez les décisions en « architecturales » et « fonctionnelles ». Les décisions architecturales (couches, navigation, DI) ne sont pas couvertes par YAGNI — elles sont nécessaires à la maintenabilité. Les décisions fonctionnelles (fonctionnalités, captures d'écran, animations) — le sont.

Suivre YAGNI aveuglément lors du travail avec les API

Un autre extrême — ignorer les contrats d'API futurs. Un développeur reçoit un JSON du backend avec 5 champs et n'en analyse que 3, parce que « les autres ne sont pas nécessaires selon YAGNI ». Le problème : lors de l'ajout d'un champ, le backend pourrait casser l'analyse si la réponse a changé. La solution est de mapper tous les champs de la réponse, même s'ils ne sont pas tous utilisés maintenant.

Selon les Meta API Design Guidelines (2023), le client doit analyser tous les champs renvoyés par le serveur, en ignorant les inutilisés, mais sans jeter toute la structure. YAGNI ici concerne autre chose : n'ajoutez pas le traitement de champs qui ne sont pas encore dans la spécification « au cas où le backend les renverrait ».

Analysez toute la structure de la réponse (tous les champs que le serveur renvoie actuellement). N'ajoutez pas le traitement de champs qui ne sont pas dans la spécification actuelle de l'API. C'est un équilibre entre YAGNI et la résilience au changement.