Ce que coûte un SaaS après le lancement, quand plus personne ne regarde

Semaine 1 du projet Optimo France, fin avril 2026. Le projet démarre le 18, et la première chose que je fais n’est pas une fonctionnalité : c’est monter Prisma de la version 6 à la 7. Six fix Docker en huit jours. Pendant ces huit jours, le changelog du produit n’a pas bougé d’une ligne.

Personne n’avait rien demandé. Ni le client, ni moi. Une brique du projet a changé de version majeure, et il a fallu la suivre. C’est ça, la maintenance d’un produit en production : du temps que tu paies sans qu’il apparaisse nulle part.

Cet article parle de ce temps-là. Pas de ta facture d’hébergement, que j’ai déjà chiffrée dans ce que coûte vraiment ton infra.

Un produit livré ne se conserve pas. Il se maintient, ou il se dégrade pendant que tu regardes ailleurs.

Six jours de fix Docker pour une version d’ORM qui n’a rien demandé

Un ORM, c’est la couche qui parle à ta base de données à la place du code. Quand elle passe d’une version majeure à la suivante, ce n’est pas un bouton « mettre à jour » : c’est une chaîne de choses qui se décalent, la génération du client, l’image Docker, les tests.

Sur Optimo, ce bump a mangé six correctifs Docker étalés sur huit jours. Et ce n’était pas isolé. Le 16 mai, le découpage du dépôt en monorepo a touché 382 fichiers d’un coup, avec 709 tests verts à l’arrivée, mais deux crashs mémoire du build dans la même journée. Le premier jour de mise en place de la CI/CD, neuf correctifs de suite.

Le truc, c’est que rien de tout ça ne se voit côté client. Il y avait déjà des utilisateurs, le produit facturait, et ces journées-là n’ont produit aucun écran nouveau. Compte-les comme des jours de calendrier perdus sur ta roadmap : c’est exactement ce qu’ils sont.

C’est aussi pour ça que je choisis mes briques en fonction de leur rythme de sortie de versions, pas seulement de leur confort au premier jour. J’en parle côté décisions dans choisir son architecture technique.

Ton build peut changer pendant que ton code ne bouge pas

Sur whispee, mon projet de messagerie chiffrée, j’ai construit deux fois la même application, sans modifier une ligne. La première fois avec Node 22.21, la seconde avec Node 22.23. Deux patchs mineurs d’écart sur le moteur qui fait tourner le code. J’ai obtenu deux fichiers JavaScript différents en sortie.

Alors, est-ce que c’était grave ce jour-là ? Non, ça marchait. Le problème vient plus tard. Le jour où un bug apparaît en production, tu commences par regarder l’historique des modifications, tu n’y trouves rien, et ton diagnostic repart de zéro. Une journée d’investigation qui aurait pu être une demi-heure.

Toujours sur whispee, j’ai passé trois commits à chercher pourquoi un build échouait. La cause était un composant du compilateur Rust, rust-src, absent de la machine. Le message d’erreur ne le nommait pas. Il pointait ailleurs.

Ce genre de temps-là n’apparaît sur aucune facture d’outil. Il apparaît sur la tienne, en heures de développeur, et c’est la première chose qu’un forfait de support « incidents » exclut sans le dire :

• une mise à jour de dépendance qui n’est demandée par personne ;
• un diagnostic qui n’aboutit pas à un correctif de code ;
• une recompilation d’environnement après un changement de runtime ;
• une lecture de changelog pour savoir si tu es concerné.

Si un contrat de TMA ne nomme pas ces quatre lignes, il ne les couvre pas.

Une CVE qui tombe sur une dépendance que tu n’as pas choisie cette semaine

Une CVE, c’est une faille de sécurité publiée publiquement, avec un identifiant. Quand elle touche une brique de ton produit, tu apprends son existence en même temps que tout le monde, y compris ceux que ça intéresse.

Sur une application que je maintiens, une injection SQL a été publiée sur la couche base de données que le projet utilisait, drizzle-orm en 0.43.1 (GHSA-gpj5-g38j-94v9). Sur Optimo, j’ai dû forcer des versions corrigées sur trois autres briques — fast-uri, hono, postcss — pour la même raison.

Le coût, ce n’est pas le patch. Un patch de dépendance, c’est souvent une heure, tests compris. Le coût, c’est la fenêtre entre le jour où l’avis est publié et le jour où quelqu’un le lit. Si personne ne surveille, cette fenêtre dure jusqu’au prochain développement — soit des semaines pendant lesquelles ton application tourne avec une faille dont la description est en ligne, en français, avec le numéro de version concerné.

Moi je regarde les avis de sécurité des briques de mes projets chaque semaine, sur le même créneau. Ça prend une vingtaine de minutes quand il n’y a rien, et c’est le genre de point à trancher avant de signer, pas après — j’en ai fait un critère dans choisir ses prestataires.

Huit migrations qui n’ont jamais existé

Sur une application que j’ai reprise en cours de route, la commande qui applique les modifications de base de données annonçait un succès complet. En la rejouant sur une base vide, 13 fichiers sur 36 échouaient, 11 tables sur 25 manquaient à l’arrivée, et huit migrations référencées n’avaient jamais existé.

L’hébergement en place n’offrait aucune sauvegarde. Autrement dit, cette chaîne de migrations était le seul chemin pour reconstruire la base en cas de perte, et elle ne fonctionnait pas. Le produit, lui, tournait très bien ce jour-là.

Une semaine entière de reprise, zéro fonctionnalité livrée au bout. Elle sert juste à savoir sur quoi on marche — et c’est du temps que personne ne provisionne, parce qu’il ne produit rien de visible.

Du coup, sur asap.cool, je fais l’inverse depuis septembre 2026 : chaque semaine, je restaure une sauvegarde pour de vrai et je vérifie qu’elle remonte. Ça ne produit rien. Ça ne se vend pas. C’est exactement le temps que personne n’avait pris sur l’application d’avril, et qui a fini par coûter une semaine à quelqu’un d’autre.

Bird passe en maintenance, et c’est mon produit qui perd une fonctionnalité

Sur asap.cool, les signataires recevaient un code par SMS pour valider un document. Le fournisseur qui envoyait ces SMS, Bird, est passé en maintenance. Pas mon code, pas mon serveur, pas ma décision.

J’ai retiré l’option de l’interface. Le choix était entre une fonctionnalité en moins et des signataires bloqués devant un code qui n’arrive pas. Une fonctionnalité retirée se réactive ; un utilisateur qui n’arrive pas à signer son devis appelle son commercial et le dossier s’arrête là.

C’est la partie de la maintenance que personne n’anticipe : les décisions produit que tu ne prends pas. Un fournisseur change ses règles, un autre déplace un champ dans son API — ça m’est arrivé côté paiement, je le raconte dans intégrer Stripe en production — et ton planning de la semaine est réécrit par quelqu’un que tu n’as jamais rencontré.

Ce que cet article ne couvre pas : la facture

Tout ce qui précède se compte en jours de développeur. Il existe une deuxième colonne, celle qui arrive par mail avec un montant dessus : le disque plein, les minutes de CI épuisées, la sauvegarde impossible à restaurer, le trafic sortant facturé à 390 % de ce que j’avais prévu. Elle est chiffrée et datée dans ce que coûte vraiment ton infra.

Les deux se cumulent, et seule la deuxième figure dans les prévisionnels que je vois passer quand un fondateur me montre son budget — cadrage que je détaille aussi dans définir un MVP.

Au passage, tu verras beaucoup d’articles avancer « 15 à 25 % du coût de développement par an » pour la maintenance. C’est le chiffre que les blogs d’agence se repassent entre eux sans jamais citer l’étude qui le mesure. Je ne m’en sers pas pour budgéter, et les travaux académiques auxquels il renvoie donnent des écarts allant de 60 % à plus de 90 % du coût total. Prends-le pour ce qu’il est : une rumeur de secteur.

Ce que je fais, moi

Je ne vends pas un forfait de maintenance avec un nombre de tickets dedans. Ce que je fais chaque semaine pour mes clients, c’est lire les avis de sécurité des briques qu’ils utilisent, regarder quelles versions ont bougé, restaurer une sauvegarde pour vérifier qu’elle remonte, et arbitrer ce qui doit être patché tout de suite. Le drill hebdomadaire d’asap.cool, c’est la même chose appliquée à mon propre produit — je ne demande pas à un client une discipline que je ne tiens pas chez moi.

Si tu payes déjà quelqu’un pour la maintenance de ton produit et que tu ne sais pas si ce temps-là est dedans, on peut en parler trente minutes et regarder ce que dit ton contrat.