É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.
Le champ fournisseur d'un bon de commande n'émet des requêtes serveur que sur environ deux saisies par session. Au-delà, la frappe ne déclenche plus aucun appel : mesuré à la trace réseau, zéro requête Rest/Invoke aux 3ᵉ, 4ᵉ et 5ᵉ essais — quelle que soit la façon d'effacer le champ (programmatique, clavier, frappe intermédiaire). Aucun message, aucune erreur : le champ reste simplement vide. Recréer le formulaire ne réarme rien ; seule une nouvelle session rétablit la capacité de recherche.
Conséquence, pour l'opérateur humain comme pour l'automation : une recherche « morte » est indiscernable d'un fournisseur inexistant. Nos reprises étaient des coups dans le vide — on croyait réessayer cinq fois, on réessayait deux fois. C'est l'origine de l'« intermittence » qui nous a longtemps paru inexplicable (voir §09).
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.
L'instance de base de données servant la base EV se nomme SQLAPNOV01 (SQL Server 2022) — nommage évoquant un serveur mutualisé du groupe, non une instance dédiée ; le frontal web est une VM Azure d'une ferme numérotée (fidelio-pip-a02) sous certificat générique *.fidelio.ca. Le 24 juillet 2026, en pleine rentrée scolaire — pic d'activité simultané de tous les marchands du réseau —, les opérations de données ont été mesurées 2 à 3 fois plus lentes que la référence (extraction de ~23 000 lignes : 27 s → 55 s → 84 s), pendant que le frontal web restait rapide (TTFB ~0,1 s). La dégradation suit la courbe d'activité de la journée et retombe le soir.
Le client n'a aucune visibilité ni levier sur la capacité qui lui est allouée, ni sur la charge des voisins avec qui il la partage — au moment précis de l'année où son activité est critique.
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é.
Deux semaines après l'évaluation initiale, la mise en production de l'automatisation des bons de commande a produit un épisode instructif : trois commandes fournisseurs bloquées une journée entière, en pleine rentrée scolaire. L'enquête a livré deux constats mesurés qui n'apparaissaient pas dans l'évaluation de juillet, et qui renforcent son verdict.
1 · La capacité serveur n'est ni dédiée ni visible
Le 24 juillet, l'instance s'est dégradée d'un facteur 2 à 3 sur les opérations de données, pendant que le frontal web restait nominal — signature d'une contention sur la couche base de données, pas d'une panne. Chronologie mesurée : × 2 à 11 h, × 3,1 à 14 h, retour à × 1,6 vers 17 h. Sur cette journée : aucun bon de commande créé pendant près de six heures (une commande abandonnée après 4 tentatives et 74 minutes) et réceptions bloquées 3 h 38.
L'hypothèse de la mutualisation (voir catalogue, § E) tient à trois indices convergents : le nom de l'instance SQL (SQLAPNOV01), la ferme de VM numérotées avec certificat générique, et la saisonnalité — tous les marchands de fournitures scolaires du réseau atteignent leur pic au même moment. Le client subit la charge de ses voisins sans en avoir connaissance.
2 · Un échec silencieux, indiscernable d'un résultat vide
La recherche de fournisseur échouait de façon apparemment aléatoire. L'instrumentation réseau a montré que le widget cesse d'émettre toute requête après ~2 saisies dans une même session, sans le signaler. Un opérateur — humain ou automate — ne peut pas distinguer « le serveur n'a rien trouvé » de « la recherche n'a jamais eu lieu ».
C'est le trait le plus coûteux : il ne produit pas une erreur qu'on corrige, mais une fausse information qu'on croit. Trois diagnostics successifs ont été formulés puis invalidés par la mesure — lenteur du serveur, puis longueur du nom fournisseur, puis état du formulaire — avant que la trace réseau ne tranche. Un ERP qui journalise ses échecs de recherche aurait rendu ce diagnostic immédiat.
3 · Ce que cela coûte, concrètement
La parade retenue illustre le propos de l'étude de cas (§05) : puisque rien ne réarme la recherche à l'intérieur d'une session, il faut échouer vite et recommencer dans une session neuve — soit, pour une seule commande d'achat, jusqu'à une vingtaine de tentatives réparties sur une douzaine de connexions. Là où une API exposerait une résolution de fournisseur en une requête, il faut ici une stratégie probabiliste, et l'on ne peut garantir le succès : on ne fait qu'en maximiser la probabilité.
Ces deux constats ne changent pas le verdict de l'évaluation — ils le durcissent. À l'absence d'API et au non-déterminisme déjà documentés s'ajoutent désormais une capacité d'hébergement partagée et opaque, et des défaillances qui se présentent comme des résultats normaux. Pour une opération dont la saisonnalité est le cœur du métier, ce sont deux risques structurels, non des incidents ponctuels.