Tribalbyte
Accueil / Projets

Créer et expérimenter / Logigramme fonctionnel

Modèle de langage local dans Godot

Explorer un comportement conversationnel dans un moteur de jeu à partir d’un modèle de langage exécuté localement.

Cadre
Projet personnel / exploration professionnelle
État
Exploration technique · intégration à confirmer
Outils
Godot · Modèle local · JSON

Le besoin

Explorer un comportement conversationnel dans un moteur de jeu à partir d’un modèle de langage exécuté localement.

L’analyse

La première fiche d’automatisation décrit une piste d’intégration avec Llama 3.2. Le point d’analyse est le contrat entre une réponse probabiliste et une application qui attend des champs et des actions précis.

L’exploration doit séparer génération de texte, validation du format et décision de l’application. Le modèle ne devient pas une autorité sur l’état du jeu.

Le processus documenté

Du besoin au résultat

Logigramme fonctionnel
Parcours fonctionnel de Modèle de langage local dans GodotDécrire l’échange attendu puis Préparer le contexte du dialogue puis Recevoir une réponse structurée puis Contrôler les champs attendus puis Appliquer une action autorisée puis Mesurer cohérence et latence. Point de contrôle : Réponse conforme ?. Refuser l’action et rendre l’erreur visible.01 Décrire l’échange attendu02 Préparer le contexte du dialogue03 Recevoir une réponse structurée04 Contrôler les champs attendusRéponse conforme ?À traiterRefuser l’action et rendrel’erreur visible.Suite du parcours05 Appliquer une action autorisée06 Mesurer cohérence et latence
Vue fonctionnelle du parcours. Le bloc latéral rend explicite le cas nécessitant un contrôle ou une intervention.

Règles de gestion

Ce que l’outil doit respecter.

  1. RG-01Cette piste reste exploratoire, sans produit autonome validé.
  2. RG-02Les réponses structurées doivent respecter un contrat de données.
  3. RG-03Une sortie non conforme doit être rejetée ou présentée comme une erreur.
  4. RG-04Les actions du jeu restent limitées à celles explicitement prévues par l’application.

Ce que ce projet démontre.

Contrat d’échange, traitement des réponses invalides et frontière entre dialogue et action.

Le niveau de réalisation ci-dessous distingue les fonctions présentes des vérifications qui restent à mener.

État au 13 octobre 2026

Une réalisation, un périmètre précis.

Ce qui est réalisé

Une expérimentation est décrite dans la documentation de portfolio existante.

Ce qui a été vérifié

Aucun résultat de recette autonome retrouvé pour cette révision documentaire.

Limites actuelles

Contrat détaillé, gestion de la latence et tests de robustesse restent à confirmer.

Prochaine étape

Conserver un scénario minimal avec réponses valides et invalides reproductibles.

Exemples de critères de recette

Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.

  1. Une réponse mal formée ne modifie pas l’état du jeu.
  2. L’absence du modèle local produit un message compréhensible.

Parlons de votre projet

Un besoin concret.
Une première discussion.

Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.

Échanger avec Loïc