Maintenance d’un logiciel sur mesure : que prévoir après le lancement ?

Séparer les types de travail

Une correction rétablit un comportement convenu qui ne fonctionne plus. Une adaptation permet de continuer à utiliser une interface, un système ou un service qui a changé. Une évolution ajoute ou transforme une fonction. Ces trois demandes peuvent toucher le même écran tout en exigeant des décisions et des budgets différents.

Distinguez également l'exploitation : surveillance, sauvegardes, capacité de stockage, renouvellement des services et gestion des accès. Le prestataire qui fournit le serveur ne connaît pas nécessairement les règles de calcul de l'application. Pour chaque tâche, indiquez le responsable et le point de contact. Une mention générale « maintenance incluse » ne permet pas de savoir ce qui sera traité.

Inventorier ce dont le logiciel dépend

Le code propre au projet utilise des bibliothèques, des outils d'exécution et parfois des services externes. Recensez les éléments qui peuvent nécessiter une mise à jour ou arriver en fin de support. Associez à chaque service son usage, son responsable, son mode de renouvellement et une procédure de changement d'accès.

OWASP recommande d'analyser les dépendances du projet et de traiter les vulnérabilités identifiées selon leur contexte. Une alerte doit être examinée, puis corrigée ou accompagnée d'une mesure adaptée ; le simple nombre d'alertes ne suffit pas à comprendre l'exposition. Ce travail est distinct de l'ajout de nouvelles fonctions demandées par les utilisateurs.

Définir une demande d'incident exploitable

Préparez un canal de signalement et une fiche courte : date, fonction concernée, compte ou rôle, étapes de reproduction, résultat attendu et effet sur l'activité. Une capture anonymisée peut aider. Évitez de diffuser des mots de passe ou des documents clients dans un outil de suivi dont les accès ne sont pas maîtrisés.

Exemple hypothétique : les utilisateurs peuvent consulter leurs dossiers, mais l'export de rapports échoue depuis une mise à jour. L'incident doit préciser quels exports échouent et s'il existe une solution temporaire. L'équipe technique peut alors reproduire le problème sans demander à chacun de modifier ses données au hasard.

• Distinguer indisponibilité totale, fonction bloquée et gêne avec contournement.
• Préciser les heures de prise en charge convenues et la façon de joindre le responsable.
• Séparer accusé de réception, diagnostic, contournement et résolution.
• Conserver la référence de l'incident et informer les personnes concernées de son évolution.

Préparer les mises à jour et les restaurations

Une modification doit être vérifiée sur un environnement adapté avant sa diffusion. Les contrôles portent sur le changement et sur les parcours qui pourraient être touchés. Pour une mise à jour de génération PDF, vérifiez aussi le téléchargement et l'envoi du document. Notez la version publiée, les changements de données éventuels et les conditions permettant de revenir en arrière.

Une sauvegarde n'est utile que si l'on sait la restaurer. Définissez les données qu'elle couvre, leur ancienneté maximale acceptable et qui peut lancer la récupération. Faites vérifier la restauration dans un environnement isolé. Un retour à une ancienne base peut perdre les saisies récentes : la procédure doit expliquer comment ces dernières seront identifiées et traitées.

Rendre le suivi et les coûts compréhensibles

Demandez une description des prestations récurrentes et des demandes chiffrées séparément. Les frais de serveur, licences et services externes doivent rester identifiables. Le besoin d'astreinte, la complexité des intégrations et la fréquence des changements influencent l'organisation du suivi ; aucun pourcentage universel du prix initial ne remplace ce périmètre.

Un relevé de suivi peut indiquer les incidents traités, les versions publiées, les contrôles réalisés et les décisions en attente. Il sert à décider ce qu'il faut maintenir, simplifier ou faire évoluer. Une application stable peut demander peu de changements fonctionnels tout en nécessitant des mises à jour de ses composants et des essais de restauration.

Prévoir la reprise par une autre personne

Vérifiez que le dossier de remise contient le code concerné, les instructions pour le lancer, la description des données, la procédure de déploiement et les tests utiles. Les services externes doivent avoir des titulaires identifiés. Les secrets se transmettent par un canal approprié ; un document de maintenance peut décrire leur emplacement sans les exposer.

La preuve de reprise consiste à faire fonctionner une copie avec la documentation fournie et les accès prévus. Si une étape dépend d'une action inconnue de l'auteur initial, complétez le dossier. Cette préparation facilite aussi les absences et les changements internes. Elle n'impose pas de changer de prestataire, mais permet de ne pas dépendre d'une mémoire individuelle.