NoSoftwarePackage (7/7) : développement spécifique ou progiciel ?

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 : 
Les premiers articles essayent de répondre aux détracteurs du développement spécifique
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

Les suivants montrent les points noirs des logiciels/progiciels
N'est ce pas un contre sens métier d'avoir trop de fonctionnalités ? 
Un nouveau nom pour le développement introduit par les progiciels... le paramétrage
Effets d'engrenage des progiciels

Le "Not Only Software Package" signifie "Pas Seulement du Progiciel" et le développement spécifique est une alternative plausible et parfois nécessaire. Mais vous me direz quand choisir l'une ou l'autre solution?

Je vais vous exposer la vision de Martin Fowler. Pour ceux qui ne le connaîtraient pas, Martin Folwer est un pionnier et une référence au niveau développement. Il a beaucoup œuvré pour améliorer l’architecture logicielle et il a publié plusieurs bouquins sur les design patterns, sur l’agilité….  Il est une des personnes ayant participé à la rédaction du manifeste agile. Les articles de son blog sont toujours très intéressants à lire

Comme sur d’autres sujets je partage sa vision du progiciel vis-à-vis des développements spécifiques. Je ne suis pas partisan du tout progiciel ni du tout développement spécifique.

Si un progiciel est mis en place il faut être intransigeant sur les personnalisations et les bannir au maximum. Il faut également se poser la question sur le coût réel de la solution et ne pas sous estimer les coûts d’un progiciel et sur estimer les coûts des développements internes. Un progiciel ne se résume pas au prix de sa licence.  Que ce soit sur la mise en place d’un progiciel ou pour le développement de sa propre solution il est important de se construire la solution de manière incrémentale (méthodes agiles).

Une entreprise ne devrait pas partir sur des progiciels pour gérer le cœur de son métier, ou pour tout domaine stratégique où elle doit se démarquer de ces concurrents. Dans ces cas précis, la meilleure stratégie est le développement spécifique car il permet d’être beaucoup plus réactif et présente moins de risque pour la stratégie d’entreprise. 

Martin Fowler illustre ce cas par le pattern UtilityVsStrategicDichotomy permettant d’identifier si un besoin peut être classifié dans la catégorie utilitaire ou stratégique.  Pour classifier un logiciel il faut déterminer si la fonction métier derrière ce logiciel est un critère différenciateur par rapport à la concurrence. Si oui il sera stratégique pour l’entreprise.

Par exemple un logiciel permettant de suivre la masse salariale sera classifié dans la catégorie utilitaire. Même si la masse salariale est une donnée importante pour une entreprise le suivi de cet indicateur est quelque chose de commun à toutes les sociétés. Ce n’est pas le logiciel de suivi qui fera qu’une entreprise sera meilleure qu’une autre.

L’effort de la mise en place d’un projet stratégique ne doit pas être le même que pour la mise en place d’un logiciel utilitaire. Il est fréquent que les gens pensent que tous les logiciels sont stratégiques. Pour un contrôleur de gestion son logiciel de suivi de la masse salariale est stratégique mais ce n’est pas pour cela qu’il l’est pour l’entreprise.

Les logiciels utilitaires sont nécessaires mais vous avez simplement besoin qu’ils fonctionnent. Vous pouvez mettre des moyens importants pour que le logiciel fonctionne toujours, mais ce n’est pas vital pour l’entreprise.

Pour un projet stratégique c’est différent, car le plus grand risque est de ne pas faire quelque chose avant son concurrent. Il faut toujours garder le moyen d’intervenir rapidement sur ces solutions. Le coût ici ne doit pas être compté car le plus gros risque financier est de ne pas pouvoir agir à temps pour gagner un marché….  Dans ce cas précis il faut éviter à tout prix les progiciels car leurs rigidités paralysent la capacité d’une entreprise à se différencier.

Pour les logiciels utilitaires le progiciel est un bon candidat à la condition que vous ne vous ruiniez pas en personnalisation. Si c’est possible il est préférable de revoir son organisation plutôt que de trop personnaliser un progiciel sinon un développement interne à moindre coût sera plus bénéfique.

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