Déployer un store d'applications Android privé sans Google Play

Votre application de scan d'entrepôt n'ira jamais sur le Play Store public. Elle tourne sur 300 terminaux durcis, elle embarque votre logique de stock, et une fiche publique n'aurait aucun sens. Un store d'applications d'entreprise privé, c'est ce qui amène ce build sur les appareils, le maintient à jour et vous dit qui utilise quelle version. Voici comment en monter un sur Android en 2026, sans rien publier publiquement.

À qui s'adresse ce guide, et les trois voies possibles

Ce guide est écrit pour la personne qui porte le parc Android dans une entreprise de 50 à 5 000 appareils : un administrateur, deux au mieux, pas d'équipe mobilité dédiée. Vous avez au moins une application développée en interne ou par une agence, et quelqu'un aux opérations envoie encore l'APK par e-mail. C'est cette habitude que nous remplaçons.

Il existe trois voies pour la distribution d'applications privées sur Android, et elles ne sont pas interchangeables. La première : publier votre application en app privée dans Managed Google Play. Google héberge et sert le binaire, votre organisation est le seul public, rien n'apparaît dans la recherche publique. La deuxième : déposer l'APK dans votre plateforme de gestion, qui l'installe directement sur l'appareil. Aucun hébergement Google, et c'est la seule option pour le matériel durci vendu sans les services Google Mobile Services. La troisième : un catalogue en libre-service sur l'appareil, un app store d'entreprise où le collaborateur choisit dans une liste que vous composez, les applications imposées s'installant silencieusement en arrière-plan.

La plupart des parcs en combinent deux sur trois.

Ce que le tableau ne montre pas : aucune de ces voies ne demande à l'utilisateur d'autoriser les installations depuis des sources inconnues. Cette case relève du sideloading, et sur un appareil enrôlé dans Android Enterprise elle n'apparaît jamais. Si votre processus actuel consiste à expliquer un réglage de sécurité au téléphone, vous ne faites pas encore de distribution gérée.

Les prérequis

Quatre points, classés selon la fréquence à laquelle ils bloquent un projet.

• Un rattachement Android Enterprise. Votre plateforme de gestion doit être liée à une organisation Android Enterprise : c'est ce qui vous donne accès à Managed Google Play et au modèle de comptes gérés. La configuration prend quelques minutes et demande un compte Google qui n'est pas celui d'une personne. Utilisez une boîte partagée de la DSI.
• Un mode d'enrôlement tranché. Entièrement géré (appareil d'entreprise, la DSI contrôle tout), profil professionnel pour les téléphones personnels, ou appareil dédié pour un usage unique comme une douchette ou une borne. Le mode décide de ce que l'installation silencieuse sait faire : en mode entièrement géré ou dédié, votre plateforme installe directement un APK déposé, alors que dans un profil professionnel un build interne passe normalement en app privée par Managed Google Play.
• Un build de production signé. Android identifie une application par son nom de package associé à son certificat de signature, et ce couple ne change jamais. Perdez le keystore et vous ne pouvez plus mettre à jour l'application : il faut désinstaller puis réinstaller, et les données locales partent avec. Rangez-le avec vos secrets de production, pas sur le poste du prestataire parti en mars.
• Un compte développeur Play, parfois. À la première publication d'une app privée depuis une console EMM, Managed Google Play crée un compte développeur Play pour votre organisation sans frais d'inscription. Les 25 USD d'inscription ne concernent que l'ouverture de votre propre compte Play Console complet, utile si vous tenez à conserver vous-même la clé de signature de vos bundles.

Déployer votre store d'applications d'entreprise privé, pas à pas

1. Préparer l'APK

Produisez une variante release signée avec votre clé de production, et incrémentez l'entier versionCode. Android refuse d'installer un versionCode inférieur par-dessus un supérieur : un retour arrière impose donc une désinstallation puis une réinstallation. Fixez votre numérotation avant le premier déploiement, pas après qu'un mauvais build a atteint 400 appareils. Le format n'a pas bougé : un APK reste le fichier que vous remettez à une plateforme de gestion, même si les nouvelles applications du Play Store public doivent être des app bundles depuis août 2021. Cette règle porte sur la publication, pas sur l'installation.

Deux vérifications valent le détour avant d'expédier quoi que ce soit. Ouvrez le manifeste et lisez la liste des permissions à voix haute : tout ce que vous ne sauriez pas justifier devant un CSE vous reviendra en pleine figure plus tard. Confirmez ensuite votre niveau d'API cible, car Play refuse les dépôts trop en retard sur l'exigence en cours.

2. Publier l'app privée, ou téléverser le build

Pour la voie Managed Google Play, tout se passe depuis votre console de gestion, pas depuis la Play Console. La documentation de Google est directe sur le peu que cela demande : vous fournissez un titre et le fichier de l'application, et la plupart des apps sont prêtes à être distribuées en moins de 10 minutes. Deux limites à anticiper. Vous pouvez téléverser 15 apps privées par jour, les web apps comptant dans ce total. Et une app privée publiée ainsi ne pourra jamais devenir publique, ni être transférée vers un autre compte développeur.

Si vous publiez des dizaines de builds par an, la Custom App Publishing API est la meilleure voie : les applications y sont définitivement privées et peuvent apparaître dans le store géré en cinq minutes, contre plus de deux heures via la Play Console.

Pour la voie directe, déposez l'APK signé dans votre plateforme, donnez-lui un nom d'affichage et une icône, et il devient une entrée de catalogue. C'est aussi le repli quand Managed Google Play est hors de portée : Managed Google Play exige les services Google Mobile Services, donc les terminaux durcis livrés sans GMS ne peuvent pas l'utiliser du tout.

3. Cibler les bons groupes

N'affectez jamais une application au parc entier le premier jour. Construisez des groupes qui collent à la réalité du travail (entrepôt, techniciens itinérants, responsables de magasin, siège) et pilotez une semaine sur un groupe de dix appareils. Décidez ensuite, groupe par groupe, si l'application est imposée ou optionnelle. Les apps imposées s'installent silencieusement avant que quiconque ouvre le catalogue. Les optionnelles patientent dans le store, ce qui est le bon réglage pour un outil dont une partie de l'équipe seulement a besoin.

Concevoir les groupes est ingrat, et c'est précisément ce qui vous sauve ensuite. Une structure propre, c'est ce qui permet de garder la version 4.2 sur l'équipe de nuit pendant que l'équipe de jour reçoit la 4.3.

4. Pousser la configuration gérée

C'est l'étape que la plupart des équipes sautent, puis regrettent. La configuration d'application envoie les réglages à l'app depuis le serveur avant toute ouverture : URL de backend, identifiant de tenant, options SSO, commutateurs de fonctionnalités. Sur Android, ce sont les managed configurations déclarées dans le XML de l'application et lues via l'API RestrictionsManager. La limite est nette : une application n'accepte que ce que son développeur a déclaré. Si votre app interne n'a aucun schéma de configuration, ajouter quelques clés représente en général une après-midi de travail, et cela supprime l'écran de première ouverture où l'on demande à un chauffeur un nom de serveur qu'il n'a jamais vu.

Gardez les valeurs dans la console, jamais figées dans l'APK. Reconstruire une application parce qu'une URL a bougé, c'est du temps perdu.

5. Gérer les mises à jour et les versions

Décidez qui maîtrise le calendrier. La mise à jour automatique partout convient à une app dont le backend est stable, et devient hostile pour une app liée aux livraisons d'un ERP. Les parcs que nous voyons s'arrêtent souvent sur des mises à jour par vagues : groupe pilote d'abord, puis tout le monde, avec un plan de retour arrière écrit qui assume le problème de la désinstallation et de la perte de données.

Un piège propre à Managed Google Play : une nouvelle version qui réclame de nouvelles permissions peut bloquer la mise à jour jusqu'à ce qu'un administrateur les valide de nouveau dans la console. Personne ne s'en aperçoit pendant trois semaines, puis quelqu'un demande pourquoi la moitié du parc est restée sur l'ancien build. Inscrivez un contrôle mensuel des versions dans votre routine.

Sécurité et conformité

La signature est votre contrôle d'intégrité, et le seul qui compte vraiment. Le couple nom de package plus certificat est ce qui permet à Android de décider si une mise à jour vient bien de vous. Traitez le keystore comme un identifiant de production : accès restreint, et inventaire des personnes qui le détiennent.

Les applications servies par Managed Google Play sont analysées par Play Protect, fiches privées incluses, ce qui constitue un vrai argument pour cette voie plutôt que le dépôt d'APK direct quand le matériel le permet. À partir d'Android 13, les applications installées hors store perdent aussi la possibilité d'obtenir les permissions d'accessibilité, ce qui casse certains outils d'automatisation anciens et se découvre plutôt pendant un pilote qu'avant.

Reste le changement que tout le monde surveille dans ce domaine. Google impose désormais une vérification d'identité des développeurs pour les applications installées hors Play sur les appareils Android certifiés, avec une entrée en application le 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande, puis une extension mondiale annoncée pour 2027. Bonne nouvelle pour les parcs : les applications distribuées par le store de votre organisation sur des appareils gérés en sont exemptées, l'administrateur les ayant déjà validées. Mauvaise nouvelle pour qui expédie encore des APK par lien de téléchargement vers des téléphones non gérés. Cette pratique a maintenant une date de péremption visible.

Côté RGPD, séparez deux sujets. Un store d'applications interne décide quels binaires arrivent sur quel appareil : votre registre des traitements doit donc décrire l'inventaire d'appareils et les données d'affectation que votre plateforme conserve, pas le contenu des applications elles-mêmes. Sur les téléphones personnels, c'est la frontière du profil professionnel qui vous protège : les apps gérées et leur configuration vivent du côté professionnel, la copie personnelle de la même app n'est pas touchée. Documentez cette frontière dans la charte BYOD et faites-la signer.

Les erreurs vues en déploiement

1. Aucune structure de groupes. Tout est affecté à « tous les appareils », donc chaque mise à jour devient un événement qui touche le parc entier, sans pilote ni vagues.
2. Le keystore sur un seul portable. Nous avons vu une entreprise perdre la clé de signature de son app de maintenance et la reconstruire sous un nouveau nom de package, avec six mois de données locales passées à la trappe.
3. Croire que le profil professionnel se comporte comme un appareil entièrement géré. Un APK déposé qui s'installe silencieusement sur du matériel d'entreprise peut exiger la voie de l'app privée Managed Google Play dans un profil professionnel. Testez les deux avant d'annoncer une date.
4. Oublier le matériel sans GMS. Les tablettes durcies arrivent, le store ne fonctionne pas dessus, et le projet s'arrête. Interrogez le fournisseur de matériel sur la présence des GMS avant de commander.
5. Laisser l'ancienne voie de sideloading ouverte. Un catalogue géré et un lien de téléchargement sur un disque partagé, en parallèle, et vous ne savez toujours pas ce qui est installé. Coupez le lien.

Comment Appaloosa le fait

Appaloosa est construit autour d'un catalogue à vos couleurs pour les applications publiques, privées et web. Vous déposez un APK ou un IPA signé, la plateforme le versionne, vous l'affectez à des groupes d'appareils, poussez les mises à jour silencieusement et le retirez à distance. Les apps publiques arrivent par Managed Google Play et Apple Business Manager dans le même catalogue, la connexion à Managed Google Play se fait pendant la configuration initiale, et la configuration d'app gérée est appliquée au moment de l'installation puis modifiable sans réinstallation.

Les builds internes fonctionnent aussi sur du matériel dépourvu de services Google Mobile Services : c'est pourquoi le catalogue porte les deux canaux. Plateformes couvertes : iOS, iPadOS, Android, Windows et macOS. Pour les politiques spécifiques à Android, voyez la gestion des appareils Android. L'infrastructure est hébergée en France, sur un hébergement qualifié SecNumCloud. Les détails sont sur la page gestion des applications mobiles, et si vous voulez d'abord le contexte, lisez notre article sur la gestion des sources inconnues sur Android en entreprise.

FAQ

Peut-on publier une app privée sans qu'elle apparaisse dans la recherche Play publique ?

Oui. Une app privée est rattachée à l'identifiant de votre organisation : elle n'apparaît ni dans la recherche publique, ni sur une fiche de store publique. Seuls les appareils de votre parc la voient, et Google continue d'héberger, d'analyser et de servir le binaire. Les apps privées publiées depuis une console EMM ne passent pas les mêmes contrôles de revue que les apps publiques, ce qui explique en partie leur disponibilité en quelques minutes.

Les utilisateurs doivent-ils autoriser les sources inconnues ?

Non, pas sur un appareil enrôlé dans Android Enterprise. L'agent de gestion installe silencieusement les applications approuvées, builds privés compris, et aucun écran de permission n'apparaît. Cette demande ne surgit que lorsqu'une personne installe un fichier à la main, hors distribution gérée : exactement le mode opératoire qu'un store privé remplace.

Et pour les applications iOS ?

La logique de catalogue est la même, la plomberie diffère. Les builds iOS internes sont distribués en interne aux appareils enrôlés avec un certificat de signature d'entreprise, et les apps publiques passent par les licences en volume d'Apple Business Manager. Un avertissement : un certificat d'entreprise révoqué empêche le lancement de toutes les applications signées avec lui, donc les dates d'expiration vont dans votre agenda, pas dans une page de wiki que personne n'ouvre.

Commencez par une application, un groupe de dix appareils et une semaine d'observation. Le travail technique tient dans une après-midi ; ce sont la structure des groupes et la politique de mise à jour qui décident si cela tient encore quand le parc double.