Les autres systèmes d'agents s'en remettent au modèle de langage pour raisonner. SynaLemma est un harnais construit à l'inverse : le modèle traduit votre question en règle, et un moteur logique fait le raisonnement. Il vérifie formellement la règle, déduit la réponse dans la base que vous exploitez déjà, et conserve la règle : chaque étape se lit et se rejoue.
La plupart des systèmes d'agents placent le modèle de langage au milieu et le laissent raisonner jusqu'à une réponse. SynaLemma le place en périphérie. Le modèle propose une règle, et le moteur effectue chaque jointure, chaque récursion et chaque total. Rien n'atteint vos données ni votre réponse sans passer par le moteur.
Synalinks L'agentPilote le modèle pas à pas et trace tout. 
Synalog Le moteur logique 
Semantic Layers La connaissanceDes règles vérifiées, en fichiers dans git. Le modèle traduit votre question en règle et formule la réponse. Chaque inférence entre les deux est celle du moteur, et peut être rejouée.
Le raisonnement qu'un modèle de langage écrit n'est qu'un texte de plus qu'il a généré, et la recherche montre régulièrement qu'il peut taire ce qui a réellement déterminé la réponse.
Journaliser les actions d'un agent a la même limite : le journal dit quels outils ont été appelés, pas si la réponse tient, et la même question posée à nouveau peut suivre un autre chemin.
SynaLemma garde bien une trace, mais seulement pour le débogage. La preuve, c'est le code logique : une règle Synalog qui a passé le vérificateur formel avant de s'exécuter, que chacun peut lire, et qui redonne les mêmes lignes quand on la relance sur les mêmes données.
La réponse du modèle se lit dans son état interne avant qu'il écrive le moindre raisonnement, et modifier cet état inverse souvent la réponse : le raisonnement vient souvent après la décision.
L'essentiel du raisonnement infidèle accompagne des réponses fausses, et c'est là qu'aucune méthode de détection testée ne fait mieux que le hasard.
Les modèles de raisonnement exploitent des indices qu'on leur a donnés et souvent ne le disent pas.
Un journal enregistre ce qui s'est passé, mais peut ne pas montrer si les preuves soutenaient une affirmation : il dit ce qui s'est produit, pas ce qui dépendait de quoi.
Chaque couche a un seul rôle et transmet à la suivante quelque chose qu'elle peut vérifier. Trois d'entre elles sont open source ; la quatrième est le produit qui les assemble.
Ce qu'utilisent vos équipes : Lemma, l'assistante ; des tables, des concepts et des règles que l'on peut lire et modifier ; le graphe de ce qui dépend de quoi ; les rôles, l'historique, et les canaux où vous échangez déjà.
Pilote le modèle pas à pas : cherche les définitions existantes, décompose la question, écrit les règles, appelle les outils. Les sorties respectent un schéma, le modèle se remplace, et chaque étape est tracée.
Vérifie chaque règle avant toute génération de SQL, la compile dans le dialecte SQL de votre base, et confronte à vos données ce que son résultat doit respecter.
Là où vivent les définitions : un fichier lisible par table, concept ou règle, dans un dépôt git. Une couche se relit comme du code et s'installe dans un autre projet.
Chercher L'agent cherche dans la couche une définition qui répond déjà à la question. Une couche de milliers de définitions n'entre jamais entière dans le contexte du modèle : seulement ce qui correspond.
Écrire Si aucune ne convient, l'agent en écrit une, en s'appuyant sur les concepts déjà présents plutôt que de repartir des tables brutes.
Vérifier La règle passe le vérificateur formel. Si elle ne passe pas, elle est refusée, avec le motif du refus, et rien n'est enregistré si l'ensemble de la couche ne tient plus.
Exécuter La règle vérifiée est compilée en SQL et exécutée dans votre base. Ses assertions sont contrôlées sur les mêmes données.
Répondre Alors seulement l'assistante répond, en reprenant les lignes renvoyées par l'exécution et en citant la règle, que vous pouvez ouvrir.
Garder La règle est versionnée dans la couche, avec son auteur et sa date. La question suivante part d'elle.
Demander à un second modèle de vérifier le premier ne fait qu'ajouter un autre avis. SynaLemma vérifie par la logique. C'est le premier et le seul système d'IA qui écrit ses propres règles, les vérifie formellement et confronte leurs résultats à des énoncés mathématiques.
Le vérificateur formel de Synalog examine chaque règle avant qu'aucun SQL ne soit généré, sans base de données : variables jamais liées, négation et agrégation non sûres, négation à travers une récursion, récursion sans cas de base ou sans borne, colonnes, fonctions et prédicats inconnus. Plus de quinze classes d'erreurs, toutes signalées d'un coup. Une règle qui ne passe pas n'est jamais enregistrée, ni exécutée.
Une assertion énonce ce qu'un résultat doit respecter, indépendamment de la façon dont il est calculé : une pièce n'apparaît qu'une fois, un stock n'est jamais négatif, les livraisons en retard ne dépassent jamais les livraisons. Elle s'écrit en logique du premier ordre (∀, ∃, →, sommes et comparaisons) sous forme de proposition Lean, la notation de l'assistant de preuve Lean. Synalog compile une recherche de contre-exemples en SQL et l'exécute sur votre base. Dans SynaLemma, une assertion contredite s'affiche sur la règle, avec les lignes qui la contredisent en un clic.
✗ OnTimeDelivery.meets_service_level is violated:
∀ s r d t, OnTimeDelivery s r d t → t ≥ 0.6
2 counterexamples:
+-------------------+------+----+-------+
| s | r | d | t |
+-------------------+------+----+-------+
| Shenzhen VoltPack | high | 34 | 0.588 |
| Hsinchu Controls | high | 47 | 0.553 |
+-------------------+------+----+-------+
Auditer une IA, c'est d'ordinaire relire les journaux de ce qu'un modèle a dit. Dans SynaLemma, vous auditez deux enregistrements exacts : la déduction, faite par le moteur logique, et l'historique des règles, conservé dans git, l'outil que les équipes logicielles utilisent déjà pour suivre chaque changement.
Chaque chiffre cite sa règle et la ligne d'où il vient. Chaque règle nomme les concepts sur lesquels elle s'appuie, et chaque concept les tables qu'il lit. Suivez la chaîne, ou réexécutez n'importe lequel de ses maillons.
Une couche sémantique est un dépôt git : un fichier par table, concept et règle. Chaque changement est un commit attribué à son auteur, que ce soit une personne, Lemma ou un autre agent, avec le détail des modifications et la possibilité de revenir en arrière.
Quelle était cette définition le jour où ce chiffre a été communiqué ? Qui l'a changée, et quand ? Comparez deux versions, restaurez-en une, ou faites passer un changement par la même relecture que n'importe quel autre code.
L'historique enregistre vos définitions et leurs changements, pas vos données : les lignes restent dans votre base.
Une couche sémantique classique est un projet de modélisation qui prend des mois et se périme peu après sa livraison. SynaLemma écrit la couche au fil des questions, par-dessus vos bases existantes.
Les règles se compilent en SQL et s'exécutent là où sont les données. Sur une base que vous exploitez, SynaLemma déclare les tables que vous choisissez et ne les modifie jamais. Un compte en lecture seule suffit.
Les schémas anciens gardent leurs vrais noms de tables et de colonnes, espaces et accents compris. La couche leur donne un sens sans y toucher.
Entités et relations sont modélisées par-dessus vos tables relationnelles. Le graphe est virtuel : il se compile en SQL.
Nomenclatures à tous les niveaux, chaînes hiérarchiques, « quels assemblages s'arrêtent si ce fournisseur fait défaut » : une récursion à la profondeur que vous déclarez, donc qui se termine toujours, et le raisonnement dans le temps.
Et vos fichiers : CSV, Excel, JSON, JSONL, Parquet.
La couche vous appartient. Tout ce qu'écrit l'assistante peut être lu, corrigé et verrouillé par une personne.
SynaLemma se déploie sur votre infrastructure. Avec un modèle local, rien n'en sort. Avec un modèle hébergé, vos questions et les extraits de données nécessaires pour y répondre vont au fournisseur que vous avez choisi, et nulle part ailleurs.
Des modèles ouverts sur votre propre matériel (Ollama, vLLM, LM Studio) ou le fournisseur avec lequel vous avez déjà un contrat. Les règles n'en dépendent pas.
Interrogées sur place, par un compte qui n'a besoin que de lire. Les identifiants de base sont stockés chiffrés. Les messages vocaux enregistrés dans l'application sont transcrits sur votre serveur.
De simples fichiers dans un langage ouvert, sur des moteurs publiés sous Apache-2.0. Elles s'exécutent aussi avec le seul outillage open source.
Non. SynaLemma vient avec un ou plusieurs ingénieurs dédiés selon la taille de votre projet, issus de l'équipe qui le construit. Ils travaillent aux côtés de vos équipes pour le mettre en place, s'occuper de vos données, et écrire et vérifier vos définitions avec vos experts.
Il décide de ce qu'il demande au moteur : quels concepts combiner, et comment. Cette décision est écrite, sous forme de règle que vous pouvez lire, et c'est le moteur, pas le modèle, qui en déduit chaque ligne. Si la décision est fausse, elle l'est à un endroit que l'on voit, que l'on corrige une fois, et que l'on verrouille.
Les trois moteurs sur lesquels il repose (Synalinks, Synalog, Semantic Layers) sont open source sous licence Apache-2.0. SynaLemma lui-même, le produit qui les assemble, est propriétaire et vendu sous licence commerciale. Vos règles sont des fichiers au format ouvert : elles ne sont jamais captives.
PostgreSQL, BigQuery, Databricks, Trino, Presto, DuckDB et SQLite, interrogées sur place : vos tables restent où elles sont. Et des fichiers : CSV, Excel, JSON, JSONL et Parquet. Une même règle se compile dans le dialecte SQL du moteur sur lequel elle s'exécute.
Tout modèle capable d'appeler des outils, choisi dans un catalogue depuis les paramètres : des modèles ouverts servis localement par Ollama, vLLM ou LM Studio, ou des fournisseurs hébergés comme Mistral, Anthropic, OpenAI ou Google. Changer de modèle ne change pas les règles. Tout, sauf la conversation elle-même, fonctionne sans aucun modèle.
Une règle structurellement fausse est refusée par le vérificateur. Une règle qui contredit une assertion est signalée, avec les lignes qui la contredisent. Et comme la règle est lisible, le responsable du chiffre peut la voir et la corriger. Ce n'est pas possible quand la réponse est un paragraphe de prose.
Non. SynaLemma ne dessine pas de graphiques : les réponses sont des chiffres, des tableaux et les règles qui sont derrière. Il donne un seul endroit où vivent les définitions de vos tableaux de bord, et permet aux personnes comme aux agents de les interroger en langage courant.
Lors d'une démo gratuite de trente minutes, nous vous montrons la réponse de SynaLemma et la règle qu'il a utilisée.
