Le contenu idéal d’un back-office pour Mobile

La mobilité ou Nomadisme (terme à choisir en fonction de votre religion MOA/MOE) est au centre des préoccupations de milliers de DSI aujourd’hui. Il y a clairement quelque chose à faire dans ce milieu et on le récent depuis plusieurs années.

Mais c’est réellement depuis l’année dernière nous assistons à un énorme boom autour de la mobilité et plus particulièrement des applications mobile. Les applicatifs mobile métiers ont le vent en poupe.

Pourquoi? Tout simplement parce qu’elles apportent un certain dynamisme (ou un dynamisme certain) dans le cycle de fonctionnement d’une entreprise. Prenons un exemple simple: Une entreprise qui vend un produit A à l’aide de commerciaux nomades (beaucoup plus jolie que VRPouille).

Aujourd’hui, un grand nombre d’entreprises que je connais travaillent de deux manières différentes:

• Lorsque le commercial est en face du client, il rempli un bon de commande sur papier, puis le fait signé par son client. S’ensuit, après le rendez-vous, une longue discussion téléphonique avec une secrétaire de saisie, qui passe sa journée à taper les bons de commande de ses commerciaux dans l’ERP de la maison. Il est clairement établit que ce fonctionnement est souvent source d’erreur. De plus la fameuse secrétaire (oui bon je sais, ce n’est pas forcément une femme, mais cela simplifie mon discours) n’étant pas encore devenue un octopode, elle ne peut renseigner qu’une commande à la fois. Et c’est souvent générateur de bouchon téléphonique, très dommageable pour l’entreprise.
• Lorsqu’un commercial se retrouve face à un client (oui encore une fois, mais en même temps c’est son boulot), il ouvre son magnifique PC portable et renseigne ses commandes dans un beau logiciel tout neuf. Bon le reste parait évident, le soir, le commercial synchronise de chez lui ou de l’Hôtel ses commandes avec le Quartier Général. Ce type de solution est problématique quand on travail en flux tendu, ou dans des métiers où la livraison doit se faire le lendemain (d’où la secrétaire de saisie plus haut).

Maintenant que vous avez bien compris la problématique, le reste coule de source. Il faut avoir une application mobile, qui fonctionne en mode connecté ou déconnecté (on a pas toujours accès à ce *ù$^ù$£ de réseau 3G/EDGE/GPRS/Pigeon voyageur) sur un Pocket PC, Smartphone, Tablet PC, …

Cela évitera beaucoup d’erreurs de ressaisie et permettra à n’importe quelle société de travailler en flux tendu.

Bon voilà, l’idée est posée, utilisée, et maintes fois appliquées depuis quelques années. Cependant, ces applications, mêmes si elles sont belles, merveilleuses, rapides, pratiques (c’est pas vraiment toujours le cas), elles n’ont pas un back-office (une arrière boutique) super méga géniale Top Cool. hé oui, en terme marketing, si le Front-office est beau, fonctionnel etc… ça suffit, et puis tant pis pour les utilisateurs du back-office, ce ne sont pas des clients, ils vont s’adapter.

Et c’est là que c’est une très mauvaise idée sur plusieurs points. Donc je me contenterais de vous donner une série de points à penser très fortement puis à appliquer très rapidement afin d’avoir un Back-Office Mobile optimal!

Back-office côté application mobile

Il est vraiment très agréable quand un applicatif mobile propose ce genre de petits points:

• Une interface de connexion (parce que si on te vole ton mobile, t’es pas bien…)
• Des fichiers de logs,
• Une vraie gestion d’erreur,
• Une gestion de mise à jour,
• Un mode debug,
• Une gestion des préférences,
• Un framework afin de crypter les données en transit (C’est mieux de ne pas les envoyer en clair au monde entier)

Vous me remercierez quand vous verrez que la flotte des 700 mobiles que vous venez d’équiper de votre magnifique applicatif commencera à bugger sans que vous ne trouviez de raisons…

Back-office côté Serveur de l’application Mobile

Alors c’est tout pareil que sur l’applicatif mobile, mais n’oubliez pas une chose: Il y a des utilisateurs qui vont travailler avec le back-office! Alors merci de les choyer!

Pour conclure, l’idée que je souhaitais faire passer n’est pas compliquée: C’est pas parce qu’on est sur un environnement Mobile, un applicatif Mobile, ou ce que vous voulez lié à la mobilité, qu’il faut voir petit, faire les choses à la va vite, ne pas penser la conception, ne pas penser l’utilisation, … C’est une application comme une autre, et elle doit être pensée comme telle.

Pourquoi croyez-vous que les framework de développement propose des librairies de gestion d’erreurs, de gestion de logs, de crypto, … ???