Naissance de NextSight : rendre les données accessibles aux métiers

NextSight est né au cours d'une mission de support informatique. Des équipes métier avaient régulièrement besoin d'extraire des données issues de plusieurs applications pour les exploiter. La question posée semblait souvent simple. Obtenir une réponse fiable l'était beaucoup moins.

Prenons un exemple : « Combien avons-nous vendu de produits A récurrents en 2025 qui n'ont pas été reconduits en 2026 ? » Pour répondre, il faut retrouver les bonnes tables (commandes, produits, ventes), comprendre le rôle de leurs colonnes, identifier les relations et construire les filtres qui traduisent réellement la question métier.

Quand on connaît bien les bases de données, le résultat peut être juste et immédiatement exploitable. Mais cette efficacité repose sur une connaissance souvent implicite du système d'information, concentrée chez quelques personnes.

Le vrai sujet n'est pas « écrire du SQL plus vite ». Le vrai sujet est de rendre l'extraction et l'exploitation des données accessibles à des personnes encore trop dépendantes du SI.

Une question métier cache un travail technique

Les équipes n'ont pas besoin d'une table ou d'une requête pour elle-même. Elles cherchent une information qui les aidera à décider. Entre leur question et cette information se trouvent pourtant la structure des bases, le vocabulaire propre aux applications, les règles de gestion et les connaissances accumulées par les personnes qui maintiennent le système.

Chaque nouvelle demande peut donc déclencher le même processus :

1. identifier les sources qui contiennent les données utiles,
2. comprendre la fonction des tables et des colonnes,
3. traduire la question métier en filtres fiables,
4. extraire puis présenter le résultat sous une forme exploitable.

Le développement de NextSight a commencé avec une ambition concrète : raccourcir ce chemin et simplifier la vie des équipes métier, sans leur demander de devenir spécialistes du SQL ou de l'architecture de leur système d'information.

Relier les bases de données à un LLM, sans sacrifier la maîtrise

La première version de NextSight devait permettre de relier des bases de données à un modèle de langage. Ce modèle peut être local ou distant, selon les possibilités et les règles de l'organisation.

Cette liberté de choix était indispensable, car NextSight a été conçu dans un environnement contraint : installation de composants encadrée, accès à l'extérieur limité et données à protéger. L'application peut fonctionner entièrement en local, sans accès à Internet, au sein d'un réseau isolé. L'accès aux données peut être limité à la lecture seule.

Le recours à un LLM ne fait pas disparaître la nécessité de comprendre les données. Il offre une nouvelle interface pour les interroger. La qualité du résultat dépend toujours du sens des tables, des colonnes et des règles métier. Un module RAG doit permettre à NextSight de mobiliser une connaissance documentée du système d'information et des règles métier. Cette connaissance reste à constituer, valider et maintenir.

Le point de bascule : des demandes différentes, un même processus

NextSight a commencé à dépasser le cadre de sa mission d'origine lorsque des demandes similaires sont venues d'équipes techniques, puis commerciales. Leurs finalités n'étaient pas les mêmes, mais le processus se répétait : aller chercher des données dans plusieurs bases, les exploiter et en faire ressortir une information utile à la décision, toujours dans un environnement contraint.

C'est à ce moment qu'une deuxième étape s'est imposée : ne plus produire seulement une réponse ponctuelle, mais transformer les usages récurrents en modules métier. Chaque module donne accès à une fonction ciblée sans exposer toute la complexité technique qui se trouve derrière.

Un premier module exploitable en trente minutes

Un premier module consacré à l'extraction et à l'exploitation de données pour l'aide à la décision a permis de mesurer la vitesse de cette approche. Son contexte et les données manipulées restent confidentiels, mais le temps de réalisation peut être détaillé :

Soit environ trente minutes entre la demande et un module intégré à NextSight. Cette rapidité vient du socle déjà présent dans l'application : le développeur ne repart pas de zéro pour chaque besoin.

Ce résultat valide la capacité à construire rapidement un module. Il ne permet pas encore d'affirmer que NextSight a réduit la dépendance au SI pour ses utilisateurs finaux : cette partie est toujours en cours de développement et devra être éprouvée sur le terrain.

Ce que la naissance de NextSight nous apprend

La possibilité de créer rapidement des modules et de travailler sans accès à Internet est puissante. Mais ce n'est pas la motivation principale du projet. NextSight est né pour rapprocher les personnes métier de leurs données et leur donner davantage d'autonomie dans leur exploitation.

Il ne s'agit ni de remplacer le SI ni de promettre qu'une IA comprend spontanément toutes les règles d'une organisation. Il s'agit de construire un passage plus court entre une question métier, des données dispersées et une information utile à la décision, tout en respectant les contraintes techniques et la protection des données.

NextSight est encore en développement. Sa naissance montre déjà une chose : lorsque des équipes différentes rencontrent la même dépendance face aux données, il devient pertinent de transformer une succession de requêtes ponctuelles en un outil conçu pour leurs usages.

Vous pouvez découvrir NextSight ou nous écrire pour nous parler de votre contexte.