Catégories
Uncategorized

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 une 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 ?

  • progiciel
    • dépendance vis à vis de l’éditeur (« souveraineté numérique »)
    • limitations quant à la « customisation » possible du progiciel
    • la « 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

vieille-roue-de-chariot-antique-2465566 (1)

Catégories
location SaaS software as a service Uncategorized

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

sharps_pixley_gold_bar_combibar_gold.jpg

 

 

Catégories
25 mai 2018 cloud computing contrat datacenter GDPR Jean-Michel Lucas logiciel Uncategorized

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

6f53f5d732_40476_nuage-blanc-gris