La virtualisation des données, expliquée simplement : tout interroger, ne rien copier

Le problème : vos données vivent à cinq endroits

Toute entreprise qui grandit finit au même point. Les ventes vivent dans l'ERP. La comptabilité a son propre logiciel. L'exploitation tourne sur des tableurs. Ajoutez un outil de projets, un CRM, ou dans la construction un modèle BIM avec des milliers de composants. Chaque système fonctionne très bien tout seul.

La douleur commence quand il faut une réponse qui les traverse. Quels clients commandent plus ce trimestre mais paient plus tard ? Quelles machines coûtent plus en maintenance qu'elles ne produisent ? Quelqu'un exporte trois fichiers, les colle dans un tableur, et le temps de finir le rapport, les chiffres sont déjà vieux. Le mois suivant, on recommence.

La réponse habituelle : tout copier au même endroit

La solution classique est de construire une copie centrale, souvent appelée entrepôt de données. Chaque nuit, les données de chaque système y sont extraites et chargées. Ça fonctionne, et pour certains besoins analytiques lourds, ça reste le bon outil. Mais pour une PME, la facture est salée : un projet de plusieurs mois avant le premier résultat, des pipelines qui cassent dès qu'une source change, et une copie permanente de tout qu'il faut désormais stocker, sécuriser et maintenir synchronisée.

Et la copie a toujours un temps de retard. Au mieux, vous décidez sur les chiffres d'hier.

La virtualisation : interroger les données là où elles vivent

La virtualisation des données prend le chemin inverse. Pensez à un réseau de bibliothèques. Plutôt que de déménager tous les livres dans un bâtiment géant, on construit un catalogue unique qui sait où se trouve chaque livre et va le chercher à la demande. Les livres ne bougent jamais. C'est le catalogue que vous consultez.

Concrètement, une couche de virtualisation se connecte à chacun de vos systèmes, apprend ce qu'ils contiennent, et traduit vos questions dans le langage de chacun. Vous posez une question à un seul endroit. La couche assemble la réponse en direct, à partir des vraies données, et ne garde jamais sa propre version de la vérité.

Ce que ça change en pratique

• Des réponses fraîches : une requête lit les données actuelles, pas l'export de la veille.
• Pas de projet de migration : vos systèmes restent en place, le premier résultat utile arrive en jours plutôt qu'en mois.
• Une seule source de vérité : chaque système reste la référence pour ses propres données, il n'y a rien à réconcilier.
• Moins à sécuriser : pas de seconde copie de toute l'entreprise qui circule.
• La liberté de changer : remplacez un système source et seule la connexion change, pas tout l'édifice.

Les vrais compromis

Aucune architecture ne gagne partout, et prétendre le contraire vend mal. Les requêtes en direct dépendent de la disponibilité des systèmes sources : une bonne couche de virtualisation utilise donc un cache pour garder les questions fréquentes rapides. La virtualisation ne nettoie pas non plus les données à votre place : si deux systèmes écrivent le nom d'un client de trois façons, il faudra toujours trancher. Et pour de l'analyse historique très lourde sur des milliards de lignes, un entrepôt garde sa place.

Pour le quotidien d'une PME, en revanche, l'échange est généralement excellent : l'essentiel de la valeur est dans le croisement de données opérationnelles vivantes, pas dans leur double archivage.

Pourquoi LOBI-SYSTEMS a construit Senga dessus

Senga est né d'un cas difficile : les projets de construction, où un modèle BIM est déjà une base de données de milliers d'objets, à côté d'un ERP, d'inventaires et d'outils de planification. Tout copier dans un entrepôt aurait été un projet que personne n'avait le temps de mener. Connecter s'est révélé la meilleure idée, et ça fonctionne aujourd'hui dans n'importe quel secteur.

La stratégie correspond aussi à notre façon de construire. Vos données restent les vôtres, sur votre infrastructure, et Senga ne les duplique pas. Vos systèmes continuent de parler les standards qu'ils parlent déjà, que ce soit SQL, Excel ou IFC. Et vous obtenez quelque chose d'utile en quelques jours, parce qu'aucune migration géante ne se met en travers.