Voici un échec qui n'a rien à voir avec l'intelligence.
Demandez à un assistant IA bien ancré de créer une règle Spark dans SkySpark. Il connaît Axon. Il a indexé la bibliothèque de fonctions. Il vous écrit du code propre, syntaxiquement valide — et vous rend un seul record.
Une règle Spark fonctionnelle en exige deux : un record func contenant la logique de détection, et un record sparkRule configurant comment et où la règle s'applique. Ils doivent concorder l'un avec l'autre. Oubliez le second et rien ne génère d'erreur — vous avez simplement une règle qui ne se déclenche jamais, sur un site que vous croyiez surveillé.
Aucune connaissance syntaxique n'empêche cela. Ce n'est pas un problème de langage. C'est un problème de procédure, et la procédure est la moitié que nous laissons de côté.
Ce qu'est réellement un workflow
Un workflow est un fichier markdown. Toute l'astuce est là.
Il porte un peu de frontmatter pour pouvoir être catalogué, puis de la prose simple et des tableaux qui décrivent comment faire une chose correctement :
---
title: Créer une règle Spark
description: Guide pas à pas pour créer une règle Spark avec les records func et sparkRule
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Les deux serveurs MCP chargent au démarrage chaque .md de leur répertoire workflows/ et les exposent via le Model Context Protocol comme ressources lisibles sous une URI workflow://. Il n'est pas nécessaire de dire à l'assistant qu'ils existent — il peut les lister, les rechercher et récupérer le texte intégral à la demande, en pleine tâche.
Fantom MCP Server surveille ce répertoire. Déposez-y un nouveau fichier, et il devient disponible sans recompilation ni redémarrage.
Les deux catalogues aujourd'hui
Fantom MCP Server — 13 workflows, couvrant le volet construction et maintenance :
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server — 10 workflows, couvrant le volet analytique et exploitation :
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
Vingt-trois fichiers. C'est toute la mémoire procédurale encodée de cette chaîne d'outils à ce jour — et c'est très loin de suffire.
À quoi ressemble un bon workflow
L'exemple phare est ai-coding-loop, qui apprend à un assistant comment modifier du code sans laisser l'index pourrir sous ses pieds. La mémoire structurelle du serveur couvre plus de 240 projets et plus de 156 000 fonctions ; une modification non réindexée rend subtilement fausse chaque recherche ultérieure.
La règle sur laquelle repose toute la boucle tient en une phrase : après chaque modification de code, appelez reindexChangedFiles sur les chemins que vous avez touchés. Re-parser, reconstruire les nœuds et les arêtes du graphe, ré-embarquer les embeddings. Sautez cette étape et la prochaine recherche sémantique répondra à partir d'une base de code qui n'existe plus.
Remarquez ce que ce workflow n'est pas. Ce n'est pas la documentation d'une API — les descriptions d'outils s'en chargent déjà. C'est l'ordre des opérations, cette chose évidente une fois que quelqu'un vous l'a dite, et invisible tant qu'il ne l'a pas fait.
Ce fichier contient aussi une ligne bonne à reprendre : « Vérifié en conditions réelles le 2026-06-10 sur sedonaWebEditor. » Un workflow avec une date de vérification est un workflow auquel on peut se fier — ou que l'on peut retirer. Sans date, c'est une rumeur.
Pourquoi c'est là que ça coince
Le réflexe est de supposer que de meilleurs modèles combleront cet écart. Ce n'est pas le cas, et il vaut la peine d'être précis sur les raisons.
La faiblesse d'un modèle dans ce domaine n'est pas le raisonnement, et de moins en moins la syntaxe — les index ancrés gèrent la syntaxe. La faiblesse, c'est que le savoir procédural de l'automatisation des bâtiments n'a jamais été consigné sous une forme exécutable. Il vit dans la tête de quelques milliers de praticiens à travers le monde et se transmet par compagnonnage : vous apprenez qu'une règle Spark a besoin de deux records parce qu'un ingénieur chevronné vous a vu en livrer une qui ne se déclenchait pas.
Ce mécanisme de transmission ne passe pas à l'échelle et ne survit pas aux changements de poste. Chaque intégrateur redécouvre les mêmes procédures de son côté. Le même après-midi est perdu, en parallèle, dans une dizaine d'entreprises.
Un workflow, c'est ce moment de compagnonnage, écrit une seule fois, puis exécuté par chaque assistant sur chaque projet à partir de là.
Pourquoi cela doit venir de la communauté
Voici la partie que je ne peux pas faire seul — et qu'aucune entreprise ne peut faire seule non plus.
Les personnes qui détiennent ce savoir n'écrivent généralement pas de serveurs. L'ingénieur qui connaît le bon ordre de mise en service d'un rooftop, ou quel motif curRule tient vraiment la route sur des points calculés, est un spécialiste de la régulation — pas un développeur TypeScript. Si contribuer exigeait une pull request sur un moteur d'indexation, son savoir resterait où il est.
Ce n'est pas le cas. Un workflow est un fichier markdown. Du frontmatter, un titre, les étapes dans l'ordre, les pièges. Si vous savez écrire comment vous procédez, vous pouvez en contribuer un.
L'économie est absurdement en notre faveur. Écrire un workflow prend un après-midi. Il fait ensuite gagner un après-midi à chaque ingénieur qui aurait sinon dû le redécouvrir — dans toutes les entreprises, indéfiniment. Rares sont les domaines du logiciel où l'effet de levier est aussi déséquilibré.
Et le domaine est trop petit pour se fragmenter. L'automatisation des bâtiments n'est pas le développement web ; aucune armée de contributeurs n'arrive. Si ceux qui connaissent Sedona, Haxall, Axon et Xeto gardent chacun leurs procédures pour eux, tout le monde continue de payer les mêmes frais d'apprentissage. Vingt-trois fichiers, c'est ce qu'une poignée d'entre nous a produit. Deux cents, relus et datés, changeraient ce qu'un nouveau venu peut faire dès sa première semaine.
Les risques, en toute honnêteté
Un catalogue de workflows n'est pas bon par nature, et prétendre le contraire condamnerait la démarche à l'échec.
Un workflow erroné est pire que pas de workflow du tout. Un assistant le suit avec assurance et produit un résultat faux avec la même assurance. Une procédure absente produit au moins de l'hésitation ; une mauvaise procédure produit une mauvaise mise en service. La relecture compte ici plus que dans la plupart des documentations.
Les workflows se périment, silencieusement. SkySpark 4.0 a changé le format des extensions et invalidé des procédures réelles du jour au lendemain. Un workflow ne s'aperçoit pas qu'il a vieilli. D'où le version: dans le frontmatter et, mieux encore, une date de vérification explicite ainsi que le projet sur lequel il a été vérifié pour la dernière fois.
Discipline de périmètre. Un workflow qui tente de tout expliquer n'enseigne rien. Les bons font une seule chose — créer ceci, migrer cela, garder l'index à jour.
Rien de tout cela ne plaide contre l'approche. Cela plaide pour que la relecture, le datage et la revérification en fassent partie dès le départ, plutôt que d'être greffés une fois arrivés à deux cents fichiers.
Venez construire le catalogue
Les deux serveurs sont à sources ouvertes, et les répertoires de workflows sont le point de départ le plus simple qui soit :
- FantomMcpServer —
workflows/, 13 fichiers, construction et maintenance - AxonMcpServer —
workflows/, 10 fichiers, analytique et exploitation
Les manques ne sont pas subtils. Il n'existe aucun workflow pour les conventions de nommage des points BACnet, aucun pour la mise en service d'une séquence de centrale frigorifique, aucun pour la demi-douzaine de décisions de tagging Haystack que chaque projet remet en débat.
Si vous connaissez l'une de ces procédures — que vous la connaissez vraiment, y compris là où elle dérape — c'est un workflow, et pour l'instant personne ne l'a couché par écrit.
Apportez-la sur le forum, où les groupes de travail se coordonnent, ou ouvrez une pull request sur l'un ou l'autre dépôt. Le fichier markdown est un seuil volontairement bas.
Pour en savoir plus sur le fonctionnement de ces serveurs : Axon MCP Server · l'intelligence de code multi-langage · la flotte Sidecar et le RLM.