Moderniser SQL Server : distinguer la base et l’interface

Cartographier les dépendances du système

Relevez l’édition et la version du moteur, les bases concernées, les pilotes utilisés par les postes et les connexions ODBC. Identifiez les procédures stockées, vues, déclencheurs et tâches planifiées qui effectuent un travail métier. Un traitement peut s’exécuter la nuit et alimenter un tableau que les utilisateurs consultent le matin ; il peut être absent de la démonstration de l’interface tout en restant indispensable.

Documentez les comptes de service et leurs responsabilités sans communiquer leurs secrets. Vérifiez qui administre le serveur, qui peut restaurer une sauvegarde et qui connaît les échanges avec la comptabilité. Les droits de l’application future ne doivent pas se résumer à un accès administrateur partagé. Faites décrire les opérations nécessaires et les autorisations correspondantes.

Choisir une trajectoire proportionnée

Si le moteur répond au besoin et reste maintenu, une interface web peut être construite devant la base existante. Cette option demande de contrôler les accès concurrents et les règles que l’ancien client appliquait seul. Les validations ne doivent pas disparaître lorsque la saisie quitte le logiciel de bureau. Une modification du schéma peut être nécessaire, mais elle doit être distinguée d’un remplacement complet.

Une montée de version du moteur traite le cycle de support et la compatibilité technique. Un changement de moteur traite aussi les différences de types, de requêtes et d’exploitation. Faites comparer ces scénarios séparément. Le prestataire doit préciser lesquels préservent les intégrations existantes, lesquels nécessitent une adaptation et comment les performances sont vérifiées sur un jeu de données représentatif.

Prévoir l’exploitation après la mise en service

Demandez un environnement de recette distinct de la production et un processus de mise à jour. Les sauvegardes doivent inclure les éléments nécessaires au redémarrage, pas seulement un fichier de données. L’accès au serveur, la configuration de l’application et les tâches d’échange font partie du dossier d’exploitation. Un tiers doit pouvoir comprendre les dépendances sans découvrir les règles par essais sur les données actives.

Le DAF compare les licences et l’exploitation selon les options chiffrées, sans supposer qu’un moteur libre rend tout le projet gratuit. Le temps d’administration et les engagements du mainteneur restent à prendre en compte. La recette doit vérifier les totaux métier, les profils et les échanges. Une requête plus rapide sur un test isolé ne prouve pas que le système est prêt pour toutes les écritures concurrentes de l’entreprise.

Exercice fictif pour préparer la recette

Préparez un scénario fictif où l’interface crée une commande et où une procédure stockée met à jour son état. Le candidat explique où la validation est réalisée et ce qui se passe si l’interface envoie deux fois la même demande. Les contraintes de base et les messages utilisateur doivent fonctionner ensemble. Une erreur SQL brute ne constitue pas une réponse métier suffisante.

Faites ouvrir le même dossier par deux comptes puis modifiez une donnée importante. La recette constate comment la concurrence est détectée et comment la décision est présentée. Si une autre interface utilise encore la base, ajoutez son écriture au test. La nouvelle application ne doit pas supposer qu’elle est le seul producteur de données.

Demandez enfin un redémarrage sur l’environnement de recette à partir des éléments documentés. Le mainteneur doit retrouver les tâches, la configuration et les droits sans recourir à une connaissance personnelle non écrite. L’exercice distingue les besoins de nouvelle interface des besoins de maintenance du moteur et met en évidence les livrables d’exploitation à inscrire au devis.

Une fiche de consultation à remplir avec le métier

Pour utiliser cette grille, réunissez le responsable du processus, un utilisateur qui connaît les exceptions et la personne qui suivra le budget. Préparez un exemple fictif représentatif plutôt qu’une base réelle. Pour chaque ligne, faites décrire l’état actuel, le résultat voulu et la personne habilitée à arbitrer un écart. Les éléments inconnus restent identifiés comme des investigations à mener avant l’engagement de réalisation.

Demandez au candidat de reprendre cette grille dans sa proposition, avec les livrables inclus et les exclusions. Une réponse qui ne couvre qu’un cas normal doit être précisée. Les erreurs, les annulations et les reprises après incident peuvent modifier le coût et le fonctionnement. Conservez les hypothèses acceptées avec le périmètre de recette afin que le responsable puisse vérifier la livraison.

Le rôle de Suite Métier est la mise en relation. Le prestataire confirme la faisabilité, son architecture et son devis après examen du besoin. Les modalités de reprise, les droits contractuels et les engagements de support sont à convenir avec lui. Aucun délai de réalisation ni résultat financier n’est garanti par cette fiche. Le décideur reste maître du choix et de la réception.

Questions pratiques

Préparer la suite du projet

• Migration Access vers une application web : cadrage, reprise et devis
• Demander un devis et cadrer votre besoin
• SQL Server 2016 : préparer mise à niveau ou migration
• Access 2016 et 2019 : choisir la suite après le support
• Notre méthode de sélection et de traitement des demandes
• Cadrer le remplacement d’un outil Access ou Excel