Gestion de configuration dans le développement mobile : ce que c'est, quelles options et comment configurer

Gestion de configuration sous Android : Build Variant et build.gradle

Build Variant — une combinaison de Build Type (debug/release/staging) et de Product Flavor (free/paid, demo/full). Gradle crée automatiquement un variant pour chaque combinaison : freeDebug, freeRelease, paidDebug, paidRelease. Chaque variant peut avoir son propre code, ses ressources et ses dépendances — c'est le fondement de la gestion de configuration dans les applications mobiles sur Android.

Build Variant vs Product Flavor

Build Type — paramètres de build : si le débogage est activé, signature, optimisation ProGuard. debug contient par défaut debuggable=true, release — minifyEnabled=true.

Product Flavor — variante de l'application : gratuite (free), payante (paid), démo (demo). Les flavors peuvent avoir différents applicationId, ressources et dépendances SDK.

// build.gradle — configuration des flavors de produit Android
android {
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt')
        }
    }
}

L'exemple crée deux flavors : free et paid. Un applicationId séparé est défini pour free — cela permet d'installer les deux applications sur un même appareil. BuildConfig est généré pour chaque variant : BuildConfig.FLAVOR = "free", BuildConfig.BUILD_TYPE = "debug". Utilisez BuildConfig dans le code pour la logique conditionnelle.

settings.gradle et Gradle KTS

settings.gradle — le fichier Gradle racine qui décrit les modules du projet.

Gradle KTS — une alternative à Groovy utilisant Kotlin DSL. KTS offre l'autocomplétion dans Android Studio et la vérification de types. Recommandé pour les nouveaux projets.

Gestion de configuration sous iOS : Scheme et .xcconfig

La gestion de configuration sous iOS repose sur Scheme — une configuration Xcode qui définit quoi et comment compiler : Build Configuration (Debug/Release), tests, analyse, archivage. Les schemes peuvent être dupliqués pour différents environnements (Development, Staging, Production). Les schemes sont stockés dans des fichiers .xcscheme dans le dossier xcshareddata.

Fichiers .xcconfig

.xcconfig — un fichier de configuration Xcode qui stocke les paramètres de build sous forme textuelle. Pour la gestion de configuration des applications mobiles, iOS utilise .xcconfig : versionnage dans Git, réutilisation entre projets, moins de paramètres manuels. Dans .xcconfig sont définis SWIFT_ACTIVE_COMPILATION_CONDITIONS, PRODUCT_BUNDLE_IDENTIFIER, CODE_SIGN_IDENTITY.

Info.plist — le fichier de métadonnées de l'application. Il stocke la version, l'identifiant, les autorisations. Info.plist peut être différent pour chaque Scheme — via Info.plist File dans Build Settings.

AndroidManifest.xml — l'équivalent Android : stocke les autorisations, les composants, les métadonnées.

Scheme vs Build Configuration

Scheme — le scénario de build (quoi faire). Build Configuration — l'ensemble de paramètres (comment faire). Un Scheme utilise une Build Configuration (Debug ou Release). Pour CI/CD : configurez l'action Archive sur Release et l'action Test sur Debug dans un même Scheme.

Gestion de configuration dans Flutter et React Native : pubspec.yaml, Podfile, .env

pubspec.yaml — le fichier de configuration du projet Flutter. Contient les dépendances, versions, ressources. Prend en charge les variables d'environnement via --dart-define.

Podfile — le gestionnaire de dépendances CocoaPods pour iOS. Définit les versions des bibliothèques et la plateforme.

.env — un fichier avec des variables d'environnement pour toutes les plateformes. Flutter et React Native utilisent une approche différente pour la gestion de configuration : dart-define dans Flutter, react-native-config dans React Native. La gestion de configuration dans les projets multiplateformes implique différents outils selon la stack.

.env et Variables d'environnement

.env — un fichier texte avec des paires clé=valeur. Ne se commit pas dans Git (ajoutez à .gitignore). Pour Flutter — flutter_dotenv, pour iOS — Config.xcconfig avec #include, pour Android — BuildConfig. Variables env : API_URL, SENTRY_DSN, APP_SECRET. Dans la gestion de configuration du développement mobile, .env est la norme de facto pour stocker les secrets en dehors du dépôt.

Podfile et pubspec.yaml

Podfile décrit les dépendances CocoaPods et la plateforme (platform :ios, '15.0'). pubspec.yaml pour Flutter — dependencies et dev_dependencies. Les deux prennent en charge les dépendances conditionnelles : pod 'Analytics', :configs => ['Release'] ou flutter pub add --flavor free. Chez IT Sectr, nous utilisons .env + BuildConfig pour les secrets et Podfile pour les dépendances natives dans les projets mobiles.

Le tableau montre les principales différences de gestion de configuration entre les plateformes mobiles. Android offre plus de flexibilité via Build Variant. iOS est plus simple mais moins flexible. Flutter centralise la configuration dans dart-define, mais les dépendances natives nécessitent toujours la configuration de Podfile/build.gradle.

Compilation conditionnelle dans la gestion de configuration

Compilation conditionnelle — inclusion ou exclusion de code à la compilation en fonction de flags. Cela fait partie de la gestion de configuration : elle permet d'intégrer des outils de débogage (logging, inspecteur) dans les builds debug et de les supprimer de la release. L'implémentation diffère selon les plateformes.

Compilation conditionnelle en Swift

#if DEBUG — directive de préprocesseur Swift. Le code à l'intérieur du bloc n'est compilé qu'en configuration Debug. Autres flags : #if !RELEASE, #if targetEnvironment(simulator). Active Compilation Conditions dans Build Settings — ajoutez vos flags personnalisés via -D FLAG_NAME. La gestion de configuration des builds par conditions de compilation est une pratique standard sous iOS.

Compilation conditionnelle en Kotlin

BuildConfig.DEBUG — champ booléen, true en build debug. BuildConfig est généré automatiquement par Gradle. Pour les flags personnalisés, utilisez buildConfigField dans build.gradle : buildConfigField "boolean", "REPORT_CRASHES", "true". Dans le code : if (BuildConfig.REPORT_CRASHES) { ... }.

Compilation conditionnelle en Flutter

dart-define — flags de compilation Flutter : flutter run --dart-define=ENV=staging. Dans le code : const env = String.fromEnvironment('ENV', defaultValue: 'production'). Pour les builds conditionnels d'applications mobiles, utilisez le plugin build_runner avec génération de code.