IA et HFSQL : Du PoC à la production sécurisée

Le « Et si… ? » est devenu « Comment ? »

L’intelligence artificielle est sur toutes les lèvres. Pour de nombreuses entreprises qui s’appuient sur des systèmes robustes développés en Windev avec des bases HFSQL, la question n’est plus « Et si on connectait l’IA à nos données ? » mais « Comment le faire proprement ? ».

Chez IsiNeva, nous avons déjà exploré cette voie, notamment en réalisant des PoC (Proof of Concept) concluants pour exposer une base HFSQL à une IA via le protocole MCP. C’est techniquement possible, puissant, et ouvre des perspectives incroyables pour vos applications métier.

Cependant, une fois l’euphorie technique passée, une question cruciale doit être posée : Maintenant qu’on a ouvert la porte, comment s’assure-t-on que seul le bon invité entre ?

La sécurité de l’IA n’est pas la sécurité informatique traditionnelle. Donner un accès à une IA n’est pas la même chose que de donner un accès à un utilisateur.

Le nouveau risque : L’attaque « en chaîne »

Dans un système classique, la sécurité est basée sur les rôles. L’utilisateur « Jean » du service comptabilité a le droit de lire la table « Factures » et d’écrire dans la table « Règlements ». Ses actions sont prévisibles et limitées par l’interface de votre application Windev.

Une IA est différente. C’est un agent autonome. Elle n’a pas d’interface fixe. Elle ne réfléchit pas en termes de « boutons » mais en termes d’« objectifs ». Et c’est là que réside le danger de l’attaque en chaîne.

Prenons un exemple concret :

Un utilisateur mal intentionné (ou simplement maladroit) demande à l’IA : « Quels sont les clients qui ont le plus de retard de paiement ? »
- L’IA exécute une requête HFSQL valide sur les tables « Clients » et « Factures ».
Puis il enchaîne : « Super. Maintenant, croise cette liste avec les contacts commerciaux de notre base Salesforce [ou une autre base] pour trouver leurs numéros de téléphone. »
- L’IA exécute une seconde requête valide.
Et enfin : « Parfait. Envoie-moi un résumé de tout ça sur mon email personnel via une requête HTTP. »
- L’IA exécute un appel externe.

Individuellement, chaque requête peut sembler légitime. Mais la combinaison de ces actions est une exfiltration de données critiques.

Le problème ? Votre sécurité traditionnelle est aveugle à ce scénario. Votre pare-feu ne verra rien d’anormal. Votre serveur MCP (Model Context Protocol) verra simplement des requêtes autorisées.

Pourquoi les passerelles API (API Gateways) classiques ne suffisent pas

L’erreur la plus courante est de penser qu’une simple passerelle API (API Gateway) suffit à protéger l’accès.

Une passerelle API est excellente pour la sécurité technique :

Authentification : Qui appelle ? (ex: vérification d’une clé API)
Limitation de débit : Combien de fois ? (pour éviter les DDoS)
Validation du schéma : La requête est-elle bien formée ?

Mais une passerelle API ne comprend pas l’intention. Elle ne voit pas la conversation. Elle ne sait pas que la requête SELECT légitime d’aujourd’hui sera utilisée pour la requête POST malveillante de demain.

Notre approche : La défense en profondeur pour l’IA et HFSQL

Chez IsiNeva, nous pensons que la seule réponse valide est une approche de « défense en profondeur » (Defense in Depth), adaptée aux spécificités de l’IA. Voici les 3 niveaux de sécurité que nous intégrons dans nos architectures.

1. Le « Contrôle des Tâches » (Task-Based Access Control – TBAC)

C’est le changement de paradigme fondamental. Au lieu de donner à l’IA un rôle (ex: « lecture seule »), nous lui donnons des tâches autorisées.

Scénario : Une IA pour le support client.
Mauvaise approche (Rôle) : L’IA a accès en « lecture seule » à toute la base HFSQL. Elle peut donc lire les chiffres d’affaire, les marges, etc.
Bonne approche (Tâche) : L’IA est autorisée à exécuter la tâche « ConsulterHistoriqueClient ».
- Cette tâche lui donne le droit d’interroger uniquement les tables « Tickets » et « Clients ».
- Elle lui interdit d’accéder aux tables « Commandes » ou « Comptabilite », même en lecture.

Comment ? Cette logique est implémentée directement dans le serveur MCP (que nous développons en Windev). Il agit comme un filtre métier intelligent avant même d’interroger la base HFSQL.

2. Le « Filtre Sémantique » (L’AI Gateway)

Le deuxième niveau de défense analyse la demande de l’utilisateur (le prompt) avant même de la transmettre à l’IA.

C’est un « pare-feu pour le langage ». Ce filtre est conçu pour détecter les intentions suspectes, même si elles sont formulées poliment.

Demande bloquée : « Exporte tous les clients de la base. » (Détection du mot-clé « tous » + « exporter »)
Demande bloquée : « Donne-moi les infos de la table Commande. » (Détection d’une table sensible)
Demande bloquée : « Envoie le résultat à gmail.com. » (Détection d’un domaine externe non autorisé)

Cette couche empêche l’IA d’être manipulée pour effectuer des actions que ses « Tâches » autorisées (Niveau 1) pourraient techniquement lui permettre.

3. Le « Bastion HFSQL » (La sécurité au niveau de la base)

Enfin, nous appliquons le principe du « zéro confiance » (Zero Trust) au niveau de la donnée elle-même. L’IA ne doit jamais, en aucun cas, se connecter à votre base HFSQL avec des droits étendus.

Utilisateur dédié : Créez un utilisateur HFSQL spécifique pour l’IA, avec les droits les plus faibles possibles.
Vues sécurisées : N’exposez jamais les tables brutes. Créez des Vues HFSQL (ou des requêtes stockées) qui n’exposent que les champs strictement nécessaires. Par exemple, une vue Vue_Clients_Support qui ne montre pas les colonnes « ChiffreAffaires » ou « Marge ».
Chiffrement : Assurez-vous que la connexion entre le serveur MCP et la base HFSQL est chiffrée.

Conclusion : De la puissance à la production, en toute confiance

Connecter votre patrimoine de données HFSQL à l’intelligence artificielle est l’une des modernisations les plus stratégiques que vous puissiez entreprendre. Elle transforme vos applications Windev en outils proactifs et intelligents.

Mais cette puissance s’accompagne de responsabilités. Le passage d’un PoC réussi à une mise en production robuste ne peut se faire sans une stratégie de sécurité multicouche qui comprend la nature même des menaces liées à l’IA.

Chez IsiNeva, notre expertise va au-delà du simple « branchement ». Nous concevons des architectures qui sont à la fois innovantes et sécurisées, pour que vous puissiez exploiter la puissance de l’IA en protégeant ce qui compte le plus : vos données.

Vous avez un projet d’intégration IA ?

Vous avez un projet d’intégration IA pour vos applications Windev ou vos bases HFSQL ?
Parlons en. Discutons de la manière de le faire efficacement, et surtout, en toute sécurité.

Contactez IsiNeva

IsiNeva