Un contrat de maintenance peut protéger votre application.
Il peut aussi recréer exactement le problème que vous vouliez éviter: dépendance, flou, délais, factures incompréhensibles, personne ne sait ce qui est inclus.
C’est le paradoxe. Une PME paie pour reprendre le contrôle avec une application métier. Puis elle signe une maintenance qui remet le contrôle chez le prestataire.
J’ai vu cette scène des deux côtés. Côté agence, avec des contrats qui rassurent mais enferment. Côté 5000.dev, avec des dirigeants qui veulent juste que leur outil continue de marcher sans transformer chaque bug en mini-projet.
Un bon contrat de maintenance d’application web ne doit pas faire peur. Il doit dire clairement: qui possède quoi, qui intervient, dans quel délai, pour quels types de problèmes, et à quel moment une demande sort de la maintenance.
Le premier point n’est pas le prix. C’est la propriété.
Avant de parler forfait mensuel, parlez propriété.
Qui possède le code ? Où est-il hébergé ? Qui a accès au dépôt Git ? Qui contrôle le serveur, le nom de domaine, les clés API, les emails, les comptes de paiement ?
Dans le corpus LinkedIn de Loïc, il y a cette histoire de Camille. Elle confie son projet à un développeur. Trois mois passent. Le dev disparaît. Le code est sur son compte GitHub perso. Les accès serveur sont à son nom. Aucune documentation exploitable. Camille ne cherche plus une fonctionnalité. Elle cherche à ne pas tout perdre.
C’est brutal, mais c’est fréquent.
Un contrat de maintenance sérieux commence donc avant la maintenance: l’entreprise doit savoir ce qu’elle possède.
Chez 5000.dev, le code source est livré. Ce point change la relation. La maintenance n’est pas une laisse. C’est une option pour continuer proprement.
Ce que le contrat doit couvrir clairement
Un contrat utile couvre les vrais risques business.
D’abord, les bugs bloquants. Si l’application empêche d’envoyer un devis, de traiter une commande, de créer un utilisateur ou de consulter une donnée critique, le contrat doit prévoir une prise en charge claire.
Ensuite, les sauvegardes. Le contrat doit dire ce qui est sauvegardé, à quelle fréquence, et comment restaurer. Une sauvegarde qui n’a jamais été testée est une phrase rassurante, pas une sécurité.
Ensuite, les accès. Qui peut intervenir ? Qui valide ? Que se passe-t-il si la personne référente est absente ? Une PME ne doit pas dépendre d’un seul compte ou d’une seule boîte mail.
Ensuite, les petites corrections. Une faute, un champ mal nommé, un affichage cassé, une règle métier minime à ajuster. Ces sujets doivent être traités vite, sans cérémonie.
Enfin, les dépendances critiques: hébergement, emails, librairies, API externes. Pas besoin de dramatiser. Il faut juste savoir ce qui peut casser et qui regarde.
Pour l’approche opérationnelle, la checklist maintenance application web complète ce point.
Ce que le contrat doit exclure sans ambiguïté
Le flou coûte cher.
Un bon contrat doit aussi dire ce qui n’est pas inclus.
Une nouvelle fonctionnalité métier n’est pas un bug. Un nouveau rôle utilisateur n’est pas forcément une “petite évolution”. Un nouveau module de reporting peut être une vraie brique. Une intégration avec un outil externe peut demander un cadrage.
Si tout passe en maintenance, deux choses arrivent.
Le client pense que tout est inclus. Le prestataire commence à compter les minutes. La relation se tend.
C’est exactement ce que 5000.dev évite avec le modèle brique par brique. Une correction reste une correction. Une demande qui crée de la valeur métier devient une nouvelle brique: 5 000 euros HT, 2 semaines de développement, un périmètre clair.
La frontière protège les deux côtés.
Méfiez-vous des contrats qui ressemblent à une agence classique
Certains contrats de maintenance sont des mini-agences classiques.
Réunion mensuelle obligatoire. Comité de suivi. Reporting. Crédit d’heures. Heures qui expirent. Tickets classés mais pas traités. On parle beaucoup de l’application. On agit peu.
J’ai dirigé une agence de 50 personnes. Je connais ces couches. Elles ont parfois du sens dans de grands projets. Elles sont souvent absurdes pour une PME qui a besoin d’une application simple, utile, maintenable.
Un contrat de maintenance pour une app de PME doit rester proportionné.
Si votre application a coûté 5 000 euros, la maintenance ne doit pas recréer une machine à 42K€ autour. Le bon niveau de process est celui qui protège l’usage, pas celui qui justifie une structure.
Le même raisonnement vaut pour le choix initial du prestataire. L’article agence forfait application détaille pourquoi le modèle économique change la relation.
Les délais doivent être réalistes, pas marketing
“Réponse sous 24h” ne veut pas dire “correction sous 24h”.
Le contrat doit distinguer:
- accusé de réception;
- diagnostic;
- correction d’un bug bloquant;
- correction d’un bug non bloquant;
- demande d’évolution.
Un dirigeant de PME a surtout besoin de savoir ce qui se passe quand l’outil bloque le travail.
La promesse utile n’est pas “tout est corrigé instantanément”. La promesse utile est: les vrais blocages sont vus vite, qualifiés vite, et traités sans tunnel administratif.
C’est aussi pour ça que l’application doit rester simple. Une app construite brique par brique, avec un périmètre clair, se maintient mieux qu’un produit gonflé pendant 12 mois.
Le contrat doit préserver la liberté du client
Le point le plus important est là.
Un contrat sain doit permettre de continuer avec le prestataire, mais aussi de partir sans catastrophe.
Le client doit pouvoir récupérer son code, ses données, ses accès, et comprendre l’état de son application. Sinon, ce n’est pas de la maintenance. C’est une captivité polie.
Chez 5000.dev, l’idée n’est pas de faire croire que tout sera figé après 2 semaines. Une app vit. Elle évolue. Elle a parfois besoin de maintenance. Mais cette maintenance doit rester au service du business, pas devenir une rente opaque.
C’est la différence entre une relation longue terme et une dépendance.
FAQ
Un contrat de maintenance est-il obligatoire après livraison ?
Non, mais il est souvent utile si l’application devient importante dans l’activité. Le minimum est de clarifier accès, sauvegardes, bugs bloquants et propriété du code.
Que doit contenir un contrat de maintenance web app ?
Il doit couvrir les bugs, les sauvegardes, les accès, les délais de prise en charge, les dépendances critiques et la frontière entre correction et nouvelle fonctionnalité.
Peut-on changer de prestataire si on a un contrat de maintenance ?
Oui, si le code, les données et les accès appartiennent bien à l’entreprise. C’est précisément ce qu’il faut vérifier avant de signer.
Si vous avez déjà une application ou si vous préparez une première brique, le bon moment pour parler maintenance n’est pas après le premier incident: c’est maintenant, avec un contrat simple qui protège votre contrôle plutôt que de l’échanger contre une nouvelle dépendance.