Web application maintenance checklist: ce qu’une PME doit vraiment surveiller

La maintenance d’une application web ne devrait pas ressembler à un deuxième projet.

C’est pourtant ce que beaucoup de PME achètent sans le voir. Une app livrée, puis un contrat flou. Des heures à consommer. Des tickets qui s’empilent. Des réunions pour parler de bugs qui auraient dû être corrigés directement. Une facture mensuelle qui grossit alors que personne ne sait vraiment ce qui est maintenu.

J’ai dirigé une agence de développement pendant 7 ans. J’ai vu des contrats de maintenance qui protégeaient vraiment le client. Et j’ai vu des contrats qui servaient surtout à prolonger la dépendance.

La bonne maintenance ne vend pas de la peur. Elle protège ce qui peut bloquer le business: accès, données, bugs, sauvegardes, petites évolutions, sécurité de base. Le reste doit rester simple.

Cette checklist existe pour une PME qui possède une application métier, pas pour une DSI de 500 personnes.

1. Les accès doivent appartenir à l’entreprise

Premier point. Le plus bête. Le plus dangereux.

Le code, l’hébergement, le nom de domaine, les comptes de paiement, les emails transactionnels, les clés API: tout doit être identifié. Pas “chez le développeur”. Pas “dans un compte perso”. Pas “on verra si besoin”.

Dans le corpus LinkedIn de Loïc, il y a cette histoire classique: le développeur disparaît, le code est sur son compte GitHub personnel, les accès serveur sont à son nom, aucune documentation claire. Le client ne sait même plus ce qu’il possède.

Ce n’est pas un problème technique. C’est un problème de contrôle.

Chez 5000.dev, le code source est livré. L’objectif n’est pas de garder le client prisonnier. Une maintenance saine commence par ça: savoir où est l’application, qui possède quoi, et comment reprendre la main si nécessaire.

2. Les sauvegardes doivent être automatiques et testées

Une sauvegarde non testée est une croyance.

La checklist doit répondre à trois questions simples:

• quelles données sont sauvegardées;
• à quelle fréquence;
• comment on restaure si quelque chose casse.

Pas besoin d’un document de 40 pages. Mais il faut une réponse claire.

Pour une PME, perdre une base client, un historique de commandes ou des dossiers métier peut coûter bien plus cher que la maintenance annuelle. C’est le genre de risque discret qui ne se voit pas tant que tout va bien.

La maintenance utile ne consiste pas à inventer des tâches. Elle consiste à éviter les pertes stupides.

3. Les bugs doivent être triés par impact business

Tous les bugs ne valent pas la même chose.

Un bouton mal aligné n’a pas le même poids qu’un devis impossible à envoyer. Une faute dans une page admin n’a pas le même impact qu’un paiement bloqué. Une lenteur sur une page secondaire n’a pas le même coût qu’un export comptable inutilisable.

La bonne question n’est pas “combien de tickets”. La bonne question est: qu’est-ce qui empêche l’entreprise de travailler ?

C’est là que beaucoup de maintenances deviennent absurdes. On transforme tout en file d’attente. On priorise à distance. On perd trois jours à classer ce qu’un senior aurait compris en dix minutes.

Une PME n’a pas besoin d’un rituel. Elle a besoin d’un interlocuteur qui comprend le business et qui corrige ce qui bloque.

4. Les petites évolutions doivent rester petites

La maintenance devient dangereuse quand elle absorbe les nouveaux projets.

“Juste un champ en plus.” “Juste une notification.” “Juste un rôle utilisateur.” “Juste un export.”

Quatre “juste” plus tard, vous avez une nouvelle brique déguisée en maintenance.

Le modèle 5000.dev évite ce mélange. Une correction reste une correction. Une petite évolution peut passer dans la maintenance si elle est vraiment limitée. Mais une nouvelle fonctionnalité métier doit être cadrée comme une brique: 5 000 euros HT, 2 semaines, un résultat clair.

C’est plus sain pour tout le monde. Le client sait ce qu’il achète. Le prestataire sait ce qu’il livre. Le périmètre ne dérive pas dans le brouillard.

5. Les dépendances doivent être surveillées, pas dramatisées

Une application web dépend toujours de plusieurs choses: framework, librairies, hébergement, emails, stockage, API externes.

Il faut les surveiller. Il ne faut pas en faire un théâtre.

Le discours classique consiste à dire: “attention, tout peut casser, il faut un gros forfait”. C’est exactement le ton que 5000.dev évite. Une app bien construite, bornée, avec peu de couches inutiles, est plus simple à maintenir.

Moins il y a d’usine à gaz, moins la maintenance devient un abonnement à l’angoisse.

La vraie checklist: savoir quelles dépendances sont critiques, lesquelles peuvent attendre, et qui intervient si un service externe change.

6. La documentation doit expliquer le métier, pas réciter la technique

Une documentation utile pour une PME répond à des questions concrètes:

• comment créer un utilisateur;
• où modifier un paramètre;
• comment exporter les données;
• quoi faire si un email ne part pas;
• qui contacter si l’app bloque.

Le reste peut vivre dans le code, les commits, les notes techniques.

Un dirigeant n’a pas besoin d’un roman d’architecture. Il a besoin de ne pas dépendre d’une seule personne pour comprendre les gestes essentiels.

Ce qu’il ne faut pas payer en maintenance

Il y a des lignes qui doivent faire lever un sourcil.

Des réunions mensuelles sans sujet. Du reporting produit pour justifier une facture. Des audits permanents sur une petite app stable. Des heures non utilisées qui expirent. Des “forfaits sécurité” vagues sans action concrète. Des tickets facturés avant même de connaître leur impact.

Une maintenance honnête est lisible. Elle dit ce qui est inclus, ce qui ne l’est pas, et quand une demande doit devenir une nouvelle brique.

C’est le même esprit que le reste de 5000.dev: simplifier avant de vendre plus.

FAQ

Une application web a-t-elle toujours besoin de maintenance ?

Oui, mais pas toujours d’un gros contrat. Il faut au minimum surveiller les accès, les sauvegardes, les bugs bloquants et les dépendances importantes.

Combien coûte la maintenance d’une application PME ?

Cela dépend du volume de demandes et du niveau critique de l’app. Le point important est de séparer corrections, surveillance et nouvelles fonctionnalités pour éviter une facture floue.

Une nouvelle fonctionnalité doit-elle passer en maintenance ?

Pas si elle change vraiment le métier. Chez 5000.dev, une vraie nouvelle fonctionnalité se cadre souvent comme une nouvelle brique à 5 000 euros HT et 2 semaines.

Si votre application commence à devenir importante pour l’équipe, le bon réflexe n’est pas de signer un contrat lourd: c’est de vérifier cette checklist et de décider ce qui mérite vraiment une surveillance simple avec 5000.dev.