Manuel de référence
Ce que l'outil fait, ce qu'il sait affirmer, et ce qu'il permet de surveiller en continu sur les caisses Simphony du parc.
Écrit à partir du code tel qu'il est — pas de la feuille de route. Chaque limite annoncée ici est une limite constatée.
Application web · la station d'automatisation, sans accès sortant
Chaque campagne arrive en brief Excel daté et versionné. Quelqu'un le saisit ensuite à la main dans EMC : les produits, les PLU, les prix, les compositions — sur 26 restaurants et 9 kits. Cette saisie rate des choses, et on s'en aperçoit tard, en test kiosque, quand corriger coûte le plus cher.
« L'item du menu 101000004 n'est présent ni sur le bridge ni dans les fichiers POS » (LTO Summer). « Souci avec le kit ciné d'un restaurant : la taxe soda n'est pas présente. » Ces deux phrases sont le problème, mot pour mot.
Studio déplace la détection au moment de la saisie. Il remplace la saisie manuelle, relit le résultat en secondes, et publie ce qui doit être testé en aval. Depuis, il a débordé de son périmètre d'origine : c'est devenu la console de lecture du parc — la seule vue qui compare 27 restaurants entre eux, confronte la caisse aux classeurs métier, et suit une commande au-delà de la fenêtre où l'API la montre.
Ce que Studio instrumente du programme
Les principes d'architecture ont été posés le 30 juillet : EMC est la source maître, maximiser les API, et « ne pas passer 4 h à saisir 1000 articles le matin à 6 h pour une campagne qui commence à 10 h ».
Le premier principe est le fondement de l'Auditor. Le troisième est, mot pour mot, ce que le Feeder résout. Studio n'est pas un outil à côté du programme : il en instrumente deux principes.
Quatre mécanismes portent tout le reste. Les comprendre évite les trois quarts des questions sur le fonctionnement des écrans.
Les profils clients
Sur quel restaurant, et sur quelle API, cet écran travaille-t-il ?
Un profil désigne une organisation, un restaurant (locRef) et un canal
de vente (rvcRef), avec les identifiants des deux API et le mode
d'exécution. Tous les écrans travaillent sur le profil actif — le changer change ce
qu'on regarde, jamais ce que l'outil sait faire.
Deux API Oracle, à ne jamais confondre
STS Gen 2 lit. CCAPI écrit.
STS Gen 2 est l'API transactionnelle : elle décrit les menus et les chèques, en GET pour l'essentiel. CCAPI est l'API de configuration : tout y est en POST, y compris les lectures. Les deux s'authentifient contre le même serveur d'identité, chacune avec son compte — d'où un flux OIDC partagé, écrit une seule fois.
/checks, en
query string pour /discounts, /menus, /tenders,
/taxes, /employees — qui rejettent les en-têtes en 400.
Studio pose les deux formes quand c'est possible.Le mode simulé
Peut-on préparer une campagne et former quelqu'un sans Internet ?
Studio embarque une Simphony en mémoire — restaurants, kits, articles, prix, groupes d'effectivité. Le cycle complet s'y joue sans aucun accès Oracle : import Excel, simulation, écriture, audit, Ledger, annulation. C'est ce qui rend l'outil utilisable sur une station sans accès sortant, et démontrable n'importe où.
Le verrou d'écriture
Qu'est-ce qui empêche un clic malheureux d'atteindre la caisse ?
En réel, la lecture est libre et toute écriture exige mot de passe + code
TOTP. Le verrou ne vit pas dans l'interface — il vit au point de passage des
appels, là où on ne peut pas le contourner. Session de 10 minutes, qui ne survit pas
à un redémarrage. Un refus rend un 423, pas un 500 : on distingue « c'est
verrouillé » de « c'est cassé ».
Le défaut est sûr : tant que personne n'a lancé la configuration du verrou, aucune écriture n'est possible. L'outil s'installe donc en lecture seule.
Un seul écran de Studio écrit dans Simphony. C'est aussi celui qui a demandé le plus de précautions, parce qu'une écriture ratée se paie directement en caisse.
Feeder
Écrire la campagne dans la caisse, sans perdre la possibilité de revenir en arrière.
Le Feeder lit le classeur, résout le périmètre, et écrit dans l'ordre imposé par les dépendances Simphony : Master → Definition → Prix. Chaque opération est journalisée au fil de l'eau, et le run produit un manifeste.
Le rollback se prépare avant d'écrire, et c'est la décision de conception qui porte tout le reste. Annuler une création ne demande que les identifiants rendus ; annuler une modification exige l'état d'avant, qu'on ne peut plus reconstituer après coup. D'où un snapshot systématique en tête de feed, avant la moindre écriture.
Deux niveaux d'annulation. La désactivation, par défaut, ferme simplement la fenêtre d'effectivité : la campagne cesse d'être active, rien n'est détruit. Le rollback, en escalade, rejoue les inverses du manifeste dans l'ordre strictement inverse — et refuse d'écraser une modification faite en dehors de l'outil : il s'arrête et demande confirmation.
the Ledger
Qu'est-ce que les tests aval doivent considérer comme vrai ?
Le Ledger est le JSON produit par l'Auditor : une projection de la campagne par kit et par restaurant. C'est lui que Cornac Driver consomme pour savoir quoi vérifier sur la borne, et il est destiné à l'être par les chantiers Deliverect et ComoSense.
Il est hybride, et il le dit. Chaque entrée porte sa
source : simphony pour ce qui a été relu en base (PLU, prix,
compositions, taxes) — fiable par construction ; brief pour ce qui vient
de la saisie (catégories, ordre, layout, visuels) — que Simphony ignore.
Un écart sur une valeur relue est un défaut de configuration ; un écart sur une
attente saisie peut aussi être une erreur de saisie. Les deux ne se diagnostiquent
pas pareil.
Ce que le Feeder n'écrit pas
Un brief se répartit sur deux systèmes. Le contrôle est complet des deux côtés ; l'écriture ne l'est que d'un seul, faute d'API Acrelec.
Neuf écrans, tous en lecture seule, qui posent chacun une question différente sur le même parc. Ils ne se recouvrent pas : la carte tient-elle debout toute seule, les restaurants se ressemblent-ils, la caisse correspond-elle à ce que le métier a écrit, et les produits partent-ils sur les bons écrans.
Le principe qui vaut pour tous
Ces écrans disent ce qui diffère, jamais ce qui est faux. Une remise locale a parfaitement le droit d'exister — une remise « festival » dans une ville qui en accueille un renvoie sans doute à celui-ci. Seule l'enseigne peut trancher entre l'intention et l'oubli. Appeler « anomalie » ce qui n'est qu'un écart ferait perdre la confiance dans l'outil au premier faux positif.
Des défauts qu'aucune comparaison entre restaurants ne peut voir, puisqu'ils sont identiques partout.
Intégrité de la carte
La carte tient-elle debout toute seule ?
Quatre constats, chacun avec sa conséquence pour l'exploitation. Une formule pointant vers un article absent et une règle de condiment sans groupe sont critiques : la formule ne peut pas être composée, le choix ne peut pas s'afficher. Un article sans famille valide et un article mort — ni affiché, ni vendable, ni appelé par une formule — relèvent de l'attention.
Ces défauts viennent de la configuration entreprise et survivent aux campagnes : le reliquat d'une opération retirée dont on a effacé le produit sans effacer ce qui pointait dessus. Le regroupement se fait par constat, pas par restaurant — un défaut présent dans 29 restaurants est une ligne, pas vingt-neuf.
Routage cuisine
Quelle famille de produits part sur quel écran de production ?
Une commande finit sur des écrans — Assembly, Expo, KDS — et c'est cette étape qui
décide si le client est servi. Rien ne la vérifiait. Simphony la décrit pourtant : la
configuration d'une location porte LP_OrderDeviceMapping, un XML qui
associe chaque order device à des familles. Croisé avec la carte, on sait pour
chaque article quel écran est censé l'annoncer.
Une campagne est conçue une fois et déployée partout — mais elle s'appuie sur des remises saisies restaurant par restaurant.
Cohérence du parc
Qu'est-ce qui diverge d'un restaurant à l'autre ?
Huit axes comparables, rangés en deux familles parce qu'on ne les regarde pas au même moment. Les promotions se vérifient avant une campagne — remises, moyens de paiement, frais de service. La carte se vérifie en continu — présence et prix des 756 articles, placement à l'écran, classes de taxe, articles indisponibles (le « 86 »).
La référence est la configuration la plus répandue du parc : un repère commode, pas une autorité — et c'est dit tel quel à l'écran. Trois gravités, et le rouge repose sur un fait, pas sur une ressemblance de mots : le montant diffère, ou l'élément manque là où il est presque partout.
Aligner un restaurant
Ce restaurant-ci doit ressembler à celui-là — qu'est-ce qui manque, et qui peut le combler ?
La question qu'on se pose à l'ouverture d'un restaurant, ou quand un site a dérivé. Là où « Cohérence du parc » compare tout le monde à tout le monde, cet écran désigne un modèle et liste l'écart.
Chaque écart dit qui peut le combler, et c'est tout l'intérêt du
document produit : api quand le CCAPI sait l'écrire (carte, placement,
taxes — le domaine du Feeder), emc quand aucun chemin d'écriture n'existe
(remises, moyens de paiement, frais de service), exploitation quand ce
n'est pas de la configuration — une indisponibilité se pose et se lève au poste de
caisse, la recopier n'aurait aucun sens. Sans cette colonne on rend une liste ; avec
elle, on rend un plan de travail.
Empreintes de configuration
Quels restaurants sont montés à l'identique — et qu'est-ce que celui-là a que les autres n'ont pas ?
Les autres écrans comparent la carte. Celui-ci compare le matériel : caisses, bornes, TPE, imprimantes, écrans de production, affichages client.
/workstations, /printers et
/orderDevices répondent 404, vérifié le 18 août. La seule description du
parc matériel est le plan d'adressage, un classeur tenu à la main. On le prend donc
pour ce qu'il est : ce que le parc est censé être. Le plan déclare, l'API
constate, et les deux ne se recoupent que sur les canaux de vente.Deux classeurs pilotent la carte de l'enseigne, et personne ne les avait posés en face de Simphony.
Conformité au référentiel carte
La caisse sert-elle ce que le métier a écrit ?
Deux classeurs, deux rôles. « Référentiel carte » porte l'état cible permanent : 498 articles, leur statut, leurs codes Oracle, quatre niveaux de prix, les allergènes. « Items à créer » porte le plan de charge par vague : une feuille par mois, une colonne par offre.
Les fichiers ne sont pas reconnus au nom — « Référentiel carte (3).xlsx » et « Copie de Référentiel carte.xlsx » désignent la même chose, et exiger un nom exact ferait échouer le premier téléchargement venu. Ils sont reconnus à leur structure : pardonner la forme, être intraitable sur le fond.
Auditor
La base correspond-elle au brief qu'on vient de pousser ?
L'Auditor relit Simphony et compare au modèle canonique de la campagne, en rendant des écarts typés plutôt qu'une différence brute. C'est lui qui produit le Ledger. Excel et CCAPI n'étant que des adaptateurs autour d'un objet unique, ce qu'on pousse, ce qu'on vérifie et ce qu'on teste sont garantis être la même chose.
Conformité campagne
Les règles écrites pour Cornac Driver sont-elles effectives en caisse ?
Confronte les règles de campagne — écrites à la main dans les fichiers
rules/*.md du dépôt Driver — à ce que l'API sert réellement. Couvre ce
qui est vérifiable par la donnée : retraits, ajouts, prix, plus une sentinelle prix
systématique. Les ordres, grilles, parcours et visuels restent à Driver, et sont
listés tels quels dans le résultat plutôt que passés sous silence.
Sites & rapprochement du plan d'adressage
Les deux registres qui décrivent le parc parlent-ils du même parc ?
La page Sites porte les 42 sites du plan d'adressage et l'environnement de recette, avec leurs machines et leurs IP — 1 149 équipements classés par rôle. C'est irréductiblement du hors-API : Oracle ne porte ni IP, ni caisses, ni écrans cuisine.
Le rapprochement confronte ce plan aux locations telles que Simphony
les connaît. Tant qu'on ne les compare pas, chacun paraît complet. Ce qu'il a révélé
n'est pas anecdotique : trois restaurants portent un code différent d'un registre à
l'autre — 077081 au plan, 177081 chez Simphony — et un nom
qui n'a rien à voir, « Centre Commercial Nord » d'un côté, « CCNORD » de l'autre. Rien ne
permettait de savoir qu'il s'agissait du même restaurant.
Le cœur du sujet pour les tests de bout en bout : une commande est passée — que devient-elle ? Trois écrans y répondent, chacun à un moment différent du cycle.
Retrouver une commande
J'ai un numéro sur un ticket. Où est cette commande, dans quel état, et que contient-elle ?
Recherche par numéro court, par identifiant posé par la borne (Order ID
dans les lignes d'information) ou par GUID. L'API n'exposant aucune recherche —
GET /checks exige de savoir dans quel restaurant chercher, ce qui est
précisément la question — Studio balaye les canaux de vente, en
commençant par celui où la commande a le plus de chances d'être. Export PDF par
restaurant.
GET /checks
ne rend que les commandes ouvertes — une commande payée et clôturée n'y figure
plus. Et les numéros se répètent d'un restaurant à l'autre : chercher « 3673 »
sans préciser le restaurant peut rendre plusieurs commandes sans rapport. Studio les
rend toutes plutôt que d'en élire une.Vérification de dispatch
Le scénario joué sur la borne a-t-il produit la bonne commande, et part-elle vers les bons écrans ?
Cornac Driver pilote la borne, capte le numéro de commande en fin de parcours, et s'arrête là. Cet appel est la suite : il retrouve la commande côté caisse, lit ce qu'elle porte réellement, et dit vers quels écrans de production elle doit partir.
Il rend un verdict, pas un tas de JSON : un booléen assertable, des écarts en phrases lisibles, et le détail pour qui veut creuser. Driver assert sur le booléen et recopie les écarts dans son rapport.
Suivi de bout en bout
Où en est le run Driver, et qu'est-il arrivé côté caisse ?
Le run à gauche, la commande Simphony à droite — on lit dans l'ordre où les choses arrivent : la borne agit, Simphony enregistre. La colonne vertébrale est le run, pas la commande : c'est lui qu'on déclenche, les commandes en sont le produit.
STS Gen 2 est une API transactionnelle : elle montre ce qui est ouvert maintenant, elle n'archive rien. Deux écrans en tirent la conséquence — si on veut de l'historique, il faut l'enregistrer soi-même, et chaque jour où personne n'enregistre est perdu définitivement.
Veille sur les commandes
Que devient une commande après l'encaissement, quand l'API cesse de la montrer ?
Passé l'encaissement, une commande devient introuvable : ni par son numéro, ni par l'Order ID de la borne. On perd donc exactement ce qui nous intéresse.
La clé est le checkRef : GET /checks/{checkRef}
répond, lui, après clôture. C'est la seule prise durable sur une commande — mais il ne
s'imprime nulle part et la borne ne le connaît pas. Le seul moyen de l'obtenir est de
le lire pendant que la commande est encore ouverte. La veille relève donc
périodiquement les commandes ouvertes, capte chaque checkRef à sa
naissance, et continue de suivre chacune après sa disparition de la liste. On
obtient la vie complète d'une commande — ouverture, envoi en cuisine, encaissement,
clôture — là où on n'avait qu'un instantané.
503 User is not available quand on la presse trop.Enregistreur d'activité
Quand les commandes arrivent, heure par heure — pour pouvoir un jour les prévoir.
Prévoir la pression d'un restaurant heure par heure demande des mois d'historique
horaire. Adoria n'en a pas : son champ de date est documenté « Sale's day », c'est un
jour. Simphony a l'heure — chaque check porte son openTime — mais
n'archive rien. L'historique horaire ne se retrouve pas, il se
constitue. C'est la seule pièce du chantier prévision dont le coût augmente
avec l'attente, d'où cet enregistreur, écrit avant le modèle qui s'en servira.
Ce n'est pas la veille : un appel par cible et par tour, une ligne par commande découverte, et rien de plus. Le reste du cycle de vie n'apprend rien sur la pression.
API history & Workbench
Qu'a-t-on appelé, qu'a répondu l'API, et comment le rejouer ?
Le Workbench expose les 33 endpoints STS Gen 2 du catalogue —
Checks, Configuration, Organization, Notifications, Employees — avec un formulaire
généré pour chacun. L'API history journalise chaque appel : durée,
statut, corps, avec rejeu à l'identique. Les en-têtes sensibles
(Authorization, Cookie, X-Api-Key) y sont
masqués.
Adoria — stocks et disponibilité datée
Depuis quand cet article est-il indisponible, et y a-t-il du stock ?
Adoria est la troisième API du projet, et la première qui ne soit pas Oracle. Elle sait deux choses que Simphony ignore : ce qu'il y a physiquement en stock, et depuis quand un article est censé être hors vente.
C'est la seconde qui compte. Le /menus/items/unavailable de STS Gen 2
rend un ensemble booléen — ni date, ni motif, ni auteur — ce qui rend les 268 articles indisponibles d'un restaurant impossibles à trier entre « retiré il y a six mois » et
« tombé ce midi ». Adoria rend des périodes datées. Croiser les deux,
c'est dater le « 86 » sans ouvrir le DataStore du CAPS.
Le mot « test » recouvre trois choses différentes dans ce projet, et les confondre mène à des malentendus. Studio exécute des contrôles sur la configuration ; il alimente des tests joués ailleurs, sur la borne ; et il est lui-même couvert par une suite de tests logiciels.
Chaque contrôle est reproductible, sans écriture, et rend un verdict daté.
| Contrôle | Ce qu'il affirme | Source | Verdict rendu |
|---|---|---|---|
| Écart au brief | Chaque produit, prix, composition et taxe du brief existe en base tel qu'écrit | CCAPI + brief Excel | Écarts typés |
| Conformité au référentiel | La carte servie correspond au référentiel permanent et au plan de charge de la vague | 2 classeurs + STS | Divergence article par article |
| Conformité campagne | Les retraits, ajouts et prix d'une règle Driver sont effectifs en caisse | rules/*.md + STS | Conforme / non conforme / hors portée |
| Intégrité de la carte | Aucune formule ne pointe vers un article absent, aucune règle de condiment n'est orpheline, aucun article n'est mort | STS | Critique / attention |
| Cohérence du parc | Sur 8 axes, ce restaurant est aligné sur la configuration la plus répandue | STS · 1 appel/restaurant | Aligné / libellé / divergent |
| Alignement dirigé | Ce qui sépare un restaurant d'un modèle désigné, et qui peut le combler | STS | Écart + responsable (api / emc / exploitation) |
| Routage cuisine | Chaque famille non-formule a un écran de production déclaré | STS · LP_OrderDeviceMapping | Routée / formule / sans écran |
| Empreintes matériel | Quels restaurants sont montés à l'identique, et ce que celui-là a de plus | Plan d'adressage | Déclaré (non constaté) |
| Rapprochement des registres | Chaque site du plan correspond à une location Simphony | Plan + STS | Exact / déduit / orphelin |
| Vérification de dispatch | La commande produite par un scénario est celle attendue et part vers les bons écrans | STS | Booléen + écarts en phrases |
| Adoria ↔ caisse | L'indisponibilité déclarée en caisse a une période datée côté Adoria | Adoria + STS | Datée / non expliquée |
Studio ne touche pas la borne. Il dit à ce qui la touche quoi vérifier.
Cornac Driver
Le parcours sur la borne, joué par un automate.
Driver pilote les bornes Acrelec en CDP/DOM et vérifie ce que Studio ne peut pas voir depuis l'API : l'ordre des catégories, les grilles, le parcours, les visuels de tuiles. Il consomme the Ledger pour savoir quoi attendre, et appelle la vérification de dispatch pour asserter sur ce que la commande est devenue en caisse.
271 tests, 8 suites, exécutés en 4,7 secondes — et la livraison en dépend.
Ce que la suite couvre en priorité
Les deux endroits où une erreur se paie directement en caisse : le
mapping Excel → payloads CCAPI, et l'allocation des objectNum. Plus les
quatre situations où l'on perd des données : feed interrompu, rollback rejoué,
modification concurrente, étage de la chaîne de dépendances en échec.
S'y ajoutent le verrou d'écriture, l'authentification STS et le placement des identifiants, le journal d'activité, le rapprochement Adoria, l'export PDF et la lecture du plan d'adressage.
Le script de livraison refuse de produire un paquet si les tests échouent, et depuis août il refuse aussi un paquet dont une dépendance manquerait : il relève les imports du serveur et vérifie que chacun est bien embarqué. La prochaine dépendance oubliée arrêtera la construction sur le poste de développement, au lieu de tuer le serveur sur une station sans Internet.
Ce que Studio permet de surveiller en continu, sans écrire une ligne dans la caisse, et sans être sur le réseau du restaurant.
| Ce qu'on surveille | Comment | Ce que ça donne |
|---|---|---|
| Le cycle de vie complet d'une commande | Veille — capture du checkRef à la naissance |
Ouverture, envoi cuisine, encaissement, clôture — y compris après disparition de la liste |
| La pression horaire, jour après jour | Enregistreur d'activité, présence journalisée | La série temporelle qui n'existe nulle part ailleurs, et qui rend la prévision possible |
| Les commandes qui ne se ferment jamais | Commandes ouvertes + export PDF par restaurant | Les checks anormalement anciens, restaurant par restaurant |
| La dérive de configuration du parc | Cohérence du parc, rejouée périodiquement | Ce qui a divergé depuis le dernier passage, sur 8 axes |
| Les indisponibilités et leur ancienneté | Croisement Adoria ↔ « 86 » Simphony | Un « 86 » daté, distinguant l'incident du jour du retrait ancien |
| La santé des API et leur latence | API history — durée, statut, corps, rejeu | Les échecs, les lenteurs, et le 503 quand on presse trop l'API |
| L'état de l'automate de test | Suivi de bout en bout — statut de l'agent Driver | Le run en cours et son effet côté caisse, dans la même vue |
| Toute écriture faite dans la caisse | Journal des opérations, en ajout seul | Qui a écrit quoi, quand — et la matière du rollback |
La limite est structurelle, pas outillée
STS Gen 2 est une API transactionnelle : elle décrit la transaction, pas sa matérialisation physique. On observe donc très bien ce que la commande contient et ce qu'elle devient en caisse, et rien de ce qui se passe ensuite dans le restaurant. Ce n'est pas un défaut de Studio, et aucun développement dans Studio ne le lèvera.
Maillon par maillon, ce qui est observable aujourd'hui et ce qui ne l'est pas. Cette liste vaut autant que la précédente : elle dit où ne pas promettre de couverture.
| Maillon | État | Ce qui manque, et à qui le demander |
|---|---|---|
| Écran de saisie borne | Couvert | Par Cornac Driver, en CDP/DOM. Canal borne uniquement. |
| Contenu de la commande | Couvert | Formules, remises, moyens de paiement, TVA — tous canaux, par STS. |
| Trace du code promo Como | Non prouvé | L'extension COMO_DATA du check n'était renseignée sur aucune des 122 commandes examinées — mais aucune n'avait utilisé de code promo. On observe l'absence du cas, pas un mécanisme qui échoue. Le test contrôlé qui tranche est prêt et n'a pas été lancé. |
| Ticket client | Vide | GET /checks/{checkRef}/printed répond 200 avec six lignes de blancs, alors que le check porte une extension d'impression. À éclaircir avec Oracle — peu coûteux, et ça débloquerait un plan de vérification entier. |
| Ticket cuisine | Non observé | Aucun endpoint. Le routage attendu est connu (écran « Routage cuisine ») ; l'impression réelle ne l'est pas. |
| Écrans KDS | Non observé | Ce n'est pas un trou d'accès : six écrans de production de l'environnement de recette sont en ligne sur le même VPN que la station. Ce qui manque est une méthode de lecture programmatique. La question à poser n'est plus « ouvrez-nous le KDS » mais « comment lit-on l'état d'un écran KDS Simphony sans le regarder ». |
| Poste de caisse (comptoir) | Non observé | Interroger STS ne suffit pas pour une commande saisie au comptoir : il faudrait écouter le poste. Ouvert chez Oracle. Les deux postes de recette sont en ligne et joignables — là aussi, la question est peut-être « que lit-on » plutôt que « peut-on y accéder ». |
| Middleware livraison | Non raccordé | La documentation Deliverect est publiée. Restent sandbox et identifiants, canaux en périmètre, mapping menu ↔ PLU. À noter : Deliveroo, UberEats et Click&Collect existent déjà comme moyens de paiement en caisse — c'est là qu'une commande marketplace se solde. |
| Notifications Simphony | Non exploitable | Un type CheckNotification est annoncé, mais s'y abonner exige de s'enregistrer comme intégrateur — une écriture — et de fournir une URL que Oracle puisse joindre. Un poste de travail n'est pas exposé sur Internet. /notifications/subscriptions répondait 404 au dernier essai. |
Sur la station d'automatisation
Une station d'automatisation, sans accès sortant.
Un script compile, refuse de livrer si les tests échouent, embarque toutes les
dépendances et dépose une archive sur OneDrive. Sur la station : extraire dans
C:\Automation\, double-clic sur studio.bat.
Pas de npm install sur la station, pas d'Internet requis
là-bas — c'est une contrainte tenue, pas une commodité : c'est elle qui
explique que le code TOTP soit calculé à la main plutôt que tiré d'une bibliothèque.
En développement
Deux processus, un port chacun.
Le client sur :5174, le serveur sur :8787. En production
sur la station il n'y a qu'un processus : le client est compilé et servi en statique
par le serveur.
127.0.0.1.Deux comportements qui ressemblent à des pannes et n'en sont pas
Ce qui reste ouvert
Cornac Studio — documentation au 24 août 2026
Feeder · Auditor · the Ledger, et les quatorze écrans de lecture du parc
Suite Cornac : Studio (configuration, parc, commandes) · Driver (bornes Acrelec)