Pourquoi les projets logiciels dérapent, et comment l'éviter

Le projet devait durer trois mois. Un an plus tard, l'application n'est pas en service, la facture a doublé, et l'équipe continue de travailler sur le tableur. Si vous avez vécu ça, vous n'êtes pas un cas isolé, et ce n'était probablement pas une question de compétence technique.

Les projets logiciels dérapent presque toujours pour les mêmes raisons. Elles se voient avant de signer, à condition de savoir quoi regarder.

Cause 1 : tout décrire avant d'avoir rien vu#

Le réflexe est compréhensible : on veut maîtriser le budget, donc on écrit tout à l'avance. Trois mois de cahier des charges, cent pages, chaque écran décrit. Puis le prestataire construit exactement ce qui est écrit.

Le problème, c'est que personne ne sait décrire un outil qu'il n'a jamais utilisé. Le conducteur de travaux découvre à la livraison que l'écran demande six champs là où il en remplit deux sur le chantier. Chaque correction devient un avenant.

Le garde-fou : décrire le premier problème à régler et les personnes qui s'en serviront, pas l'application entière. Le reste se précise en voyant tourner la première partie.

Cause 2 : une première version qui arrive trop tard#

Plus on attend pour montrer quelque chose, plus les écarts s'accumulent sans que personne les voie. Un projet dont rien ne tourne après quatre mois est un projet dont on ne peut pas juger l'avancement : on juge un planning, pas un outil.

Le garde-fou : exiger une version utilisable sur un vrai cas dans les premières semaines. Chez nous, une première version sort en quatre à six semaines sur un premier périmètre. Ce qui compte n'est pas le chiffre exact, c'est qu'un vrai utilisateur s'en serve tôt.

Cause 3 : construire pour le bureau, pas pour le terrain#

Beaucoup de projets sont définis par la direction et le service administratif. Les écrans sont pensés depuis un ordinateur, avec tout le temps devant soi. Puis le chef d'équipe doit s'en servir debout, sur un téléphone, entre deux livraisons. Il revient au message et au papier, et l'application reste vide.

Le garde-fou : que le prestataire passe du temps avec ceux qui saisissent, pas seulement avec ceux qui lisent les chiffres. Un écran de terrain se teste sur le terrain.

Cause 4 : un devis qui ne dit pas ce qu'il ne contient pas#

Deux devis au même montant peuvent décrire deux projets très différents. Le nombre de rôles, de circuits de validation et de logiciels à raccorder fait bien plus varier le prix que le nombre d'écrans. Quand ces points ne sont pas écrits, ils reviennent en cours de route sous forme de suppléments.

Le garde-fou : faire écrire noir sur blanc ce qui est inclus, ce qui ne l'est pas, et ce que coûte une évolution après la mise en service. Nous avons détaillé ce qui fait bouger le budget dans l'article sur le prix d'une application métier.

Cause 5 : ne rien voir du travail en cours#

Le dirigeant reçoit des comptes rendus, pas l'outil. Il ne sait pas combien de personnes travaillent réellement sur son projet, ni où en est le code. C'est souvent la première question qu'on nous pose, et elle est légitime.

Je ne sais pas combien vous êtes derrière, ni combien de temps vous allez mettre.

Le garde-fou : un accès au code dès le premier jour, un dépôt à votre nom, et une version en ligne que vous pouvez ouvrir quand vous voulez. Le point juridique est expliqué dans l'article sur la propriété du code.

La grille à remplir avant de signer#

Posez ces questions à tout prestataire, nous compris. Une réponse floue sur l'une d'elles est un signal.

Ce qui change avec une application construite bloc par bloc#

Au lieu d'un grand projet livré d'un coup, l'application se construit par blocs, en commençant par celui qui rapporte le plus. Pour une entreprise de rénovation, c'est souvent le suivi des devis. Pour un négociant, la réception des marchandises.

Concrètement :

• le premier bloc est en service pendant que le suivant se prépare, et il sert déjà ;
• les remarques des équipes arrivent sur un outil qu'elles utilisent, pas sur un document ;
• chaque bloc remplace un outil existant, un tableur ou un groupe de messagerie, au lieu de s'y ajouter ;
• vous voyez l'application et le code à tout moment, sans attendre un compte rendu.

Un exemple de ce découpage est visible sur notre démonstration pour une entreprise de rénovation, et la démarche est décrite sur la page votre application.

Projet logiciel qui dérape : ce qu'il faut retenir#

Un projet dérape rarement à cause du code. Il dérape parce qu'on a tout décrit trop tôt, montré trop tard, pensé pour le bureau, laissé le devis dans le flou, ou travaillé sans que le client voie rien.

Chacune de ces causes a un garde-fou simple, qui se pose avant de signer. Si un projet a déjà mal tourné chez vous, commencez par récupérer le code et les accès, puis ramenez le périmètre à un seul bloc qui tourne.