Ce que coûte vraiment une application sur mesure : une décomposition honnête et transparente

Demandez à trois agences combien coûte une application sur mesure et vous obtiendrez trois chiffres qui n'ont pas même un chiffre en commun. L'une dit quatre mille, l'autre quarante, la troisième dit tout bas « ça dépend » et planifie un second rendez-vous. Aucune ne ment vraiment, mais aucune ne vous dit ce que vous avez réellement besoin de savoir : où va l'argent et pourquoi votre application à vous atterrit là où elle atterrit. Alors ouvrons le capot.

J'ai rédigé plus de devis d'applications que je ne saurais compter, pour des entreprises allant de l'artisan en solo à la chaîne régionale. La réaction la plus fréquente face à un prix n'est pas le choc devant le total, mais la perplexité devant l'écart. Comment le même brief de trois mots (« une appli de réservation ») peut-il produire des estimations qui diffèrent d'un facteur dix ? La réponse honnête, c'est qu'« une appli de réservation » n'est pas un brief. C'est un souhait. Le prix se loge dans les cent petites décisions qui se cachent en dessous.

Cet article est la décomposition que j'aimerais que tout dirigeant ait en main avant son premier appel avec un développeur. Sans remplissage, sans tactiques alarmistes, sans vente forcée. Juste les vrais postes de coût, les éléments qui doublent un budget en silence et quelques moyens honnêtes de dépenser moins sans finir avec quelque chose que l'on regrette.

Pourquoi deux devis pour « la même appli » diffèrent d'un facteur 10

Un logiciel n'est pas un produit que l'on prend sur une étagère : c'est du travail, mesuré en heures de personnes qualifiées. Le prix d'une application sur mesure est donc, au fond, simplement périmètre × taux horaire × risque. Tout le reste n'est qu'une note de bas de page à ces trois éléments. Quand deux devis divergent fortement, l'un de ces trois chiffres est lu de façon très différente, et le plus souvent personne ne l'a dit à voix haute.

Le périmètre est le facteur évident. « Une appli de réservation » peut désigner un seul écran où les clients choisissent un créneau, ou bien des plannings d'équipe, des paiements, des rappels, un espace client, un tableau de bord d'administration, des remboursements et un rapport que le dirigeant lit le lundi. Les mêmes trois mots, dix fois le travail. Le devis bon marché suppose souvent la petite version ; le cher suppose en silence la grande. Aucun ne vous a demandé laquelle vous vouliez dire.

Vient ensuite le risque, la part que personne n'aime chiffrer. Un brief flou, un client qui n'a pas décidé ce qu'il veut, une intégration avec un vieux système hérité et bancal : tout cela n'ajoute pas que des heures, cela ajoute de l'incertitude. Les équipes expérimentées prennent une marge pour l'incertitude parce qu'elles s'y sont déjà brûlées. Un devis moins cher n'a souvent pas chiffré le risque du tout, et c'est précisément pour cela qu'il explose parfois à mi-parcours.

Où va réellement l'argent

Quand on imagine le développement d'une application, on imagine du code. Le code est bien réel, mais il représente rarement même la moitié de la facture. Une application sur mesure ressemble davantage à la construction d'une petite maison qu'à la rédaction d'un document : autour de la partie visible, il y a la conception, la plomberie, le contrôle et la paperasse. Voici comment se répartit un budget type une fois que l'on prend tout en compte.

Deux choses surprennent souvent dans ce tableau. D'abord, quelle part du budget intervient avant qu'une seule ligne de code fonctionnel ne soit écrite : le cadrage et la conception ne sont pas un luxe, ce sont l'endroit le moins cher pour corriger une erreur. Modifier un écran sur une esquisse coûte des minutes ; le modifier une fois construit coûte des jours. Ensuite, à quel point la ligne des tests est réelle. La sauter ne fait pas économiser d'argent, cela ne fait que déplacer le coût vers votre semaine de lancement, avec les intérêts.

Cadrage et conception : la partie que tout le monde veut sauter

Le cadrage, c'est là que vous transformez « une appli de réservation » en une liste précise d'écrans et de règles. Cela ressemble à des frais généraux parce que rien n'est encore construit. Mais chaque heure ici en fait économiser plusieurs par la suite, car c'est là que l'ambiguïté est éliminée tant qu'elle est encore bon marché. Une équipe qui vous annonce un prix sans phase de cadrage soit devine, soit prévoit de vous facturer le cadrage plus tard sous un autre nom.

Développement central : le moteur visible

C'est le code qui fait tourner votre idée : les écrans que les gens touchent, la logique derrière eux et la base de données qui retient tout en silence. C'est la plus grosse part unique, et elle augmente presque directement avec le périmètre. Chaque fonctionnalité ajoutée, c'est davantage à construire, à tester et à maintenir pour toujours. C'est la ligne où « ce serait sympa si... » devient vite coûteux.

Intégrations : la partie trompeusement coûteuse

Connecter votre application à d'autres systèmes — encaisser un paiement par carte, envoyer un rappel par SMS, synchroniser un agenda, récupérer des données du logiciel de comptabilité que vous utilisez déjà — paraît modeste sur une liste de fonctionnalités et pèse étonnamment lourd sur la facture. Chaque connexion est un petit projet à part entière, avec ses propres particularités et ses modes de défaillance. Une intégration de paiement bien élevée, ça va. Cinq intégrations enchevêtrées avec un système maison vieillissant, c'est là que les budgets vont mourir.

Les coûts que personne ne met dans le devis

C'est là que beaucoup de dirigeants ont une mauvaise surprise au bout de douze mois. La construction est un chiffre unique ; une application n'est pas une affaire ponctuelle. Le logiciel est vivant — les téléphones se mettent à jour, les règles changent, votre entreprise grandit — et une chose vivante doit être nourrie. Le devis que vous signez est le prix de la naissance, pas le prix de la possession.

Rien de tout cela n'est une arnaque ni un piège caché : c'est juste la partie qui ne tient pas bien sur un devis d'une page, alors les partenaires plus faibles l'omettent pour paraître moins chers. Un bon partenaire vous en parle d'emblée, même si cela fait paraître son premier chiffre plus élevé. Demandez explicitement : combien cela me coûte-t-il de faire tourner cela pendant un an après le lancement ? La qualité de la réponse en dit long sur la personne à qui vous avez affaire.

Ce qui double le prix en silence

Certaines choses ajoutent du coût à proportion de la valeur qu'elles apportent : c'est légitime. D'autres ajoutent du coût de façon totalement disproportionnée, généralement à cause de la manière dont le travail est structuré plutôt que de ce que fait l'application. Ces leviers méritent d'être compris, car quelques-uns sont entièrement entre vos mains.

• Deux plateformes plutôt qu'une. Une application native iPhone et une application native Android, c'est, grosso modo, deux constructions. Les outils multiplateformes ou une application web ramènent cela vers une seule. Ce seul choix peut faire bouger le total plus que n'importe quelle fonctionnalité.
• Un design sur mesure plutôt que des choix par défaut sensés. Une interface entièrement sur mesure et réglée au pixel coûte cher à concevoir et à construire. Une interface propre et conventionnelle, fondée sur des schémas éprouvés, est plus rapide, moins chère et souvent plus facile à utiliser pour les clients.
• Changer d'avis une fois la construction commencée. Les décisions sont bon marché sur un tableau blanc et chères dans le code. Le dépassement de budget le plus courant n'est pas une mauvaise estimation, mais un périmètre qui n'a cessé de grossir parce que rien n'était figé.
• Temps réel, hors ligne ou données volumineuses. « Ça doit fonctionner sans réseau » ou « les mises à jour doivent apparaître instantanément pour tous » sont des demandes raisonnables qui multiplient en silence l'ingénierie sous-jacente.
• S'intégrer à quelque chose d'ancien et non documenté. Se connecter à un système moderne et bien conçu est une routine. Se connecter à un outil maison de quinze ans sans documentation tient de l'archéologie, et cela se facture à l'heure.

Un exemple réel : le devis à 60 000 € devenu une appli à 14 000 €

Quelques détails ont été modifiés pour la confidentialité, mais la forme de cette histoire est vraie et tout à fait typique. Une entreprise de services régionale — imaginez une douzaine d'intervenants sur le terrain et un bureau bien occupé — est venue nous voir, frustrée. Elle voulait une application sur mesure pour que ses clients réservent des interventions, suivent leur avancement et paient. Elle avait déjà reçu ailleurs un devis d'environ 60 000 €, plus un abonnement mensuel costaud, et cela l'avait dissuadée de toute l'idée pendant près d'un an.

Quand nous avons réellement cartographié ce dont elle avait besoin — et non ce qu'on lui avait chiffré — le tableau était bien différent. Le premier devis avait supposé deux applications entièrement natives, un design sur mesure parti de zéro, un système de répartition en temps réel et une plateforme d'administration sur mesure pour remplacer des outils qu'elle possédait déjà et dont elle était discrètement satisfaite. C'était, techniquement, une très bonne application. C'était aussi la réponse à une question qu'elle n'avait pas posée.

Ce que nous avons réellement fait

Nous avons consacré les premières séances uniquement au cadrage, en séparant le souhait entre « l'entreprise s'arrête sans cela » et « ce serait bien un jour ». Les indispensables étaient plus réduits que prévu : un moyen propre pour les clients de demander et de suivre une intervention, des rappels automatiques et le paiement en ligne. La répartition en temps réel et le back-office sur mesure se sont avérés être des solutions à des problèmes que leur logiciel existant gérait déjà très bien.

1. 1
   Réduire le périmètre au vrai besoin

   Nous avons écarté les fonctionnalités qui résolvaient des problèmes qu'ils n'avaient pas et conservé une liste serrée sans laquelle l'entreprise ne pouvait vraiment pas fonctionner.
2. 2
   Choisir une seule construction multiplateforme

   Au lieu de deux applications natives distinctes, une seule application multiplateforme couvrait iPhone et Android, ce qui a à peu près réduit de moitié le développement central.
3. 3
   Utiliser des schémas de conception éprouvés

   Une interface propre et conventionnelle plutôt que sur mesure. Les clients l'ont trouvée plus facile à utiliser, et elle a fait gagner des semaines sur le calendrier.
4. 4
   Connecter, pas remplacer

   Nous avons relié l'application au logiciel de bureau qu'ils payaient déjà, au lieu de le reconstruire. La coûteuse « plateforme d'administration sur mesure » a simplement disparu du périmètre.

Le résultat fut une construction d'environ 14 000 €, en production en quelques mois, avec des coûts de fonctionnement prévisibles. Elle n'est pas aussi tentaculaire que la version à 60 000 € — et elle n'a pas besoin de l'être. Elle fait le travail que l'entreprise avait réellement. Un an plus tard, ils ont ajouté deux petites fonctionnalités par-dessus, payées avec l'argent que la première version leur avait fait économiser. C'est tout le schéma : commencer par le vrai besoin, gagner les extras avec des résultats.

Comment garder le coût raisonnable sans rogner sur l'essentiel

Dépenser moins pour une application sur mesure ne consiste pas à marchander le taux horaire à la baisse ni à trouver l'équipe la moins chère possible. C'est ainsi que l'on finit par payer deux fois. Il s'agit d'être délibéré sur le périmètre, l'ordonnancement et les décisions : les trois choses qui font réellement bouger le chiffre. C'est là que se trouvent les vraies économies.

Premièrement, construisez la plus petite version réellement utile, puis faites-la grandir. Une première livraison ciblée qui fait bien une seule chose vous met en production plus vite, coûte une fraction du rêve tout-en-un et — surtout — vous apprend quoi construire ensuite à partir de vrais clients plutôt que de suppositions. Deuxièmement, prenez vos décisions avant le début de la construction ; l'indécision est la chose la plus chère que vous puissiez apporter à un projet. Troisièmement, connectez-vous à ce que vous possédez déjà au lieu de remplacer des outils qui fonctionnent, et ne reconstruisez quelque chose que lorsqu'il vous freine vraiment.

Questions fréquentes