Évaluation technique · ERP
Lecture d'ingénierie d'un ERP legacy : architecture, surface d'intégration, ergonomie, pérennité, sécurité, dépendance fournisseur. Fondée sur l'observation directe de l'instance de production.
Verdict en une ligne
Exploitable en lecture, structurellement hostile à l'écriture automatisée et à l'intégration moderne. Fidelio expose de la donnée récupérable (SQL, PDF), mais toute automatisation d'écriture doit être arrachée à l'outil via des contournements sur-mesure et fragiles, faute d'API. Pile technologique legacy, comportements non déterministes, évolution captive d'un support externe.
Fidelio est un ERP Commsoft Phoenix sur SQL Server, servi par une UI web ASP.NET à base d'iframes imbriquées, de fenêtres dhtmlx, de grilles SlickGrid et d'une passerelle RPC générique interne (« Heimdall »). Il n'expose aucune API d'intégration documentée : les échanges passent soit par la BD, soit par cette passerelle dont les identifiants d'enregistrement sont encodés/obfusqués.
On peut extraire de la donnée de façon robuste (Console SQL, PDF). Injecter de la donnée par programme, en revanche, est une lutte permanente : chaque voie testée (saisie grille, import Excel, appels d'API) bute sur un mur d'une nature différente. L'écriture est automatisable dans certains cas — nous l'avons prouvé sur un bon de commande de 48 lignes — mais seulement au prix d'un moteur défensif sur-mesure (validation ligne par ligne, attentes de plusieurs secondes par ligne, tentatives multiples), là où un ERP doté d'une API ferait l'opération en une requête sub-seconde. Ce contraste est le painpoint.
Ce document consigne l'ensemble des points de friction constatés — intégration, automatisation, ergonomie, pile technologique, fiabilité, sécurité, dépendance fournisseur — pour éclairer une décision de pérennité de la plateforme (maintenir vs remplacer).
Notation qualitative (1 = très faible, 5 = solide), sur les plans technique, intégration, ergonomie et gouvernance.
| Couche | Technologie |
|---|---|
| Produit | Commsoft Phoenix (Fidelio) |
| Base de données | Microsoft SQL Server — schéma in_* / ac_* / pa_* |
| Serveur web | ASP.NET — pages Razor .cshtml, login Splash.aspx |
| UI client | iframes imbriquées + fenêtres dhtmlx + jQuery UI + grilles SlickGrid |
| Passerelle RPC | Heimdall/PhoenixService.svc/Rest/ (Invoke, InvokeStatic, CreateData…) |
| Service fichiers | Heimdall/FileService.svc/File/ImportFromExcel |
| Rapports | endpoint Rest/ShowReport → PDF |
La passerelle RPC est générique : la vraie méthode voyage dans le corps JSON, et les enregistrements sont désignés par un dmId de session.
POST /Heimdall/PhoenixService.svc/Rest/CreateData
{ "dmType":"AcAchatNovexco", "dmId":"_7H214KXSM" }
POST /Heimdall/PhoenixService.svc/Rest/Invoke
{ "dmId":"_7H214KXSM", "methodName":"IsOrderInProgress", "parameters":["",true,6] }Les identifiants internes sont obfusqués (mojibake : V£xvu}†´.¯, V!!™¯£´6cf). On ne peut pas construire d'appels RPC ciblés sans passer par l'UI qui génère ces IDs. L'« API-replay » direct est un cul-de-sac, et ces IDs ne sont pas portables vers un autre système.
Recensement exhaustif des frictions constatées, regroupées par dimension. Sévérité : Bloquant Sévère À surveiller
A · Intégration & interopérabilité
Pas d'API REST/SOAP publique documentée, pas de webhooks, pas de connecteurs. Les seules portes sont la BD (SQL Server) et la passerelle RPC interne (non documentée, IDs encodés). Toute intégration se fait « par-dessus » l'UI ou en lisant la BD — jamais de façon supportée.
Prix, taxes, totaux et numérotation d'un PO sont calculés par la logique métier à la saisie. Un INSERT brut dans ac_achats/ac_achats_ln produirait des enregistrements incohérents (0 $, sans taxes, mal numérotés) cassant rapports, réception et compta. La discipline SELECT-only s'impose — donc pas d'écriture par la BD.
Le seul « point d'API » réel est un tunnel RPC interne où la méthode voyage dans le corps JSON et les cibles sont des dmId de session éphémères. Non documenté, non versionné, non contractuel : rien sur quoi bâtir une intégration stable.
B · Automatisation d'écriture
Le remplissage cellule-par-cellule d'une grille SlickGrid est piégé : lookups produit asynchrones et lents, verrou d'édition qui ne se libère pas sur événements synthétiques (colonne quantité proxy nécessitant un clavier « trusted »), overlays qui interceptent les clics. C'est automatisable — nous atteignons 100 % sur 48 lignes — uniquement avec une machine à états défensive : validation par ligne, attentes de plusieurs secondes, tentatives multiples, neutralisation de popups. Effort d'ingénierie considérable, et cassable à la moindre évolution de l'UI (voir §05).
L'import xlsx exige une définition de mapping (colonnes→champs) activée par compte, un format très strict (fournisseur en G, code produit en FS, quantité en FY, sur ~468 colonnes, données dès la ligne 3), et affiche un comportement incohérent d'un essai à l'autre même une fois tout en place — y compris en usage manuel par un humain.
En headless, l'upload de fichier fonctionne mais les fenêtres dhtmlx s'ouvrent hors-écran (coordonnées négatives). En pilotant le vrai Chrome (extension), les fenêtres s'affichent mais Chrome bloque le remplissage d'input fichier via CDP (« Not allowed ») et intercepte les clics manuels. Les deux capacités manquantes sont dans deux environnements qu'on ne peut pas combiner.
C · Ergonomie & productivité opérateur
Des fonctions cœur ne sont accessibles que depuis un mode précis : il faut impérativement être dans la vue Achats ou Standard pour atteindre la fenêtre « Commande d'achats ». L'opérateur doit connaître ces conditions cachées ; se tromper de vue = fonction introuvable, sans indication.
À chaque ligne saisie, le lookup produit (description, prix) se résout de façon asynchrone et lente — plusieurs secondes, jusqu'à une vingtaine dans nos mesures avant stabilisation. Sur une commande de dizaines de lignes, cela s'accumule en minutes d'attente pure, à l'écran comme en automation.
Des modales interrompent le flux (ex. « produit déjà dans une PO ouverte ») et recouvrent la grille, bloquant clics et saisie tant qu'elles ne sont pas explicitement fermées. Multiplié par le volume de lignes, c'est une friction constante.
L'UI empile des fenêtres flottantes (dhtmlx) qui peuvent s'ouvrir hors du viewport ou l'une sur l'autre. Gestion manuelle de la taille/position parfois nécessaire ; désorientant pour l'opérateur.
D · Pile technologique & pérennité
L'interface repose sur dhtmlx (fenêtrage propriétaire ancien), jQuery UI (officiellement en fin de maintenance) et un SlickGrid d'ancienne génération, le tout dans des iframes imbriquées. Pile figée, peu compatible avec les navigateurs et outils modernes, coûteuse à faire évoluer et à tester.
ASP.NET Razor côté serveur + empilement d'iframes et de fenêtres côté client : chaque écran est une composition fragile. Ce type d'architecture rend le débogage, l'automatisation et l'audit d'accessibilité difficiles, et signale un socle technique daté.
E · Fiabilité & déterminisme
À configuration identique, la même opération (notamment l'import Excel) réussit ou échoue selon les essais, sans cause visible. Un système dont on ne peut pas prédire le résultat est difficile à exploiter en confiance et impossible à automatiser proprement.
Un bon de commande tout juste créé n'est pas immédiatement trouvable dans les recherches ni le rapport par numéro (délai d'indexation). Il faut capturer son PDF depuis le formulaire encore ouvert, pas via une recherche par n°.
La session tombe à la fermeture des onglets ; les lookups (produit, fournisseur, PO) sont asynchrones et sensibles au timing, imposant des retries et des attentes généreuses partout.
F · Sécurité & gouvernance
Login simple sans 2FA ni device-binding, sur un compte de service unique (AdminEV) à privilèges larges, partagé. Pratique pour l'automation, mais posture de sécurité faible : pas de traçabilité individuelle, surface de compromission élevée, aucune séparation des rôles observée côté intégration.
G · Indépendance & dépendance fournisseur
Schéma de données propriétaire, IDs internes non portables, définitions d'import gérées côté éditeur, absence d'API : toute évolution ou intégration passe par le support externe de l'éditeur. L'organisation n'est pas autonome pour adapter, connecter ou faire évoluer son ERP — un facteur de coût et de risque structurel dans la durée.
Objectif : créer un bon de commande de 48 lignes (fournisseur Les Éditions CEC) par automatisation. Résultat après ingénierie d'un moteur défensif dédié :
La réussite n'a été possible qu'en construisant une machine à états par ligne : ouverture d'éditeur, saisie via clavier « trusted », sondage du lookup jusqu'à stabilisation (jusqu'à ~20 s), neutralisation des popups, vérification que le code, la description et la quantité sont bien conformes, jusqu'à 5 tentatives, suppression et reprise de la ligne en cas d'échec, et collecte des lignes récalcitrantes pour reprise humaine.
Autrement dit : on peut le faire, mais l'effort pour contourner l'absence d'API est disproportionné, l'exécution reste lente, et l'ensemble est cassable à la moindre évolution de l'UI. Ce qu'un ERP interopérable règle en une requête documentée exige ici un projet d'automatisation à part entière — c'est la démonstration concrète du coût structurel de la plateforme.
Ce sur quoi on peut s'appuyer aujourd'hui, de façon fiable :
ShowReport, capturés en download.reference/) — ils ne sont nulle part ailleurs et se re-perdent vite.Fidelio remplit sa fonction d'ERP transactionnel, mais du point de vue technologique, d'intégration et de pérennité, c'est une plateforme fermée, legacy et captive. Elle donne accès à ses données en lecture, mais se comporte comme une boîte noire dès qu'on veut y écrire, l'intégrer, la faire évoluer ou l'auditer : pas d'API, identifiants opaques, UI à couches capricieuse, comportements non déterministes, sécurité d'accès faible, évolution dépendante d'un tiers.
Pour une organisation qui veut automatiser, intégrer et durer, Fidelio est un frein structurel : chaque capacité doit être arrachée à l'outil plutôt qu'offerte par lui. Les intégrations réalistes se limitent à lire Fidelio et à préparer le travail que des humains valident dans son interface — ou, au prix fort, à automatiser en écriture par des contournements fragiles. Ce constat plaide pour évaluer sérieusement une plateforme API-first dans toute réflexion de pérennité.