Harsh Joshi
Co-founder & Technical Director
La maintenance des applications ne se limite pas à la correction des bogues. Découvrez les huit domaines couverts par un périmètre complet, ce qui en est généralement exclu, et comment les niveaux de service et les facteurs de coût déterminent ce dont vous bénéficiez.
La maintenance des applications comprend les tâches nécessaires pour garantir la sécurité, la fiabilité, la compatibilité et l'utilité d'un logiciel après son lancement. Elle englobe la correction des bogues, les correctifs de sécurité, la mise à jour des dépendances, l'optimisation des performances, la maintenance de l'intégration, la surveillance et les améliorations mineures.
Pour les entreprises qui s'appuient sur des applications sur mesure, la maintenance est une responsabilité technique permanente. Sans elle, les logiciels peuvent devenir vulnérables aux menaces de sécurité, incompatibles avec les nouvelles plateformes, plus lents à mesure que le volume de données augmente, ou plus coûteux à faire évoluer. C'est pourquoi les services d'ingénierie logicielle de Monarch Innovation incluent un accompagnement structuré après la mise en production, et ne se limitent pas au développement.
Cependant, savoir qu'une application nécessite une maintenance n'est qu'un point de départ. Les entreprises doivent également comprendre ce que couvre la maintenance, quelles activités n'entrent pas dans son champ d'application et ce qu'elles peuvent attendre d'un contrat de maintenance.
Ce guide présente le périmètre, les différents types, les niveaux de service, les coûts et les aspects à prendre en compte lors de la planification que les directeurs techniques, les responsables informatiques et les chefs de produit doivent connaître avant de choisir une approche de maintenance des applications.
En quoi consiste la maintenance d'une application ?
La maintenance des applications comprend généralement huit activités principales : correction des défauts, application des correctifs de sécurité, mise à jour des dépendances, maintenance de l'intégration, optimisation des performances, surveillance, améliorations mineures et mise à jour de la documentation.
Chaque activité porte sur un risque différent susceptible d'apparaître au fur et à mesure de l'évolution du logiciel.
- Correction de bogues et de défauts : identifier et résoudre les erreurs qui affectent le fonctionnement de l'application, l'exactitude des données ou l'expérience utilisateur.
- Corrections de sécurité : corriger les vulnérabilités connues dans le code des applications, les frameworks, les bibliothèques et les environnements d'exécution.
- Mises à jour des dépendances et des plateformes : mettre à jour les composants logiciels et adapter les applications aux évolutions des systèmes d'exploitation, des navigateurs, des plateformes mobiles et des services cloud.
- Maintenance des intégrations : veiller au bon fonctionnement des connexions avec les systèmes ERP, les plateformes CRM, les passerelles de paiement et les API tierces, malgré les évolutions de ces systèmes.
- Optimisation des performances : analyser les requêtes de base de données lentes, les fuites de mémoire et les goulots d'étranglement qui apparaissent à mesure que l'utilisation et les volumes de données augmentent.
- Surveillance et gestion des incidents : suivez la disponibilité des applications, les erreurs et les temps de réponse, puis analysez les alertes et les interruptions de service.
- Améliorations mineures : apporter des améliorations modestes et clairement définies, telles que l'ajout d'un filtre dans un rapport, l'optimisation d'un workflow ou l'amélioration d'un message d'erreur.
- Mises à jour de la documentation : mettre à jour la documentation technique, les instructions de déploiement, les guides d'exploitation et les registres de modifications afin que les futurs travaux de maintenance puissent être effectués en toute sécurité.
Imaginons une application de gestion des interventions sur le terrain utilisée par des centaines de techniciens. Une nouvelle version d'Android modifie les autorisations de localisation, un prestataire de paiement met fin à une version d'API et un tableau de bord de reporting devient plus lent à mesure que les enregistrements d'interventions s'accumulent.
Ces problèmes nécessitent des solutions techniques différentes, mais peuvent tous s'inscrire dans le cadre de la maintenance d'une application. L'objectif est de garantir le bon fonctionnement, la sécurité et la fiabilité de l'application existante à mesure que son environnement d'exploitation évolue.
Quels sont les quatre principaux types de maintenance des applications ?
Les quatre types de maintenance logicielle généralement reconnus sont la maintenance corrective, adaptative, perfective et préventive. Chacun d'entre eux répond à une raison différente justifiant la modification d'un logiciel après sa mise sur le marché.
| Type | Objectif | Exemple |
|---|---|---|
| Maintenance corrective | Réparer une panne existante | Résoudre une erreur de paiement qui rejette des paiements valides |
| Maintenance adaptative | Adapter le logiciel aux changements environnementaux | Mettre à jour une application pour un nouveau système d'exploitation ou une nouvelle version d'API |
| Entretien de perfectionnement | Améliorer les fonctionnalités, la convivialité ou les performances | Optimiser un tableau de bord lent ou simplifier un formulaire |
| Maintenance préventive | Réduire le risque de défaillances futures | Refactoriser le code fragile, améliorer la couverture des tests ou supprimer les dépendances obsolètes |
Ces catégories s'inscrivent dans la terminologie établie en matière de maintenance logicielle, notamment la norme ISO/IEC/IEEE 14764:2022, la norme internationale relative à la maintenance logicielle.
Certains cadres de maintenance abordent également la maintenance additive, qui consiste à ajouter des fonctionnalités à un logiciel déjà en service. La classification exacte utilisée peut varier en fonction du cadre ou de la norme appliquée.
Un plan de maintenance équilibré ne se limite pas à la résolution des bogues de production. Les interventions correctives rétablissent le bon fonctionnement, tandis que les actions adaptatives et préventives contribuent à réduire les perturbations futures. Les interventions d'amélioration permettent à l'application de rester en phase avec l'évolution des besoins des utilisateurs et de l'entreprise.
Maintenance des applications vs. Assistance aux applications
La maintenance des applications consiste principalement à modifier et à améliorer les logiciels. L'assistance aux applications consiste quant à elle à aider les utilisateurs, à analyser les problèmes opérationnels et à assurer le bon fonctionnement quotidien des applications.
Même si ces activités se recoupent, cette distinction est importante pour définir les responsabilités dans un contrat de prestation de services.
Le support applicatif est généralement organisé en trois niveaux :
- Niveau 1 (N1) : Traite les questions courantes des utilisateurs, les réinitialisations de mot de passe, les demandes d'aide pratique et l'enregistrement initial des tickets.
- Niveau 2 (N2) : examine les problèmes liés aux applications, analyse les journaux et les configurations, et met en œuvre les correctifs ou solutions de contournement connus.
- Niveau 3 (N3) : Gère des problèmes techniques complexes nécessitant une expertise en ingénierie, une analyse des causes profondes ou des modifications du code.
Ces limites varient selon les organisations. Par exemple, un ingénieur de niveau 3 peut diagnostiquer un défaut, tandis que l'équipe de maintenance se charge de développer, de tester et de déployer la solution définitive.
Les tests de régression sont également indispensables. Chaque modification du code doit être vérifiée afin de s'assurer que la résolution d'un problème n'en a pas introduit un autre. C'est pourquoi l'assurance qualité et les tests logiciels doivent faire partie intégrante du processus de maintenance.
Lorsque vous comparez des services de maintenance d'applications, vérifiez si l'assistance aux utilisateurs, la surveillance, les corrections techniques et la gestion des versions sont toutes incluses ou facturées séparément.
Qu'est-ce qui n'est généralement pas inclus dans la maintenance des applications ?
La maintenance courante des applications porte généralement sur un système existant. À moins que le contrat ne les mentionne explicitement, les projets de développement d'envergure, les modernisations à grande échelle et l'exploitation des infrastructures peuvent nécessiter une définition du périmètre et une tarification distinctes.
Parmi les exclusions courantes, on peut citer :
- Principales nouveautés : la mise en place d'un nouveau portail client, d'un moteur de tarification ou d'un module métier important nécessite généralement un devis de développement distinct.
- Modernisation des applications : la migration d'un système existant vers une nouvelle architecture, le remplacement de composants majeurs ou le transfert d'une application vers une autre plateforme constituent généralement un projet de modernisation à part entière.
- Infrastructures et opérations d'hébergement : l'administration des serveurs, la gestion de l'hébergement, les sauvegardes et la reprise après sinistre peuvent ne pas faire partie du périmètre de maintenance, bien que de nombreux fournisseurs les proposent en tant que services supplémentaires.
- Défauts de produits tiers : les problèmes survenant au sein d'une plateforme SaaS gérée par le fournisseur ou d'un produit sous licence peuvent devoir être résolus par ce dernier. L'équipe de maintenance peut examiner le problème et mettre en place une solution de contournement appropriée lorsque cela est possible.
- Opérations métier : la saisie de données, les mises à jour régulières du contenu et la gestion administrative des utilisateurs sont souvent prises en charge par les équipes métier ou le personnel de soutien.
La distinction la plus importante réside entre le maintien des fonctionnalités existantes et la mise en place d'une nouvelle fonctionnalité majeure.
Par exemple, l'ajout d'un simple filtre de rapport peut être considéré comme une amélioration mineure. En revanche, le développement d'un nouveau module de reporting intégrant des sources de données, des autorisations et une logique métier supplémentaires nécessitera probablement une estimation distincte.
Un contrat de maintenance doit définir clairement ces limites. Il convient de préciser le volume de travail maximal autorisé pour les modifications mineures, la procédure d'approbation des travaux supplémentaires, ainsi que les responsabilités en matière d'infrastructure, de sauvegardes, de certificats et de services tiers.
Liste de contrôle pour la maintenance des applications, classée par fréquence
Un calendrier de maintenance structuré aide les équipes à identifier les problèmes avant qu'ils ne se transforment en incidents coûteux. La fréquence appropriée dépend de la criticité de l'application, des exigences de sécurité, des pratiques de mise en production et du risque opérationnel.
| Fréquence | Activités typiques |
|---|---|
| Quotidien | Examiner les alertes de surveillance, classer les incidents par ordre de priorité, analyser les erreurs critiques et vérifier que les tâches planifiées et les processus de sauvegarde ont bien été menés à bien |
| Hebdomadaire | Examiner les listes de défauts en attente, analyser les erreurs récurrentes, vérifier les alertes de vulnérabilité et publier les correctifs approuvés présentant un faible risque |
| Mensuel | Passer en revue les correctifs de sécurité, les mises à jour des dépendances, les tendances en matière de performances, les autorisations d'accès et les dates d'expiration des certificats ou des licences |
| Trimestriel | Évaluer les mises à niveau des infrastructures et des environnements d'exécution, tester la restauration des sauvegardes, analyser la dette technique et planifier les améliorations en matière de capacité |
| Annuelle | Réaliser un bilan de l'état de santé des applications, examiner les dates de fin de vie des composants et mettre à jour la feuille de route de maintenance ainsi que le budget correspondant |
Ce calendrier constitue un point de départ et non une règle universelle. Les vulnérabilités critiques et les interruptions de service nécessitent une intervention rapide, sans attendre la fenêtre de maintenance prévue. Certaines applications requièrent également des mises à jour et des réévaluations des droits d'accès plus fréquentes en raison d'exigences réglementaires ou opérationnelles.
L'automatisation permet de réduire les tâches routinières. Les pipelines CI/CD, l'analyse des dépendances, les tests de régression automatisés et les alertes de surveillance aident les équipes à détecter les problèmes et à déployer les modifications de manière plus cohérente.
Pour les applications qui reposent sur une infrastructure cloud et qui font l'objet de mises à jour fréquentes, le cloud, le DevOps et l'ingénierie de la sécurité peuvent venir compléter le processus de maintenance.
Comment fonctionnent les niveaux de service liés à la maintenance des applications ?
Un accord de niveau de service (SLA) définit le service qu'un prestataire de maintenance s'engage à fournir. Il précise généralement les horaires d'assistance, les niveaux de priorité des incidents, les délais de réponse, les délais de résolution, les procédures d'escalade et les obligations en matière de rapports.
Un modèle de gravité courant comporte quatre niveaux.
| Gravité | Exemple | Approche classique de gestion |
|---|---|---|
| P1 : Critique | Application indisponible pour tous les utilisateurs ou incident de sécurité grave | Réponse immédiate, remontée des problèmes et poursuite des interventions jusqu’au rétablissement du service ou à la réalisation de l’objectif de rétablissement convenu |
| P2 : Élevé | Une fonction métier essentielle tombe en panne sans solution de contournement viable | Priorité accordée à l'enquête et objectif convenu en matière de correction ou de solution de contournement |
| P3 : Moyen | Une fonctionnalité ne fonctionne pas, mais une solution de contournement est disponible | Traitement et résolution planifiés en fonction de la priorité convenue |
| P4 : Faible | Une question d'ordre esthétique ou une demande d'amélioration mineure | Gestion du carnet de commandes et planification des livraisons |
Il s'agit là de catégories à titre indicatif, et non de délais de réponse garantis à l'échelle du secteur. Les objectifs précis doivent tenir compte de l'impact sur l'activité, du niveau de criticité de l'application, de la couverture du support et du contrat de maintenance.
Une plateforme de paiement destinée aux clients peut nécessiter une prise en charge des incidents critiques 24 heures sur 24, 7 jours sur 7. Un outil de reporting interne utilisé pendant les heures de bureau peut, quant à lui, présenter des exigences différentes.
Quels indicateurs permettent de mesurer les performances en matière de maintenance ?
Les indicateurs appropriés permettent de déterminer si la maintenance contribue à améliorer la fiabilité des applications et à réduire les risques opérationnels.
- Temps moyen de résolution (MTTR) : mesure le temps nécessaire à la résolution des incidents, selon la méthode de mesure définie par l'organisation.
- Disponibilité : permet de suivre la proportion de temps pendant laquelle l'application est disponible.
- Taux d'échec des modifications : mesure la proportion de déploiements qui se soldent par des échecs nécessitant une intervention ou une correction.
- Latence des correctifs : mesure le délai entre la mise à disposition d'un correctif de sécurité et son déploiement.
- Ancienneté du carnet de commandes : indique depuis combien de temps les défauts et les demandes de maintenance restent en attente de résolution.
Examinez ces indicateurs en tenant compte de la gravité des incidents et de leur impact sur l'activité. Une baisse du nombre de tickets ne signifie pas nécessairement une meilleure maintenance si des problèmes graves restent sans solution.
Quels sont les facteurs qui déterminent le coût de maintenance d'une application ?
Le coût de maintenance d'une application dépend de l'état de celle-ci, de la complexité de sa pile technologique, de l'étendue de l'assistance requise et du niveau de risque que l'entreprise doit gérer.
Les principaux facteurs de coût sont les suivants :
- Qualité du code et couverture des tests : les applications bien structurées et rigoureusement testées sont généralement plus faciles et plus sûres à modifier.
- À l'ère de la technologie : les frameworks non pris en charge et les environnements d'exécution obsolètes peuvent nécessiter davantage d'analyses, de mises à jour et de travaux de compatibilité.
- Complexité de l'intégration : chaque API externe, service de paiement, système ERP ou plateforme CRM introduit des dépendances susceptibles d'évoluer de manière indépendante.
- Exigences en matière de conformité et de sécurité : les obligations applicables, telles que le RGPD, la loi HIPAA ou la norme PCI DSS, peuvent entraîner une augmentation du volume de documentation, des tests, du contrôle d'accès et des tâches liées à la sécurité.
- Couverture de l'assistance : la gestion des incidents 24 heures sur 24 nécessite généralement davantage de ressources que l'assistance pendant les heures de bureau.
- Qualité de la documentation : l'absence de notes sur l'architecture, d'instructions de déploiement ou de rapports d'incidents peut allonger la durée de l'enquête.
- Criticité des applications : les systèmes prenant en charge des opérations essentielles peuvent nécessiter des tests, une surveillance, une planification de la reprise après sinistre et une procédure d'escalade des incidents plus rigoureux.
Les prestataires de services de maintenance ont généralement recours à des forfaits mensuels avec un nombre d'heures défini, à une tarification au temps et au matériel, ou à des équipes d'ingénieurs dédiées. Le choix du modèle le plus adapté dépend de la prévisibilité de la charge de travail, de la complexité de l'application et des ressources techniques nécessaires.
La maintenance doit également être prise en compte lors de l'évaluation des coûts de possession à long terme d'un logiciel. Le budget initial de développement ne reflète pas à lui seul les efforts continus nécessaires pour garantir la sécurité, la compatibilité et l'utilité du logiciel.
Pour avoir une vision plus globale de ces décisions, consultez le guide de Monarch Innovation consacré au développement, à l'achat ou à l'externalisation des logiciels d'entreprise.
Faut-il opter pour une maintenance en interne, externalisée ou hybride ?
Le meilleur modèle de maintenance d'une application dépend des capacités techniques internes, de l'importance de l'application pour l'entreprise et du niveau d'assistance spécialisée requis.
Maintenance en interne
Une équipe interne peut constituer un choix judicieux lorsque l'application est au cœur du produit et que les ingénieurs en maîtrisent déjà l'architecture. Le défi consiste à trouver le juste équilibre entre les tâches de maintenance, le développement de nouvelles fonctionnalités et les autres priorités de la feuille de route.
Maintenance externalisée
Un prestataire externe peut fournir des ressources d'ingénierie dédiées sans que l'entreprise ait à recruter chaque spécialiste en interne. La réussite repose sur un transfert de connaissances structuré, des contrôles d'accès clairs, des responsabilités clairement définies et un accord sur les niveaux de service.
Entretien hybride
Un modèle hybride associe une prise en charge interne à un soutien technique externe. L'équipe interne peut gérer les décisions relatives au produit et définir les priorités, tandis qu'un partenaire se charge des responsabilités convenues, telles que les mises à jour de sécurité, l'amélioration des performances, les mises à niveau, les tests et la résolution des défauts.
Avant de choisir un modèle, déterminez qui sera responsable du code source, des environnements de déploiement, des identifiants d'accès, de la documentation, de la remontée des incidents et des validations de versions. Ces responsabilités doivent rester clairement définies, quelle que soit la personne chargée des tâches de maintenance.
Comment élaborer un plan de maintenance d'une application
Un plan de maintenance des applications efficace commence par une bonne compréhension du portefeuille de logiciels et des risques opérationnels qui y sont associés. Un contrat doit s'appuyer sur cette évaluation plutôt que de s'y substituer.
Suivez ces étapes pour élaborer un plan concret :
- Faites l'inventaire de vos applications. Répertoriez les systèmes utilisés, leur finalité métier, leurs piles technologiques, leurs intégrations et les responsables techniques.
- Évaluer le niveau de criticité pour l'entreprise. Identifier les applications qui prennent en charge les processus essentiels et déterminer les conséquences d'une interruption pour l'organisation.
- Définir le périmètre de la maintenance. Préciser les activités incluses, les exclusions, les limites relatives aux améliorations mineures et les responsabilités concernant les dépendances vis-à-vis de tiers.
- Définir les niveaux de service. Établir les définitions des niveaux de gravité, les objectifs en matière de réponse et de résolution, les horaires d'assistance et les procédures d'escalade.
- Attribuer les responsabilités. Préciser les responsabilités en matière de code source, d'infrastructure, d'identifiants, de sécurité, de tests, de mises à jour et de coordination avec les fournisseurs.
- Définir des indicateurs de performance. Suivre les incidents, la disponibilité, les délais d'application des correctifs, les échecs de mise en œuvre des changements et les interventions de maintenance en attente.
- Réexaminez régulièrement ce plan. Réévaluez les priorités, les risques technologiques, les coûts et les niveaux de service à mesure que l'application et l'activité évoluent.
Un plan clair réduit les ambiguïtés et aide les entreprises à distinguer la maintenance essentielle des travaux nécessitant un projet de développement distinct.
Monarch Innovation accompagne les équipes d'entreprise et industrielles grâce à ses services d'ingénierie numérique, notamment le développement de logiciels sur mesure, le cloud et le DevOps, ainsi que l'assurance qualité. La coordination de ces compétences permet de réduire les transferts de responsabilité lorsque les modifications apportées aux applications concernent à la fois le code, l'infrastructure et les tests.
Vous ne savez pas exactement ce que couvre votre contrat de maintenance actuel ?
Discutez avec Monarch Innovation de votre application, de ses intégrations et des niveaux de service dont votre entreprise a besoin.
Discutez de votre candidature
