Maintenance d'une application métier : ce qui se passe après la mise en production

La mise en production ressemble à une ligne d'arrivée. Pour une application métier, c'est en réalité un point de départ : à partir de ce jour, des personnes en dépendent pour travailler, et l'application doit continuer à fonctionner, à rester sûre et à suivre l'évolution de l'entreprise.

C'est le rôle de la maintenance. Le mot recouvre des réalités très différentes selon les prestataires, et c'est souvent là que naissent les malentendus. Voici ce qu'elle contient vraiment, comment elle s'organise, et les questions à poser avant de signer.

Une application ne reste pas stable toute seule

On imagine volontiers qu'un logiciel livré et recetté continue de fonctionner indéfiniment, tant qu'on n'y touche pas. C'est l'inverse qui se produit.

Une application moderne repose sur des dizaines de composants : un langage, un framework, des bibliothèques, un système d'exploitation, une base de données, un hébergement. Chacun reçoit régulièrement des correctifs, dont certains corrigent des failles de sécurité publiquement connues. Les navigateurs évoluent, les services tiers changent leurs interfaces, les certificats expirent.

Une application qu'on ne touche plus ne reste donc pas figée : elle s'éloigne peu à peu de son environnement, jusqu'au jour où une mise à jour imposée la fait tomber, ou où une faille connue reste ouverte.

Les premières semaines, une période à part

Les semaines qui suivent la mise en production ne ressemblent à aucune autre. Les utilisateurs découvrent l'application dans leurs conditions réelles, avec leurs vraies données et leurs vrais cas particuliers. Des anomalies que la recette n'avait pas révélées apparaissent, des parcours se révèlent moins pratiques que prévu, des demandes d'ajustement arrivent en nombre.

Cette période se prépare. Il faut savoir à l'avance qui recueille les retours, comment ils sont triés entre anomalie et évolution, et à quel rythme les corrections sont livrées. Un prestataire qui considère son travail terminé le jour de la mise en ligne laisse l'entreprise seule au moment où elle a le plus besoin d'appui.

Les quatre volets de la maintenance

La maintenance corrective. Elle répare ce qui ne fonctionne pas comme prévu : un calcul faux dans un cas particulier, un écran qui se bloque, un export qui échoue. Elle suppose un moyen clair de signaler l'incident et une règle de priorité selon sa gravité.

La maintenance préventive. Elle applique les mises à jour de sécurité et de dépendances avant qu'un problème n'apparaisse. C'est la plus invisible pour les utilisateurs, et pour cette raison la plus souvent négligée. C'est pourtant elle qui évite la majorité des mauvaises surprises.

La maintenance évolutive. Elle fait suivre l'application au métier : une nouvelle règle de calcul, un champ supplémentaire, un nouveau profil d'utilisateur, une obligation réglementaire. Les premières semaines d'utilisation réelle font presque toujours remonter des ajustements de ce type, et certains font gagner beaucoup de temps.

L'exploitation. Héberger, sauvegarder, superviser. Une sauvegarde n'a de valeur que si sa restauration a été testée. Une supervision n'a de valeur que si quelqu'un est prévenu quand elle sonne. Ce volet est parfois assuré par un autre prestataire que le développement, ce qui impose de bien définir qui fait quoi.

Ce qu'un contrat de maintenance doit préciser

Un contrat de maintenance se lit d'abord par ce qu'il ne dit pas. Voici les questions à poser, quel que soit le prestataire.

• Qu'est-ce qui est couvert, exactement ? Les quatre volets, ou seulement la correction des anomalies ? Les mises à jour de sécurité sont-elles incluses ou facturées à la demande ?
• Comment signale-t-on un incident ? Par quel canal, à quelles heures, et qui décide de son niveau de gravité ?
• Dans quel délai l'incident est-il pris en charge ? La réponse doit distinguer un blocage complet d'une gêne mineure. Un délai unique pour tout ne veut pas dire grand-chose.
• Qui héberge, qui sauvegarde, où sont les données ? Et à quelle fréquence les restaurations sont-elles testées ?
• Comment les évolutions sont-elles demandées et chiffrées ? Au cas par cas, dans un volume prévu à l'avance, ou incluses dans un abonnement ?
• Que se passe-t-il à la fin du contrat ? Documentation, accès, export des données : ces points se négocient bien mieux au départ qu'au moment de la séparation.

Un engagement qui n'est pas écrit n'est pas un engagement. Si une réponse reste floue à la signature, elle le restera le jour de l'incident.

Deux façons d'organiser la suite

Il existe principalement deux modèles, qui répartissent différemment les responsabilités.

Un développement au forfait, suivi d'un contrat de maintenance. Le produit est livré, puis un contrat distinct encadre sa vie. C'est un modèle lisible, à condition que le contrat de maintenance soit négocié en même temps que le forfait, et pas une fois l'application en production, quand le rapport de force a changé.

Un abonnement qui inclut tout. Le prestataire développe, héberge, maintient et fait évoluer l'application pour un montant mensuel. La maintenance n'est plus un poste à négocier à part : elle fait partie du service. La contrepartie est que le prestataire reste éditeur et exploitant de l'application, avec des droits définis au cas par cas dans le contrat.

Aucun des deux n'est meilleur dans l'absolu. Le premier convient à une entreprise qui veut piloter elle-même l'exploitation ou la confier à son propre service informatique. Le second convient à celle qui veut une application qui fonctionne, sans gérer la technique. Les formules proposées par LPR Studio sont détaillées sur la page des offres, et la question du budget associé est traitée dans notre article sur le prix d'une application.

Les signes d'une application mal maintenue

Certaines situations doivent alerter, même quand l'application semble fonctionner.

• Personne ne sait dire quelles versions elle utilise. Ni du framework, ni de la base de données, ni du système qui l'héberge.
• Les sauvegardes n'ont jamais été restaurées. Une sauvegarde jamais testée est une hypothèse, pas une garantie.
• Chaque correction en casse une autre. Signe d'une application sans tests automatisés, où chaque intervention se fait à l'aveugle.
• Les demandes d'évolution reçoivent toutes la même réponse : « c'est compliqué ». L'application est devenue trop risquée à modifier.
• Une seule personne connaît le code. Et rien n'est écrit.

Si plusieurs de ces signaux se cumulent, la question n'est plus de maintenir, mais de reprendre l'application en main, voire de la refondre.

La documentation, assurance de la suite

La meilleure protection contre une maintenance défaillante reste une application documentée : comment l'installer, comment la déployer, quelles sont ses dépendances, où sont ses données, quelles règles métier elle applique. Cette documentation sert au prestataire en place autant qu'à celui qui pourrait lui succéder.

Elle se demande au moment du contrat, pas au moment d'en changer. Ce qui est transmis à la fin dépend de la formule retenue et des droits définis au cas par cas dans le contrat : c'est une question à poser en même temps que celle du prix.

Une application métier se juge moins à sa livraison qu'à sa troisième année. Si vous préparez un projet, le prototype visuel permet de valider ce que fera l'application ; la maintenance, elle, décide de ce qu'elle deviendra.