Aller au contenu
NDNicolas Desjardins, retour à l'aperçu
CV
Démo en ligne, code ouvert03 / Phase 3 · Livré

Agents d'opérations supervisés

Pipeline autonome multiagent d'opérations et de marketing

Rédige les fiches produits de chaque canal de vente à partir de vos données d'inventaire, vérifie chaque allégation au regard des règles et n'envoie rien tant qu'une personne n'a pas approuvé. Si le texte enfreint encore une règle après une réécriture, il est remis à une personne au lieu d'être envoyé, et chaque décision est consignée.

Page du projet(s'ouvre dans un nouvel onglet)Démo en ligne(s'ouvre dans un nouvel onglet)Code source sur GitHub(s'ouvre dans un nouvel onglet)

Le problème réglé

Lancer un produit sur plusieurs canaux suppose d'extraire les données du SKU d'une base transactionnelle, de rédiger une fiche produit, des puces de place de marché et une publication sociale, puis de vérifier chaque allégation contre la réglementation, comme les règles de Santé Canada sur les produits de santé naturels. Une chaîne linéaire ne peut ni réessayer, ni attendre un réviseur, ni expliquer ce qu'elle a fait, et un modèle qui note ses propres textes laisse passer des erreurs mécaniques comme un dosage interverti.

Ce qui a été mesuré

  • Mesuré
  • Cible

  • 3 / 3

    envois précédés d'une décision humaine consignée, 15 octobre 2026

    mesuré

  • 9 / 9

    réponses correctes du modèle gratuit principal, banc d'essai daté

    mesuré

  • 504

    tests hermétiques, sans réseau, sans base, sans clé

    mesuré

  • 0,00 $

    de coût marginal par exécution sur la pile gratuite

    mesuré
Comment ça marchepour les équipes techniques

En termes techniques

Une machine à états LangGraph cyclique qui transforme un SKU d'inventaire en textes marketing par canal pour un produit de santé naturel homologué, et refuse de les laisser sortir tant qu'une personne ne les a pas signés. Un superviseur fait passer le travail par une consultation SQL en lecture seule, un agent de rédaction et un validateur de conformité qui répondent sous des schémas JSON stricts; les violations reviennent au rédacteur un nombre borné de fois, puis le graphe se met en pause sur un point de contrôle PostgreSQL. Une approbation ou une modification le reprend et déclenche un seul webhook signé HMAC, et un rejet termine le fil sans rien envoyer. La démo publique fonctionne à coût nul sur des modèles gratuits.

Architecture

Un nœud superviseur valide la requête et la route sur un état typé à réducteurs explicites. L'agent d'inventaire est un outil SQL déterministe en lecture seule : une seule consultation paramétrée, aucun appel de modèle, et un SKU inconnu ou en rupture termine l'exécution avant tout appel de modèle. L'agent de rédaction produit une fiche produit, cinq puces de place de marché, une publication sociale et une consigne d'image sous un schéma JSON strict, et l'agent validateur audite le brouillon contre la licence sous un autre. Un ensemble de vérifications Python déterministes (numéro de licence affiché, quantités d'ingrédients, mises en garde obligatoires, formulations interdites) l'emporte sur le modèle pour les règles mécaniques : leurs constats gagnent toujours, et une objection de pure formulation sur une allégation autorisée reformulée est écartée. Les violations reviennent au rédacteur avec des instructions de révision structurées pendant un nombre borné de cycles, et un brouillon encore fautif quand le budget est épuisé est remis à une personne. Le graphe est compilé avec interrupt_before sur le nœud webhook, si bien que chaque exécution s'arrête sur un point de contrôle PostgreSQL (langgraph-checkpoint-postgres sur un seul pool psycopg) et peut attendre son réviseur malgré les redémarrages. L'endpoint de révision approuve, modifie ou rejette : l'approbation et la modification reprennent le graphe, et un rejet est écrit dans le fil comme si le nœud webhook avait tourné, de sorte qu'il ne s'exécute jamais. Le nœud webhook refuse d'envoyer sans décision humaine consignée, signe la charge utile en HMAC-SHA256, réessaie sur 429, 5xx et délais dépassés, et écrit chaque tentative dans un journal d'audit. La génération passe par une chaîne ordonnée de modèles OpenRouter gratuits qui se répare quand un modèle est retiré.

Pile technique

  • Python 3.12
  • LangGraph
  • FastAPI
  • Pydantic v2
  • PostgreSQL
  • langgraph-checkpoint-postgres (psycopg)
  • OpenRouter
  • HMAC-SHA256 webhooks
  • Render
  • Neon
  • GitHub Pages

Éléments de preuve

  • Six scénarios enregistrés le 15 octobre 2026 sur la pile en ligne et publiés tels que l'API les a renvoyés : cas ordinaire, autocorrection, escalade, modification, rejet et rupture de stock. Les cinq exécutions qui ont rédigé un texte ont pris de 19 à 66 secondes sur des modèles gratuits, les douze appels de modèle ont tous été répondus par le premier modèle de la chaîne, et chacun des trois envois a attendu une décision humaine consignée.
  • Dans l'exécution d'escalade, le modèle validateur a jugé le brouillon conforme, et la vérification déterministe des dosages a attrapé trois quantités de probiotiques interverties (10, 10 et 20 milliards d'UFC là où la licence dit 20, 20 et 10). Le brouillon est allé à une personne plutôt que vers la sortie, et la personne l'a rejeté.
  • Dans l'exécution de rejet, le validateur a renvoyé le premier brouillon pour une allégation non autorisée et a accepté la réécriture : un cycle d'autocorrection, 66 secondes. Le réviseur l'a ensuite rejeté, et le nœud webhook n'a jamais tourné.
  • Banc d'essai de modèles daté du 15 octobre 2026 : 27 appels répartis sur trois modèles gratuits, sur les propres cas du pipeline, chaque réponse sauvegardée en JSONL pour que les chiffres puissent être recalculés sans appeler de modèle. Le modèle Liquid a répondu correctement 9 fois sur 9 avec une médiane de 9,1 s et le modèle NVIDIA 8 fois sur 9, et c'est l'ordre de la chaîne livrée.
  • 504 tests hermétiques : ni réseau, ni PostgreSQL, ni clé API. Les deux transports HTTP lèvent une exception avant qu'une requête ne sorte du processus, les vrais clients SDK ne peuvent pas être construits dans la suite, et le README comme la page du projet sont tenus au code par des tests. Quatre tests de plus font tourner le graphe compilé sur un vrai checkpointer PostgreSQL quand une base est fournie.
  • Le webhook est la seule mutation. Le nœud refuse d'envoyer tant que le statut de révision humaine n'est pas approuvé ou modifié, un rejet est inscrit au point de contrôle comme si le nœud avait tourné, le récepteur vérifie la signature en temps constant, et chaque tentative figure au journal d'audit.

Pipeline de requête

  1. 01

    Supervision

    Requête validée, état typé à réducteurs, routage selon ce que l'état contient déjà

  2. 02

    Requête

    Consultation SQL paramétrée en lecture seule, sans modèle; un SKU inconnu ou en rupture termine l'exécution

  3. 03

    Rédaction

    Fiche produit, cinq puces, publication sociale, consigne d'image; schéma JSON strict

  4. 04

    Audit

    Modèle validateur et vérifications déterministes qui gagnent toujours; les violations rebouclent, un nombre borné de fois, puis remontent à une personne

  5. 05

    Interruption

    interrupt_before sur le nœud webhook; approuver, modifier ou rejeter par l'endpoint de révision

  6. 06

    Envoi

    Webhook signé HMAC-SHA256, réessais sur 429, 5xx et délais dépassés, chaque tentative au journal d'audit