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
- Quel sont les besoins fonctionnels ?
- Quelle ergonomie est souhaitée ?
- Rédaction et émission d’un cahier des charges
- Réception des réponses
- Décision
- Lancement du projet
Le processus qui me semble participer d’une démarche optimisée:
- Quelles sont les fonctions offertes par les différentes solutions du marché ?
- Quels sont mes besoins essentiels parmi ces fonctions ?
- Rédaction et émission d’un cahier des charges orienté éditeurs
- Choix de l’éditeur
- 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
La transformation numérique des entreprises 