Votre application tombe la nuit. Personne ne sait pourquoi.Vos clients en parlent à leur entourage, pas à vous.
Une application laissée sans entretien finit par casser au mauvais moment. Voici ce qui se passe vraiment quand un site ou un outil vieillit, et ce que je surveille pour qu'il ne vous lâche pas en pleine activité.
Le constat
Votre application a été construite il y a un an, deux ans, cinq ans. Elle marche, en gros. De temps en temps, un client appelle pour signaler un message d'erreur. Vous lui répondez « essayez de rafraîchir la page ». Ça finit par marcher. Vous pensez que ce n'est pas grave.
Sauf que la majorité des clients qui rencontrent une erreur n'appellent pas. Ils ferment l'onglet, en parlent à un ami, ou essaient un concurrent. Vous perdez des utilisateurs sans le savoir, parce que personne ne regarde ce qui se passe la nuit, le week-end ou pendant les coups de feu.
Pourquoi ça finit toujours par lâcher
Personne n'a touché au code depuis la livraison
Une application repose sur des dizaines de composants fournis par d'autres, qui évoluent régulièrement. Quand on ne les met pas à jour pendant deux ans, l'écart se creuse. Le jour où il faut faire évoluer l'application, la remise à niveau coûte plus cher que des mises à jour régulières.
Personne ne regarde ce que l'application signale
Une application en service note en continu ce qui se passe : erreurs, lenteurs, comportements anormaux. Sans personne pour surveiller ces signaux, ils partent à la poubelle. Vous découvrez le problème quand un client se plaint, ou pire, quand il ne se plaint pas et qu'il part.
La sécurité s'effrite avec le temps
Des failles sont découvertes chaque mois dans les composants courants. Si l'application n'est pas à jour, ces failles vous concernent. La plupart des piratages ne sont pas des attaques ciblées : ce sont des robots qui exploitent des failles connues sur des sites jamais mis à jour.
Quand le problème arrive, personne ne sait par où commencer
Sans documentation à jour, sans accès aux journaux, sans connaître la façon dont l'application est construite, résoudre une panne prend des heures au lieu de minutes. Et chaque minute d'indisponibilité, ce sont des clients qui se détournent.
Ma méthode
Pas de forfait magique, pas de « garantie 99,99 % » impossible à tenir. Trois choses simples, faites régulièrement.
Un état des lieux complet
Je regarde l'état du code, les composants utilisés et leur version, les signaux d'alerte présents mais ignorés. Vous repartez avec une photo claire : ce qui tient bien, ce qui menace de céder, ce qui doit être traité en priorité.
Mettre l'application sous surveillance
Je mets en place de quoi faire remonter automatiquement les erreurs, les lenteurs et les comportements anormaux. Quand quelque chose cloche, je le sais dans la minute. Vos utilisateurs n'ont plus à me prévenir.
Des mises à jour régulières, sans grands chantiers
Toutes les quelques semaines, je mets à jour les composants, je traite les alertes accumulées et je note ce qui a changé. Pas de grosse refonte tous les deux ans : de petites maintenances qui évitent d'en arriver là.
Une plateforme en service depuis plus d'un an, sans incident bloquant
Bimi est utilisée tous les jours par un restaurant toulousain pour ses commandes en ligne, ses réservations et son équipe. Pas une seule indisponibilité critique en plus d'un an.
Ce n'est pas un coup de chance. C'est le résultat d'un suivi régulier : surveillance active, mises à jour programmées, intervention dans la minute si quelque chose cloche.
À quoi vous attendre
Première intervention : un état des lieux complet en 1 à 2 semaines. Vous repartez avec un bilan écrit, qu'on travaille ensemble ou non. Écrit simplement : ce qui va, et ce qui ne va pas.
Si on continue ensemble, je mets en place la surveillance, je rattrape ce qui doit l'être, puis je passe à un rythme régulier. Chaque mois, vous recevez un récapitulatif clair : ce qui a été fait, ce qui a été détecté et corrigé, ce qui reste à traiter.
Je reste joignable rapidement en cas d'urgence pendant les heures ouvrées. Pour les pannes de nuit, je définis avec vous ce qui est inclus et ce qui demande une astreinte dédiée, inutile pour la plupart des applications.
Ce que je ne fais pas
Pour être clair sur ce qui ne me correspond pas.
Je ne maintiens pas une application sans état des lieux préalable.
Reprendre une application sans savoir dans quel état elle est, c'est s'engager sur un temps impossible à estimer. L'état des lieux n'est pas une formalité commerciale : c'est ce qui rend le suivi possible.
Je ne m'engage pas sur « 99,99 % de disponibilité ».
Personne d'honnête ne s'y engage pour une application courante. Ce qui est tenable : une surveillance active, une intervention rapide, des mises à jour régulières. C'est ce que je propose, sans embellir.
Je ne facture pas un forfait fixe sans dire ce qu'il contient.
Vous savez ce qui est inclus, ce qui est mesuré, ce qui est traité. Si un mois il n'y a presque rien à faire, je vous le dis. Si un mois est plus chargé, on en parle avant, pas après.
Les questions qu'on me pose
- Intervenez-vous sur des projets que vous n'avez pas développés ?
- Oui, sous conditions. Je commence par un audit du code existant pour évaluer la qualité et identifier les risques avant de m'engager.
- Quel est le délai d'intervention en cas de panne critique ?
- Pour les pannes bloquantes : réponse dans l'heure, correction dans la journée. Pour les bugs non critiques : traités dans les 48 heures ouvrées.
- Comment sont facturées les interventions de maintenance ?
- Au forfait mensuel pour un suivi régulier, ou à la demande pour des interventions ponctuelles. On définit ensemble la formule adaptée à votre usage.
- Peut-on combiner maintenance et évolution de l'application ?
- C'est le cas le plus courant. Maintenance corrective et évolutions fonctionnelles sont gérées dans le même cadre contractuel.
Si vous voulezen parler.
Un appel de 30 minutes en visio. Vous me décrivez votre application, ses incidents récents, vos craintes. Je vous donne un avis honnête, avec ou sans état des lieux, avec ou sans suivi. Aucun engagement.