KISS dans le développement mobile — définition, principe de simplicité et comment l’appliquer

Qu’est-ce que KISS ?

KISS (Keep It Simple, Stupid) est un principe de conception qui exige de minimiser la complexité du système. Il a été formulé dans la marine américaine dans les années 1960 par l’ingénieur Kelly Johnson (Lockheed SR-71 Blackbird). Johnson insistait pour que l’avion soit réparable par un mécanicien sur le terrain sans outils spéciaux — c’est l’essence de KISS.

Dans le développement logiciel, KISS signifie : une solution doit être aussi simple que possible, mais pas plus simple (la deuxième partie de la phrase est attribuée à Albert Einstein). La simplicité n’est pas synonyme de primitivité ; une solution simple exécute la tâche avec un minimum de redondance.

Une étude de Google Research (2022) a montré que le temps d’intégration moyen d’un nouveau développeur est de 3 semaines dans les projets respectant KISS contre 10 semaines dans les projets avec une architecture excessive. Le code simple est un investissement dans la vitesse d’adaptation des nouveaux membres de l’équipe.

Utilisez KISS comme filtre : avant d’ajouter une nouvelle abstraction, demandez-vous « est-ce que cela résout un problème qui existe aujourd’hui, ou un problème qui pourrait survenir dans un an ? » Si c’est le second cas — ne le faites pas.

KISS et le rasoir d’Occam

Le rasoir d’Occam (XIVe siècle) est un principe philosophique : « les entités ne doivent pas être multipliées sans nécessité ». En programmation, cela signifie : de deux solutions qui satisfont également aux exigences, choisissez celle qui a le moins d’entités (classes, modules, dépendances). KISS est l’implémentation pratique du rasoir d’Occam dans le code.

La différence est que le rasoir d’Occam est un principe général de la connaissance, tandis que KISS est une pratique d’ingénierie spécifique avec des résultats mesurables : réduction de la complexité cyclomatique, moins de lignes de code, temps de revue de code plus court. Les métriques permettent d’évaluer objectivement la conformité à KISS.

Suivez cette métrique : le code est considéré comme « suffisamment simple » si un nouveau développeur comprend le fragment en une minute sans commentaires. Si plus de temps est nécessaire — simplifiez.

Pourquoi la simplicité est-elle cruciale dans le développement mobile ?

Le développement mobile a trois caractéristiques qui rendent KISS particulièrement important : des ressources limitées de l’appareil (mémoire, processeur), des mises à jour fréquentes des plateformes (iOS annuellement, Android trimestriellement) et la nécessité d’une livraison rapide de fonctionnalités via CI/CD. Le code complexe ne peut pas suivre ce rythme.

Une analyse de l’Apple WWDC 2023 : « Embrace Swift Generics » a montré que le projet iOS moyen contient 40–60% de « code mort » — des abstractions écrites « pour le futur » qui ne sont jamais utilisées. Ce code non seulement augmente la taille du binaire, mais ralentit également la compilation et complique la navigation. KISS l’empêche : écrivez seulement ce qui est nécessaire maintenant.

Selon le Android Developer Relations Report (2024), les projets avec un faible ratio code/tests (moins de 1:0.8) ont 67% de bogues de production en plus. Le code complexe est plus difficile à tester — c’est une menace directe pour la qualité. La simplicité est une condition préalable à une couverture de tests élevée.

Mesurez la complexité de votre code via des métriques : complexité cyclomatique — maintenez chaque méthode en dessous de 10, idéalement en dessous de 5. Utilisez Detekt (Android) ou SwiftLint (iOS) pour la vérification automatisée.

KISS contre l’overengineering : exemples pratiques

Architecture excessive : trop de couches

L’overengineering typique consiste à créer une fabrique abstraite de dépôts dans un projet avec une seule source de données. Au lieu d’une classe Repository simple, le développeur construit une chaîne : RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — pour la possibilité hypothétique de changer l’API pour GraphQL.

Selon la JetBrains Developer Survey (2023), 43% des développeurs Android ont admis avoir supprimé une couche architecturale lors du refactoring parce qu’elle n’a jamais été utilisée. KISS dit : créez une abstraction lorsqu’une deuxième option d’implémentation apparaît, pas par anticipation.

Commencez par une implémentation concrète sans interface. Lorsqu’une deuxième source de données apparaît — extrayez l’interface via le refactoring (l’IDE le fera automatiquement). C’est plus rapide que d’écrire une interface à l’avance.

Graphes d’injection de dépendances trop complexes

Les frameworks DI (Dagger, Hilt, Swinject) sont des outils puissants, mais ils provoquent souvent de la complexité. Les développeurs créent un module séparé pour chaque entité, même si elle n’est utilisée qu’à un seul endroit. Alternative KISS : injection manuelle par constructeur pour les cas simples.

// Overengineering : module pour un seul dépôt
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS : injection manuelle s’il n’y a qu’un seul dépôt
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

L’injection manuelle dans le constructeur est le modèle DI le plus simple. Elle ne nécessite ni génération de code, ni annotations, ni modules. Passez à un framework DI seulement lorsque le projet atteint 5+ écrans et que l’injection manuelle devient difficile à maintenir.

Comment appliquer KISS dans Android et iOS ?

KISS dans Android : ViewModel et LiveData simples

Le ViewModel Android est une source fréquente de complexité excessive. Les développeurs ajoutent StateFlow, combine, flatMapLatest et des chaînes de transformations là où un simple MutableLiveData avec postValue suffirait. KISS recommande : commencez par la solution la plus simple (LiveData), complexifiez seulement pour un besoin spécifique (réinitialisation d’état, debounce).

// KISS : ViewModel simple sans chaînes réactives
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

Dans cet exemple, le ViewModel utilise une coroutine pour la requête asynchrone, LiveData pour publier le résultat. Pas de StateFlow, pas de combine — seulement ce qui est réellement nécessaire. Ajoutez StateFlow lorsqu’un flux de données unidirectionnel (UDF) avec état explicite est requis.

KISS dans iOS : des structures simples au lieu de classes

Dans iOS, le principe KISS se manifeste en préférant les structures (struct) aux classes (class) pour les modèles de données. Les structures sont des types valeur, ne nécessitent pas de gestion de mémoire via ARC et sont immuables par défaut. Les classes ne sont justifiées que lorsque l’identité (deux références au même objet) ou l’héritage est nécessaire.

// KISS : struct au lieu de class pour le modèle
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering : class avec init et deinit manuels
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

La structure User obtient automatiquement un init memberwise, la conformité Equatable et Hashable (par tous les champs), l’immuabilité et la sécurité dans un environnement multithread. Une classe nécessite un init manuel, l’implémentation de NSObject et est sujette aux conditions de course via l’état partagé.

Simplicité dans la couche réseau

La couche réseau est un autre domaine où KISS est souvent violé. Les développeurs ajoutent une chaîne d’Interceptor de 5+ éléments, une sérialisation via des fabriques abstraites et des mappeurs pour chaque point de terminaison. Solution KISS : une URLSession avec configuration et un décodage via Codable/JSON.

Selon le Guide de programmation URLSession d’Apple (2023), une couche réseau simple avec URLSession et Codable couvre 95% des scénarios d’applications mobiles. Les chaînes d’Interceptor complexes ne sont nécessaires que pour des cas spécifiques : rafraîchissement de jetons, journalisation, chiffrement.

Commencez par une couche réseau simple basée sur URLSession + Codable. Ajoutez des Interceptors lorsque des besoins réels surgissent, pas « par précaution ». Cela réduit le code de la couche réseau de 2 à 3 fois.

Erreurs typiques en suivant KISS

Confusion entre simplicité et primitivité

La simplicité n’est pas la même chose que la primitivité. Une solution simple est une solution concise et claire qui résout la tâche sans redondance. Une solution primitive ignore les bonnes pratiques et l’architecture saine. La différence est qu’une solution simple est facile à étendre, tandis qu’une solution primitive ne l’est pas.

Exemple : utiliser Activity comme seule entité pour tous les écrans est de la primitivité, pas de la simplicité. La simplicité consiste à utiliser Navigation Component avec différents Fragments pour différents écrans, mais sans abstractions inutiles. KISS ne justifie pas une mauvaise architecture.

Vérifiez par vous-même : votre code peut-il changer lors de l’ajout d’une nouvelle fonctionnalité ? Si oui — la simplicité est correcte. Si chaque fonctionnalité nécessite de tout réécrire — c’est de la primitivité, refactorisez immédiatement.

Ignorer les motifs au nom de KISS

Les motifs (MVVM, MVI, Coordinator) ne sont pas une complication, mais une structuration. KISS n’interdit pas d’utiliser des motifs architecturaux éprouvés. Il interdit leur utilisation excessive : trois motifs là où un seul suffirait. Le juste milieu est un motif architectural par projet et pas plus de 2–3 motifs auxiliaires (DI, Navigation).

Selon le State of Mobile Architecture Report (2024), les projets qui utilisent exactement un motif architectural ont 34% de bogues en moins dans la première année de développement que les projets « Frankenstein » qui combinent 3+ motifs. Choisissez MVVM ou MVI pour un projet mobile — et tenez-vous-y sur tous les écrans.

Ne mélangez pas MVVM et MVI dans le même projet. Si l’équipe a choisi MVVM — tout le projet doit suivre MVVM. Les exceptions sont des modules de fonctionnalités individuels avec leur propre décision architecturale, mais cela doit être un choix conscient.