Le logiciel est livré, l'équipe l'utilise, et tout le monde respire. Puis un navigateur se met à jour, un employé change de poste, une règle de prix évolue ou un serveur manque d'espace. Un logiciel sur mesure n'est pas fini le jour de la mise en ligne : il faut prévoir qui s'en occupe ensuite.
Cette question se règle mieux avant la signature qu'au moment du premier problème. Voici ce que recouvre la maintenance, ce qu'elle ne couvre pas et comment l'encadrer simplement.
Quatre types de travail à distinguer
Le mot « maintenance » regroupe des tâches très différentes. Les confondre mène à des malentendus sur ce qui est inclus et sur ce qui se facture.
- Les correctifs : le logiciel ne fait pas ce qui était prévu. Un calcul est faux, un courriel ne part pas, un écran plante.
- Les mises à jour techniques : le langage, les bibliothèques, la base de données et le serveur reçoivent des correctifs de sécurité qu'il faut appliquer.
- L'exploitation : sauvegardes, surveillance, gestion des accès, renouvellement des certificats et des services externes.
- Les évolutions : une nouvelle fonction, un nouveau rapport, une nouvelle étape dans le processus. Ce n'est pas un défaut, c'est du développement.
Un correctif répare un écart avec ce qui avait été convenu; une évolution change ce qui avait été convenu. Cette distinction suffit à régler la plupart des discussions.
Les mises à jour ne sont pas facultatives
Un logiciel qui fonctionne aujourd'hui peut devenir vulnérable demain sans qu'on y touche. Les composants qu'il utilise reçoivent des correctifs de sécurité, et certaines versions cessent d'être prises en charge.
Reporter ces mises à jour pendant deux ans les rend plus risquées : on doit alors franchir plusieurs versions d'un coup, et un changement qui aurait pris une heure demande une semaine. Un petit entretien régulier coûte généralement moins cher qu'une grande remise à niveau.
Les sauvegardes comptent seulement si on peut restaurer
Avoir des sauvegardes ne suffit pas. La vraie question est : combien de temps faut-il pour remettre le système en marche, et jusqu'à quel moment les données seraient-elles récupérées?
- Où sont conservées les copies, et sont-elles séparées du serveur principal?
- Combien de temps garde-t-on les anciennes versions?
- Quand a-t-on testé une restauration pour la dernière fois?
- Qui est prévenu si une sauvegarde échoue?
Une restauration testée sur un environnement de vérification vaut mieux qu'une promesse. Faites-en un essai après la livraison, puis de temps en temps.
Ce que vous devez posséder et connaître
La maintenance devient pénible quand une seule personne détient les clés. Dès le départ, assurez-vous de pouvoir répondre à ces questions :
- Le code source est-il dans un dépôt dont votre entreprise est propriétaire ou auquel elle a accès?
- Les comptes d'hébergement, de nom de domaine et de services externes sont-ils à votre nom?
- Existe-t-il une documentation pour installer, configurer et redéployer le logiciel?
- Pouvez-vous exporter vos données dans un format lisible?
Ces éléments n'empêchent pas de continuer avec le même développeur. Ils vous évitent d'être coincé si la collaboration prend fin ou si cette personne n'est pas disponible une semaine.
Encadrer les demandes sans alourdir le travail
Pas besoin d'un système compliqué. Un seul endroit pour déposer les demandes, avec une description de ce qui est observé, suffit : ce qui devait arriver, ce qui est arrivé, et un exemple précis si possible.
Le développeur peut alors classer chaque demande : urgente (le travail est bloqué), à planifier ou à discuter comme évolution. Les évolutions peuvent être regroupées et estimées ensemble, ce qui est souvent plus efficace que de les traiter une à une.
Choisir la forme de l'entente
Il existe plusieurs façons d'organiser le suivi, et aucune ne convient à tout le monde.
- Une banque d'heures : vous réservez du temps à utiliser pour les correctifs et les petites évolutions. C'est flexible, mais il faut suivre la consommation.
- Un forfait mensuel : il couvre les mises à jour, la surveillance et un volume convenu de demandes. Le budget est prévisible.
- Au besoin : vous payez seulement lorsque vous appelez. Cela convient à un outil peu critique, mais le délai de réponse n'est pas garanti.
Plus le logiciel est au cœur de vos opérations, plus il vaut la peine de préciser le délai de réponse attendu, les heures de disponibilité et ce qui arrive en cas de panne. Pour un outil dont dépend la production, un arrêt d'une demi-journée n'a pas le même effet que pour un rapport mensuel.
Si vous hésitez encore sur la forme du projet, l'article sur le coût d'un logiciel sur mesure aide à prévoir le budget initial, et celui sur le choix entre générique et sur mesure aide à décider si la solution sur mesure se justifie.
Ce qu'il faut demander avant de signer
- Que couvre la période de garantie après la livraison, et pour combien de temps?
- Comment sont traités les correctifs, les mises à jour de sécurité et les évolutions?
- Où sont hébergés le code, les données et les sauvegardes, et à qui appartiennent les comptes?
- Quelle documentation sera remise?
- Comment signaler un problème, et dans quel délai peut-on s'attendre à une réponse?
Un logiciel bien entretenu reste un outil fiable pendant des années. Un logiciel laissé à lui-même finit par devenir celui que personne n'ose toucher. Quelques décisions simples, prises au départ, font toute la différence.