Du binaire vérifié à votre première opération contrôlée.

1. Télécharger et installer

Choisissez le binaire correspondant au système et à l’architecture de la machine cible. Vérifiez son empreinte SHA-256 sur la page Téléchargements, puis placez-le dans un dossier durable.

Expand-Archive -LiteralPath '.\helixflow-windows-amd64.exe.zip' -DestinationPath '.'

Vérifier l’intégrité du fichier

Dans le dossier de téléchargement, calculez l’empreinte et comparez-la à la valeur de la page Téléchargements.

Get-FileHash .\helixflow-windows-amd64.exe -Algorithm SHA256

Utiliser un emplacement durable

Depuis le dossier du binaire extrait, exécutez ces commandes dans un terminal sous votre compte utilisateur. Elles installent HelixFlow et définissent les mêmes dossiers pour le terminal, Claude et Codex. Gardez cette session ouverte pour les étapes suivantes. Dans les chemins illustratifs, remplacez « you » par votre nom de compte : C:\Users\you\HelixFlow\helixflow-windows-amd64.exe

.\helixflow-windows-amd64.exe version

2. Activer la licence machine

Générez request.json avec la version actuelle, sur la machine qui exécutera HelixFlow. La demande reste un fichier JSON ; la licence reçue est un fichier .lic au format HFL1. Une démo dure 7 jours (168 heures) ; une licence à vie n’expire pas. Toutes deux sont liées à la machine.

.\helixflow-windows-amd64.exe license request --output request.json

La demande identifie la machine pour la licence. Contrôlez son transfert et ne la publiez pas.

Vous avez une ancienne licence JSON ? Conservez l’ancien binaire et demandez une réémission à l’éditeur avec une nouvelle demande générée par le client actuel. Renommer le fichier ne le convertit pas. Une migration ne redémarre pas une période de démonstration. Contact

Téléchargez helixflow.lic depuis votre compte après émission (la licence à vie nécessite l’approbation de l’éditeur). Placez-le dans le dossier courant du terminal, puis importez-le et vérifiez-le :

.\helixflow-windows-amd64.exe license import helixflow.lic
.\helixflow-windows-amd64.exe license status

3. Configurer un profil

Un profil est un petit fichier texte YAML : il indique à HelixFlow quel serveur SecureTransport (ST) contacter et comment s’identifier. Vous le créez sur votre poste. Le portail ne reçoit ni ce fichier ni vos identifiants ST.

Avant de commencer : demander les informations ST

SecureTransport est le serveur qui gère les comptes et les transferts de fichiers de votre organisation. Ces exemples concernent son accès administrateur.

1. Demandez l’adresse HTTPS et le port de l’administration ST, par exemple https://st01.example.test:8444. 8444 est un exemple : le port réel peut être différent. Dans base_url, ne mettez ni /api/v2.0 ni le chemin d’une page Web.
2. Demandez un compte administrateur ST et les droits nécessaires à vos lectures. Le compte du portail HelixFlow et un compte ST destiné au transfert de fichiers ne remplacent pas ce compte administrateur.
3. Vérifiez avec l’équipe ST que votre poste peut joindre cette adresse (réseau interne ou VPN), puis testez le compte dans la console Web ST. Demandez à l’équipe de traiter un mot de passe expiré ou un compte verrouillé.

Certificat serveur : « Est-ce bien le serveur ST attendu ? »

Le bloc tls vérifie le serveur : system utilise les autorités reconnues par votre système ; ca utilise le fichier d’autorité fourni par votre équipe ; insecure désactive cette vérification.

Certificat client : « Qui se connecte à ST ? »

Le bloc client_auth présente votre certificat à ST et utilise sa clé privée sur votre poste pour prouver votre identité. Cette connexion s’appelle mTLS. La clé privée n’est jamais envoyée au serveur ; seul le certificat public peut être partagé.

Choisissez l’une des deux méthodes ci-dessous : A. Se connecter avec un identifiant et un mot de passe · B. Se connecter avec un certificat client

Choisir une racine de configuration explicite

Si vous avez ouvert un nouveau terminal, rétablissez ces quatre variables avant toute commande de licence ou de connexion MCP. Les dossiers restent sous votre dossier utilisateur, y compris avec Codex sous Windows : C:\Users\you\HelixFlow\config

$env:HELIXFLOW_CONFIG_DIR = 'C:\Users\you\HelixFlow\config'

Créez le dossier profiles, puis le fichier C:\Users\you\HelixFlow\config\profiles\validation.yaml

Ouvrez un éditeur de texte, collez un seul exemple complet et enregistrez-le sous validation.yaml, pas validation.yaml.txt. Conservez les espaces d’indentation, sans tabulation. Les exemples sont des alternatives : remplacez le contenu du fichier au lieu de les assembler.

A. Se connecter avec un identifiant et un mot de passe

Utilisez votre identifiant administrateur ST et son mot de passe. Le YAML indique seulement où HelixFlow les trouvera : aucun champ login ou password ne doit y contenir leur valeur.

Exemple avec vérification du serveur

base_url: https://st01.example.test:8444
env_class: test
tls:
  mode: system
credentials:
  source: env

Remplacez l’adresse d’exemple. env_class décrit la vraie cible : test pour un laboratoire, preprod pour la préproduction, prod pour la production. Ne déclarez jamais une production comme test. validation est le nom du fichier sans .yaml.

Exemple de laboratoire avec tls.mode: insecure

Si votre laboratoire utilise un certificat serveur auto-signé non reconnu, cet exemple permet un premier essai. HTTPS chiffre toujours la connexion, mais HelixFlow ne vérifie plus l’identité du serveur : un faux serveur pourrait récupérer vos identifiants.

base_url: https://st01.example.test:8444
env_class: test
tls:
  mode: insecure
credentials:
  source: env

Réservez insecure à un laboratoire isolé. Pour un usage normal, choisissez system ou reprenez le bloc tls de l’exemple certificat ci-dessous (mode: ca et chemin absolu vers server-ca.pem). Obtenez ce certificat d’autorité auprès de l’équipe ST. Un login/mot de passe n’impose pas le mode insecure.

$stCredentials = Get-Credential -Message 'SecureTransport credentials for validation'
$env:HELIXFLOW_LOGIN = $stCredentials.UserName
$env:HELIXFLOW_PASSWORD = $stCredentials.GetNetworkCredential().Password
Remove-Variable stCredentials

keyring set helixflow/validation login
keyring set helixflow/validation password

printf 'ST login: '; IFS= read -r HELIXFLOW_LOGIN
printf 'ST password: '; IFS= read -rs HELIXFLOW_PASSWORD; printf '\n'
export HELIXFLOW_LOGIN HELIXFLOW_PASSWORD

Ne collez jamais les identifiants SecureTransport dans ce site, un fichier de configuration MCP ou une conversation avec l’assistant.

B. Se connecter avec un certificat client

Cette méthode remplace le mot de passe ST par un certificat reconnu et associé à votre administrateur ST. Préparez d’abord ST avec son équipe d’administration, puis configurez votre poste.

1. Obtenir les fichiers auprès de l’équipe ST ou PKI

La PKI est l’équipe ou le service qui délivre les certificats. Demandez un certificat X.509 d’authentification client (usage clientAuth), sa clé correspondante et les autorités de confiance. Renommer un fichier ne change pas son format.

client.pem

Votre certificat public au format PEM, suivi des certificats intermédiaires si nécessaire. Il contient votre identité et une date d’expiration.

client.key

La clé privée correspondante au format PEM non chiffré, à protéger par les droits du système. Si vous recevez un P12/PFX ou une clé PEM chiffrée, utilisez la variante P12 ci-dessous avec l’aide de l’équipe PKI.

client-issuer-ca.pem

Le certificat public de l’autorité qui a signé votre certificat client, avec les intermédiaires nécessaires. L’équipe ST s’en sert pour vous reconnaître.

server-ca.pem

L’autorité qui permet à votre poste de vérifier le certificat HTTPS du serveur ST. Elle peut être différente de celle qui a signé votre certificat client.

2. Configurer le certificat dans SecureTransport

À réaliser dans la console d’administration ST avec un administrateur habilité. Les intitulés ci-dessous sont ceux des interfaces ST classiques ; ils peuvent varier selon la version.

1. Conservez un accès administrateur de secours par mot de passe, déjà testé, et prévoyez la procédure de reprise avant toute modification.
2. Dans Setup > Certificates > Trusted CAs, importez l’autorité du certificat client et ses intermédiaires avec l’équipe ST. Importez seulement les certificats publics, jamais client.key.
3. Dans Setup > Admin Settings, activez la connexion administrateur par certificat client. Choisissez Client certificates: optional et l’acceptation des émetteurs de confiance (any trusted issuer). Enregistrez. N’imposez pas required pour ce premier essai.
4. Dans Accounts > Administrators, ouvrez l’administrateur concerné et renseignez Certificate DN avec le sujet exact de son certificat client. Le DN est l’identité complète, par exemple CN=helixflow-reader,O=Example ; ce n’est pas forcément le login. Enregistrez.
5. Faites appliquer le réglage et redémarrer le service d’administration ST par l’équipe ST selon sa procédure. Ce redémarrage peut interrompre l’accès à la console ; celui du seul service HTTP de transfert ne remplace pas cette étape.
6. Après redémarrage, vérifiez que l’accès de secours par mot de passe fonctionne encore. Testez ensuite le nouveau profil certificat avec une lecture, comme indiqué plus bas.

Pour afficher le sujet du certificat public, lancez cette commande depuis son dossier si OpenSSL est installé. Copiez la valeur après subject=, sans ce préfixe, et faites vérifier sa correspondance exacte avec Certificate DN par l’équipe ST. Sinon, demandez-lui le DN.

openssl x509 -in client.pem -noout -subject -issuer -dates -nameopt RFC2253

Cette procédure concerne l’API administrateur. Authentication > Login Settings et les Login Certificates d’un compte de transfert concernent un autre accès. Si l’administrateur utilise LDAP ou une authentification externe, faites confirmer sa compatibilité certificat/dual par l’équipe ST avant de continuer.

Références Axway : consultez « Administrator login options » et la gestion des administrateurs pour votre version. Axway SecureTransport 5.5 — Administrator Guide · Axway — LDAP (KB 71206)

3. Créer le profil et protéger la clé sur votre poste

Dans la racine de configuration choisie plus haut, créez le dossier certs et placez-y les fichiers. Remplacez « you » dans ca_path par votre nom de compte : ce chemin doit être absolu. Les chemins ../certs de client_auth partent du dossier profiles contenant validation.yaml et fonctionnent sur les trois systèmes.

config/
  profiles/
    validation.yaml
  certs/
    server-ca.pem
    client.pem
    client.key

base_url: https://st01.example.test:8444
env_class: test
tls:
  mode: ca
  ca_path: 'C:/Users/you/HelixFlow/config/certs/server-ca.pem'
client_auth:
  mode: certificate
  cert_path: ../certs/client.pem
  key_path: ../certs/client.key

Il n’y a pas de bloc credentials : c’est le mode certificat seul, sans login/mot de passe ST. Si le certificat serveur est déjà reconnu par votre système, utilisez tls.mode: system et retirez ca_path. Vérifiez que le nom de serveur de base_url figure dans son certificat.

Sous Windows, ouvrez les propriétés de client.key > Sécurité > Avancé. Avec l’aide de votre support si nécessaire, limitez l’accès à votre compte Windows ; SYSTEM et les administrateurs locaux peuvent rester autorisés. Retirez les accès des autres utilisateurs et groupes, y compris les droits hérités trop larges. HelixFlow refuse une clé insuffisamment protégée.

chmod 700 "$HELIXFLOW_CONFIG_DIR/certs"
chmod 600 "$HELIXFLOW_CONFIG_DIR/certs/client.key"

base_url: https://st01.example.test:8444
env_class: test
tls:
  mode: ca
  ca_path: 'C:/Users/you/HelixFlow/config/certs/server-ca.pem'
client_auth:
  mode: certificate
  format: pkcs12
  cert_path: ../certs/client.p12
  passphrase_entry: p12-passphrase

keyring set helixflow/validation p12-passphrase

credentials:
  source: env

4. Vérifier la connexion sans modifier ST

Connectez l’assistant à l’étape suivante, puis lancez server_info pour vérifier le MCP local. Cet appel ne teste pas ST. Demandez ensuite de lister les comptes avec le profil validation : une réponse sans erreur confirme la connexion à ST et les droits de lecture pour cet appel. Une liste vide peut simplement signifier qu’aucun compte n’est visible. 4. Connecter votre assistant · 5. Effectuer une première lecture

4. Connecter votre assistant

Les trois exemples ci-dessous utilisent le même binaire, la même licence et les mêmes dossiers. Exécutez les commandes dans la session du guide. Si securetransport existe déjà, mettez à jour son entrée existante dans votre client.

Claude Desktop

Remplacez « you » par votre nom de compte dans tous les chemins. Fusionnez cette entrée avec vos autres serveurs dans %APPDATA%\Claude\claude_desktop_config.json

Un processus Desktop lancé hors de la session PowerShell n’hérite pas de ses identifiants. Utilisez une méthode de lancement vérifiée depuis cette session ou Claude Code.

Sous Linux, utilisez Claude Code ou un autre client MCP compatible stdio.

Claude Code

Avec Claude Code installé, enregistrez le serveur pour votre compte utilisateur :

Codex

Avec la CLI Codex installée, enregistrez le même serveur. Codex utilisera explicitement le dossier de licence partagé :

Vérifiez uniquement le client que vous utilisez, puis fermez et relancez complètement Claude ou Codex pour charger sa nouvelle configuration. Dans l’assistant, appelez server_info et contrôlez la version annoncée.

Conservez les identifiants SecureTransport dans le trousseau du système ou l’environnement de processus pris en charge. Ne les collez jamais dans une conversation.

5. Effectuer une première lecture

Commencez par server_info pour vérifier la connexion MCP sans contacter SecureTransport. Demandez ensuite une lecture avec le nom exact du profil de test.

Le profil validation correspond à validation.yaml. Vérifiez sa cible avant le premier appel. Les lectures peuvent utiliser un cache de trente secondes par défaut.

6. Préparer une modification

Les modifications de flux suivent un cycle explicite. Ces noms sont des outils MCP, pas des commandes de terminal.

1. Validez le document de flux avec flow_validate.
2. Prévisualisez-le avec flow_plan et relisez la référence de plan retournée.
3. Confirmez avant que flow_apply utilise le même document et la même référence.

Un plan expire après quinze minutes par défaut. Un document modifié doit être planifié de nouveau. Sur une cible de production, suivez les exigences d’approbation renvoyées par l’outil.

Les abonnements (options, attributs de flux, abonnement sans configuration de transfert) se gèrent par les documents de flux. Pour les routes, un modèle qui exécute d’autres routes peut être mis à jour de façon ciblée : sa description, le statut d’une étape, ou une étape d’exécution de route ajoutée à la fin ; retirer une telle étape est refusé. Un export complet se relit désormais à l’identique.

Le dossier flows défini par HELIXFLOW_FLOW_DIR est la racine autorisée pour les documents flow_path et les certificats à importer via un flux. Le certificat de connexion client_auth reste dans le dossier certs décrit à l’étape 3.

7. Résoudre un problème

Le client ne trouve pas le binaire

Vérifiez le chemin absolu, le nom correspondant à l’architecture et le droit d’exécution sous macOS ou Linux. Relancez version dans un terminal.

Aucun profil n’est trouvé

Contrôlez HELIXFLOW_CONFIG_DIR et son sous-dossier profiles. Le nom demandé correspond au fichier YAML sans extension.

La connexion TLS échoue

« unknown authority » : vérifiez server-ca.pem et tls.ca_path. Un nom de serveur incorrect demande de corriger base_url ou le certificat, pas de passer en insecure. « certificate required » ou « bad certificate » : faites contrôler le certificat client, sa chaîne et les autorités acceptées par ST.

L’authentification est refusée

Une erreur 401 indique que ST refuse l’identité ; 403 peut indiquer des droits insuffisants. Avec un mot de passe, vérifiez les identifiants, le verrouillage du compte et le trousseau ou l’environnement reçu par le MCP. Avec un certificat, vérifiez Certificate DN, l’émetteur autorisé, le réglage optional et le redémarrage de l’administration. Confirmez si ST exige le mode dual.

Le fichier de certificat ou la clé est refusé

Vérifiez les chemins depuis le dossier du profil, la date de validité, la correspondance certificat/clé et les permissions. Une clé PEM chiffrée seule n’est pas prise en charge : utilisez un P12 avec son mot de passe dans le trousseau. Avec P12, vérifiez aussi l’entrée helixflow/validation → p12-passphrase.

La licence est refusée

Dans la session configurée ci-dessus, lancez license status. Vérifiez le format HFL1, la machine cible et l’expiration. HELIXFLOW_LICENSE_DIR doit être identique dans le terminal et le client MCP. Une ancienne licence JSON nécessite une réémission.