Prix d’une application métier web : comparer les devis

Définir la première version achetable

Décrivez le parcours qui doit fonctionner lors de la première mise en service : création d’un dossier, validation par un responsable, export vers la comptabilité, consultation par la direction. Classez les fonctions indispensables séparément des améliorations. Un écran de reporting souhaitable peut attendre ; une règle de calcul utilisée pour engager une commande ne peut pas rester implicite. Faites indiquer les profils, les volumes à tester et les interfaces incluses dans le périmètre.

Le nombre d’écrans ne mesure pas seul le travail. Un écran de saisie avec une seule règle peut être moins complexe qu’un formulaire comportant des dépendances entre remises, marges et droits de validation. Transmettez des exemples fictifs représentatifs. Faites inscrire les exclusions : reprise de documents, migration des comptes, formation de nouveaux arrivants ou adaptation ultérieure à un logiciel tiers.

Séparer investissement et dépenses récurrentes

Le développement initial n’est qu’un poste. La reprise des données comprend les extractions, les transformations et les contrôles. La recette mobilise aussi vos collaborateurs, même si leur temps n’apparaît pas dans la facture du prestataire. L’hébergement, les licences, la supervision, les sauvegardes et la maintenance constituent des dépenses distinctes. Demandez ce qui est inclus dans chaque contrat et ce qui déclenche une facturation complémentaire.

Comparez les montants sur une durée commune avec l’outil de coût total. Ne mélangez pas des montants hors taxes avec des montants toutes taxes comprises. Une proposition peut inclure les abonnements de la première année et les exclure ensuite : relevez cette différence avant de présenter le budget au dirigeant. Les économies attendues doivent provenir de mesures internes, pas d’un pourcentage annoncé sans démonstration.

Traiter les inconnues avant le forfait

Si personne ne connaît toutes les macros ou les tables actives, demandez un audit préalable avec un livrable précis. Le résultat doit permettre de chiffrer la construction, ou de conclure qu’une amélioration de l’outil actuel est préférable. Une provision pour une interface inconnue doit être visible et assortie d’une méthode de révision. L’absence d’information ne justifie pas une promesse de prix définitif.

Lors de la négociation, vérifiez les conditions de paiement liées aux livrables, la procédure de changement de périmètre et les critères de réception. Une correction d’anomalie convenue ne doit pas être confondue avec une nouvelle fonctionnalité. Faites décrire les modalités de sortie : remise des exports, accès au code selon les droits contractuels, documentation et assistance à un repreneur. Le devis doit rendre ces choix lisibles pour le DAF.

Exercice fictif pour préparer la recette

Prenez un devis de réalisation et demandez au candidat de rattacher chaque poste à un livrable. Une ligne de reprise doit indiquer les ensembles de données et les contrôles ; une ligne d’interface doit identifier le logiciel tiers et les opérations couvertes. Si une ligne reste intitulée « développement » sans précision, demandez ce qui déclenchera sa réception. L’exercice ne consiste pas à discuter un montant isolé, mais à vérifier ce que l’entreprise achète.

Préparez ensuite une demande de changement fictive : le métier veut ajouter une validation après le prototype. Faites expliquer comment cette demande est estimée, acceptée et intégrée au calendrier. Une réponse qui suppose tout changement inclus doit être clarifiée avec les limites du forfait. Une réponse qui facture toute correction doit distinguer défaut de livraison et nouvelle fonction.

Enfin, demandez la même décomposition à un autre candidat, en conservant les mêmes hypothèses de données et d’utilisateurs. Comparez les exclusions, la durée des abonnements et les responsabilités. Les propositions ne sont comparables qu’après cette mise à plat. Conservez les questions restées sans réponse dans le dossier d’achat et faites-les confirmer avant la décision.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• Coût des ressaisies Excel : mesurer avant de décider
• Maintenance et réversibilité : obtenir des livrables reprenables
• Hébergement de l’application métier : vérifier l’exploitation
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel