Le problème

Suite à de nombreux incidents de fin de projet, sur Progonline, nous avons pu sélectionner un certain nombre de points qu’il est important d’établir dès le début pour votre projet web. Cela vaut pour le client, mais également pour le prestataire. A la fin du projet, quand ces problèmes apparaissent, c’est trop tard, et le projet prend du retard. Prestataire et client entrent souvent en conflit pour cette raison.

La solution

• Définissez pour quels navigateurs et quelles versions le site web doit-il être compatible. Les clients ont le reflexe de demander ou de sous-entendre “compatibilité toutes versions, tous navigateurs (MAC, PC, IE toutes versions, FF toutes versions, Conqueror, Mozilla, etc.)”. Bien évidemment, ce n’est pas possible. Si on peut obtenir une compatibilité pour 95% des utilisateurs (il suffit de prendre les 2 dernières versions de Internet Explorer et Firefox), aller au delà est très difficile et onéreux. Sauf cas spécifiques, l’intérêt de tout le monde est de s’arrêter à ce niveau. Précisez explicitement dans votre cahier de charges les navigateurs pour lesquels il faut assurer la compatibilité, cela vous servira à la fin.
• Définissez la/les résolutions pour lesquelles le site web doit être compatible/optimisé. Même remarque que précédemment, peu de sites offrent une compatibilité toutes résolutions. Ils ont de surcroît un graphisme minimaliste et un template particulier (tout est concentré en haut à gauche). Mentionnez clairement les résolutions pour la réalisation du projet web.
  
• Faites attention aux problèmes liés à la différence d’environnement entre le serveur de test/développement et le serveur de production. Très souvent, le prestataire développe le projet sur son propre serveur, sur lequel il a un certain environnement, avec certaines versions, avec des droits le plus souvent absolus. Le site fonctionne parfaitement chez lui, mais lors du déploiement sur le serveur du client, le prestataire rencontre de sérieux problèmes :
  • la version PHP et MySQL n’est pas la même que chez lui;
  • il n’a pas accès aux crontab;
  • il n’a pas accès root à la machine;
  • il ne peut modifier le fichier php.ini;
  • il n’y a pas d’accès https;
  • etc…

Dans ce genre de cas, le mieux est de s’y préparer à l’avance, soit en développant directement sur le serveur du client, soit en synchronisant systématiquement, soit en lui spécifiant clairement qu’il devra acheter un serveur avec des droits absolus pour le déploiement de son site sur l’environnement de production. Sinon, il devra vous indiquer ce qu’il va acheter, et vous devrez vous y adapter.
Recommandation

Dans le cahier de charges, introduisez une clause : Limites du projet. Dedans, mettez toutes les limitations “sensibles”, telles que les 3 points évoqués plus haut. Pour prévenir dans une certaine mesure les sous-entendus, introduises aussi la limite suivante :

“la réalisation de ce projet ne comprend que les modules/fonctionnalités explicitement mentionnées dans ce cahier de charges. Tout module supplémentaire fera l’objet d’un cahier de charges et d’un budget supplémentaires”.

Dans le cas d’un arbitrage, cette mention n’aura de valeur que dans le cadre de fonctionnalités supplémentaires majeures, hors des us et coutumes de la typologie de projet que vous réalisez. Néanmoins, elle peut faire refléchir le client plus attentivement avant de valider le cahier de charges initial.