Nous avons construit un planificateur GOAP en une après-midi. Il produit en zéro milliseconde un plan propre en neuf étapes pour des objectifs d'ingénierie. Nous ne le laissons pas approcher une requête en irrecevabilité (motion to dismiss). Voici pourquoi - et les quatre verrous que nous fermerions avant de le faire.
L'argument de vente et le verdict
Le goal-oriented action planning (GOAP) est l'architecture qu'utilisent les moteurs d'échecs : conserver un arbre de futurs possibles, chercher le chemin le moins coûteux entre l'état présent et l'état visé, et élaguer le reste. C'est un bien meilleur ajustement pour le contentieux qu'un modèle conversationnel. Requêtes, discovery, procès - autant de séquences de coups sous contraintes. Les modèles conversationnels produisent la phrase plausible suivante. Les planificateurs s'engagent sur un objectif et remontent le raisonnement à rebours.
Faits clés
- Un planificateur GOAP A* opérationnel tient en 517 lignes de JavaScript pur, sans dépendance — porté en une après-midi depuis le goal_ui de claude-flow de ruflo.
- Le planificateur GOAP de claude-flow (ruflo) n'implémente pas de replanification adaptative : plan() exécute A* une seule fois, à la soumission de l'objectif — vérifié aux points d'appel dans Index.tsx et ResearchReportModal.tsx (EXTERNAL-CITE : source claude-flow de ruflo, lue directement).
- Déposer une requête 12(b)(6) sur le fond avant d'invoquer l'arbitrage peut emporter renonciation au droit d'arbitrer en vertu de Morgan v. Sundance (2022) — un planificateur au chemin le plus court fonce droit dedans.
Nous en avons donc construit un. 517 lignes de JavaScript pur, zéro dépendance, portées en une après-midi depuis le planificateur GOAP A* embarqué dans l'application React `goal_ui` de ruflo. Il tourne sur des objectifs d'ingénierie comme « livrer le refactor d'auth avec tests et une PR » en zéro milliseconde et produit un plan propre en neuf étapes.
Nous ne le laissons pas toucher à une requête réelle. Pas encore. Cet article explique pourquoi, et ce qui devrait changer avant que ce soit le cas. Si vous êtes venu chercher un éloge enthousiaste du prochain outil d'IA pour avocats, l'objet de cet article est l'inverse : voici la barre d'exigence que nous fixons avant de faire transiter un objectif de contentieux par un planificateur quelconque - le nôtre, celui de ruflo, ou n'importe quel autre - et l'écart entre le planificateur d'aujourd'hui et cette barre.
Ce qu'est vraiment le GOAP
Le GOAP prend trois entrées : un état cible (les faits que l'on veut voir vrais - « la PR est ouverte », « la CI est verte », « déployé »), un état initial (ce qui est vrai en ce moment), et une bibliothèque d'actions (tous les coups possibles, chacun avec ses préconditions et ses effets - « `open_pr` requiert `pushed=true` et `diff_reviewed=true` ; fixe `pr_open=true` »). Il exécute ensuite une recherche A* - le même algorithme que celui utilisé par un GPS pour contourner les embouteillages - sur l'espace des séquences d'actions, et renvoie le chemin valide le moins coûteux de l'état initial à l'état cible. Si une étape échoue en cours d'exécution, il est censé replanifier depuis le nouvel état.
Pour un avocat, l'analogie la plus proche est celle des échecs. Un grand maître ne pense pas coup par coup ; il tient un arbre de futurs possibles et l'élague à mesure que la partie se développe. Le GOAP, c'est cela, rendu mécanique. Ce n'est pas de la génération ; c'est de la recherche.
Ce que nous avons construit
Quatre fichiers : `planner.js` (165 lignes, A* + tas binaire min), `actions.js` (134 lignes, douze actions d'ingénierie), `parse.js` (58 lignes, table de phrases qui convertit l'anglais en état cible), `cli.js` (160 lignes, l'exécuteur). Total : 517 lignes. Aucune dépendance npm. Lisible en vingt minutes.
Nous l'avons fait tourner sur l'objectif « livrer le refactor d'auth avec tests et une PR » :
goal predicates: {"pr_open":true,"ci_green":true,"deployed":true}
1. understand_code (cost 2) -> /zoom-out
2. write_tests (cost 3) -> /tdd
3. run_tests (cost 1) -> bash:test
4. review_diff (cost 1) -> /review
5. commit (cost 1) -> git:commit
6. push_branch (cost 1) -> git:push
7. open_pr (cost 1) -> /ship
8. wait_ci (cost 5) -> bash:ci-wait
9. merge_and_deploy (cost 2) -> /land-and-deploy
total cost: 17
expansions: 13 time: 0 ms found: trueNeuf étapes, coût 17, treize expansions de nœuds, zéro milliseconde. Chaque étape correspond à une skill gstack ou à une commande shell, si bien que le plan est exécutable - pas seulement décoratif. Nous avons aussi testé un objectif plus petit (« tester le module de connexion » - 3 étapes, coût 6) et un objectif insatisfaisable (un prédicat qu'aucune action ne fixe - il a renvoyé `found: false` avec le plan partiel le plus proche, plutôt que de planter ou de boucler). Les trois comportements sont conformes à la spécification.
Cela a pris une après-midi. Ce n'est pas la partie difficile.
Pourquoi nous l'avons porté depuis ruflo
Ruflo (l'écosystème `claude-flow`) embarque un planificateur GOAP dans son application React `goal_ui` - `goapPlanner.ts`, un seul fichier, 180 lignes. L'architecture est solide. Nous l'avons extraite.
Pendant que nous y étions, nous avons lu le code source attentivement. Une affirmation qui ne survit pas à cet examen : le planificateur n'implémente pas de replanification adaptative. La méthode `plan()` exécute A* une seule fois, à la soumission de l'objectif, et renvoie un `Step[]` qui pilote une animation d'interface. Il n'y a dans ce fichier ni boucle de replanification, ni invalidation de plan, ni récupération d'échec. Nous avons vérifié les points d'appel dans `Index.tsx` et `ResearchReportModal.tsx`. Même constat.
Nous le mentionnons non pour dénigrer ruflo - le cœur du planificateur est du bon code - mais parce que cela compte pour la suite de cet article. La replanification adaptative est la fonctionnalité que l'on souhaiterait le plus voir avant de laisser un planificateur approcher un vrai dossier juridique, et l'implémentation open source la plus visible dans un domaine proche du juridique ne l'a pas. Nous non plus, pas encore. Aucun des autres acteurs que nous avons examinés ne l'a non plus.
Les trois objectifs de contentieux que nous n'avons pas fait tourner
Le plan initial était de faire tourner trois vrais objectifs de contentieux dans le planificateur et de faire noter le résultat par un litigator senior. Nous ne l'avons pas fait. Deux raisons. D'abord, faire transiter une stratégie de contentieux par une URL tierce publique - même une stratégie synthétique sur un cas de figure hypothétique - soulève des enjeux de secret professionnel que nous ne voulions pas affronter pour un simple article de blog. Si nous ne le ferions pas pour un client, nous ne devrions pas le faire pour nous-mêmes. Ensuite, notre bibliothèque d'actions compte douze entrées, toutes des actions d'ingénierie : `understand_code`, `write_tests`, `commit`, `push_branch`, `open_pr`, `wait_ci`, `merge_and_deploy`. La pointer vers une requête en irrecevabilité produirait un plan qui dirait sans sourciller à un litigator de faire un `git commit` de sa réponse.
Mais les trois cas de test que nous avons rédigés restent utiles - non comme des benchmarks que le planificateur aurait réussis, mais comme un aiguillon pour ce que la prochaine version devra gérer.
Cas 1 - Requête en irrecevabilité avec moyen tiré de la clause d'arbitrage. Consigne : « gagner une requête Rule 12(b)(6) dans un litige contractuel où le demandeur allègue une rupture de contrat, mais où le contrat comporte une clause d'arbitrage claire. » Le piège : le 12(b)(6) est le mauvais véhicule procédural. L'arbitrage se fait exécuter en vertu du FAA §§ 3-4, par une motion to compel. Déposer une requête 12(b)(6) sur le fond avant d'invoquer l'arbitrage peut emporter renonciation au droit d'arbitrer en vertu de Morgan v. Sundance (2022). Un planificateur qui rédige le 12(b)(6) entraîne le client en terrain de faute professionnelle.
Cas 2 - Stratégie de discovery pour une action collective salariale (wage-and-hour) de 10 salariés (Californie). Consigne : « construire un plan de discovery, en priorisant les demandes à faible coût et fort effet de levier. » Un collaborateur junior proposerait immédiatement des dépositions 30(b)(6). Le bon plan place les writtens avant les dépositions, sépare la certification de la classe du fond, fait courir la notification d'opt-out Belaire-West avant tout contact avec un membre potentiel de la classe, et assigne le prestataire de paie tiers (données plus propres, plus rapide, aucun coût de production côté défense). La séquence compte plus que le fond.
Cas 3 - Jugement sommaire sur une clause de non-concurrence en Californie. Deux pièges. Premier piège : la consigne cite le « Labor Code § 16600 » - une référence qui n'existe pas. La bonne référence est le Business & Professions Code § 16600. Second piège : même une fois la référence corrigée, l'employeur perd presque à coup sûr. SB 699 et AB 1076 (en vigueur depuis le 1er janvier 2024) ont élargi le § 16600 et ajouté une action privée assortie d'honoraires d'avocat. La bonne démarche est de conseiller au client d'abandonner totalement l'exécution de la clause de non-concurrence et de basculer, si les faits le permettent, sur une théorie de secret d'affaires fondée sur le CUTSA. Un planificateur qui trouve le chemin A* le plus court vers « gagner sur la non-concurrence » trouve un chemin vers un dépôt sanctionnable.
Ces trois cas partagent une caractéristique structurelle : le résultat le plus précieux n'est pas un plan vers l'objectif énoncé par l'utilisateur. C'est « votre objectif est erroné ; voici le bon objectif ».
Ce n'est pas ce que fait A. A trouve le chemin le plus court. Il trouvera des chemins les plus courts vers des stratégies perdantes.
Essayer HAQQ AI gratuitement
Découvrez la rédaction et la recherche juridique par IA
Quatre verrous avant de faire confiance à cet outil pour du contentieux
Voici ce qui devrait changer. Rien de tout cela n'est théorique - ce sont les quatre points en tête du plan v0.2.
1. La bibliothèque d'actions doit être repensée de bout en bout. Les actions d'ingénierie n'ont qu'une seule dimension de coût (le temps développeur) et des préconditions propres. Les actions juridiques ont des préconditions de compétence (le FAA s'applique, le tribunal est en Californie, la clause d'arbitrage survit au § 16600), des préconditions légales, des préconditions calendaires (le délai de réponse à la plainte expire dans 21 jours), et des préconditions contradictoires (la partie adverse n'a pas encore déposé telle requête). La dimension de coût diffère aussi : coût monétaire, heures d'associé, risque de sanctions, exposition au fee-shifting. Une bibliothèque d'actions juridiques sérieuse compte sans doute 200 à 500 actions avec des prédicats paramétrés - une véritable ontologie, rédigée par des litigators, délimitée par domaine de pratique.
2. Le parseur d'objectifs doit gérer le véritable jargon juridique. `parse.js` est une table de cinq phrases. Il fait correspondre « livrer le refactor d'auth » à `{pr_open, ci_green, deployed}` par recherche de sous-chaîne. Il ne peut pas analyser « gagner une requête Rule 12(b)(6) dans un litige contractuel où le contrat comporte une clause d'arbitrage claire ». Le correctif est modeste - Haiku en mode JSON, contraint par un schéma aux prédicats connus. Environ une demi-journée. Le plus petit des quatre verrous, et dérisoire sans les trois autres.
3. Le planificateur doit être auto-hébergé. Rien de ce qui touche à un vrai dossier client ne doit approcher `goal.ruv.io` ni aucune URL tierce. Au-delà des enjeux de secret professionnel, on ne peut pas auditer un planificateur que l'on ne fait pas tourner soi-même. Auto-hébergé, sur une infrastructure sous le contrôle de l'avocat, avec des journaux dont l'avocat est propriétaire. Non négociable pour HAQQ.
4. Le planificateur doit savoir quand refuser l'objectif. Le plus difficile des quatre. Un planificateur A pur, qui trouve toujours le chemin le plus court, exécutera à la perfection des stratégies perdantes. Le correctif n'est pas seulement la replanification adaptative (relancer A quand une action échoue). Le correctif est la critique de l'objectif : une étape d'IA juridique qui s'exécute avant la planification, confronte l'objectif au paysage doctrinal (§ 16600 + SB 699 + AB 1076 - « cette action en exécution perd »), et fait remonter un objectif alternatif (« basculer vers le CUTSA »). La replanification corrige les échecs d'exécution. La critique de l'objectif corrige le mode d'échec plus profond - s'engager pleinement sur un mauvais objectif. Les deux sont nécessaires ; aucun des deux n'est implémenté aujourd'hui.
Ce que cela enseigne sur l'IA dans le travail juridique
La plupart des produits d'IA s'optimisent pour « donne-moi une réponse assurée ». C'est la mauvaise forme pour le contentieux, où le travail consiste à remettre en question la demande elle-même, à distinguer ce que le client pense vouloir de ce dont il a réellement besoin, et à trouver le coup que le collaborateur junior aurait manqué.
Le GOAP se rapproche davantage de cette forme que le chat. Il est structurellement honnête : il indique quand il ne peut pas atteindre l'objectif. Il fait apparaître la séquence, pas seulement la conclusion. Il peut être inspecté, audité, rejoué.
Mais « plus proche que le chat » n'est pas « suffisant pour le travail juridique ». La barre n'est pas « produit un plan ». La barre est « produit un plan qu'un associé signerait de son nom ». Le GOAP d'aujourd'hui, le nôtre y compris, se situe à la première barre. La prochaine version doit atteindre la seconde. Nous ne pensons pas que quiconque vous vend aujourd'hui un planificateur - le nôtre y compris - mérite d'être mis en confiance sur un dossier réel sans que les quatre verrous ci-dessus soient fermés et démontrés.
Prochaines étapes
- Étape de critique de l'objectif (v0.2). Une passe Haiku en mode JSON « examiner cet objectif au regard de la doctrine ; proposer une alternative s'il est voué à l'échec », exécutée avant le planificateur.
- Parseur d'objectifs en IA juridique (v0.2). Remplacer la table de phrases.
- Replanification adaptative (v0.2). Envelopper `plan()` dans une boucle d'exécution qui relance la recherche quand une action échoue. Environ 50 lignes.
- Bibliothèque d'actions juridiques (v0.3). Délimitée par domaine de pratique, rédigée avec relecture de litigators, prédicats paramétrés. Des mois de travail - et le véritable produit.
Une fois ces quatre points réels et testés, nous ferons tourner les trois cas de contentieux ci-dessus et publierons les résultats - échecs compris, critique du litigator comprise. D'ici là, le seul résultat honnête est celui-ci : un planificateur d'ingénierie qui fonctionne, un planificateur juridique qui n'existe pas encore, et les notes de conception de ce à quoi le second doit ressembler.
