Le choix d'un MDM/EMM{ #mdm_choosing }¶

Lors du choix de la solution MDM, il est important de définir les fonctionnalités qui seront considérées comme obligatoires et celles qu'il est souhaitable d'avoir. Cela peut considérablement varier d'une implémentation à l'autre ; cependant, nous avons identifié certaines fonctionnalités comme obligatoires dans la liste ci-dessous en raison de la nature du DHIS2. Bien que cela puisse être revu en fonction de l'implémentation, ces caractéristiques devraient être considérées comme notre recommandation.

Voir l'annexe A - Gestion des terminaux mobiles pour plus de détails.

Caractéristiques requises et leur raison d'être :

• Android comme une plateforme prise en charge :

  This might seem obvious but some MDM solutions are aimed at other types of devices like iOS or Windows. At the moment the DHIS2 Android App is only compatible with Android devices, and it supports from version 5 (not recommended) and above (we recommend from version 7).

• Application(s) distribution management:

  DHIS2 implementations need to test and train users before releasing a new App version. As most of the implementations install the DHIS2 Android App from the Google Play store, when an update is published there the devices could be updated without the project being ready if there is no other mechanism in place to manage updates.

• Informations sur le dispositif :

  DHIS2 implementations need to maintain an inventory of their devices in order to troubleshoot issues or to update their devices. All the MDM solutions considered include this a basic feature but it is listed here just in case a solution exists that may not include this.

• Utilisation d'un mot de passe :

  In most (if not all) DHIS2 implementations, sensitive information is stored in the application. Therefore enforcing a password policy on the device may prevent undesired access to this data.

  Note that despite the DHIS2 Android Application allowing the possibility to set a password for access control, because the information in the device is not yet encrypted (Feb 2020) it could still be extracted by an attacker.

• Suppression à distance :

  In most (if not all) DHIS2 implementations sensitive information is stored in the application. If for instance a device is lost or stolen, ensuring that it can be remotely wiped can help prevent the leakage of sensitive data.

Il serait bon d'avoir des caractéristiques et leur raison d'être :

• Mode kiosque (mode AKA à application unique)

  Some DHIS2 implementations might require the devices to be locked down to a single application (DHIS2 Android Capture App) without allowing the user to access any other application or settings. A kiosk policy would achieve this.

• Gestion du téléphone

  In some DHIS2 implementations it might be required to use devices with SIM cards in order to provide data connection over a mobile network (2G-5G). This might require the devices to use specific calling services in order to recharge data bundles or to limit call support, etc.

• Restrictions relatives aux applications/paramètres

  Some DHIS2 implementations might require the users to be able to use not only one but several applications (i.e. a device that needs to be used for DHIS2 and picture capturing).

• Gestion du réseau

  Some DHIS2 implementations might require the devices to not use the data network, or limit to specific domains (firewalling) or to always use only specific wireless networks or setting up dynamically the wireless networks, etc.

• Gestion des utilisateurs

  Some DHIS2 implementations might require the devices to be used by several users (even two DHIS2 users). User management functionality can increase the level of security in this scenario, as each user could have different access codes, allowing multi user accounts for DHIS2 Android Capture App (currently not natively supported), several application policies per user, etc.

Prix initial et frais de fonctionnement¶

L'un des facteurs critiques auxquels les projets seront confrontés lorsqu'ils décideront d'implémenter un MDM est le prix initial et les frais de fonctionnement. Un MDM peut entraîner des frais imprévus, il est donc recommandé d'évaluer le besoin et d'inclure ses frais le plus tôt possible dans la définition du projet et du budget.

La plupart des solutions MDM présentées dans les sections suivantes incluent des frais de fonctionnement mensuels ou annuels qui peuvent augmenter considérablement le coût du projet en fonction du nombre d'appareils. Il est donc conseillé de suivre les conseils suivants :

1. Si le projet a la capacité d'héberger la solution MDM sur ses serveurs, il s'agit généralement d'une meilleure option que de choisir une solution incluant l'hébergement.
2. Certains donateurs peuvent imposer le choix d'une solution de MDM spécifique. Si c'est le cas, assurez-vous que le budget est alloué pour les étapes futures du projet ou que le MDM peut être utilisé gratuitement (ou moins cher) avec un ensemble d'options limité.
3. La plupart des solutions proposent différents forfaits comme modèle de tarification. Si la solution est principalement (ou uniquement) utilisée pour gérer l'application DHIS2 (installation et mise à jour), l'utilisation sera minime et le choix de la solution la moins chère sera probablement suffisant.
4. En raison de la nature de la plupart des projets (santé dans les pays en développement, ONG, éducation, etc.), de nombreux fournisseurs de MDM seront probablement en mesure d'offrir une réduction. Une négociation avant de choisir une solution est vivement recommandée car, pendant la rédaction de ce document, de nombreux fournisseurs se sont montrés intéressés et ont déjà proposé des offres plus intéressantes que celles annoncées sur leurs sites.

BYOD / Dispositif d'entreprise¶

Un autre facteur clé dans le choix du MDM/EMM à utiliser est de savoir si le déploiement inclura une politique BYOD ("Apportez votre propre terminal") ou s'il ne fonctionnera qu'avec les terminaux de l'entreprise. Il peut s'agir d'un facteur critique car la plupart des MDM différencieront les politiques qui peuvent être appliquées à ces deux types d'appareils. De nombreuses implémentations DHIS2 sont basées sur des terminaux d'entreprise uniquement, mais dans certaines implémentations, une politique mixte BYOD-entreprise ou même une politique de terminaux BYOD complète pourrait être possible.

Une configuration BYOD implique d'avoir un MDM qui autorise un ensemble minimum de politiques conformes aux caractéristiques obligatoires énumérées ci-dessus. En fonction du MDM, un profil de travail peut être nécessaire pour installer l'application DHIS2. Dans ce cas, la formation peut s'avérer encore plus importante pour expliquer les différences entre les profils. Par exemple, un utilisateur dont l'application DHIS2 est installée dans son profil personnel (ainsi que dans son profil professionnel) présente des risques supplémentaires pour la sécurité des données, car les données stockées dans son profil personnel ne peuvent pas être effacées à distance en cas de perte ou de vol de l'appareil.

Une configuration d'entreprise implique que tous les terminaux soient soumis à un ensemble de règles plus strictes (qui peuvent varier selon les terminaux, les utilisateurs et les lieux). C'est la situation idéale du point de vue de la gestion informatique, mais elle aura un impact sur la flexibilité et les coûts.