Télévision à la demande et banques en ligne : deux exemples d’amélioration de l’expérience utilisateur.

La transformation numérique des entreprises a souvent pour effet induit des améliorations de l’expérience utilisateur.

L’utilisateur de l’ outil numérique, qu’il soit collaborateur d’une entreprise ou d’une institution, ou bien encore aussi citoyen et consommateur, mérite bien des égards. Aussi, le secteur du logiciel et de l’informatique s’investit afin qu’au-delà des fonctionnalités qui sont proposées à l’utilisateur, une expérience plus simple, plus fluide, plus agréable, voire ludique lui soit offerte.

Développons cela avec l’exemple de la télévision à la demande.

Pour commencer, quelques chiffres (source médiamétrie): en 2021, le CSP+ regarde en moyenne la télévision 2h56 chaque jour; chaque jour, en 2022, plusieurs millions de Français sont devant leur « petit écran ».

« Petit écran » est devenu « grand », et , avec la transformation numérique des diffuseurs et des téléviseurs, les utilisateurs -téléspectateurs- bénéficient d’une expérience plus confortable et plus maitrisée.

Le téléviseur est numérique: doté d’un OS (android ou autre), il est sous le contrôle, plus que jamais, de l’utilisateur. L’utilisateur ne choisit plus non seulement le programme, mais aussi la temporalité de celui- ci grâce à ce qui est courant de dénommer désormais « la télévision à la demande« .

Notez-bien que le terme utilisateur désigne dans le jargon de l’informaticien ce que d’autres appellent usager, client, téléspectateur, citoyen, habitant etc.

La « télévision à la demande » constitue donc, à mon sens, une avancée majeure -via la transformation numérique- vers la liberté individuelle. 24 h sur 24, 7 jours sur sept, l’utilisateur est désormais libre de sélectionner son programme télévisuel. Il peut maintenant de plus interrompre, reprendre, revisionner, enregistrer, bénéficier d’une description écrite de son programme avant de décider d’y investir son temps. Grâce au choix des applications gratuites sur son téléviseur android connecté, qu’il télécharge via l’internet, il peut à tout moment s’informer, se divertir, travailler, se former, se cultiver dans tous les domaines : documentaires et reportages, cinéma, séries et fictions, information et société, histoire, voyages et découvertes, Sciences, culture et pop pour n’en citer que quelques uns …

Bon nombre d’intellectuels s’expriment -depuis son invention- sur le caractère potentiellement aliénant de la télévision sur le téléspectateur, avec son cortège de publicités, de simplifications, d’outrances, d’addictions perpétrées. Il n’en demeure pas moins vrai que les chiffres parlent d’eux-mêmes: sociologiquement, la télévision occupe toujours une place importante dans nos vies, en 2022.

Mais la donne a changé: le téléspectateur peut reprendre le contrôle, dans son intérêt, avec la télévision à la demande.

°°°

Un autre changement majeur s’opère de nos jours dans le domaine de la Banque. Naguère, l’agence bancaire était un endroit géographiquement localisé, ultra-sécurisé, incontournable, aux horaires intangibles, au personnel plus ou moins disponible et compétent, plus ou moins transparent. En bref, la gestion de nos avoirs dépendaient fortement de l’agence bancaire et de son cortège de contraintes. Quant au pouvoir du banquier sur son client, il était important aussi pour de mauvaises raisons: lenteurs induites, autorité, manque de souplesse.

La transformation numérique des entreprises est en marche ; nous pouvons de nos jours, via l’internet sécurisé, être plus autonome et plus libre, dans nos relations avec la Banque. Consulter ses comptes, encaisser de l’argent, effectuer des virements, procéder à des arbitrages, épargner, accéder à la documentation, emprunter, choisir d’avoir plusieurs banques, est rendu possible depuis chez soi ou depuis tout lieu donnant un accès à internet, en quelques clics et écrits numériques bien pensés.

Allons plus loin et plus vite dans la réflexion et projetons-nous dans l’avenir: l’émergence des cryptomonnaies induit l’atténuation potentielle du rôle de ce tiers de confiance qu’est la Banque. Certains pensent que les technologies informatiques dont la blockchain permettront à l’avenir d’envisager à large échelle tout commerce licite sans que la Banque ne soit nécessaire…

Publicité

« Spaghettiware»: de l’art difficile de l’intégration des composants du système d’information.

Un système d’information d’entreprise est, dans la plupart des cas, composé de modules remplissant chacun une ou plusieurs fonctionnalités bien précises. Citons les fréquents modules suivants :

• La gestion de la relation client (CRM), dénommée à tort car il s’agit de gérer les prospects (qui ne sont pas encore clients par définition) et les opportunités associées
• La gestion commerciale permettant l’établissement automatisé de devis et la transformation en commande
• La gestion des catalogues de produits et services
• Le système de facturation (parfois directement associé à la gestion commerciale)
• La comptabilité
• Le système d’information des achats et du procurement
• Les systèmes d’information des ressources humaines (gestion du temps, registre du personnel, gestion prévisionnelle de l’emploi et des compétences, gestion des recrutements, paie, etc.)
• Le système de gestion des stocks
• Les annuaires (personnel interne)
• Le site institutionnel de l’entreprise
• Les systèmes de reporting et décisionnels agrégeant les données
• Les sites de e-commerce accessibles aux clients
• etc.

On le voit donc, au travers de cette première liste, un SI d’entreprise composé de nombreux éléments comporte naturellement une complexité d’autant plus exacerbée que chacun de ces éléments va interagir avec les autres.

Chaque composant peut être une partie d’un progiciel, un développement spécifique, mais à coup sûr ou disons dans 90% des cas, aucun SI n’est composé d’une solution unique couvrant tous les besoins fonctionnels.

D’où la nécessité d’interfaces, c’est à dire d’éléments autorisant la communication entre ces différents modules.
Prenons un module A et un module B, composants d’un SI, on peut avoir une interface « monodirectionnelle » A vers B (A envoie des infos à B), « bidirectionnelle » (A envoie des infos à B et réciproquement B envoie des infos à A). Voilà pour le sens des flux, par ailleurs il faudra considérer la dimension temporelle de ces flux :A envoie-t-il à B des données de façon périodique (par exemple une fois par jour, la nuit entre 3 et 4 h du matin, A envoie l’ensemble de ses données mises à jour depuis la veille à B), ou bien encore A et B échangent-ils de façon synchrone : dès qu’une information de A est ajoutée ou mise à jour, B en est immédiatement notifié et l’information lui est envoyée ? Ce caractère synchrone se mesure-t-il selon une latence exprimable en minutes, secondes, milli voire microsecondes ?
On voit donc plusieurs critères apparaître dans la définition d’un flux inter-applicatif :

• la (les) direction(s) des flux
• la temporalité de ceux-ci (périodicité/synchronicité)
• la nature des données transitant entre les 2 applications
• les évènements déclencheurs de transit d’information entre les applications (par exemple lors d’un ajout, une mise à jour ou une suppression d’une information dans A, B en est informé et l’information lui étant envoyé).

On comprend dès lors aisément toute la complexité de l’intégration d’un SI comportant, par exemple, une dizaine de modules. Si chaque module communique avec tous les autres, selon un flux unique, ce ne sont pas moins de 9+8+7+…+2+1= 45 interfaces qui sont potentiellement à mettre en œuvre !
Prenons un exemple concret aisément compréhensible. Imaginons un SI composé de 3 modules : un CRM (pour les commerciaux), une gestion commerciale permettant de faire des devis détaillés (avec catalogue de produits et services intégré) et un système de facturation. Voici un flux simple : le commercial identifie un prospect et une opportunité, il les saisit dans le CRM. Son prospect souhaitant recevoir un devis, une première interface permet au système de gestion commerciale de recevoir les informations relatives au prospect, sans que l’on ait à les ressaisir. Puis le devis est réalisé, et s’il est accepté, transmis par une seconde interface au système de facturation. On voit dans cette chaine simple deux interfaces : CRM vers gestion commerciale et gestion commerciale vers la facturation. Il est clair que le premier intérêt de la mise en place de telles interfaces réside dans le fait qu’il évite la saisie multiple d’information, ainsi ici, le nom du prospect saisi en amont dans le CRM, n’aura plus à être écrit de nouveau jusqu’à l’émission de la facture.

Se pose la question de la « vélocité » de ces interfaces. Peut-on accepter un délai d’une journée voire d’une heure entre la création d’un prospect dans le CRM et sa prise en compte dans le système de gestion commerciale ? Quel(s) est(sont) par ailleurs  le(s) événement(s) déclencheur(s) de la transmission d’information ?

L’effet « spaghettiware »

On le conçoit aisément, l’intégration inter-applicative d’un SI constitue une des activités essentielles et réellement difficile de l’architecture informatique d’entreprise. Quand on a vu que pour 10 modules différents, il existe potentiellement 45 interfaces, on comprend mieux l’utilisation fréquente par les informaticiens du fameux mot « spaghettiware » : tel un plat de spaghettis, l’information circulerait au sein du SI au travers d’innombrables tuyaux enchevêtrés. Ce serait d’autant plus vrai que les SI ont une histoire et que, au gré de leurs évolutions, de nouveaux modules se sont greffés, avec leur lot de nouvelles interfaces …

Comment donc concevoir un SI simple, lisible, pleinement opérationnel, et évolutif ? Cela passe par une réflexion sur plusieurs axes:

1/ la définition claire des « datamaster », c’est à dire les systèmes qui sont référentiels pour chaque type de données

2/ les interfaces ne devraient servir qu’à transporter que les informations strictement nécessaires

3/ une analyse détaillée des flux, tant d’un point de vue du contenu transporté que des contraintes de temps de transport

4/ une harmonisation des technologies de circulation des informations (fichiers plats, API, middleware …)

5/ un effort proportionné dans le développement de l’interface en fonction des enjeux sur les données transportées selon plusieurs critères dont : le volume de données, et les délais acceptables pour les transporter.

Jean-Michel Lucas

©2018-2024

Développement spécifique versus progiciel, ou comment réinventer la roue …

  Désireuse de s’équiper d’une solution informatique dotée d’un certain nombre de fonctions, une entreprise émet une expression de besoins, le plus souvent un « cahier des charges ».

Une question fondamentale -à mon sens- doit apparaître très vite : un progiciel, c’est à dire un produit de « série » proposant une gamme de fonctionnalités pourra-t-il répondre à ce cahier des charges, ou bien alors faut-il envisager un développement spécifique, c’est à dire un produit « sur mesure », totalement spécifié par le cahier des charges ?

Cette réflexion est réellement fondamentale pour l’entreprise à de nombreux égards, notamment :

A. Le coût total de la solution

B. La maintenabilité et l’évolutivité de la solution

C. L’adéquation fonctionnelle attendue

---

A. Le coût total de la solution

J’ai pour habitude d’utiliser une métaphore automobile pour comparer le coût potentiel d’une solution spécifique versus l’acquisition d’un progiciel.

En investissant pour un développement spécifique, le client demande un « prototype », une solution unique, qu’aucun autre client n’utilisera. En choisissant un progiciel, c’est comme si celui-ci choisissait un véhicule de « série », fabriqué en grande quantité, en usine.

On comprend mieux alors, au travers de cette analogie industrielle, la différence potentiellement drastique de coût entre les deux solutions.

Le raisonnement est simple. Imaginons la solution 1., spécifique, dont le développement coûterait 1 Million d’€. Cette solution sera vendue une fois et une seule au coût de 1,3 Million d’€ par exemple. 

Imaginons désormais la solution 2., progiciel dont le développement coûterait 2 Millions d’€. Si la solution est vendue 50 fois, il suffit de la vendre 2 x 2 M€ / 50 soit 80 000 € pour générer au total un revenu double du coût de production !

1,3 M€ dans le 1er cas …

80 k€ dans le second cas …

De quoi réellement s’interroger quant à la bonne alternative ! 

---

B. La maintenabilité et l’évolutivité de la solution

Une entreprise s’équipant d’une solution logicielle un tant soit peu élaborée le fait pour plusieurs années. Se pose donc la question du caractère maintenable et évolutif de la solution choisie. Quels sont les risques en fonction du scénario choisi ?

• progicieldépendance vis à vis de l’éditeur (« souveraineté numérique »)limitations quant à la « customisation » possible du progiciella « mitigation » de ces risques consiste à s’assurer de la qualité économique et technique proposée par le fournisseur (l’éditeur)s’organiser pour optimiser l’autonomie (configurabilité, connaissance intime du produit, transfert de compétences de l’éditeur au client)veiller au nombre de versions livrées par an, au nombre de clients de l’éditeur etc.
• choix d’une solution spécifique
  En 1997, je suis personnellement intervenu au sein d’une PME (électronique) qui avait fait réaliser une partie de son informatique de gestion (prise de commandes et facturation) par un indépendant qui lui avait « codé » une application spécifique. Résultat: trois ans plus tard, l’indépendant était occupé à tout autre chose, et le système se met à « bugger ». L’entreprise, qui avait tout de même pris soin de devenir propriétaire du code, se retrouve totalement bloquée, sans possibilité de générer la moindre commande ni la moindre facture. Je me souviens de plusieurs journées passées à trouver les fameux « bugs », en entrant dans le code qui avait été réalisé (non documenté bien sûr et absolument pas du tout maitrisé par l’entreprise). Indéniablement, choisir une solution spécifique et la faire développer, c’est prendre un risque important quant à la capacité d’assumer la maintenance corrective et évolutive de la solution.

La vocation même de l’éditeur est effectivement de proposer des produits qu’il fera évoluer, débuggera, et qui sont utilisés par plusieurs clients.

---

C. L’adéquation fonctionnelle attendue.

On marche souvent sur la tête dans ce domaine si l’on n’a pas bien compris l’importance de la dualité progiciel / développement spécifique.

On lit même bien souvent dans des cahiers des charges : « un développement spécifique ou une solution à base de progiciel pourront être proposés ».

De fait, le processus d’expression des besoins est – me semble-t-il – à reconsidérer:

Processus classique

1. Quel sont les besoins fonctionnels ?
2. Quelle ergonomie est souhaitée ?
3. Rédaction et émission d’un cahier des charges
4. Réception des réponses
5. Décision 
6. Lancement du projet

Le processus qui me semble participer d’une démarche optimisée: 

1. Quelles sont les fonctions offertes par les différentes solutions du marché ?
2. Quels sont mes besoins essentiels parmi ces fonctions ?
3. Rédaction et émission d’un cahier des charges orienté éditeurs
4. Choix de l’éditeur
5. Lancement du projet

Ceci me parait d’autant plus pertinent que 80% des besoins ne sont pas spécifiques à la société (ou organisation) cliente, mais communes à toutes les entreprises (ou organisations) du même secteur. Par ailleurs, il est bon de rappeler la fameuse règle des 80/20 : 20% des efforts risquent de représenter 80% du prix.

A quoi bon se restreindre à une description très spécifique et unique du besoin ? A quoi faire (il en existe encore) des maquettes d’écran ? A quoi bon croire que c’est le client qui reste décideur quant à l’ergonomie du logiciel ?

En conclusion : 

• soit le besoin est couvert à plus de 50% par un produit du marché, et il me semble alors totalement inefficace d’envisager une solution en « développement spécifique ».
• soit le besoin est tellement spécifique qu’aucun progiciel du marché ne le couvre. J’attends des exemples de ce cas là …  Je ne parle bien sûr ici pas du jargon, des sigles, des acronymes utilisés par le client mais réellement des fonctionnalités attendues.

Jean-Michel Lucas

©2018-2024

Pourquoi numériser ?

  Il est bon de retourner aux fondamentaux et de simplement tenter d’identifier les avantages de la numérisation (et la dématérialisation) des documents.

Imaginons un dossier de 5 000 pages, comportant des notes manuscrites, des plans, des diagrammes, des tableaux, une structuration (chapitres, sections, paragraphes). Composé de feuilles A4, à 5 grammes par feuille, notre dossier pèse 25 kilogrammes.

Quels sont les avantages d’une version numérisée de notre dossier ? Imaginons désormais que notre document soit disponible sous forme de fichier informatique.

1. Transport et accès : copié sur un disque dur externe, mon dossier ne « pèse » désormais que quelques dizaines de grammes. En y accédant via internet sur un cloud par exemple, je peux y accéder où je veux, quand je veux , sur un ordinateur personnel, une tablette ou un smartphone (lire mon article Pourquoi l’informatique est-elle « dans les nuages » ? )
2. Copie : en quelques secondes, je peux copier l’intégralité de mon dossier, pour un coût marginal. Je réalise autant de copies que je le souhaite. Une seule photocopie du document papier me coûterait environ 200 €.
3.  Diffusion : je peux partager mon dossier avec qui je souhaite en y donnant accès, en lecture ou en écriture, en quelques minutes. Envoyer une copie « papier » de mon dossier aux Etats Unis depuis la France me coûte 400 €, avec un délai de 2 à 3 jours. Déposer mon document sur un cloud et donner l’accès au document à d’autres utilisateurs ne prend que quelques minutes. Je peux également envoyer un lien vers le document par email en utilisant une plateforme sécurisée de téléchargement de fichier volumineux.
4. Sauvegarde : en copiant notre dossier sur un cloud et/ou sur un support externe, il est sauvegardé, à l’abri de tout incendie, intempérie, inondation, vol, usure (versus jaunissement et dégradation du papier).
5. Recherche dans le dossier :  en utilisant les fonctions basiques de recherche du logiciel de lecture du document, je retrouve en quelques secondes, des mots, acronymes, expressions, groupe de mots, ou des modifications apportées. Une utilisation plus avancée avec les techniques de LAD/RAD (lecture/reconnaissance automatique de documents) me permettent d’automatiser une partie des traitements que je souhaite effectuer sur la base des informations contenues dans le document.
6. Modification : je peux modifier mon document, le corriger, sauvegarder l’historique des modifications, collaborer en lecture et écriture avec d’autres personnes travaillant également sur ce document. Le travail collaboratif est extraordinairement optimisé.
7. Lecture : en quelques secondes je peux accéder, par exemple, à la page 2 758 de mon document de 5 000 pages. Je peux zoomer, dézoomer, adapter la mise en page afin que mon confort de lecture soit optimal.
8. Annotations, paraphes et signature: avec la version numérisée, plusieurs personnes peuvent annoter, parapher et signer électroniquement le document. La signature électronique a une valeur légale: depuis la loi n°2000-230 du 13 mars 2000, la signature électronique dispose de la même force probante que la signature manuscrite. L’article 1316-4 du Code civil prévoit en effet que la signature électronique est une preuve littérale au même titre qu’une signature manuscrite.
9. Correction et traduction : des correcteurs orthographiques et grammaticaux, voire des traducteurs automatiques sont disponibles. Bien sûr, rien ne vaut un travail humain pour finaliser une version correcte du dossier.
10. Rangement : Volume physique occupé = 50 cm * 21 cm * 29, 7cm = 31 185 cm3  pour le document papier.
11. Coût pour l’environnement : on produit environ 8 500 pages avec 1 arbre moyen.

Voilà donc quelques avantages qui illustrent l’intérêt de travailler sur des documents numériques. Ils sont nombreux et je vous propose de continuer à les recenser en commentant cet article.

 

ROI et NPV (retour sur investissement et net present value)

   Le retour sur investissement (ROI: return on investment, retour sur investissement) est un calcul visant à démontrer, qu’après un certain temps, l’investissement que vous réalisez va vous rapporter beaucoup plus que ce que vous dépensez.

Pour le quantifier, trois principales entités entrent en jeu:

• le facteur temps
• le montant de l’investissement
• le gain réalisé

Le gain réalisé

Le gain réalisé correspond aux économies que vous allez réaliser grâce à votre investissement: il peut s’agir d’un gain en productivité, d’une réduction des dépenses et achats, d’une augmentation de vos ventes rentables.

Par exemple , un logiciel peut vous permettre de passer deux fois moins de temps sur une activité. Le coût de votre activité est donc réduit de moitié dès que vous êtes formés et l’utilisez. Ou encore, un progiciel permet de réduire de 10% les temps de coordination d’une équipe de 100 personnes (*). Alors, chaque personne dégage 1 dixième de son temps pour ses activités principales. L’économie réalisée correspond au travail à temps plein de 10 personnes, qui peuvent dès lors se concentrer pleinement sur leur cœur de métier.

L’investissement

Le montant de l’investissement peut se décomposer en deux principaux paramètres : le CAPEX (coût ponctuel) et l’OPEX (coût récurrent). Par exemple si on achète un logiciel 100 000 € en CAPEX, on aura un OPEX de 20 000 € par an au titre de la maintenance évolutive, corrective, et du support qui est proposé. Ou encore si on loue un logiciel 5 000 € par mois (SaaS), maintenance et support inclus, il n’y a pas de CAPEX. Enfin si on achète un meuble neuf, il n’y a quasiment pas d’OPEX (hormis le temps que l’on passera à l’entretenir).

Le facteur temps

L’échelle de temps est ponctuée par le lancement du projet et le point mort, comme l’illustre le schéma ci-dessous:

A inflation nulle, le retour sur investissement (ROI) commence donc à opérer après le point mort, c’est à dire le moment d’équilibre entre l’argent investi et les économies réalisées.

Quant au NPV (net present value), il s’agit simplement de se dire: en cas de statut quo, donc si vous retardez votre investissement, vous décalez le point mort et décalez donc d’autant l’encaissement des gains nets cumulés réalisables.

Jean-Michel Lucas

©2018-2024

(*) lire mon article : Tableurs, solution durable ?

« Patience et longueur de temps font plus que force ni que rage. »

Jean de La Fontaine

Le stop and go dans la transformation numérique

  Disons que le déploiement d’un progiciel correspond à sa mise en production pour tout ou partie de ses utilisateurs. Alors, l’engagement proposé repose sur une date anticipée.

Comment s’assurer du respect des délais ? Comment planifier le projet ?

Une première approche consiste à définir la date de mise en production en partant de cette date future; bref, à concevoir un planning inversé (rétro-planning). 

Ainsi, en simplifiant, la séquence 1. spécifications, 2. développement et paramétrage, 3. tests 4. recette interne, 5. recette externe, 6. ajustements, et 7. mise en production, aura à être planifiée en commençant par l’étape 7. puis 6. 5… jusqu’à la date présente.

Cet exercice comporte des règles de l’art, à l’époque de la méthode dite du cycle en V, on avait coutume de répartir en trois tiers les phases de a. spécifications, b. développement et paramétrage, c. recette, tests et ajustements.

Avec les méthodes agiles, on procède me semble-t-il, finalement, de la même façon, à ceci près que l’on découpe le projet en tranches, chaque tranche correspondant à une sous-partie des fonctionnalités attendues, ou à la résolution d’une anomalie, ou bien encore à une évolution.

Mais cette vision de l’organisation du temps du projet ne peut en aucun cas se faire sans une co-construction avec la maitrise d’ouvrage, autrement dit le prospect (en avant-vente) ou le client (après la vente). Respecter les délais nécessite un accord préalable entre maitrise d’œuvre et maitrise d’ouvrage sur les modalités d’interactions entre les deux parties. C’est la continuité du respect de cet accord lors du projet qui constituera un facteur limitant de risque de ce que l’on appelle couramment les dérives, c.à.d tout simplement les retards.

Vouloir objectiver cet accord, c’est d’abord quantifier les ressources humaines nécessaires, tant du côté de la maitrise d’ouvrage que de la maitrise d’œuvre. Aussi le coût global du projet inclue l’addition du montant de la commande avec le coût investi par le maître d’ouvrage. 

On doit donc veiller à une transparence quant à l’application d’abaques donnant les ratios :

Temps passé par la maitrise d’ouvrage (tmoa) / Temps passé par la maitrise d’œuvre (tmoe)

tmoa/tmoe < 0.1 : les délais ne seront pas tenus et en conséquence la date de mise en production sera décalée. 

Par ailleurs, tout retard implique une augmentation du coût projet (TCO: total cost of ownership).

Le retard du démarrage du projet lui-même induit une augmentation du TCO, on peut essayer de la prévoir avec le calcul du NPV (net present value). 

Le retour sur investissement (ROI: return on investment) global est lié à une augmentation de la performance de l’entreprise après la mise en production, tout simplement lorsque les utilisateurs ont été formés et utilisent la nouvelle infrastructure progicielle en mode nominal.

Et l’exercice budgétaire, traditionnellement annuel, est-il possible sans associer le montant prévisionnel du projet avec le temps de réalisation nécessaire ? 

Reprenons la liste des principaux critères :

La date de mise en production prévue (liée aux exercices fiscaux, aux publications des comptes et résultats, aux autres projets en cours).

La charge de travail de la maitrise d’ouvrage dédiée.

La charge de travail de la maitrise d’œuvre dédiée.

La date de démarrage du projet.

Et surtout, le respect tout au long du projet de l’accord entre le fournisseur et le client.

Les paroles s’envolent et les écrits restent. C’est du ressort de l’avant-vente que d’inclure dans sa proposition les modalités de cet accord. C’est de la responsabilité du client de s’engager, à la signature, au respect de ces modalités. Sans quoi le projet n’est rentable ni pour la moa, ni pour la moe.

 

Jean-Michel Lucas

©2018-2024

SaaS : Software As A Service ?

  Utiliser à titre gratuit, louer ou acheter, telle est la question …

La production d’un logiciel mobilise des moyens : d’abord naît l’idée, puis la conception, les spécifications, la réalisation, les tests, et ce que l’on appelle la mise en production.

Le fait même d’évoquer succinctement ces étapes implique qu’un travail est réalisé. Et comment est-il alors possible que la gratuité des logiciels – progiciels, App(s), et autres utilitaires- soit si répandue ?

D’abord parce qu’il existe des supports matériels aux logiciels (smartphones, tablettes, ordinateurs) dont le coût inclut bon nombre d’entre eux. Ensuite parce qu’il existe également des communautés de bénévoles qui contribuent à cette production. Enfin parce que les publicités financent certaines productions en contrepartie d’une visibilité de leur contenu au sein du logiciel.

Ayons également en tête l’Etat et les Institutions publiques, qui proposent l’utilisation gratuite d’outils financés par l’impôt et les cotisations obligatoires. Et, bien sûr, les entreprises qui mettent à disposition des particuliers ou de leurs clients de l’informatique les aidant et les fidélisant.

C’est extraordinaire : de quels autres types d’outils bénéficiez-vous sans que cela ne vous coûte ?

C’est paradoxal : comment envisager un avenir du logiciel, donc une production et une maintenance, sans qu’aucun ne daigne le financer ?

La gratuité du logiciel est une illusion. Chacun doit en prendre conscience ; on lit si souvent la question « qui connait un logiciel gratuit qui … ? ».

Alors, évoquons ici trois modalités de sa commercialisation : 

• Le modèle freemium
• La location
• L’achat

Le modèle freemium consiste à mettre à disposition de l’utilisateur, gratuitement, une partie des fonctions de l’outil logiciel, puis de proposer, moyennant un loyer ou un achat, une version plus complète de l’outil. C’est une bonne possibilité de faire découvrir l’outil au plus grand nombre tout en pariant que cet investissement sera rentabilisé par une extension payante de son usage. Son succès est lié à la popularité, l’addiction ou l’impérieuse nécessité.

La location est de plus en plus répandue et classique : c’est le fameux « Software As a Service -SaaS-« , le « logiciel comme un service », dont les modalités de mise en œuvre sont définies par un loyer (le plus souvent mensuel) et une durée d’engagement (le bail).

L’achat est également toujours possible et sera généralement assorti d’un contrat de maintenance (évolutive et corrective) et d’un contrat de support. Typiquement le montant d’exécution ces contrats – non obligatoires – est, pour une annuité, de l’ordre de 20% du montant de l’achat.

Bien sûr, il conviendra d’analyser les avantages et inconvénients de ces modèles, à la fois pour les éditeurs mais aussi pour leurs clients.

Vu par l’éditeur, le SaaS permet la génération de revenus récurrents et une visibilité sur l’activité de l’entreprise pour plusieurs années.

Pour le client, le SaaS permet de s’équiper sans trop réduire sa trésorerie voire devoir faire appel à l’emprunt.

Les critères pertinents de décision sont multiples : durée de l’engagement, coût de l’abonnement (mensualité), nombre d’utilisateurs, évolutivité. 

A suivre …

Jean-Michel Lucas

©2018-2024

 

 

Pourquoi l’informatique est-elle « dans les nuages » ?

  Le « cloud computing », littéralement l’informatique du nuage, ou en nuage, est omniprésent et mérite quelques explications. Il désigne simplement le fait que l’information numérisée réside en dehors des locaux de la société, l’entité hôte étant distincte de l’entité utilisatrice.

Ce jargon anglo-saxon illustre donc une réalité historique qui existe depuis que le réseau informatique a permis le lien entre un lieu d’utilisation des données et leur hébergement.

Par extension, on parle de cloud computing en désignant les entreprises spécialisées dans l’hébergement de serveurs informatiques ; on parle alors de datacenters (« centres de données »). 

On parle donc avec le cloud computing d’externalisation de l’hébergement des données mais aussi des traitements sur ceux-ci: outre les mémoires, les processeurs sont en dehors de l’entreprise. Et les logiciels : systèmes d’exploitation, logiciels spécifiques ou progiciels peuvent être également à l’extérieur de l’entreprise.

Ceci n’est pas bien sûr sans susciter des interrogations responsables quant à la maîtrise des données et de leur traitement. Tout d’abord, il existe un contrat entre l’utilisateur et l’hébergeur qui, s’il est précis, indique la localisation, la disponibilité, et les droits d’administration de l’utilisateur. Par ailleurs, la circulation des données sur le réseau est garantie par des protocoles élaborés et normalisés. Le centre de données est une forteresse, le réseau est sécurisé. En outre un processus de sauvegarde et de réplication est assumé par l’hébergeur qui possède plusieurs datacenters.

Les tiers susceptibles d’interférer entre les deux parties (utilisateur et hébergeur) sont les transporteurs de données (opérateurs de télécommunications), les potentiels ayant droit comme l’état sous réserve d’une législation appropriée et de sa mise en application, et les nuisibles (malveillance et piraterie).

Et l’entreprise utilisatrice est responsable des données qu’elle exploite avec la protection de la donnée personnelle notamment (25 mai 2018: loi européenne GDPR – general data protection regulation), mais aussi évidement par les contrats qui la lient avec ses clients et partenaires.

Jean-Michel Lucas

©2018-2024

Tableurs : solution durable ?

  Une des raisons d’être des progiciels élaborés réside dans le fait qu’ils contiennent une base de données relationnelle en général normalisée. La normalisation est une garantie de souplesse, d’agilité et de réduction de saisies multiples d’informations identiques.

Par ailleurs, ce que l’on appelle souvent les accès concurrents, c’est à dire la possibilité pour plusieurs personnes de travailler en même temps sur le même progiciel, constituent fréquemment un impératif à la bonne exécution des processus fonctionnels de l’entreprise. Fusse-t-elle autre qu’unipersonnelle, une société requiert l’exécution de tâches collaboratives, et la création de richesse est simplement augmentée lorsque les agissants interviennent simultanément sur le même contenant.

Essayez donc de faire travailler plusieurs personnes sur un même fichier de tableur …

Non pas que les tableurs soient inutiles, mais les remplacer par des solutions logicielles dotées de base de données relationnelles constitue un effort conduisant à une optimisation de la performance de l’entreprise.

Il faut donc changer !

Mais la « disruptivité » permanente est aussi source de chaos. Une bonne gestion de projet et un accompagnement fondent donc les conditions nécessaires à un tel changement.

Jean-Michel Lucas

©2018-2024