Maintenance applicative : sécurité, mises à jour, ANSSI
La maintenance applicative d'une application web repose sur trois bonnes pratiques de sécurité que rappellent l'ANSSI et la CNIL : un rythme de mises à jour défini et tenu, des composants limités et surveillés, des sauvegardes séparées dont la restauration est testée. Aucune de ces trois tâches ne se fait seule. Pour une application sur mesure, elles doivent être attribuées à une personne nommée dans un contrat.
Je vends ce service, donc j'ai un intérêt dans le sujet. Une précision de méthode pour rester honnête : je n'ai pas trouvé, à la date du 1er novembre 2026, de guide de l'ANSSI intitulé « maintenance applicative ». Les recommandations ci-dessous viennent de documents plus généraux, que j'applique à ce cas précis. Quand c'est mon interprétation, je le dis.
Ce que disent vraiment l'ANSSI et la CNIL
Trois documents servent de socle. Le guide d'hygiène informatique de l'ANSSI réunit 42 mesures présentées comme un minimum, et concerne tout le système d'information plutôt qu'une application en particulier. Le guide Sauvegarde des systèmes d'information : les fondamentaux, en version 1.1 du 27 novembre 2025, traite spécifiquement des sauvegardes. Enfin, la fiche de la CNIL Sécuriser les sites web, publiée en mars 2024, est la plus directement applicable au web.
La page de l'ANSSI Sécuriser un site web renvoie, elle, vers un guide de 2021 centré sur les standards de sécurité côté navigateur. Il est utile à votre développeur, mais il ne remplace pas un plan de maintenance : il ne faut donc pas le citer comme une réponse à la question des mises à jour et des sauvegardes.
Mises à jour : décider d'un rythme, puis le tenir
Une application sur mesure n'a pas de bouton « tout mettre à jour » comme un CMS grand public. Elle dépend d'un langage, d'un framework et de dizaines de bibliothèques, dont chacune peut publier un correctif. La CNIL demande de limiter le nombre de composants, de les surveiller et de les tenir à jour. Moins il y a de dépendances, moins il y a de portes à garder : c'est une décision à prendre dès le développement.
La question concrète pour un dirigeant est simple : qui lit les alertes de sécurité, qui décide, qui déploie, et après quels tests ? Mon interprétation est qu'il faut distinguer deux régimes. Le correctif de sécurité d'une faille exploitée doit passer vite, avec un test ciblé. La montée de version majeure se prépare comme un petit projet, sur une copie de l'application. Mélanger les deux conduit soit à repousser les correctifs urgents, soit à casser la production dans la précipitation.
La fiche de la CNIL ajoute un contrôle facile à intégrer : rechercher les vulnérabilités régulièrement et avant chaque mise en production, avec des outils comme OWASP ZAP. Pour l'application métier, ce test se branche sur la chaîne de déploiement et devient une habitude. J'explique ses limites dans mon article sur les scans ZAP, car un outil automatique ne voit pas tout.
Sauvegardes : ce qui compte, c'est la restauration
Le guide de l'ANSSI recommande la règle 3-2-1 : trois copies des données (dont celles en production), sur deux supports différents, dont une hors ligne. La CNIL va dans le même sens. Elle suggère des sauvegardes incrémentales quotidiennes complétées par des sauvegardes complètes, au moins une copie hors ligne et une autre sur un site géographiquement distinct, ainsi que des tests réguliers de restauration. Son raisonnement est direct : une sauvegarde stockée au même endroit que les données peut disparaître avec elles lors d'un rançongiciel ou d'un sinistre.
Pour une application, il y a un piège supplémentaire. Restaurer la base de données ne suffit pas si les fichiers envoyés par les utilisateurs, les clés de configuration ou la bonne version du code manquent. Demandez donc une chose précise : un exercice de restauration complète sur un serveur vierge, avec sa durée notée. C'est lui qui vous dira combien de temps vous seriez à l'arrêt.
Si vous externalisez, le guide de l'ANSSI signale des risques propres aux environnements que vous ne maîtrisez pas, comme le cloud public ou la sous-traitance. Il recommande notamment de vérifier la localisation des données, de chiffrer les sauvegardes avant envoi et de prévoir des clauses de sécurité. Il considère aussi l'opérateur de sauvegarde comme un administrateur à hauts privilèges : un point à ne pas oublier quand vous confiez ces accès.
Ce qu'un contrat de maintenance applicative doit préciser
| Sujet | Question à poser | Risque si la réponse est floue |
|---|---|---|
| Veille de sécurité | Qui surveille les failles des composants, et comment suis-je prévenu ? | Un correctif publié mais jamais appliqué |
| Mises à jour | Quel rythme, quel environnement de test, quel retour arrière ? | Une panne en production après une mise à jour |
| Sauvegardes | Quel périmètre, quelle durée, quelle copie hors ligne ? | Des données perdues ou impossibles à relire |
| Restauration | Quand a eu lieu le dernier test, et combien de temps a-t-il pris ? | Un arrêt plus long que prévu |
| Accès | Qui détient le code, les comptes et la documentation ? | Une dépendance totale à un seul prestataire |
Quand ce n'est pas à un indépendant de s'en charger
Un développeur indépendant convient bien à une application métier de taille raisonnable, où l'échange direct avec la personne qui écrit le code fait gagner du temps. Il convient moins si vous avez besoin d'une astreinte jour et nuit, ou si vos obligations imposent une équipe de sécurité dédiée : une société spécialisée ou une équipe interne sera plus adaptée. Et si votre application n'est plus utilisée que par deux personnes, la bonne décision est peut-être de la retirer, ce qui supprime aussi ses risques.
Dans tous les cas, demandez à tout prestataire, moi compris, de montrer comment il travaille sur un cas comparable au vôtre : un exemple de rapport de maintenance, une procédure de restauration, un historique de correctifs.
Par où commencer
Commencez par noter trois dates : celle de la dernière mise à jour de sécurité, celle du dernier test de restauration, celle de la dernière vérification des accès. Si vous n'en trouvez aucune, vous tenez votre priorité. Je peux reprendre ce travail via mon offre de maintenance et d'hébergement, ou intervenir sur une application web existante écrite en Symfony, PHP ou React. Pour connaître mon prix, le plus simple est une demande de devis.