On commence souvent à chercher un prestataire pour le développement d'une application métier sur mesure quand les outils du marché couvrent chacun une partie du besoin, mais pas l'enchaînement réel du travail. Les écarts finissent alors par être comblés avec des tableurs, des ressaisies et des habitudes internes.
Avant de demander un devis, il vaut mieux avoir tranché quelques points en interne. Ces décisions ont un effet direct sur le périmètre du projet, et donc sur son budget.
Ce qu'on appelle une application métier
Une application métier ne se résume pas à un site ou à un tableau de bord. C'est un logiciel dans lequel une partie du travail de l'entreprise se fait réellement : des fiches qui représentent quelque chose de réel, des statuts par lesquels elles passent, des droits différents selon les rôles, un historique de qui a changé quoi, et des échanges avec les autres systèmes de l'entreprise.
C'est aussi la raison pour laquelle ce type de projet se juge sur la durée. Un site se refait ; une application métier se vit tous les jours, et ses défauts se paient en minutes perdues à chaque utilisation.
Sur mesure ou logiciel du marché
Le test le plus utile n'est pas la liste de fonctionnalités, c'est l'enchaînement. Si plusieurs logiciels couvrent chacun une partie du processus sans gérer correctement les passages de l'un à l'autre, vous pouvez vous retrouver à cumuler les abonnements, les ressaisies et les contournements manuels. C'est ce coût d'ensemble qu'il faut comparer au sur-mesure, pas seulement le prix des licences.
Le sur-mesure se justifie particulièrement quand une partie de votre façon de travailler constitue elle-même un avantage : une méthode de qualification, une règle de tarification, un contrôle qualité qui vous distingue. Faire développer sur mesure un besoin déjà bien couvert par des logiciels du marché est rarement rentable.
Où part le budget
- Le cadrage : comprendre le processus réel, exceptions comprises. C'est souvent l'un des premiers postes que l'on cherche à réduire. Pourtant, ce qui n'est pas compris à ce stade réapparaît généralement plus tard, sous forme de retours, de règles oubliées ou de changements de périmètre.
- Le modèle de données : ce qu'est une fiche, ses états, ce qui doit rester vrai en permanence. Une mauvaise décision à ce niveau se propage facilement dans le reste de l'application et devient coûteuse à corriger une fois les données et les règles métier construites autour.
- Les intégrations : chaque système à connecter peut devenir un lot à part entière. Il faut comprendre ses accès, les données qu'il expose, ses limites, et ce qui se passe lorsqu'un échange échoue.
- La reprise des données existantes, à chiffrer séparément, surtout lorsque l'historique a été saisi à la main pendant des années et contient des doublons ou des formats incohérents.
- La prise en main et la documentation, sans lesquelles l'outil devient la chose qu'une seule personne sait utiliser.
- La maintenance, à prévoir dès le départ : les API évoluent, les accès expirent ou sont renouvelés, et les besoins métier continuent de bouger.
Cinq points à trancher avant de consulter
- Qui utilise l'application, et avec quels droits. Des rôles et des droits clairement définis coûtent moins cher à concevoir qu'une notion floue d'« utilisateurs » qui se précise au fil du développement.
- Où sont hébergées les données et lesquelles sont des données personnelles. À décider avant la conception, pas après.
- À qui appartient le code, et sous quel compte vivent les dépôts et les accès de production.
- Faut-il réellement reprendre tout l'historique ? Reprendre plusieurs années de données n'a pas le même coût que migrer uniquement ce dont les équipes ont encore besoin au quotidien.
- Définissez ce qui doit fonctionner en premier. Une première tranche réellement utilisable en production permet de valider les choix avant d'élargir le périmètre.
Ce que nous avons construit
Le développement d'applications métier sur mesure est aujourd'hui au cœur de notre activité. Pour Mutualys, maison mère de Normandie Santé, le travail a abouti à un CRM interne et un chatbot WhatsApp, parce que la gestion des demandes vivait entre e-mails, notes téléphoniques et tableurs.
Pour Orange VOD, nous avons livré onze campagnes interactives entre 2012 et 2016 sur un socle commun plutôt qu'en repartant de zéro à chaque sortie, ce qui rendait tenable une fenêtre de livraison de deux semaines. La technologie de l'époque a vieilli, le principe non : c'est le même raisonnement que celui qui consiste à faire d'un processus répété une application configurable.