Maintenance & TMA

Un site ou une application n’est jamais vraiment « terminé ». Les dépendances évoluent, les usages changent et les incidents finissent par arriver. Une prestation de maintenance ou de TMA sert à rendre cette évolution visible, priorisée et réversible.

Nous reprenons l’existant, clarifions les risques et installons un rythme compréhensible par les équipes métier comme par les responsables techniques.

Applications, sites et CMS concernés

Le diagnostic peut concerner une application web, une API, un back-office, un site WordPress ou un autre CMS, ainsi que les services qui permettent au produit de fonctionner : base de données, hébergement, tâches planifiées, intégrations et outils de suivi.

Nous ne confirmons pas une reprise sur la seule base d’un nom de technologie. La version utilisée, les extensions, la qualité du code, les accès disponibles et les conditions d’hébergement déterminent le niveau de risque. Pour un produit qui doit être profondément transformé, un projet de développement sur mesure peut compléter la TMA.

L’audit de reprise

La première étape vise à savoir ce qui peut réellement être maintenu. Elle couvre selon le périmètre :

• les dépôts de code, versions et dépendances ;
• les accès à l’hébergement, aux domaines et aux services tiers ;
• les procédures de déploiement et de retour arrière ;
• les sauvegardes et la possibilité de les restaurer ;
• les erreurs connues, alertes et incidents récents ;
• les zones sensibles pour la sécurité et les données ;
• la documentation disponible et les personnes qui connaissent encore le système ;
• le backlog métier et les échéances à protéger.

Le résultat n’est pas une liste abstraite de défauts. Nous classons les actions entre urgences, risques à planifier, améliorations et éléments acceptables en l’état.

Incidents, priorités et niveaux de service

Une indisponibilité générale, une perte de données ou un blocage du parcours principal ne se traite pas comme un défaut d’affichage. Nous définissons avec vous des catégories d’incident, le canal de signalement, les informations à fournir et les personnes autorisées à décider.

Les horaires de couverture, délais de prise en compte et objectifs de rétablissement sont inscrits dans le contrat adapté au produit. Nous n’affichons pas un SLA universel : il serait trompeur sans connaître la criticité, l’architecture, le budget et les dépendances externes. Le dispositif peut aller d’un suivi planifié à une couverture renforcée, après validation explicite.

Correctif, préventif et évolutif

La maintenance corrective résout un dysfonctionnement observé. Le préventif traite les mises à jour, la supervision, les sauvegardes et les risques avant l’incident. La TMA évolutive ajoute ou modifie des fonctions selon des critères d’acceptation définis.

Par exemple, une reprise peut commencer par restaurer un déploiement fiable et mettre à jour une dépendance critique, puis documenter un module fragile avant d’ajouter une évolution. Sur une automatisation IA ou un assistant RAG, elle inclut aussi le suivi des intégrations, des modèles, des erreurs et de la qualité des réponses.

Ce qu’il faut pour transmettre un produit

Une reprise efficace demande au minimum un contact décisionnaire et les accès légalement transmissibles. Le dépôt de code, l’historique des incidents, les contrats d’hébergement, les comptes techniques, les sauvegardes et les échéances connues réduisent fortement l’incertitude.

S’il manque des accès ou de la documentation, nous le signalons et proposons un ordre de récupération. Nous ne promettons pas un délai précis avant d’avoir identifié ces dépendances. La page Méthode explique comment les décisions, livrables et responsabilités restent visibles pendant l’intervention.

Nos produits Respark et Devisia sont exploités par la même équipe qui les développe. Cette expérience nourrit l’approche de maintenance, sans remplacer l’audit nécessaire pour chaque système repris.