Une application livrée en production n'est pas un produit fini. Maintenance corrective, mises à jour de sécurité, évolutions fonctionnelles : voilà ce qu'il se passe après la mise en ligne. Voici comment cadrer ces postes pour éviter qu'ils ne deviennent un trou noir budgétaire.
Maintenance ≠ évolutions
Confusion fréquente : maintenance et évolutions sont deux choses différentes qui se cadrent différemment.
| Aspect | Maintenance | Évolutions |
|---|---|---|
| Nature | Corrections, mises à jour, monitoring | Nouvelles fonctionnalités, refontes partielles |
| Récurrence | Continue, prévisible | Ponctuelle, à la demande |
| Facturation | Forfait mensuel ou temps passé | Au temps passé ou par sprints |
| Budget annuel | 15-30 % du coût du build | Variable selon ambitions |
| Décision | Plus technique (dette technique, sécurité) | Plus métier (besoin client, opportunité) |
La maintenance : ce que ça couvre
- Mises à jour de dépendances : Node, React, Postgres, packages tiers. Pour rester sécurisé.
- Corrections de bugs résiduels : ce qui apparaît en production après la garantie.
- Monitoring : surveillance erreurs (Sentry), performances, sauvegardes, alertes.
- Ajustements mineurs : textes, labels, micro-UX, sans logique métier nouvelle.
- Maintenance préventive : refactor ciblé, nettoyage de dette, optimisations.
Les évolutions : comment les cadrer
Distinguer urgent vs confortable
Vrai bug bloquant : urgent, à corriger sous le contrat maintenance. Envie de nouvelle feature : à arbitrer, à chiffrer, à priorisé.
Backlog priorisé
Les évolutions s'empilent dans un backlog visible (Notion, Linear, GitHub Issues). Priorisation régulière : impact x effort. Les petites évolutions à fort impact passent en premier.
Sprints courts ou temps passé
Pour les évolutions régulières : sprints de 1-2 semaines avec forfait fixe. Pour les évolutions ponctuelles : temps passé avec estimation préalable.
Le contrat type
- Périmètre maintenance : ce qui est inclus, ce qui ne l'est pas (refonte majeure exclue).
- SLA : délai de réponse aux incidents (24h ouvré, 4h critique, etc.).
- Forfait ou taux horaire clairs.
- Modalités pour évolutions : temps passé, sprints, validation préalable.
- Procédure de fin de contrat : transmission, accès, doc.
Pour cadrer la maintenance et les évolutions de votre app, prévoyez un premier appel. Voir aussi coûts d'hébergement et maintenance.
Questions fréquentes
Quel est le coût typique de maintenance d'une app ?
Entre 15 et 30 % du coût du build par an. Pour une app à 15 000 €, compter 2 500-4 500 € par an de maintenance, soit ~200-400 €/mois lissé. Ça couvre : mises à jour de dépendances, corrections de bugs résiduels, monitoring, sauvegardes. Pas les nouvelles fonctionnalités.
Forfait mensuel ou au temps passé ?
Forfait mensuel sur les apps stables avec besoin régulier. Au temps passé sur les apps moins actives. Pour les évolutions fonctionnelles, le temps passé ou des sprints courts sont plus naturels que le forfait.
Que se passe-t-il si on n'entretient pas l'app pendant 1 an ?
Dépendances obsolètes ou vulnérables, intégrations tierces qui changent et cassent, erreurs accumulées sans correction, base de données qui dégrade en performance. À 12-18 mois sans maintenance, des plantages partiels deviennent fréquents. À 24-36 mois, une réécriture est souvent nécessaire.