Comment créer un catalogue d’applications d’entreprise simple à utiliser et facile à administrer ?

Un catalogue d’applications d’entreprise permet aux collaborateurs d’accéder aux outils professionnels dont ils ont besoin, sans multiplier les installations non contrôlées. Pour le responsable informatique, il constitue un point central de distribution, de validation et de suivi des logiciels autorisés sur les terminaux mobiles.

Son efficacité repose sur un équilibre : les applications indispensables sont déployées automatiquement, les outils complémentaires restent accessibles en libre-service et les applications incompatibles avec les exigences de l’organisation sont écartées. Cette organisation évite de transformer chaque demande d’installation en intervention du support informatique.

Mais un catalogue ne se résume pas à une liste d’applications approuvées. Il faut définir des droits par profil métier, examiner les risques de sécurité, maîtriser les licences et anticiper le retrait des logiciels devenus inutiles. Une gouvernance claire permet de conserver un environnement applicatif cohérent, même lorsque les collaborateurs changent de poste, de terminal ou de responsabilités.

Pourquoi laisser chaque salarié installer ses outils complique-t-il la gestion du parc ?

Lorsque chaque collaborateur choisit librement ses applications, le service informatique perd progressivement la visibilité sur les logiciels réellement utilisés. Les doublons se multiplient, les versions divergent et les permissions accordées deviennent difficiles à contrôler. Cette dispersion complique la maintenance des terminaux, la protection des données professionnelles et la continuité des activités lors des changements de personnel.

Le premier problème est l’accumulation d’applications répondant aux mêmes besoins. Plusieurs outils de prise de notes, de messagerie ou de partage documentaire peuvent coexister au sein d’une équipe. Les informations professionnelles se retrouvent alors réparties dans des environnements différents, parfois sans interopérabilité ni règles communes de conservation.

Cette diversité augmente également la charge d’administration. Chaque application possède son propre cycle de mise à jour, ses paramètres de sécurité et ses conditions d’utilisation. Une version obsolète peut subsister sur un terminal alors qu’un correctif est déjà disponible.

Il faut distinguer deux catégories de risques :

• Les risques de sécurité : permissions excessives, accès injustifié aux contacts ou aux fichiers, transferts de données insuffisamment encadrés et applications dont l’éditeur ne garantit plus la maintenance.
• Les risques organisationnels : multiplication des demandes d’assistance, difficultés de migration, dépendance à des outils individuels et impossibilité de standardiser les environnements de travail.

Une difficulté supplémentaire apparaît lorsqu’un collaborateur quitte l’entreprise ou reçoit un nouveau terminal. Sans inventaire applicatif fiable, le service informatique ne sait pas toujours quelles applications doivent être récupérées, reconfigurées ou supprimées. Certaines données peuvent rester associées à des comptes personnels, ce qui complique leur restitution à l’organisation.

Un catalogue encadré répond à cette dérive en proposant une sélection de logiciels adaptés au travail. Sur Android Enterprise, la documentation officielle Android Enterprise sur Managed Google Play décrit notamment la mise à disposition d’applications approuvées et leur distribution sur les appareils gérés.

L’objectif n’est donc pas d’interdire systématiquement toute installation, mais de déplacer le choix des applications vers un environnement validé, suffisamment accessible pour ne pas encourager les contournements.

Une fois la distribution centralisée, la priorité consiste à organiser les applications selon les besoins des collaborateurs plutôt qu’à constituer une bibliothèque identique pour tous.

Comment organiser les applications disponibles selon les fonctions des collaborateurs ?

Un catalogue applicatif doit être structuré autour des profils métier plutôt qu’autour d’une liste uniforme de logiciels. Les collaborateurs accèdent ainsi aux applications nécessaires à leurs fonctions, tandis que les droits d’installation et les licences restent maîtrisés. Cette segmentation facilite l’arrivée de nouveaux salariés et permet d’adapter les autorisations lorsque leurs responsabilités évoluent.

La première étape consiste à définir des groupes fonctionnels représentatifs de l’organisation : commerciaux, production, support, ressources humaines ou direction. Chaque groupe reçoit un ensemble d’applications cohérent avec ses missions.

Une même application peut appartenir à plusieurs groupes. Un outil de visioconférence peut être commun à toute l’entreprise, tandis qu’une application de gestion des interventions ne concerne que les techniciens de terrain.

Pour organiser cette attribution, il est utile de distinguer quatre catégories :

• Applications obligatoires : outils imposés par le métier, les exigences internes ou certaines obligations applicables à l’activité.
• Applications quotidiennes : logiciels indispensables à la réalisation régulière des tâches.
• Applications occasionnelles : outils proposés à la demande lorsqu’un besoin précis apparaît.
• Applications personnelles : logiciels extérieurs aux usages professionnels pris en charge par l’entreprise.

Cette classification permet de séparer deux notions souvent confondues : la visibilité et le droit d’installation. Selon les possibilités du système de gestion, une application peut être présentée à différents utilisateurs à titre informatif, tout en réservant son installation aux profils autorisés. Dans d’autres environnements, l’application doit être masquée aux personnes qui ne disposent pas des droits requis.

La conception des groupes doit également anticiper les situations hybrides. Un responsable commercial peut avoir besoin d’applications de management et de prospection. Un collaborateur qui rejoint le support technique doit recevoir ses nouveaux outils sans conserver automatiquement les droits de son ancien poste.

Le rattachement aux groupes gagne donc à être synchronisé avec les processus de mobilité interne. Chaque changement de fonction doit entraîner un réexamen des droits, des installations nécessaires et des licences associées.

Cette organisation prépare ensuite une décision essentielle : déterminer quels logiciels doivent être installés automatiquement et lesquels peuvent rester disponibles en libre-service.

Installation imposée ou libre-service : quel modèle pour les applications internes ?

Le modèle le plus adapté consiste à combiner trois modes de distribution : installation automatique pour les applications indispensables, libre-service pour les outils facultatifs validés et blocage pour les logiciels non autorisés. Ce choix doit être effectué application par application, selon les besoins métier, les contraintes de sécurité et les capacités de gestion des terminaux.

Un déploiement entièrement imposé simplifie l’uniformisation des postes, mais risque d’installer des outils inutiles. À l’inverse, un libre-service sans restrictions rend le contrôle difficile. La solution consiste à appliquer des règles différenciées.

Le libre-service encadré peut réduire les interventions manuelles du support. Un collaborateur installe un logiciel approuvé sans ouvrir systématiquement un ticket. Il faut néanmoins vérifier cet effet à partir des demandes réellement enregistrées : aucun gain automatique ne peut être garanti.

L’objection selon laquelle le libre-service ferait perdre le contrôle repose sur une confusion. L’utilisateur décide du moment de l’installation, mais l’entreprise conserve la maîtrise de l’éligibilité, des droits et des conditions de distribution. Les quotas de licences ou les validations particulières restent applicables lorsqu’ils sont nécessaires.

Dans Microsoft Intune, la documentation Microsoft Intune sur l’affectation des applications aux groupes distingue notamment les intentions « requise », « disponible » et « désinstaller ». Leur fonctionnement exact varie selon la plateforme, le type d’application et le contexte d’inscription.

Le modèle doit aussi tenir compte des appareils personnels utilisés à des fins professionnelles, ou BYOD. Une entreprise peut accepter une gestion approfondie sur ses propres terminaux tout en limitant les mécanismes de contrôle sur les équipements personnels des collaborateurs.

Pour le BYOD, les recommandations de la CNIL sur la sécurisation de l’informatique mobile préconisent notamment l’évaluation des risques, la limitation des accès selon la criticité des données et le cloisonnement des usages professionnels et personnels. Ces recommandations françaises constituent un repère, sans remplacer l’analyse des règles applicables dans chaque pays francophone.

Une fois ces modes définis, la qualité du catalogue dépend surtout du processus de validation : aucune application ne devrait devenir disponible simplement parce qu’un collaborateur en a fait la demande.

Quelles vérifications effectuer avant de publier une application dans le catalogue interne ?

Avant d’intégrer une application au catalogue, le responsable IT doit vérifier sa sécurité, sa conformité juridique, sa compatibilité technique et son modèle économique. Il doit aussi désigner un propriétaire fonctionnel responsable de son suivi. Une période pilote permet ensuite de contrôler son fonctionnement et son intérêt métier avant d’autoriser une diffusion plus large.

La validation doit commencer par une fiche décrivant le besoin couvert, les utilisateurs concernés, l’éditeur, les systèmes compatibles et les données manipulées. Sans cette base, il devient difficile de justifier la publication ou de comparer deux outils concurrents.

L’examen de sécurité porte notamment sur les permissions demandées, les mécanismes d’authentification, les dépendances externes, la provenance du logiciel et la politique de maintenance de son éditeur. Il ne suffit pas qu’une application soit distribuée par une boutique officielle pour considérer tous ses usages comme adaptés à l’entreprise.

La dimension juridique comprend les conditions de licence, les traitements de données personnelles, les éventuels transferts de données et les engagements contractuels de l’éditeur. Les exigences exactes dépendent des pays, des activités et des catégories de données concernées.

Pour les terminaux personnels, il faut examiner le cloisonnement entre données professionnelles et personnelles. Une application qui mélange les fichiers de travail aux contenus privés peut rendre plus délicates la gestion des accès, la restitution documentaire et la suppression sélective des données de l’entreprise.

Le contrôle technique vérifie les versions minimales de système, les dépendances, les mises à jour et le fonctionnement sous les modes de gestion effectivement déployés. Enfin, l’analyse budgétaire doit préciser si le coût dépend de l’utilisateur, du terminal, d’un volume contractuel ou d’une fonctionnalité activée.

Le pilote peut être confié à un groupe réduit représentant les futurs utilisateurs. Les critères de sortie doivent être fixés à l’avance : fonctionnement des principales tâches, absence d’incident bloquant, capacité du support à traiter les demandes et adéquation avec le budget prévu.

Le propriétaire fonctionnel désigné doit rester identifiable après publication. Il pourra confirmer la pertinence de l’application, accompagner les évolutions métier et participer aux décisions de retrait.

Une application acceptée aujourd’hui ne conserve pas nécessairement son utilité ou son niveau de maintenance dans le temps. Le catalogue doit donc faire l’objet de réexamens réguliers.

Comment repérer les applications à retirer d’un catalogue devenu trop volumineux ?

Pour identifier les applications à retirer, il faut croiser les données d’installation, l’utilisation réellement observable, les licences consommées et l’état de maintenance des logiciels. Les applications peu adoptées, redondantes ou abandonnées par leur éditeur deviennent des candidates à la révision. La décision doit toutefois tenir compte des besoins des petits groupes métier.

Un catalogue trop volumineux finit par perdre son principal avantage : permettre aux collaborateurs de trouver rapidement les bons outils. Lorsque plusieurs applications semblent répondre au même besoin, les utilisateurs peuvent hésiter, solliciter le support ou chercher une solution hors du dispositif approuvé.

La revue peut s’appuyer sur plusieurs indicateurs :

• Un faible taux d’installation dans les groupes auxquels l’application est proposée.
• Des licences attribuées mais jamais activées.
• Une absence de mise à jour ou de maintenance identifiable de l’éditeur.
• Des fonctionnalités faisant doublon avec une application déjà approuvée.
• Un propriétaire fonctionnel absent ou incapable de justifier le maintien de l’outil.

Ces indicateurs signalent des situations à examiner, pas des décisions automatiques. Une application installée sur peu de terminaux peut être indispensable à un processus spécialisé. De même, l’absence de données d’activité ne prouve pas qu’un utilisateur ne s’en sert jamais.

Trois décisions doivent être distinguées.

La revue peut être alignée sur les échéances contractuelles, les exercices budgétaires ou les comités de gouvernance informatique. Cette périodicité limite l’accumulation et évite une opération exceptionnelle particulièrement perturbatrice.

Chaque décision doit laisser une trace : application concernée, motif, profils touchés, responsable de la validation et suite prévue pour les licences. Un registre de décision permet de reprendre le dossier lors d’un audit ou d’un changement d’équipe.

Les applications dépubliées ou supprimées peuvent aussi libérer des licences payantes. Le nettoyage du catalogue doit donc être relié à une analyse de la consommation contractuelle.

Comment détecter les licences mobiles sous-utilisées avant le prochain renouvellement ?

La détection des licences sous-utilisées consiste à comparer les droits attribués avec les données d’activation et d’usage disponibles, puis à examiner les écarts avant l’échéance contractuelle. Cette analyse doit commencer suffisamment tôt pour permettre une réaffectation, un ajustement de volume ou une négociation. Une licence inactive ne doit toutefois pas être résiliée sans vérifier sa fonction réelle.

Le premier ensemble de données provient des contrats, des consoles applicatives et des systèmes de gestion des comptes. Il indique les licences achetées, affectées et disponibles. Le second ensemble rassemble les signaux d’utilisation accessibles de manière légitime : activation d’un compte, connexion à un service ou usage déclaré par le propriétaire métier.

Ces informations ne sont pas toujours équivalentes. Une application installée n’est pas nécessairement utilisée, tandis qu’un compte qui semble inactif peut être conservé pour une activité saisonnière. Sur les appareils personnels, la collecte doit rester proportionnée et respecter les règles de confidentialité applicables.

Le diagnostic doit ensuite rechercher la cause de chaque anomalie :

• Départ d’un collaborateur : vérifier si son compte et sa licence ont été désattribués.
• Remplacement de terminal : contrôler si une attribution supplémentaire subsiste sans justification.
• Application non adoptée : comprendre si le problème vient du besoin, du déploiement ou de l’accompagnement.
• Usage occasionnel : confirmer si un accès permanent reste nécessaire ou si une autre formule est possible.

Le calendrier est déterminant. Une analyse réalisée après reconduction peut révéler des dépenses inutiles sans permettre de modifier immédiatement l’engagement. Le responsable IT doit donc connaître les délais de notification contractuels et travailler en amont avec les achats et les responsables métier.

La revue du catalogue constitue un déclencheur naturel : lorsqu’une application est dépubliée, son contrat doit être examiné, mais les licences des utilisateurs existants ne doivent pas disparaître avant la fin effective de leur besoin.

Ce diagnostic permet de distinguer les économies possibles des simples anomalies administratives. La prochaine étape consiste à intégrer la gestion des licences dans le cycle de vie des collaborateurs.

Comment gérer les licences mobiles sans payer pour des comptes inutilisés ?

Pour éviter de payer des licences inutilisées, l’entreprise doit relier leur attribution et leur retrait aux arrivées, départs et changements de fonction des collaborateurs. Elle peut ensuite réaffecter, rétrograder ou résilier les licences devenues superflues. Ce pilotage nécessite un inventaire fiable, des règles de désattribution et une analyse des possibilités réellement prévues dans les contrats.

La fuite des licences apparaît souvent lorsque la création d’un compte est automatisée, mais que sa suppression reste manuelle. À chaque arrivée, une licence est affectée. Lorsqu’un salarié part ou change de service, son ancien abonnement peut continuer à être facturé si aucune action de restitution n’est déclenchée.

Le problème touche aussi les comptes de test, les profils temporaires et les droits maintenus après une mobilité interne. Il est donc nécessaire de rapprocher trois référentiels : les identités des collaborateurs, les applications auxquelles ils ont droit et les licences effectivement attribuées.

Trois leviers peuvent alors être étudiés :

• Réaffecter : récupérer une licence inutilisée pour répondre à une nouvelle demande, lorsque le contrat le permet.
• Rétrograder : passer à une formule moins coûteuse si les fonctionnalités avancées ne sont plus nécessaires et si une telle formule existe.
• Résilier : supprimer les droits devenus inutiles, en respectant les conditions contractuelles et les besoins de conservation des données.

Le choix dépend de la durée d’inactivité observée, du besoin métier résiduel, du prix de la licence et de la flexibilité contractuelle. Une licence peu coûteuse mais indispensable à une activité ponctuelle ne doit pas être supprimée uniquement pour améliorer un indicateur.

Idéalement, le départ d’un collaborateur déclenche un processus coordonné : désactivation de ses accès, retrait des groupes d’applications, récupération des licences éligibles et traitement des données professionnelles selon les procédures internes. Les automatisations doivent être contrôlées afin d’éviter des retraits prématurés.

Au renouvellement, l’historique des attributions et de leur utilisation aide les achats à demander des volumes plus adaptés, des paliers évolutifs ou des possibilités de réaffectation. Ces dispositions restent soumises à la négociation et aux offres réellement disponibles.

Cette discipline budgétaire doit néanmoins s’accompagner d’une gestion prudente des suppressions. Retirer un logiciel sans préparer les utilisateurs peut interrompre un processus métier et compromettre des données de travail.

Comment supprimer les applications inutiles sans perturber les habitudes de travail ?

La suppression d’une application professionnelle doit suivre une transition progressive : identifier les utilisateurs concernés, annoncer le changement, préparer une solution de remplacement, transférer les données nécessaires puis organiser la désinstallation. Cette méthode limite les interruptions métier et donne aux collaborateurs le temps d’adapter leurs pratiques. Une suppression immédiate ne se justifie que lorsque le risque impose une intervention urgente.

Le retrait commence par une analyse d’impact. Le responsable IT identifie les terminaux concernés, les fonctions utilisées et les éventuelles dépendances. Une application peu présente dans le catalogue peut être essentielle à un petit service qui utilise une fonctionnalité spécifique ou un processus non documenté.

Cette vérification doit être conduite avec le propriétaire fonctionnel et un échantillon représentatif d’utilisateurs. Elle permet notamment de repérer les fichiers conservés localement, les configurations particulières et les automatisations qui dépendent de l’application.

Une transition standard peut ensuite suivre quatre phases :

1. Informer : expliquer la raison du retrait, les échéances, les utilisateurs concernés et le canal d’assistance disponible.
2. Préparer le remplacement : publier la nouvelle application pour les groupes concernés, vérifier les droits et accompagner les utilisateurs.
3. Dépublier : empêcher les nouvelles installations de l’ancien outil, tout en maintenant temporairement les environnements nécessaires à la transition.
4. Désinstaller : retirer l’application une fois les dépendances traitées, les données sécurisées et les critères de fin de migration validés.

La conservation des données mérite une attention particulière. Les documents, éléments hors ligne et paramètres stockés dans le conteneur applicatif doivent être identifiés avant la suppression. Selon la plateforme, la disparition de l’application peut entraîner celle de données locales qui n’ont pas été transférées.

Sur les appareils Apple compatibles, le guide officiel de distribution des apps gérées explique que les applications peuvent être installées, mises à jour et supprimées au moyen d’un service de gestion. Il précise également que, sur iPhone, iPad et Apple Vision Pro, la suppression d’une application gérée entraîne celle des données associées à son conteneur. Cette conséquence doit être intégrée au plan de migration.

La dépublication ne doit pas être confondue avec la désinstallation. Retirer une application de la liste des outils proposés peut empêcher de nouvelles demandes sans modifier immédiatement les installations existantes. Ce comportement doit cependant être vérifié dans la solution de gestion, car les actions et leurs conséquences diffèrent selon les plateformes et les politiques configurées.

Le succès d’un retrait ne se mesure pas uniquement au nombre d’applications supprimées. Il dépend aussi de la capacité des utilisateurs à accomplir leurs tâches avec l’outil de remplacement, de l’absence de données perdues et de la fermeture effective des licences devenues inutiles.

Une période d’observation après migration permet d’identifier les difficultés restantes. Les demandes de support, les incidents métier et les éventuelles réinstallations non prévues constituent des signaux utiles pour confirmer la fin de l’opération.

Pour engager cette démarche, le responsable IT peut commencer par inventorier les applications actuellement installées, identifier leurs propriétaires métier et sélectionner un premier groupe pilote. Il devient alors possible de construire un catalogue approuvé, de tester ses règles de distribution et de mettre en place un cycle régulier de validation, de suivi et de retrait, sans bouleverser simultanément les habitudes de toute l’entreprise.