Maintenance et exploitation de logiciel après le lancement : ce qui doit être réglé ensuite

Le schéma est connu. Un logiciel mis en service il y a deux ans affiche soudain un message d’erreur. L’employée du bureau appelle l’interlocuteur de l’époque, qui est désormais pris par un autre projet. L’accès au serveur est détenu par un prestataire que plus personne ne connaît, et le mot de passe se trouve probablement dans un e-mail de l’époque. Le temps que quelqu’un comprenne la situation, l’après-midi est terminé.

Dans ce scénario, le projet n’a rien fait de mal. Le logiciel remplit son rôle, la réception a été propre, les utilisateurs sont satisfaits. Ce qui manque, c’est un modèle d’exploitation, car le projet n’avait pas de place pour cela. Le développement a une fin et un budget ; l’exploitation n’a ni l’un ni l’autre. Elle dure tant que l’entreprise dure.

Cet article décrit ce qui devrait être réglé après le lancement. Il s’adresse à la direction et aux responsables internes qui utilisent ou planifient un logiciel sur mesure et veulent savoir quelles questions poser avant la mise en production. Il ne s’agit pas d’un outil, mais de responsabilités, de rythmes et de preuves.

Une idée utile au départ : un logiciel se comporte comme un bâtiment, pas comme un meuble. Il vieillit même sans usage, car son environnement change. Navigateurs, systèmes d’exploitation, bibliothèques et situations de sécurité continuent d’évoluer, que votre entreprise change quelque chose ou non.

La stratégie d’exploitation la plus courante est : ne toucher à rien tant que ça fonctionne. Elle paraît raisonnable, car tout changement comporte un risque. Mais elle ne fait que déplacer le risque. Une application qui n’a pas vu de mise à jour depuis deux ans ne devient pas plus stable ; son écart avec l’environnement grandit. Quand le saut devient finalement nécessaire, il est grand, difficile à tester et rarement planifiable.

Derrière cela se cachent plusieurs types de défaillances qui se manifestent rarement isolément. Les dépendances, c’est-à-dire les bibliothèques tierces dont se compose en grande partie un logiciel moderne, reçoivent des correctifs de sécurité qui ne sont jamais appliqués. Les sauvegardes tournent chaque nuit, mais personne n’a jamais tenté une restauration. L’accès de l’ancien développeur est toujours actif. Le certificat expire, et personne n’a la date dans son agenda.

S’y ajoute une faiblesse organisationnelle : le savoir est dans les têtes. Celui qui a construit l’application connaît des particularités notées nulle part, par exemple pourquoi une tâche nocturne doit s’exécuter à trois heures ou quel paramètre doit être repris lors du déménagement du serveur. Quand cette personne quitte le projet, le savoir part avec elle, et l’exploitation devient un jeu de devinettes.

La conséquence n’est pas la panique, mais la sobriété. Une politique d’exploitation n’a pas besoin d’être grande, mais elle doit exister et appartenir à quelqu’un. Les questions auxquelles elle répond sont limitées, et la plupart peuvent être réglées en une demi-journée si on les pose avant la panne plutôt qu’après.

Pour rendre l’exploitation concrète, il est utile de la décomposer en couches qui reposent les unes sur les autres. En bas se trouve l’infrastructure : serveur, réseau, système d’exploitation. Dessus tourne l’environnement d’exécution avec ses bibliothèques, et au-dessus l’application proprement dite avec ses données. Chaque couche a sa propre vitesse de vieillissement, ses propres responsables et ses propres types de défaillances, et on peut les examiner séparément.

Transversalement courent des sujets qui touchent chaque couche : accès, protection des données, surveillance et documentation. On les oublie volontiers parce qu’ils n’appartiennent à aucune couche en particulier. Une gestion des rôles, par exemple, n’est ni un sujet de serveur ni de la pure logique applicative, et une politique de suppression concerne la base de données, les sauvegardes et les journaux de la même manière.

La décomposition est surtout utile pour clarifier les responsabilités. En cas de panne, on décide en quelques minutes si la cause est en bas ou en haut. Mais si l’on n’a pas défini qui est responsable de quelle couche, la recherche commence chez le prestataire, qui renvoie à l’hébergeur, qui renvoie à l’application. Un simple tableau avec couche, responsable et suppléant résout ce problème avec une fiabilité surprenante.

L’ordre d’examen suit le dommage, pas la technique. Nous commençons par ce qui coûte le plus cher à perdre : les données et l’accès à celles-ci. Ce n’est qu’ensuite qu’il vaut la peine de parler de confort, de performance et d’évolution.

Pour l’exploitation, trois modèles sont possibles, et aucun n’est toujours le bon. Dans l’exploitation en interne, l’entreprise assure elle-même l’hébergement et l’entretien, ou avec un prestataire informatique local. Cela donne du contrôle, mais exige des compétences et la disponibilité d’être joignable aussi la nuit. Pour les petites entreprises, c’est rarement réaliste, sauf si l’application n’est pas critique.

Dans le deuxième modèle, le développeur exploite le logiciel dans le cadre d’un contrat de maintenance. L’avantage est que le code et l’exploitation sont entre les mêmes mains et que les erreurs sont rapidement circonscrites. L’inconvénient est la dépendance : si le contrat devient difficile ou que le prestataire change d’orientation, l’entreprise est confrontée à un changement qui, sans bonne documentation, coûte cher. C’est précisément pourquoi la réversibilité doit faire partie du concept dès le départ.

Le troisième modèle sépare les responsabilités. Un hébergeur exploite l’infrastructure, le développeur entretient l’application, et un tiers, souvent la direction ou un responsable interne, tient les fils. C’est le modèle le plus robuste, mais aussi celui qui comporte le plus d’interfaces. Il ne fonctionne qu’avec des interlocuteurs clairement désignés et un document commun indiquant qui fait quoi.

Nous recommandons en règle générale de séparer l’infrastructure et l’application, à condition que l’entreprise n’ait pas d’informatique propre. Cela limite la dépendance et permet de remplacer une partie sans tout reconstruire. La condition est que l’application puisse être remontée sur un autre serveur sans connaissances particulières, et cela se vérifie au lieu de se croire.

Un cadre d’exploitation se compose de quelques éléments que nous passons en revue comme une liste de contrôle avant la mise en production. Le premier est un rythme de maintenance : les dépendances et le système d’exploitation sont vérifiés à intervalles fixes, et les correctifs de sécurité très urgents sont traités hors calendrier. Le rythme relève moins de la technique que de l’accord, car il garantit que quelqu’un le fait.

Le deuxième élément est la gestion des rôles. Elle règle qui peut voir et modifier quoi dans l’application, et suit le principe du moindre privilège : chaque personne reçoit exactement les accès dont elle a besoin pour sa tâche. S’y ajoute une procédure pour les arrivées et les départs, afin que les comptes de collaborateurs partis ne restent pas actifs pendant des années. Cela vaut aussi pour les accès techniques tels que comptes serveur, utilisateurs de base de données et clés d’interface.

Troisièmement, la documentation. Il ne s’agit pas d’une bibliothèque de prose, mais d’un manuel d’exploitation allégé : schéma d’architecture, liste des environnements, stockage des identifiants dans un gestionnaire de mots de passe, description des tâches planifiées, étapes de redémarrage et interlocuteurs. Il doit être rédigé de sorte qu’une personne compétente mais extérieure puisse comprendre l’application en une journée.

Quatrièmement, les questions de propriété, qui ne sautent souvent aux yeux qu’en cas de litige. À qui appartient le code source, qui peut le modifier ou le transmettre, et où se trouve-t-il ? Nous jugeons judicieux que le code soit dans un dépôt auquel le client a son propre accès, et que les droits d’utilisation soient clairement réglés dans le contrat. Les détails juridiques relèvent du contrat et de l’examen par un juriste ; ici, il s’agit de l’aspect technique : l’accès ne doit pas dépendre uniquement de la bonne volonté du prestataire.

Pour les mises à jour de sécurité, ce qui compte est moins la fréquence que la capacité de les appliquer sans danger. Cela suppose un environnement de test proche de la production, des tests automatisés pour les processus les plus importants et un moyen d’annuler les modifications. Une mise à jour devient alors une opération de routine. Sans ces conditions, chaque mise à jour devient un défi, et par prudence on y renonce. Les outils qui vérifient les dépendances à la recherche de vulnérabilités connues fournissent la base de données pour cela, mais ne remplacent pas l’évaluation de la question de savoir si une alerte concerne vraiment sa propre application.

Pour les sauvegardes, la règle d’or est claire : une sauvegarde qui n’a jamais été restaurée est un espoir. Nous prévoyons donc des tests de restauration réguliers dans un environnement séparé et vérifions deux choses. D’abord, si les données sont complètes et lisibles. Ensuite, combien de temps il faut pour que l’application fonctionne de nouveau. Ce temps est le temps de restauration réel, et il s’écarte souvent fortement de l’hypothèse. De plus, au moins une copie doit être conservée dans un autre lieu, séparée du serveur et de ses identifiants, afin qu’une attaque ou une erreur ne détruise pas la sauvegarde en même temps.

La supervision répond à une question simple : le remarquons-nous avant les utilisateurs ? Quelques contrôles suffisent souvent. L’application est-elle joignable de l’extérieur, la base de données tourne-t-elle, y a-t-il assez d’espace libre, la tâche nocturne va-t-elle jusqu’au bout, quand le certificat expire-t-il ? Les alertes doivent parvenir à quelqu’un qui peut agir, et être assez rares pour être prises au sérieux. Une alarme qui se déclenche dix fois par jour sans raison finit vite par être ignorée.

Les journaux complètent le tableau. Les journaux d’erreurs de l’application révèlent des problèmes qu’aucun utilisateur ne signale, par exemple des appels d’interface échoués. Ils ne doivent toutefois pas collecter de données personnelles inutiles et devraient être supprimés après un délai défini. Ils touchent ainsi à la politique de suppression, que nous reprenons dans le chapitre consacré aux cas particuliers.

Le premier cas particulier concerne la protection des données. Les données personnelles ne doivent pas être conservées indéfiniment, et cela vaut aussi pour les sauvegardes et les journaux. Une politique de suppression définit quelles données sont conservées combien de temps et quand elles sont supprimées, et tient compte des obligations légales de conservation. Cela se veut une orientation technique, non un conseil juridique. Les délais concrets devraient être clarifiés avec votre délégué à la protection des données ou un conseil juridique. Sur le plan technique, il vaut la peine de prévoir la suppression comme fonction, car l’ajouter après coup est généralement coûteux.

Le deuxième cas est le changement de personnel des deux côtés. Lorsqu’une collaboratrice quitte l’entreprise, les comptes dans l’application, dans le gestionnaire de mots de passe et chez l’hébergeur doivent être adaptés. Lorsque le développeur change chez le prestataire, une deuxième personne devrait connaître l’application. Cela peut se vérifier : demandez qui intervient en cas de congés, et faites-vous montrer la réponse plutôt que de vous la faire raconter.

Troisièmement, l’héritage. Certaines applications tournent sur des versions pour lesquelles il n’existe plus de correctifs de sécurité. La maintenance est alors, au fond, une question de modernisation. Nous évaluons selon le risque : l’application est-elle accessible depuis internet, contient-elle des données sensibles, est-elle critique pour l’activité ? Selon la réponse, un cloisonnement du réseau suffit pour une période transitoire, ou une refonte progressive devient urgente. Une reconstruction complète est rarement la première étape.

Le quatrième cas est l’incident de sécurité. Celui qui détermine à l’avance qui il informe, ce qui est coupé en premier et qui parle aux clients agit plus calmement en situation d’urgence. Un plan d’urgence d’une page suffit : contacts, premières mesures, emplacement des sauvegardes. Des obligations de notification en cas de violation de données existent ; leurs détails relèvent d’un examen par des spécialistes et ne sont volontairement pas développés ici.

Enfin, la sortie. Un logiciel est réversible lorsque les données peuvent être exportées dans un format ouvert, que le code est chez le client et que l’environnement est documenté. Le but n’est pas de changer, mais de conserver sa position de négociation.

Une politique d’exploitation ne rend pas un logiciel invulnérable. Elle modifie la probabilité et les conséquences des perturbations. Les pannes deviennent plus rares parce que les vulnérabilités connues sont corrigées, et elles durent moins longtemps parce que la reprise a été exercée. Personne ne peut sérieusement garantir qu’il ne se passera rien, et celui qui le fait vend une sécurité qui n’existe pas.

Le bénéfice se mesure à l’aide de quelques indicateurs. Parmi eux : la disponibilité sur un mois, mesurée de l’extérieur, le temps mesuré jusqu’à la restauration depuis la sauvegarde, l’âge des correctifs de sécurité appliqués et le nombre de vulnérabilités connues et ouvertes dans les dépendances. S’y ajoutent des indicateurs plus souples : combien de temps faut-il à un nouveau développeur pour lancer l’application en local, et combien de perturbations ont d’abord été signalées par les utilisateurs ?

L’effort est continu et devrait être traité comme l’entretien d’autres installations. Un rapport avec le développement sert de repère, selon l’ampleur et la criticité de l’application. Un pourcentage général ne serait pas sérieux, car les applications petites et bien construites demandent peu, tandis que celles qui sont reliées à de nombreuses interfaces demandent nettement plus. Nous ne donnons une estimation qu’après un état des lieux.

Après six mois, on voit si le concept tient. Les rythmes ont-ils été respectés, le test de restauration a-t-il été répété, les accès sont-ils à jour ? Si ce n’est pas le cas, la cause est rarement technique. Le plus souvent, il manque un créneau dans l’agenda ou une responsabilité claire. Ce sont des problèmes solubles, mais ils ne se résolvent pas d’eux-mêmes.

L’une des sources de litige les plus fréquentes est la frontière floue entre maintenance et évolution. La maintenance préserve l’état existant : correctifs de sécurité, adaptation aux nouveaux environnements, surveillance. La correction d’anomalies élimine les écarts par rapport au comportement convenu. L’évolution étend le périmètre fonctionnel et constitue un nouveau projet avec son propre effort. Celui qui le définit à l’avance évite les discussions lorsque le souhait d’un nouveau champ est soudain qualifié d’anomalie.

Il existe néanmoins des cas limites. Si le format change dans une interface connectée, l’adaptation relève-t-elle de la maintenance ou de l’évolution ? Nous la rattachons à la maintenance lorsque le comportement existant doit être conservé, et à l’évolution lorsque le périmètre fonctionnel change. L’important est que le client et le prestataire connaissent la règle avant que le premier cas ne se produise.

En pratique, une liste commune des souhaits en attente, classés par urgence et par utilité, a fait ses preuves. Elle donne lieu, à intervalles fixes, à un petit lot de réalisations, au lieu que chaque idée déclenche aussitôt une intervention. Cela ménage le budget et la stabilité, car chaque modification est aussi un risque, et des modifications regroupées se testent mieux.

Un point que beaucoup sous-estiment : la dette technique grandit aussi à cause de solutions rapides bien intentionnées. Un provisoire qui n’est jamais remplacé fait, au bout de deux ans, partie du système. Une part du temps de maintenance devrait donc rester réservée au nettoyage, afin que l’évolution ne devienne pas à chaque fois plus chère que la précédente.

Un logiciel sur mesure est un outil doté d’un cycle de vie. Sa valeur dépend de sa capacité à fonctionner encore en toute sécurité après des années, de la possibilité de récupérer les données et de la capacité de l’entreprise à le poursuivre avec un autre partenaire. Les réponses ne tiennent pas à de gros budgets, mais à de petites décisions contraignantes, que l’on prend de préférence avant le lancement.

L’étape suivante est simple. Vérifiez quatre points pour votre logiciel : qui a accès, quand une restauration a-t-elle été testée pour la dernière fois, quel est l’âge des derniers correctifs de sécurité, et le code est-il chez vous ? Si l’une de ces quatre questions ne peut pas être résolue en quelques minutes, c’est votre point de départ.

Prévoyez pour cela un rendez-vous fixe et court chaque trimestre. Une heure suffit pour passer en revue les accès, le test de sauvegarde, l’état des correctifs et les souhaits en attente, et pour consigner les résultats dans le manuel d’exploitation. Ce rendez-vous est discret, mais il fait la différence entre une exploitation qui est entretenue et une qui continue seulement, on l’espère, de tourner.

Nous examinons volontiers cela avec vous, avec un état des lieux et une évaluation honnête du cadre d’exploitation qui convient à votre application. Que vous assuriez finalement l’exploitation vous-même, que vous l’externalisiez ou que vous la partagiez, c’est à vous de décider. Notre rôle est de faire en sorte que la décision repose sur des faits connus.