Développement d'application sur mesure : les 5 étapes incontournables

Un projet de développement d'application sur mesure réussi se reconnaît à une chose : l'application est utilisée en routine six mois après la mise en production. Cette définition est plus exigeante qu'elle n'y paraît. Sur les projets PME et ETI, une part non négligeable des applications livrées sont abandonnées dans les trois premiers mois, malgré un budget tenu et un périmètre livré. La cause n'est presque jamais technique : elle se trouve dans la mauvaise séquence des étapes en amont, qui produit une application qui marche mais ne sert pas. Les cinq étapes qui suivent décrivent une trajectoire qui maximise les chances que l'application soit utilisée en routine.

Étape 1 : le cadrage, l'étape la plus sous-investie

Le cadrage représente entre 10 et 15 % du budget total du projet, et conditionne 80 % de sa réussite. Cette asymétrie est mal comprise par la majorité des commanditaires, qui perçoivent le cadrage comme un coût d'entrée à minimiser pour entrer plus vite en développement. Le calcul est exactement inverse : un cadrage écourté produit des allers-retours en cours de développement dont le coût agrégé dépasse largement les économies de la phase initiale.

Le cadrage utile produit quatre livrables précis : une note de cadrage qui sert de référence partagée entre commanditaire, métier et prestataire, un modèle de données qui décrit les objets métier et leurs relations, un découpage en lots qui définit l'ordre des livraisons, et une architecture cible qui pose les choix structurants (stack technique, modes d'intégration, environnements). Sauter l'un de ces quatre livrables n'accélère pas le projet, le déplace : la même réflexion devra avoir lieu en cours de développement, à un coût supérieur, parce que des choix techniques auront déjà été pris sur de mauvaises bases.

« Les développeurs écrivent de moins en moins de lignes de code. En revanche, ces lignes doivent être guidées, construites grâce à une bonne conception en amont, par les règles métier, le modèle de données, l'architecture technique et business. »

Pour aller plus loin sur la méthode de cadrage en pratique, l'article sur la méthode de cadrage en trois ateliers décrit la mécanique appliquée sur les projets PME.

Étape 2 : la conception, où se prennent les décisions structurantes

La conception est l'étape pendant laquelle les choix structurants sont arbitrés et documentés. Modèle de données détaillé, parcours utilisateurs, design d'interface, règles métier formalisées : tout ce qui sera ensuite codé se décide ici. Une heure de conception correctement menée économise dix heures de développement et cent heures de correction post-livraison.

La règle de pilotage de cette étape est qu'une décision non documentée est une décision non prise. Sur les projets pilotés sans documentation, les choix structurants sont effectués implicitement par les développeurs en cours de codage, ce qui produit des incohérences qu'il faut ensuite rattraper par des refactorings coûteux. La documentation des décisions n'est pas un livrable cosmétique : c'est la seule manière de garder la cohérence d'ensemble quand plusieurs personnes travaillent sur le même projet en parallèle.

Cette étape inclut aussi la formalisation des règles métier implicites, qui est souvent le chantier le plus chronophage et le plus sous-évalué. Dans les PME et ETI qui ont grandi sur un métier technique, ces règles vivent dans la tête de 2 ou 3 personnes-clés. Les sortir, les écrire, les valider est un livrable à part entière, qui peut représenter plusieurs semaines de travail. Le sous-évaluer est ce qui explique la majorité des dérives de calendrier sur les projets de modernisation SI.

Étape 3 : le développement, qui suit le cadrage et la conception

Une fois les deux premières étapes correctement menées, le développement devient une étape d'exécution dont les choix structurants ont déjà été tranchés. Cette inversion est la clé : le développement n'est pas l'étape pendant laquelle on découvre le projet, c'est l'étape pendant laquelle on construit ce qui a déjà été conçu. Quand le cadrage et la conception ont été sous-investis, le développement devient une étape de découverte permanente, dont le coût explose.

Le bon découpage du développement est vertical, pas horizontal. Découpage vertical : on livre un parcours utilisateur complet sur un sous-ensemble de fonctionnalités, ce qui permet aux utilisateurs de s'en servir dès la première livraison. Découpage horizontal : on construit toutes les briques de l'application à moitié, ce qui ne donne rien d'utilisable avant la toute fin. Le découpage vertical produit du feedback exploitable au bout de quelques semaines. Le découpage horizontal ne produit du feedback qu'à la mise en production, c'est-à-dire trop tard.

Sur le cas Cartoon Prod, un premier POC fonctionnel a été développé en deux semaines, suffisamment opérationnel pour être mis en production. Ce n'était pas l'application complète, mais c'était un parcours complet sur un cas d'usage prioritaire. Le retour sur investissement constaté est arrivé en six à sept mois, parce que la valeur produite a démarré à la semaine 2 et non à la fin du projet.

Étape 4 : la recette et les tests utilisateurs

La recette est l'étape pendant laquelle l'application est testée par les utilisateurs cibles dans un environnement de recette identique à la production. Cette étape inclut trois sous-phases : la recette fonctionnelle (les parcours marchent comme prévu), la recette de performance (les temps de réponse tiennent sous charge réelle), et la recette utilisateur (les utilisateurs cibles s'en servent sans guidage).

La recette utilisateur est presque toujours celle qui révèle les écarts entre l'application conçue et l'application utilisable. Une fonctionnalité techniquement parfaite mais cachée dans un menu de troisième niveau est une fonctionnalité qui ne sera pas utilisée. Une terminologie maîtrisée par le commanditaire mais incompréhensible pour les utilisateurs quotidiens est une terminologie qui produira de la résistance au changement. Ces écarts ne se voient que pendant la recette utilisateur, et ne se corrigent qu'à ce moment-là.

Le piège classique consiste à comprimer cette étape pour rattraper un retard accumulé en développement. Ce calcul est faux : une mise en production faite avec une recette insuffisante produit une chute d'usage qui peut être définitive. Mieux vaut décaler la mise en production de deux semaines que de livrer un produit qui sera abandonné par les utilisateurs après deux jours d'usage.

Étape 5 : la mise en production et la stabilisation

La mise en production n'est pas la fin du projet, c'est le début de la vie utile de l'application. Cette distinction conceptuelle a une conséquence opérationnelle : la phase de stabilisation post-mise en production fait partie du projet, avec budget alloué et ressources dédiées. Cette phase dure entre 4 et 8 semaines selon la complexité de l'application, et couvre trois sujets : la correction des bugs détectés en usage réel, l'ajustement des parcours en fonction du comportement observé des utilisateurs, et la montée en charge progressive si l'application doit servir un nombre d'utilisateurs important.

Couper cette phase pour réduire le budget est l'erreur la plus coûteuse du projet. Une application livrée sans phase de stabilisation produit une chute d'usage dans les trois premières semaines, qui devient ensuite très difficile à rattraper. Les utilisateurs qui ont essayé une fois et qui ont rencontré un bug bloquant ne reviennent pas spontanément. Le coût de la phase de stabilisation est dérisoire comparé au coût d'une relance d'adoption six mois après la livraison.

Ce qui distingue un projet sur mesure réussi d'un projet sur mesure raté

À l'arrivée, la différence entre un projet sur mesure qui produit de la valeur et un projet qui termine sans atterrir tient à un nombre limité de variables. La première est la proportion budgétaire accordée au cadrage. La seconde est la documentation des décisions structurantes pendant la conception. La troisième est le découpage vertical du développement. La quatrième est le sérieux de la recette utilisateur. La cinquième est l'inclusion explicite de la phase de stabilisation dans le projet.

Aucune de ces variables n'est technique. Toutes relèvent de la posture du commanditaire et du prestataire face au temps. Un projet sur mesure n'est pas une commande qu'on passe et qu'on récupère terminée : c'est une construction collective dans laquelle le commanditaire reste impliqué de bout en bout. Pour aller plus loin sur le coût réel de cette implication et sur ce qui détermine vraiment le devis, l'analyse détaillée du prix d'un logiciel sur mesure PME décompose les facteurs structurants. Et pour comparer cette approche aux alternatives, la comparaison entre sur mesure et SaaS selon le stade de l'entreprise donne une grille de décision réutilisable.

La semaine prochaine, prenez un projet d'application sur mesure que vous avez livré ou que vous êtes en train de piloter, et vérifiez sur chacune des cinq étapes si elle a été menée avec le budget et le temps qu'elle méritait. Cette relecture vous donnera en moins d'une heure une lecture claire des étapes que vous avez tendance à sous-investir, et donc des dérives prévisibles sur vos prochains projets. Cette grille vaut autant pour un projet en cours, sur lequel il est encore temps d'ajuster, que pour un projet à venir, sur lequel elle change la manière dont vous calibrez le brief et le devis.