Faire vivre ton produit après le lancement.

Le problème que ça règle

Le jour de la mise en production n’est pas une ligne d’arrivée. C’est le moment où le produit commence enfin à rencontrer la réalité : des utilisateurs qui font des choses imprévues, des données qui ne ressemblent pas au jeu de test, des besoins qui n’existaient pas au cadrage.

Et c’est souvent le moment où le prestataire disparaît. Le projet est livré, la facture est soldée, le contrat est terminé. Six mois plus tard, tu as un produit qui tourne, personne pour le corriger, et un bug qui coûte un client par semaine.

Ce qu’il y a réellement dans la TMA

Les corrections. Les vrais utilisateurs trouvent en deux semaines des cas qu’aucune recette n’a produits. Ce n’est pas un échec de qualité, c’est le fonctionnement normal d’un logiciel qui rencontre le monde.

La fiabilisation. Les points qu’on a acceptés comme dette pour livrer à temps, et qu’il faut reprendre avant qu’ils ne deviennent un incident : la requête qui ralentit à mesure que la base grossit, la tâche de fond sans reprise sur erreur, la sauvegarde qu’on n’a jamais tenté de restaurer.

Les évolutions. Le produit change parce que ton métier change. Chaque lot est chiffré et livré séparément, ce qui te laisse la liberté d’arrêter à n’importe quel moment sans rien laisser en chantier.

Le support. Répondre quand quelque chose ne va pas, avec un délai de réaction convenu à l’avance plutôt qu’une promesse de disponibilité permanente qu’aucun indépendant ne tient honnêtement.

Le monitoring utile, et le reste

La plupart des dispositifs de supervision échouent de la même façon : ils produisent tellement d’alertes que plus personne ne les lit, et la seule qui comptait passe inaperçue.

Je préfère peu d’alertes, toutes actionnables. Une alerte doit désigner quelque chose de cassé et suggérer quoi faire. Si elle ne mène à aucune action, elle ne devrait pas exister. Le reste — les métriques, les traces, les journaux — sert à enquêter quand un problème est signalé, pas à réveiller quelqu’un la nuit.

Et une sauvegarde ne compte pas tant qu’on ne l’a pas restaurée pour de vrai, au moins une fois, en conditions réelles.

La question du freelance seul

Tu confies un produit dont dépend ton activité à une personne. Si cette personne tombe malade, change de métier ou devient indisponible, que se passe-t-il ?

C’est une objection sérieuse et elle mérite mieux qu’une réassurance verbale. Elle se traite par construction :

• Le code est sur ton dépôt, l’infrastructure sur tes comptes. Rien ne transite par un accès qui n’appartient qu’à moi.
• La stack est délibérément banale — TypeScript, Postgres, des outils que des milliers de développeurs connaissent. Aucun framework maison, aucune astuce personnelle à déchiffrer.
• Les décisions d’architecture sont écrites : pourquoi telle structure, pourquoi ce compromis, ce qu’il ne faut surtout pas changer sans comprendre.

L’objectif n’est pas que tu ne puisses pas me remplacer. C’est que tu puisses le faire en quelques jours si tu en as besoin.

Preuve

La TMA est le domaine où les promesses sont les moins vérifiables — tout le monde jure qu’il reste. Le seul indicateur qui compte est la durée réelle.

SimplyJury a été mis en production puis a continué d’évoluer sans interruption depuis : correctifs, fonctionnalités, fiabilisation, au rythme du produit et de ses utilisateurs. Optimo France est en exploitation depuis sa mise en service, sauvegardes et tâches planifiées comprises.

Ce sont des produits que je fais encore tourner, pas des références que j’ai livrées puis quittées.