Maintenance of public applications

A serious takeover must cover code, access, environments, deployment chain, monitoring, useful documentation, third-party dependencies, and known fragile zones. The goal is not only to get the service running again, but to understand what its continuity actually depends on.

The distinction must start from the impact on service: immediate outage or degradation, functional defect, new need, or structural weakness in the foundation. Without that framework, priorities become political or emotional, and the real stability issues disappear behind the loudest requests.

Realistic commitments distinguish at least criticality, response time, diagnosis time, workaround time, and fix time when it can be announced properly. A useful SLA is not a uniform promise: it must reflect actual risk and the hours during which the service truly matters.

You need to treat documentation as a maintenance workstream in its own right, starting with critical flows, access, dependencies, and recovery procedures. Waiting to understand everything before documenting is rarely realistic; it is better to rebuild what is missing progressively as operations come back under control.

Because a public application may change operator, contract, or provider without the service being allowed to stop for long. If reversibility is only considered at contract exit, it is often too late to recover access, procedures, or a reliable view of the environments.

You need to isolate accessibility gaps, prioritize them by impact on usage, and attach them to the relevant components or journeys. RGAA-related fixes become steerable when they stop being buried in generic tickets and start producing a clear view of what has been fixed or remains blocking.

The most useful are the ones that connect a symptom to a service impact: availability, application errors, response times, security events, resource saturation, and traces of critical journeys. Stacking metrics without a link to actual usage does not make maintenance more steerable.

You need a simple but stable rhythm, with a clear distinction between operational follow-up, priority trade-offs, and evolution trajectory. Reporting must help teams decide on incidents, delays, security topics, debt items, and evolution requests, not only list closed tickets.

It is maintenance that keeps the service available, the code understandable, access clean, documentation usable, and decisions reviewable several years later. You recognize it by the fact that it gradually reduces system opacity instead of merely absorbing emergencies week after week.