Foundgine - Plateforme d'exécution sémantique programmable pour .NET

Qu'est-ce que Foundgine

Les applications modernes ne sont plus consommées depuis une seule surface. Web, mobile, API, clients GraphQL, services internes, automatisations et, désormais, agents IA — chacun de ces appelants tend à construire son propre chemin d'autorisation, de validation, de traduction de requête et d'accès aux données. Cette prolifération sémantique conduit à une duplication massive de logique, des divergences de comportement et, surtout, des surfaces de sécurité difficilement auditées.

Foundgine répond à ce problème avec une proposition radicalement différente : une plateforme d'exécution sémantique programmable pour .NET qui établit une frontière contrôlée entre les appelants d'une application et les données et opérations qu'ils sont autorisés à exécuter. Plutôt que de laisser chaque appelant implémenter sa propre validation et traduction de requête, Foundgine transforme une intention structurée en un plan d'exécution autorisé, puis exécute ce plan via un fournisseur.

L'idée centrale tient en une phrase : les appelants décrivent ce qu'ils veulent ; Foundgine détermine ce qui est autorisé, comment l'exécuter et quel fournisseur s'en charge. Cette inversion de responsabilité est au cœur de l'architecture : l'appelant cesse d'être l'autorité sur l'accès aux données.

Il importe de préciser ce que Foundgine n'est pas : ce n'est ni un remplacement d'ORM, ni une base de données, ni un serveur GraphQL, ni un LLM, ni un framework d'agents, ni un fournisseur d'identité. Foundgine se positionne comme une couche d'exécution pouvant se placer sous ces systèmes — une fondation neutre qui unifie la sémantique d'exécution.

Le pipeline d'exécution central illustre cette architecture : l'Intention est transformée en Modèle sémantique, puis traverse la Résolution, l'Autorisation, la construction d'un Plan, la Réécriture/Optimisation, la Compilation du fournisseur, avant l'Exécution et la production d'un Résultat accompagné de Preuve. Chaque étape est déterministe et observable.

La vision à long terme du projet est ambitieuse : établir une frontière d'exécution sémantique stable entre ce qu'un système demande et ce qu'une application est prête à exécuter — une frontière qui fonctionne aussi bien pour les logiciels traditionnels que pour les agents intelligents.

Architecture Centrale et Détails Techniques

Séparation des préoccupations

L'architecture de Foundgine repose sur une décomposition rigoureuse des responsabilités. Le modèle sémantique définit les capacités exposées par l'application. L'intention décrit ce que l'appelant souhaite accomplir, sans le lier directement à un fournisseur physique. L'autorisation détermine quelles parties de l'opération demandée sont permises et peut injecter des prédicats ou contraintes dans le plan d'exécution. Le planificateur construit une représentation indépendante du fournisseur. La réécriture et l'optimisation transforment le plan tout en préservant la sémantique et les contraintes d'autorisation. Enfin, le fournisseur compile et exécute le plan contre un backend concret.

Modèle d'exécution multi-appelants

REST/API
GraphQL
JSON
Agent IA
Automatisation
   │
   ▼
Intention Sémantique
   │
   ▼
Planificateur Foundgine
   │
   ├── SQL
   ├── InMemory
   └── Fournisseurs futurs

Cette normalisation permet d'éviter d'implémenter une sémantique d'exécution distincte pour chaque interface. Un client GraphQL et un agent IA, bien que très différents dans leur nature, passent par le même point de convergence : l'intention sémantique.

Pourquoi le plan intermédiaire est essentiel

Le plan constitue la frontière architecturale entre l'intention sémantique et l'exécution physique. Il donne au runtime les moyens de préserver les contraintes d'autorisation, de valider les dépendances, de réécrire les opérations, d'estimer les coûts, de raisonner sur les capacités du fournisseur, d'optimiser l'exécution et de produire une preuve d'exécution. C'est ce mécanisme central qui permet à des surfaces d'entrée et des fournisseurs multiples de partager une même sémantique d'exécution.

Modèle sémantique vs modèle de persistance

La distinction est fondamentale. Un modèle de persistance décrit comment les données sont stockées ; un modèle sémantique décrit ce que l'application accepte d'exposer et de manipuler. Ces deux modèles ne coïncident pas nécessairement. La surface sémantique peut être plus petite, plus sûre et plus intentionnelle que le modèle physique. Par exemple, un modèle de persistance peut contenir des champs internes comme TenantId ou InternalRiskScore que le modèle sémantique exposé aux appelants ne révèle jamais.

Foundgine et Agents IA

Le changement de paradigme

Le modèle naïf d'accès aux données pour les agents IA — IA → générer SQL → base de données — présente un risque structurel majeur : il confère à un modèle génératif l'autorité sur l'accès aux données applicatives. Foundgine inverse cette dynamique. Un modèle IA décide de ce qu'il veut accomplir, mais il ne devient jamais l'autorité sur les données auxquelles il accède, et il ne reçoit jamais d'identifiants directs de base de données.

Le flux d'exécution

Agent IA
    │
    │ intention structurée
    ▼
Foundgine
    ├── résoudre
    ├── valider
    ├── autoriser
    ├── planifier
    └── exécuter
            │
            ▼
        PostgreSQL

Ce flux est délibérément distinct de IA → générer SQL → base de données. Foundgine maintient l'application aux commandes de l'autorisation et de l'exécution, tout en permettant aux agents et aux autres appelants structurés d'utiliser les capacités applicatives.

Surface d'intégration IA

L'écosystème comprend plusieurs paquets dédiés aux agents :

• Foundgine.AI — intégration d'outils via Microsoft.Extensions.AI, permettant d'exposer des capacités sémantiques comme outils IA.

• Foundgine.Agent.OpenAI — intégration pour les agents OpenAI.

• Foundgine.MCP — adaptateur MCP exposant les capacités sémantiques et l'intention neutre vis-à-vis du fournisseur, avec transport MCP Streamable HTTP sur /mcp et découverte automatisée via .well-known/mcp.json.

Le benchmark d'agents mesure précisément ce que ces intégrations apportent : il compare un agent appelant Foundgine via MCP à un agent appelant directement un chemin EF Core conventionnel, à travers les dimensions de taille de charge, débit, temps de réponse et charge par jeton.

L'histoire E2E de chaîne d'approvisionnement rend l'architecture concrète : agent → MCP → Foundgine → PostgreSQL, avec PlaceOrder comme tranche verticale haute assurance combinant autorisation, validation, tarification côté serveur, vérification d'inventaire, mutation atomique, protection d'idempotence et preuve d'exécution.

Preuve de Performance

Le benchmark de graphe PostgreSQL CoffeeBeanery

Pour valider les performances de requête dans des conditions réalistes, Foundgine a été soumis à un benchmark déterministe sur un graphe PostgreSQL relationnel. Le fixture comprend 1 000 clients, 4 000 relations bancaires, 12 000 contrats et 48 000 transactions, avec des niveaux de concurrence de 1, 8 et 32, des mesures de 10 secondes et un préchauffage de 3 secondes.

Résultats des requêtes à concurrence 32

Ces chiffres correspondent approximativement à :

• 20,0× le débit de la baseline sans cache de plan

• 20,4× avec cache de plan

• 16,7× la latence p95 inférieure sans cache

• 17,0× la latence p95 inférieure avec cache

Un point crucial : l'avantage substantiel sur les requêtes ne dépend pas du cache de plan de fournisseur. La supériorité est structurelle, inhérente à la conception sémantique.

Fiabilité

Sur les trois exécutions indépendantes réussies : 0 erreur d'application, 0 délai d'attente, 0 requête annulée.

Portée des résultats

Il faut rester rigoureux sur l'interprétation. Ces résultats sont une preuve spécifique à une charge de travail, pas une assertion universelle que Foundgine surpasse tous les workloads EF Core ou GraphQL. Les résultats dépendent de la charge, du schéma, des versions de fournisseur, de l'hôte et des implémentations. Par ailleurs, la performance de mutation est plus variable et ne doit actuellement pas être présentée comme la principale revendication de performance.

Écosystème, Paquets et Intégrations

Foundgine est distribué comme une famille coordonnée de paquets NuGet — 18 paquets publiés, version 0.5.2, ciblant .NET 9.0, avec 7 801 téléchargements totaux à travers l'écosystème. Cette modularité offre un chemin clair depuis les contrats indépendants du fournisseur jusqu'à l'exécution, englobant SQL, IA, MCP, GraphQL, AOT et l'autorisation haute assurance.

L'intégration GraphQL mérite une attention particulière : l'adaptateur Foundgine.GraphQL.HotChocolate permet d'utiliser GraphQL comme interface sans en faire le modèle d'exécution. Les sélections GraphQL sont converties en requêtes sémantiques Foundgine, puis exécutées par le planificateur — une approche qui combine la familiarité de GraphQL avec la rigueur d'un plan autorisé.

Côté documentation, le site publié est disponible sur Foundgine.io avec un index lisible par machine (llms.txt et llms-full.md) conçu pour l'outillage IA et LLM.

Enfin, Foundgine a été soumis à un audit indépendant de sécurité AST par UnofficialOS, obtenant un score de 90/100 avec des notes maximales en Edge Sandbox Safety, conformité de licence open source, qualité de documentation et hygiène de dépôt. Il convient de noter qu'UnofficialOS est un répertoire communautaire indépendant, non affilié à l'écosystème Cloudflare.

Conformité de Sécurité et Mutations Haute Assurances

Sécurité comme contrat d'exécution

Foundgine traite les exigences de sécurité comme partie intégrante du contrat d'exécution sémantique. Les invariants de sécurité requis sont propagés dans les plans puis vérifiés contre les capacités du fournisseur avant l'exécution. Cette vérification préventive empêche un fournisseur d'exécuter silencieusement une capacité dont les garanties de sécurité ne pourraient être préservées.

La progression de sécurité actuelle comprend : l'enregistrement d'invariants de sécurité, la preuve au niveau du plan, la conformité du fournisseur SQL, la conformité des mutations haute assurance et la conformité inter-fournisseurs.

Responsabilité partagée

Il est essentiel de circonscrire le périmètre. Les frontières d'autorisation et d'exécution de Foundgine visent à réduire les chemins d'accès non sécurisés, mais la sécurité applicative demeure une responsabilité partagée. L'authentification, la gestion des secrets, la sécurité du transport, le rate limiting, les permissions de base de données et la sécurité de déploiement restent des responsabilités de l'application et de l'infrastructure.

Mutations haute assurance

Les garanties de mutation sont spécifiques et vérifiables. La propagation d'annulation de mutation est portée jusqu'à la frontière d'exécution du fournisseur : une mutation ne peut pas valider après qu'une vérification d'annulation a échoué.

La sécurité du cycle de vie du contexte d'autorisation repose sur plusieurs propriétés : l'identité acteur/locataire est immuable, les versions sont strictement monotones, les identités supprimées conservent une tombe de version, et une configuration manquante échoue fermée (fail closed). Les écritures de cycle de vie utilisent la même frontière de sérialisation par verrou de ligne que les lectures d'autorisation de mutation.

L'intégrité cryptographique est structurée autour de la preuve persistée : elle est liée cryptographiquement à sa charge de sécurité canonique complète via une clé HMAC-SHA256 détenue en externe, avec un cycle de vie de clé autorisé comprenant des états actif/vérification-seule/retiré, une provenance de rotation monotone, des instantanés d'anneau atomiques immuables et une vérification sûre de retraite contre les preuves persistées. Les clés inconnues, les incohérences d'algorithme, les valeurs modifiées et les tombes de cycle de vie falsifiées échouent fermée.

Portes de vérification

L'architecture de vérification progresse par étapes : tests unitaires (sémantique, planification, autorisation, runtime), tests d'intégration avec le véritable fournisseur PostgreSQL, pénétration d'autorisation (chemins haute assurance attaqués), entrées sémantiques adversariales (rejeu d'entrées hostiles et de moteurs adversarial), smoke de performance (trafic de benchmark réel dans Docker), puis E2E de chaîne d'approvisionnement (workflow métier complet agent-facing). Le workflow CI de release rend les tests unitaires, l'intégration PostgreSQL, la pénétration d'autorisation, les tests adversarial et les jobs de performance prérequis à la publication des paquets.

Premiers Pas et Statut Actuel

Chemin d'onboarding recommandé

Pour itérer rapidement, la documentation recommande de commencer par le fournisseur InMemory (Foundgine.InMemory). Il permet de valider le modèle sémantique, la planification et l'autorisation sans infrastructure de base de données — un terrain d'expérimentation idéal pour le développement et les tests avant d'adopter le fournisseur SQL.

Le point d'entrée est l'index de documentation et le site publié sur Foundgine.io, qui couvre l'architecture, la performance, la sécurité et l'intégration des agents IA. L'index llms.txt / llms-full.md, lisible par machine, est particulièrement adapté à un onboarding orienté agents et LLM.

Statut et maturité

Foundgine en est à la version 0.5.2, ciblant .NET 9.0. Le projet est en évolution active : la stabilité de l'API publique suit la politique de version et de compatibilité en cours, et les déploiements orientés Native AOT sont pris en charge via Foundgine.Aot (attributs de métadonnées et support d'exécution pour métadonnées générées).

Le CHANGELOG.md conserve des notes d'ingénierie datées et détaillées pour chaque release. La version 0.5.0 a notamment consolidé Foundgine.Authorization comme bibliothèque publiée (plan de contrôle de récupération d'autorisation avec quorum de témoins, cycle de vie des identifiants, réconciliation de journal et basculement), et la version 0.4.0 a introduit le plan de contrôle de récupération, la réplication de termes d'autorité et les certificats de récupération cryptographiquement signés.

Structure du dépôt

• src/Foundgine.MCP — adaptateur MCP et découverte d'écosystème

• benchmarks/CoffeeBeanery.Performance/ — données sources du benchmark de requêtes

• benchmarks/AgentEndToEnd/ — données sources du benchmark du chemin agent

• docs-site/ — sources du site de documentation publié

FAQ