1. Mal définir son besoin
La première pierre d'achoppement des projets informatiques est souvent une mauvaise définition du projet. "Nous répondons souvent à des cahiers des charges dont la précision varie du simple au double d'une rubrique (site web) ou d'une fonction de service (application métier) à l'autre. Résultat, certaines sont trop détaillées alors que d'autres sont à peine évoquées !", constate Stéphane Bordage. Pire, selon lui, certaines entreprises n'arrivent pas à déterminer la typologie de leur projet : s'agit-il d'un intranet de communication, d'une application métier, d'un site web ?
Ce qu'il faut faire :
- Commencer par caractériser le projet, quitte à être légèrement caricatural. Une vision claire de la typologie du projet permet de guider plus aisément les prestataires ou les équipes internes. Elle permet également de se poser rapidement les bonnes questions et d'isoler les pièges à éviter.
- Définir ensuite avec précision - mais sans excès - le besoin : fonctions de services, contraintes, règles de gestion, public visé, etc.

2. Se précipiter au début du projet pour tenir les délais
"Il n'y a rien de pire que de vouloir à tout prix tenir le budget et les délais en précipitant les phases amonts du projet. C'est la meilleure façon de ne pas y parvenir", estime Franck Laudet. Pour lui, il est fondamental d'investir sur les premières étapes de spécifications et de mise en place du projet. "C'est la meilleure façon pour éviter 80% des problèmes que l'on risque de rencontrer par la suite", explique-t-il.
Ce qu'il faut faire :
- Ne pas remettre à tout prix les spécifications dans les délais si elles ne sont pas complètement analysées. Mieux vaut perdre du temps pendant cette phase d'analyse plutôt qu'en fin de projet "où cela peut être beaucoup plus coûteux", rappelle Franck Laudet (photo).
- Prendre le temps de bien spécifier les aspects fonctionnels et ne pas s'appuyer sur les fonctions du progiciel pressenti pour gagner du temps.

3. Sous estimer la charge, le coût, et l'implication nécessaire
La réussite d'un projet repose à la fois sur le temps et les moyens financiers qu'on lui alloue et sur l'implication des équipes en interne. "A trop vouloir économiser sur le budget, on se retrouve souvent à devoir réaliser le projet en interne, même si l'on manque de certaines compétences", explique Serge Cadenat. Mais ce n'est pas le seul danger. "L'absence d'interlocuteur coté utilisateur, le manque de disponibilités ou encore des interlocuteurs trop nombreux et sans chef pour décider peuvent "plomber" un projet correctement dimensionné par ailleurs", note Franck Laudet.
Ce qu'il faut faire :
- Ne pas sous estimer le coût et la durée du projet : mieux vaut surdimensionner légèrement les besoins en ressources - quitte à réduire légèrement le périmètre du projet - que l'inverse.
- Eviter le classique "effet tunnel" (manque d'implication du client pendant la phase de développement) en animant concrètement le projet.
- Ne pas attendre trop longtemps l'implication d'une autre direction potentiellement légitime sur le contenu du projet. "Mieux vaut aller au clash que de chercher à tout prix à éviter les conflits directs. Ils éclateront de toute façon tôt ou tard", conseille Serge Cadenat.

4. Faire évoluer le périmètre fonctionnel en cours de route
"De nombreux clients sont conscients d'avoir validé des spécifications détaillées mais cela ne les empêche pas de demander des évolutions fonctionnelles avant même la recette de la première version", constate Stéphane Bordage. Résultat : les rustines s'accumulent dans la précipitation jusqu'au moment où il est préférable de tout remettre à plat...
Ce qu'il faut faire :
- S'en tenir aux contraintes initiales (périmètre fonctionnel, budget, charge, planning) quitte à livrer un projet moins ambitieux mais opérationnel.
- Temporiser et planifier à nouveau le projet s'il n'y a pas d'autre solution. "Même si cela reste souvent un voeu pieux, il faut conserver un périmètre de développement le plus fixe possible", conseille Franck Laudet.