« Et après la mise en ligne, qu'est-ce qui se passe ? » C'est la question qui vient toujours en fin d'atelier de cadrage, et c'est la bonne. Un SaaS livré aujourd'hui doit tourner correctement dans 5 ans, recevoir ses mises à jour de sécurité, encaisser les évolutions des navigateurs et des bibliothèques, et continuer à servir ses utilisateurs sans incident silencieux. C'est précisément ce que couvre la maintenance SaaS que j'inclus systématiquement dans mes contrats. Voici en clair ce qui est dans le périmètre, ce qui n'y est pas, et pourquoi cette frontière est dans votre intérêt.
Pourquoi 5 ans de maintenance incluse, et ce que ça veut dire concrètement
Quand je livre un SaaS sur-mesure, le contrat inclut 5 ans de maintenance. Ce n'est pas un argument commercial gratuit : c'est aligné sur la durée de support des composants techniques que j'utilise. Une version Long Term Support de Symfony est supportée 4 ans (3 ans de bugs + 1 an de sécurité). Une version stable de Debian est supportée 5 ans (3 ans de support standard + 2 ans de Debian LTS), jusqu'à 10 ans avec un contrat Extended LTS. MariaDB LTS est supportée 5 ans. Un cycle de 5 ans, c'est donc la durée de vie naturelle d'une stack soignée.
Concrètement, sur cette période, je m'engage à ce que votre SaaS reste fonctionnel, sécurisé et conforme. Ça couvre la correction de bugs, les mises à jour de sécurité, la surveillance opérationnelle et le support utilisateur courant. Ça ne couvre pas l'ajout de nouvelles fonctionnalités - j'y reviens plus bas.
Ce qui est inclus dans la maintenance SaaS
Voici, en clair, ce que couvre le contrat de maintenance pendant les 5 ans qui suivent la mise en production.
| Domaine | Inclus dans la maintenance | Exemple concret |
|---|---|---|
| Maintenance corrective | Correction des bugs identifiés post-livraison | Un calcul de TVA arrondi à l'envers, un export PDF qui plante sur certains caractères |
| Mises à jour Composer | Bumps de versions Symfony LTS, bundles, librairies PHP | Montées de version Symfony LTS, Twig, Doctrine ORM, patchs de sécurité |
| Mises à jour npm/yarn | Stimulus, Turbo, dépendances front, lockfiles régénérés | Application des CVE remontées par npm audit |
| Mises à jour OS et serveur web | Debian stable, nginx, PHP-FPM, MariaDB, certificats TLS | Renouvellement Let's Encrypt automatisé, patchs noyau Linux mensuels |
| Monitoring | Surveillance disponibilité, espace disque, logs d'erreur, certificats | Alerte au moindre code 500 récurrent, monitoring serveur Zabbix et erreurs applicatives Bugsink |
| Sauvegardes et restaurations | Sauvegardes automatisées chiffrées, test de restauration semestriel | Règle 3-2-1 maintenue dans la durée |
| Support utilisateurs courant | Réponse aux questions d'usage, accompagnement de l'admin client | « Comment réinitialiser le mot de passe d'un utilisateur ? » par email |
Le détail de la procédure d'audit cyber qui complète cette maintenance est documenté dans mon audit cybersécurité TPE. Pour la conformité réglementaire associée, mon article RGPD SaaS : checklist 2026 détaille les obligations à maintenir pendant l'exploitation.
Ce qui n'est pas inclus : les évolutions fonctionnelles
La maintenance ne couvre pas les évolutions fonctionnelles : toute demande qui ajoute, modifie ou retire une fonctionnalité par rapport au périmètre livré initialement. Ces demandes sont traitées sur devis dédié.
- Nouveau module métier : ajout d'un module facturation, d'un connecteur comptable, d'un nouveau type de rapport
- Intégration tierce : connexion à un nouveau CRM, un nouveau service de paiement, une API externe
- Nouvelle fonctionnalité majeure : ajout du multi-langue, d'un mode hors-ligne, d'une application mobile
- Refonte d'interface : redesign UX, refonte du back-office, ajout d'un nouveau parcours utilisateur
- Migration de données : import depuis un ancien système, restructuration du modèle de données
Chaque évolution est cadrée comme un mini-projet : périmètre, livrables, planning, prix forfaitaire. C'est la même méthodologie que pour le projet initial, simplement appliquée à un incrément.
Pourquoi cette dichotomie : budget maîtrisé sans facture surprise
Cette frontière nette entre maintenance (forfait inclus) et évolution (devis dédié), ce n'est pas un détail contractuel. C'est une protection mutuelle.
Pour vous, client : votre budget annuel de maintenance est connu et constant. Vous savez exactement ce que vous payez, sans mauvaise surprise quand un patch de sécurité Symfony arrive. Vous gardez la maîtrise des évolutions : chacune est arbitrée selon sa valeur métier et son coût, sans pression.
Pour moi, prestataire : je m'engage à un périmètre clair, sans dérive de scope. Cela me permet de tenir un coût opérationnel raisonnable et de ne pas répercuter d'incertitudes dans le forfait. C'est le principe du fixed scope, fixed price appliqué à la maintenance.
Je le vois sur les SaaS que je maintiens depuis plusieurs années : les éditeurs qui ont ce cadre contractuel clair avancent plus vite parce qu'ils ne confondent jamais « bug » et « évolution ». Les autres passent du temps à arbitrer chaque demande, parfois en se fâchant avec leur prestataire. La clarté contractuelle, c'est un investissement de tranquillité.
Au-delà de 5 ans : reconduction ou transfert
Cinq ans, c'est long. Au terme du contrat initial, deux options s'ouvrent.
Option 1 : reconduction. Si la relation fonctionne, on signe un nouveau contrat de maintenance. Le tarif est réévalué selon la stack en vigueur (les versions Symfony et Debian auront avancé) et selon la complexité accumulée du SaaS (tenants, modules, volumétrie). On peut aussi profiter de cette échéance pour planifier une refonte ciblée des parties les plus anciennes - c'est souvent le bon moment pour migrer une stack vieillissante.
Option 2 : transfert vers une équipe interne ou un autre prestataire. Mes projets sont conçus pour être repris. Code lisible, documentation à jour, dépôt Git propre, infrastructure Docker reproductible, choix techniques mainstream (Symfony LTS, MariaDB, Debian stable). Je transmets toute la chaîne et j'accompagne la transition pendant 1 à 3 mois selon le besoin. C'est une garantie d'indépendance pour l'éditeur : aucun verrouillage propriétaire.
Cadrer la maintenance de votre SaaS
Une maintenance SaaS bien cadrée, c'est ce qui transforme un projet livré en service durable. Les 5 ans inclus dans mes contrats ne sont pas un argument commercial : c'est l'horizon naturel des stacks LTS sur lesquelles je m'appuie. Et la frontière nette avec les évolutions fonctionnelles protège votre budget autant que la qualité de mon engagement.
Si vous portez un projet SaaS ou que vous reprenez la maintenance d'un SaaS existant, je propose un audit du contrat actuel et un cadrage du périmètre cible. Comme tous mes accompagnements, le périmètre est défini sur devis personnalisé après un échange initial gratuit de 30 minutes. Pour comprendre comment la maintenance s'inscrit dans le cycle complet d'un projet, l'étape 6 « Maintenance et évolution » de mon guide du développement SaaS sur-mesure détaille la méthodologie. Le formulaire de contact permet de prendre date.
