Ecrire un cahier des charges pour un développement de site web (1)

INTRODUCTION : CONTEXTE, INTERETS ET BUT DE CETTE SERIE DE NOTES “Ecrire un cahier des charges pour un site web”

Le développement informatique de systèmes d’information, de sites Internet et de logiciels  par des prestataires se fait en France en grande partie en mode Régie (Obligations de moyens pour le prestataire qui détache chez le client une ou plusieurs personne(s) pour réaliser un projet dont a priori les personnes détachées connaissent l’objet et la façon de le réussir). La crise, les dépassements de budget et de temps, l’importance croissante des SI dans les entreprises, la montée en puissance des acheteurs dans l’utilisation des prestataires ainsi que les problèmes juridiques et humains du détachement de personnel font que le mode de travail au forfait se développe grandement.

Dans le cas des sites web, les utilisateurs finaux ou les agences en conseil, communication ou même les “web agency” ont de plus en plus rarement la possibilité ou même l’envie de détacher du personnel technique chez le client car celui-ci veut toujours quelque chose pour la veille et ne veut en aucun cas avoir à gérer le développement et ses problèmes..

Travailler au forfait implique pour le prestataire une obligation de résultats, de qualité et de délais en réponse aux exigences du client. Cela nécessite du prestataire non seulement des connaissances techniques mais aussi de véritables connaissances en gestion de projet pour garantir au client qu’à des dates planifiées, les livrables prévus (qui peuvent être autre chose que du code source – documentation, plan de test, données, interfaces…- ) seront dans l’état attendu, physiquement et accessibles aux endroits définis.

Pour la plupart des sites et développement web, les livrables se réduisent au site (ou développement) lui même en une seule fois, modulo les problèmes récurrents de design à changer ou de process ergonomique ou de cheminement de l’internaute à faire évoluer une fois que tout est fait

Un projet de développement informatique commençant logiquement par une demande de développement et donc dans le cadre du forfait par une cotation de la réalisation du projet par le prestataire (qui doit en outre préciser quelques détails comme les phases et les délais), la première difficulté à résoudre est pour le client, l’établissement (avec ou sans aides extérieures) d’un Cahier des Charges –cdc- (ou Expression de besoins ou Spécifications ou Spécifications Fonctionnelles ou Cas d’utilisation ou Maquettes ou Modèles ou Exigences ou Scénarios, etc, etc...).

Chez les différents prospects et clients rencontrés par Tubbydev, qu’ils soient des start-up, des grands comptes, des PME, le problème du cahier des charges s’est toujours posé et ce pour 2 raisons principalement :

-       « Cahier des charges » signifie en général pour le client: document décrivant tout le système à développer y compris la manière dont les opérations « informatiques » doivent être menées, donc document très lourd et très long à écrire !!!

Par exemple, si le client est un adepte de MERISE « cahier des charges » signifie pour lui MCD, Processus, etc.. A l’époque actuelle où les besoins satisfaits par l’informatique, les utilisateurs de l’informatique et les souhaits des clients changent souvent, s’engager dans l’écriture d’un Cdc de ce type court inévitablement à l’échec du projet (sauf si on a l’équipe capable de le faire VITE) car quand ce Cdc sera prêt, les exigences des différents clients et des autres acteurs du système auront changé (notamment à cause de la réflexion menée par l’établissement du cdc ;-)) 

-         la personne chargée chez le client de la rédaction du Cdc sera l’objet de toutes les pressions du projet. Pression du prestataire qui demandera de l’information supplémentaire et pression des utilisateurs finaux qui auront tendance à confondre ce qui a été réalisé avec ce qu’ils veulent actuellement et donc à « accuser » le chef de projet « Cdc » de la non adéquation du système à leurs envies présentes. Ce phénomène est loin d’être négligeable et explique à notre avis pourquoi la plupart des grandes entreprises françaises ne font que très peu appel au forfait. Qui aurait en effet envie au sein d’une DSI de grand groupe de se créer des conflits avec des personnes d’autres branches de l’entreprise ?

Le problème principal vient de l’orientation mentale, donnée par notre éducation, avec laquelle on considère le ……. développement …… de “quelque chose”.

Nous le considérons en effet la plupart du temps exactement de la même façon dont on considère la construction d’un immeuble..

Il faut D ABORD faire un plan (le cdc) et seulement ENSUITE l’immeuble qui lui se construira D ABORD par les fondations, SUIVIES des murs porteurs, etc, etc..

C’est une façon de penser SEQUENTIELLE qui refuse l’idée qu’on puisse commencer une étape N si l’étape N-1 n’est pas finie et validée…

Par ailleurs, on considère le RESULTAT à obtenir.. “je veux un site pour vendre des produits xx avec yy, rrr  caractéristiques”  et jamais par les CAS D’UTILISATION: “je voudrais une “chose web” qui permette à un internaute de faire le choses suivantes:  “arriver sur une page qui lui propose soit de “ACTION A” soit de “ACTION B” et ensuite, si il y a eu A, de faire ACTION AA ou ACTION AB, etc, etc……

A suivre ……