L’optimisation écologique : c’est le moment !

Nous n’avons pas le choix, profitons-en!

L’écologie est nécessaire. La raréfaction des ressources fossiles, la nécessité de réduire le réchauffement climatique rendent indispensable d’intégrer la notion de développement durable et d’écologie dans nos stratégie tant personnelles que professionnelles, quelle que soit la taille de la structure. Et plus les décisions seront prises tard, plus les alternatives seront réduites et difficiles.

Par contre l’écologie est avant tout une opportunité. Souvent traduite ces dernières années en mesures coercitives, le but de cet article est de donner des pistes pour des mesures positives, créatrices de marge et d’améliorations sociales.

Pas de croissance verte du CA, mais une optimisation écologique de la marge avec un progrès tant économique que social

Parmi les tentatives de retirer le caractère répressif de l’écologie, l’une des plus citées est la notion de croissance verte. Cette notion implique de poursuivre une croissance économique dans nos modèles actuels tout en conservant les actifs de notre planète.

Or ce graphique (source, theshiftproject.org) illustre un concept assez intuitif : notre économie possède un lien direct entre croissance et consommation d’énergie.

graphique

Par conséquent et à moins d’une disruption technologique qui permettrait de dé-corréler activité humaine et consommation de ressources (i.e. l’utopie technologique de Star Trek), cette vision d’une croissance continue même verte paraît illusoire. Je range donc le dictionnaire Klingon et les costumes une pièce et je choisis l’hypothèse d’une future réinvention de l’économie qui intègre une forme de décroissance du PIB.

Voici donc l’optimisation écologique : utiliser les ressources fossiles aujourd’hui pour lancer des actions d’économie d’énergie et de ressources avec pour but d’augmenter le taux de marge plutôt que le CA, ce qui servira d’une part à financer les investissements et d’autre part se préparer à l’avenir.

L’objectif n’est pas uniquement économique, mais également social : améliorer la vie des salariés, en diminuant certains aspect kafkaïens de leur travail et en leur proposant de mener une action qui a du sens et participe à l’intérêt commun.

Du 0 papier…

La période de confinement que nous avons vécue a été un révélateur de la possibilité pour de nombreux employés de télétravailler et d’effectuer des tâches à distance. Même si le télétravail n’est pas la panacée car destructeur de lien social et parfois gourmand en énergie il faut continuer sur cette dynamique.

Le télétravail personnellement m’a fait passer définitivement au 0 papier :

  • les contrats sont électroniques et scannés, signés électroniquement avec des solutions comme Yousign ou avec mon certificat personnel.
  • les documents que je lis sont sur écran ou sur une liseuse
  • les factures sont expédiées par email, et si par courrier par un prestataire qui optimise les flux et consommations de papier (comme Esker)

Mon bureau s’est vidé, mes documents sont mieux classés et plus simples à trouver pour mes collaborateurs, et surtout j’ai considérablement diminué les déplacements inutiles et prenants. Gain écologique mais aussi gain de confort, de temps et de marge.

…au 0 déplacement, et au 0 perte d’information

La démocratisation de la visioconférence a également montré qu’il n’était pas nécessaire de déplacer 50 personnes pour effectuer une réunion :

  • trouver un horaire est plus simple si on ne déplace pas les gens
  • le format de web-conference et en particulier le format de la salle virtuelle plus rigide et formalisé qu’une salle réelle où tout le monde peut parler en même temps implique également des réunions plus structurées et qui vont droit au but.
  • l’enregistrement permet de gagner du temps et de transformer des réunions / webinars en supports de formation ou de communication commerciale.

L’impact global est considérable : le principal problème de la pollution en ville est le transport intra-urbain pour aller sur le lieu de travail : tout le monde ici contribue, en gagnant en qualité de vie.

Enfin l’automatisation des processus et des échanges en utilisant des interfaces web et/ou mobile pour les échanges internes (dans le respect des RGPD) permettent de diminuer les déplacements inutiles, les pertes de données, et permet également à terme de créer des bases de connaissances déjà classées et directement exploitables.

Pour cela des outils de réseaux sociaux internes comme mon partenaire Whaller sont à la fois des outils de productivité, de knowledge management et de lien social.

L’économie d’énergie dans les bureaux

Plusieurs études estiment entre 20 et 40% (comme l’étude Negawatt) l’économie d’électricité possible à activité égale dans le tertiaire. Notre expérience (relatée ici) montre que ces chiffres sont même plutôt pessimistes.

Il est vrai que l’électricité est rarement un poste de dépense important dans des bureaux, mais ce travail peut ici contribuer à obtenir un résultat spectaculaire : ramenée au pays, cette économie correspond annuellement à la consommation en électricité de Toulouse et Montpellier ou alors à la consommation d’essence nationale pour 15 jours.

De plus l’effort demandé n’est pas important, l’investissement est relativement faible et le résultat est positif non seulement pour la facture mais aussi pour le confort des équipes, qui constatent au quotidien les résultats des efforts de tous.

Dans notre cas nos économies d’énergies ont divisé par trois la facture et amélioré le confort de vie au bureau : les salariés ont un matériel et des conditions de travail plus adaptés à leur activité, la lumière est de meilleure qualité, la climatisation toute neuve ne fonctionne qu’en cas de canicule, car tout ce qui chauffait le bureau est éteint.

Une politique d’achat et de recyclage optimale

De nombreuses personnes utilisent maintenant avec plus ou moins de bonheur des applications et des outils pour donner du sens à leur achat. De nombreuses marques et producteurs de produits grand public proposent des produits ou des services avec une transparence sur les origines et les coûts en énergie, ainsi que des modes de recyclages des produits et emballages.

Il faut répéter et amplifier cette conduite dans nos entreprises :

  • privilégier pour les achats informatiques le reconditionné et les produits réparables (comme fairphone par exemple)
  • encourager les salariés à la sous-consommation non pas par des messages punitifs ou paternalistes, mais en formant et proposant des alternatives qui modifient peu le comportement, et améliorent le confort de vie.
  • se documenter sur le bilan carbone (de plus en plus simple à trouver) de produits et services pour intégrer ce bilan dans le choix, en le priorisant par rapport au prix.
  • préférer pour les transports urbains des moyens de transports verts, comme le vélo (électrique ou non). Mettez à disposition de vos employés des vélos électriques ou non pour le trajet domicile/travail ou pour les trajets pro. Le coût à l’achat est faible, le coût à la maintenance quasi-nul.
  • intégrer dans l’achat et le suivi matériels l’étude du cycle de vie et de recyclage. Utiliser le vrac, recycler tout ce qui peut l’être et privilégier l’achat de produit au maximum recyclables.

Nous achetons du reconditionné, intégrons l’écologie dans nos choix technologiques et tous les salariés qui le peuvent (80%) utilisent le vélo (deux fournis par l’entreprise, dont un utilisé quotidiennement). Tout ceci a été volontaire, accepté sans aucune difficulté ni inconfort, au contraire.

Enfin : communiquez !

Nous ne parlons pas ici que d’optimiser notre bilan, mais de mener une action dans l’intérêt de tous, donc il faut en parler !

En interne, menez cette action main dans la main avec les salariés, rendez les acteurs en utilisant des moyens de transport verts, montrez leur que cette action a du sens, va dans l’intérêt commun et est une initiative de l’entreprise pour changer les choses au-delà de l’activité purement économique. Il est primordial d’ajouter votre volonté et votre action dans la culture de l’entreprise, voire même intégrer dans les avantages factuels des fiches de postes un confort de travail accru et une action écologique qui donne du sens au travail des employés.

En externe, publiez votre bilan carbone, faites du prosélytisme, partagez comme nous vos actions positives, cela améliore l’image de l’entreprise et transmet le bon virus de la réflexion écologique.

Conclusion : soyez stratège, choisissez l’écologie maintenant.

En stratégie, une bonne méthode quand on a un sacrifice à faire ou une perte à assumer est de se donner les moyens de choisir le moment opportun pour l’effectuer, afin de transformer cette perte en avantage.

La fenêtre pour être proactif sur les actions que j’ai donné ici est de plus en plus réduite, foncez !

« C’est l’algorithme qui l’a dit » ou la déconnexion du logiciel et du métier

badcomputerday

Les premiers retours d’APB, logiciel gérant les souhaits des élèves pour leurs études après le Bac, ont été publiés récemment, avec leur lot de retours négatifs et d’incompréhensions de la part d’étudiants et de parents mécontents du résultat final. Pour expliciter ce phénomène les commentateurs utilisent la formule « c’est un algorithme qui décide », comme si le destin de nos enfants dépendait du bon vouloir de froids circuits imprimés. J’ai même entendu sur une radio une mère indignée menacer sur un ton mi-humoristique « si je trouve l’ordinateur qui a fait cela, que je lui explique ma façon de penser ».

Cette réaction est assez classique quand la décision est prise par un système informatique : celle-ci prend un aspect arbitraire et injuste, parfois plus que quand elle est prise par un être humain. Cette vision est paradoxale car dans la plupart des cas (écartons les algorithmes neuronaux, mon directeur technique en parlera) l’ordinateur applique de façon impartiale et linéaire les règles qui lui ont été indiquées par ses concepteurs. Donc si une question doit être remontée, ce n’est pas au produit mais aux concepteurs des règles fonctionnelles qui le composent. Or après une longue période d’utilisation le logiciel est personnifié par son utilisateur, et se sépare de ses concepteurs.

Revenons au métier, et en particulier à une phase importante de la vie d’un logiciel métier : le moment où la grande majorité (voire la totalité) des utilisateurs d’une application ne connait plus les règles qui expliquent la réaction d’un logiciel.

Il m’est arrivé plusieurs fois, dans le cadre de projets qui durent plusieurs années, d’avoir à expliquer à mon client, qui connait son métier, pourquoi le logiciel, qui applique son métier, prenait telle ou telle décision. Aussi surréaliste qu’elle puisse paraître cette inversion des rôles est finalement assez compréhensible. Je vais dans la suite de cet article l’expliquer, et donner des clés ergonomiques et organisationnelles pour l’éviter.

La perte de contrôle

Pour comprendre cette perte de contrôle, revenons au principe d’une application métier : l’un de ses objectifs est de faire gagner du temps à utilisateur en appliquant plus efficacement les règles de son métier qui sont suffisamment systématiques et simples pour d’une part être applicables sans erreur, et d’autre part que le fait que ce soit un être humain qui l’applique n’apporte aucune valeur ajoutée. Par exemple, dans une application de validation de dossier de normes, il n’y a aucun intérêt à demander à un utilisateur de vérifier dans un dossier la présence d’un document, un ordinateur le fera plus rapidement. De la même manière, historiquement la première application qui a provoqué l’engouement pour les ordinateurs personnels (même maintenant d’ailleurs) est le tableur : pourquoi faire les calculs compliqués et inintéressants si un ordinateur peut les exécuter instantanément pour nous?

Lorsqu’un utilisateur appuie sur un bouton de son application des milliers d’actions et de calculs peuvent se déclencher en quelques millisecondes pour afficher à l’écran un oui ou non. L’utilisateur n’a aucun intérêt à refaire le calcul lui même, le résultat est fiable, et on a gagné des heures et des heures. Mais la conséquence de cela est que l’utilisateur, même s’il est au fait de par sa connaissance du métier des règles qui sont en jeu, finit par perdre de vue la série d’opérations qui est effectuée, et l’action devient quasiment magique (le terme de « bouton magique » a souvent été évoquée par nos utilisateurs pour décrire un composant de leur application).

Les cas typiques où cette incompréhension est particulièrement forte sont les cas particuliers d’utilisation de l’application. En effet dans un cas non usuel, l’utilisateur attend une réponse de la part du logiciel conforme à sa vision des règles appliquées et non conforme aux règles telles qu’elles sont inscrites. Du coup la réponse du logiciel paraît peu cohérente voire complètement fausse.

Comment l’éviter

Commençons par le plus important : le mode d’emploi de l’interface utilisateur n’est pas la solution pour éviter ce type de problème. Si je reprends l’exemple d’APB, tous les utilisateurs qui ne comprennent pas la décision finale ont comme argument : « mais je l’ai bien rempli pourtant », et c’est vrai. Le problème ici ne réside pas dans une mauvaise utilisation du logiciel mais dans une mauvaise compréhension du résultat de la bonne utilisation.

Les pistes pour éviter ce type de problème sont les suivantes :
 – Entretenir la confiance dans le logiciel : la première solution pour éviter les incompréhensions est que l’utilisateur ait un a priori positif sur la qualité de la réponse du logiciel. C’est pour cette raison que les premiers mois d’utilisation d’une application métier sont décisifs : ils construisent sa réputation. Si celle ci est mauvaise, et même si au final le logiciel fonctionne, les retours négatifs vont se multiplier car les utilisateurs vont croire que le retour étrange est tout simplement un bug.
Expliciter les décisions : quand un logiciel propose une résultat qui nécessite plusieurs étapes de calcul, il n’est pas déraisonnable de les expliciter en quelques phrases. Dans 90% des cas, l’utilisateur ne va pas lire ce petit résumé, mais celui-ci sera primordial dans les 10% restants. Un bon exemple dans le grand public est l’application web de saisie de la feuille d’imposition, qui propose en quelques lignes une explication du montant de l’impôt sur le revenu final.
Rendre l’interface de saisie la plus proche possible du processus de décision de l’ordinateur : par exemple, si les conditions de décision dépendent de l’état du dossier dans un cycle, il est préférable que soit présents à l’écran l’état de l’objet, le cycle et la position de l’objet dans le cycle. Le but est de donner à l’utilisateur la possibilité d’apprécier la situation en un coup d’oeil et d’éviter les qui pro quo.
Décrire dans une documentation les workflow de façon synthétique, et valider que cette documentation est précisément ce qui est appliqué dans le logiciel, et surtout la mettre à jour au fur et à mesure. Il m’est arrivé plusieurs fois d’avoir des rapports d’erreur concernant des calculs, et l’utilisateur qui écrivait le rapport d’erreur utilisait comme référence un tableur excel qu’il avait fabriqué pour l’occasion, mais sans l’avoir maintenu : un beau dialogue de sourds !
Créer un forum utilisateur : l’avantage de cette solution est qu’elle présente des cas pratiques. Mais c’est une arme à double tranchant : il est impératif que le forum soit modéré et validé par quelqu’un qui maîtrise les processus décrits dans l’étape ci-dessus. Toute personne ayant consulté des forums sur internet sait que l’on peut trouver des mauvaises idées tout comme des bonnes.

La leçon à retenir de ce type de problème est que l’évolution d’une application pendant sa vie n’est pas uniquement interne : l’évolution de son environnement et de ses utilisateurs fait partie intégrante de son cycle de vie et doit être prise en compte dès le départ dans sa conception. Cette phase est souvent oubliée, et cet oubli se paye des mois voire des années après l’écriture de la première ligne de code. Encore une bonne raison de placer l’utilisateur au centre du système d’information!

Les méthodes agiles : agile oui mais surtout méthode!

cadavre

Le cadavre exquis, application dans l’Art de la méthode agile

Scrum, XP, DSDM, FDD… derrière ces acronymes se cache un concept de méthode de conception et de fabrication de produits informatique : la méthode agile. Le principe de base est simple : le produit informatique est immatériel, donc le coût de mise sur le marché (en production) d’une nouvelle version est négligeable par rapport à celui de n’importe quel autre secteur de l’industrie. Donc pourquoi ne pas proposer des mises en production en cours de réalisation, pour pouvoir affiner le produit directement au contact de l’utilisateur ?

En ce qui concerne la définition de la méthode, je vous propose de lire la fiche Wikipedia de description de la méthode agile, et en particulier les principes fondamentaux que je ne vais pas énoncer dans l’article. Je rappelle juste que le principe de la méthode agile est de créer le produit par itérations, chaque itération donnant lieu à une mise en production auprès des utilisateurs et à une mise à jour des spécifications de l’itération suivante, le tout suivi par des réunions et comités réguliers.

L’idée est extrêmement séduisante : l’utilisateur est alors mis au centre du processus de conception, et y participe activement pour un résultat qui ne peut que le satisfaire. Cela s’applique particulièrement au métier de la conception d’applications personnalisées, où le constat à éviter absolument lors de la mise en production de l’application est que l’orientation du produit ne soit pas en adéquation avec les besoins des utilisateurs. Vous pensez donc : « est-ce donc le design pattern idéal de Marc Lemaire et de Yoocan ? ».

Ma réponse est plus nuancée, et je vais la développer en évoquant en premier lieu le principe de la méthode, ses avantages et ses inconvénients, puis son implémentation (car non tout ne se passe pas comme dans le manuel!).

1) Avantages et inconvénients en théorie

Sur le principe inclure les utilisateurs en livrant de façon itérative est une bonne solution dans les cas suivants :

  • Le métier est particulièrement complexe et difficile à aborder : une démarche itérative évite les erreurs de conception dues à une mauvaise compréhension
  • Le volume d’utilisateurs est très faible : la coordination est très simple
  • L’ergonomie ou les fonctionnalités sont très innovantes : le retour des utilisateurs est essentiel sur un fonctionnement complètement nouveau
  • Le métier de l’utilisateur est innovant pour la même raison

D’un autre côté, également sur le principe il vaut mieux éviter ce type de méthode dans les cas suivants :

  • Le projet est une V1 avec un budget ou un temps limité : la méthode itérative demande du temps et en particulier du temps de réunion, donc c’est peu adapté pour un produit dont la phase de développement doit être la plus rapide possible.
  • Le projet est l’implémentation directe de la stratégie de l’entreprise : l’itération peut faire perdre de vue l’objectif principal du projet, et l’objectif d’évolution stratégique disparaît au fur et à mesure des itérations.
  • Il n’y a pas de rôles clairement définis chez le client (notamment pas de rôle de décision) : la démarche itérative demande la coordination des acteurs, chacun ayant un rôle bien précis. La non définition de ces rôles rend la communication et la prise de décision très complexe.
  • Un projet avec une part importante de recherche : la recherche et développement doit être confiée à la direction technique en premier lieu. La démarche de recherche est agile par définition, mais pas agile dans le sens des méthodes agiles.

2) Dans la pratique : les écueils à éviter

Dans la pratique, la réussite de l’application d’une démarche agile demande le bon suivi de chacun de ses règles.

Or l’application de cette méthode s’accompagne parfois de l’oubli conscient ou non de ces règles, et donne lieu aux comportements suivants

  • Itération sans livraison : il faut dans une démarche agile que l’application soit mise au contact des utilisateurs (règle 3). Ne pas passer par cette étape et itérer sans contact en vie réelle augmente considérablement le risque de hors-sujet, plus parfois que pour un cycle en V classique.
  • Itération sans rédaction de documentation ou validation technique (règles 9 et 11) : l’application évolue et donc son plan doit évoluer en restant lisible si on prend le projet de A à Z. Si vous créez un cagibi et ajoutez les pièces pour obtenir une maison au fur et à mesure, il paraît être du bon sens de maintenir un plan complet. Ce bon sens a tendance à être oublié au quotidien dans la conception d’un produit informatique.
  • Itération sans recette complète (règles 4, 7 et 12) : ces règles utilisent le terme d’applications fonctionnelles. Cela signifie que l’application doit être complètementfonctionnelle, et donc le métier et la technique doivent collaborer pour valider (même si l’évolution ne porte que sur une part du métier) un cahier de test reprenant les processus dans leur globalité.

Pour moi le problème de la non compréhension de l’intérêt de la méthode agile réside dans son nom. Le nom d’agile convient pour exprimer la qualité de cette méthode pour stimuler la créativité technique et fonctionnelle, et obtenir des produits innovants et proches du besoin final. Mais il y a une tendance à confondre agilité et manque de rigueur.

Durant ma carrière j’ai rencontré de nombreux chefs de projets ou dirigeants qui pensent qu’implémenter une méthode agile permet de ne suivre aucun plan de développement et de ne travailler qu’au fil de l’eau, sans cadre. Or au contraire l’application d’une méthode agile demande un surcroit de rigueur dans le suivi technique et fonctionnel, et ce afin d’éviter d’aboutir à une usine à gaz impossible à maintenir.

En conclusion, si vous voulez obtenir un beau cadavre exquis, il faut que tous les dessinateurs connaissent leur métier, leur rôle et leur style. Sinon vous obtiendrez un infâme gribouillis inexploitable.

Introduction à la sécurité pour le décideur : où sont les failles et suis-je concerné?

safety-sign-13

Imaginez une société qui possède certaines données critiques de ses clients, par exemple des milliers d’adresses postales. Un prestataire intervient dans les locaux de la société, passe les trois barrières de sécurité physique, obtient un badge, arrive dans une salle serveur techniquement bien maintenue et mise à jour avec un seul point d’accès réseau à l’extérieur. Là il assiste à une réunion, commence à travailler sur la structure de la base de données et repart après avoir montré une dernière fois patte blanche. Le lendemain il demande à la société un exemple de données pour pouvoir effectuer des tests. Et sans lui faire signer quoi que ce soit, un responsable lui tend un CD contenant la totalité des données, les fameuses données critiques comprises. Le site est-il physiquement et techniquement sécurisé? Oui. Les données sont-elles sécurisées? Beaucoup moins sûr.

A notre époque où le piratage est une à la fois pratique « sportive » et stratégique, où les pirates peuvent sortir des photos dénudées de stars et voler des secrets industriels et militaires, la sécurité est devenu un enjeu majeur et générateur d’articles anxiogènes dans le monde des applications informatiques.

En effet, en tant que particulier ou professionnel, vous ne serez jamais à l’abri d’une attaque ou d’un vol de données (tout comme vous ne serez jamais à l’abri d’une agression ou d’un cambriolage de vos bureaux) : aucune protection n’est sûre à 100%. Pire, quand une faille de sécurité est trouvée (comme la fameuse faille HeartBleed), il est parfois compliqué voire impossible de savoir si vous en avez été ou non victime, d’autant que les fabricants des solutions ne communiquent que lorsque la faille a été identifiée et bouchée.

Bien sûr, comme pour beaucoup de problématiques très techniques, il est compliqué pour le décideur profane, mais pourtant concerné, de discerner où résident les menaces. Le résultat est que quand au journal de 20 heures le présentateur annonce avec le visage fermé des catastrophes une nouvelle faille, il est incapable de déterminer s’il en est une potentielle victime. Cet article a pour but de l’aider à y voir plus clair.

Pour comprendre, reprenons un peu le trajet d’une donnée quand un utilisateur affiche un écran de votre application, dans le cas d’une application client serveur, comme par exemple un Extranet.

Etape 1 : le point de départ est l’ordinateur qui la contient, qui utilise un système d’exploitation pour stocker et récupérer les données. Ce système peut contenir des failles qui peuvent permettre à une personne mal intentionnée de prendre contrôle de l’ordinateur et éventuellement extraire ou manipuler la donnée. Ci-dessous les statistiques de fuite des différents systèmes d’exploitation. Ces chiffres sont à prendre toutefois avec des pincettes, car ce n’est pas parce qu’un système est moins attaqué qu’il est plus sûr, il peut être tout simplement moins attractif pour les pirates (source GFI, enquête par un organisme américain sur les failles de sécurités recensées sur l’année 2014).

vulne-2014-3

Etape 2 : la donnée est ensuite éventuellement répertoriée et exploitée par des logiciels (système de gestion de base de données par exemple), qui possèdent leurs propres failles potentielles, comme par exemple celle-ci sur Oracle.

Etape 3 : nous arrivons maintenant à votre application métier qui exploite les données, et qui peut posséder une faille dans son développement, avec les conséquences suivantes :
– celles permettant de prendre le contrôle du système d’exploitation et de retourner à l’étape 1.
– celles  permettant d’accéder à la base de données et de retourner à l’étape 2.
– enfin celles permettant d’accéder à des écrans sans le droit d’accès approprié.
J’ajoute ici que les informations sont également lues par l’utilisateur via un logiciel (souvent un navigateur Web), qui n’est pas exempt de faille comme le montre le tableau ci-dessous (même source).

vulne-2014-2

Etape 4 : la donnée est transportée dans un tuyau (la plupart du temps le réseau  internet) pour arriver sur le poste de l’utilisateur final, et ce tuyau peut être écouté par un tiers (cela peut même être un gouvernement cf. cet article de mon directeur technique). Si les données ne sont pas cryptées, il suffit de les écouter, sinon il est nécessaire de posséder ou de trouver la clé pour les lire.

Etape 5 : et enfin nous arrivons à la dernière faille, la moins documentée et prévue par les experts : l’utilisateur lui même. De très nombreuses failles de sécurité sont dues à un utilisateur qui fait preuve de libéralité, que ce soit involontairement (mot de passe trop simple, trop utilisé ou communiqué à un tiers, enregistrement de données sur un support non sécurisé, prêt de matériel, transmission de la données sans signature de contrat ou de dérogation, etc.), ou volontairement (vouloir partir avec les données de son entreprise pour les vendre ou les exploiter soi-même, vendetta, etc.).

Maintenant que j’ai brossé ce tableau succinct et en apparence catastrophiste, voici pour conclure cette introduction deux principes fondamentaux à suivre pour limiter les risques :

En premier principe, la sécurité est un effort à prendre en compte dans les choix techniques et pendant non seulement le développement et le déploiement d’une application, mais également pendant l’exploitation :
– mise à jour régulière par votre hébergeur des serveurs pour l’étape 1.
– mise à jour régulière par votre développeur des système de gestion de bases de données pour l’étape 2.
– audit régulier de la sécurité de l’application, avec tests d’intrusion et validation du code pour l’étape 3 (et si un framework ou une bibliothèque sont utilisés, mise à jour régulière de ceux-ci).
– utilisation et renouvellement d’un protocole https pour l’étape 4.
– formation régulière des utilisateurs finaux, surveillance de l’utilisation des données, suppression ou restriction des comptes utilisateurs le plus tôt possible pour l’étape 5.

Toutes ces précautions doivent prendre en compte le second principe : les mesures de sécurité doivent être à la hauteur de la confidentialité ou du caractère critique des données. Par exemple, sécuriser une base contenant l’adresse de 500 000 personnes demande un audit de sécurité plus conséquent et coûteux que la base de ce blog (malgré les trésors de connaissance qu’il contient).
Il faut ne pas toujours céder aux sirènes des sécuritaristes et à tout prix éviter que la barrière  ne coupe le chemin des utilisateurs honnêtes en même temps que celui des pirates. En effet trop de sécurité sans justification peut entraîner au mieux une perte de productivité et un agacement pour les utilisateurs, et au pire des failles encore plus grandes par réaction. Une connaissance m’a confié qu’après s’être vu refuser pendant 2 mois les clés des réserves de son propre rayon pour raisons de sécurité, il a obtenu par un ami le passe-partout du magasin pour ouvrir donc toutes les réserves. Une sécurité particulièrement mal dosée comme dans ce cas est très facilement transposable à l’informatique et peut être plus dangereuse que le pire des pirates.

Réussir un projet – Episode 2 : l’avant vente

SouffléConséquence d’une phase d’avant-vente trop rapide

Je vais être franc, je suis un peu gêné pour écrire cet épisode, car pour moi pour réussir une avant-vente la solution c’est choisir Yoocan. Cependant en tant que chef de projet et consultant j’ai suivi de nombreuses phases d’avant-vente, et j’ai l’intention ici d’énoncer les problématiques importantes ou les éléments que j’attends d’un client en prospection.

Cet article tient pour acquis le fait que vous avez lu et que vous avez suivi les conseils de mon épisode 1 et que donc votre besoin est bien défini et votre opinion affirmée.

La spécificité de la vente d’un logiciel informatique consiste en l’immatérialité du produit fini, ce que signifie que vous êtes dans un centre commercial face à des rayons pleins de produits invisibles, rendant très compliquée la tâche de choisir le bon parmi tous ceux qui existent. Quelques conseils pour décrypter les offres.

Je vais supposer également que vous êtes un fan de mon blog et que vous avez lu mon article sur le cloud, qui vous aidera à comprendre quoi choisir parmi les différents types d’accès à votre logiciel.

Donc vers quel type de solution se diriger : logiciel tout fait ou solution personnalisée? Il ne vous est pas du tout interdit de prospecter pour les deux, mais il serait intéressant que d’avoir dans votre for intérieur une opinion sur la question.
Cette question est équivalente à la suivante : est-ce que je veux le même logiciel que mon voisin ? La réponse peut être oui : vous voulez un système de partage de fichier avec versioning, un logiciel de compta, ou un CRM orienté annuaire client sans fonctionnalité spécifique à votre métier, faire développer cela de A à Z revient à peu près à réinventer la roue. Pour ma part j’ai parfois répondu à des appels d’offre en répondant « prenez tel ou tel logiciel, pas la peine de passer par nous pour faire ce que vous voulez ».
Par contre si vous voulez que votre valeur ajoutée spécifique soit concentrée dans votre application, attentions aux sirènes du « prenez un logiciel (à licence ou gratuit), nous le personnaliserons », car d’une part les personnalisations peuvent être très chères et d’autre part il vaut mieux parfois partir de rien plutôt que d’une base peu adaptée.

En dehors des fonctionnalités proposées, de la technologie utilisée, des raisons de politique interne ou de la faconde du commercial en face de vous, pour une application métier les notions suivantes sont très importantes à vérifier : bien sûr le prix, mais également le périmètre d’utilisation, et la pérennité, et le mode de réponse de vos candidats.

Que cache un prix? Le prix d’une application est principalement en quatre parties : le coût de licence, le coût de paramétrage / développement / formation, le coût d’hébergement, le coût du contrat de maintenance. Dans beaucoup de proposition ces coûts sont confondus : une licence annuelle d’utilisation d’un produit contient souvent la maintenance, le coût d’une application en SaaS sur le cloud confond l’hébergement et la maintenance. Dans tous ces coûts un seul n’est pas récurrent. Il peut être paradoxal de voir des sociétés gagner de l’argent sur la base de logiciels libres, mais ce qui est gratuit est uniquement la phase 1 du coût, et pas le reste. Je suggère soit de demander au commercial soit d’établir vous même un planning de facturation sur 3 ans. Faites attention également aux coûts de licence par utilisateur : très avantageux au début, ce type de facturation peut être incohérent avec une stratégie de croissance où l’augmentation du budget d’un département ne doit pas être linéaire.

Il ne faut pas également oublier dans le coût d’une application la possibilité d’en faire financer une partie. Le plus simple : la partie formation peut être intégrée à votre budget formation si la société est ou possède un organisme agréé. Un autre : le CIR (Crédit d’Impôt Recherche pour la recherche et développement) et surtout le CII (Crédit d’Impôt Innovation, pour la conception d’un prototype de produit innovant), permettent de faire financer en économie d’impôt le développement de votre solution.

Une autre information qu’il est essentiel d’évoquer lors d’une réunion commerciale est : quel est le périmètre d’utilisation de l’application, et quelles sont ses limites notamment en terme de charge ? J’ai construit plusieurs applications qui étaient destinées à 10-15 utilisateurs permanent, et qu’il a fallu reprendre quand ce chiffre est passé à plusieurs centaine d’utilisateurs. Le client s’est attendu au surcoût car je l’avais prévenu au départ. Il est donc essentiel pour vous de savoir dans quelle mesure le logiciel peut être utilisé : combien d’utilisateur en même temps, combien d’utilisateurs au total, volume de données maximum, les heures d’exploitation (si par exemple des mises à jour doivent être effectuées à heures régulières).

Pour terminer une application métier est une application que vous allez utiliser au quotidien avec à mon opinion une durée minimum d’exploitation de 3 ans. Il est donc nécessaire pour vous client de suivre comment l’application peut évoluer.
Concernant un logiciel, il est nécessaire de vérifier la santé de l’éditeur, la durée d’exploitation du logiciel et s’il existe un autre intégrateur (un de mes anciens clients a du recréer toute une solution en 3 mois car le seul intégrateur restant du logiciel est parti devenir professeur de plongée en Thaïlande).
Concernant une application personnalisée, la santé de l’entreprise doit également être surveillée, la technologie connue d’au moins un autre intégrateur (et attention à la notion de framework, j’écrirai un article sur le sujet dans les prochains jours), et la proposition commerciale doit contenir une partie de documentation technique pour permettre une reprise par une autre équipe, et surtout une description fonctionnelle et technique basique du mode de fonctionnement de la solution proposée : dans le cadre d’une application personnalisée, il vous faut vérifier que votre futur prestataire a bien compris votre besoin.

En conclusion, quelle que soit l’option prise, une application métier est une solution qui définira votre façon de travailler pendant quelques années, donc le choix du prestataire doit être fondé non seulement sur la qualité technique et fonctionnelle, mais également sur la capacité de votre prestataire à vous accompagner dans la durée.

 

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.

Mais au fait, pourquoi donner une tablette avec des applications à mes salariés?

tablette-tactile-enfant1
Entrepreneur de demain saisissant son rapport quotidien

Le titre de cet article peut vous donner l’impression que cette semaine je vais enfoncer des portes ouvertes, mais il s’avère que ces portes ne sont pas réellement ouvertes, ni même si évidentes à trouver. En effet ma position est qu’une tablette est un outil essentiel pour une grande majorité de salariés, y compris les non itinérants, a condition de l’utiliser à bon escient.

Dans cet article je vais me consacrer à ma spécialité, le B2B, un petit passage sur votre Store favori vaut mieux qu’un long article concernant le B2C. Le but est de présenter les avantages et inconvénients du support mobile, d’une part pour encourager des entrepreneurs à utiliser le mobile, et d’autre part pour décourager des entrepreneurs technoïdes à utiliser une tablette à tout prix.

Au lancement des applications mobiles B2B, les premiers bénéficiaires furent les coursiers (ce fut d’ailleurs mon premier projet d’application à composante mobile, sous windows mobile à l’époque), puis le marché s’est lentement ouvert à d’autres professions. Néanmoins pour les autres entreprises non visionnaires, une application mobile métier était un nice to have, et non un must have. Le must have l’emporte depuis à peu près un an, mais peut-être comme pour beaucoup de modes de manière un peu trop systèmatique.

Voici donc un petit rappel de ce qu’une tablette ou un smartphone avec application apporte (ou pas).

Les plus

Parlons d’abord du cas simple : les itinérants (VRP, techniciens, coursiers). Ici la tablette ou le smartphone connecté est une passerelle, un lien permanent d’une part entre le siège et l’itinérant, mais également entre l’itinérant et le client, voire entre l’itinérant et un tiers.

Exemple : avec une application de qualité, un technicien peut en trois clics récupérer son prochain rendez vous, commander une pièce au fournisseur par texto avant d’aller la chercher, et prévenir le client par texto et/ou email qu’il a dix minutes de retard. D’une part la qualité du service est excellente pour le client (un retard prévenu est la plupart du temps accepté, et par mécanisme d’engagement un client prévenu d’un retard va attendre plus longtemps avant de renoncer), d’autre part la rentabilité du technicien est optimisée au maximum, dans l’intérêt de tous.

Deuxième avantage : tout le monde a une tablette. Le prix bas des supports et le fait que les fonctionnalités proposées dans la plupart des tablettes, même bas de gamme, sont largement suffisantes pour une utilisation quotidienne à domicile vont aboutir à ce que la tablette bannisse l’ordinateur même portable dans les foyers, et à terme monsieur Toulemonde aura au minimum une tablette Wifi chez lui. Ceci signifie que l’application tablette (pour peu qu’elle soit multi-support comme les applications Yoocan Move) est une application idéale pour des dialogues avec tiers comme des concessionnaires, des indépendants, des clients ou des entrepreneurs, même pour une utilisation non itinérante.

Dans ces cas là, comme la volonté stratégique de l’entreprise ne peut pas se transmettre aussi facilement que pour une application interne, la nécessité de « vendre » l’application est encore plus forte (nous verrons cela dans un autre article sur la conduite du changement). Or un bon moyen de conduire cet acteur externe à utiliser vos outils est de les lui rendre disponibles le plus simplement possible, par exemple sur sa tablette. Les applications ici sont très nombreuses : simulateur pour concession automobile, loueur, application pour cours à domicile ou professions libérales, etc…

Dernier avantage : l’ergonomie. La légèreté du support, son interface au doigt, sa connectivité et son côté ludique rendent les applications tablette les applications idéales pour saisir des données structurées, quelles qu’elles soient.

Que ce soit sur un chantier (le fondateur de FinalCAD, entreprise française à succès, ne dira pas le contraire), dans un entrepôt, dans une salle de réunion ou dans un bureau, pourquoi fournir un ordinateur de bureau ou un portable lourd et cher à un collaborateur qui doit accomplir uniquement des actions simples d’un point de vue informatique (mail, internet, bureautique simple) ou des actions complexes mais structurées (rapports d’expertise normalisés, commandes…) alors qu’une tablette moins chère peut être transportée aisément partout, sans fatigue, et que l’interface au doigt est plus simple et plus ludique que l’interface à la souris? Enfin la tablette est le support idéal pour les personnes qui, sans être itinérantes, passent beaucoup de temps debout : animateurs(trices) de salon ou de conférences, vendeurs(ses), etc…

Les moins

Les applications tablettes ne sont tout de même pas la panacée et voici ce qu’elles ne font pas :

Premièrement une tablette est un outil très peu adapté à la saisie de données non structurées. Malgré l’utilisation de claviers, j’ai pu constater autour de moi que mêmes les plus technophiles de mes collègues et amis n’utilisent que très peu les tablettes pour saisir un texte de plus de deux lignes. Moi même pour écrire cet article je délaisse mon I… (pas de marque) chéri pour mon ordinateur.  Par conséquent, les utilisateurs (y compris itinérants!) qui passent beaucoup de temps à écrire des textes même relativement longs dans leur métier doivent plutôt utiliser un ordinateur ou un hybride PC/tablette tactile (pour allier le meilleur, mais pas le moins cher, des deux mondes).

Deuxièmement : une tablette ne doit pas être un outil de stockage de données et doit rester un outil transitoire, sans se substituer à une application avec serveur central. Au vue de l’évolution technique des environnement tablettes et même si leurs performances s’approchent des PC de bureau, les applications doivent être conçues pour recevoir des informations ciblées  et les données doivent être renvoyées régulièrement au siège social. Ce qui est peu important dans une utilisation privée s’avère crucial dans une utilisation en entreprise.

Enfin : une application tablette ne doit pas être aussi riche en contenu et fonctionnalités qu’une application client/serveur d’entreprise. Une application sur support tablette doit être extrêmement simple avec un accès direct aux fonctionnalités centrales et un nombre d’écrans faible, afin de profiter au maximum des qualités du support. Le principe est simple : un objectif, une appli.

En conclusion, la tablette est l’outil professionnel de demain en plus de l’outil personnel d’aujourd’hui. Une entreprise qui réalise maintenant une transition vers l’utilisation de ces supports verra immédiatement des résultats tangibles et durables, si les applications sont utilisées en exploitant au mieux le modèle tablette.

Fausse bonne idée : commençons vite fait, on verra plus tard…

 numerobis1Souvent, avec des partenaires ou des anciens ou futurs clients, la réunion se déroulait de la façon suivante : ils nous expliquaient leur idée géniale, je répondais « elle est géniale cette idée, mais il faut faire attention à la mise en place technique », la personne rétorquait « boah on verra, pour le moment on fait rapidement avec un développeur pas cher que j’ai trouvé ». La conséquence est quasiment à tous les coups la suivante : le détenteur de l’idée revient en catastrophe quelques temps plus tard, en nous demandant de le sauver ou de finir le projet : un site de vente qui a des soucis de performance le jour des soldes, une application métier jamais finie, un site de contenu ne tenant pas la charge un jour de buzz, etc…

Avant de continuer cet article un petit disclaimer : ceci n’est pas le manifeste du technicien que je suis toujours pour affirmer la supériorité de la technique sur le marketing ou la vente  : mon but est de d’appuyer sur le fait qu’une erreur fondamentale de nombreuses start’up ou les pure player informatique en particulier en France est de négliger (volontairement ou non) la qualité technique du produit.

Quand on construit une maison, on ne choisit pas un constructeur au pif et le moins cher possible, mais plutôt à un architecte pour faire des plans. C’est une question de bon sens : il faut que la maison suive des normes et le projet s’avérera très compliqué par la suite si par exemple les évacuations d’eau sont négligées, si les fondations sont mal fichues, ou si personne ne pense au jour où il faudra construire une dépendance de plus… De même certaines parties de la maison sont réalisées par des maçons, plombiers ou ouvriers d’élites, qui sont en général payés plus chers. Il y a un consensus sur le côté nocif du « vite fait mal fait pas cher ».

Pour un site web ou une application métier, le raisonnement est le même : pour construire une solution pérenne, il est beaucoup plus incertain de demander à un développeur au pif plutôt qu’à demander à un architecte informatique au moins au démarrage du projet. De même certaines parties doivent être développées par un technicien d’élite, qui peut coûter plus cher.

Meetic, Vente privée, facebook, google, Amazon : des grandes success story du web ont toutes un point commun : ce sont certes des belles idées très bien vendues mais elles ont avant tout une base technique solide menée par un équipe avec un directeur technique capable de réfléchir en amont aux problèmes futurs, et des développeurs capable de réaliser du code de très haute qualité.

Évoquons ici les problèmes qui peuvent survenir dans le cas d’un développement d’un produit vite fait.

Première crise possible : le projet ne se termine pas. J’écrirai un autre article sur les causes de non finition d’un projet, mais dans le cadre d’un projet fondateur d’un nouvel acteur du web, l’une des causes les plus fréquentes est que le développeur n’arrive pas à créer une solution stable, ou que le projet s’arrête en cours de développement.

Deuxième crise possible : l’instabilité de la solution empêche sa croissance. D’une part notre expérience nous montre qu’un taux d’indisponibilité de 2% d’un site web peut résulter en une perte de fréquentation de l’ordre de 10%. D’autre part lors du lancement d’un site, la nouveauté ainsi qu’une éventuelle opération marketing amène rapidement des internautes dès la mise en production, et une mauvaise réputation peut être construite en peu de temps si le site est inutilisable. Ce type de handicap est par la suite très compliqué à rattraper.

Troisième crise possible : problème de montée en charge quand la croissance arrive. La grande réussite de plusieurs grands acteurs du Web a été d’inclure dans le plan technique la croissance de la solution. Les problèmes de charge peuvent résulter soit en un site beaucoup plus lent, soit en un blocage définitif lors de la plus grosse période d’affluence. Un site mal codé dès le départ sera très compliqué à réparer le jour où le trafic du site est multiplié par 100 ou 200 d’un coup. Cela arrive même aux plus grand, comme Facebook qui a dû reprendre son site pour en changer les choix techniques de design.

En conclusion, quand un patron a une bonne idée, négliger le développement et ne pas donner le travail à un directeur technique et à des développeurs d’élite (profils difficiles à trouver) est une erreur, qui risque d’aboutir à l’échec du projet ou à des passages très douloureux en cours d’exploitation. L’argument de l’économie d’argent est illusoire, mieux vaut resserrer au départ les fonctionnalités pour se laisser la marge et le temps de créer un outil parfaitement conçu au départ.

Le mode déconnecté : tout est disponible, mais ne pas oublier la synchro!

Une des premières demandes de nos clients avec une équipe commerciale est d’avoir facilement et rapidement toutes les pièces nécessaires à leur travail : une société de GPS nous demande d’avoir à disposition toutes les vidéos et les documents de démonstration, un vendeur de matériel industriel nous demande les spécifications techniques détaillés, un vendeur d’alimentation vétérinaire nous demande d’avoir toutes les statistiques de vente.

Au final tous ces clients souhaitent avoir à disposition en permanence pour 100 à 300 Mo de données! Dans ce cas un système de synchronisation régulière est obligatoire.

Le principal avantage d’une application 100% déconnecté est l’accessibilité immédiate à un grand volume d’informations. Quand on voit que n’importe quelle tablette d’entrée de gamme possède plusieurs Go de stockage, il est simple d’imaginer l’intérêt pour un VRP d’avoir sur sa tablette en accès immédiat un maximum de données.

De plus, si on a du mal à avoir de la 4G partout, il est assez simple de trouver dans un rayon d’1km une connexion Wifi. Le fait de devoir attendre d’avoir une connexion stable pour une synchronisation complète est donc de moins en moins un problème.

Pour moi une application en mode déconnecté est la solution essentielle pour des commerciaux ou des techniciens qui ont la complète maîtrise de leur plan de tournée sur 12 ou 24h (et qui donc effectuent une à deux synchro par jour maximum), ou les personnes qui ont besoin de faire des démonstrations sur des supports de grande taille qui changent peu (conférenciers, événementiel, statistiques mensuelles ou hebdomadaire sur un volume de données important, documentation et catalogue client).

Avec YOOCAN Move la complexité technique de ce type d’application est modeste et revient surtout à limiter au maximum la durée de la synchronisation et/ou prédigérer au maximum les données.

Cette méthode n’est pas exempte de défaut. Le premier inconvénient est bien sûr le délai d’obtention des informations, mais les problématiques qui sont souvent oubliées dans ce type d’application sont :

  • La sécurité : si les informations sont stockées sur la tablette, elles le restent si la tablette est volée ou pire si l’utilisateur décide de partir avec pour l’exploiter en concurrence avec son ancien patron. Il convient donc de sécuriser les données au maximum, soit par des mots de passe, un cryptage de la base de données (des solutions existent), ou même par l’obligation pour utiliser l’application d’une connexion régulière au siège.
  • L’obligation de synchroniser régulièrement : il est nécessaire pour les utilisateurs de renvoyer régulièrement leurs données afin de limiter le risque de perte et de décalage entre l’itinérant et le siège. Cela nécessite un réflexe de la part des utilisateurs (qui n’est pas évident), et une formation.

Conclusion : le déconnecté est relativement peu complexe à mettre en place (pour Yoocan Move), et permet un accès immédiat à un volume de données important. Par contre il est nécessaire de bien calibrer le volume de données pour des raisons de temps de synchronisation et surtout de sécurité, et le maniement de ce type d’application est plus délicat qu’une application connectée ou semi déconnectée.