NoSoftwarePackage pour Not Only Progiciel (1/7)

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.

Par rapport à mon expérience, je me suis aperçu que les grandes DSI essayaient toujours d’appliquer les mêmes solutions (aller vers l’achat de solutions toutes faites) même si ces dernières ne montrent pas de bons résultats.

Personnellement, je ne pense pas que tous les besoins doivent être couverts par des logiciels "fabriqués maison" et que des logiciels "prefabriqués" peuvent être une réponse adéquate, mais je ne pense pas non plus que tous les besoins passent par des progiciels ou des logiciels du marché.

Il est donc intéressant de réfléchir à ce qui peut faire peur dans le développement spécifique et pourquoi les personnes ont tendance à s’orienter vers l’achat de solutions toutes faites. Je vais essayer au cours d'une série d'article de mener une réflexion sur ce ce qui peut faire peur dans le développement spécifique et pourquoi les personnes ont tendance à s’orienter vers l’achat de solutions toutes faites.

Comme je le dis dans le titre NoProgiciel ne veut pas dire pas de logiciel mais comme pour le mouvement NoSql, je parle de Not Only Software Package

Les idées reçues plaidant pour l’achat d’un logiciel 
En tant qu’architecte applicatif le développement est mon cœur de métier. Comme je l’ai déjà dit je ne suis pas du style à proposer des développements spécifiques à tous les besoins métiers qui me parviennent, mais lorsque j’ai dû défendre certains cas où j’estimais qu’un développement en interne était plus approprié j’ai pu entendre des phrases du style

• Le développement est une solution trop risquée dans notre cas 
• Le développement interne est trop cher 
• Le développement n’est pas notre métier 
• Les développeurs ne sont pas efficaces 
• … 

Le développement est une solution trop risquée dans notre cas
En début de projet il est logique de se poser la question de l’intérêt de la mise en place d’un logiciel et de couvrir toutes les possibilités en pesant le pour et le contre. Certains feront remarquer que les solutions développées en interne sont pleines de bugs, que les livraisons ne sont jamais faites comme prévu initialement, que les charges sont sans arrêt dépassées, que le budget initial est multiplié par deux…

Deux solutions sont envisagées pour éviter les développements en interne

• Le mode forfait où on s’engage sur un prix auprès d’une SSII qui encaissera les dépassements par rapport au budget initial. On fait un report de certains risques côté éditeur mais ce mode ne va généralement pas dans le sens d’une amélioration de la qualité 
• L’achat d’une solution éprouvée dans le cas où le logiciel existe déjà. 

La performance au niveau d’une DSI est calculée sur sa compétence à fournir une solution répondant au besoin fonctionnel dans un délai rentrant dans un budget initial alloué. La DSI est rarement jugée sur le coût global d’une solution. Donc pour elle, la solution du progiciel est la solution la plus facile… et rien ne sert de s’embêter avec les risques liés au développement spécifique. Même si le progiciel est une solution surdimensionnée pour les directions métiers ou que la solution couvre vaguement le besoin, ce n’est pas gênant car ce n’est pas contraire aux objectifs fixés au départ.

Si on se place à un niveau plus global, au niveau de l’entreprise, la donnée n’est pas la même et le coût global est un facteur important. Le meilleur indicateur pour savoir si un projet est viable, est de calculer son ROI (return of investisment). Le ROI calcule le ratio entre l’investissement et le gain apporté par une solution. Obtenir un résultat proche de la réalité est un exercice difficile. Il ne faut pas oublier de prendre en compte les frais de maintenance ou de supports de la solution que l’on met en place, les frais d’hébergement, le coût du changement que ce soit au niveau de la formation des utilisateurs ou de l’utilisation du logiciel (un utilisateur peut gagner ou perdre en productivité)…

C’est là où on peut se poser la question. En quoi un progiciel développé dans un autre contexte se calera exactement aux besoins de l’entreprise, à son schéma, à son métier ? Bien souvent la question est posée à l’envers. Le progiciel ne répond pas à mon besoin donc c’est à moi de m’adapter à la façon de fonctionner de ce progiciel. On dirait que certains dirigeants sont prêts à oublier ce qui leur a permis d’arriver là où ils en sont. En quoi un progiciel externe pourrait remettre en cause l’histoire de la société, son métier, ses spécificités ? Chaque nouvelle version ou nouvelle solution demande t-elle une réorganisation ?

J’entends déjà les sceptiques dire que les gens sont contre le changement, que la  majorité des personnes est perdue quand ils n’ont plus les mêmes repères. Je me remémore souvent une personne à qui on avait mis en place une solution me dire « Les noms et les codes de mes clients et de mes fournisseurs ont été remplacés par des numéros techniques sans aucune signification… et on me demande d’aller aussi vite qu’avant pour répondre à nos clients…. Je passe déjà un temps inouï à les retrouver ».

Je ne dis pas, qu’il n’est pas nécessaire dans certains cas de réorganiser les différents processus dans une entreprise mais je m’interroge sur le fait d’attendre la mise en place d’une solution informatique pour le faire, ou plus gênant de se voir imposer une organisation par un logiciel.

On peut voir que la mise en place d’un progiciel est une solution qui minimise le risque pour une DSI, mais qui peut être beaucoup moins rentable quand on regarde la rentabilité à long terme.


Que peut-on faire pour optimiser les développements ?
Peut-on faire en sorte qu’ils remplissent notre objectif « produire le strict minimum, pouvoir tester le logiciel avant que tout soit terminé, le modifier rapidement si l’environnement commercial évolue afin de réduire les coûts », tout en ajoutant en contrôlant le ROI ?

Si on regarde l’état de l’art au niveau du développement en général, il a beaucoup évolué ces dernières années. Les méthodes agiles permettent de construire incrémentalement une application en restant ouvert aux évolutions afin que la solution développée réponde strictement au besoin de l’entreprise. Au niveau de ces méthodes, on trouve certaines tendances comme le déploiement ou les livraisons continues qui permettent de raccourcir et de fiabiliser les mises à disposition des applications en recette ou en production. Elles permettent de construire des applications qui collent aux besoins métiers et permettent d’être plus réactif face aux évolutions.

Les méthodes agiles peuvent aussi permettre de rester dans le budget initial. J’ai plusieurs fois entendu des remarques du style « les méthodes agiles sont très bien dans le monde des bisounours mais si le périmètre évolue sans arrêt comment fait on pour suivre les objectifs initiaux…. ».

Le principe de Pareto (ou la règle des 80-20) observe que 80% du résultat provient de 20% de nos efforts. Si on suit les principes agiles, les développements se font de manière incrémentale en se basant toujours en premier lieu sur les éléments critiques de l’application (use case avec une forte fréquence usage, UC de forte complexité technique….).

Si au bout de 6 mois de développement, vous estimez que le budget initial est atteint vous pouvez faire un état des lieux. Une solution n’a pas besoin de remplir 100% du cahier des charges pour être utilisée. Si 80% des fonctionnalités sont disponibles et que l’application est utilisable, les 20% restants peuvent être remis à plus tard ou abandonnés. Comme chaque itération fournit un livrable testable votre application doit être utilisable. On observe de plus en plus de solutions construites de cette manière aujourd’hui, où l’on essaie de développer et déployer vite afin d’avoir tout de suite le ressenti des utilisateurs. Les différentes fonctionnalités sont ajoutées au fur et à mesure.

Prévoir l'organisation d'une entreprise au delà de quelques années est une hérésie car le monde et en particulier le mode de l'informatique bouge beaucoup trop vite.

Dans le prochain article j'aborde une autre idée reçue "Le développement n’est pas notre métier"

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