MCP générique pour HFSQL

Introduction

Dans un récent échange sur LinkedIn, une question simple mais stratégique m’a été posée : « Comment mettre en place un serveur MCP générique capable d’interroger dynamiquement n’importe quelle analyse HFSQL ? » Cet article propose une réponse concrète, réutilisable, et alignée avec les bonnes pratiques de modélisation de données.

L’objectif est de fournir au serveur MCP une fonction unique : getDataBaseModels(). Celle-ci expose la structure complète d’une analyse HFSQL – fichiers, rubriques, index, et relations – sous forme d’un modèle JSON. Ce modèle, auto-généré et auto-décrit, permet à un agent intelligent de déterminer quelles entités interroger et comment les relier selon les besoins exprimés par l’utilisateur.

Découverte du contenu d’une analyse HFSQL

1. Les fonctions Windev

Windev fournit toutes les fonctions nécessaires pour « découvrir » le contenu d’une analyse :

• HListeFichier : pour obtenir la liste des tables de l’analyse.
• HListeRubrique : extrait les colonnes (ou champs) d’une table.
• HListeClé : liste les clés d’indexage définies.
• HListeLiaison : liste les liaisons entre champs avec les cardinalités.

2. Définir des structures standardisées pour le MCP

Pour rendre l’analyse exploitable par le serveur MCP, il est indispensable de structurer les informations extraites sous une forme cohérente, claire et standardisée. Cela garantit une lisibilité optimale pour toute consommation automatisée, notamment par une IA.

Les quatre structures suivantes servent de socle au modèle retourné :

STR_Relationship est une Structure
	name		est une chaîne
	table1 		est une chaîne
	column1		est une chaîne
	cardinality1	est une chaîne
	table2		est une chaîne
	column2		est une chaîne
	cardinality2	est une chaîne
FIN

STR_Indexes est une Structure
	name		est une chaîne
	description	est une chaîne
	type		est une chaîne
	unicity		est une chaîne
	keycomponent	est une chaîne
FIN

STR_Columns est une Structure
	name		est une chaîne
	description	est une chaîne
	datatype	est une chaîne
FIN

STR_Table est une Structure
	table 		est une chaîne
	description 	est une chaîne
	columns    	est un tableau de STR_Columns
	indexes		est un tableau dynamique de STR_Indexes
	relationships 	est un tableau de STR_Relationship
FIN

Cette structuration permet de passer d’un modèle relationnel natif HFSQL à un modèle de données sémantique exploitable directement par un moteur d’IA. Elle prépare également la sérialisation JSON de ces données pour exposition via API.

3. La fonction getDataBaseModels()

L’API du serveur MCP expose la fonction getDataBaseModels() qui retourne un objet JSON décrivant l’ensemble des entités de l’analyse HFSQL : fichiers, rubriques, clés, et relations.

Voici une version complète de la procédure :

PROCÉDURE getDataBaseModels()
jsModel est un Buffer

sListeFichier	est une chaîne
sListeRubrique	est une chaîne
sListeClé		est une chaîne
sListeLiaison	est une chaîne

model est un tableau dynamique de STR_Table

sListeFichier = HListeFichier(hLstDétail + hLstTout)

POUR TOUTE CHAÎNE sNomFichier DE sListeFichier SÉPARÉE PAR RC
	uneTable est un STR_Table
	uneTable.table = ExtraitChaîne(sNomFichier,1,TAB)
	uneTable.description = ExtraitChaîne(sNomFichier,2,TAB)

	sListeRubrique = HListeRubrique(uneTable.table, hLstDétailPlus)
	sListeClé = HListeClé(uneTable.table, hLstDétailPlus)
	sListeLiaison = HListeLiaison(uneTable.table,hLstDétail)

	POUR TOUTE CHAÎNE sRubrique DE sListeRubrique SÉPARÉE PAR RC
		uneRubrique est un STR_Columns
		uneRubrique.name = ExtraitChaîne(sRubrique,1,TAB)
		uneRubrique.description = ExtraitChaîne(sRubrique,6,TAB)
		uneRubrique.sdatatype = ExtraitChaîne(sRubrique,2,TAB)
		TableauAjoute(uneTable.columns, uneRubrique)
	FIN

	POUR TOUTE CHAÎNE sClé DE sListeClé SÉPARÉE PAR RC
		unIndex est une STR_Indexes
		unIndex.name = ExtraitChaîne(sClé,1,TAB)
		unIndex.description = ExtraitChaîne(sClé,6,TAB)
		unIndex.type = ExtraitChaîne(sClé,2,TAB)
		unIndex.keycomponent = ExtraitChaîne(sClé,4,TAB)
		SELON ExtraitChaîne(sClé,5,TAB)
			CAS "0" : unIndex.unicity = "primary"
			CAS "1" : unIndex.unicity = "unique"
			CAS "2" : unIndex.unicity = "multiple"
			AUTRE CAS : unIndex.unicity = "unknown"
		FIN
		TableauAjoute(uneTable.indexes,unIndex)
	FIN

	POUR TOUTE CHAÎNE sLiaison DE sListeLiaison SÉPARÉE PAR RC
		uneLiaison est un STR_Relationship
		uneLiaison.name = ExtraitChaîne(sLiaison,1,TAB)
		uneLiaison.table1 = ExtraitChaîne(sLiaison,2,TAB)
		uneLiaison.column1 = ExtraitChaîne(sLiaison,3,TAB)
		uneLiaison.cardinality1 = ExtraitChaîne(sLiaison,4,TAB)
		uneLiaison.table2 = ExtraitChaîne(sLiaison,5,TAB)
		uneLiaison.column2 = ExtraitChaîne(sLiaison,6,TAB)
		uneLiaison.cardinality2 = ExtraitChaîne(sLiaison,7,TAB)
		TableauAjoute(uneTable.relationships,uneLiaison)
	FIN

	model.Ajoute(uneTable)
FIN

Sérialise(model,jsModel,psdJSON)
RENVOYER jsModel

4. Exemple de modèle JSON retourné par le serveur

Le tableau JSON ci-dessous illustre le résultat retourné par la fonction getDataBaseModels() pour une analyse contenant trois fichiers : Client, Ticket et Solution.

Chaque objet JSON correspond à une table. On y retrouve :

• Les colonnes avec leur nom, type et description.
• Les index définis sur la table, avec leur unicité.
• Les relations inter-tables avec les cardinalités dans chaque sens.

Ce modèle devient un véritable dictionnaire de données dynamique utilisable par le serveur MCP. Il autorise :

• Une navigation transverse entre les entités.
• Une interprétation automatisée des jointures possibles.
• Un mapping clair entre un prompt utilisateur (ex : « affiche les tickets récents d’un client ») et les fichiers HFSQL à interroger.

Conclusion

La combinaison des fonctions d’introspection HFSQL et d’une modélisation dynamique standardisée permet de construire un serveur MCP générique, indépendant de toute analyse spécifique. Grâce à la fonction getDataBaseModels(), l’IA dispose d’une source de vérité fiable, contextualisée, et interrogeable automatiquement.

Ce type d’architecture facilite :

la scalabilité vers de multiples analyses HFSQL,

l’automatisation de la génération des requêtes métier,

la réduction des erreurs de jointures ou de navigation dans la base.

Pour une entreprise comme EloNeva, cela signifie des gains concrets en flexibilité, maintenabilité, et vitesse de déploiement de nouveaux cas d’usage basés sur des données Windev.

Liens externes

Documentation officielle PCSoft HFSQL

Exemples d’utilisation de HListeFichier sur le forum PCSoft

Spécification JSON – ECMA International