Il n’existe pas de prix fiable pour une application métier sans connaître ses parcours, ses données et ses conditions d’exploitation. Deux projets avec le même nombre d’écrans peuvent demander des efforts très différents. Pour obtenir un budget exploitable, il faut décrire ce qui doit fonctionner, ce qui doit être repris et ce qui devra être maintenu.

Les repères pour décider.

  • Le nombre d’écrans ne suffit pas à estimer le travail.
  • Séparer construction, transition et fonctionnement après lancement.
  • Comparer les devis avec les mêmes exclusions et critères de réception.

Les règles métier comptent autant que les écrans.

Un écran de dossier peut sembler simple. Il devient plus exigeant lorsque chaque rôle voit des champs différents, qu’une validation dépend du montant et qu’une correction doit conserver l’historique. L’effort dépend des comportements à construire et à tester, y compris lorsque les données sont incomplètes.

Décrivez chaque parcours par un scénario observable : qui agit, avec quelles données, à quel moment, et quel résultat doit être obtenu. Ajoutez un cas d’erreur et un cas d’exception. Cela donne une base de discussion plus précise qu’un intitulé comme « gestion des dossiers » et réduit les interprétations entre prestataires.

Six postes à faire apparaître dans l’estimation.

Cette grille permet de repérer les sujets absents d’un devis. Elle ne donne pas un tarif : chaque poste doit être estimé à partir de votre périmètre et des accès réellement disponibles.

Postes de budget d’une application métier sur mesure

Faites défiler le tableau horizontalement pour lire toutes les colonnes.

Postes de budget d’une application métier sur mesure
PosteQuestions à résoudre avant de chiffrer
Cadrage et conceptionQuels parcours, utilisateurs, règles et prototypes doivent être validés ?
Développement et testsQuels rôles, validations, exceptions et volumes faut-il couvrir ?
IntégrationsLes API sont-elles documentées, accessibles et testables ?
MigrationQuelles données, pièces jointes et relations doivent être nettoyées puis reprises ?
LancementQuels environnements, formations et contrôles de bascule sont nécessaires ?
ExploitationQui assure hébergement, supervision, sauvegardes, corrections et évolutions ?

Ne pas découvrir la reprise des données en fin de projet.

Les informations existantes sont rarement prêtes à être importées sans examen. Une même entreprise peut avoir plusieurs identifiants, une date peut être enregistrée comme du texte et une pièce jointe peut n’exister que dans une boîte email. La reprise demande une cartographie, des règles de transformation et une validation métier.

Fournissez un échantillon représentatif avant l’estimation, en retirant les informations personnelles inutiles à cette étape. Décrivez les volumes, les doublons connus, l’historique à conserver et le moment où les données cesseront d’être modifiées dans l’ancien outil. Une migration testée peut révéler un travail que le seul schéma des écrans ne montre pas.

Découper une première version utilisable.

Réduire le périmètre ne consiste pas seulement à retirer des écrans. Une première version doit permettre de terminer une opération réelle. Par exemple, pour une gestion d’interventions, créer une demande sans pouvoir l’affecter ni suivre son état laisse un processus incomplet. Ce scénario illustratif doit être adapté à votre métier.

Classez les besoins en trois groupes : indispensables au premier parcours, utiles après observation et hors périmètre. Expliquez les tâches qui resteront manuelles durant la transition. Le découpage rend les arbitrages visibles et permet de discuter du budget sans masquer une partie du travail nécessaire.

  • Un parcours complet avec les rôles indispensables.
  • Les intégrations nécessaires à ce parcours.
  • La visibilité sur les erreurs et les actions à reprendre.
  • Les conditions de déploiement et de récupération des données.

Comparer deux devis sans comparer deux produits différents.

Un devis plus court peut exclure les tests de migration, l’administration, l’environnement de recette ou la documentation d’exploitation. Demandez un découpage des livrables, des hypothèses et des exclusions. Lorsque l’incertitude est importante, une phase de cadrage distincte peut être plus utile qu’un engagement détaillé fondé sur des informations incomplètes.

Vérifiez aussi ce qui déclenche la réception : scénarios testés, anomalies admises, données reprises et accès remis. Clarifiez les modalités de correction, de maintenance et d’évolution. Les conditions de propriété intellectuelle et de réversibilité se définissent dans le contrat ; elles doivent être comprises avant de choisir le prestataire.

Mesurer l’intérêt du projet avant de parler de rentabilité.

Observez la situation de départ : opérations réalisées, délais entre étapes, erreurs corrigées et interventions manuelles. Notez les volumes et la période de mesure. Ces observations permettent de relier le projet à une amélioration attendue, sans inventer un pourcentage de gain.

Après lancement, comparez le même processus dans des conditions explicites. Une hausse de volume ou un changement d’équipe peut modifier le résultat. Un budget défendable relie les dépenses, le périmètre et des critères vérifiables ; il ne repose pas sur une promesse de retour universel. Pour démarrer, apportez un parcours, vos outils et un échantillon de données : nous pourrons préciser les inconnues et la prochaine étape.