Le vrai problème n’est souvent pas le développeur, mais le manque de cadrage

Lorsque l’on développe une application sur mesure, beaucoup pensent que le plus difficile est d’écrire le code. En réalité, le plus grand défi commence bien avant la première ligne de programmation.

Le véritable enjeu est de comprendre précisément ce que le client souhaite… et c’est souvent là que les difficultés apparaissent.

Le client connaît son métier… mais pas forcément sa solution

Un entrepreneur maîtrise parfaitement son activité. Il sait quelles difficultés il rencontre au quotidien.

En revanche, il est beaucoup plus difficile pour lui de transformer ses besoins en spécifications techniques précises.

Il est donc fréquent d’entendre des phrases comme :

• « Je veux quelque chose de simple. »
• « On verra pendant le développement. »
• « On ajoutera ça plus tard. »
• « Je pensais que c’était évident. »

Ces remarques sont parfaitement normales. Elles ne traduisent pas un manque de compétence, mais simplement le fait que chacun parle avec son propre métier.

Le développeur pense en logique informatique.

Le client pense en besoins métier.

Entre les deux, il faut construire un langage commun.

Le problème des projets sans cahier des charges

Lorsqu’un projet démarre sans véritable phase de cadrage, les premières semaines semblent souvent très productives.

Puis arrivent les demandes du type :

• « Finalement je préfère que ce bouton soit ici. »
• « Est-ce qu’on pourrait changer tout le fonctionnement ? »
• « En fait nos techniciens travaillent autrement. »
• « Nous avons changé notre organisation. »

Chaque modification paraît raisonnable prise individuellement.

Mais après plusieurs dizaines de changements, on ne parle plus d’ajustements.

On est en train de redéfinir complètement le projet.

Le piège du « ce n’est qu’une petite modification »

C’est probablement la phrase que tous les freelances entendent le plus souvent.

« Ce n’est qu’un petit changement. »

Pour le client, déplacer un bouton ou ajouter un champ semble anodin.

Pour le développeur, cette modification peut avoir des conséquences sur :

• la base de données ;
• les règles métier ;
• les droits utilisateurs ;
• les exports ;
• les statistiques ;
• les tests ;
• l’expérience utilisateur.

Une simple demande peut parfois nécessiter plusieurs heures, voire plusieurs jours de travail.

Un client change naturellement d’avis

Contrairement à une idée reçue, changer d’avis n’est pas un problème.

C’est même tout à fait normal.

Au fur et à mesure qu’il découvre l’application, le client visualise mieux son fonctionnement.

Il réalise alors que certains choix initiaux ne correspondent plus à ses besoins.

C’est une évolution naturelle.

Le problème apparaît uniquement lorsque ces changements ne sont pas encadrés.

Sans limites clairement définies, le projet devient une cible mouvante.

Quand le périmètre n’est pas défini, le projet ne se termine jamais

Un projet informatique possède normalement trois éléments essentiels :

• ce qui est inclus ;
• ce qui n’est pas inclus ;
• la procédure permettant d’ajouter de nouvelles fonctionnalités.

Sans ces règles, chaque réunion devient l’occasion d’ajouter de nouvelles idées.

Au bout de quelques mois, le développeur a l’impression que le projet n’avance plus.

Le client, de son côté, a le sentiment qu’il reste encore beaucoup de choses à faire.

Les deux parties sont persuadées d’avoir raison.

En réalité, elles travaillent simplement avec deux visions différentes du projet.

Le rôle du développeur n’est pas seulement de programmer

Un bon développeur ne se contente pas d’écrire du code.

Il aide également son client à structurer son besoin.

Il pose des questions.

Il remet certains choix en perspective.

Il identifie les cas particuliers.

Il anticipe les impacts futurs.

Cette phase peut parfois sembler longue, mais elle représente souvent plusieurs dizaines d’heures économisées pendant le développement.

Pourquoi les professionnels parlent de « cadrage »

Le cadrage consiste à transformer une idée en un projet concret.

Avant de développer, il faut définir notamment :

• les objectifs du projet ;
• les profils utilisateurs ;
• les fonctionnalités prioritaires ;
• les règles métier ;
• les scénarios d’utilisation ;
• les contraintes techniques ;
• les limites du périmètre ;
• les évolutions qui seront traitées ultérieurement.

Plus cette étape est précise, plus le développement devient rapide, prévisible et économique.

Les demandes de changement doivent toujours exister… mais être organisées

Un projet sur mesure n’est jamais figé.

Des améliorations seront toujours nécessaires.

La bonne méthode consiste simplement à distinguer :

• les corrections de bugs ;
• les ajustements mineurs ;
• les nouvelles fonctionnalités.

Les nouvelles demandes doivent faire l’objet d’une estimation, d’une validation et, si nécessaire, d’un nouveau devis ou d’une nouvelle phase du projet.

Ainsi, le développement reste maîtrisé et le client garde une parfaite visibilité sur les coûts et les délais.

Une relation gagnant-gagnant

Un bon cahier des charges ne protège pas uniquement le développeur.

Il protège aussi le client.

Le client sait exactement ce qu’il achète.

Le développeur sait précisément ce qu’il doit livrer.

Les délais deviennent réalistes.

Le budget reste maîtrisé.

La communication est beaucoup plus sereine.

Conclusion

L’expérience montre qu’un projet informatique échoue rarement à cause de la technologie.

Il échoue le plus souvent parce que son périmètre n’a jamais été clairement défini.

Prendre le temps de cadrer un projet n’est pas une perte de temps.

C’est un investissement.

Chez FDW48, chaque projet commence par une véritable phase d’analyse et de cadrage. Cette étape nous permet de comprendre les besoins réels du client, de définir un périmètre clair et de construire une solution évolutive sans entrer dans une succession infinie de modifications.

Parce qu’un projet sur mesure réussi n’est pas celui qui change tous les jours. C’est celui dont les objectifs sont clairement définis dès le départ, tout en laissant une place maîtrisée aux évolutions futures.