MDM et smartphones en 2013: pourquoi il ne faut pas jeter "BB" avec l'eau du bain ?

Un smartphone a peu ou prou le même coût qu'un téléviseur, un ordinateur de bureau, un camescope, un réfrigérateur, etc. sauf qu'en le changeant tous les ans ou presque ça en fait un marché ou les positions des constructeurs changent extrêmement vite. Avec évidemment des percées et des reculs spectaculaires chaque année. De ce point de vue là, BlackBerry (BB) passe une sale année 2013. A tel point que certains enterrent (un peu vite) la solution.

C'est oublier -il me semble- que BB n'est pas une marque de téléphones mobiles comme les autres. C'est un ensemble "terminal ET solution logicielle de gestion de flotte" ("Mobile Device Management" ou MDM). Si le grand public n'a pas grand intérêt pour cette deuxième brique logicielle "MDM", elle rend par contre beaucoup de service à ceux qui gèrent des parcs de plusieurs dizaines, centaines, ou milliers de terminaux au sein d'une entreprise.

C'est là que s'est construite la réputation de BB: des terminaux simples, fiables, qui n'avaient peut-être pas l'ouverture et les capacités multimédia de certains concurrents mais qu'il était très simple de déployer à des centaines d'utilisateurs, sans coûts exorbitants de support et de maintenance auprès de l'utilisateur final. Pas besoin d'expliquer par exemple à un utilisateur comment saisir l'adresse de son serveur de messagerie, ni comment synchroniser les annuaires, ou encore comment il fallait changer son password quand on changeait de password au bureau, etc.

La force de la solution résidait dans la gestion "bout en bout", du terminal jusqu'au serveur de gestion des terminaux.

C'est sans doute là l'enjeu principal des actuels éditeurs de MDM concurrents: parvenir à assurer la gestion précise de terminaux dont les systèmes d'exploitation évoluent très vite et sont abondamment "customisés" par les constructeurs. Par exemple, assurer une bonne gestion de la sécurité Android devient compliqué quand on a chaque mois des dizaines de nouveaux terminaux qui sortent, avec des implémentations différentes des couches applicatives (on parle de "fragmentation": il semble qu'on parle actuellement de plus de 10 000 terminaux Android différents par an!). Et cette compatibilité ne concenre pas que d'obscures fonctions de sécurité avancées: la simple gestion distante du logiciel de messagerie entreprises sur des terminaux hétérogènes Android n'est pas anodine..

Je rencontre beaucoup de DSI en ce moment qui se posent la question de l'avenir de leur flotte BB.

En gros, il y a 3 grandes stratégies:

Rester sur la technologie BB "legacy" (terminaux BB avec l'OS Java BB 7 et serveurs BES 5)

Ce choix a deux avantages principaux et deux inconvénients.

Passer à Blackberry 10

Ce choix amène à installer les nouveaux serveurs BES 10 et à déployer des terminaux compatibles (BB10 ou iOS ou Android)

Passer à autre chose

Passer à autre chose, c'est se poser la question d'installer -ou pas- une solution de MDM pour gérer son parc de terminaux mobiles d'entreprise.

On peut ne rien installer et considérer que la maturité des utilisateurs en 2013 est suffisante pour qu'ils se "débrouillent" de leur paramétrage de messagerie d'entreprise, évitent d'installer n'importe quelle application, se comportent "raisonnablement" en situation de roaming, et ne demandent aucun support en cas de problème. D'une certaine manière, c'est comme si on donnait les "droits administrateurs" aux salariés de l'entreprise sur leur PC/portable de bureau en leur autorisant d'installer les applis de leur choix. C'est possible, mais il n'y a pas encore eu beaucoup de sociétés avec plusieurs centaines de postes qui s'y risquent (d'un point de vue financier, sécurité, ou RH/droit du travail, d'ailleurs).

On peut objecter au contraire qu'il n'a jamais été autant utile d'avoir une solution de MDM, pour contrôler/restreindre les usages.

Après tout on parle d'accès aux ressources SI de l'entreprises (sécurité), et d'enjeux financiers (coût des usages en mobilité, support des utilisateurs). Et ce, à un moment ou l'offre applicative explose sur les stores applicatifs, et ou le pire côtoie le meilleur; une startup californienne, Appthority, propose par exemple un système de notation de dangerosité des applications mobiles; cela permet par exemple d'interdire aux utilisateurs en entreprise d'installer des programmes dont le niveau de risque dépasse certains critères.

Il existe de nombreuses solutions de MDM, certaines très performantes. C'est un marché qui bouge très vite, avec beaucoup d'acteurs spécialisés et une tendance de fond à la "cloudification" plutôt qu'à l'installation de serveur dans le SI client.

Enfin comme mentionné plus haut, pour qu'une solution MDM fonctionne parfaitement il faut maitriser les 2 extrémités: la solution MDM d'un coté, et le choix des terminaux pleinement compatibles de l'autre. Si vous êtes DSI, soit vous demandez cet effort de conseil et de qualification à votre prestataire (SSII, opérateur mobile, etc), soit vous le faites faire en interne. Cela représente une charge récurrente, qui a un coût. En synthèse, il est bien difficile de lire dans la boule de cristal concernant l'avenir de tel ou tel fabricant de terminaux mobiles. Par contre dans le cas particulier des flottes d'entreprise, la question de la gestion applicative du parc (MDM) n'est pas neutre en terme de sécurité et de gestion des coûts. Dans ce domaine, il ne faudrait pas jeter BB avec l'eau du bain, car la solution représente sans doute l'un des meilleurs retours d'expérience dans le domaine. Dont on peut s'inspirer, que l'on décide d'avoir un parc de Blackberry ou pas.

NB: je parle ici de l'intérêt de la solution technologique BlackBerry, pas de la pérénité de l'entreprise Blackberry en tant que telle; je ne connais pas sa situation exacte; au vu des grands noms qui se semblent s'être montrés intéressés par la société, on peut raisonnablement penser qu'elle dispose de sérieux atouts stratégiques (pas seulement son parc client, mais aussi pas mal de brevets notamment à propos de la cryptographie à base de courbes elliptiques).

disclaimer note: ces propos n'engagent que leur auteur