Coût de maintenance logicielle : la ligne du budget que tout fondateur non technique sous-estime

Un guide direct pour fondateur non technique sur ce que vous payez réellement après le lancement, pourquoi « 15 % du build » est la mauvaise règle pour les startups en phase initiale, et le diagnostic en cinq questions pour estimer votre vrai chiffre avant qu’il n’arrive.

Un fondateur avec qui nous avons travaillé l’an dernier a livré un MVP propre à 86 000 USD. Checkout Stripe, un tableau de bord admin, une petite application mobile. Il a bouclé son tour seed à temps, dit au board que le risque technique était derrière lui. Neuf mois plus tard, il nous a transféré une facture de 14 200 USD et nous a demandé ce qui s’était passé.

Ce qui s’était passé était ordinaire. AWS a déprécié le runtime Node 14 sur lequel tournaient ses Lambdas. Son fournisseur de paiement a envoyé un préavis de 60 jours sur un changement de signature de webhook qu’il n’a pas su lire. Le target SDK Android allait passer sous le minimum du Play Store, ce qui aurait retiré l’application de la boutique entièrement. Sentry, ajouté sur un plan gratuit au mois un, était discrètement passé sur un tier à 79 USD par mois. Et son seul développeur était parti pour un autre poste trois mois plus tôt, donc le fondateur a dû faire venir un contractor à 190 USD par heure pour tout courser.

Rien de tout cela n’a été une surprise pour quiconque livre du logiciel pour vivre. Tout cela a été une surprise pour lui.

Le coût de maintenance logicielle est le coût opérationnel récurrent du maintien d’un système vivant, sécurisé et utile après le lancement. Il est séparé du coût de build. Il n’est pas 15 % de quoi que ce soit de manière significative. Et pour les startups en phase initiale, c’est la ligne la plus systématiquement sous-estimée du budget pendant les dix-huit premiers mois d’un produit réel en production.

Ce texte est un framework budgétaire pour fondateur non technique. Il nomme les trois choses que vous payez réellement, explique pourquoi la règle du pourcentage standard échoue à votre stade, liste les coûts cachés que personne ne vous chiffre, et vous donne un diagnostic en cinq questions pour estimer votre vrai chiffre avant de signer quoi que ce soit.

Les trois choses que vous payez réellement

Tout devis crédible de maintenance logicielle couvre une combinaison de trois catégories. La plupart des devis ne les séparent pas. La plupart des fondateurs, par conséquent, ne savent pas laquelle ils achètent en quantité suffisante.

Garder les lumières allumées

Le travail qui doit avoir lieu pour que le produit reste vivant, avec ou sans nouvelle fonctionnalité. Patches de sécurité. Mises à jour de dépendances. Upgrade de runtime quand le cloud provider déprécie celui que vous utilisez. Renouvellement de certificats. Vérification de backup. Migration quand Stripe ou son équivalent local change un contrat de webhook. Changements cassants côté navigateur et OS mobile.

Ce travail n’est pas négociable. Si vous le sautez, le produit finit par casser d’une façon plus coûteuse à réparer que le travail ne l’aurait été. Le fondateur ci-dessus a payé 14 200 USD en un mois en grande partie parce que neuf mois de garder-les-lumières-allumées sautés se sont accumulés d’un coup.

Pour un produit SaaS ou marketplace typique de pré-A à Série A avec un à trois services en production, budgétez 8 à 25 heures par mois de temps d’ingénierie ciblé. Cela correspond à environ 1 500 à 5 000 USD par mois à des tarifs raisonnables de contractor.

Petits correctifs

Bugs en production. Edge cases que la bêta n’a pas attrapés. Un client précis n’arrive pas à se connecter. Un export génère un CSV mal formé. Un décalage de fuseau d’une heure casse un rapport quotidien. Le formulaire d’inscription rejette un format d’e-mail réel.

La plupart des fondateurs non techniques regardent cette catégorie et y voient « des choses qui tournent mal ». Il est plus exact d’y voir le bruit irréductible d’un produit réel utilisé par de vrais usagers. Un produit avec zéro petits correctifs est un produit que personne n’utilise.

Le volume ici monte avec les utilisateurs actifs quotidiens et la cadence de release, pas avec la taille du code. Un produit B2B avec 40 clients génère deux à six petits correctifs par mois. Un produit B2C avec 5 000 actifs en génère vingt. Budgétez 15 à 40 heures par mois pour un produit en phase initiale. Les fondateurs sous-estiment cette catégorie de moitié parce que les tests qu’ils ont faits eux-mêmes avant le lancement ont fait remonter une fraction de ce que les vrais utilisateurs vont faire remonter.

Faire évoluer

Le travail qui n’est pas tout à fait de la maintenance et pas tout à fait du nouveau produit. C’est garder le logiciel à la forme de votre business pendant que le business change. La page de pricing lancée avait trois tiers ; l’opération commerciale que vous utilisez vraiment en a quatre. L’onboarding supposait du self-serve ; vos vrais clients sont des démos guidées. Le tableau de bord admin fonctionne pour un opérateur ; vous en avez maintenant trois et chacun veut des filtres différents.

Si vous ne budgétez pas pour faire évoluer, chaque changement de business devient un débat : on le fait maintenant ou on attend la prochaine grosse release. Ce débat coûte plus cher que le travail. Pour une startup qui itère encore sur son modèle, budgétez 20 à 60 heures par mois pendant les dix-huit premiers mois après le lancement, en décroissant à mesure que le modèle se stabilise.

Ces trois catégories s’additionnent. Elles ne se substituent pas l’une à l’autre. Un devis qui ne les nomme pas est un devis que vous ne pouvez pas mettre sous pression.

Pourquoi la règle des « 15 % du coût de build » est fausse pour les fondateurs

Demandez à internet combien coûte la maintenance logicielle et on vous répond par un pourcentage. Quinze pour cent du build. Vingt. Parfois trente. Cette règle vient du lifecycle management de logiciel d’entreprise, où le périmètre est stable, la base d’utilisateurs bornée, et l’essentiel du travail de maintenance est du garder-les-lumières-allumées plus quelques patches mineurs sur un horizon de cinq à dix ans.

Ce monde n’est pas votre monde.

Pendant les dix-huit premiers mois après le lancement, votre périmètre n’est pas stable. Vous cherchez encore le product-market fit. Votre bucket de faire-évoluer est parfois plus gros que votre coût de build parce que chaque conversation client redessine la surface. Votre base d’utilisateurs grossit d’un ordre de grandeur par trimestre, ce qui veut dire que chaque bug de petits-correctifs apparaît devant dix fois plus de gens chaque mois. Votre stack est plus jeune et moins stable qu’un codebase d’entreprise, donc le churn de dépendances frappe plus fort. Et votre équipe est plus petite, donc personne n’absorbe un e-mail de dépréciation sans le facturer.

Pour une startup typique de seed à Série A, le coût annuel réel de maintenance logicielle en années un et deux tombe souvent entre 40 % et 80 % du coût original de build, pas 15 %. À l’année trois, à mesure que le périmètre se stabilise, ce chiffre peut redescendre vers 20 % à 30 % si l’ingénierie a été bien faite. Si elle ne l’a pas été, le chiffre de la deuxième année est encore plus haut parce que chaque raccourci pris au build est venu réclamer son dû.

La règle des 15 % n’est pas un mensonge. C’est une mesure prise dans un autre système, appliquée au vôtre, et c’est l’un des chiffres empruntés les plus coûteux du logiciel en phase initiale. Si un fournisseur vous chiffre un forfait de maintenance à 15 % du coût de build, demandez-lui laquelle des trois catégories est couverte. Il vous chiffre presque certainement uniquement le garder-les-lumières-allumées.

Les lignes cachées que personne ne vous chiffre

Quand vous demandez à un fournisseur un devis de maintenance, vous obtenez un chiffre qui inclut ses heures d’ingénierie. Vous n’obtenez presque jamais le reste de la facture.

Dépendances SaaS tierces. Sentry, Postmark, Datadog, Auth0, Twilio, Segment, Mixpanel, Stripe Billing, Plaid, votre CDN, votre fournisseur d’e-mail transactionnel, votre captcha, votre planificateur de tâches. La plupart ont un tier gratuit dans lequel vous tenez au lancement et un tier réel dans lequel vous grandissez vers le mois quatre. Le burn mensuel cumulé pour un produit Série A typique est de 400 à 2 000 USD, et presque rien de cela n’apparaît dans votre devis initial.

Croissance du coût d’infrastructure. Votre facture AWS ou GCP au jour 1 est petite parce que votre trafic est petit. La croissance est rarement linéaire ; une requête qui marchait bien sur 1 000 lignes devient un timeout quotidien sur 100 000. Le fondateur qui saute une revue trimestrielle d’infra est le fondateur dont la facture cloud a soudain triplé en octobre.

Changements de prix d’API chez vos dépendances. OpenAI augmente le prix des modèles. Stripe prend un pourcentage plus élevé sur un moyen de paiement dont vous dépendez. Votre fournisseur de géocodage resserre le rate limit du plan dans lequel vous étiez grandfathered. Aucun de ces points n’est négociable sur le moment ; tous doivent être absorbés ou contournés par du travail d’ingénierie.

Couverture d’astreinte. Si votre produit doit être en ligne à 2 h du matin et que la seule personne qui connaît le système dort, vous n’avez pas un produit maintenu, vous avez un produit fragile. L’astreinte est soit une ligne explicite (un fractional CTO avec une fenêtre de réponse définie, un prestataire SRE externe, un contractor sous retainer), soit un coût implicite qui apparaît sous la forme de votre développeur unique qui se grille en silence.

Réponse à incident de sécurité. La probabilité annuelle d’un événement de sécurité qui demande du travail réel n’est pas négligeable, même pour des petits produits. Une clé d’API exposée sur GitHub. Une fuite de credential. Une règle de WAF qui bloque un vrai client. Un DDoS qui vous coûte un week-end. La réponse se paie en heures qui n’existaient pas dans votre plan de maintenance.

Dépréciations de tiers. C’est ce qui a attrapé le fondateur ci-dessus. Les cloud providers déprécient des runtimes. Les fournisseurs de paiement changent des signatures de webhook. Les fournisseurs d’e-mail durcissent DMARC. Les vendors d’OS mobile relèvent le target-SDK floor. Aucun n’est une urgence le jour où l’e-mail arrive ; tous deviennent une urgence six mois plus tard quand personne n’a fait le suivi.

Un budget de maintenance qui n’a pas une ligne explicite pour chacun de ces éléments n’est pas un budget. C’est une supposition.

Cinq questions pour estimer votre vrai coût de maintenance

Avant de signer le moindre accord de maintenance, ou de décider quelle capacité d’ingénierie interne garder disponible, travaillez honnêtement ces cinq questions avec votre développeur ou votre fournisseur. Ça prend une après-midi. Ça vous évitera le choc de la deuxième année.

1. Combien de services en production faisons-nous tourner, et quelle est la cadence de patch de chacun ? Deux services avec une mise à jour de dépendances hebdomadaire est une facture différente d’un monolithe avec une mise à jour annuelle. Comptez-les, listez la cadence, demandez qui est responsable de chaque.

2. Quelle est notre facture mensuelle cumulée sur tous les SaaS, infra et API tiers dont nous dépendons, et lesquels ont des tiers gratuits que nous allons dépasser dans les six prochains mois ? Sortez chaque reçu. Listez chaque service. Marquez ceux qui scalent avec l’usage. La liste est toujours plus longue que ce que le fondateur croit.

3. Qui est d’astreinte, quel est l’engagement de temps de réponse, et combien cela coûte ? Si la réponse est « notre développeur unique quand il voit le message », vous avez votre réponse. Estimez ensuite ce qu’il en coûterait de rendre cela moins fragile.

4. Quelle est notre cadence de release prévue et la roadmap des deux prochains trimestres, et quelle proportion est du travail de faire-évoluer sur des surfaces existantes vs. du produit réellement nouveau ? Si 60 % de la roadmap consiste à réécrire l’onboarding, le checkout et l’admin, votre bucket de faire-évoluer est énorme et doit être budgété en conséquence.

5. Quel est notre pire scénario sur les douze prochains mois, et combien coûterait la récupération ? Le développeur unique part. Un gros client déclenche une feature qui touche à tout. Le cloud provider déprécie un runtime avec 90 jours de préavis. Choisissez les deux les plus probables. Chiffrez la récupération. Ajoutez un buffer.

Le fondateur qui sait répondre à ces cinq questions a un vrai chiffre de maintenance. Le fondateur qui ne sait pas a un souhait.

Comment budgéter la maintenance dès l’année un : la répartition 30-50-20

Pour chaque dollar du budget annuel de maintenance, allouez 30 % au garder-les-lumières-allumées, 50 % aux petits-correctifs et faire-évoluer combinés, et 20 % au buffer. Le buffer n’est pas du mou ; c’est la ligne qui absorbe les dépréciations de tiers, l’incident de sécurité et la facture SaaS surprise. Le fondateur qui ne budgète pas de buffer le paie quand même, mais en panique.

En valeur, pour un produit SaaS ou marketplace typique de pré-A à Série A, cela donne un budget de maintenance de l’année un dans la fourchette 30 000 à 90 000 USD, en plus du coût original de build. La fourchette reflète deux facteurs réels : la part de votre produit déjà en ligne (plus de surface vivante, plus de coût), et la stabilité de votre modèle de business (plus de changement, plus de travail de faire-évoluer). Si votre build a coûté 80 000 USD et que votre modèle bouge encore chaque trimestre, attendez-vous au haut de la fourchette. S’il a coûté 200 000 USD et que le modèle est calé, vous pouvez être en bas en proportion.

C’est un chiffre de départ à confronter au diagnostic ci-dessus, pas une réponse finale. C’est le diagnostic qui donne la réponse finale.

Comment négocier la maintenance dans le contrat de développement logiciel

Le bon moment pour négocier la maintenance est avant de signer le contrat de build, pas après que le premier e-mail de dépréciation soit arrivé. Nous avons écrit sur la structure de contrat dans notre texte sur forfait vs régie ; la clause de maintenance est la partie que la plupart des fondateurs sautent en première lecture.

Trois choses sur lesquelles il faut insister avant de signer.

Un périmètre de maintenance nommé, avec les trois catégories séparées. Pas « support continu ». Garder-les-lumières-allumées comme une ligne avec une fenêtre de réponse définie, petits-correctifs comme deuxième ligne avec un pool d’heures mensuelles, faire-évoluer comme troisième ligne avec un taux horaire séparé. Si le fournisseur refuse de les séparer, vous achetez un seul seau et vous recevez la catégorie qu’il a envie de servir ce mois-là.

Le code source à votre nom dès le jour un, et l’accès à chaque service tiers sur vos comptes, pas sur les siens. Cela n’est pas négociable. La maintenance est impossible à changer de fournisseur si le code vit sur son GitHub et que le compte AWS est sur sa carte d’entreprise. Notre texte sur les software houses couvre la posture plus large sur la responsabilisation des fournisseurs.

Une clause de transition de 30 jours. Si vous décidez de ramener la maintenance en interne ou chez un autre fournisseur, vous avez 30 jours de handover payé avec documentation, transfert de credentials et un dernier sprint de mise à jour de dépendances. Sans cette clause, changer de fournisseur vous coûte une réécriture forcée.

Pour la question plus large de savoir qui supervise la maintenance quand vous n’avez pas de CTO, notre texte sur les fractional CTO nomme les quatre alternatives. Pour la décision interne vs externalisation spécifiquement sur la maintenance, notre texte sur interne vs externalisation donne le framework à trois axes. Version courte pour la maintenance : externaliser le garder-les-lumières-allumées est presque toujours la bonne décision en phase initiale ; ramener les petits-correctifs en interne commence à avoir du sens quand il y a assez de volume pour justifier une personne dédiée ; faire-évoluer est la dernière catégorie à internaliser, parce que c’est là que la connaissance du business s’accumule. Le texte complet sur combien coûte développer une application est le pendant côté coût de build ; lire les deux ensemble donne l’image complète des deux premières années.

FAQ

Combien coûte la maintenance d’un logiciel ?
Pour un produit SaaS ou marketplace typique de pré-A à Série A, la maintenance annuelle tombe entre 30 000 et 90 000 USD en années un et deux, en plus du coût original de build. Ce chiffre se décompose en trois catégories : garder-les-lumières-allumées, petits-correctifs et faire-évoluer. La règle des 15 à 20 % du build que l’on trouve sur la plupart des sites d’agence est empruntée au logiciel d’entreprise et sous-estime systématiquement le coût réel pour des startups au périmètre encore mouvant.

Comment estimer le coût de maintenance d’un logiciel ?
Répondez honnêtement à cinq questions avec votre développeur ou fournisseur : combien de services en production vous faites tourner et leur cadence de patch ; la facture mensuelle cumulée de chaque SaaS, infra et API tiers dont vous dépendez ; qui est d’astreinte et à quel coût ; votre cadence de release et la part entre travail de faire-évoluer et produit réellement nouveau ; et votre pire scénario sur les douze prochains mois. Additionnez les cinq réponses, ajoutez 20 % de buffer. Quiconque vous chiffre un montant de maintenance sans travailler ces cinq entrées vous chiffre une supposition.

Quel est le pourcentage typique de coût de maintenance ?
La règle des 15 à 20 % vient du logiciel d’entreprise à périmètre stable. Pour les startups en phase initiale, la maintenance annuelle réelle en années un et deux tombe typiquement entre 40 % et 80 % du coût original de build, et redescend à 20 %–30 % à l’année trois si l’ingénierie a été bien faite. Le cadrage en pourcentage est moins utile que le cadrage en catégories ; demandez ce que vous payez, pas à quelle fraction du build cela équivaut.

Pourquoi la maintenance logicielle est-elle chère ?
Trois raisons. Le monde autour de votre logiciel ne s’arrête pas (cloud provider, processeur de paiement, vendor d’OS mobile et API tierces imposent des changements que vous devez absorber). Vos utilisateurs font remonter des bugs et des edge cases qu’aucun test interne ne trouve. Et votre business change plus vite que votre code, donc le logiciel doit être remodelé pour coller au business. La combinaison des trois est ce qui rend la maintenance plus chère que les fondateurs ne s’y attendent, et ce qui rend la règle des 15 % systématiquement basse.

Un produit vivant n’est pas un produit terminé. Le coût de l’opérer honnêtement est sa propre ligne, et les fondateurs qui le planifient dès le mois un sont les fondateurs dont l’e-mail du mois neuf parle d’un nouveau client, pas d’une facture de 14 000 USD.