Una aplicación en producción continúa evolucionando incluso cuando no se agrega ninguna funcionalidad. Los navegadores, sistemas, bibliotecas, certificados, volúmenes y servicios de terceros cambian. Los usuarios se encuentran con casos imprevistos y los riesgos de seguridad se reevalúan.
El mantenimiento de aplicaciones organiza esta continuidad. No se reduce a un stock de horas ni a una dirección de correo electrónico. Define el alcance, las responsabilidades, las prioridades, los plazos de atención, la capacidad de evolución y la manera de medir el servicio.
Esta guía ayuda a estructurar el dispositivo. No constituye un modelo jurídico; las cláusulas deben adaptarse al contexto y ser validadas por las partes.
TMA, soporte, mantenimiento y gestión de TI: distinguir los servicios
El mantenimiento correctivo trata las anomalías. El mantenimiento preventivo reduce los riesgos antes del incidente: actualizaciones, revisiones, pruebas de respaldo. El mantenimiento evolutivo modifica el producto. El soporte acompaña a los usuarios o administradores. La externalización de la gestión cubre la explotación de la infraestructura y de los servicios técnicos.
La TMA, o mantenimiento de aplicaciones por terceros, puede agrupar varias de estas actividades cuando se confían a un proveedor. El contrato debe especificar lo que está incluido. Un error de código, un dato incorrecto, una saturación del servidor y una pregunta de uso no requieren la misma competencia ni el mismo compromiso.
Definir el alcance antes de los plazos
El perímetro comprende las aplicaciones, versiones, entornos, interfaces, procesos planificados, servicios de terceros y horas de uso. Precisa quién gestiona la nube, la base, los certificados, las copias de seguridad, el DNS, el puesto de usuario y los proveedores externos.
También es necesario enumerar las exclusiones: sistema no documentado, componente sin soporte, acceso no proporcionado, modificación directa por un tercero o entorno de prueba ausente. Una exclusión debe conducir a un plan de reducción, no convertirse en una excusa permanente.
Construir una matriz de prioridad
Una prioridad se determina por el impacto, el alcance y la existencia de una solución alternativa. Un ejemplo genérico:
| Nivel | Situación | Ejemplo | Objetivo inicial |
|---|---|---|---|
| Crítica P1 | Servicio o función vital no disponible, riesgo de datos/seguridad | imposibilidad de procesar pedidos | atención y célula de incidente inmediatas según cobertura |
| P2 mayor | Función importante degradada, contorno limitado | importado bloqueado para un equipo | diagnóstico prioritario |
| Estándar P3 | Anomalía circunscrita, desvío aceptable | error de visualización o regla secundaria | planificación en el mantenimiento |
| P4 menor | molestia leve o solicitud de mejora | expresión, confort, optimización | acumulación evolutiva |
La calificación debe poder ser revisada después del diagnóstico. Un síntoma visible por un solo usuario puede revelar un defecto de datos global; una alerta impresionante puede no tener impacto.
No confundir los plazos
El plazo de atención corresponde al inicio del tratamiento. El plazo de diagnóstico apunta a una comprensión inicial. El plazo de recuperación devuelve el servicio a un nivel aceptable, a veces mediante un desvío. El plazo de resolución aporta la corrección definitiva.
Prometer una resolución fija para cualquier anomalía rara vez es realista, ya que la causa puede depender de un tercero o requerir una migración. Un compromiso más sólido se centra en la movilización, la comunicación, la recuperación y la escalada.
Definir las horas de cobertura
Una aplicación utilizada de lunes a viernes no necesita automáticamente un servicio de guardia 24/7. En cambio, los procesos nocturnos, los usuarios internacionales o las campañas pueden crear períodos críticos fuera de la oficina.
La cubierta debe distinguir:
- recepción y registro de las solicitudes;
- supervisión automática;
- atención humana;
- intervención técnica ;
- disponibilidad de los responsables de negocio.
Una guardia sin acceso, documentación, supervisión ni autoridad de decisión ofrece poca protección.
Organizar el canal de entrada y la escalada
Cada solicitud debe recibir un identificador, una prioridad, un entorno, un impacto, elementos de reproducción y un solicitante. Las urgencias utilizan un canal explícito; un correo electrónico enviado por la noche no debe presumirse que active un guardia si no se ha acordado este mecanismo.
La escalada precisa que se contacta cuando el incidente supera el perímetro, implica a un proveedor, requiere una decisión empresarial o se convierte en una crisis. Los datos de contacto y los roles se revisan regularmente.
El esquema representa siete etapas sucesivas. La restauración del servicio no cierra el ciclo: el análisis y la prevención transforman cada incidente en una mejora medible.
- Detectar: detectar la anomalía mediante la supervisión, los registros o un informe de usuario.
- Calificador: medir el impacto, la extensión, la criticidad y los riesgos asociados.
- Contener: limitar la propagación y proteger los datos o trayectos aún disponibles.
- Restablecer: restablecer el servicio a un nivel aceptable, si es necesario mediante un desvío controlado.
- Analizar: identificar las causas técnicas y organizativas a partir de los hechos.
- Prevenir: agregar los correctivos, alertas, pruebas o procedimientos que reduzcan la recurrencia.
- Mejorar : seguir las acciones y ajustar el dispositivo de mantenimiento durante la revisión del servicio.
Prever una capacidad, no solo una tasa diaria
El mantenimiento corriente se beneficia de una capacidad reservada. Puede tomar la forma de un forfait, un número de días mensuales, un mínimo de consumo o un presupuesto real con un tope. Cada modelo distribuye de manera diferente el riesgo de disponibilidad de los recursos.
El presupuesto debe distinguir:
- base de servicio y gobernanza;
- supervisión y guardia;
- corrección actual;
- actualizaciones preventivas;
- evoluciones planificadas;
- obras excepcionales.
Mezclar todo en un solo sobre a menudo conduce a sacrificar las actualizaciones en favor de las solicitudes visibles.
Mantener una política de versiones
El contrato describe cómo se siguen las dependencias, las vulnerabilidades y los fines de soporte. Las actualizaciones menores se prueban regularmente; las versiones mayores son objeto de un estudio y de un proyecto planificado.
El objetivo es evitar la alternancia entre inmovilismo y migración urgente. Un presupuesto preventivo suaviza el esfuerzo y mantiene la posibilidad de evolucionar.
Medir un servicio útil
El número de tickets cerrados no es suficiente. Los indicadores pueden incluir:
- disponibilidad de los recorridos críticos;
- plazo de detección;
- plazo de atención y recuperación por prioridad;
- tasa de reapertura;
- incidentes recurrentes;
- cambios que provocaron una falla;
- edad del backlog de seguridad;
- consumo correctivo, preventivo y evolutivo;
- satisfacción de los interlocutores.
Las medidas deben interpretarse. Un aumento de los tickets puede reflejar una mejor detección, no un deterioro.
Organizar las revisiones de servicio
Una revista mensual o trimestral examina los incidentes, la capacidad, los riesgos, las versiones y la hoja de ruta. Identifica las causas repetidas y decide sobre acciones preventivas. Los temas de presupuesto se discuten con evidencia, no solo durante una emergencia.
El informe atribuye cada acción, su plazo y su criterio de cierre. Las desviaciones de compromiso se analizan para mejorar el proceso.
Preparar la salida desde la entrada
El dispositivo debe incluir la reversibilidad: documentación, acceso del cliente, exportación de los tickets, propiedad de las cuentas, transferencia de conocimiento y rotación de secretos. Esta preparación protege al cliente y también mejora la calidad diaria.
Un contrato alineado con la criticidad real
La disponibilidad perfecta no existe y todo requisito tiene un costo de arquitectura, de herramientas y de organización. El buen contrato hace explícito este compromiso. Define qué es crítico, cómo se restablece el servicio y cómo se reducen los riesgos con el tiempo.
Partitech asegura el mantenimiento correctivo, evolutivo, el alojamiento, la externalización y, según las necesidades, guardias. Podemos retomar un proyecto desarrollado por un tercero y construir un marco de servicio adaptado a sus usos reales.
Para profundizar en el enfoque, consulte la método para retomar el mantenimiento de una aplicación existente, prepara la continuidad y reanudación de la actividad y aprendan a calcular el TCO de una aplicación en cinco años. Descubra también la oferta Mantenimiento, evoluciones y alojamiento de Partitech.
Referencia oficial
Referencia consultada el 17 de agosto de 2026: