Maintenance évolutive : définition, exemples et règles pour la piloter

La maintenance évolutive regroupe les travaux qui font évoluer une application en service : nouvelles fonctions, amélioration de l’existant, mise en conformité avec une règle nouvelle. Elle se distingue du correctif, qui répare, et de l’adaptatif, qui suit l’environnement technique. Ce guide en donne la définition, des exemples, et la façon de la cadrer avec un prestataire.

Il s’adresse aux dirigeants, aux DSI et aux responsables de produit dont l’application est en production et continue de changer. Dans un contrat de maintenance applicative (TMA), l’évolutif est la partie qui se décide au fil de l’eau : il engage le périmètre, le budget et les priorités.

Maintenance évolutive : définition

La maintenance évolutive désigne les travaux qui modifient ce que fait une application déjà en service, ou la façon dont elle le fait. On ne répare pas, on ne remet pas à niveau : on ajoute, on améliore, on met en conformité.

Le cahier des clauses administratives générales des marchés publics de techniques de l’information et de la communication, le CCAG-TIC 2021, en donne une définition qui sert de repère bien au-delà des marchés publics. Son article 38 entend par « évolutif » « les mesures de maintenance visant à faire évoluer une ou plusieurs applications ». Il range sous ce mot trois sortes de travaux.

• Ajouter des fonctions. Un nouvel export, un nouveau rôle d’utilisateur, une nouvelle étape dans un parcours.
• Améliorer le fonctionnement ou l’ergonomie. Un écran simplifié, un traitement plus rapide, une saisie moins longue.
• Tenir compte de nouvelles obligations légales ou réglementaires. Une règle change, l’application doit suivre.

Source : CCAG-TIC 2021, article 38 (arrêté du 30 mars 2021). Les exemples sont les nôtres.

Le même article définit la tierce maintenance applicative comme les prestations qui conservent un système d’information dans un état lui permettant de remplir sa fonction, et précise qu’elles peuvent aussi porter sur l’évolution ou l’adaptation des logiciels. L’évolutif fait donc partie d’une TMA quand le contrat le prévoit, pas d’office.

Évolutive, corrective, adaptative, préventive : les frontières

Les quatre familles de maintenance ne répondent pas à la même question. Les distinguer n’est pas un exercice de vocabulaire : chacune a son déclencheur et son degré d’urgence, et peut avoir son propre mode de facturation.

Définitions d’après le CCAG-TIC 2021, article 38. Les questions et les exemples sont les nôtres.

Anomalie ou évolution ? C’est la frontière qui fait naître les désaccords. Une anomalie est un écart par rapport à ce qui a été convenu : spécification, recette signée, comportement documenté. Si l’application fait ce qui était prévu et que ce n’est plus ce que l’on veut, c’est une évolution. La référence est un écrit, pas le ressenti de celui qui signale.

Adaptation ou évolution ? L’adaptatif absorbe un changement de l’environnement technique (système d’exploitation, base de données, interfaces d’échange, composants) sans rien ajouter au service rendu. Dès que l’on en profite pour modifier une fonction, la part ajoutée relève de l’évolutif.

Exemples de maintenance évolutive

Quelques cas, du plus léger au plus lourd.

• Ajouter un champ, un filtre ou une colonne dans un écran existant.
• Créer un nouvel export ou un nouveau modèle de document.
• Ouvrir un nouveau rôle d’utilisateur, avec ses droits.
• Brancher l’application sur un service tiers : paiement, signature, envoi de messages.
• Revoir un parcours que les utilisateurs jugent trop long.
• Accélérer un traitement devenu lent avec la croissance des données.
• Se conformer à une obligation nouvelle, comme la réception des factures électroniques ou l’accessibilité des services en ligne.

À l’inverse, n’en font pas partie : la correction d’un calcul faux (correctif), l’application d’une mise à jour de sécurité (préventif) ou le passage à une nouvelle version d’une base de données (adaptatif).

Évolution ou nouveau projet : où s’arrête la maintenance

Toute évolution n’a pas sa place dans un contrat de maintenance. Quatre signes indiquent que l’on sort de la maintenance pour entrer dans un projet.

• La taille. Le travail ne tient plus dans le rythme habituel des livraisons de maintenance.
• L’architecture. La demande touche au modèle de données ou à la structure de l’application, pas à un écran.
• Le public. Elle ouvre l’application à de nouveaux utilisateurs ou à un nouvel usage.
• Le risque. Elle demande une recette complète, une reprise de données ou une bascule planifiée.

Un projet se conduit autrement : cadrage, budget propre, équipe dédiée, calendrier. Le plus simple est d’écrire le seuil dans le contrat, par exemple une charge au-delà de laquelle une demande sort de la maintenance et fait l’objet d’un chiffrage séparé. Le chiffre dépend de l’application ; l’important est qu’il existe.

Comment une évolution se commande et se paie

Le correctif et le préventif se prêtent à un engagement forfaitaire : leur volume s’estime à partir de l’existant. L’évolutif, lui, dépend de ce que l’entreprise décidera. Trois façons de le contractualiser coexistent.

Les trois formules peuvent se combiner : une enveloppe pour les petites demandes, un devis au-delà du seuil. Dans tous les cas, deux règles protègent les deux parties : pas de développement sans accord écrit sur le périmètre et la charge, et un relevé du temps passé accessible sans avoir à le demander. Notre guide du contrat de maintenance applicative détaille les clauses correspondantes.

Piloter la maintenance évolutive : six règles

• Une seule liste de demandes. Toutes les évolutions y entrent, d’où qu’elles viennent, avec leur demandeur et leur raison d’être.
• Une qualification à l’entrée. Chaque demande est classée (anomalie, adaptation, évolution) avant d’être traitée.
• Des priorités fixées par le métier. Le prestataire chiffre et alerte ; l’ordre de passage se décide côté client.
• Un chiffrage avant le lancement. Avec ce qu’il comprend : développement, tests, documentation, mise en production.
• Des tests de non-régression. Une évolution ne doit pas casser l’existant : les tests et la recette font partie du travail, pas d’une option.
• Un point périodique. Ce qui a été livré, ce qui a été consommé, ce qui vient ensuite.

Ce que l’entreprise garde quand un prestataire fait évoluer son application

• Les droits sur le code ajouté. Avec un prestataire externe, ils supposent une cession écrite : payer un développement ne suffit pas à en détenir les droits, rappelle Bpifrance Création. Vérifiez que la cession prévue au contrat couvre aussi les évolutions, pas seulement la version d’origine.
• Le dépôt de code et les accès. Chaque évolution est livrée dans un dépôt au nom de l’entreprise.
• La documentation. Elle est mise à jour avec l’évolution, sinon elle cesse de décrire l’application.
• La décision. Ce qui entre dans l’application, et dans quel ordre, reste un arbitrage interne.

Ces points valent pour toute maintenance confiée à un tiers. Ils sont développés dans notre guide pour externaliser sa maintenance applicative.

Questions fréquentes

Maintenance évolutive : cadrez-la avant de la lancer

La maintenance évolutive est ce qui garde une application utile dans la durée. Elle se passe bien quand trois choses sont écrites : ce qui distingue une évolution d’une anomalie, la façon dont une évolution se chiffre, et qui décide des priorités.

L’équipe iones assure la maintenance applicative d’applications existantes, évolutions comprises, et peut commencer par un audit de l’existant. Vous pouvez aussi nous écrire pour un premier échange.