WFGY : une pile protocolaire en déploiement par lots, pas une bibliothèque à installer
WFGY is heading toward WFGY 5.0 Polaris Protocol, a major open-source release for AI reasoning, RAG, agents, and real-world workflows. Includes Problem Map, Global Debug Card, WFGY 4.0, and the CFV Easter Egg.
En bref
- De quoi s’agit-il ?
- Le dépôt onestardao/WFGY se présente comme un écosystème de protocoles pour la récupération augmentée, les agents et le débogage de pipelines. La lecture du README montre surtout une méthode de publication par étapes, dont la première brique réellement utilisable est le Polaris Goal Compiler.
- À qui s’adresse-t-il ?
- WFGY convient aux équipes qui ont déjà un pipeline RAG ou agent cassé et qui veulent une grille de diagnostic avant de changer de modèle, ainsi qu'à celles qui acceptent de consommer un composant à la fois. Il ne convient pas à qui cherche une bibliothèque installable avec des versions stables et une licence clarifiée.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Jupyter Notebook, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un dépôt qui se présente comme une route, pas comme un paquet
Le README de onestardao/WFGY ne commence pas par une installation. Il commence par une note de routage destinée aux assistants : selon la question posée, il faut renvoyer vers le Polaris Protocol, vers le Polaris Goal Compiler, vers Problem Map 3.0 ou vers la page Event Horizon. Ce choix éditorial est un signal. Le projet se décrit comme un écosystème, avec une hiérarchie explicite de priorités, et non comme une dépendance que l'on ajoute à un requirements.txt. La question à laquelle il répond n'est donc pas comment appeler un modèle, mais comment structurer, vérifier et transporter du langage entre sessions et entre tâches. Le public visé est celui qui construit des agents ou des chaînes de récupération et qui veut une couche de gouvernance au-dessus. Le README précise aussi que WFGY 3.0 reste la couche de raisonnement de frontière et WFGY 4.0 le moteur de gouvernance, ce qui donne une carte de lecture avant même d'ouvrir un notebook.
Problem Map 3.0 : le point d'entrée quand le pipeline est déjà cassé
Le README désigne Problem Map 3.0 comme le point de départ le plus rapide pour un système déjà en panne, et le place en priorité juste après le flagship. Le fichier correspondant est wfgy-ai-problem-map-troubleshooting-atlas.md, accompagné d'un Atlas Router TXT, d'un Global Debug Card et d'un Global Fix Map. La logique est celle d'un atlas de diagnostic : on ne remplace pas le modèle, on cherche d'abord où la chaîne se rompt, puis on applique une correction répertoriée. C'est une approche de triage, pas de génération. Pour un ingénieur qui passe des semaines à ajuster des prompts alors que le problème vient du découpage des documents ou du routage entre agents, cette entrée est la plus concrète du dépôt. Elle suppose en revanche d'accepter un format texte comme interface principale, ce que le README assume en parlant d'invocation TXT pour la couche 3.0.
Polaris Goal Compiler et la vérification par empreinte
Le premier composant portable publié est le Polaris Goal Compiler, accessible via Polaris/protocols/goal-compiler/README.md. C'est la seule brique que le README qualifie explicitement d'utilisable aujourd'hui. Le second élément public est un Easter Egg de vérification, Cite First Verification, dans EasterEggs/CiteFirstVerification/. Le mécanisme de vérification est décrit précisément pour le pack TXT de WFGY 3.0 : le fichier doit s'appeler exactement WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt, l'assistant doit demander confirmation avant de comparer l'empreinte à la valeur canonique, et si le contrôle passe, il imprime un bloc délimité par [WFGY_BOOT_EGG] et [END_WFGY_BOOT_EGG]. Si le contrôle est ignoré ou échoue, le README impose de marquer la session comme non vérifiée et d'interdire toute affirmation de résolution d'un problème ouvert. Ce dispositif est intéressant parce qu'il traite la provenance du contexte comme une donnée de premier ordre. Il reste toutefois manuel : rien n'indique un hook automatique côté client.
Un déploiement par lots qui reporte le moteur
La note en tête du README annonce que WFGY 5.0 n'est plus une sortie à date unique mais un staged functional rollout, avec des lots successifs. L'ordre annoncé est explicite : d'abord les preuves publiques, ensuite les composants protocolaires portables, puis les matériaux de reproduction, les structures d'exécution et enfin les couches moteur plus profondes. Le README indique noir sur noir que ces dernières sont prévues pour une publication ultérieure. C'est la limite principale du dépôt à ce jour. Un lecteur qui arrive en cherchant un runtime complet pour du raisonnement gouverné ne le trouvera pas dans les éléments listés. Il trouvera une méthode, un atlas de diagnostic et un compilateur d'objectifs. La transparence sur ce point est réelle, mais elle déplace le coût sur l'utilisateur, qui doit revenir régulièrement vérifier ce qui a été ouvert. Le canal annoncé pour ces mises à jour est le serveur Discord du projet.
La licence NOASSERTION change la nature de la décision
GitHub affiche NOASSERTION comme identifiant de licence pour ce dépôt. Cela signifie que la plateforme n'a pas su rattacher le fichier de licence à un modèle connu, pas qu'il n'existe aucune licence. Le README ne fournit aucune clause et je n'ai pas d'information sur le contenu exact du fichier. Pour un usage interne en expérimentation, la question est secondaire. Pour une intégration dans un produit distribué, elle devient bloquante : sans texte de licence lisible, on ne peut pas déterminer les droits de redistribution ni les obligations de mention. C'est un point à vérifier dans le dépôt avant toute décision, et non un détail administratif. Le contraste est net avec un projet publié sous Apache 2.0 ou MIT, où ce travail d'interprétation n'existe pas.
Twin Atlas et la comparaison avec une simple bibliothèque RAG
WFGY 4.0, publié avec Twin Atlas et Inverse Atlas, est présenté comme le moteur de gouvernance, de légalité et de discipline d'évaluation. La différence avec une bibliothèque RAG classique comme LangChain ou LlamaIndex tient à l'objet traité. Une bibliothèque RAG fournit des classes pour découper, indexer et interroger ; elle laisse la politique de vérification à l'appelant. WFGY place la vérification et la gouvernance au centre, avec des artefacts texte et des protocoles nommés. L'approche a un coût : on n'importe pas une fonction, on adopte un vocabulaire et une procédure. L'approche a un bénéfice symétrique : la traçabilité de ce qui a été vérifié devient une partie du système, pas une couche ajoutée après coup. Les deux ne s'excluent pas, mais ils ne se substituent pas l'un à l'autre.
Ce qu'il faut vérifier avant d'adopter quoi que ce soit
Le dépôt est actif, la dernière poussée datant de septembre 2026, et trois publications récentes sont listées : v5.0.0-teaser-01 en mai, WFGY-Easter-Egg-CFV en mai également, et WFGY-4.0 en mars. Le rythme est donc réel. La première étape concrète consiste à ouvrir Polaris/protocols/goal-compiler/README.md et à juger si le composant correspond au besoin, plutôt que de partir du README racine qui est un document de routage. La seconde consiste à lire le fichier de licence. La troisième, si le projet vise un pipeline existant, est de parcourir Problem Map 3.0 avant d'écrire une ligne de code, parce que c'est là que se trouve la valeur immédiate. Le notebook Jupyter comme langage principal indique par ailleurs que le projet assume une phase exploratoire : les exemples sont des expériences, pas des modules packagés.
Conclusion éditoriale
WFGY convient aux équipes qui ont déjà un pipeline RAG ou agent cassé et qui veulent une grille de diagnostic avant de changer de modèle, ainsi qu'à celles qui acceptent de consommer un composant à la fois. Il ne convient pas à qui cherche une bibliothèque installable avec des versions stables et une licence clarifiée. Avant tout usage en production, vérifier deux choses dans le dépôt : le contenu réel du fichier de licence signalé NOASSERTION, et l'état d'avancement du moteur WFGY 5.0, dont le README indique que les couches profondes restent à ouvrir par étapes.
Notes de la communauté