Le stockage interne de l’application est un espace dédié sur l’appareil accessible uniquement à une application spécifique via un stockage isolé. Selon Android Developers, 2026, chaque application reçoit son propre répertoire sandbox auquel les autres applications n’ont pas d’accès direct. Cette approche protège les données contre la lecture non autorisée et assure un fonctionnement stable dans un environnement multitâche d’appareils mobiles.
Points clés
Context.getFilesDir(), getCacheDir() et getDataDir() pour accéder au stockage interneNSDocumentDirectory et NSCachesDirectory dans le conteneur Sandbox de l’applicationLe stockage interne de l’application est un répertoire isolé que le système d’exploitation attribue à chaque application lors de son installation. Les autres applications et l’utilisateur ne peuvent pas accéder à ce répertoire via les gestionnaires de fichiers standard. Le système garantit que toutes les données contenues dans ce répertoire seront complètement supprimées lors de la désinstallation de l’application. Cette approche constitue la base du modèle de sécurité des systèmes d’exploitation mobiles, empêchant les fuites d’informations confidentielles entre programmes.
Contrairement au stockage externe (carte SD), le stockage interne est toujours disponible et ne nécessite pas de vérification de présence de support. Les vitesses de lecture et d’écriture dans la mémoire flash NAND des appareils modernes atteignent 800–900 Mo/s en lecture séquentielle et 200–300 Mo/s en écriture séquentielle, comparables aux SSD SATA. La taille de la zone allouée dépend de la capacité totale de l’appareil et de la politique du fabricant : sur les appareils avec 64 Go de mémoire flash, l’application reçoit 16 à 64 Mo d’espace initial avec possibilité d’extension selon les besoins.
L’architecture du stockage interne diffère entre Android et iOS. Sous Android, chaque application reçoit un répertoire /data/data/<package_name>/, dans lequel le système crée les sous-répertoires files/, cache/ et databases/. Sous iOS, l’application fonctionne dans un conteneur Sandbox avec les répertoires Documents/, Library/ et tmp/, chacun ayant son propre objectif et sa politique de sauvegarde.
Les développeurs ont accès à plusieurs méthodes pour sauvegarder des données dans le stockage interne de l’application. Chaque méthode résout une tâche spécifique et convient à un type particulier de données. Le choix de la bonne méthode affecte directement les performances de l’application, la facilité de développement et la sécurité des données utilisateur.
La méthode la plus bas niveau est l’écriture directe de fichiers dans le répertoire de fichiers. L’application peut créer tous les fichiers et répertoires nécessaires dans son sandbox. Cette méthode convient pour stocker des fichiers média, des documents utilisateur et toutes les données binaires qui ne nécessitent pas d’organisation structurée. Sous Android, l’accès au répertoire se fait via l’appel Context.getFilesDir(), qui retourne le chemin absolu vers le répertoire de fichiers de l’application. Sous iOS, la fonction NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) sert un objectif similaire.
Pour stocker des paires clé-valeur, Android propose SharedPreferences et le plus moderne DataStore basé sur les coroutines Kotlin et le protocole protobuf. SharedPreferences stocke les données dans un fichier XML dans le répertoire /data/data/<package>/shared_prefs/. Malgré sa simplicité d’utilisation, SharedPreferences présente des inconvénients : l’écriture synchrone peut provoquer des ralentissements sur le thread UI, et l’absence de sécurité de type augmente le risque d’erreurs. DataStore résout ces problèmes en fournissant une API asynchrone basée sur Flow et un support complet des types via des schémas protobuf.
Pour les données structurées avec des relations, SQLite ou l’encapsulation Room est le choix optimal. La base de données est stockée dans un seul fichier dans le répertoire databases/ et prend en charge la syntaxe SQL complète. Room est une bibliothèque officielle Jetpack qui fournit une API type-safe, une migration automatique de schéma et la prise en charge des coroutines. La taille de la base de données peut atteindre plusieurs gigaoctets sans perte significative de performances avec un indexage approprié. SQLite sur les appareils mobiles gère jusqu’à 50 000 opérations d’écriture par seconde sur un processeur phare moderne.
Pour stocker des données confidentielles telles que des jetons d’authentification et des clés de chiffrement, Android fournit EncryptedSharedPreferences. Cette encapsulation des SharedPreferences standard chiffre automatiquement les clés et les valeurs en utilisant AES256-GCM-None. Le chiffrement est effectué au niveau du fichier avant l’écriture sur le disque, donc même avec un accès physique à l’appareil, un attaquant ne peut pas lire le contenu. EncryptedSharedPreferences fait partie de la bibliothèque AndroidX Security, qui inclut également EncryptedFile pour chiffrer des fichiers entiers.
L’Android SDK fournit un ensemble de méthodes pour travailler avec le stockage interne via la classe Context. Chaque méthode retourne un chemin vers un répertoire système spécifique dans le sandbox de l’application. Examinons les opérations de base d’écriture et de lecture de fichiers en utilisant Kotlin comme exemple.
La méthode principale pour obtenir le chemin vers le répertoire de fichiers interne est context.filesDir. Elle retourne un objet File pointant vers le répertoire /data/data/<package>/files/. Lors du premier accès, le système crée automatiquement tous les répertoires parents nécessaires. La taille des fichiers dans le stockage interne n’est pas explicitement limitée, mais le volume total de données ne doit pas dépasser l’espace disponible sur la partition /data, qui représente généralement 60 à 80 % de la capacité totale de la mémoire flash.
val context = getApplicationContext()
val file = File(context.filesDir, "notes.txt")
file.writeText("Contenu de la note")
val content = file.readText()
println("Lu : $content")
Les méthodes writeText et readText sont des fonctions d’extension de la bibliothèque standard Kotlin. Elles gèrent automatiquement l’ouverture et la fermeture des flux, évitant ainsi les fuites mémoire. Pour les données binaires, utilisez writeBytes et readBytes, qui ne nécessitent pas d’encodage et fonctionnent avec des tableaux ByteArray. Lorsque vous travaillez avec des fichiers volumineux, il est recommandé d’utiliser des flux bufferisés : BufferedReader et BufferedWriter pour le texte, BufferedInputStream et BufferedOutputStream pour les données binaires.
Pour organiser les fichiers en hiérarchie, créez des sous-répertoires dans filesDir. Cela aide à structurer les données par type : images, documents, fichiers d’exportation. La méthode mkdirs() crée tous les répertoires manquants dans le chemin, y compris les répertoires imbriqués. Assurez-vous que l’opération de création a réussi — la méthode retourne true uniquement lorsque de nouveaux répertoires sont créés. Les échecs de création sont le plus souvent liés à un espace insuffisant sur la partition /data ou à l’épuisement des inodes du système de fichiers.
val imagesDir = File(context.filesDir, "images")
if (imagesDir.mkdirs()) {
println("Répertoire créé")
}
val imageFile = File(imagesDir, "photo.jpg")
imageFile.writeBytes(byteArray)
Pour vérifier l’espace disponible avant d’écrire des fichiers volumineux, utilisez File.getFreeSpace() ou File.getUsableSpace(). La deuxième méthode retourne le nombre d’octets disponibles pour l’application actuelle en tenant compte des quotas de sécurité — elle est plus précise dans le contexte des appareils multi-utilisateurs. Si l’espace disponible est inférieur à la taille attendue du fichier, affichez un message à l’utilisateur et suggérez de libérer de l’espace dans les paramètres de l’appareil.
Sous iOS, chaque application fonctionne dans un conteneur Sandbox isolé. Le système ne fournit pas d’API pour sortir de ses limites sans autorisations spéciales. L’outil principal pour travailler avec le système de fichiers est la classe FileManager du framework Foundation. Le conteneur Sandbox comprend plusieurs répertoires standard, chacun avec sa propre politique de sauvegarde.
Le répertoire Documents est destiné aux données utilisateur qui doivent persister entre les lancements de l’application et être restaurées à partir de la sauvegarde. iOS inclut automatiquement ce répertoire dans les sauvegardes iCloud et iTunes. La méthode urls(for:in:) retourne un tableau d’URL du répertoire demandé — le premier élément du tableau est le principal.
let fm = FileManager.default
let docs = fm.urls(
for: .documentDirectory,
in: .userDomainMask
).first!
let fileURL = docs.appendingPathComponent("data.plist")
try data.write(to: fileURL)
FileManager prend en charge un ensemble complet d’opérations sur les fichiers : création, copie, déplacement, suppression et renommage. Chaque opération peut lever une erreur, donc tous les appels doivent être encapsulés dans une construction do-catch. Accordez une attention particulière à la suppression de fichiers — l’opération est irréversible et la restauration des données après removeItem(at:) est impossible sans sauvegarde préalable.
Toutes les données du conteneur Sandbox ne doivent pas être incluses dans la sauvegarde iCloud. Par exemple, les images mises en cache téléchargées ou les fichiers temporaires de traitement n’ont pas besoin d’être restaurés — ils seront recréés lors de la prochaine utilisation. Pour exclure un répertoire ou un fichier de la sauvegarde, définissez l’attribut isExcludedFromBackup sur true. Apple recommande de toujours exclure de la sauvegarde les données pouvant être restaurées à distance, afin de minimiser l’utilisation du stockage iCloud et de réduire le temps de restauration.
var cacheURL = fm.urls(
for: .cachesDirectory,
in: .userDomainMask
).first!
cacheURL.hasExcludedFromBackupKey = true
var values = URLResourceValues()
values.isExcludedFromBackup = true
try cacheURL.setResourceValues(values)
Chaque type de stockage sur un appareil mobile a son objectif et ses règles d’utilisation. Comprendre ces différences aide le développeur à choisir le bon emplacement pour chaque type de données. Voici une comparaison des trois principaux types de stockage disponibles pour une application.
| Caractéristique | Internal Storage | Répertoire Cache | External Storage |
|---|---|---|---|
| Visibilité pour les autres apps | Masquée | Masquée | Accessible |
| Suppression à la désinstallation | Complète | Complète | Dépend de l’emplacement |
| Sauvegarde | Android — non, iOS — oui (Documents) | Non | Uniquement lors de la synchronisation |
| Disponibilité sans support | Toujours | Toujours | Nécessite carte SD |
| Risque de perte de données | Minimal | Élevé | Moyen |
| Taille de fichier recommandée | Jusqu’à 100 Mo | Jusqu’à 50 Mo | Quelconque |
Le stockage interne est optimal pour stocker les configurations d’application, les fichiers de base de données et les documents utilisateur qui ne doivent pas être accessibles aux autres programmes. Le répertoire cache est destiné aux fichiers temporaires qui peuvent être recréés lors de la prochaine utilisation : images téléchargées, réponses API, données de traitement intermédiaires. Le stockage externe est le plus adapté pour les fichiers média volumineux (photos, vidéos, musique) et les données que l’utilisateur souhaite partager avec d’autres applications via un accès partagé.
Le choix du type de stockage affecte également la note de l’application sur Google Play et l’App Store. Les applications qui stockent de grandes quantités de données dans le stockage interne sans nettoyage reçoivent des avis négatifs : les utilisateurs se plaignent du manque d’espace. Selon une étude d’App Annie, 62 % des utilisateurs suppriment une application si elle occupe plus de 500 Mo de stockage interne de l’appareil sans option de nettoyage.
Une gestion appropriée du stockage interne de l’application améliore les performances, la sécurité et l’expérience utilisateur. Les recommandations suivantes sont basées sur la documentation officielle d’Android et iOS, ainsi que sur l’expérience pratique du développement d’applications avec des millions d’installations.
Une attention particulière doit être accordée aux tests de cas limites. Vérifiez le comportement de l’application lorsque le stockage interne est plein, lorsqu’une opération d’écriture est interrompue de manière inattendue (plantage de l’application, appel entrant) et lors de la restauration à partir d’une sauvegarde iOS. Dans chacun de ces scénarios, les données doivent rester cohérentes ou être restaurées au dernier état stable. Utilisez des fichiers transactionnels : écrivez les données dans un fichier temporaire, puis renommez-le atomiquement vers la destination. Cela évite la lecture de données corrompues en cas d’échec d’écriture.
N’oubliez pas le contrôle utilisateur. Prévoyez dans les paramètres de l’application une option pour effacer les données temporaires et afficher le volume occupé du stockage interne. Selon Google Play Console, les applications dotées de cette fonctionnalité reçoivent 18 % d’avis positifs supplémentaires dans la catégorie « Performances ».
Questions fréquentes
Toutes les données du stockage interne de l’application sont complètement supprimées. Le système d’exploitation garantit l’absence de fichiers résiduels, y compris les bases de données, les paramètres et les fichiers temporaires. Les données sur le stockage externe peuvent persister.
Sans accès root à l’appareil, les autres applications ne peuvent pas lire les fichiers depuis Internal Storage d’une autre application. Sous Android, cela nécessite des privilèges superutilisateur, tandis que sous iOS, l’isolation est assurée au niveau du noyau via Sandbox.
Il n’y a pas de limite explicite, mais le volume total est contraint par l’espace disponible sur la partition /data. Il est recommandé de ne pas dépasser 100 Mo par application — les volumes plus importants doivent être placés sur un stockage externe ou dans le cloud.
filesDir est destiné aux données permanentes de l’application et n’est pas supprimé par le système sauf nécessité. cacheDir est pour les fichiers temporaires que le système peut supprimer en cas de manque de mémoire. Le système ne garantit pas la persistance de cacheDir.
La copie directe d’Internal Storage vers une carte SD est interdite par la politique de sécurité. Utilisez l’API MediaStore sur Android 10+ ou SAF (Storage Access Framework) pour créer des copies de données dans le stockage partagé avec le consentement de l’utilisateur.
Résumé
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi