Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Inventorier application, extensions, thèmes, serveur Web, version PHP ou autre moteur et base de données. Identifier leurs matrices de compatibilité. Une mise à jour du système ne garantit pas que l’application et ses extensions soient maintenues.
Avant intervention, vérifier sauvegarde de la base, fichiers et pièces jointes, puis restaurer un jeu de test isolé. Empêcher cet environnement d’envoyer de vrais messages, factures ou tâches programmées. Utiliser autant que possible des données fictives ou anonymisées.
Lire les notes de version et vérifier les migrations intermédiaires requises. Tester la combinaison application/extensions/runtime sur l’environnement isolé. Prévoir un créneau, un mode maintenance si nécessaire et une méthode de retour arrière complète. Une migration de schéma peut rendre l’ancienne application incompatible avec la nouvelle base.
Après mise à jour, tester connexion, recherche, création d’un objet de test, pièces jointes, tâches planifiées et envoi de notification contrôlé. Vérifier les journaux et la version affichée. Ne pas limiter le test à la page d’accueil.
Supprimer les composants inutilisés selon une décision documentée, fermer l’installation et protéger les fichiers de configuration, sauvegardes et dépôts de code. Réserver l’administration aux personnes habilitées, activer MFA lorsque disponible et limiter les droits du compte de base au besoin applicatif.
Un proxy inverse ou un WAF peut filtrer certains flux, mais ne remplace pas les correctifs et les permissions. Conserver les adresses réelles des clients par une chaîne de proxys de confiance pour que les alertes soient attribuables.
Retour arrière : restaurer ensemble la version du code et la base correspondante, en tenant compte des données créées depuis la sauvegarde. Informer les utilisateurs des pertes ou réconciliations nécessaires avant de rétablir un point ancien.
| Couche | Informations à relever | Pourquoi |
|---|---|---|
| DNS / proxy public | Nom, résolution, terminaison TLS | Une panne externe peut précéder l’application |
| Reverse proxy | Frontend, backend, en-têtes et certificat | Mauvais backend, boucle HTTPS ou IP client faussée |
| Serveur Web | Nginx/Apache, virtual host, répertoire servi | Ne pas exposer sauvegardes et fichiers de configuration |
| Runtime | PHP/Node/Python et extensions | Compatibilité avec l’application cible |
| Application | Version, méthode d’installation, modules | Procédure de migration et support |
| Base | Moteur, version, hôte, compte applicatif | Migration de schéma et droits |
| Données | Uploads, documents, configuration, clés | Ces éléments ne sont pas forcément dans la base |
| Tâches | Cron, files d’attente, mail, synchronisations | Une page d’accueil peut marcher avec les tâches en panne |
Créer une sauvegarde cohérente de la base, des fichiers et de la configuration. Reproduire l’application dans un environnement isolé, désactiver courriels, paiements et intégrations réelles, puis tester le chemin de mise à jour supporté. Ne pas sauter des versions majeures si l’éditeur l’interdit.
Vérifier plugins, thèmes et runtime avant la bascule. Un retour au code précédent ne remet pas automatiquement l’ancien schéma de base ; le retour doit restaurer un ensemble cohérent. Évaluer les données reçues pendant l’intervention et prévoir une suspension des écritures si nécessaire.
Décrire nom public, chemin privé d’administration, version, responsable, stockage système/données, dépendances, sauvegarde, compte de service, test de santé et méthode de reprise. Le secret n’apparaît pas dans la fiche : seul son emplacement dans le coffre. Définir le résultat métier attendu, par exemple créer un ticket de test et joindre un fichier, pas seulement obtenir HTTP 200.
Définir une URL de base cohérente avec HTTPS et les proxies de confiance. Limiter taille des uploads au besoin métier et à l’espace disponible, à chaque niveau proxy/runtime/application. Le répertoire d’uploads ne doit pas servir à exécuter du code arbitraire. Un compte de service doit écrire seulement là où nécessaire.
Configurer l’envoi SMTP avec hôte, port, mode TLS, authentification et adresse d’expéditeur autorisés par le fournisseur. Tester vers une boîte maîtrisée et vérifier le contenu, pas seulement « envoyé ». Une file bloquée se diagnostique avant relance : des milliers d’anciens messages pourraient partir. Isoler le stock avec sauvegarde et procédure approuvée avant réparation.
Tester visiteur anonyme, utilisateur normal et administrateur. Contrôler accès refusé aux données d’un autre utilisateur, connexion/déconnexion, recherche, upload, génération de document, mail et tâche planifiée. Vérifier logs serveur/proxy/base, espace et expiration des certificats. Tester depuis Internet et VPN selon le rôle de chaque interface.
Les guides WordPress, Dolibarr, Nextcloud, Samba et Jitsi détaillent les contrôles propres aux services.