Moderniser le système que votre entreprise a dépassé
La base a été conçue il y a des années, pour une version plus petite de cette entreprise. Elle contient toujours tout — elle met simplement plus longtemps à répondre, se modifie plus difficilement et ne sait pas parler aux systèmes récents. C’est un problème différent de celui du remplacement.
Reconnaissez-vous ceci ?
Un rapport qui prenait quelques secondes prend des minutes, ou tourne la nuit.
Le même client existe trois fois, légèrement différemment.
L’application ne tourne que sur un serveur, et personne ne veut le redémarrer.
Le déploiement est une opération manuelle qu’on fait prudemment un vendredi.
Les systèmes récents n’atteignent les données que si quelqu’un les exporte.
Le système d’exploitation en dessous ne reçoit plus de mises à jour depuis un moment.
Ancien ne veut pas dire obsolète
Une base mûre est souvent le bien le plus précieux d’une entreprise. Elle contient des années d’historique et une structure qui a survécu au contact du réel — ce qu’on ne peut pas dire de la plupart des schémas neufs.
Ce qui vieillit, c’est rarement la conception. C’est le volume qu’elle porte désormais, les index qui convenaient à un dixième des données, les requêtes écrites avant qu’on sache lesquelles compteraient, et la plateforme en dessous qui arrive en fin de support. C’est l’entreprise qui a dépassé les hypothèses, pas le modèle.
La modernisation ici n’est donc pas une question de mode. L’objectif est un système qu’on peut modifier sans risque, interroger rapidement, et atteindre depuis d’autres logiciels.
Parfois la base va très bien
Souvent la base reste exactement où elle est et le travail se fait autour : une nouvelle interface web, une API pour que d’autres systèmes atteignent proprement les données, une couche de reporting, un portail client, une application mobile, ou des traitements planifiés qui remplacent des gestes manuels — le tout construit sur un cœur qui a déjà fait ses preuves.
C’est généralement le résultat utile le moins cher, et il est réversible comme une migration ne l’est pas. Nous le recommandons quand la structure est saine, bien que ce soit le plus petit chantier.
Parfois la réponse honnête est plus petite encore : la base n’a pas besoin d’être modernisée, elle a besoin de trois index et d’une requête réécrite.
Comprendre avant de modifier
Rien n’est touché avant qu’on sache ce qui en dépend : le schéma, les procédures stockées, chaque application qui s’y connecte, les tâches planifiées, les imports et exports qui tournent à des heures étranges, le reporting, le modèle de sécurité, et si les sauvegardes ont déjà été restaurées.
Ce dernier point compte plus qu’il n’y paraît. Un nombre surprenant de systèmes ont des sauvegardes que personne n’a testées, et une migration est le mauvais moment pour l’apprendre.
Améliorer la base, et la déplacer sans risque
Quand la base elle-même demande de l’attention, le travail relève généralement de l’indexation, de l’optimisation des requêtes, de l’amélioration du schéma, de l’archivage des données qui n’ont plus besoin d’être en ligne, des montées de version, et d’une supervision pour que le prochain ralentissement soit vu avant qu’un utilisateur ne le signale.
Quand elle doit être déplacée — vers de l’hébergement infogéré, AWS ou Azure — elle part avec une migration d’essai, des sauvegardes vérifiées et un plan de retour arrière, et généralement en parallèle de l’existant jusqu’à ce que les deux concordent.
Comment nous procédons
Comprendre
Relever le schéma, les dépendances, les tâches, le reporting et l’état des sauvegardes.
Décider
Séparer ce qui doit être corrigé de ce qui a seulement l’air vieux. Cela raccourcit souvent le chantier.
Construire
Indexer, optimiser, restructurer si besoin, et poser une interface ou une API moderne autour du cœur.
Déplacer
Migrer avec une restauration testée et un plan de retour arrière, en parallèle chaque fois que possible.
Rester
Superviser, pour que la performance soit une tendance qu’on observe et non un incident qu’on découvre.
Nous avons déjà résolu cela
NET Services — évaluation électrotechnique
NET gère les évaluations électrotechniques en Angleterre, au pays de Galles et en Irlande du Nord, dont un système interne de gestion des recours sur lequel l’organisation s’appuie au quotidien. Il ne s’agissait pas de le remplacer, mais de permettre aux candidats, aux organismes de formation et aux employeurs d’atteindre ce qu’il contient.
Nous avons construit la plateforme publique autour de ce cœur : un localisateur de centres consultable par lieu, code postal, région ou type d’évaluation, les disponibilités en temps réel, et une procédure de recours qui s’intègre directement au système interne pour que la demande d’un candidat arrive là où le personnel travaille déjà. Le système en dessous a continué de tourner pendant toute la durée.
Ce que cela implique généralement
Logiciels sur mesure
La nouvelle interface, le portail ou l’application construits autour d’un cœur qui tient.
Hébergement et informatique
Infrastructure infogérée, sauvegardes testées et supervision qui remarque en premier.
Les questions qu’on nous pose
Faut-il quitter SQL Server ?
Généralement non. Les montées de version, l’indexation et le travail sur le schéma règlent souvent la plainte réelle. Changer de moteur est un gros chantier et doit avoir une raison autre que l’âge.
La base peut-elle rester où elle est ?
Fréquemment, c’est même le meilleur résultat : le cœur reste et l’application, le reporting ou l’API autour changent. C’est moins cher et bien plus facile à annuler.
Nos rapports sont lents. Est-ce un projet de modernisation ?
Souvent non. La lenteur du reporting vient couramment de l’indexation, de la conception des requêtes ou du fait de rapporter sur une base transactionnelle en production. Cela se compte en jours, pas en mois, et nous préférons l’établir d’abord.
Pouvez-vous la déplacer vers le cloud ?
Oui, vers AWS ou Azure et vers des services de base infogérés quand ils conviennent. La migration compte plus que la destination : restauration testée, plan de retour arrière, fonctionnement en parallèle.
Personne ici ne sait comment elle a été construite. Est-ce un problème ?
C’est normal, et c’est la première chose que nous traitons. L’état des lieux produit une documentation que vous gardez, quelle que soit la direction prise ensuite.
Avant de le remplacer, découvrez ce qui vaut d’être gardé.
Vous n’avez pas besoin de connaître la réponse technique. Dites-nous ce qui vous gêne. Nous partirons de là.
Nous construisons et exploitons des systèmes d’entreprise depuis 2000. L’équipe qui le construit reste pour le faire tourner.
Engageons la conversation