Logiciel & IA · De la stratégie à la production

Après la mise en production

TMA : tierce maintenance applicative de vos logiciels en production

La TMA (tierce maintenance applicative) maintient vos logiciels en production : corrections, évolutions, montées de version, sécurité et supervision. Nos ingénieurs, encadrés par nos leads techniques, reprennent aussi les applications construites par un autre prestataire.

Visio de 30 minutes, gratuite et sans engagement, suivie d’un récapitulatif écrit avec un ordre de grandeur.

Un ingénieur DevOps suit des tableaux de supervision

Ce que nous prenons en charge

Garder vos applications en service.

Une application en production ne reste pas stable d’elle-même. Les utilisateurs découvrent des anomalies, les besoins métier évoluent, les frameworks et les versions de PHP arrivent en fin de support, des vulnérabilités sont publiées dans les dépendances, les volumes augmentent. Sans maintenance organisée, chaque correction devient une intervention risquée et chaque évolution coûte plus cher que la précédente.

La tierce maintenance applicative organise ce travail : un périmètre clair, un circuit de demandes, des priorités partagées, des livraisons testées et un suivi régulier. Vous gardez la maîtrise de la feuille de route ; nous prenons en charge la réalisation et la continuité du service.

Maintenance corrective

Qualification des anomalies signalées, reproduction, correction, tests de non-régression et mise en production. Les causes récurrentes sont identifiées pour ne pas corriger deux fois le même problème.

Maintenance évolutive

Nouvelles fonctionnalités, adaptations aux évolutions réglementaires ou métier, nouvelles intégrations avec vos outils. Chaque évolution est estimée, priorisée avec vous puis livrée par étapes.

Maintenance préventive

Réduction de la dette technique, ajout de tests sur les parties fragiles, optimisation des performances et nettoyage du code avant que les difficultés ne se transforment en incidents.

Montées de version

Mise à jour des frameworks, de la version de PHP ou du langage, des bibliothèques et des composants d’infrastructure, planifiée avant la fin de support plutôt que subie après.

Sécurité

Suivi des vulnérabilités publiées sur vos dépendances, application des correctifs, revue des accès et des secrets, contrôle des points d’exposition de l’application.

Supervision et exploitation

Journaux, alertes, suivi des erreurs et des temps de réponse, sauvegardes vérifiées, pour détecter un problème avant vos utilisateurs et diagnostiquer plus vite.

Ingénieurs surveillant plusieurs écrans de supervision

Les signaux à reconnaître

Quand externaliser la maintenance applicative ?

La maintenance applicative externalisée répond rarement à une décision abstraite. Elle s’impose le plus souvent lorsqu’une application importante pour l’activité n’a plus d’équipe clairement responsable de son fonctionnement.

Le prestataire d’origine n’est plus là

L’agence ou le freelance qui a développé l’application a cessé son activité, n’est plus disponible ou ne répond plus dans des délais compatibles avec votre activité. Personne ne connaît plus vraiment le code.

Les mises à jour ont été repoussées

L’application tourne sur une version de PHP ou de framework qui n’est plus maintenue. Chaque mise à jour paraît risquée, alors elle est reportée, et l’écart se creuse.

Les incidents se répètent

Les mêmes anomalies reviennent, les mises en production provoquent des régressions, et les utilisateurs signalent les problèmes avant que vous ne les détectiez.

Votre équipe interne est absorbée par l’exploitation

Vos développeurs passent plus de temps à corriger et à dépanner qu’à faire avancer le produit. Une partie du maintien en conditions opérationnelles peut être confiée à l’extérieur.

Les évolutions coûtent de plus en plus cher

Ajouter une fonctionnalité simple demande des semaines, parce que le code est difficile à comprendre, mal testé ou très couplé. La dette technique doit être traitée en parallèle des demandes.

Reprendre l’existant

Notre méthode de reprise.

Reprendre une application développée par un autre prestataire est l’un des cas les plus fréquents de TMA. C’est aussi le moment où l’on prend le plus de risques si l’on commence à corriger sans avoir compris le système. Nous procédons donc par étapes, en commençant par rendre l’application lisible et sa mise en production reproductible.

Lorsque l’état de l’application est incertain, la reprise commence par un audit technique du code, de l’architecture, des dépendances, de la sécurité et du déploiement, qui débouche sur un plan d’action priorisé.

Récupération des accès et des sources

Dépôts de code, hébergement, bases de données, noms de domaine, services tiers, comptes d’envoi d’e-mails, outils de supervision. Nous vérifions que vous détenez bien chaque accès et que rien ne dépend d’un compte personnel de l’ancien prestataire.

État des lieux

Lecture du code, inventaire des versions et des dépendances, analyse de la base de données, du déploiement et de l’historique des incidents. Vous obtenez une cartographie des risques et des priorités.

Remise en état de la chaîne de livraison

Environnement de développement reproductible, environnement de recette, déploiement documenté et, si possible, automatisé. Une correction doit pouvoir être livrée sans manipulation hasardeuse sur le serveur.

Sécurisation des zones critiques

Tests sur les parcours les plus importants avant toute modification, correctifs de sécurité urgents, sauvegardes vérifiées. On protège ce qui fonctionne avant de changer quoi que ce soit.

Prise en charge de la maintenance courante

Une fois la base stabilisée, le cycle normal de maintenance démarre : traitement des demandes, livraisons régulières, suivi des indicateurs et plan de montées de version.

Les éléments remis à votre équipe

  • Cartographie de l’application, des accès et des dépendances
  • Plan de reprise et de maintenance priorisé
  • Documentation d’installation, de déploiement et d’exploitation

Tenir la base technique à jour

Montées de version de PHP, de frameworks et de dépendances.

Les langages, les frameworks et les bibliothèques ont un calendrier de support. Lorsqu’une version n’est plus maintenue, elle ne reçoit plus de correctifs de sécurité, et les composants récents cessent progressivement de la prendre en charge. Plus l’écart grandit, plus la mise à jour devient longue et risquée.

Nous traitons les montées de version comme un chantier planifié : inventaire, ordre des étapes, tests de non-régression, environnement de recette et mise en production maîtrisée. Sur les applications PHP, nous intervenons sur les versions du langage et sur les frameworks qui les structurent, avec nos expertises en développement Symfony, en développement PHP sur mesure et en maintenance d’applications CodeIgniter.

Inventaire et calendrier

Versions en place, dates de fin de support, dépendances abandonnées ou incompatibles, et calendrier de mise à jour aligné sur vos périodes sensibles.

Montée par étapes

Passage de version en version lorsque c’est nécessaire, correction des usages dépréciés, remplacement des bibliothèques qui ne sont plus maintenues.

Filet de tests

Tests automatisés sur les parcours essentiels avant la migration, pour vérifier que l’application se comporte de la même manière après la mise à jour.

Mise en production maîtrisée

Recette sur un environnement équivalent à la production, plan de retour arrière et suivi renforcé dans les jours qui suivent la bascule.

Le cadre de la maintenance

Un engagement de service défini avec vous.

Toutes les demandes n’ont pas la même urgence. Une indisponibilité qui bloque vos utilisateurs ne se traite pas comme une amélioration d’écran. Le cadre de la maintenance est donc défini au démarrage, en fonction de la criticité de l’application et de vos contraintes, puis inscrit dans le contrat.

Un interlocuteur identifié suit la maintenance avec vous et arbitre les priorités ; nos leads techniques supervisent les choix techniques et la relecture des livraisons. Les indicateurs de suivi sont partagés et revus régulièrement, pour que l’effort de maintenance reste visible et discuté.

  • Classification des demandes par niveau de gravité et circuit de signalement
  • Délais de prise en charge et plages d’intervention définis selon la criticité de l’application
  • Outil de suivi partagé : chaque demande est tracée, de la qualification à la mise en production
  • Livraisons testées sur un environnement de recette avant la production
  • Point de suivi régulier : incidents traités, évolutions livrées, dette technique et risques
  • Documentation tenue à jour au fil des interventions

L’exploitation de l’infrastructure — environnements, déploiements automatisés, hébergement et coûts cloud — peut être associée à la maintenance applicative avec notre offre DevOps & Cloud Management. Nos pratiques de revue de code et de tests sont détaillées dans nos engagements.

La réalisation en pratique

Des applications en production que nous faisons évoluer.

Deux développeurs relisent du code ensemble

Maintenance applicative offshore

Une maintenance applicative offshore pilotée depuis la France.

Nos ingénieurs francophones travaillent à Madagascar et à l’île Maurice, avec 1 à 3 heures d’avance sur Paris. Ils interviennent dans vos outils, vos dépôts et vos rituels, et les échanges se font en français, à l’écrit comme à l’oral.

La proximité horaire compte particulièrement en maintenance : un incident signalé le matin se qualifie dans la journée, avec les mêmes interlocuteurs que ceux qui connaissent votre application. La continuité ne repose pas sur une seule personne : la connaissance du code est partagée, documentée et transmise au sein de l’équipe.

Les choix qui comptent

Maintenir, moderniser ou reconstruire ?

Toute application ancienne ne doit pas être réécrite. Une refonte complète est longue, coûteuse et réintroduit des risques que l’application existante a déjà résolus. Dans la plupart des cas, une modernisation progressive — montées de version, refactorisation ciblée, remplacement d’un module à la fois — donne de meilleurs résultats.

L’état des lieux permet de trancher partie par partie : ce qui peut être maintenu tel quel, ce qui doit être restructuré et ce qui gagnerait à être reconstruit. Ces choix sont documentés, avec leurs conséquences en effort, en risque et en exploitation, pour que vous puissiez décider en connaissance de cause.

Le cadre de collaboration

Démarrer la maintenance de votre application.

Présentez-nous l’application, son rôle pour votre activité, les technologies utilisées, son hébergement et les difficultés que vous rencontrez. Nous préciserons ensuite les accès nécessaires à l’état des lieux.

Selon le contrat, la TMA est une régie ou un forfait de maintenance. En régie, une équipe dédiée prend en charge l’application lorsqu’elle évolue en continu, ou l’un de nos ingénieurs renforce votre équipe interne sur l’exploitation courante. Au forfait, un contrat de maintenance fixe un volume d’intervention convenu, et une reprise avec mise à niveau peut être menée en projet au forfait sur un périmètre court et défini. Une modernisation de plusieurs mois se conduit plutôt en projet en régie.

Questions fréquentes

Vos questions.

Qu’est-ce que la TMA ?

La TMA, ou tierce maintenance applicative, consiste à confier à un prestataire externe la maintenance d’une ou plusieurs applications en production. Elle couvre la correction des anomalies, les évolutions fonctionnelles, la maintenance préventive, les montées de version, la sécurité et la supervision, dans un cadre de service défini au contrat. Chez Etixio, elle prend la forme d’une régie ou d’un forfait de maintenance, selon le contrat.

Quelle différence entre maintenance corrective et maintenance évolutive ?

La maintenance corrective traite les anomalies, c’est-à-dire les écarts entre le comportement attendu de l’application et son comportement réel. La maintenance évolutive ajoute ou modifie des fonctionnalités pour répondre à un nouveau besoin métier, réglementaire ou technique. La maintenance préventive, enfin, agit avant l’incident, en réduisant la dette technique et en tenant les composants à jour.

Pouvez-vous reprendre une application développée par un autre prestataire ?

Oui. Nous commençons par récupérer l’ensemble des accès et des sources, puis nous réalisons un état des lieux du code, des dépendances, de la base de données et du déploiement. Avant toute modification, nous sécurisons les parcours critiques par des tests et rendons la mise en production reproductible. La maintenance courante démarre ensuite sur une base maîtrisée.

Que faire si nous n’avons plus accès au code source ou aux serveurs ?

Il faut d’abord identifier qui détient chaque accès — hébergeur, registrar, dépôt de code, services tiers — et les faire transférer à votre nom. Nous vous aidons à dresser cet inventaire et à organiser la récupération. Lorsque le code source n’est pas récupérable, l’état des lieux porte sur ce qui est déployé et permet d’évaluer les options.

Pourquoi faut-il faire les montées de version de PHP et des frameworks ?

Une version qui n’est plus supportée ne reçoit plus de correctifs de sécurité et devient progressivement incompatible avec les bibliothèques récentes et certains hébergements. Plus la mise à jour est repoussée, plus l’écart à rattraper est important. Une montée de version planifiée, testée et réalisée par étapes est beaucoup moins risquée qu’une migration subie dans l’urgence.

Comment est défini l’engagement de service ?

Au démarrage, avec vous, selon la criticité de l’application. Nous définissons les niveaux de gravité des demandes, les délais de prise en charge, les plages d’intervention, le circuit de signalement et les indicateurs suivis. Ces éléments sont inscrits au contrat et revus lors des points de suivi.

Votre application mérite une maintenance organisée.

Présentez-nous l’application, son contexte technique et les difficultés rencontrées. Nous vous dirons comment la reprendre et la maintenir dans la durée.

Que recherchez-vous ?