PoC : Exposer une base HFSQL à l’IA via MCP

, ,
poc hfsql mcp ia

Introduction

Dans le monde des applications métiers, HFSQL s’impose comme une base de données robuste, performante et parfaitement intégrée à l’écosystème PC Soft. Pourtant, malgré ses nombreux avantages, elle reste souvent fermée à l’extérieur, difficilement accessible par d’autres languages.

À l’inverse, le protocole MCP (Model Context Protocol), standard ouvert promu par OpenAI, permet à une IA de se connecter facilement à des ressources externes (API, bases de données, fichiers, etc.) via un format bien défini. MCP agit comme une couche d’abstraction qui expose les fonctionnalités d’un serveur à une IA, de manière déclarative et sécurisée.

L’objectif de ce Proof of Concept (PoC) est de démontrer qu’il est tout à fait possible de connecter une base HFSQL à une IA via MCP, en construisant un serveur MCP en Windev, capable de répondre aux attentes du protocole.


1. Qu’est-ce que le protocole MCP ?

Le protocole MCP est conçu pour offrir aux intelligences artificielles un moyen simple et standardisé d’interagir avec des ressources informatiques. En d’autres termes, MCP joue le rôle de pont entre une IA et un système informatique (base de données, API métier, etc.).

Le cœur du protocole repose sur un fichier manifest.json, sorte de carte d’identité du serveur, qui décrit :

  • Les ressources disponibles (par exemple, une table ticket, une table solutions),
  • Les outils ou fonctions qu’on peut appeler (getAllTicketWithSolutions, getTicketWithSolutions, etc.),
  • Les schémas de données en entrée et en sortie.

Ce manifest est déclaratif : il décrit ce qui est possible, mais ne réalise aucune opération lui-même. L’implémentation réelle se fait via des endpoints, qui exécutent les fonctions décrites dans le manifest.


2. La base HFSQL utilisée

Pour ce PoC, nous avons utilisé une base HFSQL simple, avec deux tables :

  • Ticket : identifiant, titre, description, date de création.
  • Solution : identifiant, id_ticket (clé étrangère), contenu, date de résolution.

L’objectif est d’exposer cette base à l’IA pour permettre, par exemple, à un assistant intelligent de retrouver tous les tickets ouverts ou associer une solution à un problème déjà résolu.

Ces données métiers sont typiques de nombreux services internes (support technique, helpdesk, gestion d’incidents), et elles constituent un cas d’usage idéal pour une IA.


3. Mise en place du serveur MCP en Windev

La mise en place a été réalisée directement dans Windev 2025.

Le serveur expose une route /mcp/manifest, qui retourne dynamiquement le manifest JSON. Ce dernier contient :

  • Une section resources, définissant les types de données (ticket, solution).
  • Une section tools, listant les fonctions appelables par l’IA :
    • getAllTicketWithSolutions : retourne tous les tickets avec leurs solutions.
    • getTicketWithSolutions : retourne un ticket spécifique avec sa ou ses solutions.

Côté back-end, ces tools sont mappés sur des routes internes :

  • /api/tickets (méthode GET) → renvoie un tableau de tickets avec solutions.
  • /api/ticket/{id} (méthode GET avec un ID) → renvoie un ticket spécifique.

Ce mapping respecte la philosophie REST, tout en offrant une compatibilité avec MCP.


4. Démonstration du PoC

Imaginons maintenant qu’une IA souhaite connaître l’ensemble des tickets et solutions en base. Elle invoque simplement la fonction getAllTicketWithSolutions via le manifest MCP.

Le serveur MCP (notre projet Windev) répond avec un JSON structuré, de ce type :

[
  {
    "id": 101,
    "titre": "Erreur de connexion",
    "solution": {
      "id": 4001,
      "contenu": "Redémarrer le routeur."
    }
  },
  ...
]

Côté IA, la réponse est interprétée comme un résultat contextuel, que l’assistant peut reformuler pour un utilisateur final :

“Le ticket #101 (‘Erreur de connexion’) a pour solution : ‘Redémarrer le routeur’.”

On voit donc que la communication entre l’IA et la base HFSQL devient fluide, naturelle et intelligible.



5. Bénéfices et perspectives

Ce PoC démontre plusieurs points essentiels :

  • Il est techniquement possible de connecter une base HFSQL à un LLM via MCP, même avec un simple serveur écrit en Windev.
  • Cela permet à une IA d’exploiter une base existante sans modifier l’infrastructure.
  • On centralise les données métiers dans un point d’accès standardisé, ouvert et maîtrisé.

Mais ce n’est qu’un début.

Les perspectives à court terme :

  • Ajout d’un système d’authentification (via secrets ou jetons) pour sécuriser l’accès.
  • Filtrage des données (tickets non résolus, par utilisateur, par date).
  • Écriture de données, pas seulement en lecture (création ou mise à jour de tickets).
  • Interopérabilité avec des containers Docker exposant d’autres APIs métiers via MCP.
  • Sécurisation des données à la volée : anonymisation des rubriques rgdp, transformation des ID en UUID, …

Conclusion

Le protocole MCP ouvre la voie à une intégration fluide entre HFSQL et les intelligences artificielles modernes. Ce Proof of Concept prouve qu’une telle connexion est réalisable de manière simple et sécurisée, directement avec Windev, sans rupture avec l’existant.

Chez IsiNeva, nous croyons fermement que ces approches permettent de moderniser les applications métiers sans tout réécrire, tout en préparant leur intégration dans l’écosystème IA de demain.

Le prochain article traitera de la sécurisation des données…


Liens externes