Stockage interne de l’application : ce que c’est, méthodes de stockage de données et fonctionnement en développement

Auteur : IT Sectr Publié le : 2026-03-13 Temps de lecture : 11 min

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

  • Internal Storage — stockage isolé de chaque application, inaccessible aux autres programmes
  • Modèle Sandbox garantit que les données d’une application ne peuvent pas être lues par une autre sans autorisations spéciales
  • Android fournit Context.getFilesDir(), getCacheDir() et getDataDir() pour accéder au stockage interne
  • iOS utilise NSDocumentDirectory et NSCachesDirectory dans le conteneur Sandbox de l’application
  • Nettoyage automatique lors de la désinstallation de l’application garantit la suppression complète de toutes les données du stockage interne

Qu’est-ce que le stockage interne de l’application ?

Le 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.

Méthodes de stockage des données dans la mémoire interne

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.

Stockage de fichiers isolé

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.

SharedPreferences et DataStore

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.

Base de données SQLite et Room

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.

EncryptedSharedPreferences

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.

Comment travailler avec le stockage interne sur Android

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.

Accès à filesDir via Context

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.

kotlin
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.

Création de sous-répertoires dans le stockage interne

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.

kotlin
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.

Comment travailler avec le stockage interne sur iOS

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.

Accès au répertoire Documents via FileManager

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.

swift
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.

Gestion des exclusions de sauvegarde

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.

swift
var cacheURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!
cacheURL.hasExcludedFromBackupKey = true

var values = URLResourceValues()
values.isExcludedFromBackup = true
try cacheURL.setResourceValues(values)

Différences entre le stockage interne, le cache et le stockage externe

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éristiqueInternal StorageRépertoire CacheExternal Storage
Visibilité pour les autres appsMasquéeMasquéeAccessible
Suppression à la désinstallationComplèteComplèteDépend de l’emplacement
SauvegardeAndroid — non, iOS — oui (Documents)NonUniquement lors de la synchronisation
Disponibilité sans supportToujoursToujoursNécessite carte SD
Risque de perte de donnéesMinimalÉlevéMoyen
Taille de fichier recommandéeJusqu’à 100 MoJusqu’à 50 MoQuelconque

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.

Recommandations pour l’utilisation du stockage interne

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.

  • Minimisez le volume des données stockées. Utilisez le stockage interne uniquement pour les fichiers critiques ; placez le reste dans le cache ou le stockage externe
  • Nettoyez régulièrement les fichiers temporaires. Vérifiez le répertoire cache à chaque lancement et supprimez les fichiers de plus de 24 heures — cela réduit la charge système et évite le débordement de la partition /data
  • Chiffrez les données confidentielles avec EncryptedSharedPreferences ou EncryptedFile de la bibliothèque AndroidX Security. Stocker les jetons et mots de passe en texte clair est une vulnérabilité courante exploitée par les chevaux de Troie avec accès root
  • Utilisez la migration lors de la mise à jour de la structure de fichiers. Lors de la publication d’une nouvelle version de l’application, vérifiez la présence d’anciens fichiers et déplacez-les vers de nouveaux répertoires avant de supprimer les anciens

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

Que devient le Internal Storage après la désinstallation de l’application ?

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.

Une autre application peut-elle lire mes fichiers depuis Internal Storage ?

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.

Quelle est la quantité maximale de données pouvant être stockée dans la mémoire interne ?

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.

Quelle est la différence entre filesDir et cacheDir sur Android ?

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.

Comment transférer des données d’Internal Storage vers une carte SD ?

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é

  • Internal Storage — répertoire isolé de chaque application, protégé contre l’accès des autres programmes et de l’utilisateur
  • Architecture Sandbox sur Android et iOS garantit que les données de différentes applications ne se chevauchent pas et ne peuvent pas être lues sans accès root
  • Le choix de la méthode de stockage dépend du type de données : fichiers via filesDir, paramètres via DataStore, données structurées via Room
  • iOS Sandbox inclut une politique de sauvegarde qui doit être contrôlée via l’attribut isExcludedFromBackup pour les données non critiques
  • Différence avec le cache réside dans la garantie de persistance : Internal Storage n’est pas supprimé par le système, contrairement à cacheDir qui peut être vidé en cas de manque de mémoire
  • Volume de données recommandé dans le stockage interne — jusqu’à 100 Mo. Les fichiers plus volumineux doivent être placés sur un stockage externe ou un service cloud
  • Le contrôle utilisateur de l’espace occupé et la possibilité de nettoyer les données augmentent la confiance et la note de l’application dans les magasins

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.

Discuter du projet

Lisez aussi