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 enregistrement.
Une règle Spark fonctionnelle en exige deux : un enregistrement func contenant la logique de détection, et un enregistrement sparkRule configurant comment et où la règle s'applique. Les deux doivent concorder. Oubliez le second et rien ne signale d'erreur — vous avez simplement une règle qui ne se déclenche jamais, sur un site que vous croyiez surveillé.
Aucune quantité de connaissance syntaxique n'évite cela. Ce n'est pas un problème de langage. C'est un problème de procédure, et la procédure est précisément 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 embarque 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: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Les deux serveurs MCP chargent au démarrage chaque .md de leur dossier workflows/ et les exposent via le Model Context Protocol comme des ressources lisibles sous une URI workflow://. Il n'est pas nécessaire de dire à l'assistant qu'elles existent — il peut les lister, les rechercher et en récupérer le texte intégral à la demande, en pleine tâche.
Fantom MCP Server surveille ce dossier. Déposez-y un nouveau fichier et il devient disponible sans recompilation ni redémarrage.
Les deux catalogues actuels
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 dont dépend toute la boucle tient en une phrase : après chaque modification de code, appelez reindexChangedFiles sur les chemins que vous avez touchés. Réanalyser, reconstruire les nœuds et les arêtes du graphe, recalculer 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 dès qu'on vous la dit et invisible tant que personne ne le fait.
Ce fichier contient aussi une ligne qui mérite d'être copiée : « Vérifié en conditions réelles le 10/06/2026 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, ce n'est qu'une rumeur.
Pourquoi c'est là que se situe le goulot d'étranglement
L'intuition voudrait que de meilleurs modèles comblent cet écart. Ils ne le font pas, et il vaut la peine d'être précis sur le pourquoi.
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 du bâtiment n'a jamais été consigné sous une forme exécutable par quoi que ce soit. Il vit dans la tête de quelques milliers de praticiens à travers le monde, et il se transmet par compagnonnage : vous apprenez qu'une règle Spark nécessite deux enregistrements 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 il ne survit pas aux changements d'emploi. 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, exécuté ensuite par chaque assistant sur chaque projet.
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 pour la plupart 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 là où il est.
Ce n'est pas le cas. Un workflow, c'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 de l'affaire nous est absurdement favorable. Un workflow prend un après-midi à écrire. 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 du bâtiment n'est pas le développement web ; aucune armée de contributeurs ne va débarquer. Si les personnes qui connaissent Sedona, Haxall, Axon et Xeto gardent chacune leurs procédures pour elles, 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 réussi à produire. Deux cents, relus et datés, changeraient ce qu'un nouveau venu peut accomplir dès sa première semaine.
Les risques, honnêtement
Un catalogue de workflows n'est pas bon par nature, et prétendre le contraire reviendrait à le condamner à l'échec.
Un mauvais workflow est pire que pas de workflow du tout. Un assistant le suit avec assurance et produit un résultat faux avec assurance. L'absence de procédure produit au moins de l'hésitation ; une mauvaise procédure produit une mauvaise mise en service. La relecture compte ici plus que pour la plupart des documentations.
Les workflows se périment, silencieusement. SkySpark 4.0 a changé le format d'extension et invalidé du jour au lendemain des procédures bien réelles. 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é contrôlé pour la dernière fois.
La 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.
Aucun de ces points ne plaide contre l'approche. Ils plaident pour que la relecture, le datage et la re-vé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 à source ouverte, et les dossiers de workflows constituent 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 mis par écrit.
Apportez-le sur le forum, où les groupes de travail se coordonnent, ou ouvrez une pull request sur l'un ou l'autre dépôt. Un fichier markdown, c'est un seuil bas — et c'est voulu.
Pour en savoir plus sur le fonctionnement de ces serveurs : Axon MCP Server · intelligence de code multilangage · la flotte Sidecar et le RLM.