Combien coûte une application sur mesure

Pourquoi personne ne vous répond au téléphone

Vous appelez, vous décrivez votre besoin en trois phrases, vous demandez un ordre de grandeur — et on vous propose une rencontre. C'est agaçant, et c'est pourtant en partie légitime.

Un chiffre annoncé sans avoir vu le besoin est faux dans les deux sens. Trop bas, et le fournisseur devra se rattraper en cours de route, par des avenants ou en rognant sur les essais — c'est l'histoire de la plupart des projets qui tournent mal. Trop haut par prudence, et il vous fait renoncer à un projet qui était parfaitement viable.

Ce qui est légitime, c'est de refuser un montant ferme sans avoir regardé. Ce qui ne l'est pas, c'est de refuser un ordre de grandeur après une vraie conversation. Quelqu'un qui a fait le métier sait, au bout d'une heure, si vous êtes devant un outil de quelques semaines ou devant un chantier de deux ans. S'il ne veut rien dire du tout, ce n'est plus de la prudence.

Ce qui fait vraiment le prix

L'intuition dit : le nombre d'écrans. C'est le facteur le moins déterminant. Deux applications de vingt écrans peuvent différer d'un facteur cinq. Voici ce qui pèse, dans l'ordre.

• La densité des règles métier. Un écran qui enregistre un nom et une adresse, ou un écran qui applique un barème réglementaire, vérifie huit conditions et déclenche trois calculs : même surface à l'écran, effort sans commune mesure.
• Le nombre d'intégrations. Chaque système avec lequel l'application doit dialoguer — comptabilité, paie, boutique en ligne, appareil de mesure — ajoute son lot de formats, de pannes à gérer et d'essais. C'est le poste qui déraille le plus souvent.
• La reprise des données existantes. Rarement propre, jamais rapide. Les doublons, les champs détournés de leur usage, les dates au mauvais format et les codes que plus personne n'explique se découvrent au moment de la reprise, pas avant.
• Le nombre de profils d'utilisateurs. Un système où tout le monde voit tout coûte bien moins cher que le même système avec cinq rôles, des permissions fines et une piste de vérification.
• Les exigences réglementaires. Renseignements personnels, conservation, traçabilité, accessibilité. Ce sont des contraintes réelles qui se chiffrent, et qu'il vaut mieux nommer au départ qu'ajouter en cours de route.
• Le niveau de finition attendu. Un outil interne pour dix personnes formées n'exige pas le soin d'une application que vos clients utiliseront sans aide. L'écart est considérable, et il est légitime dans les deux sens.

Ce qu'on sous-estime presque toujours

Quand un projet dépasse son budget, c'est rarement parce que le développement des écrans a coûté plus cher que prévu. C'est parce que des postes entiers n'avaient pas été chiffrés.

• L'intégration et la reprise de données. Sur un système d'entreprise, ces deux postes pèsent souvent autant que le développement lui-même. Une soumission qui les passe sous silence n'est pas moins chère : elle est incomplète.
• Les essais sur données réelles. Vérifier qu'un système donne les bons chiffres sur vos propres données prend du temps — et c'est précisément ce temps qui évite les mauvaises surprises en production.
• La formation et l'accompagnement. Un système que personne ne sait utiliser n'a rien coûté : il a été perdu.
• La vie après la mise en ligne. C'est la ligne la plus souvent absente des budgets. Un système vit des années : hébergement, correctifs, montées de version, évolutions, conformité. Prévoyez une enveloppe annuelle récurrente dès le départ plutôt que de la découvrir la deuxième année.

Trois façons de payer, trois répartitions du risque

Le mode de facturation n'est pas un détail administratif : il décide qui porte le risque quand la réalité s'écarte du plan.

Le forfait convient quand le besoin est stable et bien décrit. Le risque de dépassement passe au fournisseur — qui le facture dans sa marge, c'est normal. Son défaut : tout changement devient une négociation, et le fournisseur a intérêt à livrer le strict minimum décrit.

La régie — vous payez le temps réellement passé — convient quand le besoin va évoluer en chemin, ce qui est fréquent. Elle est honnête et souple, mais vous portez le risque, et elle exige une confiance que vous n'avez pas encore au premier mandat.

La voie mixte combine les deux, et c'est celle que nous privilégions : un cadrage à prix fixe, court, qui produit un document et un chiffre ; puis des étapes à périmètre fermé, chacune décidée à la lumière de la précédente. Vous gardez la main à chaque palier, et vous pouvez vous arrêter sans avoir tout perdu.

Avant de construire : faut-il vraiment construire ?

La façon la plus sûre de réduire le coût d'une application sur mesure est de ne pas en faire une. Un fournisseur honnête commence par regarder si un produit existant ferait l'affaire.

Le sur-mesure se justifie quand votre façon de travailler est un avantage concurrentiel qu'aucun progiciel ne reproduit ; quand aucun produit ne couvre votre métier ; ou quand l'abonnement d'un progiciel, multiplié par le nombre d'utilisateurs et par les années, finit par dépasser le coût du développement.

Dans les autres cas, acheter et adapter revient moins cher — et nous vous le dirons. Une recommandation de ne pas acheter chez nous vaut mieux qu'un projet que vous regretterez.

Comment obtenir un chiffre auquel se fier

Un montant fiable ne vient pas d'une conversation : il vient d'un cadrage écrit. C'est un travail court — quelques jours, pas quelques mois — qui produit un document listant ce qui est à faire, ce qui ne l'est pas, dans quel ordre, et à quel coût.

Nous le facturons à prix fixe, et il vous appartient. Vous pouvez le mettre en concurrence, le confier à un autre, ou décider de ne rien faire. C'est ce qui le rend crédible : nous n'avons pas intérêt à gonfler un périmètre que vous irez chiffrer ailleurs.

Les questions à poser à tout fournisseur

• L'intégration et la reprise de données sont-elles chiffrées séparément ? Si elles n'apparaissent pas, elles arriveront plus tard.
• Que se passe-t-il si le besoin change en cours de route ? La réponse révèle le mode de facturation réel.
• Combien coûtera la deuxième année ? Hébergement, soutien, évolutions.
• À qui appartient le code ? Et pourrai-je le confier à quelqu'un d'autre ?
• Qui fera le travail ? Les personnes rencontrées à la vente sont-elles celles qui livreront ?
• Que verrai-je, et quand ? Un projet sans livraison intermédiaire est un projet qu'on ne peut pas corriger.

Si votre besoin n'est pas de construire mais de reprendre un système existant, le raisonnement change : moderniser un logiciel ancien sans arrêter l'entreprise.

Questions fréquentes

Pouvez-vous me donner un prix sans rencontre ?

Un ordre de grandeur, oui, après une vraie conversation. Un montant ferme, non — il ne vaudrait rien.

Qu'est-ce qui fait le plus varier le prix ?

La densité des règles métier et le nombre d'intégrations, bien avant le nombre d'écrans.

Et si le projet dépasse le budget ?

Avec des étapes à périmètre fermé, le dépassement se voit à la fin d'une étape, pas à la fin du projet. C'est tout l'intérêt de découper : vous décidez d'arrêter ou de continuer en connaissance de cause, alors que les modules déjà livrés fonctionnent.

Payez-vous le cadrage si nous ne vous confions pas la suite ?

Oui, il est facturé — et il est à vous. C'est précisément ce qui vous permet de le mettre en concurrence.