Quel processus pour créer un site ou une application web ?

Quand on veut créer un site ou une application web, on a tendance à plus ou moins chercher une sorte de fil conducteur ou de processus pour ne pas partir et finir dans le choux, le décor et le rien.

Rappelons qu'en France, un projet informatique sur 2 ne finit jamais (au grand bonheur des SSII françaises qui fonctionnent à 80% en régie donc qui facturent encore + et encore mieux quand un projet s'enlise, cf Louvois et Steria: défaite militaire mais victoire financière pour la SSII ?? ).

Des milliers de méthodes, méthodologies, framework et autres dénominations du même genre existent pour montrer comment travailler.

Voici un joli dessin qui résume à peu près ce que le bon sens commun indique:

Seulement, il y a quelques hics ..

Tout d'abord, ces schémas et processus ne tiennent jamais compte:

- du temps disponible du client

- du délai de réalisation du design (qui va lancer un projet sans "design" ? Personne alors que ..  on pourrait s'en passer la plupart du temps, surtout que le design est souvent fait pour plaire aux tauliers du site, ce qui est débile puisqu'en toute logique, il doit plaire aux clients et prospects -à moins d'être une "marque" qui impose ses choix)

Tout ça fait qu'en général, un joli processus foire.

Concrètement, l'allant des développeurs et/ou la connaissance du projet se diluent dans le temps, les obligeant à chaque retour du client de reprendre connaissance du projet.

Résultat: le temps prévu explose et le "comptable" du projet commence à s'inquiéter.

Temps et délais provoquent aussi "réflexion" chez le client, qui change alors d'avis sur tel ou tel point.

Là intervient alors la capacité "commerciale" du prestataire: est-il capable de dire "non" au client, est-il rusé pour lui vendre quelque chose de plus, est-il faible pour tout accepter et faire une opération déficitaire ?

Y a-t-il une solution à tout ceci ?

Quelques pistes (que nous suivons ):

- séparer le design du reste du projet

- raisonner non pas en "tel truc à telle date" mais "à telle date + ou - tel truc) pour se baser sur le TEMPS et non les objectifs fonctionnels

- développer le plus possible avec des briques plutôt que de tailler tout au burin soi-même (ajouter une fonctionnalité ou en enlever une sera plus simple; par ailleurs, si quelqu'un a développé une brique, il y a forcément quelque part la réponse aux questions et nouvelles envies du client)

Par ailleurs (hé oui, il y a un autre hic, c'est un hoquet), la première étape de définition du projet, est complètement utopique.

Si un client a un projet "défini" au sens d'un "développeur", alors il sait le faire lui-même et n'a pas besoin d'un prestataire (il a peut-être besoin d'embaucher quelqu'un mais ne veut pas gérer une embauche et un licenciement une fois le projet fini).

Le "besoin" du client, la "définition" d'un projet est souvent une combinaison linéaire de différents exemples et voeux pieux: je voudrais un truc comme ça, avec aussi ça, un peu comme ça ..

Là encore, la définition du design est souvent symptomatique: "un truc dynamique, responsive (c'est la mode), qui soit clair pour l'internaute, qui corresponde à nos valeurs (là tout est dit en général :-)), avec ça, ça, ça et ça, et encore ça, et puis ça et ça .." 

Et bien sûr, le sapin de Noël orné de tous les ça, ne conviendra pas :-)

Si on veut arriver à un projet entièrement défini ... on n'y arrivera jamais car il y aura toujours une différence en 3 projets: le projet décrit sur le papier, le projet que veut le client et le projet expliqué aux développeurs. Là encore, le responsable est le temps: entre le moment où le client décrit son projet, celui où le développeur le comprend et le traduit, il y a forcément dans la tête du client une évolution (première différence) en plus d'un décalage de compréhension.

Les solutions ?

Découper encore en étapes "temporelles": on va commencer par ça puis ça. Le reste ? On verra après car VOUS (vous = client) aurez réfléchi en VOYANT les premières choses et donc VOUS aurez une idée plus précise.

On reparle encore du design qui est là encore un excellent exemple. Faire créer un design alors que le contenant et le contenu n'existent pas revient à avoir un  joli psd avec des phrases en latins qui comme par hasard font que les blocs sont toujours bien alignés, et les images toujours cadrées.

Quand le contenu et le contenant du site existent .. Oh bizarre, on a des phrases plus petites ou des textes plus longs et on n'a pas d'images en taille aaa x bbb comme dans le design ( ou alors on en a mais elles font 10 Mo )...

L'idée est donc de prendre les briques qui sont compréhensibles par tout le monde et de les faire le plus rapidement possible, en voyant le reste APRES avoir fait ces choses. La vision du client aura évolué, sera plus claire car basée sur du concret.

A propos de briques, cela baisse aussi sacrément les prix et coûts.

Un site de e-commerce ? Wordpress et Woocommerce et on en a la plupart du temps pour MOINS de 1000 euros .. (modulo le design)

Un site de contenu ? Aux alentours de 500 euros (modulo le design) avec un wordpress qui peut faire 95% de ce genre de sites.

Un extranet-intranet ? Là aussi un wordpress bien utilisé et 1000 euros + ou - 500 (modulo le design aussi). (A ce sujet, on vous présentera bientôt ICI un site avec extranet pour clients et partenaires, fct différentes pour les 2 types, réalisé avec Wordpress pour 1200 euros ht).

Voir aussi Coût d' un développement web et Combien vaut un blog Wordpress ?

Dernier point: la maintenance .. Un site web n'est pas un vélo .. Il ne s'use pas .. Et il faut que le client soit le plus possible autonome.

Plutôt que de la maintenance, il faut de la FORMATION pour que le client SACHE se débrouiller tout seul, non seulement pour le contenant et le contenu mais aussi pour des choses comme le SEO (http://www.redac-web-seo.com/ ).