Au secours, ma compta est dans les nuages

Ou pourquoi utiliser ou ne pas utiliser le Cloud pour ses données métier

cloudChef d’entreprise s’aventurant dans le Cloud

Lors d’une discussion avec un de mes amis jeune et dynamique chef d’entreprise dans les telecom, je lui ai parlé de nos solutions de saisie de rapport en ligne, et sa réponse a été « Ah non, si c’est dans le Cloud, je refuse! ». Un client m’a dit un autre jour « si c’est dans le Cloud, c’est super! ». Le seul point commun est que dans mon argumentaire, non seulement le cloud n’était pas le sujet, mais en plus je n’ai même pas cité le mot.

A l’instar de Web 2.0 ou de Big Data, le mot Cloud est sur toute les lèvres et est employé à toutes les sauces. De Microsoft à Sales Force en passant par SAP, Google, Apple, Amazon, tous proposent des services de stockage sur le Cloud ou des applications en mode SaaS (service à a software), allant jusqu’au logiciel personnalisable dans le cas de Sales Force. Mon intention est donc ici de rationaliser le débat et de percer le brouillard pour expliquer les caractéristiques, avantages et inconvénients fonctionnels des différentes solutions d’hébergement de vos données, Cloud y compris.

Avant tout, réponse à la première des questions : qu’est-ce que le Cloud? Je ne me substituerai pas ici à Wikipedia, qui possède d’ailleurs un très bon article sur le cloud ici. Vous constaterez d’ailleurs en le lisant que la notion de Cloud Computing ne date pas d’hier. Je vais plutôt prendre le mot de Cloud dans l’acception globale et indiquer les différences entre une application métier locale, une métier application hébergée sur un serveur et une application métier Cloud.

L’application locale est une application que vous exécutez à 100% sur votre ordinateur. Prenons par exemple Excel : c’est une application qui charge un fichier présent sur votre ordinateur ou sur un ordinateur de votre réseau et qui effectue les calculs en utilisant les ressources mémoires et processeur de votre ordinateur : si celui ci rame, Excel rame.

Pour une application métier hébergée sur un serveur, vous récupérez sur votre ordinateur des données stockées à distance, et les calculs sont effectués par le serveur distant. Ce serveur est clairement identifié, c’est un (ou plusieurs) support(s) physique(s) situé(s) à un endroit précis. Cela permet à plusieurs personnes de synchroniser et de mutualiser leur données.

La grande différence avec un service Cloud (Microsoft, Google, Sales Force ou autre) est que vous ne savez ni où sont précisément les données, ni qui effectue les calculs, et cela n’a de plus aucune importance! Vous n’avez qu’un point d’entrée défini, et le fournisseur s’occupe du reste, en vous garantissant une efficacité et un niveau de service constant.

Maintenant quid de ces solutions pour des données métiers, qui sont sensibles pour votre entreprise?

Dans un premier temps, j’aimerais tout de suite démolir une idée préconçue, qui est que conserver des données chez soi est plus sécurisé que de les avoir chez un hébergement professionnel. Cette idée vient de l’argument en apparence valable  que les données stockées sur un cloud ou sur un hébergeur professionnel sont accessibles par un point d’entrée public du Web, donc à priori plus simple à trouver et surtout plus tentantes pour un hackeur. Les photos de célébrités dénudées qui ont été extraites du Cloud Apple sont des exemples typiques (même si l’erreur de sécurité ne vient pas d’Apple, j’écrirai un article dans quelques semaines à propos de la sécurité).

Même en prenant en compte cet argument, pour être au minimum aussi sécurisé qu’un (bon) hébergeur professionnel, il faut prendre toutes les précautions qu’il prend : sécurité contre le vol, les incendies, les coupures de courant et les hausses de température, réplication et sauvegarde régulière des données, mise à jour des sécurités logicielles, pares feu… Au contraire donc, si vous voulez la sécurité, ne conservez pas votre application chez vous ou mettez en place des infrastructures complexes et coûteuses.

Maintenant quels sont les avantages de stocker des données sur le Cloud, ou d’utiliser les nombreuses applications accessibles en mode SaaS :
accéder à vos données de partout : dès que vous avez du réseau, vous avez un point d’entrée qui vous permet d’accéder à votre application ou à votre site. Si vous donnez un accès à quelqu’un partout dans le monde, il pourra accéder à vos données aussi facilement que vous (remarquez bien que ce côté n’est pas forcément très positif).
profiter des mises à jour d’une application immédiatement : quand une application cloud est mise à jour et propose des nouvelles fonctionnalités, celles ci sont disponibles pour tous les clients du Cloud. Pas d’installation, pas de frais de licence, le vrai plug and play.
mutualiser les ressources et lisser les coûts : par rapport à posséder un hébergement dédié, l’accès à un Cloud est moins cher (voir gratuit), l’investissement de départ nul, et les coûts d’utilisation et de licences fixes.

Maintenant sortons un peu du tableau idéal de ce type de solution pour parler de l’inconvénient principal : vous ne savez pas où vos données sont stockées. Quand les données sont stockées chez vous, vous avez le support sur les yeux; quand les données sont stockées chez un hébergeur dédié, il peut vous fournir un support avec des données voire si la machine vous appartient vous la rendre.

Ce que cela implique :
la non garantie de l’intégrité des données : aucun des grands du marché, même ceux qui proposent des contrats de SLA très précis ne garantit l’intégrité des données. Il est ici nécessaire de tempérer le caractère catastrophiste de ce que j’écrit ici : l’accord est beaucoup plus tacite, c’est un accord de réputation. Google, Amazon ou Microsoft n’a aucun intérêt à ce que vos données disparaissent, mais cela relève plus de la publicité mensongère que de la rupture de contrat.
la non maîtrise de l’existence ou non d’un fichier : quand vous supprimez un fichier ou une données sur le cloud, la suppression est dans un premier temps en tout cas logique (ce qui veut dire que la données est toujours physiquement disponible). Ceci veut dire que contrairement à quand vous posez un aimant sur un disque dur, quand vous supprimez un fichier sur un espace de stockage Cloud, vous ne savez pas quand celui ci sera réellement supprimé, ni même s’il l’a été.
des difficultés en cas de perte de service : les données peuvent être toujours présentes sur les serveurs mais le service non accessible, ce qui entraîne tout autant une perte des données pour votre entreprise. L’exemple de MegaUpload et de sa fin brutale est très parlant, mais on peut aussi imaginer une coupure de service pour raison de coupure réseau entre deux pays (matérielle ou diplomatique), etc…
Tout ceci signifie que la conservation (et la confidentialité, CF cet article de mon directeur technique) de vos données métier dépend donc de paramètres que vous maîtrisez beaucoup moins.

En conclusion, concernant vos données métier sensibles, je ne suis pas un amateur du « tout chez moi », et malgré mon métier je ne suis pas non plus un ayatollah de l’hébergement dédié. Par contre l’utilisation d’une application Cloud implique une réflexion en amont sur un plan de sauvegarde et de récupération régulière des données présentes en ligne.

En clair, si vous envoyez votre entreprise dans les nuages, prévoyez une piste d’atterrissage et un parachute !

Réussir un projet – Episode 1 : décider de lancer le projet

 280px-Leaning_tower_of_pisa_2Avant de faire les plans, il fallait vérifier le terrain…

Lors d’une discussion avec un ami à propos de l’aviation civile, activité dangereuse s’il en est, celui ci m’a donné un conseil plein de bon sens : « le secret de la survie en avion, c’est de savoir quand ne pas décoller ».

On pourrait croire que je ne prêche pas pour ma paroisse en écrivant cet article sur la prise de décision, avec comme objectif d’indiquer quand renoncer, mais je préfère les projets qui réussissent, et à l’instar de cette illustration, il existe des projets mourants avant même leur conception. Ce temps de réflexion ne sera pas perdu, il ne s’agit pas de temps supplémentaire, mais d’anticiper une phase qui a lieu quoi qu’il arrive.

Volontairement ici je ne me poserai pas la question du budget, celle-ci sera évoquée lors de mon article sur l’avant-vente. De la même façon je ne parlerai pas ici d’une application grand public, mais bien d’une application métier.
Voici donc les questions à se poser avant de décider de refondre une application, de concevoir une nouvelle application pour un métier existant, ou même d’acheter un nouveau logiciel sur l’étagère.

Commençons par la question évidente : pourquoi ce projet? La réponse à cette question peut être technique (utiliser des outils plus modernes, abandonner une technologie passée de mode ou non maintenue),  mais pour moi si cette raison est la seule, elle ne sera pas comprise par l’utilisateur final. Le pire scénario est pour moi : « prenons cette belle techno toute neuve et faisons de l’isofonctionnalité » : une application doit apporter quelque chose de nouveau.
D’un point de vue fonctionnel, la réponse peut venir d’une volonté stratégique ou d’une demande utilisateur. Il est préférable de mélanger les deux : si le patron veut une application pour créer un nouveau métier, il doit tâter le terrain avant investissement auprès des utilisateurs, et si c’est une demande utilisateur, elle doit être validée par un responsable qui comprend l’utilité de la fonctionnalité demandée.

La deuxième question coule de source : est-ce que mon besoin est suffisamment défini? Un nombre incalculable de prospects (ou clients), répondent à la question « que voulez vous? » par « je veux un CRM » ou « je veux un ERP » ou (mot à la mode) « je veux un algorithme » ou encore « je veux un ERP avec une IHM qui n’est pas une UAG » (le premier qui me donne la signification de tous les acronymes de cet article dans les commentaires gagne 15 minutes de consulting gratuit).
Ceci ne veut rien dire, je peux citer une douzaine de projets de CRM radicalement différents d’un point de vue philosophie de conception et qui sont tous des CRM. Il faut donc avoir une idée précise des fonctionnalités principales, et surtout préparer un discours et un cahier des charges (même peu détaillé) clair et compréhensible à transmettre en avant vente : qui utilise l’application, pourquoi, qu’est ce qui sera stocké, quelle sera la volumétrie de données approximativement. La précision diminue la perte de temps d’explication en avant-vente et vous permet d’être réactif voir proactif dans la suite du projet.

Après le pourquoi, le quoi, voici le quand : quand le projet doit il être fini? J’ajoute même une question subsidiaire : si cette date de finition n’est pas atteignable, quelle serait la date de prochaine finition?
La deadline contribue à la réussite du projet, même si elle est peu réaliste. Par contre il vaut mieux en déterminer au départ au moins deux, même si l’existence de la deuxième date est tenue secrète, cela permet d’une part d’être réceptif à une livraison par lot, d’autre part de pouvoir se retourner rapidement et efficacement en cas de problème en présentant un retro planning cohérent avec l’exploitation.

Parlons maintenant des questions pratiques lors de la conception, de la recette et de l’utilisation finale. La première question est : est-ce que mes équipes peuvent suivre un nouveau projet ? Nous évaluerons lors de la phase d’avant-vente les besoins en fonction de la solution abordée en ressources internes, mais aucun logiciel (même la suite office) ne s’installe dans un entreprise sans un travail de ses collaborateurs : réflexion, choix avant-vente, réunion de suivi des développements, recette, et utilisation attentive avec remontées de bug en production. Beaucoup de projet perdent un temps précieux car les collaborateurs même de bonne volonté n’arrivent tout simplement pas à trouver du temps. Cette question est à rapprocher du « quand », car évidemment la réponse dépend du plan de charge du service et donc de la période de l’année.

Autre question : est-ce qu’il n’existe pas des contraintes pratiques empêchant l’utilisation de l’application? Ces contraintes peuvent être très diverses : doublon avec une application déjà utilisée, données trop complexes ou trop contraignantes à saisir, utilisateur incapables techniquement d’utiliser l’application, trop de cas particuliers trop important pour justifier une utilisation d’une solution automatique, etc…
Une personne talentueuse  mais peu technique nous a demandé un outil de conception automatique d’interface graphique en JAVA. L’outil fonctionnait bien et était conforme à la demande, mais l’utilisateur a constaté qu’il n’avait tout simplement pas les compétences techniques et les automatismes intellectuels pour l’utiliser à bon escient.
Une autre société nous a demandé un outil pour que leur utilisateurs (des monteurs vidéos) saisissent toutes les informations matérielles d’une opération : outils utilisés, temps passés, usure des pièces, salles occupées. Au final les utilisateurs finaux n’ont jamais pu concilier l’urgence du terrain avec la saisie de ces informations.
Enfin une société nous a demandé de créer une application pour gérer la commande de vêtements. Le responsable avait monté un modèle de processus et de devis pour automatiser une grande partie du travail, mais le modèle s’est avéré ne correspondre qu’à une toute petite partie des commandes possibles, et l’application en est devenu inutilisable.
Ces trois projets ont un point commun : ils n’auraient jamais dû dépasser la phase de la réflexion.

Dernière question pratique souvent oubliée mais essentielle : dans le cas d’une refonte, que faire des données existantes? L’exploitation d’une application peuvent permettre d’enregistrer l’équivalent de millier d’heures de saisie, et s’il n’existe pas de processus automatique ou qu’aucune décision stratégique n’a été prise en en ce qui concerne la transition, au moment d’une refonte l’obstacle peut s’avérer infranchissable. Une non reprise des données est vraiment un classique du ratage d’application, il est donc nécessaire d’aborder ce sujet très sérieusement.
Un de nos clients nous a demandé une application de gestion de personnes et de groupes de travail, avec des options de recherche et de catégorisations très intelligentes. L’application a été conçue et réussie, mais le seul problème était que le client n’a jamais pu mettre dans une forme exploitable les dizaines de milliers de personnes et les centaines de groupes créé dans la dernière version de l’application.
Les solutions peuvent être complexes (remise en forme des données, saisie semi automatiques), optimistes (le prestataire saura bien se débrouiller) ou drastiques (table rase), mais il est nécessaire de retenir dès maintenant un point qui reviendra en phase de recette et d’exploitation : la ligne entre l’ancienne et la nouvelle application doit être ferme et marquée (suppression pure et simple de l’application précédente, date butoir, périmètres fonctionnels ou géographiques bien défini). Toute utilisation floue de deux applications en même temps résulte en erreurs, double saisie et données perdues.

Conclusion : rien ne sert de courir, le temps de la réflexion peut avoir lieu avant de décrocher le téléphone pour appeler son prestataire favori, et en plus permettra d’avoir d’ores et déjà la réponse à des questions que tout bon architecte métier vous posera.