Coût de développement d’une application — un calcul, pas une fourchette

Vous avez trois devis sur votre bureau pour la même application : environ CHF 9 000, CHF 30 000 et CHF 105 000 — des chiffres ronds illustratifs. Toutes émanent d’entreprises d’apparence sérieuse. Le premier réflexe est de chercher combien une application « devrait » coûter — et c’est là que les ennuis commencent, car la réponse que vous cherchez n’existe pas. Pas parce que personne ne l’a calculée, mais parce qu’aucune référence publique sur le prix du développement de logiciels sur mesure n’existe à l’échelle du marché suisse. Tout ce que vous trouverez, ce sont les grilles tarifaires des prestataires eux-mêmes.

Cet article n’ajoutera pas une fourchette de plus à la liste. Il montre à la place un calcul que vous pouvez refaire vous-même : ce que nous avons pu vérifier sur un taux horaire, et ce que nous n’avons pas pu ; pourquoi deux devis pour le même projet peuvent varier du simple au triple ; ce que coûte réellement une application après son lancement ; et ce qu’un devis doit contenir avant de pouvoir être comparé à quoi que ce soit. Chaque chiffre donné a une source et une date. Là où il n’y a pas de source, nous décrivons le mécanisme plutôt qu’un chiffre.

Pourquoi personne ne vous donne de prix pour une application ?

Parce qu’il n’y a rien à donner. Aucune institution ni organisation professionnelle ne publie de prix pour le développement de logiciels sur mesure en Suisse — ce qui est très différent de dire qu’il n’existe aucune donnée sur le secteur IT.

Nous avons cherché une organisation professionnelle suisse publiant des grilles de taux pour développeurs, ainsi que des statistiques suisses du coût du travail comparables à ce que publient d’autres pays. Le dernier chiffre d’Eurostat sur le coût du travail en Suisse a été mesuré en 2016, et nous ne l’utilisons pas. La seule référence suisse publiée que nous ayons trouvée est une étude tarifaire de Beyondweb, passant en revue 161 agences suisses avec des prix pour 36 d’entre elles, donnant un tarif horaire de CHF 120 à 250, moyenne CHF 166 — mais sur seulement dix observations, et elle chiffre des sites et du travail d’agence web, pas le développement d’applications sur mesure. Nous la citons plus loin, avec cette réserve, plutôt que de prétendre qu’elle répond à une question à laquelle elle ne répond pas.

Pour le reste, il ne subsiste que les grilles tarifaires des prestataires eux-mêmes, et l’on voit ici pourquoi on ne peut pas en faire une moyenne. En parcourant plusieurs pages qui chiffrent des applications, on retrouve toujours la même construction : trois paliers, généralement nommés « simple », « moyen » et « complexe », une liste de facteurs de prix en dessous, et l’année en cours dans le titre. L’année signale que la page est à jour, pas qu’une mesure a été faite à une date donnée — en dessous, il n’y a généralement ni nombre d’observations, ni période de collecte, ni définition de ce que recouvre « simple ».

Il ne s’agit pas de la malhonnêteté d’un prestataire en particulier. C’est la preuve que l’expression « application simple » ne veut rien dire d’assez précis pour être chiffrée. Tant que vous ne savez pas combien d’écrans, combien de rôles utilisateurs, combien d’intégrations et quel temps de travail est compris dans le prix, deux chiffres très différents peuvent tous deux être « vrais » — ils décrivent deux produits différents sous une même étiquette.

La conclusion pratique pour un acheteur n’est pas philosophique : arrêtez de chercher un prix de marché, commencez à comparer des périmètres. La suite de cet article montre comment.

Ce qui compose réellement le prix

Le prix d’une application est le produit de trois choses : un taux, du temps et un périmètre. Le périmètre décrit vos exigences, le temps découle du périmètre, et le taux est le seul chiffre pour lequel, comme l’explique cette section, il n’existe pas de source publique solide.

Étape 1 : pas de coût horaire suisse exploitable

Pour la plupart des marchés européens, on pourrait tirer un coût du travail d’Eurostat et construire le calcul à partir de là. Pour la Suisse, Eurostat a mesuré cela pour la dernière fois en 2016, et nous n’allons pas bâtir un calcul de 2026 sur un chiffre aussi ancien. Le seul chiffre dont nous disposons est la fourchette horaire de Beyondweb pour les agences web suisses, CHF 120 à 250, moyenne CHF 166 — utile comme ordre de grandeur pour du travail facturé en agence, mais construite sur dix observations et chiffrant des sites, pas spécifiquement du développement d’applications. La même étude cite aussi un prix de « plateforme web » de CHF 30 000 à 70 000, mais sur deux observations seulement — bien trop peu pour autre chose qu’un ordre de grandeur approximatif, raison pour laquelle nous ne construisons rien dessus non plus. Traitez ces deux chiffres comme des points de données, pas comme une référence à opposer à qui que ce soit.

Étape 2 : notre propre taux, et pourquoi il se situe en dessous de cette fourchette

Notre propre taux est de CHF 110 de l’heure — notre propre hypothèse, pas un taux de marché mesuré, car personne n’en a mesuré un spécifiquement pour le développement d’applications. Il se situe en dessous du plancher de CHF 120 de la fourchette d’agences Beyondweb de l’étape 1 — nous le disons clairement plutôt que de l’atténuer : le chiffre de Beyondweb facture du travail de site et d’agence web, sur un petit échantillon, pas du développement d’applications.

Étape 3 : pourquoi deux devis pour le même projet peuvent varier du simple au triple

Le seul véritable écart dont nous disposons est celui de Beyondweb : CHF 120 à 250 de l’heure, soit environ le double, sur dix agences web qui chiffrent des sites, pas des applications. Si vous avez sous les yeux des devis qui diffèrent du triple ou du décuple, cet écart ne se loge pas dans le taux. Il se loge dans le nombre d’heures — autrement dit, dans le périmètre.

La seule question à poser à chaque prestataire, dans les mêmes termes : combien d’heures supposez-vous, et pour quoi. Un devis qui ne peut pas y répondre n’est pas moins cher — il est indéfini.

Il n’existe pas d’agrégat suisse sur ce que les entreprises paient réellement pour faire développer une application web. C’est le même type d’écart que traite notre propre étude du marché polonais, mais strictement pour la Pologne ; nous n’étendons pas ses chiffres à la Suisse.

Nos propres prix, et ce qui se trouve derrière

Voici la partie où nous devons être précis, pour ne pas donner l’impression de nous contredire. Nous ne nous comparons à aucune médiane suisse — ce qui suit, ce sont simplement nos propres prix de départ et ce qu’ils détaillent séparément.

Nous ne publions pas de prix de départ fixe pour un MVP : le montant final résulte toujours d’un devis individuel. Dans notre calculateur, une application standard démarre à CHF 72 500 et un système enterprise multi-modules à CHF 250 000. Ce sont nos propres prix, fixés dans notre configuration — pas une affirmation sur le marché.

Ce qui distingue notre devis d’un prix affiché classique, c’est que ce qui est ajouté plus tard ailleurs est déjà une ligne visible chez nous : une phase de discovery avec recherche et maquettes ajoute CHF 4 000 pour un MVP, l’hébergement cloud géré coûte CHF 200 par mois, une astreinte avec SLA CHF 750 par mois, et chaque intégration avec un système externe CHF 4 000. Le calculateur affiche le résultat sous forme de fourchette de ±15 %, car c’est l’incertitude honnête au stade du brief.

Ce n’est donc pas que vous paieriez chez nous « plus de fonctionnalités » que dans une offre tirée d’une grille tarifaire — c’est que le reste de la facture est détaillé dès le départ chez nous, plutôt qu’ajouté plus tard.

Soyons clairs : nous ne prétendons pas que notre prix est le prix du marché, ni qu’un prix de marché est ce que vous paieriez chez nous. Ce sont deux choses différentes, mesurées de deux façons différentes, et toutes deux figurent dans cet article pour que vous puissiez les distinguer dans n’importe quel devis que vous recevrez.

Ce qui fait vraiment monter le coût, et ce qui ne le fait pas

Après avoir chiffré des dizaines de projets, nous constatons que le budget dérape toujours aux mêmes endroits — et presque jamais là où le client s’y attend.

Les intégrations avec les systèmes d’autrui. Chaque connexion à un système externe — paiements, ERP, transporteur, comptabilité — est un travail à part : authentification, correspondance des données, gestion des erreurs de l’autre côté, tests sur un environnement que vous ne contrôlez pas. Dans notre calculateur, c’est CHF 4 000 par intégration, et c’est le poste qui se multiplie le plus souvent en cours de projet.

Les rôles et les droits. « L’administrateur voit tout, l’utilisateur voit ses propres données » : c’est une seule règle. Cinq rôles aux droits partiellement chevauchants forment une matrice à concevoir, implémenter et tester dans chaque combinaison. C’est généralement la différence entre une application et un système.

La migration des données. Les données d’un système précédent ne sont jamais propres. Doublons, trous, trois formats de date différents et des champs utilisés autrement que leur nom l’indique : un travail invisible en démo et impossible à chiffrer sans ouvrir la base.

La conformité et les audits. Les exigences formelles peuvent dépasser le coût de l’application elle-même. Dans notre configuration, des niveaux de conformité comme SOC 2, ISO 27001, HIPAA ou PCI-DSS coûtent CHF 40 000 à 70 000 en une fois, plus CHF 1 000 à 2 000 par mois. Si votre secteur l’exige, c’est le premier poste à régler, pas le dernier.

Le rythme. Selon notre calculateur, réduire le calendrier de 30 % augmente le prix de 40 %, et le réduire de moitié le double. Pas parce que quelqu’un profite de votre urgence, mais parce qu’une équipe plus large travaillant en parallèle exige plus de coordination par unité produite.

Votre propre temps. Le poste le moins souvent compté, car il n’apparaît jamais sur une facture. Le brief, les ateliers, les validations, les tests de recette, les décisions que l’équipe attend : ce sont des heures de quelqu’un chez vous. Un projet où personne de votre côté n’a le temps de décider coûte plus cher, quel que soit le tarif du prestataire, car les retards se facturent aussi.

Et maintenant, contrairement à l’idée reçue, ce qui n’est pas le principal moteur du coût. Le choix de la technologie — tant que vous restez dans des solutions courantes — fait varier le budget de quelques pour cent ; d’après notre expérience, les tarifs des spécialistes des stacks populaires ne diffèrent pas beaucoup. Une interface « plus jolie » non plus : le travail de design évolue avec le nombre d’écrans et d’états distincts, pas avec le raffinement de l’un d’eux. Si une offre s’écarte des autres de 200 % et l’explique par la technologie ou la qualité du design, cela n’explique en rien un écart de périmètre.

Ce que coûte une application après son lancement

C’est la question à laquelle on répond le plus souvent par un pourcentage : « l’entretien, c’est 15 à 20 % de la valeur du projet par an », ou « comptez 20 % » — un chiffre qui circule sur des blogs d’agences. Nous avons cherché une source primaire à cette règle et n’en avons pas trouvé. Ce qui existe à la place, ce sont des blogs qui citent d’autres blogs, avec un écart de 10 à 30 %, sans échantillon, sans méthodologie ni période de mesure derrière aucun d’eux. Cet article ne donne donc aucun pourcentage pour l’entretien.

À la place : un calcul poste par poste. Commençons par le plus facile à vérifier.

Le serveur est la ligne la moins chère de ce calcul. Sur la grille tarifaire d’OVHcloud, une machine virtuelle à 2 cœurs, 4 Go de mémoire et 40 Go de stockage NVMe coûte 3,81 € net par mois, et une plus puissante — 8 cœurs, 24 Go, 200 Go — coûte 19,96 € net, toutes deux avec sauvegarde quotidienne et protection anti-DDoS incluses en standard. OVHcloud ne publie pas ces prix en francs suisses — c’est le prix en euros tel qu’OVHcloud le liste lui-même, et nous ne le convertissons pas en un chiffre CHF inventé. De quelques euros à une vingtaine par mois. Si quelqu’un justifie des frais d’entretien par le coût du serveur, vous venez de voir ce que ce serveur coûte réellement.

Les frais des stores sont fixes et publics. L’Apple Developer Program coûte 99 USD par an d’adhésion, le prix en monnaie locale n’étant affiché qu’à l’inscription, donc nous ne le convertissons pas. Un compte développeur Google Play est une redevance unique de 25 USD — une fois, pas par an.

Tout le reste est du temps de quelqu’un. Il est utile ici de reprendre les catégories de la norme ISO/IEC/IEEE 14764 — publiée le 21 janvier 2022, qui décrit la maintenance logicielle comme un processus itératif, avec une planification débutant dès le développement. Elle distingue quatre types de maintenance : corrective (correction de bugs découverts après le lancement), adaptative (adaptation aux changements autour de l’application — nouvelle version d’OS, API d’un prestataire de paiement modifiée, nouvelle réglementation), perfective (amélioration des performances et de la maintenabilité) et préventive (élimination de problèmes avant qu’ils n’apparaissent). La norme décrit un processus, pas une grille tarifaire — c’est exactement pourquoi aucun pourcentage n’en découle.

Le calcul pratique est donc : hébergement plus domaine, sauvegardes à fréquence définie, surveillance de la disponibilité et des performances, mises à jour des dépendances selon un rythme établi, un temps de réponse convenu en cas d’incident, et un budget séparé pour les changements imposés de l’extérieur. Notre propre modèle d’entretien chiffre exactement de cette façon — un montant mensuel pour chacun de ces postes, sans aucune référence à la valeur du projet. Un contrat de service qui donne un seul chiffre et le mot « accompagnement » ne vous dit pas ce que vous payez.

Comment lire un devis que vous avez reçu

Puisque la différence entre les offres se loge dans le périmètre, seuls les devis qui décrivent ce périmètre sont réellement comparables. Un bon devis a quatre parties, et leur absence signale que vous avez reçu une grille tarifaire plutôt qu’une offre.

La dernière ligne est la plus importante, car c’est là que se logent la plupart des conflits. Un forfait vous donne un budget connu à l’avance et moins de risque de surprise, mais chaque changement de périmètre demande un avenant formel — et plus le contrat est rigide, plus la marge de sécurité que le prestataire intégrera dans son prix sera importante. La facturation en régie (time and material) signifie que vous payez les heures réellement travaillées et pouvez changer de direction en cours de route, mais c’est à vous de veiller à ce que le périmètre ne s’étende pas sans limite. Un compromis courant est un forfait sur un noyau défini, et des heures pour tout le reste.

Questions à poser à chaque prestataire, dans les mêmes termes :

• Combien d’heures supposez-vous, réparties comment entre les étapes ?
• Qu’est-ce qui est exclu de ce prix ?
• Les tests et corrections de bugs sont-ils inclus, ou facturés séparément ?
• À qui appartient le code source, et où sera-t-il conservé ?
• Quel est le temps de réponse après le lancement en cas de panne, et combien cela coûte-t-il ?

Un mot sur les offres nettement moins chères que les autres. Moins cher ne veut pas automatiquement dire moins bon — cela signifie que la même arithmétique de la section sur le taux s’applique aussi du côté du prestataire. Si un prix est inférieur d’un ordre de grandeur à tous les autres, soit le périmètre est différent, soit les tests, la documentation et le support n’y figurent pas, soit quelqu’un a sous-évalué le projet et l’écart réapparaîtra plus tard — le pire des cas, car c’est à vous deux qu’il reviendra de le corriger.

Par où commencer

Commencez par la plus petite version qui résout un vrai problème — un MVP. Pas parce qu’il serait moins cher d’un pourcentage fixe (personne ne l’a mesuré), mais parce que c’est le seul moyen de découvrir ce dont vous avez réellement besoin avant de payer la version complète. Un périmètre que vous ne savez pas décrire est la chose la plus chère de tout ce calcul.

En pratique : écrivez le parcours utilisateur étape par étape, repérez où l’application doit dialoguer avec un autre système, comptez les rôles, et notez quelles données doivent être migrées depuis ce que vous utilisez aujourd’hui. Avec ce document, vous pouvez partir chercher des devis réellement comparables.

Revenons aux trois devis du début. Avec ce document en main, posez à chacun des trois prestataires la même question sur les heures et les exclusions, et comparez les réponses, pas les totaux. Neuf fois sur dix, l’écart se loge dans trois ou quatre postes précis — intégrations, rôles, migration, support après lancement — et une fois ceux-ci alignés, les offres se rapprochent assez pour que la décision cesse d’être une loterie.

Si vous voulez d’abord voir l’ordre de grandeur, le calculateur du coût d’une application web affiche un résultat avec les postes qui le composent. En chemin, il vaut la peine de lire à quoi ressemble le processus côté prestataire et ce qu’il faut préparer avant de démarrer. Si vous envisagez une application mobile, nous traitons cette famille de coûts séparément dans notre article sur la création d’applications mobiles. Et si vous préférez discuter d’un périmètre précis, nous construisons des systèmes sur mesure.