Coût réel d’une plateforme Node.js sur mesure : création, lancement et trois ans d’exploitation

On vous a communiqué un montant pour développer une plateforme sur mesure. Ce montant est élevé, et vous cherchez à savoir s’il est justifié. La réalité, inconfortable, est que le coût de développement — quel que soit le prestataire — ne représente qu’environ la moitié de ce que la plateforme vous coûtera sur trois ans. L’autre moitié n’est pas cachée ; elle ne figure simplement pas dans le périmètre d’une proposition classique.

Voici le modèle que nous utilisons lorsqu’un client nous demande de l’aider à établir un budget réaliste, y compris pour des travaux qui ne nous seront peut-être pas confiés.

Année zéro : la construction

Le montant visible. Sa répartition est généralement plus prévisible que ce que les marchands imaginent :

• Découverte et architecture : 8 à 12 % du coût de développement. Négliger cette phase est le moyen le plus sûr de dépenser plus ensuite.
• Application principale : 40 à 50 %. Les fonctionnalités prévues dans le cahier des charges.
• Intégrations : 15 à 30 %. Presque toujours sous-estimées — voir ci-dessous.
• Travaux non fonctionnels : 10 à 20 %. Authentification, gestion des droits, rate limiting, gestion des fichiers, e-mails transactionnels, journalisation, gestion des erreurs. Invisibles en démonstration, essentiels en production.
• Tests et sécurisation : 8 à 15 %.
• Déploiement et mise en place de l’infrastructure : 5 à 10 %.

Pour une plateforme réellement sur mesure avec de vraies intégrations, le coût de développement se situe généralement entre 120 000 £ et 450 000 £. En dessous de 80 000 £, il s’agit d’un MVP, ce qui peut être pertinent si tout le monde en est conscient.

Pourquoi les intégrations font exploser les estimations

Intégrer l’ERP tient en une ligne dans un cahier des charges, mais représente trois à huit semaines de travail. La variation dépend de facteurs impossibles à connaître lors du chiffrage : documentation de l’API, existence d’un bac à sable, limites de débit du fournisseur, adéquation du modèle de données, et disponibilité de la personne qui maîtrise le système.

Chiffrez les intégrations sous forme de fourchette, avec une hypothèse explicite pour chacune, puis réajustez après un spike technique. Un forfait sur une intégration dont personne n’a encore vu l’API est une estimation déguisée.

Année un : lancement et stabilisation

L’année que la plupart des budgets appellent « maintenance » alors qu’il n’en est rien.

• Stabilisation post-lancement : 15 à 25 % du coût de développement. Les utilisateurs réels découvrent toujours ce que les tests n’ont pas vu.
• Infrastructure : 500 à 5 000 £/mois selon la taille et la redondance.
• Services tiers : supervision, suivi des erreurs, envoi d’e-mails, recherche, authentification. 200 à 2 000 £/mois, avec une croissance discrète.
• Le backlog de changements : tout ce que l’entreprise voulait mais a accepté de reporter. Prévoyez 20 à 35 % du coût de développement pour la première année, ou la plateforme sera figée dès son lancement.

Années deux et trois : appropriation

C’est ici que le logiciel sur mesure diffère fondamentalement d’un logiciel sous licence, et là où la plupart des business plans cessent discrètement de modéliser.

Maintenance des dépendances

Une application Node.js s’appuie sur une arborescence de dépendances importante, qui évolue constamment. Le cycle de publication de Node impose l’obsolescence programmée des versions ; frameworks et bibliothèques introduisent des ruptures ; les alertes de sécurité arrivent, que vous ayez de la capacité ou non.

Prévoyez 5 à 10 % du coût de développement par an uniquement pour rester à jour. Faire l’impasse n’est pas une économie : c’est une dette qui se paie d’un coup, souvent lors d’une alerte de sécurité, quand la mise à niveau implique cinq versions majeures successives.

Exploitation et astreinte

Quelqu’un intervient quand cela tombe en panne à 3 h du matin. Ce service a un coût, qui varie fortement selon vos besoins réels :

• Heures ouvrées, best effort : 1 500 à 4 000 £/mois
• Heures étendues avec SLA de réponse : 4 000 à 10 000 £/mois
• Véritable 24/7 avec astreinte : 10 000 £/mois et plus, car il faut assez de personnes pour rendre l’astreinte supportable

Définissez vos besoins de façon honnête. Acheter du 24/7 pour une plateforme dont tous les utilisateurs sont dans un seul fuseau horaire est un gaspillage ; se contenter des heures ouvrées pour un système qui traite des commandes la nuit est une fausse économie que vous découvrirez à vos dépens.

Développement continu

Une plateforme qui ne change pas est une plateforme dépassée. La plupart des développements sur mesure aboutis nécessitent 15 à 30 % du coût initial par an en évolution continue. Ce n’est pas un échec du périmètre initial : c’est la réalité de la possession d’un logiciel.

Risque de personne-clé

La ligne la plus difficile à chiffrer et la plus facile à ignorer. Si une seule personne comprend la plateforme, vous avez un risque, pas un actif. Le réduire — documentation, travail en binôme, second ingénieur réellement formé — a un coût, mais il est inférieur à celui de l’alternative. Prévoyez-le explicitement, sinon vous le paierez en imprévu.

La vision à trois ans

Prenons un développement à 200 000 £. Un total réaliste sur trois ans, avec une feuille de route modérée et un support en heures ouvrées, se situe autour de 520 000 à 700 000 £ une fois la stabilisation, l’infrastructure, la maintenance des dépendances, l’exploitation et les évolutions continues intégrées.

Ce n’est pas un argument contre le développement sur mesure. C’est le chiffre à comparer à l’alternative, ce qui est précisément l’objectif de l’exercice.

Quand il ne faut pas développer

Nous refusons régulièrement des projets sur mesure, pour les raisons suivantes :

• Un produit configurable couvre 80 % du besoin. Les 20 % restants justifient rarement de tout posséder indéfiniment.
• Personne en interne ne peut en assurer la responsabilité. Un logiciel sur mesure sans propriétaire interne devient inévitablement un risque non maintenu, quelle que soit sa qualité initiale.
• Les besoins évoluent encore. Développer sur une cible mouvante revient à payer deux fois. Prototypagez d’abord sur une solution légère.
• Le coût sur trois ans dépasse la valeur créée. Faites ce calcul avant de lancer le projet, pas en deuxième année.
• Ce n’est pas votre différenciateur. Développez ce qui fait votre valeur ; achetez ce dont tout le monde a besoin.

La meilleure raison de développer est l’inverse : le logiciel est le cœur de l’activité, ou il porte un avantage concurrentiel que personne ne propose en standard. C’était le cas pour Hotelogix (SaaS de gestion hôtelière) et Dad.Live : dans chaque cas, le produit était l’activité, pas un support annexe.

Questions à poser pour tout devis

1. Qu’est-ce qui est exclu ? La question la plus instructive à poser : la réponse révèle l’expérience de l’équipe.
2. Pour quelles intégrations avez-vous réellement vu l’API ? Toute intégration non vue reste une estimation, pas un prix.
3. Que comprend la passation — documentation, procédures d’exploitation, décisions d’architecture, un environnement local prêt pour un nouvel ingénieur ?
4. Qui détient le code, les dépôts, les comptes cloud et les noms de domaine ? Demandez-le avant de signer, pas au moment de partir.
5. Quel est le modèle de support après la mise en ligne, et à quel coût ?
6. Que feriez-vous différemment avec un budget réduit de 30 % ? La réponse indique ce qu’ils jugent essentiel.

Si vous souhaitez un modèle sur trois ans construit selon vos propres besoins, nos équipes Node.js et full-stack interviennent en amont du projet, et notre pratique de développement full-stack couvre les aspects de propriété non inclus dans le devis de réalisation.

Modélisez avant de vous engager

Envoyez-nous votre cahier des charges et nous établirons la projection sur trois ans — y compris les cas où la recommandation honnête est d’acheter plutôt que de développer. Contactez notre équipe : réponse sous un jour ouvré.