Skip to main content

Glossaire

APK

Un APK (Android Package Kit) est le fichier d'installation d'une application Android : une archive qui contient le code compilé, les ressources, le manifeste et la signature de l'éditeur. Pour une équipe IT, c'est l'objet que vous versez dans votre store d'entreprise quand l'application est développée en interne et n'a aucune raison d'exister sur le Play Store public.

Comment ça marche

L'APK est un fichier ZIP avec une structure imposée : le dossier classes.dex pour le bytecode, res pour les ressources, lib pour les bibliothèques natives par architecture, et AndroidManifest.xml qui déclare les permissions, la version minimale d'Android et les composants de l'application. La signature cryptographique de l'éditeur scelle l'ensemble. Android refuse toute mise à jour signée avec une autre clé, ce qui rend la perte d'un keystore particulièrement douloureuse.

Depuis août 2021, Google impose l'Android App Bundle (format .aab) pour toute publication sur le Play Store. Le bundle n'est pas installable tel quel : Google y découpe des APK adaptés à chaque appareil. Pour une distribution hors Play Store, vous restez donc sur des APK, soit universels, soit générés par architecture avec bundletool.

Un détail qui coûte des heures : le champ versionCode. C'est un entier, et Android n'accepte une mise à jour que si ce nombre augmente. Deux builds avec le même versionCode créent une confusion impossible à diagnostiquer depuis une console de gestion.

Pourquoi c'est important pour une flotte

Les applications métier ne vont pas sur le Play Store. Une application de tournée pour 300 livreurs, un outil de relevé pour des techniciens réseau, une caisse pour 40 magasins : rien de tout cela n'a de public, et publier le code en clair sur une boutique ouverte serait absurde.

Le réflexe qui pose problème, c'est d'envoyer l'APK par e-mail ou de le déposer sur un lien partagé. L'utilisateur doit alors autoriser les sources inconnues, une autorisation qu'Android durcit à chaque version, et personne ne sait plus six mois plus tard quelle version tourne sur quel terminal. Android 13 a ajouté des restrictions sur l'accès aux services d'accessibilité pour les applications installées hors boutique, et Google a annoncé en 2025 un durcissement de la vérification des développeurs pour les installations hors Play. La distribution manuelle devient un cul-de-sac.

La voie propre, c'est la distribution gérée : le MDM installe l'APK silencieusement sur un appareil enrôlé, sans prompt, sans autorisation de sources inconnues, avec un rapport d'installation par appareil.

Comment Appaloosa le gère

Vous téléversez vos APK dans l'app store d'entreprise d'Appaloosa, vous affectez une version à un groupe d'appareils, et l'installation part silencieusement sur les appareils Android enrôlés. Chaque version est conservée, ce qui permet un retour arrière quand un build casse quelque chose sur le terrain, et les applications publiques arrivent en parallèle via managed Google Play. Le périmètre est décrit sur la page gestion des applications mobiles.

Explorer

Découvrez toute la plateforme

Enrôlement, apps, sécurité, support à distance : tout au même endroit.

Explorer Appaloosa

Envie d'essayer Appaloosa ? Démarrer gratuitement

Questions fréquentes

Quelle différence entre un APK et un AAB ?
L'APK s'installe directement sur un appareil. L'AAB est un format de publication que Google exige depuis 2021 pour le Play Store, et dont Google dérive ensuite les APK adaptés à chaque modèle. Pour une distribution interne via MDM, vous générez un APK à partir du bundle avec bundletool.
Faut-il activer les sources inconnues pour installer un APK interne ?
Non, si l'appareil est enrôlé. Un MDM sous Android Enterprise installe un APK privé silencieusement, sans toucher au réglage des sources inconnues. Celui-ci ne concerne que les installations manuelles, et il vaut mieux le laisser désactivé sur une flotte.
Comment éviter qu'une mauvaise version d'APK ne se propage ?
Incrémentez systématiquement le versionCode, gardez un groupe pilote de quelques appareils pour chaque nouveau build, et n'élargissez qu'après 48 heures sans incident. Une console qui conserve l'historique des versions vous permet de revenir en arrière sans reconstruire l'application.