FERS dans le terminal et depuis les agents de code

1. Installer, et vérifier ce que vous avez

Un seul paquet contient les objets de modélisation, le moteur compilé et la commande. fers doctor affiche les versions et l’emplacement des exemples ; avec une clé, il demande aussi au serveur de licences si la clé est acceptée.

pip install FERS
fers doctor --offline      # versions and where the examples live
fers version

Sans clé API, le moteur travaille avec l’offre gratuite, pour un usage non commercial jusqu’à 100 barres, et ne fait aucun appel réseau. Placez une clé dans FERS_API_KEY (ou passez --api-key) pour Pro, qui couvre l’usage commercial ; le moteur la vérifie alors auprès de ferscloud.com une fois par calcul.

2. La boucle : modéliser, valider, résoudre, lire

La modélisation reste en Python, là où sont les objets et les exemples numérotés. La commande prend le relais au fichier : elle valide le JSON contre le schéma d’entrée du moteur, le lui transmet tel quel et rend compte en une ligne.

1. Modéliser en Python — Construisez le modèle avec fers_core en unités SI et enregistrez-le avec model.save_to_json("model.json"). fers examples list et fers examples show 001 sont la référence la plus rapide pour l’API objets.
2. Valider le fichier — fers validate model.json le vérifie contre le schéma d’entrée et nomme le champ fautif. fers schema --list et fers schema Member affichent le schéma quand un nom de champ fait douter.
3. Résoudre dans un fichier — fers solve model.json --out results.json écrit les résultats directement dans le fichier. La sortie standard est une ligne de résumé, ou un objet JSON avec --json.
4. Lire une sélection — Chargez le fichier résolu avec FERS.from_json et lisez le cas de charge ou la combinaison voulue, ou demandez moins au moteur dès le départ avec un ResultRequest.

python build_model.py                     # authors with fers_core and saves model.json
fers validate model.json                  # the input schema, naming the field that fails
fers solve model.json --out results.json  # the engine streams the results to the file
# solved: 3 load cases, 8 combinations in 0.4 s -> results.json (2.1 MB)

3. Les résultats restent dans des fichiers

fers solve n’analyse jamais les résultats : le moteur les écrit et la commande n’en relit que ce qu’il faut pour le résumé. Un modèle qui écrit des centaines de mégaoctets ne coûte rien au processus, ni au contexte d’un agent. Le code de sortie dit ce qui s’est passé, de sorte qu’un script ou un agent peut brancher sans lire de prose.

• 0 résolu. 4 résolu, mais le moteur a enregistré des échecs (solve_failures, load_case_failures) : lisez-les avant d’utiliser le moindre nombre.
• 1 le moteur a refusé le calcul ou celui-ci a échoué, avec son message sur stderr. 2 entrée invalide : fichier absent, JSON invalide, modèle qui ne respecte pas le schéma.
• 3 licence : pas de clé là où il en faut une, clé refusée, ou délai de la vérification de licence dépassé.
• La ligne de résumé compte les cas de charge, les combinaisons, les échecs enregistrés, les jeux de résultats non convergés, et les erreurs et avertissements du moteur.

from fers_core import FERS, ResultBlock, ResultRequest

# Before solving: ask the engine for only the blocks you will read.
model.settings.analysis_options.result_requests = [
    ResultRequest(ResultBlock.REACTIONS, limit_state="ULS"),
    ResultRequest(ResultBlock.NODE_DISPLACEMENTS, components=["dy"]),
]
model.save_to_json("model.json")

# After "fers solve model.json --out results.json":
solved = FERS.from_json("results.json")
case = solved.resultsbundle.loadcombinations["ULS 1"]
print(case.reaction_nodes["1"].nodal_forces.fy)

4. Vérifications normatives et rapports

Un modèle qui porte des définitions de vérification — check_beam dans fers_core.builders en construit un en une ligne — reçoit son verdict EN 1993-1-1 de fers check : statut, taux de travail et barre déterminante par vérification. fers report génère le rapport HTML avec calcul manuel à partir d’un document déjà résolu, sans recalculer.

fers check beam.json --out beam_solved.json
# ec3: Green, utilization 0.778, governing 1 in combination 1
fers report beam_solved.json --out report.html

5. Catalogues et schéma

Les tables de profilés (EN, British Steel, AISC) et les matériaux prédéfinis sont ceux que résolvent les objets Python, affichés en SI pour qu’une valeur puisse être confrontée à un catalogue avant d’entrer dans un modèle.

fers sections list --series HEB
fers sections get IPE200          # h, b, i_y, i_z, j, area, wel, wpl ... in m, m2, m4
fers materials list
fers materials get S355 --json
fers schema --list                # the schema's definitions, one line each
fers schema Member                # one definition in full

6. Agents de code et fichier skill

Un agent doté d’un shell — Claude Code, Codex, l’agent de Cursor, un runner CI — n’a besoin ni de serveur ni de connecteur : le paquet est le solveur. Ce qu’il lui faut, c’est la boucle ci-dessus sous une forme qu’il lit avant de commencer, et c’est le fichier skill : une page au format skill avec l’étape d’installation, la boucle, la lecture des résultats et le cas où le serveur MCP convient mieux.

Le fichier est embarqué dans le paquet, et fers skill --install . l’écrit dans .claude/skills/fers/SKILL.md, là où Claude Code le cherche ; fers skill --path en donne le chemin pour tout autre agent. Il vit aussi dans le dépôt FERS_core. Les agents qui lisent plutôt qu’appellent ont toujours llms.txt et la version Markdown de cette page sous /docs/command-line.md.

fers skill --install .     # writes .claude/skills/fers/SKILL.md, where Claude Code looks
fers skill --path          # the file's path, for any other agent
fers skill                 # or read it

7. CLI ou MCP ?

C’est l’endroit où tourne l’agent qui décide, pas le protocole meilleur dans l’absolu. Les deux voies exécutent le même moteur et renvoient les mêmes nombres.

• Un agent en terminal (Claude Code, Codex, un job CI) installe le paquet : le calcul tourne sur sa propre machine au rythme du moteur, sans limites de requêtes ni délais, les résultats restent dans des fichiers, et il modélise en Python à partir des exemples.
• Un client de bureau ou d’éditeur (Claude Desktop, Cursor, VS Code, ChatGPT pour ordinateur) utilise le serveur MCP local : il calcule sur la même machine, et un seul appel d’outil renvoie les valeurs vérifiées. Un agent en terminal peut aussi l’utiliser ; pour une vérification clé en main, il lui faut moins d’échanges qu’avec la commande.
• Une application de chat dans le navigateur ou sur un téléphone utilise le serveur MCP hébergé : il construit et valide le modèle et renvoie un lien qui le calcule dans votre navigateur.
• Les deux peuvent partager un compte : la clé API qui relève les limites de la commande est celle que le serveur MCP accepte.