Votre logiciel mérite une équipe dédiée pour durer

Le développement classique crée un logiciel de zéro. La TMA (Tierce Maintenance Applicative) prend en charge un logiciel existant en production : corrections de bugs, montées de version, nouvelles fonctionnalités, sécurité. C'est un engagement dans la durée, avec une équipe qui connaît votre code.

Tout ce qui traite un défaut avant qu'il se manifeste en production : mises à jour mineures des dépendances, audit CVE pour les failles de sécurité, mise à jour des outils d'analyse du code, nettoyage de code obsolète. Elle est souvent négligée parce qu'elle ne produit rien de visible, et c'est pourtant elle qui évite les crises. Ce qu'elle ne couvre pas : l'optimisation des performances, qui améliore un logiciel qui fonctionne déjà et relève donc du perfectif.

Oui. Nous commençons par un audit technique pour comprendre l'architecture, identifier les points sensibles et évaluer la dette technique. Cet audit produit un plan d'action priorisé avant que la maintenance courante démarre.

Un incident critique, c'est un logiciel inutilisable ou une donnée en danger. Il est pris en charge sous 4 heures ouvrées, du lundi au vendredi, de 9 h à 18 h. Prise en charge veut dire qu'un développeur qui connaît votre projet travaille dessus, pas que la correction est livrée : si la remise en service prime, une mesure de contournement rétablit d'abord l'usage, et la correction de fond suit. Les incidents majeurs et mineurs sont pris en charge sous 24 et 72 heures ouvrées.

Sur un budget annuel en trois lignes. La maintenance technique, ce que nous faisons à notre initiative, sur une enveloppe de jours que nous vous conseillons d'après le niveau de suivi retenu. La maintenance client, ce que vous nous demandez, sur vos jours. Le Pack hébergement, ce qui fait tourner l'application. Les demandes sont priorisées ensemble à chaque point projet, et tout ce qui est réalisé est documenté et livré sur un environnement de recette avant mise en production.

C'est très fréquent. Nous intégrons progressivement des tests sur les parties critiques au fil des interventions. Cela fait partie de notre approche : chaque passage laisse le code dans un meilleur état qu'avant.

La plupart des librairies open source sont développées et maintenues bénévolement. Quand le mainteneur arrête d'y consacrer du temps (changement de carrière, projet personnel, perte d'intérêt) : la librairie n'est plus mise à jour. Sans maintenance, les nouvelles failles de sécurité restent ouvertes et la compatibilité avec les versions récentes de PHP ou de Symfony n'est plus assurée. C'est pourquoi nous remplaçons proactivement les librairies abandonnées par des alternatives actives, plutôt que d'attendre un incident.

Une CVE (Common Vulnerabilities and Exposures) est un identifiant public attribué à une faille de sécurité découverte dans un logiciel ou une librairie. Elles sont publiées sur des bases de données publiques (NVD, GitHub Security Advisories) dès qu'une vulnérabilité est confirmée et documentée. On ne peut pas anticiper leur apparition : elles dépendent de la découverte d'une faille dans un code existant, parfois vieux de plusieurs années. Ce qu'on peut faire, c'est surveiller les CVE publiées sur les dépendances utilisées et appliquer les correctifs rapidement : c'est précisément ce que couvre la maintenance préventive.

Quand votre logiciel est connecté à un service externe (CRM, ERP, plateforme de paiement, API partenaire…), il s'appuie sur l'interface de programmation (API) de ce service. Si le fournisseur modifie cette interface (changement de format de données, renommage d'un endpoint, suppression d'un paramètre), votre logiciel peut cesser de fonctionner correctement, même si votre code n'a pas changé. Ce type de changement est souvent annoncé avec un préavis, mais pas toujours. C'est le domaine de la maintenance adaptative : le travail n'a pas été déclenché par un défaut de votre logiciel, mais par une décision prise ailleurs, et il n'en est pas moins à faire.

Les deux, selon l'état du socle. Passer de Symfony 6 à 7 quand le socle est suivi tient dans l'enveloppe de maintenance technique, au rythme de la politique de version choisie au contrat. La même montée sur une application laissée trois ans sans intervention est un chantier à cadrer et à estimer : une offre ponctuelle de remise à niveau, préalable au contrat. Dans les deux cas, la nature du travail est identique : ce n'est ni un bug ni une nouvelle fonctionnalité, c'est l'environnement qui a bougé. Nous le rangeons donc dans l'adaptatif, et non dans le correctif où il passerait pour inclus et sans arbitrage.

Un mail regroupe souvent plusieurs demandes : la première étape est de les découper en tickets autonomes. Chacun est ensuite qualifié dans notre outil de suivi selon l'un des cinq types, puis suit le même cycle, du backlog à la clôture. Cette qualification détermine le délai de traitement prévu au contrat ; la priorisation entre tickets, elle, se décide avec vous.