Une application en production continue d’évoluer même lorsque aucune fonctionnalité n’est ajoutée. Les navigateurs, systèmes, bibliothèques, certificats, volumes et services tiers changent. Les utilisateurs rencontrent des cas non prévus et les risques de sécurité sont réévalués.
La maintenance applicative organise cette continuité. Elle ne se réduit pas à un stock d’heures ni à une adresse e-mail. Elle définit le périmètre, les responsabilités, les priorités, les délais de prise en charge, la capacité d’évolution et la manière de mesurer le service.
Ce guide aide à structurer le dispositif. Il ne constitue pas un modèle juridique ; les clauses doivent être adaptées au contexte et validées par les parties.
TMA, support, maintenance et infogérance : distinguer les services
La maintenance corrective traite les anomalies. La maintenance préventive réduit les risques avant incident : mises à jour, revues, tests de sauvegarde. La maintenance évolutive modifie le produit. Le support accompagne les utilisateurs ou administrateurs. L’infogérance couvre l’exploitation de l’infrastructure et des services techniques.
La TMA, ou tierce maintenance applicative, peut regrouper plusieurs de ces activités lorsqu’elles sont confiées à un prestataire. Le contrat doit préciser ce qui est inclus. Une erreur de code, une mauvaise donnée, une saturation serveur et une question d’utilisation n’exigent pas la même compétence ni le même engagement.
Définir le périmètre avant les délais
Le périmètre comprend les applications, versions, environnements, interfaces, traitements planifiés, services tiers et heures d’usage. Il précise qui gère le cloud, la base, les certificats, les sauvegardes, le DNS, le poste utilisateur et les fournisseurs externes.
Il faut également lister les exclusions : système non documenté, composant hors support, accès non fourni, modification directe par un tiers ou environnement de test absent. Une exclusion doit conduire à un plan de réduction, pas devenir une excuse permanente.
Construire une matrice de priorité
Une priorité est déterminée par l’impact, l’étendue et l’existence d’un contournement. Un exemple générique :
| Niveau | Situation | Exemple | Objectif initial |
|---|---|---|---|
| P1 critique | Service ou fonction vitale indisponible, risque données/sécurité | impossibilité de traiter des commandes | prise en charge et cellule d’incident immédiates selon couverture |
| P2 majeur | Fonction importante dégradée, contournement limité | import bloqué pour une équipe | diagnostic prioritaire |
| P3 standard | Anomalie circonscrite, contournement acceptable | erreur d’affichage ou règle secondaire | planification dans la maintenance |
| P4 mineur | gêne faible ou demande d’amélioration | libellé, confort, optimisation | backlog évolutif |
La qualification doit pouvoir être révisée après diagnostic. Un symptôme visible par un seul utilisateur peut révéler un défaut de données global ; une alerte impressionnante peut être sans impact.
Assistant de cadrage local
Configurer un niveau de service indicatif
Décrivez les usages et les capacités actuelles pour obtenir un profil de couverture, des prérequis et les questions à traiter dans le contrat.
Important : ce résultat est pédagogique. Il ne constitue ni un SLA, ni un tarif, ni une promesse de délai. Les engagements doivent être vérifiés techniquement, budgétés et validés par les parties et leurs conseils.
Confidentialité : les réponses restent dans ce navigateur, sans stockage ni transmission. Ne saisissez aucune donnée de projet, de client ou d’infrastructure.
Recommandation non contractuelle
Profil conseillé : —
Dispositif à cadrer
Prérequis techniques et organisationnels
- Les prérequis apparaîtront après le calcul.
Matrice P1 à P4 indicative
Les objectifs ci-dessous structurent le processus ; ils ne fixent aucune durée contractuelle automatique.
| Priorité | Situation | Mobilisation | Contournement ou rétablissement | Résolution définitive |
|---|
Questions à traiter dans le contrat
- Les questions contractuelles apparaîtront après le calcul.
Métriques à suivre
- Les métriques apparaîtront après le calcul.
Ne pas confondre les délais
Le délai de prise en charge correspond au début du traitement. Le délai de diagnostic vise une compréhension initiale. Le délai de rétablissement remet le service à un niveau acceptable, parfois par contournement. Le délai de résolution apporte la correction définitive.
Promettre une résolution fixe pour toute anomalie est rarement réaliste, car la cause peut dépendre d’un tiers ou nécessiter une migration. Un engagement plus robuste porte sur la mobilisation, la communication, le rétablissement et l’escalade.
Définir les heures de couverture
Une application utilisée du lundi au vendredi n’a pas automatiquement besoin d’une astreinte 24/7. En revanche, les traitements nocturnes, utilisateurs internationaux ou campagnes peuvent créer des périodes critiques hors bureau.
La couverture doit distinguer :
- réception et enregistrement des demandes ;
- supervision automatique ;
- prise en charge humaine ;
- intervention technique ;
- disponibilité des décideurs métier.
Une astreinte sans accès, documentation, monitoring ni autorité de décision offre peu de protection.
Organiser le canal d’entrée et l’escalade
Chaque demande doit recevoir un identifiant, une priorité, un environnement, un impact, des éléments de reproduction et un demandeur. Les urgences utilisent un canal explicite ; un e-mail envoyé la nuit ne doit pas être supposé déclencher une astreinte si ce mécanisme n’est pas convenu.
L’escalade précise qui est contacté lorsque l’incident dépasse le périmètre, implique un fournisseur, exige une décision métier ou devient une crise. Les coordonnées et rôles sont revus régulièrement.
Le schéma représente sept étapes successives. Le rétablissement du service ne ferme pas le cycle : l’analyse et la prévention transforment chaque incident en amélioration mesurable.
- Détecter : repérer l’anomalie par la supervision, les journaux ou un signalement utilisateur.
- Qualifier : mesurer l’impact, l’étendue, la criticité et les risques associés.
- Contenir : limiter la propagation et protéger les données ou parcours encore disponibles.
- Rétablir : remettre le service à un niveau acceptable, au besoin par un contournement contrôlé.
- Analyser : identifier les causes techniques et organisationnelles à partir des faits.
- Prévenir : ajouter les correctifs, alertes, tests ou procédures qui réduisent la récurrence.
- Améliorer : suivre les actions et ajuster le dispositif de maintenance lors de la revue de service.
Prévoir une capacité, pas seulement un taux journalier
La maintenance courante bénéficie d’une capacité réservée. Elle peut prendre la forme d’un forfait, d’un nombre de jours mensuels, d’un minimum de consommation ou d’un budget au réel avec plafond. Chaque modèle répartit différemment le risque de disponibilité des ressources.
Le budget doit distinguer :
- socle de service et gouvernance ;
- supervision et astreinte ;
- correctif courant ;
- mises à jour préventives ;
- évolutions planifiées ;
- chantiers exceptionnels.
Mélanger tout dans une enveloppe unique conduit souvent à sacrifier les mises à jour au profit des demandes visibles.
Maintenir une politique de versions
Le contrat décrit comment sont suivies les dépendances, les vulnérabilités et les fins de support. Les mises à jour mineures sont testées régulièrement ; les versions majeures font l’objet d’une étude et d’un projet planifié.
L’objectif est d’éviter l’alternance entre immobilisme et migration urgente. Un budget préventif lisse l’effort et maintient la possibilité d’évoluer.
Mesurer un service utile
Le nombre de tickets fermés ne suffit pas. Les indicateurs peuvent inclure :
- disponibilité des parcours critiques ;
- délai de détection ;
- délai de prise en charge et de rétablissement par priorité ;
- taux de réouverture ;
- incidents récurrents ;
- changements ayant provoqué une panne ;
- âge du backlog de sécurité ;
- consommation corrective, préventive et évolutive ;
- satisfaction des interlocuteurs.
Les mesures doivent être interprétées. Une hausse des tickets peut refléter une meilleure détection, pas une dégradation.
Organiser les revues de service
Une revue mensuelle ou trimestrielle examine les incidents, la capacité, les risques, les versions et la roadmap. Elle identifie les causes répétées et décide des actions préventives. Les sujets de budget sont discutés avec des preuves, pas uniquement lors d’une urgence.
Le compte rendu attribue chaque action, son échéance et son critère de fermeture. Les écarts d’engagement sont analysés pour améliorer le processus.
Préparer la sortie dès l’entrée
Le dispositif doit inclure la réversibilité : documentation, accès du client, export des tickets, propriété des comptes, transfert de connaissance et rotation des secrets. Cette préparation protège le client et améliore aussi la qualité quotidienne.
Un contrat aligné sur la criticité réelle
La disponibilité parfaite n’existe pas et toute exigence a un coût d’architecture, d’outillage et d’organisation. Le bon contrat rend ce compromis explicite. Il définit ce qui est critique, comment le service est rétabli et comment les risques sont réduits dans le temps.
Partitech assure la maintenance corrective, évolutive, l’hébergement, l’infogérance et, selon les besoins, des astreintes. Nous pouvons reprendre un projet développé par un tiers et construire un cadre de service adapté à ses usages réels.
Pour approfondir la démarche, consultez la méthode pour reprendre la maintenance d’une application existante, préparez la continuité et la reprise d’activité et apprenez à calculer le TCO d’une application sur cinq ans. Découvrez aussi l’offre Maintenance, évolutions et hébergement de Partitech.
Référence officielle
Référence consultée le 17 août 2026 :