Votre application tombe la nuit. Personne ne sait pourquoi. Vos clients en parlent à leur entourage, pas à vous.

Le constat

Votre application a été développée il y a un an, deux ans, cinq ans. Elle marche, en gros. De temps en temps, un client appelle pour dire qu'il a eu un message d'erreur. Vous lui répondez "essayez de rafraîchir". Ç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, ils en parlent à un ami, ou ils essayent 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 bourre.

Pourquoi ça finit toujours par lâcher

Le code n'a pas été touché depuis qu'il a été livré

Une application repose sur des dizaines de briques tierces (les outils qu'on utilise pour développer, 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 le code, le coût de remise à niveau est plus élevé que le coût d'une mise à jour régulière.

Personne ne regarde ce que l'application dit

Une application qui tourne génère des journaux de bord en continu. Erreurs, lenteurs, comportements anormaux. Sans dispositif pour les surveiller, ces signaux 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

Les failles découvertes dans les briques tierces sont publiées chaque mois. Si l'application n'est pas à jour, ces failles vous concernent. La plupart des piratages d'applications ne sont pas des attaques ciblées, ce sont des exploitations automatiques de failles connues sur des sites qui n'ont pas été patchés.

Quand le problème arrive, personne ne sait par où commencer

Sans documentation à jour, sans accès aux journaux, sans connaissance de l'architecture, résoudre une panne prend des heures au lieu de minutes. Et chaque minute d'indisponibilité est une minute pendant laquelle des clients se détournent.

Notre méthode

Pas de forfait magique, pas de "garantie 99,99 %" qu'on ne peut pas tenir. Trois choses simples, faites régulièrement.

1. Audit complet de l'existant

   On regarde l'état du code, les briques tierces utilisées et leur version, les éventuels signaux d'alerte présents mais ignorés. Vous repartez avec une photo claire : qu'est-ce qui tient bien, qu'est-ce qui menace de céder, qu'est-ce qui demande à être traité en priorité.

2. Mettre l'application sous surveillance

   On installe ce qu'il faut pour que l'application remonte d'elle-même les erreurs, les lenteurs, les comportements anormaux. Quand quelque chose cloche, on le sait dans la minute. Vos utilisateurs n'ont plus à nous prévenir.

3. Mises à jour régulières, sans grands événements

   Toutes les quelques semaines, on met à jour les briques techniques, on traite les alertes accumulées, on documente les changements. Pas de grosse refonte tous les deux ans, des petites maintenances qui empêchent la refonte d'être nécessaire.

À quoi vous attendre

Première intervention : un audit complet en 1 à 2 semaines. Vous repartez avec un état des lieux écrit, qu'on travaille ensemble ou pas. Pas de jargon, pas d'effet de manche, juste ce qui va et ce qui ne va pas.

Si on continue ensemble, on installe la surveillance, on rattrape ce qui doit l'être, puis on rentre dans un rythme régulier. Vous avez chaque mois un récapitulatif clair de ce qui a été fait, de ce qui a été détecté et corrigé, de ce qu'il reste à traiter.

On reste joignable rapidement en cas d'urgence pendant les heures normales. Pour les pannes nocturnes, on cadre clair ce qui est inclus et ce qui demande un dispositif d'astreinte dédié, qui n'a pas de sens pour la plupart des applications.

Ce qu'on ne fait pas

Pour être clair sur ce qui ne nous correspond pas :

• On ne maintient pas une application sans audit préalable. Reprendre une application sans savoir dans quel état elle est, c'est s'engager sur du temps qu'on ne peut pas estimer. L'audit n'est pas une formalité commerciale, c'est ce qui rend le suivi possible.
• On ne s'engage pas sur "99,99 % de disponibilité". Personne d'honnête ne s'engage là-dessus pour une application standard. Ce qui est tenable : surveillance active, intervention rapide, mises à jour régulières. C'est ce qu'on offre, sans embellir.
• On ne facture pas un forfait fixe pour de l'opaque. Vous savez ce qui est inclus, ce qui est mesuré, ce qui est traité. Si un mois il n'y a presque rien à faire, on vous le dit. Si un mois c'est plus chargé, on en parle avant, pas après.

Les questions qu'on nous pose

Intervenez-vous sur des projets que vous n'avez pas développés ?

Oui, sous conditions. On commence par un audit du code existant pour évaluer la qualité et identifier les risques avant de s'engager.

Quel est le délai d'intervention en cas de panne critique ?

Pour les pannes bloquantes en production : 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.