From c30bfa067732a84828bfbbeaa7484f2006bb1d53 Mon Sep 17 00:00:00 2001 From: gwen Date: Fri, 3 Jul 2026 09:37:20 +0200 Subject: [PATCH] docs(prompt): prompt based app documentation --- doc/AsynchronousPrompts.md | 8 ++ doc/CypherBasedGraphDb.md | 25 +++++ doc/GraphBasedTool.md | 46 +++++++++ doc/PromptBasedApplications.md | 97 +++++++++++++++++++ doc/RougailBasedAppStructuration.md | 2 + doc/SparqlVsCypher.md | 34 +++++++ doc/index.md | 12 ++- .../persona}/initial_user_prompt.md | 5 + {persona => doc/persona}/sytem_prompt.md | 6 ++ 9 files changed, 233 insertions(+), 2 deletions(-) create mode 100644 doc/AsynchronousPrompts.md create mode 100644 doc/CypherBasedGraphDb.md create mode 100644 doc/GraphBasedTool.md create mode 100644 doc/PromptBasedApplications.md create mode 100644 doc/RougailBasedAppStructuration.md create mode 100644 doc/SparqlVsCypher.md rename {persona => doc/persona}/initial_user_prompt.md (75%) rename {persona => doc/persona}/sytem_prompt.md (97%) diff --git a/doc/AsynchronousPrompts.md b/doc/AsynchronousPrompts.md new file mode 100644 index 0000000..da46a61 --- /dev/null +++ b/doc/AsynchronousPrompts.md @@ -0,0 +1,8 @@ +--- +description: carottage de prompts asynchrones +--- +# prompts asynchrones + +- [[AsynchronousTextualPrompt]] +- [[persona/initial_user_prompt]] +- [[sytem_prompt]] \ No newline at end of file diff --git a/doc/CypherBasedGraphDb.md b/doc/CypherBasedGraphDb.md new file mode 100644 index 0000000..2fbfcb4 --- /dev/null +++ b/doc/CypherBasedGraphDb.md @@ -0,0 +1,25 @@ + +Voici une liste de bases de données graphes open source qui supportent Cypher. Elle inclut les bases que vous avez mentionnées et d'autres options. + +### Liste des bases de données open source supportant Cypher + +* **Memgraph** : Base de données en mémoire, optimisée pour les scénarios nécessitant de très faibles latences, comme la détection de fraude en temps réel ou l'analyse de flux de données. Elle est reconnue pour son efficacité mémoire comparée à Neo4j. +* **ONgDB (Open Native Graph Database)** : Un fork open source de Neo4j Enterprise Edition. Son principal avantage est de proposer des fonctionnalités de clustering et de haute disponibilité gratuitement, contrairement à Neo4j. Sa consommation mémoire est proche de celle de Neo4j. +* **JanusGraph** : Conçue pour le passage à l'échelle et les données massives. Elle est distribuée et s'appuie sur des systèmes de stockage comme Cassandra ou HBase. Elle est donc plus complexe à opérer, mais est un choix pour de très gros volumes de données. Elle utilise nativement le langage Gremlin, mais peut supporter Cypher via des extensions. +* **RedisGraph** : Un module pour Redis qui utilise le langage Cypher. Étant entièrement en mémoire, elle excelle pour des requêtes en temps réel ultra-rapides. En revanche, elle est moins adaptée pour des analyses de graphes très profondes. +* **ArcadeDB** : Une base de données multi-modèle (Graphe, Document, Clé-Valeur, etc.) sous licence Apache 2.0, ce qui est très permissif pour une utilisation commerciale. Son moteur openCypher est compatible, ce qui facilite la migration depuis Neo4j. +* **Kùzu** : Une base de données de graphes *embarquable* (comme SQLite), écrite en C++ et optimisée pour la vitesse. Elle implémente Cypher, ce qui en fait un bon choix pour des applications légères, intégrées ou pour les tests. + +--- + +### 🔎 Faire le bon choix + +Pour vous aider à décider, voici une synthèse des forces de chaque base en fonction de vos besoins : + +* **Pour les performances en temps réel et la mémoire** : **Memgraph** est un excellent candidat si votre priorité est la vitesse, car elle fonctionne en mémoire et est optimisée en C++ . +* **Pour la haute disponibilité open source** : **ONgDB** est une alternative directe à Neo4j Enterprise, offrant des fonctionnalités de clustering sans coût de licence . +* **Pour passer à l'échelle avec d'énormes volumes de données** : **JanusGraph** est conçu pour la distribution, mais cela ajoute de la complexité . +* **Pour la flexibilité et un modèle de données unique** : **ArcadeDB** se distingue par son approche multi-modèle et sa licence permissive . **Kùzu** est idéal si vous cherchez une base de données légère et embarquable . +* **Pour des requêtes ultra-rapides sur des données légères** : **RedisGraph**, en tant que module Redis en mémoire, est parfait pour des cas comme la personnalisation en temps réel . + +Avez-vous une idée plus précise de votre cas d'usage (ex: volume de données, besoin de scalabilité, type d'analyses) pour que je puisse vous aiguiller plus finement ? \ No newline at end of file diff --git a/doc/GraphBasedTool.md b/doc/GraphBasedTool.md new file mode 100644 index 0000000..d9b8a23 --- /dev/null +++ b/doc/GraphBasedTool.md @@ -0,0 +1,46 @@ +--- +description: manipuler les variables d'une configuration d'une manière légère, approche orientée graph +--- +# Graph based tools + +L'idée est d'organiser en graphe et de représenter un ensemble des variables susceptibles d'évoluer dynamiquement. On démarrera à partir d'un lexique (dictionnaire) existant et on essayera de "dégager des faits" pour faire en sorte que le dictionnaire ne soit pas trop lourd à manipuler. + +deux options : + +- graph based +- Rougail ! -> FIXME [[RougailBasedAppStructuration]] + +Le faire grâce à Rougail, qui est très générique et qui peut avoir un usage en "data modeling", est évident. Mais il s'agit de ne négliger aucune piste. + + +Concernant le choix d'une graph database, pourquoi pas graph db, enfin la version libre.  + +Leur doc est pas mal, + +[https://graphdb.dev/article/Introduction_to_Graph_Databases.html](https://graphdb.dev/article/Introduction_to_Graph_Databases.html) + +C'est bien pensé. + +Je sais pas quel est ton niveau en graphe de, voici un bon tuto : + +[https://graphdb.dev/article/Introduction_to_Graph_Databases.html](https://graphdb.dev/article/Introduction_to_Graph_Databases.html) + +[https://www.emilien-guilmineau.fr/posts/graphdb/10-what-is-it/](https://www.emilien-guilmineau.fr/posts/graphdb/10-what-is-it/) + + + +Et sur comment modéliser les datas : + + + +[https://www.emilien-guilmineau.fr/posts/graphdb/20-how-to-model-data-for-graph/](https://www.emilien-guilmineau.fr/posts/graphdb/20-how-to-model-data-for-graph/) + + +## bases possibles + +- [[CypherBasedGraphDB]] +- [[SparqlVsCypher]] + +### pas d'ontologies + +Perso je ne sais pas encore ce que je vais choisir comme base, enfin je n'ai pas besoin de modéliser ça en ontologies avec du RDF donc ça simplifie les choses, parce que les ontologies c'est un peu lourd, je te déconseille ça. \ No newline at end of file diff --git a/doc/PromptBasedApplications.md b/doc/PromptBasedApplications.md new file mode 100644 index 0000000..64c7650 --- /dev/null +++ b/doc/PromptBasedApplications.md @@ -0,0 +1,97 @@ +## question +comment trouver une meilleure manière de faire du développement d'IHM (UI) aujourd'hui dans l'ère de l'IA ? +Faut-il centrer nos UI sur le prompt ? +Dans ce cas, +- quelles librairies choisir, qui permette de construire un prompt web et aussi d'afficher des widgets, charts, etc... adaptés à l'utilisateur +- quel système de génération d'UI ? +l'ui doit être plus dynamique, "generative ui", elle doit s'adapter au contexte. +Cela est bien différent d'une SPA (single page app), et necessite une structuration pour ne pas produire des widgets hallucinés par l'ia. +Est-ce que l'approche API first est toujours valable ? + +# A propos des UI + +Il faut complètement repenser les IHM (UI). +L'arrivée des IA a complètement changé l'interface utilisateur. +Elle reste une appli web, mais : + +- "generative UI" (une application web qui est conçue par l'IA en fonction + du contexte de l'utilisateur, donc une application beaucoup plus générique + une application générée en fonction du contexte en quelque sorte, +- prompt first. L'injonction de centrer l'app sur un dialogue avec l'IA est forte. + le point d'entrée est le promt. Les widgets qui doivent apparaître sont + issues d'interaction avec le prompt (champs de formulaires, charts, etc...) + +L'application doit donc devenir dynamique. Pas seulement dynamique au niveau +des pages web et des queries. Dynamique au niveau de l'ergonomie. +Les widgets doivent apparaître en fonction de la demande utilisateur. +Mais il faut une base structurelle forte qui permette d'éviter des widgets +complètement hallucinés et ne correspondant pas au contexte. +Il faut des outils de validation de la consistency, de la cohérence +de l'application. + +La réponse courte est **oui, l'ère de l'IA redéfinit fondamentalement le développement d'IHM**. Il ne s'agit plus de concevoir des interfaces statiques, mais de créer des surfaces d'interaction dynamiques, générées et adaptées par l'IA en fonction du contexte. Cette approche, appelée "Generative UI" ou "Agent-driven UI", place le prompt et la conversation au centre de l'expérience . + +Cependant, cette nouvelle liberté apporte son lot de défis, principalement autour de la fiabilité, de la sécurité et de la cohérence. + +Voici une feuille de route pour naviguer dans ce nouveau paradigme. + +### 🤔 Centrer l'UI sur le prompt ? Oui, mais... + +Oui, l'interface utilisateur doit être centrée sur le prompt, mais de manière structurée. Le prompt devient le principal vecteur d'intention de l'utilisateur. L'IA interprète cette intention et génère une interface utilisateur dédiée à la tâche à accomplir. + +Cela ne signifie pas pour autant abandonner les widgets, graphiques et autres composants d'interface riches. L'IA doit être capable de les assembler et de les configurer à la volée. La clé est que l'interface (UI) est dictée par le besoin de l'utilisateur, qui est lui-même exprimé par le prompt, transformant l'agent en un véritable "orchestrateur d'interface". + +### 🎨 Choisir les bonnes librairies et systèmes de génération d'UI + +La génération d'UI par l'IA se décline en plusieurs approches, classées du plus contrôlé au plus ouvert. Comprendre ces approches vous aidera à choisir les outils adaptés. + +**1. L'approche "UI Déclarative" (Recommandée)** + +C'est l'approche qui répond le mieux à votre besoin de sécurité et de contrôle. L'IA ne génère pas de code exécutable, mais un **spécification JSON structurée** qui décrit l'UI (les composants, leurs propriétés et leurs données). Le front-end possède un "catalogue" de composants prédéfinis qu'il sait rendre, et il utilise cette spécification pour les afficher . + +* **Avantages:** Sécurisé (pas d'exécution de code arbitraire), contrôle total sur le rendu, possibilité de streamer l'UI au fur et à mesure de la génération, et "data-binding" intégré pour des interactions réactives . +* **Librairies clés pour cette approche:** + +| Librairie/Framework | Description | Points clés | +| :--- | :--- | :--- | +| **`json-render`** | Framework "Generative UI" polyvalent. | Permet de définir un catalogue de composants avec leurs schémas. L'IA génère un JSON conforme. Supporte React, Vue, React Native, et même Web Components. Idéal pour un contrôle total avec un rendu cross-platform . | +| **`genui` (Flutter)** | Package Flutter pour UI génératives. | Utilise les concepts de catalogue et de modèle de données. Le `GenUiConversation` gère tout le cycle de vie, de l'envoi du prompt au rendu et à la gestion des interactions . | +| **A2UI (Agent-to-User Interface)** | Protocole standardisé (Google) pour ce type d'UI. | C'est une spécification ouverte, soutenue par des implémentations comme **CopilotKit** (React) ou **Freesail** (React). Elle standardise les messages (création de surface, mise à jour des composants, mise à jour des données) pour une meilleure interopérabilité . | +| **`prefab-ui` (Python)** | Framework pour construire des UIs en Python, conçu pour MCP Apps. | Idéal si vous voulez que l'agent génère lui-même l'UI en Python. Il propose un DSL (Domain Specific Language) en Python pour décrire l'interface, qui est ensuite compilée en JSON et rendue par un front-end React . | + +**2. L'approche "UI Contrôlée"** + +C'est l'approche la plus simple et la plus sûre. Le développeur crée des composants UI (par exemple, `WeatherCard`, `DataChart`) et l'agent décide lequel utiliser et avec quelles données, souvent via l'appel d'un outil. L'UI est pré-construite, l'IA ne fait que la sélectionner et la paramétrer . +* **Exemple:** L'agent appelle un outil `get_weather`. Sur le front-end, on sait que cet outil doit afficher un composant `WeatherCard`. On peut même montrer différents états (chargement, résultat) . + +**3. L'approche "UI Ouverte" (À Utiliser avec Prudence)** + +L'agent génère du code complet (HTML, etc.) qui est rendu dans un conteneur sécurisé (comme un iframe). C'est la plus flexible, mais aussi la plus risquée en termes de sécurité et de cohérence visuelle . + +### 🔒 Éviter les "Widgets Hallucinés" : L'Importance du Design System + +C'est ici que la structuration est cruciale. Pour éviter que l'IA ne "produise des widgets hallucinés", vous devez lui fournir un cadre strict. L'outil principal est le **Design System** et le **Catalogue de Composants**. + +1. **Définissez un Catalogue :** Vous créez une "boîte à outils" de composants que l'IA est autorisée à utiliser. Pour chaque composant, vous définissez son nom, sa description et son schéma de propriétés (c'est-à-dire quelles données il accepte). Par exemple, un composant `Card` peut avoir une propriété `title` . +2. **Fournissez le Catalogue à l'IA :** Ce catalogue est inclus dans le prompt système de l'IA. Elle sait ainsi quels sont les "briques" à sa disposition, ce qu'elles font et comment les utiliser . +3. **Validez la Sortie :** Sur le front-end ou via une passerelle, on valide que la spécification JSON générée par l'IA respecte bien le schéma défini dans le catalogue. Cela permet d'ignorer ou de corriger toute tentative de génération de composants non autorisés, éliminant les "hallucinations" structurelles . + +> **Point de vigilance :** Les librairies mentionnées (json-render, genui, A2UI) intègrent toutes ce mécanisme de catalogue. C'est la pierre angulaire d'une UI générative fiable. + +### 🧱 Structuration d'une UI Dynamique vs SPA + +Une UI générative (GenUI) n'est pas une SPA classique. Là où la SPA a un état et un routage prédéfinis, la GenUI est éphémère et contextuelle. Cependant, elle peut s'appuyer sur des architectures existantes. + +* **L'approche "API First" est toujours valable et même essentielle.** L'UI générative est une nouvelle couche client qui **consomme** et **envoie** des données via des APIs. La séparation entre le front-end et le back-end reste la bonne pratique. +* **Nouveaux concepts architecturaux à intégrer:** + * **Surfaces :** L'IA peut créer des "surfaces" (comme des zones ou des fenêtres) dans l'UI pour y placer des composants . La chat peut n'être qu'une surface parmi d'autres. + * **Data Binding :** Les composants UI sont liés à un modèle de données. Les interactions de l'utilisateur (ex: remplir un champ) mettent à jour ce modèle, ce qui peut déclencher de nouvelles actions de l'agent ou la mise à jour d'autres composants . + * **State Store :** Des bibliothèques comme Zustand, Jotai ou Redux peuvent être utilisées comme l'état central de l'UI générative, notamment pour gérer le data binding et les conditions d'affichage . + +### 💎 Conclusion : Comment se lancer ? + +Le développement d'IHM à l'ère de l'IA est un changement de paradigme majeur, mais il repose sur des principes solides. + +1. **Définissez votre approche :** Commencez avec une approche **"UI Contrôlée"** en utilisant des outils comme `useFrontendTool` de CopilotKit pour des cas simples. Elle est plus facile à mettre en œuvre et très sécurisée . +2. **Construisez votre Catalogue :** Pour une approche plus dynamique, choisissez un framework supportant l'UI déclarative (**json-render**, **A2UI avec CopilotKit/Freesail**) et investissez du temps à définir un **design system et un catalogue de composants solide** . C'est la clé pour garder le contrôle et la cohérence. +3. **Pensez "Maîtriser pour Déléguer" :** Comme le souligne la pratique "Claude Design" chez GitLab, l'IA est un accélérateur de créativité et un partenaire de réflexion puissant, mais elle ne remplace pas le jugement humain . Utilisez-la pour explorer, itérer et générer rapidement des hypothèses, puis affinez et validez les résultats. Votre rôle évolue de "constructeur d'UI" à "architecte et validateur d'UI générées". \ No newline at end of file diff --git a/doc/RougailBasedAppStructuration.md b/doc/RougailBasedAppStructuration.md new file mode 100644 index 0000000..bdf652b --- /dev/null +++ b/doc/RougailBasedAppStructuration.md @@ -0,0 +1,2 @@ + +# TODO \ No newline at end of file diff --git a/doc/SparqlVsCypher.md b/doc/SparqlVsCypher.md new file mode 100644 index 0000000..1af2d79 --- /dev/null +++ b/doc/SparqlVsCypher.md @@ -0,0 +1,34 @@ +Cypher n'est pas une alternative directe à SPARQL, car ils sont conçus pour des modèles de données fondamentalement différents. Le choix entre les deux dépend donc avant tout de la nature de vos données et de vos objectifs. + +La différence réside dans la distinction entre les **graphes de propriétés** (Property Graphs) et les **graphes RDF** (Resource Description Framework). + +### 📊 La différence fondamentale : le modèle de données + +| Caractéristique | Cypher (et les graphes de propriétés) | SPARQL (et les graphes RDF) | +| :--- | :--- | :--- | +| **Modèle de données** | Graphes de propriétés : nœuds et relations (arcs) qui peuvent tous deux posséder des paires clé-valeur (propriétés). | Graphes RDF : un ensemble de triplets (sujet, prédicat, objet). C'est un modèle standardisé par le W3C, conçu pour le Web sémantique. | +| **Philosophie & Standardisation** | Langage industriel de fait (originellement pour Neo4j) qui s'oriente vers une norme ISO (GQL). | Standard officiel du W3C (SPARQL 1.1), garantissant une forte interopérabilité entre systèmes. | +| **Force principale** | **Exploration intuitive et performante** des relations. Excellent pour les applications où la structure du graphe et ses attributs sont au premier plan (réseaux sociaux, détection de fraude, recommandation). | **Intégration et raisonnement sémantique**. Excellent pour relier des données hétérogènes, utiliser des ontologies et effectuer des requêtes fédérées sur des sources de données distribuées. | +| **Expressivité des Relations** | Les relations sont des citoyens de première classe, peuvent avoir des propriétés (ex: une relation `ACHAT` avec les propriétés `date` et `montant`). | Les relations (prédicats) ne peuvent pas avoir de propriétés directement. Pour ajouter des métadonnées à une relation, il faut utiliser des techniques de "réification", qui sont plus complexes. | + +### 🤔 Comment faire votre choix ? + +Le choix dépend entièrement de votre cas d'usage : + +* **Choisissez Cypher (graphe de propriétés)** si : + * Vous construisez une application opérationnelle comme un moteur de recommandation, un outil de détection de fraude, une analyse de réseau social ou de parcours client. + * Vous avez besoin d'une syntaxe intuitive et visuelle (en ASCII-art) pour exprimer des motifs de graphe (ex: `(a:Person)-[:KNOWS]->(b)`). + * La performance et la simplicité de modélisation d'attributs sur les relations sont essentielles. + +* **Choisissez SPARQL (graphe RDF)** si : + * Vous travaillez dans un contexte où l'interopérabilité et le partage de données sont clés (ex: données gouvernementales liées, publications scientifiques, bases de connaissances). + * Vous devez effectuer des requêtes fédérées sur plusieurs bases de données RDF distantes. + * Vous avez besoin de capacités de raisonnement sémantique avancées en utilisant des ontologies (OWL, RDFS). + +### 🚀 La convergence : GQL et l'interopérabilité + +Le paysage est en pleine évolution. Le nouveau standard **ISO GQL (Graph Query Language)** s'inspire fortement de Cypher, ce qui pourrait en faire le futur langage unifié pour les graphes de propriétés. Par ailleurs, des solutions comme **Amazon Neptune** montrent que l'interopérabilité est possible en supportant à la fois SPARQL et openCypher sur des données RDF, ou en permettant à openCypher d'interroger directement un graphe RDF. + +En résumé, Cypher est l'outil idéal pour les "applications graphiques" intuitives, tandis que SPARQL est le standard pour l'échange de données et le Web sémantique. + +Si vous avez un cas d'usage plus spécifique en tête, je pourrai vous aider à préciser la solution la plus adaptée. \ No newline at end of file diff --git a/doc/index.md b/doc/index.md index d657b73..09492a1 100644 --- a/doc/index.md +++ b/doc/index.md @@ -1,10 +1,18 @@ # Baklava's documentation +## Repenser les UI + +[[PromptBasedApplications]] + ## Variable name search engine - [[lexique]] - [[lexique_variable]] + +## UI structuration tool + +- [[GraphBasedTool]] + ## LLM prompt UI -- [[AsynchronousTextualPrompt]] -- \ No newline at end of file +- [[AsynchronousPrompts]] \ No newline at end of file diff --git a/persona/initial_user_prompt.md b/doc/persona/initial_user_prompt.md similarity index 75% rename from persona/initial_user_prompt.md rename to doc/persona/initial_user_prompt.md index b99580d..6fdda64 100644 --- a/persona/initial_user_prompt.md +++ b/doc/persona/initial_user_prompt.md @@ -1,3 +1,8 @@ +--- +type: persona +description: initial user prompt +--- + Voici mon lexique (au format JSON) : [COLLE ICI TON LEXIQUE] diff --git a/persona/sytem_prompt.md b/doc/persona/sytem_prompt.md similarity index 97% rename from persona/sytem_prompt.md rename to doc/persona/sytem_prompt.md index 67a4242..3839004 100644 --- a/persona/sytem_prompt.md +++ b/doc/persona/sytem_prompt.md @@ -1,3 +1,9 @@ +--- +type: persona +description: prompt système +--- + + Tu es un lexicographe interactif spécialisé dans la recherche de mots-clés à partir d’un lexique que je t’ai fourni. TON RÔLE :