Développer une application métier sur-mesure

Le coût de reprise d’un défaut logiciel a été relevé étape par étape dans un rapport commandé par le NIST, et il change d’ordre de grandeur entre le stade des exigences et la mise en exploitation. Une décision prise trop tard, ou prise par quelqu’un qui n’avait pas l’information pour la prendre, ne se paie donc pas au même tarif selon le moment où elle tombe. Développer une application métier sur-mesure revient à placer chaque décision là où elle coûte encore peu, et à savoir laquelle vous revient plutôt qu’à votre prestataire. Cet article suit ces décisions dans l’ordre où elles se présentent, du premier atelier de cadrage à la recette du premier lot, avec pour chacune le moment où elle se prend et ce qu’il en coûte de la repousser.

Le moment d’une décision et la personne qui la prend

Ce qu’une décision vous coûtera dépend de l’étape à laquelle vous la prenez, et du fait qu’elle ait ou non un propriétaire désigné dans votre entreprise. Le premier point a été mesuré et publié. Le second se règle avant le premier atelier.

Ce que montrent les mesures de reprise

Le rapport commandé par le NIST sur l’économie des tests logiciels reproduit deux séries de mesures du coût de reprise d’un défaut selon l’étape à laquelle il est trouvé. Dans la série tirée d’une étude de Boehm publiée en 1976, la réparation vaut 0,2 au stade des exigences, 0,5 à la conception, 1,2 au codage, 5 au test système et 15 au test d’installation. Dans la série tirée d’une étude de Baziuk publiée en 1995, le même défaut vaut 1 au stade des exigences, 90 au test système, 440 au test d’acceptation, et de 470 à 880 en exploitation et maintenance.

Ces séries emploient des unités relatives distinctes et ne se comparent pas l’une à l’autre. Le rapport précise par ailleurs que la valeur au stade des exigences est, dans les deux séries, une hypothèse d’équivalence posée par ses auteurs et non une mesure de l’étude d’origine. Elles montrent l’une comme l’autre dans quel sens l’écart se creuse à mesure qu’un cycle avance.

Le même rapport présente, pour un panel de développeurs interrogés dans la fabrication de matériel de transport, la répartition des défauts selon leur point d’introduction et leur point de détection. Dans ce panel, 15,6 % des défauts sont introduits au stade des exigences, et le tableau détaille où ils réapparaissent : 5 % du total au stade des exigences lui-même, 8 % au codage ou aux tests unitaires, 2,3 % à l’intégration, 0,2 % en bêta et 0,2 % après la mise en production. Pour votre projet, la lecture utile est celle de cette ligne : un besoin mal formulé au cadrage ressort à toutes les étapes suivantes, jusqu’après la mise en production.

Les décisions que personne ne peut prendre à votre place

Trois décisions restent chez vous du premier jour au dernier, quelle que soit l’agence en face. Le périmètre, ce que l’application couvre et ce qu’elle laisse dehors. Les règles que vous appliquez réellement, y compris celles que personne n’a écrites. Et le nom de la personne qui tranche quand deux services demandent l’inverse l’un de l’autre.

La troisième est la plus facile à repousser. Un projet sans arbitre désigné fait remonter chaque désaccord au dirigeant, qui tranche sans avoir le détail sous les yeux, ou qui repousse. Le désaccord ressort alors à la recette, une fois le lot développé, à un stade où le corriger n’a plus rien à voir avec ce qu’il aurait coûté au cadrage. Désigner cette personne se fait par écrit et avant le premier atelier : qui a le dernier mot sur le périmètre, et qui l’a sur les règles.

Faire sortir au cadrage les règles que personne n’a écrites

L’atelier de cadrage n’est pas une prise de commande. Il sert à extraire de votre organisation ce qu’elle sait faire sans l’avoir écrit, et ce travail décide de la suite : le développement transformera ces règles en code, il ne les inventera pas.

Les exceptions portent les vraies règles

Le processus nominal se décrit vite, et tout le monde le connaît. Les exceptions occupent le reste de l’atelier. Un dossier qu’une personne rouvre après clôture parce que le client rappelle. Une pièce que l’équipe accepte en photo alors que la procédure demande l’original. Un cas traité entièrement hors outil parce qu’il n’entre dans aucune des cases prévues.

Ces exceptions forment la règle métier réelle, celle qui décide de ce qui se passe dans la vraie vie de vos équipes. Une application qui les ignore se fera contourner, par un fichier tenu à côté, exactement comme le tableur qu’elle remplaçait.

Elles se collectent sur pièces plutôt que sur déclaration. Asseyez-vous avec ceux qui font le travail, rouvrez des dossiers récents et suivez ce qu’ils en ont fait, en particulier ceux qui sont sortis du chemin prévu. Vous obtenez le périmètre fonctionnel réel, et la liste des cas qui servira à vérifier la livraison.

Le cadrage relève également ce que l’outil devra échanger avec vos autres logiciels. Ces échanges se décident maintenant parce qu’ils dépendent de ce que chaque logiciel accepte de donner, sujet traité pour lui-même du côté de la circulation des données entre logiciels d’une même entreprise.

Les données personnelles se décident au cadrage

Si l’application traite des données concernant des personnes, salariés, clients, patients ou candidats, l’article 25 du règlement européen sur la protection des données impose au responsable du traitement des mesures techniques et organisationnelles appropriées, et il situe cette obligation tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même. Son second paragraphe ajoute que, par défaut, seules les données nécessaires à chaque finalité sont traitées, ce qui porte sur la quantité collectée, l’étendue du traitement, la durée de conservation et l’accessibilité.

L’obligation vous revient, puisque le responsable du traitement est, à l’article 4 du même règlement, celui qui détermine les finalités et les moyens du traitement, donc votre entreprise dès lors que c’est elle qui décide de ce que l’outil traitera et pourquoi. Et elle tombe au moment où se décident les moyens, c’est-à-dire pendant le cadrage. La protection des données dès la conception se traduit alors en décisions concrètes : les durées de conservation par type de donnée, les champs que vous renoncez à stocker, et les profils qui voient quoi. Posées au cadrage, elles tiennent en une phrase de spécification. Posées après la mise en service, elles demandent une reprise de la base et des écrans.

La propriété du code se décide aussi au cadrage

Le code que le prestataire écrit pour vous ne vous appartient pas par défaut. La cession des droits sur le code, sur la base de données et sur la documentation se négocie et se signe avant le début du développement, pas à la toute fin du projet.

Cette cession décide aussi ce qui se passe si vous voulez changer de prestataire. Demandez l’accès au code source, à son historique de versions et à la documentation technique dès la livraison de chaque lot, plutôt qu’à la seule clôture du projet. Sans cet accès, une application qui fonctionne reste entre les mains de l’agence qui l’a écrite, et vous dépendez d’elle pour la moindre évolution.

Ce que vous cherchez à faire échouer sur le prototype

La maquette cliquable reproduit les écrans principaux et leur enchaînement sans rien développer derrière. Vous y cliquez, vous y naviguez, et les champs y occupent déjà leur place définitive. Ce qui se décide à cette étape, c’est ce que vous allez lui faire subir : une revue qui se termine par un accord général n’a rien produit.

Le groupe qui la manipule reste étroit, et vous le composez sur ce que chacun voit du travail. Celui qui traite le plus gros volume connaît le geste courant et repère ce qui coince quand il faut le refaire d’affilée. Celle qui hérite habituellement des dossiers compliqués est votre meilleur utilisateur pilote, parce qu’elle connaît les exceptions par cœur et qu’elle ira les chercher dans la maquette.

Donnez à chaque testeur un dossier réel de la semaine à dérouler à l’écran, en choisissant un dossier qui porte au moins une des exceptions relevées au cadrage, et regardez-le faire sans l’aider. C’est le seul moyen de savoir si la maquette couvre autre chose que le chemin nominal.

Notez trois choses pendant qu’il avance. Les endroits où il s’arrête pour demander quoi faire, qui signalent un enchaînement d’écrans qui ne correspond pas au travail. Les informations qu’il cherche et qui ne sont pas affichées, qui signalent un champ manquant ou mal placé. Les gestes qu’il répète, qui signalent une saisie à automatiser ou une valeur à pré-remplir, et qu’un écran mal ordonné rendra pénibles à mesure qu’ils reviennent.

Ces relevés se transforment directement en corrections d’écran, et ils alimentent ensuite les cas que vous ferez vérifier à la livraison.

Ce qui entre dans le premier lot et selon quelle méthode

Un développement sur-mesure avance par ensembles livrables. Le contenu du premier et la manière dont les suivants s’enchaînent ne se décident pas ensemble.

Le critère qui rend un premier lot autonome

Un critère mécanique suffit à trancher : le premier lot doit pouvoir entrer en service seul. Si sa mise en service attend un deuxième lot, ce n’est pas un lot, c’est une moitié, et vous portez le coût du projet sans en tirer le moindre gain avant la fin.

Ce critère écarte des candidats qui paraissent évidents. Un écran de statistiques se développe vite et ne sert à rien tant que les données ne sont pas saisies ailleurs. Une reprise d’historique est autonome techniquement et ne change rien au travail de la semaine tant qu’aucun écran ne s’appuie dessus. Parmi les candidats qui restent, l’ordre se décide sur ce que le processus vous coûte aujourd’hui en heures, pas sur ce qu’il coûterait à développer.

Repérer le processus qui remplit ce critère revient souvent à repérer le fichier qui le fait déjà tourner, et la méthode se déroule sur la page qui montre comment distinguer le classeur de calcul de celui qui porte un processus. Quand le processus retenu fait vivre un dossier de son ouverture à sa clôture, votre premier lot dessine une application construite autour du suivi de dossiers.

Cycle en V ou développement par itérations

Deux méthodes structurent un développement sur-mesure. Dans un cycle en V, le prestataire fige les besoins dans un document, développe l’ensemble, puis vous remet le résultat à valider à la fin. Dans un développement par itérations, il découpe le même périmètre en lots et vous fait valider à la fin de chacun.

Ce que ce choix déplace, c’est la date de votre première vérification, et donc l’étape à laquelle vos écarts se paient. Le cycle en V la place à la fin : ce qui a été mal compris au départ se découvre à la recette, et se répare au tarif de la recette. Le développement par itérations la place à la fin du premier lot, sur un périmètre plus étroit et un écart plus court à rattraper.

Le cycle en V garde un domaine propre. Quand le contenu de l’application est déjà écrit ailleurs, dans un texte réglementaire par exemple, votre première vérification ne vous apprendra rien que le document ne disait déjà, et la placer à la fin ne vous coûte rien. Le cas coûteux est de le choisir en croyant être dans cette situation, alors que vos règles sortent encore d’ateliers.

Posez la même question aux deux offres que vous avez sur la table : si mes équipes constatent dans trois mois que l’écran ne correspond pas à leur travail, qu’est-ce qui se passe, et qui le paie ? Une offre sans réponse claire sur ce point vous fera payer ce décalage plus tard.

Ce que vous vérifiez avant d’accepter un lot

La recette est l’étape où vous déclarez qu’un lot fait ce qu’il devait faire. Tout ce que vous n’y vérifiez pas passe en production avec le lot.

Un cas de recette décrit une situation réelle, ce que la personne fait à l’écran, et le résultat attendu, refus compris. Un devis au-delà d’un certain montant doit demander une validation, et le cas de recette vérifie que l’outil bloque le devis tant que cette validation manque. Constater qu’il sait enregistrer un devis ne dit rien de cette règle.

Ces cas s’écrivent pendant le développement, jamais à la livraison. Écrits après avoir vu le logiciel, ils décrivent ce que le logiciel fait, et ils ne vérifient plus rien. Vous les avez déjà en grande partie : reprenez les dossiers réels déroulés sur la maquette, ajoutez les exceptions relevées au cadrage, et vous obtenez une liste que vos utilisateurs pilotes peuvent parcourir sans vous.

Reste à décider ce qui bloque une mise en service et ce qui attend, et à le décider avant de commencer. Trois niveaux suffisent : ce qui empêche de faire le travail, ce qui oblige à un contournement connu mais laisse le travail possible, et ce qui gêne le confort.

Sans ce classement, la discussion glisse vers l’un de deux réflexes. Ou bien tout devient bloquant et la mise en production recule sans fin, chaque nouvelle anomalie remettant la date en cause. Ou bien rien ne l’est, l’outil part en service avec ses défauts, et vos équipes retournent à leurs fichiers. Le classement se décide avec le prestataire avant la livraison du premier lot, quand personne n’a encore d’intérêt dans la réponse.

Ce que le projet consomme chez vous

Le temps que ce projet prend dans votre entreprise se concentre sur un poste qui ne se planifie pas : le délai avec lequel vous répondez aux questions du prestataire. Les ateliers, les revues et l’accès aux données existantes se posent dans un calendrier, et vous les voyez venir. Les questions, elles, arrivent au fil du développement et sans prévenir.

Une question qui attend coûte davantage que le temps qu’elle a attendu : il faut y ajouter le temps qu’il faut à l’équipe pour se remettre dans le sujet, et l’hypothèse qu’elle a souvent prise par défaut pour ne pas rester à l’arrêt, hypothèse que vous découvrirez à la recette.

Nommez un interlocuteur unique qui centralise les questions et sait à qui les adresser en interne, plutôt que de laisser le prestataire chercher la bonne personne service par service. Et fixez un rythme de point fixe, court et régulier, qui donne aux questions un endroit où tomber sans dépendre de la disponibilité de chacun.

L’après se prévoit au même titre. Les premières semaines de service produisent des demandes que l’usage réel révèle et qu’aucun atelier n’aurait fait sortir. Décidez avant la mise en service qui les reçoit chez vous et sur quel critère l’une passe devant l’autre, sinon c’est la dernière arrivée qui passe. La charge de développement, elle, se compte en jours et se lit à part, avec les postes qui pèsent le plus lourd au chiffrage, détaillés dans l’anatomie du budget d’une application de gestion.

Ce qui se prépare avant le premier rendez-vous

Une agence qui ouvre votre dossier sans ce matériel passe le premier rendez-vous à le reconstituer avec vous. Vous pouvez le réunir avant : la liste des exceptions de votre processus, le nom de la personne qui tranche, les personnes qui dérouleront un dossier réel sur la maquette, et le processus dont la facture en heures est la plus lourde. Les trois premiers sortent d’une matinée passée avec les équipes concernées. Le quatrième se lit dans ce que vos plannings et vos tableurs contiennent déjà.

C’est de là que part le travail décrit sur notre page de développement d’applications de gestion ouvertes dans le navigateur, avec vos règles, vos validations et vos droits par profil.

Reste la décision qui précède celle-ci : votre besoin justifie-t-il un développement, ou un produit d’éditeur correctement paramétré y répond-il déjà ? Elle se tranche sur des critères que la comparaison entre acheter une licence et faire écrire son outil pose un par un, et elle se prend avant le cadrage, pas pendant.

Sources

The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, RTI pour le National Institute of Standards and Technology, mai 2002, tableau 1-5 page 1-13 et tableau 6-2 page 6-10, https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf

Règlement européen sur la protection des données, article 25, Protection des données dès la conception et protection des données par défaut, chapitre IV, CNIL, consulté le 8 septembre 2026, https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4

Règlement européen sur la protection des données, article 4, Définitions, chapitre I, CNIL, consulté le 8 septembre 2026, https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre1