D'abord un fait rassurant et vérifiable : une application générée fige ses dépendances à la version exacte — Next, React, Prisma et les autres sont épinglés au numéro près, pas à une fourchette. Elle se réinstalle donc à l'identique dans deux ans et ne se casse pas toute seule. Ce qui demande un entretien, ce sont trois choses distinctes : les correctifs de sécurité des bibliothèques, l'hébergement, et vos propres évolutions métier. Tant que l'application vit à l'URL incluse, les deux premières ne vous coûtent rien ; le jour où vous l'hébergez vous-même ou modifiez son code, elle devient un logiciel comme un autre — et le code étant du Next.js et du Prisma standard qui vous appartient, n'importe quel développeur peut le reprendre.
Une application qui tourne ne se dégrade pas toute seule
L'intuition dit qu'un logiciel « vieillit » et finit par tomber en panne de lui-même. Ce n'est pas ce qui se passe. Le `package.json` d'une application générée épingle chaque dépendance à sa version EXACTE — pas de plage, pas de « dernière version compatible » : le numéro précis. Réinstaller l'application dans deux ans reconstruit exactement le même arbre de bibliothèques qu'au premier jour, et le code, lui, n'a pas bougé d'un octet.
Ce qui se dégrade, c'est l'environnement autour : le certificat qui expire, le serveur qu'on migre, la version de Node qu'un hébergeur retire, et surtout les correctifs de sécurité que des versions figées ne reçoivent plus. C'est une différence de nature avec « le logiciel casse », et elle change complètement ce qu'il faut prévoir.
Trois entretiens distincts, qu'on confond souvent
Le premier est la SÉCURITÉ des bibliothèques : une faille découverte dans une dépendance appelle une montée de version. C'est le seul entretien qui a une horloge, et il ne dépend pas de votre activité.
Le deuxième est l'HÉBERGEMENT : le domaine, le certificat, la base de données, les sauvegardes. Tant que l'application est servie à l'URL incluse, c'est la plateforme qui le porte — et c'est aussi la question précise à poser, ici comme à n'importe quel fournisseur : quelle est la politique de sauvegarde, et à quelle fréquence. Le jour où vous rapatriez l'application sur votre serveur, ce volet devient le vôtre.
Le troisième n'est pas de la maintenance mais du TRAVAIL : ajouter un champ, un statut, un écran parce que votre métier a changé. Celui-là ne se produit que si vous le demandez, et il se traite à sa propre échelle — c'est le sujet du guide « faire évoluer son application ».
Qui peut le faire, et pourquoi personne ne vous tient
Le code est du Next.js et du Prisma standard, exportable en archive ZIP ou poussé sur GitHub, et il vous appartient. Il n'y a ni dialecte propriétaire, ni format que seul l'éditeur sait relire : le développeur qui reprend le dossier travaille avec l'outillage qu'il connaît déjà, et c'est ce qui rend la reprise possible sans nous. C'est exactement l'inverse d'un outil fermé, où « qui maintiendra ? » n'a qu'une réponse — l'éditeur, tant qu'il existe.
La contrepartie est honnête : le jour où vous modifiez ce code vous-même, la version qui tourne cesse d'être celle que la plateforme sait régénérer. Vous gagnez la liberté complète et vous prenez l'entretien avec. Beaucoup de petites structures ne franchissent jamais ce pas, et n'en ont pas besoin — mais la porte reste ouverte, et c'est ce qui compte le jour où l'on veut la prendre.
Ce qu'il faut vraiment provisionner
Sur un logiciel développé sur mesure, la littérature du secteur met la maintenance corrective autour de 15 à 20 % du coût initial par an, et l'ensemble maintenance-évolutions à la moitié environ du coût total de possession sur cinq ans. C'est la ligne que presque personne ne budgète, et c'est elle qui transforme un projet réussi en outil abandonné trois ans plus tard.
Le calcul change quand le coût initial est petit et que l'hébergement est inclus : il n'y a rien à provisionner tant que l'application tourne telle quelle. La dépense réapparaît à deux endroits seulement — si vous rapatriez l'hébergement, ou si vous faites modifier le code. Décider en connaissant ces deux bifurcations vaut mieux que de payer une assurance contre une panne qui, sur des versions figées, n'arrive pas.