Maintenance d’application métier : les clés de la réussite

Une application métier sur mesure peut parfaitement répondre aux besoins définis lors de sa conception et devenir progressivement moins adaptée quelques années plus tard. En effet, l’entreprise évolue, ses processus se transforment, les équipes changent, les volumes de données augmentent et les outils avec lesquels l’application doit communiquer sont eux-mêmes mis à jour. L’application, elle, ne s’adapte que si cette évolution a été prévue.

La maintenance d’application métier ne consiste donc pas uniquement à intervenir lorsqu’une anomalie bloque les utilisateurs. Elle englobe aussi les mises à jour techniques, la sécurité, les optimisations et les évolutions fonctionnelles qui permettent à l’outil de rester en phase avec son environnement.

Le projet d’application métier ne s’arrête pas une fois l’application mise en production, au risque d’exposer progressivement l’entreprise à une dette technique, à une baisse d’adoption et à des interventions plus coûteuses lorsqu’il devient nécessaire de rattraper le retard. Explications.

Maintenir l’application métier dans le temps

Une application métier n’est pas un produit figé que l’on peut considérer comme terminé une fois livré. Sa pertinence dépend de sa capacité à accompagner les évolutions de l’entreprise, mais aussi de son environnement technique.

Une application métier n’est jamais un livrable figé

Lorsqu’une application passe en production, le projet de développement est terminé, mais la vie de l’application ne fait que commencer. Les processus métiers peuvent évoluer, l’organisation interne peut changer, de nouvelles obligations réglementaires peuvent apparaître ou encore un outil tiers peut être remplacé.

Si l’on ne fait pas évoluer l’application métier malgré ces transformations, elle finit par créer un décalage avec les pratiques réelles. Certaines fonctionnalités deviennent inadaptées, certaines informations ne sont plus disponibles au bon endroit et l’outil risque de ne plus répondre aux besoins. En conséquence, ls utilisateurs chercheront des solutions alternatives à l’utilisation de l’application.

L’erreur du « projet terminé » est l’une des plus fréquentes côté client : considérer que l’objectif est atteint dès lors que l’application fonctionne conformément aux spécifications initiales. Or, ces spécifications décrivent un besoin à un instant donné. Elles ne peuvent pas prévoir toutes les évolutions que connaîtra l’entreprise dans les années suivantes.

Une application métier doit donc être considérée comme un outil vivant, dont la maintenance permet de préserver progressivement l’adéquation avec le métier. Et, l’amélioration continue est la meilleure solution pour faire évoluer l’application progressivement en restant à l’écoute des utilisateurs.

Les premiers signes d’une application vieillissante

Une application qui commence à ne plus répondre correctement aux besoins ne devient pas nécessairement inutilisable du jour au lendemain. Les premiers signaux sont souvent beaucoup plus discrets : les utilisateurs commencent à contourner l’outil.

On retrouve par exemple :

• une information saisie dans l’application puis ressaisie dans Excel ;
• des échanges par mail pour effectuer une opération qui devrait être gérée dans l’outil ;
• des tableaux de bord développés « maison » pour compléter ceux de l’application ;
• des tâches réalisées manuellement alors qu’elles pourraient être automatisées ;
• une baisse progressive de l’utilisation de certaines fonctionnalités.

Ces contournements constituent de véritables indicateurs d’usage. Ils montrent que l’application ne répond plus complètement à une situation rencontrée sur le terrain. L’usage de l’application se réduit progressivement jusqu’à son remplacement, parfois par un outil du marché moins adapté au fonctionnement de l’entreprise, mais perçu comme plus « vivant » et plus simple à faire évoluer.

L’entreprise risque alors de remplacer une application qu’il aurait été possible de faire évoluer progressivement.

Maintenance et évolution : deux dimensions indissociables

Maintenir une application métier ne signifie donc pas seulement la maintenir en état de fonctionnement. Il faut également lui permettre d’évoluer.

Les corrections permettent de résoudre les anomalies rencontrées. Les mises à jour techniques et de sécurité évitent que l’application ne repose progressivement sur des composants obsolètes. Les évolutions fonctionnelles, quant à elles, permettent d’intégrer les nouveaux besoins identifiés auprès des utilisateurs ou liés aux transformations de l’entreprise.

Cette approche présente aussi un intérêt économique. Faire évoluer régulièrement une application permet généralement d’éviter l’accumulation de modifications et de mises à niveau qui devront être réalisées dans l’urgence. Une application entretenue au fil du temps conserve et continue de créer de la valeur, contrairement à un outil laissé sans intervention pendant plusieurs années et qui nécessitera une refonte ou un remplacement.

Sachant que le coût de refonte ou de remplacement, quand il finit par arriver, est presque toujours supérieur à ce qu’aurait coûté une maintenance évolutive menée en continu.

Conseil pratique - Considérer la mise en production comme un point de départ et pas une fin. C’est le début d’un nouveau cycle : celui de l’utilisation, de l’observation et de l’amélioration continue de l’application. Pour cela, il faut garder un budget dédié à l’écoute des usages et prévoir un canal simple de remontée des irritants (formulaire, réunion mensuelle, ticket).

Anticiper la maintenance de l’application métier

La maintenance d’une application métier est souvent sous-estimée. Elle ne se limite pas simplement à corriger les anomalies signalées par les utilisateurs. Elle comprend trois dimensions complémentaires : corrective, préventive et évolutive. Les distinguer permet notamment de mieux anticiper les interventions et de prévoir un budget adapté.

La maintenance corrective : corriger les anomalies

La maintenance corrective correspond aux interventions réalisées lorsqu’un dysfonctionnement est constaté : erreur d’affichage, fonctionnalité qui ne répond plus correctement, problème de traitement ou anomalie dans les données.

C’est la forme de maintenance la plus visible pour les utilisateurs, puisqu’elle intervient généralement après l’apparition d’un problème. Elle ne doit pourtant pas occuper toute la place dans la stratégie de maintenance.

Mais se limiter à la maintenance corrective revient à attendre que les problèmes se déclarent. Or, certaines interventions doivent justement être réalisées avant qu’une anomalie ou une faille ne se manifeste pour que l’application reste fiable et compatible avec son environnement. C’est le rôle de la maintenance préventive.

La maintenance préventive : anticiper les problèmes techniques

La maintenance préventive regroupe les interventions qui permettent d’éviter que des problèmes techniques ou de sécurité ne se transforment en incidents.

Croire que tant que l’application fonctionne, ces interventions sont inutiles est une erreur courante. C’est le sujet où l’écart entre perception client et réalité technique est le plus grand. La maintenance préventive est justement celle qu’on ne voit pas, jusqu’au jour où son absence devient visible, généralement au pire moment.

> Les mises à jour : souvent négligées et pourtant primordiales

Il faut prévoir un budget dès le début du projet pour anticiper les mises à jour de sécurité, du code, des serveurs, des dépendances, etc. Plus on attend pour faire les mises à jour, et plus c’est coûteux et complexe, les repousser régulièrement ne fait qu’augmenter l’écart à combler. De plus, chaque version non appliquée s’ajoute à la dette technique à rattraper plus tard.

Une mise à jour effectuée régulièrement reste relativement simple. Mais, lorsqu’une application a accumulé plusieurs versions de retard faute de budget alloué, le jour où une évolution urgente est nécessaire ou qu’une faille de sécurité critique est découverte, il faut d’abord monter en version avant de pouvoir traiter le besoin initial.

Pour cela, il peut devenir nécessaire de vérifier la compatibilité du framework, des bibliothèques, du code métier et de l’infrastructure, voire procéder à une refonte partielle plutôt qu’une simple mise à jour.

Nous avons eu le cas avec l’un de nos clients. Le passage à une version supportée a nécessité un chantier dédié de plusieurs semaines avant de pouvoir livrer l’évolution fonctionnelle initialement demandée par le client. En conséquence, ce coût et ce délai non anticipés par le client, sur un sujet qui, traité en amont de façon incrémentale, aurait pu être lissé sur plusieurs mois à moindre coût.

À cela, s’ajoute le fait que cette obsolescence peut également compliquer la maintenance elle-même pour des questions de ressources humaines. En effet, plus une technologie s’éloigne des versions actuellement utilisées, plus il peut être difficile de trouver des développeurs (en interne, comme chez un prestataire) maîtrisant l’environnement concerné. Ce qui, une fois de plus, allonge les délais et fait grimper les coûts.

Enfin, stagner sur des versions obsolètes est dangereux en matière de sécurité.

> La veille sécurité à mener en continu

La sécurité est souvent le point le plus mal traité de tous. Elle ne se voit pas tant qu’il ne se passe rien, et c’est le premier poste qui saute quand le budget se resserre.

Prenons l’exemple d’une version PHP obsolète qui n’est plus prise en charge (fin de support). Cela signifie qu’il n’y a plus de correctifs de sécurité. Les vulnérabilités connues peuvent alors rester présentes dans l’application alors qu’elles ont déjà été corrigées dans des versions plus récentes.

Mais la sécurité ne se limite pas qu’au code applicatif : serveurs, dépendances tierces, CMS, certificats, accès, etc., sont très souvent aussi souvent laissés de côté.

Et croyez-nous, le jour où les problèmes arrivent, comme une fuite ou une compromission de données, le coût pour l’entreprise est bien plus élevé que celui d’une veille de sécurité menée en continu. Et l’on ne parle pas seulement du coût d’intervention, mais aussi du coût inhérent en termes d’obligations légales, de communication, d’image d’entreprise, etc.

La veille sécurité doit être un sujet permanent et un outil ne devrait jamais rester des années sans intervention, même sans demande d’évolution.

Conseil pratique - Provisionner dès le cadrage une ligne budgétaire dédiée à la maintenance préventive (montées de version régulières, veille sécurité) distincte du budget d’évolution fonctionnelle et raisonner en petits incréments réguliers plutôt qu’en gros rattrapages ponctuels.

La maintenance évolutive : accompagner les nouveaux besoins

Nous l’avons vu, la maintenance évolutive permet de faire évoluer l’application lorsque les besoins métier changent. Elle peut correspondre à l’ajout d’une fonctionnalité, à la modification d’un workflow ou à l’adaptation d’un traitement devenu inapproprié.

Mais, elle ne se limite pas qu’aux évolutions fonctionnelles. Par exemple, une optimisation technique peut également être nécessaire pour conserver de bonnes performances lorsque le volume de données augmente.

Cette distinction est importante, car une application peut être parfaitement fonctionnelle tout en ayant besoin d’évoluer.

Retenez qu’une application non maintenue peut progressivement devenir un risque opérationnel pour l’entreprise :

• indisponibilité du service ;
• perte de données (prévoir des sauvegardes régulières) ;
• incompatibilité avec les outils tiers ;
• impossibilité d’ajouter rapidement une évolution métier ;
• etc.

Faire évoluer l’application avec les usages réels

La faible adoption d’un outil métier est un risque fréquent, car une application techniquement performante (rapide, stable et sans bug) ne garantit pas son adoption. Si elle ne correspond pas ou plus aux pratiques métiers des utilisateurs, ces derniers peuvent développer des résistances ou mettre en place des mécanismes de contournement.

L’implication des utilisateurs doit donc commencer dès le début du projet d’application métier, pendant le développement, mais aussi après la mise en production avec des ateliers clients. Ces ateliers permettent de confronter les choix de conception aux pratiques réelles et d’inclure les utilisateurs dans la construction et l’évolution de l’application.

Les remarques remontant du terrain sont importantes à prendre en compte, car ce sont elles qui permettent d’identifier les points de friction et de faire évoluer l’application en fonction des usages réels.

En outre, cette inclusion permet de faciliter la prise en main de l’outil et éviter le risque d’utilisateurs réfractaires. En effet, une application métier perçue comme imposée « d’en haut », sans concertation, rencontre presque systématiquement de la résistance à l’usage.

Nos experts ont déjà rencontré ce type de situation lors d’une reprise de projet en TMA. Les utilisateurs n’avaient été impliqués qu’au moment de la recette. Plusieurs mois après la mise en production, l’utilisation de l’application restait bien inférieure aux attentes.

Le problème venait notamment du fait que l’ordre réel de traitement des dossiers ne correspondait pas à l’ordre prévu dans le workflow de l’application. Ce décalage n’avait pas été identifié dans les spécifications, faute d’ateliers terrain organisés suffisamment tôt dans le projet.

Dès lors que nous avons identifié ce décalage, un ajustement relativement simple du parcours a permis de relancer l’adoption.

Ce type de friction peut pourtant être évité facilement. Et plus la détection se fait tôt, moins la maintenance est coûteuse.

Bien évidemment, l’objectif ici n’est pas de répondre à chaque demande individuelle, mais de faire évoluer l’application en fonction des besoins métier réellement observés.

Conseil pratique - Traiter la formation et la documentation en parallèle du développement, et non comme une étape finale. Garder également des canaux de remontée terrain actifs après la mise en production pour recenser les irritants (formulaire, système de tickets, échanges réguliers).

Anticiper les évolutions des besoins métiers

Les besoins métiers changent. Une application métier évolue parce que son utilisation évolue, ainsi que l’entreprise. Ces évolutions doivent être anticipées pour éviter que le succès de l’application ne devienne lui-même une source de dette technique.

Un biais fréquent consiste à considérer que le périmètre défini au départ restera stable dans le temps. Or, une application métier qui fonctionne bien peut rapidement changer d’échelle.

Par exemple, une application qui répond correctement aux besoins avec quelques milliers de dossiers peut rencontrer des problèmes de performance lorsque le volume de données est multiplié par dix et qu’aucune des optimisations nécessaires (index, mise en cache, requêtes) n’a été prévue en amont. Même constat si l’augmentation du nombre d’utilisateurs n’a pas été prise en compte en amont.

Même si la dette technique est inéluctable, il faut anticiper ces seuils afin d’intervenir avant que les utilisateurs ne subissent une dégradation de l’application : augmentation des temps de réponse, perte des performances ou problèmes de stabilité, par exemple.

L’environnement technologique doit également être pris en compte dans cette projection. Les technologies utilisées par l’application évoluent et leurs cycles de support imposent d’anticiper certaines migrations.

Par exemple, le cycle des versions majeures de Symfony prévoit une nouvelle version tous les deux ans, avec une fenêtre de support limitée par version. Ce qui illustre bien que la dette technique n’est pas une question d’éventualité (« si une dette technique apparaît »), mais bien une question de temporalité (« quand elle apparaîtra », car elle est inévitable).

Conseil pratique - Intégrer un exercice de projection dès le cadrage (volume de données, nombre d’utilisateurs, usages attendus à un an et à trois ans) pour anticiper les paliers techniques avant qu’ils ne deviennent des urgences.

Mettre en place une gouvernance pour pérenniser l’application

La maintenance et les évolutions d’une application métier ne peuvent pas être gérées uniquement au fil des demandes. Toutes les évolutions n’ont pas le même impact ni le même niveau d’urgence.

Une gouvernance permet donc de prioriser les demandes en fonction des enjeux métiers et de conserver une vision partagée entre l’entreprise et le prestataire.

Un sponsor métier doit être clairement identifié du côté client. Il constitue le principal interlocuteur pour les décisions liées aux priorités de l’application et peut arbitrer entre les différentes demandes d’évolution. Si personne n’a explicitement le rôle de décisionnaire, alors les échanges s’enlisent en allers-retours entre plusieurs interlocuteurs.

Sans instance de pilotage clairement identifiée, les demandes peuvent venir de plusieurs utilisateurs ou services, sans qu’une vision commune permette de déterminer lesquelles doivent être traitées en priorité.

Le prestataire se retrouve alors à devoir arbitrer entre des besoins contradictoires, alors que ce n’est ni son rôle ni l’intérêt du client. En outre, des correctifs mineurs de confort semblant simples et urgents passent parfois avant des évolutions structurantes ayant un impact à moyen terme.

De plus, la mise en place d’un comité de pilotage régulier entre le client et le prestataire permet de conserver une vision commune. Sa fréquence dépend du volume d’évolutions et de la vie du projet. Il peut être mensuel ou trimestriel.

Ce comité peut s’appuyer sur :

• le backlog des demandes d’évolution ;
• la dette technique identifiée ;
• les indicateurs d’usage de l’application ;
• les éventuels problèmes ou irritants remontés par les utilisateurs.

L’objectif n’est pas de multiplier les réunions, mais de disposer d’une instance où les sujets sont examinés collectivement et où les décisions sont prises avec une vision d’ensemble.

Conseil pratique - Choisir un rythme permettant de garder une vision partagée entre client et prestataire pour éviter les décisions prises dans l’urgence, qui coûtent statistiquement le plus cher à long terme.

Les clés d’une maintenance durable d’application métier

Sur les projets accompagnés dans la durée, ce qui distingue le plus nettement une application encore pertinente cinq ou dix ans après sa mise en production n’est pas uniquement la qualité de son développement initial. C’est la présence d’une stratégie de maintenance continue et planifiée, plutôt qu’une logique réactive consistant à intervenir uniquement lorsqu’un problème apparaît.

Pour mettre toutes les chances de son côté, plusieurs éléments doivent donc être prévus et maintenus dans le temps. La checklist récapitulative à suivre peut être utilisée comme un cadre de pilotage.

Aucun de ces éléments n’est suffisant isolément. C’est leur combinaison, et surtout leur maintien dans la durée, qui permet à une application métier de continuer à créer de la valeur.

La maintenance d’une application métier ne doit pas être envisagée comme une succession d’interventions ponctuelles lorsque les problèmes apparaissent. Elle s’inscrit dans la durée, avec un suivi technique, une écoute des utilisateurs, des évolutions régulières et une gouvernance adaptée. Nos experts Adimeo peuvent vous accompagner dans la maintenance de votre application métier. En pratique, il vaut généralement mieux avancer par petits incréments réguliers que laisser s’accumuler plusieurs années de retard technique ou fonctionnel. Lorsqu’une mise à jour, une évolution ou une optimisation devient urgente, il est souvent déjà plus coûteux et plus complexe d’intervenir.

Crédit photo : bombermoon