Après le lancement, quelqu’un doit s’occuper de l’application, de ses données et des services qu’elle utilise. Le travail dépend de ce sur quoi les gens comptent : un site de contenu et une application qui prend des commandes n’ont pas besoin des mêmes vérifications ni des mêmes plans de reprise.
Avant de convenir d’une maintenance, définissez ce qui demande de l’attention, qui est responsable de quoi et quelles preuves vous recevrez. Voici les questions que je passerais en revue avec vous.
Distinguez hébergement, maintenance et nouveaux développements
L’hébergement fournit l’infrastructure sur laquelle tourne votre logiciel. Selon le service, il peut aussi gérer une partie de la sécurité, des certificats ou des sauvegardes. Cela ne veut pas dire que quelqu’un vérifie que le paiement, la connexion ou les notifications fonctionnent encore.
La maintenance couvre le travail convenu pour que le produit actuel continue de fonctionner. Un nouveau développement change ce qu’il fait. Un contrat de suivi peut prévoir du temps pour les deux, mais une refonte, un nouveau parcours de paiement ou une intégration importante a besoin de son propre périmètre. Mettez cette frontière par écrit avant que le travail commence.
Demandez aussi quel support est inclus après la livraison initiale, pendant combien de temps et pour quoi. Savoir où s’arrête ce support aide à planifier le travail continu.
Gardez les dépendances à jour et vérifiez les mises à jour
Les applications reposent sur des bibliothèques, des frameworks et des services externes qui évoluent. Les correctifs de sécurité et les fins de support demandent de l’attention. Les mises à jour doivent être évaluées pour votre application et vérifiées sur les parcours importants avant d’arriver en production.
Le rythme dépend du risque et du produit. Une faille de sécurité urgente qui vous concerne ne devrait pas attendre le créneau mensuel habituel. Convenez de la façon dont ces cas sont signalés et traités, y compris quand le travail dépasse le cadre du contrat.
Sachez ce qui est sauvegardé et comment le restaurer
Le code dans un dépôt n’est qu’une partie de la reprise. Votre produit peut aussi dépendre de données clients, de fichiers envoyés et de la configuration des services. Demandez ce qui est sauvegardé, à quelle fréquence, combien de temps les copies sont conservées et qui peut les restaurer.
Choisissez la fréquence des sauvegardes selon la quantité de données que vous pourriez vous permettre de perdre. Par exemple, si la dernière sauvegarde réussie date de minuit et que la base de données tombe en panne à 17 h, restaurer cette seule copie ferait perdre les changements de la journée. Un produit qui prend des commandes n’a pas forcément besoin de la même approche qu’un site dont le contenu change chaque semaine.
Convenez aussi, à part, de la durée pendant laquelle le produit peut rester indisponible pendant la restauration. La quantité de données récupérables et le temps nécessaire pour les récupérer sont deux questions différentes.
Une notification de sauvegarde réussie ne prouve pas que l’application peut être restaurée. Testez la restauration dans un environnement séparé adapté et notez les étapes. Lesrecommandations du NCSC sur les sauvegardes conseillent elles aussi de vérifier que les sauvegardes contiennent les données importantes et que vous savez les restaurer.
Surveillez ce dont vos clients ont besoin
Une vérification de disponibilité vous dit qu’une page répond. Elle ne montre pas forcément que des e-mails ne partent plus, qu’une tâche de fond s’est arrêtée ou qu’un client ne peut pas finaliser un achat. Décidez quelles vérifications comptent pour le produit et où les pannes doivent être signalées.
La disponibilité de l’application et de ses services importants.
Les erreurs dans les parcours critiques, comme la connexion, le paiement ou la réservation.
Les tâches de fond, notifications et intégrations tierces en échec.
Le renouvellement du domaine, l’état du certificat, les limites de stockage et l’utilisation des services.
Chaque alerte a besoin d’un destinataire et d’une réponse convenue. Définissez les horaires pendant lesquels quelqu’un répond, comment signaler un problème urgent et qui contacter si cette personne n’est pas disponible. Un forfait mensuel n’implique pas une astreinte 24 h/24 ; cela doit être convenu explicitement.
Demandez ce que recouvre un engagement de réponse. Prendre en compte un problème, commencer l’analyse et rétablir le service sont des étapes distinctes. La formulation doit préciser quelle étape est couverte et ce qui se passe ensuite.
Revoyez les performances et les accès à mesure que le produit évolue
Les données grossissent, de nouvelles fonctionnalités arrivent et les vrais utilisateurs ne se comportent pas comme les comptes de test. Examinez les pages lentes et les opérations coûteuses quand un problème se manifeste. Partez de l’impact pour l’utilisateur, puis cherchez la cause, au lieu d’augmenter l’infrastructure par réflexe.
Revoyez les accès aux comptes quand des personnes arrivent ou partent. Tenez à jour la propriété des comptes et les dates de renouvellement, et documentez où se trouvent les services importants. Un produit ne devrait pas dépendre d’un compte oublié que personne dans l’équipe ne peut récupérer.
Demandez un plan de maintenance que vous comprenez
Avant de convenir d’un travail continu, posez ces questions :
Quelles applications, quels services et quels environnements sont couverts ?
Quelles vérifications et quelles tâches de routine auront réellement lieu ?
Qui est responsable des sauvegardes, des tests de restauration, des renouvellements et des factures des services ?
Quels horaires de réponse s’appliquent, et comment signaler un problème urgent ?
Comment le temps de correction ou d’amélioration est-il utilisé, et qu’est-ce qui demande un devis séparé ?
Quel compte rendu du travail fait et des risques restants vais-je recevoir ?
Que deviennent les accès et la documentation si nous arrêtons de travailler ensemble ?
Demandez un compte rendu écrit du travail effectué et des points ouverts. Par exemple, un point de maintenance pourrait dire :
Fait : mise à jour des dépendances de l’application et vérification de la connexion, de la réinitialisation du mot de passe et du principal parcours de réservation en préproduction avant la mise en ligne.
Test de reprise : restauration de la dernière sauvegarde de la base de données dans un environnement séparé et contrôle d’un échantillon d’enregistrements. Les fichiers envoyés ne sont pas encore inclus dans ce test.
Décision nécessaire : l’espace de stockage utilisé augmente. Les options et leur impact attendu sont listés pour examen avant tout changement.
C’est un exemple du niveau de détail à demander, pas la promesse d’un calendrier mensuel précis. Votre plan devrait indiquer quelles vérifications s’appliquent à votre produit et à quelle fréquence.
Partez du produit que vous avez
Pour un premier regard sur un site public, vous pouvez lancer monbilan de santé du site ou l’audit du site. Ils peuvent faire ressortir des points qui méritent d’être examinés. Ils ne peuvent pas inspecter le code privé de l’application ni prouver que vos sauvegardes et les parcours de vos clients fonctionnent.
Si vous souhaitez un suivi dans la durée,parlez-moi de votre produit, des services qu’il utilise et de ce que vous voulez couvrir. Nous pouvons définir un contrat de suivi selon ces besoins, ou cadrer d’abord un ensemble précis d’améliorations.