Voici les 8 principaux écueils référencés par les équipes d’IBELEM :

Sous-estimer l’impact du projet sur l’entreprise :

Il ne s’agit pas simplement de livrer un terminal à un utilisateur. Ces projets répondent à des objectifs qui doivent être fixés en amont (gains en productivité et compétitivité, simplification des processus, optimisation du travail quotidien) et partagés avec les collaborateurs. A défaut d’adhésion au projet, le terminal peut être considéré comme simple accessoire supplémentaire et être, de ce fait, sous-exploité voire inutilisé. Par ailleurs, au-delà des aspects sécuritaires et technologiques, l’intégration de ces outils au sein de l’entreprise a des impacts au niveau RH, juridique, financier puisque on touche à de nombreux aspects : délimitation des sphères privée et professionnelle, horaires de travail, dotations...

Dans ce contexte, on ne saurait trop recommander de mettre à jour sa charte technologique et d’adopter une démarche de conduite du changement au sein de l’entreprise.


Traiter les sujets indépendamment les uns des autres sans ordonnancement et sans pilote

On peut constater, sur les  projets de déploiement de terminaux mobiles et d’applications, une désorganisation qui ne reflète pas les méthodologies de travail habituelles de la DSI : il manque souvent un chef d’orchestre pour piloter le projet dans sa globalité.

Il est important de prendre conscience que le projet initial se décline en de multiples sous-projets périphériques imbriqués les uns dans les autres, chaque projet ayant un impact sur les autres et chaque choix des conséquences structurantes. Parmi la multitude de sous-projets ou sujets à traiter, on peut citer : la définition de la politique de sécurité, l’estimation du ROI, le choix de la technologie de développement des applications, le choix des tablettes, de l’OS, des solutions de Mobile Device Management (MDM) et d’anti-virus... Il faut également se poser la question du mode de fonctionnement : faut-il internaliser ou externaliser tout ou partie du projet (développement des applications, administration des solutions...)?  

Certaines sociétés ont déjà choisi le terminal avant même d’avoir entamé la réflexion sur les usages et applications! Il faut impérativement penser ces multiples projets concomitamment et nommer un chef de projet disposant de moyens de pilotage transverses.


Mal identifier les besoins fonctionnels utilisateurs


Les DSI ont trop souvent tendance à établir leur cahier des charges global à partir des fonctionnalités du terminal et/ou de la solution de MDM testée et passent trop rapidement sur la phase d’identification des besoins fonctionnels utilisateurs. Pourtant, cette étape est primordiale pour la réussite et la crédibilité du projet. De son bon déroulement, qui est l’expression la plus visible de la gouvernance mobilité, découle l’adhésion aux arbitrages qui seront faits ultérieurement.

Donner la parole aux directions métier et aux utilisateurs permet également de déterminer les niveaux de service à fournir ultérieurement et les process à mettre en œuvre pour la phase de post-déploiement.


Choisir le mauvais OS mobile et/ou le mauvais constructeur


Le choix des OS mobiles et des modèles de terminaux est crucial. De ces choix découleront certaines possibilités ou, au contraire, certaines restrictions. De nombreuses questions se posent : technologie de développement des applications, sécurité native de l’OS, possibilité de gestion distante, règles inhérentes à la création et à l’utilisation des comptes utilisateurs (iTunes, Google, Live ID) qui ne sont pas homogènes sur tous les OS. En effet, les OS mobiles actuels dépendent d’un compte utilisateur personnel (iTunes, Google, Live ID). Il faut, par exemple, bien mesurer les conséquences d’une mauvaise gestion de ces comptes : utilisation abusive des numéros de CB, inconvénients de l’utilisation d’un compte générique sur tous les terminaux…Il faut également bien considérer les surcouches logicielles proposées par les constructeurs. Elles permettent souvent d’étendre les fonctions de gestion et de renforcer la sécurité native des OS.



Rappelons que, d’une manière générale (même dans le cadre de la mise en place d’un programme de BYOD), la DSI doit garder la maîtrise du périmètre des OS et modèles de terminaux mobiles supportés. Les plateformes qui ne respectent pas les politiques de sécurité ne doivent pas être intégrées sous la pression des utilisateurs. L’application de cette règle de base permet d’éviter, notamment, des coûts de formation et de gestion supplémentaires sur des plateformes non maîtrisées.



Et bien sûr, le terminal en lui-même doit être choisi en fonction de l’utilisation qui en sera faite en déplacement et donc reposer sur des critères tels que : ergonomie, autonomie, robustesse…



Choisir une solution de MDM sans avoir listé l’ensemble des prérequis et de ses besoins



Trop souvent encore, on constate que la DSI perd un temps précieux ou fait les mauvais choix faute d’avoir listé exhaustivement les prérequis et besoins opérationnels relatifs à la solution de MDM.

On citera le cas d’une entreprise qui a effectué un POC (proof of concept) pendant plus d’un mois d’une solution mobilité en mode SaaS avant de se rendre compte qu’elle perdait son temps. En effet, la solution était hébergée à l’étranger alors qu’une des conditions sine qua none (non exprimée) était un hébergement en France. Autre cas rencontré : un DSI qui a dû abandonner très rapidement la solution qu’il avait récemment installée. Son administrateur a refusé de l’utiliser, l’interface étant disponible uniquement en anglais.



Négliger les phases de POC (proof of concept) et les pilotes


Les POC et pilotes doivent être réalisés avec application et sur des durées confortables. Ils permettent de tester tous les composants de la solution globale et à chaque étape du projet : applications, terminaux, solution de MDM (fonctionnalités, profils de déploiement, mise à jour des OS mobiles…). On voit encore, par exemple, des déploiements massifs de nouvelles applications ou nouvelles versions d’applications non testées préalablement.


Les pilotes et les POC permettent également d’enrichir sa liste de prérequis ou, au contraire, d’ouvrir le champ des possibilités. Ils permettent aussi de valider les processus relatifs au déploiement et à la phase de vie courante.


Sous-estimer les compétences nécessaires à la maîtrise des solutions


Les solutions de gestion de flottes mobiles permettent, de manière centralisée, de couvrir un champ fonctionnel toujours plus important. Les sujets tels que possibilités d’interconnexion avec vos infrastructures internes, outils de sécurisation de vos développements mobiles, sécurisation de vos flux réseaux ne doivent pas être oubliés. Ces fonctionnalités font intervenir des compétences totalement différentes. Il est rare qu’un collaborateur les ait toutes acquises.


Par ailleurs, les solutions de MDM évoluent en permanence (souvent plus de six mises à jour par an) avec un enrichissement fonctionnel et parfois aussi des modifications profondes de l’arborescence de l’interface déstabilisant parfois les administrateurs. Considérant ces solutions comme très intuitives, les administrateurs ont tendance à faire l’impasse sur les formations. De fait, ils ne connaissent ou ne maîtrisent pas nécessairement toutes les fonctionnalités de ces logiciels.


A titre d’exemple, une société nous a contactés pour changer sa solution de MDM alors même que l’outil déjà utilisé répondait en tout point au cahier des charges communiqué. Dans ce contexte, des formations initiales et continues sont fortement recommandées.


Se focaliser sur le déploiement en occultant la vie courante (post-déploiement)


Tellement focalisée sur les choix à faire en amont et la réussite du déploiement, la DSI a tendance à minimiser ses efforts sur la phase post-déploiement.


Tout d’abord, il ne faut pas oublier que les utilisateurs ne sont pas tous aussi technophiles que les informaticiens. La tablette peut constituer une véritable rupture avec leurs usages habituels. C’est la raison pour laquelle les collaborateurs apprécient de recevoir un guide d’utilisation personnalisé du terminal. Ce guide peut inclure une liste de « trucs et astuces » sur l’utilisation quotidienne du terminal  comme, par exemple, les fonctions à désactiver pour économiser la batterie. Autoriser l’utilisation d’un terminal professionnel dans un cadre personnel peut également être un bon moyen de contribuer à l’appropriation de ce nouvel outil.


Dernier point, il faut prévoir tous les cas de figure pouvant se présenter post-déploiement que ce soit au niveau de l’utilisation du terminal par le collaborateur (vol, casse…) que de l’évolution des différentes solutions (ex : impact d’une mise à jour d’OS sur les applications installées). Tous ces points doivent faire l’objet de process écrits et communiqués à l’utilisateur final.



En conclusion, les impacts de ce type de projets dépassent bien souvent les projections. Il convient de prendre son temps et, surtout, de respecter les principes qui régissent la gestion de projets informatiques, principes trop souvent oubliés quand il s’agit de projets mobilité.

Par ailleurs, il ne faut pas hésiter à faire appel à des spécialistes qui, au-delà des phases de POC et de déploiement, vous accompagneront en amont et en aval sur votre projet. Ils vous feront bénéficier de leur expérience et vous aideront à faire les bons choix.