Unit — Programmation visuelle et specs executables comme reduction de risque¶
Resume¶
Unit (4.9K stars, MIT, TypeScript) est un langage de programmation visuelle ou les programmes sont des graphes de "units" (FSM multi-input/multi-output) connectees entre elles — comme des pipes Unix en 2D. IDE web, runtime browser + Node.js, support tactile/voix. Les units sont formellement definies comme des machines a etats finis, pas juste des boites visuelles. Beta, 2530 commits, 5 ans de developpement.
Analyse critique¶
Le projet est techniquement ambitieux (FSM formelles, TypeScript, runtime dual). L'analogie pipes Unix en 2D est juste. Mais les langages visuels existent depuis 30 ans (LabVIEW, Max/MSP, Node-RED, n8n) sans remplacer le texte pour du dev serieux. 4.9K stars en 5 ans montre une adoption lente.
L'interet n'est pas Unit en soi mais le concept qu'il incarne : les specs visuelles devraient etre executables, pas juste documentaires.
Pertinence ProbatioVault¶
Impact modere. Unit revele un trou reel dans notre pipeline de gouvernance.
Le gap actuel :
Les diagrammes Mermaid dans nos specs sont de la documentation morte. L'agent step 6b les lit, les interprete, ecrit du code. Si l'agent comprend mal le diagramme, le bug passe — les tests sont ecrits depuis la meme spec texte, pas depuis le diagramme execute.
Risque concret : un state diagram dit "A → B sur event X, B → C sur event Y". L'agent implemente A → C directement (raccourci). Les tests verifient A → C (ecrits depuis la meme comprehension). L'etat intermediaire B est perdu — bug silencieux.
Ce qu'on a deja (et ses limites) : - TLA+/Prolog : verifie la coherence formelle, mais l'extraction spec → TLA+ est textuelle — elle ignore les diagrammes Mermaid - Coherence inter-EB : verifie les contradictions entre besoins, pas la conformance code/diagramme
Ce qui manquerait : parser les Mermaid state diagrams des specs → generer des assertions de conformance. Trois approches possibles : 1. Mermaid → TLA+ : compiler les state diagrams en specs TLA+ verifiables (ajouter a notre pipeline formel existant) 2. Mermaid → tests : generer des tests de transition d'etat depuis la structure du graphe, pas depuis le texte de la spec 3. Mermaid → simulation : executer le diagramme comme prototype avant le code (approche Unit-like)
L'approche 2 (Mermaid → tests) est la plus pragmatique : pas de nouvelle infra, juste un script de generation de tests a integrer en step 2 ou step 6a.