Chez Schörger, une première application métier demande 4 à 10 semaines de travail. Elle porte sur une première version (V1) centrée sur un seul parcours, celui qui compte le plus dans votre activité. Une application de réservation, un portail B2B et un SaaS avec abonnement ne demandent ni le même travail ni les mêmes précautions.
Avant de demander « combien coûte une application ? », décidez quelle partie du métier doit fonctionner proprement dès la première mise en ligne, et ce qui peut encore rester manuel pendant trois mois. C'est cette limite, écrite au départ, qui protège le budget.
Ce que paie une première version métier
Le devis d'une V1 paie un outil en ligne, que vos clients ou votre équipe utilisent pour de bon, avec comptes utilisateurs, rôles, base de données, interfaces métier, sécurité, sauvegardes, déploiement et documentation. Une maquette cliquable n'a rien de tout cela. Le périmètre exact varie, mais l'outil doit déjà faire son travail principal.
- Une V1 plus légère : un parcours principal bien délimité, peu de rôles, une administration simple et une seule intégration simple.
- Une V1 plus large : plusieurs espaces connectés, des permissions plus fines, un paiement ou un abonnement, un tableau de bord et une reprise de données raisonnable.
- Au-delà : le projet cumule souvent plusieurs produits, une migration complexe, du mobile natif ou des contraintes spécifiques. On le découpe alors en étapes, chiffrées séparément.
Un devis très inférieur peut être parfaitement adapté s'il s'agit d'un prototype ou d'un outil no-code limité. Il devient dangereux quand il promet le même produit complet et retire sans le dire les tests, l'administration, la sécurité ou le traitement des cas d'erreur.
Ce qui coûte vraiment n'est presque jamais le nombre d'écrans
Une page de tableau de bord peut être simple. Un bouton « valider » peut, lui, déclencher une écriture comptable, réserver un créneau, notifier trois personnes et interdire une double opération. À l'écran, c'est un bouton. Derrière, c'est une règle métier qui doit rester vraie même si le réseau coupe ou si deux personnes cliquent en même temps.
Les six postes qui font varier un devis
- Les rôles et permissions : client, équipe, administrateur, partenaire ou technicien ne doivent ni voir ni modifier les mêmes données.
- Les règles métier : statuts, validations, calculs, disponibilités, tarification et exceptions forment l'essentiel du logiciel.
- Les intégrations : Stripe, calendrier, CRM, comptabilité, signature ou API fournisseur ajoutent chacune leurs erreurs et leurs cas limites.
- La reprise de données : importer un fichier propre n'a rien à voir avec réconcilier cinq années de tableurs contradictoires.
- L'administration : quelqu'un doit pouvoir corriger une donnée, relancer une opération et comprendre ce qui s'est passé sans appeler le développeur.
- Ce qui tient l'outil en ligne : tests, journalisation, sauvegardes, sécurité, performance, déploiement et procédure de retour arrière.
Trois projets réels, trois complexités différentes
Le studio a codé et mis en ligne ces trois outils. Aucun ne se résume à « faire quelques pages ».
- Arqua, climatisation autour d'Avignon : un site relié à trois espaces métier, au paiement Stripe, à Google Calendar et aux rappels d'entretien. La difficulté est de garder devis, planning et rôles cohérents.
- Les Safrans, maison d'hôtes à Tavel : réservation directe, acompte Stripe, blocage croisé entre chambres et maison entière, puis synchronisation iCal avec Airbnb et Booking. Tout est fait pour éviter la double réservation.
- Alieva, outil d'audit de sites : connexion d'un site, contrôles automatisés, génération d'un rapport de vitalité mensuel et abonnement. Le produit réunit une application web et un moteur d'audit Python.
Ce que vous payez, ce sont ces règles, celles qui empêchent la double réservation aux Safrans ou qui gardent devis et planning cohérents chez Arqua. Un devis sérieux les nomme une par une.
Acheter un logiciel existant ou construire le vôtre ?
Faire développer votre outil n'est pas automatiquement la meilleure décision. Si votre besoin correspond à 90 % à un logiciel du marché, commencez par ce logiciel. Il sera plus rapide, moins risqué et probablement moins cher la première année.
- Achetez un SaaS si le processus est standard : facturation classique, newsletter, prise de rendez-vous simple ou CRM sans règle particulière.
- Construisez si votre façon de travailler est un avantage, si plusieurs outils doivent s'appuyer sur les mêmes données ou si les contournements occupent déjà une personne.
- Faites-le aussi quand la propriété des données, les rôles ou l'expérience client demandent des réglages que le logiciel générique ne permet pas.
Quand un logiciel du marché fait le travail, on vous le dit, et on ne développe rien. Payer un développement pour refaire un outil standard qu'on loue au mois, c'est de l'argent perdu.
Comment réduire le budget sans fabriquer une mauvaise application
Pour économiser, retirez une branche du processus et gardez la sécurité et les tests. Une V1 solide peut couvrir peu de choses, à condition de les faire sans erreur.
- Choisissez un seul résultat principal : par exemple, permettre à un client de réserver et payer, avant de construire tout le CRM.
- Limitez les rôles au strict nécessaire. Chaque nouveau rôle multiplie les scénarios de permission et de test.
- Gardez une opération rare en validation manuelle plutôt que d'automatiser immédiatement tous les cas exceptionnels.
- Repoussez l'application mobile native si une application web adaptée au téléphone couvre réellement l'usage sur le terrain.
- Préparez des exemples de données et cinq cas réels avant les ateliers. Ils valent mieux que trente pages de cahier des charges abstrait.
- Décidez ce qui prouvera que la V1 fonctionne : temps gagné, erreurs supprimées, réservations directes ou délai de traitement.
Comparer deux devis sans comparer deux listes de fonctions
Le devis le plus détaillé n'est pas forcément le meilleur, mais un bon devis montre où sont les risques. Demandez une réponse écrite aux sept questions suivantes. Une hésitation aujourd'hui devient souvent un supplément ou un blocage en cours de projet.
- Qui possède le code, les comptes cloud, le domaine et les données à la livraison ?
- Quelles intégrations sont réellement incluses et lesquelles sont seulement évoquées ?
- La reprise de données comprend-elle le nettoyage, les doublons et un essai d'import ?
- Quels navigateurs, rôles et parcours sont testés avant la mise en ligne ?
- Que se passe-t-il si une API tierce est indisponible ou change ses règles ?
- L'administration, les sauvegardes, les logs et la documentation sont-ils compris dans le devis ?
- Quel est le mécanisme de validation et comment sont chiffrées les demandes hors périmètre ?
Le coût après la mise en ligne fait partie de la décision
Une application continue de coûter après sa mise en ligne. Les navigateurs évoluent, les API changent, les utilisateurs découvrent de nouveaux cas et les règles métier bougent. Décidez avant de signer qui surveille, qui sauvegarde, qui corrige et qui arbitre les évolutions.
Inutile pour autant de signer un gros contrat par réflexe. Demandez le coût total, avec l'hébergement, les services tiers, la maintenance corrective, les évolutions et la disponibilité attendue. Un produit moins cher à construire peut devenir le plus coûteux si personne ne sait le reprendre.