Développement d'application web sur mesure : prix et méthode

Six variables expliquent la quasi-totalité de l'écart entre deux devis d'application. Aucune ne dépend de votre secteur, toutes dépendent de ce que l'outil doit faire.

Le nombre de rôles est le facteur le plus sous-estimé. Chaque rôle supplémentaire ne double pas le travail d'interface, il multiplie les cas à vérifier : qui voit quoi, qui modifie quoi, ce qui se passe quand un utilisateur change de rôle en cours de route.

Les intégrations arrivent juste derrière. Se connecter à un système extérieur, ce n'est pas brancher un câble : il faut lire sa documentation, gérer ses limites d'appel, prévoir son indisponibilité et décider ce que fait votre application pendant ce temps.

Le volume de données change moins de choses qu'on ne le croit au début, et beaucoup plus ensuite. Dix mille lignes ou dix millions, l'écran est le même ; la recherche, les filtres, les exports et les sauvegardes ne le sont pas. Nous posons donc la question du volume à trois ans, pas du volume d'aujourd'hui.

La disponibilité attendue est la variable la plus coûteuse et la moins souvent exprimée. Une application utilisée par votre équipe aux heures de bureau et une application dont dépendent vos clients la nuit ne demandent ni la même infrastructure, ni la même surveillance, ni le même engagement de notre côté.

La reprise de données existantes est le poste le plus difficile à chiffrer sans avoir vu les données. Nous demandons un échantillon réel avant de donner un montant sur cette ligne, plutôt que d'écrire un chiffre de précaution qui vous ferait payer une incertitude qui est la nôtre.

Ces quatre mots recouvrent des projets très différents. Voici ce que chacun implique concrètement, pour situer votre besoin avant le premier échange.

Une plateforme SaaS ajoute au développement classique tout ce qui entoure l'abonnement : inscription autonome, essai, niveaux de service, facturation récurrente, gestion des clients qui arrêtent puis reviennent. C'est le périmètre où le travail invisible dépasse souvent le travail visible.

Un CRM sert à suivre des contacts, des opportunités et des relances. Le cœur est simple ; ce qui coûte, c'est l'import de l'historique, les règles d'attribution entre commerciaux, et les rapports que la direction veut voir sans ouvrir un tableur.

Un ERP touche aux stocks, aux achats, à la production ou à la facturation. Nous ne remplaçons pas un ERP complet du marché en un projet : nous développons la partie qui vous manque et nous la connectons à ce que vous utilisez déjà. Le dire avant le devis évite une déception à six mois.

Un portail client donne à vos clients un accès à leurs documents, à leurs commandes ou à leurs dossiers. C'est le périmètre le plus abordable des quatre, parce que les rôles sont peu nombreux et les écrans en lecture.

Avant de choisir un de ces périmètres, il vaut la peine de vérifier qu'un outil du marché ne fait pas déjà l'essentiel. Nous le regardons avec vous, et quand la réponse est oui, le développement sur mesure se réduit souvent à la pièce qui manque et à la connexion entre les deux. C'est un projet plus court, moins cher, et qui échoue moins souvent.

Helix Trading, dans notre portfolio, montre une cinquième famille : la plateforme métier. Trading éducatif, simulateur développé pour elle, parcours de challenges, base PostgreSQL, authentification séparée par rôle. Rien de cela n'existait sur étagère.

Le cadrage n'est pas une formalité commerciale. C'est la phase où les décisions coûtent le moins cher à changer, et c'est la seule qui produit un document utile même si vous ne travaillez pas avec nous ensuite.

Nous écrivons d'abord les rôles et les cas d'usage : qui fait quoi, dans quel ordre, et ce qui se passe quand une étape échoue. Une commande annulée, un paiement refusé, un employé qui quitte l'entreprise : ces cas représentent une part importante du code et ils sont presque toujours absents des briefs.

Vient ensuite le modèle de données : les entités, leurs relations, ce qui doit rester historisé. Une facture ne se modifie pas, elle s'annule et se remplace. Une décision comme celle-là se prend avant le développement, pas après le premier contrôle comptable.

Nous écrivons aussi ce qui ne sera pas dans la première version. C'est la partie la plus utile du document. Une application qui essaie de tout faire dès le départ sort tard, coûte cher et se révèle fausse sur la moitié de ses hypothèses. Nous préférons une première version étroite, mise entre les mains de vos utilisateurs, puis élargie avec ce qu'ils ont réellement demandé.

Ce cadrage est écrit, chiffré et vous appartient. Le devis qui suit s'appuie dessus, ligne par ligne.

Le développement est un coût qui s'arrête. L'exploitation est un coût qui continue, et c'est celui que les projets d'application oublient de budgéter.

Quatre postes reviennent systématiquement. L'hébergement, qui pour une application dépasse la mutualisation d'un site vitrine : il faut de la mémoire, une base de données correctement dimensionnée et des sauvegardes. Les services extérieurs facturés à l'usage : envoi d'e-mails transactionnels, stockage de fichiers, solution de paiement, cartographie. La maintenance : mises à jour des dépendances, correctifs de sécurité, surveillance des erreurs. Le support aux utilisateurs, enfin, qui est un vrai poste dès que l'application sort de votre équipe.

Nous chiffrons ces postes dans la proposition, projet par projet, parce qu'ils dépendent du dimensionnement réel et pas d'un forfait moyen. Le prix annoncé est le prix final, aucun montant n'est ajouté ensuite, et cela vaut aussi pour la ligne d'exploitation une fois qu'elle est écrite.

C'est le point qui sépare une application développée pour vous d'une application louée. Chez un prestataire qui livre sur sa propre plateforme, vous payez pour utiliser ; le jour où vous partez, il ne reste rien.

À la livraison, vous recevez le dépôt de code avec son historique, la base de données et son schéma, les accès à l'hébergement, l'administration à votre nom, et les comptes des services tiers créés sur vos adresses plutôt que sur les nôtres. Vous recevez aussi la documentation technique : comment l'application se déploie, de quoi elle dépend, où regarder quand quelque chose ne va pas.

Sur le plan du droit, l'hébergement se choisit avec vous et le traitement des données personnelles suit le RGPD, puisque le studio et le contrat sont dans l'Union européenne. Quand l'application manipule des données de vos clients, nous écrivons dans la proposition qui y accède de notre côté, pendant combien de temps, et ce qui se passe à la fin du projet.

Vos données restent exportables dans un format lisible par un autre outil. Nous ne construisons pas de sortie payante et nous ne conditionnons pas le fonctionnement de l'application à un abonnement chez nous. Si vous confiez la suite à une autre équipe dans deux ans, elle reprend le projet sans nous appeler.

Une application se corrige en production tôt ou tard, et c'est exactement ce qu'il faut éviter. Chaque projet part donc avec deux environnements séparés : la production, que vos utilisateurs voient, et la recette, qui lui ressemble et sur laquelle tout se teste d'abord.

La recette sert à trois choses. Vous y validez chaque lot avec vos propres cas avant qu'il parte en production. Nous y rejouons les mises à jour de dépendances avant de les appliquer. Et quand un utilisateur signale un comportement étrange, nous le reproduisons là, sans toucher aux données réelles.

Les sauvegardes suivent la même logique. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde, c'est un fichier. Nous vérifions qu'une restauration fonctionne réellement, et la proposition précise la fréquence, la durée de conservation et le temps nécessaire pour remettre l'application en marche après un incident.

Nous écrivons aussi ce qui est enregistré : qui s'est connecté, qui a modifié quoi et quand. Sur une application qui touche à des données personnelles, cette traçabilité fait partie du travail de conformité, pas des options.

La page roumaine de notre studio annonce une première version utilisable en trois à six mois pour une application métier. Cet ordre de grandeur tient quand le périmètre est tenu et quand les retours arrivent dans la semaine. Il ne tient pas si le cadrage se rouvre tous les quinze jours.

Le déroulement est le suivant : cadrage écrit et chiffré, puis maquettes et modèle de données validés ensemble, puis développement par lots livrés sur la recette, puis vérification complète avec vos données, puis mise en production et transfert des accès.

Un lot n'est pas une étape de calendrier, c'est un morceau utilisable. Il contient ses écrans, ses règles, ses cas d'erreur et ses tests, et il part en recette fini plutôt qu'à moitié. Cela rallonge un peu le premier lot et raccourcit tous les suivants, parce que vous corrigez une direction sur du concret.

Le compteur ne démarre pas à la signature mais au cadrage validé. Ce qui décale le plus les projets n'est presque jamais technique : ce sont les décisions en attente chez le client, les contenus qui n'arrivent pas et les accès aux systèmes à intégrer qui mettent trois semaines à être délivrés.

Après la mise en ligne, une période de corrections est comprise. Elle couvre les écarts par rapport à ce qui a été écrit, pas les fonctionnalités nouvelles, qui sont chiffrées à part et acceptées avant le travail.

Pages liées: notre façon de développer sur mesure