NoSoftwarePackage (4/7) : n'est ce pas un contre sens métier d'avoir trop de fonctionnalités ?

Cet article fait partie de la suite d'article sur NoSoftwarePackage

Le contexte : 
Une question essentielle se pose lorsqu’un besoin informatique est identifié dans une entreprise. Doit-on construire la solution ou faut-il adopter une solution toute faite ? Dans la plupart des cas les entreprises orientent leur choix sur des solutions du marché, et les développements internes n’interviennent que si aucun logiciel n’existe ou seulement si aucun d’entre eux ne répond correctement au besoin.


Articles déjà publiés : 
Le développement est une solution trop risquée dans notre cas
Le développement n'est pas notre métier
Le développement spécifique peut être efficace

La première partie ne vous a peut être pas encore convaincu. Donc si vous pensez encore que le développement spécifique est le Mal absolu, essayons de nous attarder sur les problématiques liées à l’achat d’un progiciel. Car toute solution comporte des avantages et des inconvénients

Trop de fonctionnalités ?

Les progiciels sont faits pour répondre aux besoins d’un maximum de personnes, un maximum d’organisations. D’une société à une autre les processus ne sont pas forcément les mêmes. Pensez par exemple un logiciel de paie. On pourrait se dire, faire une paie n’est pas très compliquée. Il est donc logique de s’orienter vers un progiciel. Pourquoi s’embêter avec un logiciel maison ?  Mais quand on regarde de plus prêt, chaque société signe des accords de branches, des conventions collectives différentes et ont donc des règles différentes. Les éditeurs doivent construire des solutions complexes pour essayer de couvrir l’ensemble des besoins. La réglementation évolue sans arrêt demandant des adaptations permanentes des solutions, et forçant les clients de ces solutions à acheter les mises à jour.

Le modèle économique des éditeurs est de développer un socle le plus générique possible et  remplissant le maximum des besoins des clients potentiels. Dans un marché très concurrentiel, les éditeurs se font la course à celui qui présentera le plus de fonctionnalités.

Si on s’attarde sur les fréquences usages de ces fonctionnalités on se rend compte que très peu sont utilisées. Prenons l’exemple du logiciel de bureautique MS Word que tout le monde connait. La version 2003 comporte plus de 1000 commandes mais si on regarde de plus prêt seules quelques commandes sont utilisées (sauvegarde, mise en forme, copier/coller, impression). Une dizaine de commande suffisent pour couvrir 80% des besoins (Cette constatation est la base de la refonte de l’ergonomie de la version 2010 de Word). 

Il est difficile de trouver des statistiques précises sur ces fréquences usages mais on estime que la plupart du temps les utilisateurs lambda n’utilisent pas plus de 10% des fonctionnalités proposées dans les logiciels.

Vous me direz l’essentiel pour les utilisateurs est d’avoir au moins toutes les fonctionnalités dont ils ont besoin. Mais toutes les fonctionnalités non utilisées amènent une surcharge de l’interface venant polluer l’utilisateur final et son utilisation du logiciel. Ces problèmes d’ergonomie se traduisent souvent par une baisse de productivité et un plus grand effort de formation. Cet aspect n’est jamais pris en compte en début de projet alors que les impacts sur les utilisateurs peuvent remettre en question le ROI. 

Le prochain article parlera des problèmes liés au "paramétrage des progiciels"

Merci à Agnes Crepet, Anne Laure Rigaudon, Alfred Almendra, et les autres anonymes pour leur relecture et leurs différentes critiques.