Etude de faisabilité

le 11 Mars 2010, par Stéphane

Quelques réflexions complémentaires aux slides pour bien appréhender l'étude de faisabilité d'un projet web

Ne jamais sous-estimer l'étude de l'existant

L'étude de l'existant consiste comme son nom l'indique à... comprendre où l'on met les pieds pour ensuite étudier l'écart entre ce qui existe et le besoin exprimé. Si le principe est simple, sa mise en pratique l'est beaucoup moins. Car, derrière l'ordre apparent, se cache souvent une réalité moins glorieuse : applications pirates, documentation rarement à jour, peu ou pas d'urbanisme... La première étape de l'étude, le recueil d'informations (nombre d'applications, qui fait quoi, comment, avec quelles technos...), est donc souvent beaucoup plus longue et complexe que prévu. Le chef de projet se transforme vite en archéologue dépoussiérant des strates de documentation que tous pensaient oubliées.

Pas de diagnostic sans besoin clairement exprimé

Il est impossible de mesurer l'écart entre l'existant et la cible sans une expression du besoin très claire et exhaustive. En effet, pour mesurer l'écart il faut :
  • savoir ce que fait le système actuel et comment il le fait (pour cela il faut une documentation fonctionnelle et technique à jour) ;
  • savoir ce que fera le futur système et comment il le fera (pour cela il faut une expression du besoin précise).

Attention aux écarts partiels

Le diagnostic permet de mesurer trois types d'écart:
  • total (le besoin n'est pas couvert),
  • nul (le besoin est couvert à 100% et de la manière souhaitée),
  • partiel (le besoin est partiellement couvert et/ou pas de la manière souhaitée).
Les deux premiers types d'écart nécessitent peu de travail. Mais le chef de projet web doit se méfier des écarts partiels qui peuvent être très chronophages.

Bien typer les scénarios pour bien évaluer les solutions

Une fois les solutions décrites, le travail principal consiste à les évaluer. Pour que l'évaluation soit juste, il faut imaginer comment chaque solution sera mise en œuvre. C'est le rôle des scénarios. Typiquement, un "gros" CMS s'inscrira dans un scénario multi-prestataires incluant une SSI et une webagency. Avec pour conséquences, d'alourdir la charge (coordination plus lourde, méthodologie plus lourde), d'étaler le planning (démarche linéaire) et d'augmenter les risques de situations de blocage (plusieurs prestataires). La solution alternative, un petit CMS par exemple, sera mise en œuvre dans un scénario mono-prestataire. La charge sera allégée (attention au confort de travail), le planning raccourci (est-ce l'objectif du projet ?) mais les risques ne seront pas diminués. Au contraire, le prestataire sera peut être plus limité en termes fonctionnels ; il n'aura peut être pas la disponibilité nécessaire pour mener la mission dans de bonnes conditions...

Ne pas sous-estimer le travail d'évaluation

Pour évaluer précisément une solution, il est indispensable de prototyper un peu. Or, l'installation de 3 solutions de boutique en ligne et le paramétrage d'un bout de catalogue demandent souvent 2 ou 3 jours de travail, voire beaucoup plus. Si le chef de projet n'est pas capable de prototyper lui même, le recours à des experts lui coûtera cher. Reste le recours à des comparatifs disponibles en ligne. Mais cette solution est risquée car la plupart des comparatifs (de CMS par exemple) datent ou sont réalisés trop rapidement pour être utilisables dans le cadre d'une étude de faisabilité.

comments powered by Disqus