Prix d’un logiciel métier sur mesure : comment construire un budget vérifiable ?

Partir du processus à fiabiliser, pas d’une liste d’écrans

Décrivez le travail réel depuis son déclencheur jusqu’au résultat attendu. Pour chaque étape, notez qui agit, quelle donnée entre, quelle règle s’applique, quelles exceptions surviennent et quelle preuve confirme la fin. Un écran de planning peut cacher des droits complexes, des conflits, des notifications et un historique. À l’inverse, plusieurs vues peuvent réutiliser la même donnée et coûter moins qu’une intégration invisible mais critique.

Choisissez un parcours prioritaire que la première version doit terminer sans ressaisie dangereuse. Le reste devient une option datée, avec dépendances et condition de déclenchement. Cette frontière empêche de chiffrer un produit idéal sans fin. Elle permet aussi au prestataire de signaler ce qui relève du paramétrage, d’un développement spécifique ou d’une décision métier encore absente.

Mesurez le point de départ avant de parler de rendement : temps consacré, erreurs, retards, volumes et contournements observés. Cette situation initiale ne promet pas le gain futur. Elle permet de vérifier si le logiciel traite la cause annoncée, de choisir les indicateurs à suivre après livraison et d’éviter de financer l’automatisation d’un processus dont les responsabilités restent indécises.

Conservez ces mesures avec leur source, leur période et leurs limites afin que la comparaison future reste honnête.

Décomposer le devis en huit lots observables

Séparez cadrage, conception, développement, intégrations, reprise de données, sécurité, recette, puis mise en service. Chaque lot doit produire une sortie contrôlable : cartographie validée, prototype, fonctionnalité testée, rapport d’import, matrice de droits, procès-verbal ou procédure de retour arrière. Une ligne « développement complet » masque les hypothèses et rend les écarts impossibles à discuter.

Ajoutez pour chaque lot le responsable client, le responsable prestataire, les entrées attendues, les exclusions et le nombre de cycles de correction. Une dépendance non fournie à temps doit être visible. Le budget devient alors la conséquence d’un travail décrit, pas une estimation opaque. Deux propositions peuvent être comparées parce qu’elles répondent au même tableau.

• Cadrage et critères d’acceptation
• Conception des parcours et états
• Développement et automatisations
• Connexions, reprise et qualité des données
• Sécurité, habilitations et journalisation
• Recette, déploiement, exploitation et sortie

Chiffrer les données, les intégrations et les exceptions

Inventoriez les sources : tableurs, base existante, logiciel comptable, messagerie, annuaire ou API. Pour chacune, demandez propriétaire, format, volume, qualité, fréquence, authentification et comportement en cas d’erreur. Une intégration n’est pas « incluse » tant que sa documentation, ses limites et un environnement de test ne sont pas disponibles.

Échantillonnez les données avant de promettre une reprise. Les doublons, champs libres, identifiants manquants et historiques incohérents créent du travail de décision, pas seulement d’import. Faites chiffrer séparément nettoyage, transformation, rapprochement, test et validation. Préservez un journal permettant de comprendre ce qui a été repris, rejeté ou corrigé.

Intégrer sécurité et sous-traitance au périmètre initial

Si l’outil traite des données personnelles, le contrat doit préciser finalités, responsabilités, confidentialité, restitution, incidents et mesures de sécurité. La CNIL recommande d’évaluer les garanties du sous-traitant et de connaître les mesures réellement mises en œuvre. Remplacez « conforme RGPD » par des exigences vérifiables : habilitations, authentification, chiffrement, sauvegardes, journaux et procédure d’incident adaptées au risque.

Prévoyez les environnements de développement et de recette sans copier par défaut des données réelles. La CNIL rappelle que les données hors production augmentent les risques si les accès et stockages se multiplient. Faites documenter les jeux de test, la suppression, les comptes administrateurs et les sous-traitants ultérieurs. Ces choix ont un coût légitime qui doit apparaître avant la livraison.

Calculer exploitation, maintenance et réversibilité

Le coût initial ne couvre pas automatiquement hébergement, surveillance, sauvegardes, support, mises à jour de dépendances, certificats, services tiers et évolutions. Construisez un coût total sur une durée choisie par l’entreprise. Identifiez ce qui est certain, variable ou conditionnel. Une licence liée au volume reçoit une formule ; un besoin inconnu reçoit une plage d’hypothèses, jamais un zéro rassurant.

Simulez aussi la sortie : export des données, documentation, code et licences, secrets, domaine, procédure de transfert et délai d’assistance. La réversibilité n’impose pas une technologie particulière ; elle rend la dépendance compréhensible. Un logiciel durable doit pouvoir être maintenu, audité et quitté selon des conditions écrites.

Définissez les niveaux de service réellement utiles : canal, horaires, niveaux de gravité, prise en charge, sauvegarde, test de restauration et escalade. Une indisponibilité qui arrête la production ne se traite pas comme un défaut d’affichage dans un outil consulté occasionnellement. Le budget du support doit suivre ce risque documenté, avec une responsabilité et une preuve pour chaque engagement.

Outil 1 — transformer le besoin en unités à chiffrer

Créez une ligne par parcours. Colonnes : déclencheur, utilisateurs, données, règle, exception, résultat, fréquence, risque, intégration et preuve d’acceptation. Marquez ensuite chaque ligne « première version », « option » ou « hors périmètre ». Le prestataire estime la charge uniquement sur les lignes assez précises ; les autres passent dans un atelier de cadrage.

Le résultat de l’outil n’est pas un prix automatique. Il produit un dossier identique à envoyer aux prestataires et une liste des inconnues qui empêchent encore un engagement. Refusez toute estimation présentée comme ferme si les données, API ou règles critiques n’ont pas été examinées.

• Une ligne correspond à un résultat métier terminé
• Une exception critique reste visible
• Une hypothèse possède un propriétaire
• Une option n’est pas incluse silencieusement
• Chaque lot possède une preuve de recette

Scénario fictif : appliquer la formule de coût complet

Entrées fictives : une PME veut remplacer trois tableurs utilisés par douze personnes. Le premier parcours couvre création d’un dossier, validation par deux rôles, génération d’un document et export comptable. Les données comportent des doublons et l’API comptable doit être vérifiée. Le raisonnement sépare cadrage, prototype, nettoyage, connexion, droits, tests et accompagnement.

La formule demandée aux prestataires est : coût initial = cadrage + conception + développement + intégrations + reprise de données + sécurité et recette + déploiement + provision des risques identifiés. Le coût total sur l’horizon choisi ajoute l’hébergement, le support, les licences, la maintenance, les évolutions prévues et la réversibilité. Chaque terme doit renvoyer vers une quantité, un prix unitaire, une hypothèse ou une option, jamais vers une ligne globale inexpliquée.

Exemple purement pédagogique, qui n’est ni un prix de marché ni une offre Clic Monsieur : un devis fictif répartit 4 800 € de cadrage, 7 200 € de conception, 36 000 € de développement, 8 000 € d’intégrations, 4 000 € de reprise, 6 000 € de sécurité et recette, 3 000 € de déploiement, puis 6 900 € de risques documentés. Le socle atteint 75 900 €. Avec 900 € par mois d’exploitation et 6 000 € d’évolutions par an, le coût total illustratif à trois ans atteint 126 300 €. Le calcul est vérifiable ; ses montants ne sont pas transposables à un autre projet.

Résultat : le devis demandé comporte un socle ferme après cadrage, une option pour l’API si le test aboutit et un coût d’exploitation annuel documenté. Limites : seuls l’audit des données, la documentation technique, les taux réels et les devis reçus permettent de chiffrer votre projet. Le scénario montre comment contrôler une addition, pas comment prédire votre budget.

Comparer les offres avec des critères éliminatoires

Écartez d’abord une proposition qui ne définit pas le périmètre, les droits d’accès, la sécurité, la recette, la propriété des comptes ou la restitution des données. Comparez ensuite méthode, qualité des preuves, continuité, coût total et capacité à expliquer les risques. Une moyenne ne doit pas sauver une offre qui échoue sur une exigence critique.

Demandez une démonstration du processus de livraison : comment une anomalie est enregistrée, priorisée, corrigée puis retestée ? Qui autorise la mise en production ? Que se passe-t-il en cas d’échec ? La décision finale doit relier le prix à des obligations observables, sans garantie de gain de productivité avant mesure réelle.