Audit SQL Server : décrire les symptômes avant les réglages
Notez l’opération lente, les utilisateurs touchés et les circonstances. Un export de fin de mois ne pose pas le même problème qu’un écran lent à chaque ouverture. Indiquez si l’incident est permanent ou lié à certaines périodes. Conservez les erreurs constatées et les changements récents, sans transmettre de données réelles ni d’identifiants dans une demande de devis.
| Symptôme | Piste à examiner | Preuve attendue |
|---|---|---|
| Une recherche ralentit sur certaines valeurs | Requête, plan et volumes traités | Mesures pour des paramètres comparables |
| Des saisies attendent simultanément | Blocages et transactions concurrentes | Chronologie des sessions concernées |
| Un écran reste lent alors que la requête est rapide | Interface, réseau ou échange externe | Mesure des étapes du parcours |
| Un traitement nocturne dépasse sa fenêtre | Ordonnancement et dépendances | Durées et incidents par étape |
| La restauration n’a jamais été essayée | Sauvegardes et procédure de reprise | Compte rendu de restauration sur environnement séparé |
L’audit logiciel de l’existant donne le contexte des usages. Le guide migration SQL Server et interface métier aide à distinguer mise à niveau, changement de base et refonte des écrans.
Examiner les requêtes et leurs dépendances
L’audit base SQL Server relève les requêtes associées aux parcours prioritaires, les procédures stockées et les tâches planifiées. Il décrit également les bases et logiciels qui lisent ou écrivent les mêmes données. Une modification d’index ou de requête doit être discutée à partir de ces dépendances et testée sur les opérations concernées.
La documentation Microsoft sur Query Store explique comment conserver un historique des requêtes, des plans et des statistiques d’exécution. Ces informations peuvent aider à comprendre un changement de performance. Leur disponibilité dépend de la configuration : l’absence d’historique doit apparaître dans les limites du diagnostic.
- Version, édition et configuration effectivement relevées.
- Parcours métier reliés aux requêtes et traitements.
- Échanges avec Access, Excel ou une autre interface.
- Historique disponible et mesures à recueillir.
Vérifier la reprise et l’exploitation
La disponibilité de la base ne résume pas la continuité du service. L’application peut aussi dépendre d’un fichier déposé, d’une tâche planifiée ou d’un compte de service. L’audit doit relever ces éléments et attribuer les responsabilités de surveillance, de sauvegarde et de restauration. Faites préciser ce qui a réellement été vérifié.
- Inventorier les dépendances qui servent les parcours prioritaires.
- Lire les procédures de sauvegarde et les journaux disponibles.
- Organiser un essai de restauration sur un environnement séparé.
- Vérifier que l’interface retrouve les données et les échanges attendus.
La CNIL recommande de tester la restauration des sauvegardes. Le guide hébergement de l’application web précise la répartition des tâches. Le plan de bascule et de retour arrière décrit le fonctionnement à prévoir lors d’un changement.
Si l’auditeur accède à des données personnelles pour votre compte, fixez les conditions d’intervention. La CNIL détaille l’encadrement de la sous-traitance. Les accès nécessaires au diagnostic doivent être définis avec l’administrateur, ainsi que leur retrait à la fin de la mission.
Transformer le rapport en décision de modernisation
Une conclusion utile sépare les corrections possibles dans la base, les modifications de l’application et les questions qui demandent des mesures complémentaires. Une nouvelle interface n’efface pas automatiquement une requête lente. Inversement, une base qui fonctionne correctement peut rester en place si le problème concerne surtout les parcours utilisateurs.
Le plan d’actions précise pour chaque mesure le risque métier, les prérequis et le test qui permettra de l’accepter. Reliez ces tests à la recette de l’application. Pour des règles réparties entre procédures et code de l’interface, complétez le diagnostic par un audit code source avant reprise.
- Constats mesurés et hypothèses encore à vérifier.
- Corrections proposées avec parcours de validation.
- Dépendances qui limitent une migration éventuelle.
- Options de conservation ou de remplacement de la base.
Le budget de développement logiciel doit distinguer l’audit, les corrections et une éventuelle refonte. La décision se prend après le diagnostic, sur les usages et les preuves, plutôt que sur un changement de moteur décidé à l’avance.
Questions pratiques
L’audit doit-il modifier la production ?
Définissez le périmètre avant l’intervention. La collecte et l’analyse peuvent constituer une première mission. Les modifications sont ensuite préparées avec l’administrateur, leurs tests et leur procédure de retour.
Quels livrables demander ?
Demandez l’inventaire, les mesures datées, les limites de la collecte et les recommandations classées. Chaque action doit être reliée à un symptôme ou à un risque observé, avec un moyen de vérifier son effet.
Sources
Sources officielles consultées le 1er octobre 2026.