← Projets
PROJET INTERNE — EN PRODUCTION

BlueprintRunner

Un message. Une solution déployée sur Vercel. Zéro intervention manuelle.

LE PROBLÈME

Développer une solution avec un LLM en mode libre produit des résultats non déterministes. L'agent improvise l'orchestration, accumule les erreurs à chaque étape, et diverge. Ce n'est pas un problème de modèle — c'est un problème d'architecture.

LangChain et les frameworks similaires laissent le LLM décider du flux. BlueprintRunner fait l'inverse : le graph d'étapes est figé dans le code, le LLM ne remplit que des slots définis avec un schéma strict. La fiabilité vient du déterminisme, pas du modèle.

LA DÉCISION D'ARCHITECTURE

Inspiré de l'architecture Stripe Minions — des agents de code one-shot qui entrelacent boucles d'agent et code déterministe (git, lint, tests), et qui mergent chez Stripe plus de 1 000 pull requests par semaine sans code écrit par un humain. BlueprintRunner pousse le principe plus loin : séparer radicalement l'orchestrateur déterministe (qui décide quoi faire et dans quel ordre) du LLM (qui ne fait que produire un JSON validé dans un slot isolé).

Le LLM ne voit jamais le graph complet. Il reçoit un contexte précis, produit une sortie TypeBox-validée, et s'arrête. C'est le runner qui décide de la suite. Si la validation échoue : retry, puislastFailurehandler. Jamais de dérive silencieuse.

PIPELINE — DE SLACK À VERCEL
01

Message Slack

Un prompt en langage naturel décrit la solution à construire. C'est le seul input humain.

02

Blueprint Architect

Agent conversationnel qui traduit le prompt en blueprint.yaml : graph d'étapes ordonné, contrats d'entrée/sortie définis.

03

Exécution déterministe

BlueprintRunner parcourt le graph étape par étape. À chaque slot LLM : appel one-shot, validation TypeBox du JSON retourné, passage à l'étape suivante ou déclenchement du lastFailure handler.

04

Push Vercel

La solution est construite, testée (lint + tests), commitée et déployée automatiquement. Aucune intervention.

ANATOMIE D'UN BLUEPRINT

Le graph d'étapes est déclaratif. Chaque étape est soit déterministe (lecture, écriture, lint, déploiement), soit un slot LLM contraint par unoutput_schemastrict. Le runner exécute, valide la sortie, puis passe à l'étape suivante — ou déclenchelastFailuresans jamais diverger.

blueprint.yamlcsv → dashboard → Vercel
version: "1.0"
name: "csv-dashboard"
description: >
  Lit un fichier CSV, génère un composant React de visualisation,
  et déploie sur Vercel. Un prompt Slack suffit à déclencher le pipeline.

context:
  - output-contract.md
  - skills/react.md
  - skills/recharts.md

steps:

  # ── Étape 1 : lecture déterministe du fichier source
  - id: read_csv
    type: deterministic
    action: read_file
    params:
      path: "data/input.csv"
    output:
      raw: string              # contenu brut du CSV

  # ── Étape 2 : slot LLM — analyse des colonnes
  - id: analyse_schema
    type: llm
    depends_on: [read_csv]
    prompt: |
      Tu reçois un CSV brut. Identifie les colonnes pertinentes
      pour une visualisation (axes, métriques, catégories).
      Réponds uniquement en JSON valide, sans markdown.
    output_schema:
      type: object
      properties:
        x_axis:   { type: string }
        y_axis:   { type: string }
        chart_type:
          type: string
          enum: [bar, line, area, scatter]
        title:    { type: string }
      required: [x_axis, y_axis, chart_type, title]

  # ── Étape 3 : slot LLM — génération du composant React
  - id: generate_component
    type: llm
    depends_on: [analyse_schema]
    prompt: |
      Génère un composant React avec Recharts selon le schéma fourni.
      Utilise les données CSV passées en props.
      Réponds uniquement en JSON valide, sans markdown.
    output_schema:
      type: object
      properties:
        filename: { type: string }
        code:     { type: string }
      required: [filename, code]

  # ── Étape 4 : écriture déterministe du fichier
  - id: write_component
    type: deterministic
    action: write_file
    depends_on: [generate_component]
    params:
      path:    "{{ steps.generate_component.output.filename }}"
      content: "{{ steps.generate_component.output.code }}"

  # ── Étape 5 : lint — si échec, lastFailure stoppe proprement
  - id: lint
    type: deterministic
    action: run_lint
    depends_on: [write_component]
    on_failure: lastFailure

  # ── Étape 6 : push Vercel
  - id: deploy
    type: deterministic
    action: vercel_push
    depends_on: [lint]
    output:
      url: string              # URL de preview retournée par Vercel

# Résultat final exposé par le runner
output:
  preview_url: "{{ steps.deploy.output.url }}"
  chart_title: "{{ steps.analyse_schema.output.title }}"
CE QUE ÇA REND POSSIBLE

Prototyper un projet data, visualisation ou app Vercel en un seul prompt Slack. La solution est complète, valide, et déployée sans intervention supplémentaire. Ce n'est pas de la génération de code — c'est un pipeline de développement agentique de bout en bout.

BlueprintRunner est la base sur laquelle GTB construit des solutions d'automatisation du développement pour ses clients. Le même pattern — orchestration déterministe, LLM confiné, validation stricte — s'applique à tout pipeline métier qui exige de la cohérence en production.

STACK TECHNIQUE
RuntimeTypeScript strict, Node.js
ValidationTypeBox — schéma JSON strict sur chaque slot LLM
Orchestrationblueprint.yaml — graph d'étapes déterministe
LLMSlots one-shot isolés — le modèle ne voit pas le graph
InterfaceSlack (PI) — un message déclenche le pipeline
DéploiementVercel (push automatique) + Linux self-hosted

Ce pattern d'orchestration déterministe est applicable à vos processus métier. Audit, dimensionnement, déploiement — c'est la méthode GTB.