Bonjour Lionel,

Merci pour votre message.

Afin de bien comprendre votre demande, pourriez-vous nous envoyer quelques captures d’écran montrant les endroits où les libellés « Catégories » et « Produits » apparaissent de manière inappropriée dans votre projet ?

Cela nous permettra de mieux identifier les éléments concernés et de vérifier quelle solution pourrait être envisagée.

Merci d’avance pour votre aide.

Cordialement.

Bonjour Élisa, 

Merci pour votre réponse rapide. En fait, nul besoin de copie d'écran. Il suffit de tester la partie boutique e-commerce de WX5 pour voir que le logiciel génère automatiquement les mots "Produit", "Produits", "Catégorie", "Catégories" dans le processus d'achat...

Or, comme expliqué, des "Séances" ne sont pas des "Produits" que l'on stocke & expédie ensuite, mais des prestations. Idem, pour les "Catégories", terme générique qu'il devrait être possible de remplacer & personnaliser suivant l'activité du client (praticien, praticienne, prestataire, etc...)...

Dans l'attente d'une solution (même temporaire) pour résoudre ce problème, je vous remercie, ainsi que les développeurs D'INCOMEDIA, de l'attention accordée à ma demande dont la solution sera utile à tous dans le futur... 

Bonjour Jean-Pierre, 

Merci de l'intérêt accordé à ma demande. 

Dans cette section e-commerce, tu peux effectivement attribuer des noms aux produits, prestations, etc... 

Mais dans l'exécution de la commande, ce sont bien les termes génériques automatiques qui s'affichent dans la poursuite de l'achat... Pas les noms associés aux prestations proposées... 

Il te suffit de tester pour t'en rendre compte... 

On ne peut pas modifier ces appellations automatiques pour l'instant... 

Tiens-moi au courant de tes essais en local... 

Bien cordialement, 

Lionel

D'ailleurs, sur ta seconde image, il est bien marqué "3 produits" & non "3 séances"... Idem dans la poursuite de l'achat...

Sans oublier cette partie qui s'affiche automatiquement sous l'appellation "Produits" alors que cela n'a pas lieu d'être pour des séances, des prestations, des séjours, etc... : cette partie devrait être paramétrable pour ne s'afficher qu'en cas d'utilité...

Cela veut dire que le système est trop générique & insuffisamment paramétrable à cet endroit...

Bonjour, 

vous pouvez changer ces textes à l'étape 1 > Informations généales> Langue du contenu > Gestion du contenu linguistique. Par examples, les textes "Que les produits à prix réduits" et "Que le produits nouveaux" correspondent aux ID cart_search_page_products_discounted et cart_search_page_products_new.

Merci !

L'étape 1 ? À quel endroit Élisa ? 

Bonjour, 

ici :

Merci !

Merci Élisa pour votre retour et pour cette solution temporaire.

Cependant, la modification via le “traitement de la langue” implique une intervention directe dans les fichiers internes du logiciel, ce qui n’est absolument pas pratique pour un néophyte.

Même pour un utilisateur expérimenté, c’est une zone délicate, car :

• cela modifie des fichiers système du logiciel,

• cela touche aux libellés de langue utilisés dans l’ensemble du projet,

• cela peut casser certaines pages automatiques,

• cela peut provoquer des incohérences dans le panier,

• cela peut rendre le projet incompatible avec une future mise à jour,

• et cela peut même entraîner des erreurs lors de l’exportation ou de la prévisualisation.

Il s’agit donc d’une manipulation avancée, non documentée, non supportée, et clairement pas destinée à l’utilisateur standard.

Le “traitement de la langue” revient à éditer manuellement les fichiers XML/JSON pour remplacer des libellés tels que :

• Products

• Product

• Categories

• Related Products

• etc.

Vous savez comme moi que :

• 95 % des utilisateurs ne peuvent pas effectuer ce type de modification,

• c’est risqué,

• c’est non supporté,

• et ces changements sont susceptibles d’être réinitialisés à chaque mise à jour.

C’est pourquoi je compte sur une évolution du logiciel dans une prochaine mise à jour, afin de permettre la personnalisation ponctuelle des libellés e‑commerce directement depuis l’interface, sans avoir à intervenir dans les fichiers de langue, et surtout sans que ces modifications soient perdues lors des mises à jour.

Dans l’attente du suivi de cette demande, je vous remercie à nouveau et vous souhaite une excellente fin de journée.

Cordialement, Lionel

Vérifications faites, tous les CMS modernes qui utilisent (WordPress, Prestashop, Shopify) ont cette possibilité native depuis plusieurs années. WX5 est donc très en retard sur une fonction aussi simple que basique... 

Bonjour Lionel,

en attendant une éventuelle évolution du logiciel, il est toutefois possible de contourner cette limitation de manière plus ciblée : vous pouvez dupliquer la langue française et lui attribuer un nom différent, spécifiquement pour le projet concerné.

De cette manière, les modifications apportées aux libellés de cette langue ne s’appliqueront qu’à ce projet, sans modifier les fichiers de langue français utilisés par vos autres projets.

Je vais également signaler votre suggestion à notre équipe, afin qu’elle puisse être prise en considération pour une future évolution de WebSite X5.

Merci encore et cordialement.

Bonjour Elisa, 

Je prends note de cette solution mais à la prochaine mise à jour, la langue française dupliquée & modifiée sera effacée, donc ce travail sera perdu.

Il y a certainement une solution indépendante du fichier "langue" en créant & utilisant un code à injecter ? Ce serait bien que vos codeurs se penchent sur aspect ? 

Dans l'attente de votre retour d'informations à ce sujet... 

Cordialement, 

Lionel 

Hello Lionel,
unless a reinstallation of the software also takes place, an update should not impact the custom languages created.
As a failsafe, you can also choose to export the .xml file for the custom language, so that you can import it back if needed.

Online translation:

Bonjour Lionel,
sauf si une réinstallation du logiciel est également effectuée, une mise à jour ne devrait pas avoir d’impact sur les langues personnalisées que vous avez créées.
Par mesure de précaution, vous pouvez également choisir d’exporter le fichier .xml de la langue personnalisée, afin de pouvoir le réimporter si nécessaire.

Bonjour Éric,

Merci pour le complément d'informations. Je note dans le message "qu'une mise à jour ne devrait pas avoir d'impact sur le fichier langue créé"... Nous sommes donc dans une hypothèse, pas une certitude... 
Après vérification, les libellés e‑commerce (Products, Product, Categories, Related Products, etc.) sont effectivement présents dans le fichier de langue française. Leur modification fonctionne, mais cela confirme justement la limite que j’ai signalée :

• ces libellés font partie de la langue système,
• ils sont partagés par tous les projets utilisant cette langue,
• ils ne sont pas isolables par projet, même en dupliquant la langue
• ils peuvent être réinitialisés lors d’une mise à jour, d’une réparation ou d’une réinstallation.

La duplication d’une langue utilisateur ne règle donc pas ce point, puisque ces libellés ne sont pas gérés comme des clés personnalisables projet par projet. D'autre part, on ne règle pas un problème aussi basique en créant un fichier langue parallèle au fichier langue natif. Ce n'est pas une solution pérenne mais du "bricolage". 

C’est pourquoi, comme précisé à Élisa, une évolution du logiciel serait réellement utile : permettre la personnalisation des libellés e‑commerce directement depuis l’interface, de manière propre, stable et sans risque de réinitialisation.

Merci pour la prise en compte de ma demande dans les meilleurs délais,

Bonne journée,

Lionel

Bonjour à l’équipe INCOMEDIA,

Je reviens vers vous concernant le problème que j’ai signalé ci-dessus sur les libellés e‑commerce (noms des catégories, produits, etc.) dans la section e-commerce.

Vous m’avez proposé de créer une langue française parallèle et de modifier manuellement les entrées liées à l’e‑commerce. Après vérification minutieuse, cette méthode ne règle pas le problème de fond : les libellés concernés appartiennent à la langue système et ne sont pas isolés par projet.

De plus, la dernière mise à jour bêta annoncée ne contient aucune correction concernant ce point, ni même une mention dans le changelog.

Pouvez-vous me préciser :

• si cette correction est réellement prévue dans une mise à jour officielle,
• pourquoi elle n’apparaît pas dans la bêta actuelle,
• et si une solution durable est envisagée pour la gestion des libellés e‑commerce ?

Une clarification serait appréciée, car ce point impacte directement la personnalisation des projets.

Merci d’avance pour votre retour d'informations à ce sujet...

Cordialement, 

Lionel

Hello Lionel,
unfortunately at the moment there are no plans for a change regarding this aspect of the software in our next updates, this is why you did not see any reference to this in the changelog.
I remain available.

Online translation:

Bonjour Lionel,
malheureusement, pour le moment, aucune modification de cet aspect du logiciel n’est prévue dans nos prochaines mises à jour. C’est pourquoi vous n’avez trouvé aucune référence à ce sujet dans le changelog.
Je reste à votre disposition.

Bonjour Eric,

Merci pour votre retour.

Je prends note qu’aucune modification n’est prévue concernant la gestion des libellés e‑commerce dans les prochaines mises à jour.

Permettez-moi toutefois de souligner un point important : cette limitation ne relève pas d’une préférence personnelle, mais d’un problème structurel qui empêche d’adapter correctement l’interface e‑commerce aux besoins réels d’un site professionnel.

Aujourd’hui, les libellés utilisés dans la page de recherche (catégories, produits, etc.) sont liés à la langue système et ne peuvent pas être personnalisés projet par projet.

Cela signifie que :les termes affichés ne correspondent pas toujours au "vocabulaire métier" du site, la cohérence graphique et éditoriale est rompue, et il n’existe aucune solution native pour corriger cela.

Pourriez-vous au moins préciser si cette limitation est considérée comme un comportement normal du logiciel, ou si elle est destinée à évoluer à moyen terme ?

Cela nous permettrait de savoir si nous devons adapter nos projets en conséquence ou attendre une évolution future.

Merci d’avance pour votre clarification.

Lionel 

Éric,

Je souhaite attirer votre attention sur un point que beaucoup d’utilisateurs constatent depuis longtemps : les mises à jour de WebSite X5 se présentent presque systématiquement comme une succession de « correction d’un problème », sans véritables nouveautés fonctionnelles, sauf rare exception...

Je comprends parfaitement qu’un logiciel complexe nécessite de la maintenance, mais la structure répétitive des changelogs laisse penser que WX5 fonctionne aujourd’hui sur un moteur interne ancien, difficile à faire évoluer, et que chaque tentative d’amélioration entraîne de nouvelles régressions à corriger.

Ce n’est pas une critique gratuite : c’est un constat technique.

Les utilisateurs avancés voient bien que certaines limitations (DOM encapsulé, sandbox restrictive, réécritures d’IDs/classes, incompatibilités JS/CSS modernes, comportements différents entre l’aperçu interne et les navigateurs) ne sont pas des « bugs isolés », mais les symptômes d’une architecture qui a du mal à suivre les standards actuels du web.

Nous serions nombreux à apprécier davantage de transparence sur ce point :

Le moteur interne de WX5 est‑il prévu pour être modernisé ?

Une refonte progressive est‑elle envisagée ?

Peut‑on espérer des mises à jour qui apportent de vraies fonctionnalités plutôt qu’une liste de correctifs ?

Ce message n’est pas une attaque : c’est une demande constructive.

WX5 reste un outil apprécié, mais il mérite une communication plus claire sur sa feuille de route technique.

Merci d’avance pour votre retour d'informations à ce sujet également

Lionel

La preuve ci-dessous :

WebSite X5 – 2026.2.7 [BETA]

Responsive Design

Correction d’un problème provoquant un crash lors du copier‑coller d’objets entre des projets ayant des points de rupture différents.

E‑commerce

Correction d’un problème où des produits ajoutés au panier alors qu’ils étaient disponibles pouvaient encore être commandés plus tard, même après avoir été définis comme indisponibles et après republication du site.

Général

Correction d’un problème où les liens vers des fichiers locaux assignés à des images n’étaient parfois pas conservés après la réouverture des paramètres de l’objet ou le lancement d’un nouvel aperçu.

Amélioration de la visibilité du contenu des cartes défilantes, afin de rendre plus clair lorsqu’un texte supplémentaire est disponible sous la zone visible.

Hello Elbe,
we do not have an available roadmap to disclose regarding future updates or overhauls at the moment, and I cannot unfortunately comment on these aspects.
We of course prioritize compatibility and optimization with modern standards as they evolve, and so will consider changes to these elements as needed, in the future.

Regarding the updates, what you mention has indeed been the standard for years: major updates (2026.1, 2026.2, 2026.3) contain new features and usually 3 or 4 of them are released each year, whereas the minor updates within them (2026.2.7, for example) contain mostly fixes, and only occasionally add features.
I remain available.

Online translation:

Bonjour Elbe,
nous ne disposons malheureusement pas, à l'heure actuelle, d'une feuille de route à communiquer concernant les futures mises à jour ou évolutions du logiciel, et je ne peux donc pas commenter ces aspects.
Nous accordons bien entendu la priorité à la compatibilité et à l'optimisation avec les standards modernes au fur et à mesure de leur évolution, et nous étudierons donc les éventuelles modifications de ces éléments lorsque cela sera nécessaire à l'avenir.

Concernant les mises à jour, ce que vous mentionnez est effectivement le fonctionnement standard depuis plusieurs années : les mises à jour majeures (2026.1, 2026.2, 2026.3) contiennent de nouvelles fonctionnalités et, généralement, 3 ou 4 d'entre elles sont publiées chaque année, tandis que les mises à jour mineures qui s'y rattachent (2026.2.7, par exemple) contiennent principalement des corrections et n'ajoutent que ponctuellement de nouvelles fonctionnalités.
Je reste à votre disposition.

Franchement Éric, la majorité des mises à jour de WebSite X5 se compose essentiellement de « correction d’un problème », avec très peu d’évolutions fonctionnelles ou UX significatives.

Ce n’est pas une critique gratuite, mais un constat technique que je me permets de détailler ici afin de mieux comprendre la situation et d’obtenir, si possible, une clarification sur la feuille de route du logiciel.

1. Architecture interne héritée
Le moteur interne de WX5 repose sur une base technologique conçue il y a plusieurs générations web. Cela implique que chaque tentative d’introduire une nouveauté doit composer avec des modules anciens, ce qui augmente fortement le risque de régression.

2. DOM encapsulé et réécrit
WX5 ne s’appuie pas sur un DOM standard comme les navigateurs modernes. Le logiciel encapsule, renomme et réécrit des éléments, ce qui entraîne des incompatibilités avec les scripts JS/CSS actuels. Toute nouveauté doit donc être ajustée pour éviter de casser ce fonctionnement interne.

3. Sandbox restrictive des objets HTML
Les objets HTML ne disposent pas d’un environnement standard : certains comportements JS, certaines transitions CSS ou certains listeners sont neutralisés ou modifiés. Cela limite fortement l’introduction de nouvelles fonctionnalités sans risquer de perturber l’existant.

4. Compatibilité multi‑navigateurs forcée
WX5 doit garantir un rendu cohérent dans son aperçu interne, dans Chrome, Edge, Firefox, Safari et WebKit mobile. Chaque nouveauté multiplie donc les scénarios de test et les risques de régression. Lorsqu’un module ancien est ajusté pour corriger un bug, cela peut en déclencher d’autres dans des zones inattendues du logiciel. D’où la nécessité de publier des mises à jour composées principalement de correctifs successifs.

6. Conséquence directe : cycle de maintenance plutôt que cycle d’innovation
Ces contraintes techniques expliquent pourquoi les mises à jour se concentrent sur la stabilité plutôt que sur l’ajout de fonctionnalités modernes.

Ma question est donc simple :
Ce fonctionnement est‑il destiné à rester la norme, ou une modernisation progressive du moteur interne est‑elle envisagée à moyen terme ?

Une clarification sur ce point serait très appréciée, car elle permettrait aux utilisateurs avancés d’adapter leurs projets et leurs attentes en conséquence.

Merci d’avance pour votre retour d'informations à ce sujet...

Cordialement,

Traduction en italien si vous voulez transmettre directement mon message au staff des programmeurs ainsi qu'à votre Direction :

Eric, la maggior parte degli aggiornamenti di WebSite X5 consiste essenzialmente in una serie di «correzioni di problemi», con pochissime evoluzioni funzionali o miglioramenti UX significativi.

Non si tratta di una critica gratuita, ma di una constatazione tecnica che mi permetto di dettagliare qui, per comprendere meglio la situazione e ottenere, se possibile, un chiarimento sulla roadmap del software.

1. Architettura interna ereditata
Il motore interno di WX5 si basa su una struttura tecnologica progettata diverse generazioni fa. Questo implica che ogni tentativo di introdurre una novità deve confrontarsi con moduli datati, aumentando notevolmente il rischio di regressioni.

2. DOM incapsulato e riscritto
WX5 non utilizza un DOM standard come i browser moderni. Il software incapsula, rinomina e riscrive vari elementi, generando incompatibilità con script JS/CSS attuali. Ogni nuova funzionalità deve quindi essere adattata per evitare di compromettere questo funzionamento interno.

3. Sandbox restrittiva degli oggetti HTML
Gli oggetti HTML non dispongono di un ambiente standard: alcuni comportamenti JS, alcune transizioni CSS o determinati listeners vengono neutralizzati o modificati. Questo limita fortemente l’introduzione di nuove funzionalità senza rischiare di alterare quelle esistenti.

4. Compatibilità multi‑browser forzata
WX5 deve garantire un rendering coerente nell’anteprima interna, in Chrome, Edge, Firefox, Safari e WebKit mobile. Ogni novità moltiplica quindi gli scenari di test e i rischi di regressione. Quando un modulo datato viene corretto, può generare problemi in altre parti del software. Da qui la necessità di rilasciare aggiornamenti composti principalmente da correzioni successive.

5. Conseguenza diretta: ciclo di manutenzione invece che ciclo di innovazione
Questi vincoli tecnici spiegano perché gli aggiornamenti si concentrano sulla stabilità piuttosto che sull’introduzione di funzionalità moderne.

La mia domanda è quindi semplice:
Questo funzionamento è destinato a rimanere la norma, oppure è prevista una modernizzazione progressiva del motore interno nel medio termine?

Un chiarimento su questo punto sarebbe molto apprezzato, perché permetterebbe agli utenti avanzati di adattare i propri progetti e le proprie aspettative di conseguenza.

Grazie in anticipo per il vostro riscontro in merito.

Cordiali saluti. 

Bonjour Eric,

Merci pour votre réponse.

Je comprends que vous ne puissiez pas communiquer une roadmap détaillée, mais votre message confirme que le modèle actuel — mises à jour mineures composées essentiellement de correctifs, et rares évolutions dans les mises à jour majeures — est destiné à rester la norme.

Permettez-moi toutefois de reformuler ma question, car elle ne concerne pas la fréquence des mises à jour, mais la nature du moteur interne du logiciel.

Aujourd’hui, certaines limitations structurelles (DOM encapsulé, sandbox HTML, réécritures d’IDs/classes, incompatibilités JS/CSS modernes, différences entre l’aperçu interne et les navigateurs) rendent difficile l’introduction de fonctionnalités UX modernes sans générer des régressions.

Ma question est donc simplement la suivante :
Une modernisation progressive du moteur interne est‑elle envisagée à moyen terme, ou le fonctionnement actuel est‑il destiné à rester tel quel ?

Ce point est important pour les utilisateurs avancés, car il conditionne la manière dont nous pouvons planifier nos projets et anticiper les limites du logiciel.

Au vu de votre réponse, et du fonctionnement que vous décrivez, j’en déduis que WebSite X5 est aujourd’hui un logiciel en maintenance permanente, davantage centré sur la correction de problèmes que sur une évolution technique ou UX significative.Ce n’est pas une critique, simplement la conclusion logique de ce que vous indiquez.C’est précisément pour cette raison que je souhaitais savoir si une modernisation progressive du moteur interne était envisagée à moyen terme.

Merci d’avance pour votre clarification.

Bien cordialement, 

Lionel

Hello,
we are not planning changes regarding WebSite X5's engine at the moment, and our future major updates will be focused on new features, as it has been for the last years.
Regarding what you mentioned about DOM or sandbox, could you provide some clarifications?
For example, our DOM is standard and the pages generated by WebSite X5 pass HTML validation, and what do you mean exactly by sandbox in that context?

I would not say that WebSite X5 is "focused more on fixing problems." Rather, it is normal for a software product to have a greater number of maintenance releases containing fixes and smaller improvements compared to releases introducing larger new features or more substantial changes.
In the case of WebSite X5, we currently release around three major updates per year, alongside the smaller updates that may be released between them to address issues and introduce smaller improvements. This type of release cycle is also common in software development, where larger feature releases are generally complemented by more frequent maintenance and bug-fix releases.

I remain available.

Online translation:

Bonjour,
Nous ne prévoyons pas de modifications concernant le moteur de WebSite X5 pour le moment, et nos prochaines mises à jour majeures seront axées sur de nouvelles fonctionnalités, comme cela a été le cas ces dernières années.
Concernant ce que vous avez mentionné au sujet du DOM ou du sandbox, pourriez-vous apporter quelques précisions ?
Par exemple, notre DOM est standard et les pages générées par WebSite X5 passent la validation HTML. Que voulez-vous dire exactement par « sandbox » dans ce contexte ?

Je ne dirais pas que WebSite X5 est « davantage axé sur la correction de problèmes ». Il est plutôt normal qu'un logiciel propose un plus grand nombre de mises à jour de maintenance contenant des corrections et de petites améliorations, par rapport aux mises à jour introduisant de nouvelles fonctionnalités importantes ou des changements plus conséquents.
Dans le cas de WebSite X5, nous publions actuellement environ trois mises à jour majeures par an, auxquelles s'ajoutent les mises à jour plus petites qui peuvent être publiées entre-temps afin de résoudre certains problèmes et d'apporter des améliorations mineures. Ce type de cycle de publication est également courant dans le développement logiciel, où les mises à jour apportant de nouvelles fonctionnalités importantes sont généralement complétées par des mises à jour de maintenance et de correction de bugs plus fréquentes.

Je reste à votre disposition.

Hello Elbe 2

La partie e-Commerce devrait être refondue totalement .... pour déjà être construite une base de données et rien d'autres et c'est loin d'être le cas.
Oui c'est un sacré job....

C'est pour cela qu'ils sont incapables de faire un vrai outil de back office pour gérer les commandes, les produits, les prix.... pour qu'un client soit autonome à faire ce qu'il souhaite avec sa boutique.
A ce jour il faut WSX5 pour modificer quoique ce soit dans la partie e-commerce.
C'est  absurde  et  hors  marché  !

Ils mettent à chaque fois des rustines mais le fond ne change pas.
et c'est demandé depuis des années déjà !!!

Comme ils n'ont pas les ressources ils vont avec ce qu'il ont...

C'est un produit mort pour cette partie.....

Axel

Bonjour Éric,

Merci pour votre retour rapide, j'apprécie...

Je vous apporte volontiers les précisions demandées concernant le DOM et la notion de “sandbox”, afin d’éviter tout malentendu.

1. À propos du DOM “standard”

Je comprends que les pages générées par WebSite X5 passent la validation HTML, mais cela ne signifie pas que le DOM utilisé par le logiciel est identique à celui d’un navigateur moderne.

Dans WX5, plusieurs comportements montrent que le DOM est encapsulé et réécrit :

• certains IDs et classes sont renommés automatiquement ;
• certains éléments sont regroupés dans des conteneurs internes ajoutés par le logiciel ;
• certaines structures sont modifiées entre l’aperçu interne et l’export final ;
• certains scripts JS ne peuvent pas cibler directement les éléments générés (sélecteurs qui ne correspondent plus après export).

Ce sont ces mécanismes de réécriture qui rendent l’intégration de fonctionnalités modernes plus délicate, car le DOM final n’est pas toujours identique au DOM édité.

2. À propos de la notion de “sandbox”

Je n’utilise pas ce terme dans le sens strict d’un environnement isolé comme dans les navigateurs, mais dans le sens d’un environnement contrôlé où certains comportements sont volontairement limités.

Concrètement, dans WX5 :

• certains scripts JS sont neutralisés ou ne s’exécutent pas dans l’objet HTML ;
• certains événements (onclick, onload, scroll, resize…) sont filtrés ou modifiés ;
• certaines transitions CSS ne fonctionnent pas dans l’aperçu interne ;
• certains listeners ne peuvent pas être attachés directement aux éléments générés ;
• certaines librairies externes ne fonctionnent pas correctement dans l’objet HTML.

Ces limitations ne sont pas des défauts en soi : elles existent pour protéger le moteur natif interne utilisé dans WX5.

Mais elles montrent que l’objet HTML n’est pas un environnement “ouvert” comme dans un navigateur classique, d’où l’usage du terme “sandbox”.

3. À propos du cycle de mises à jour

Je comprends votre explication concernant les mises à jour majeures et mineures.
Ma remarque ne concernait pas la fréquence des mises à jour, mais le fait que les limitations structurelles évoquées ci‑dessus rendent l’introduction de nouvelles fonctionnalités UX plus complexe, ce qui explique pourquoi les mises à jour mineures sont très souvent composées de correctifs.

C’est dans ce contexte que je me demandais si une modernisation progressive du moteur interne était envisagée à moyen terme...

À titre d’information, il existe déjà des solutions externes permettant de corriger le comportement des libellés e‑commerce dans la page de recherche comme dans la procédure d'achat de WX5.
Cela montre que la correction est techniquement possible sans modifier le moteur du logiciel, ce qui rend d’autant plus surprenante l’absence d’un correctif officiel de votre part.

Merci encore pour votre disponibilité et votre prochaine réponse... 

Bien cordialement, 

Lionel

Hello Axel,

Merci pour ton retour, je comprends très bien ton point de vue.

Il est vrai que la partie e‑commerce de WebSite X5 repose sur une structure qui n’est pas basée sur une base de données classique, ce qui limite forcément les possibilités d’évolution et de gestion autonome côté client.

Je partage ton constat : tant que le moteur reste construit sur ce modèle, il est difficile d’imaginer un back‑office complet permettant de gérer produits, prix, commandes ou stocks sans repasser par le logiciel lui‑même.

De mon côté, je ne cherche pas à critiquer, mais simplement à comprendre si une modernisation progressive du moteur est envisagée à moyen terme.

D’autant que certaines solutions externes montrent déjà que certains correctifs sont techniquement possibles, ce qui laisse penser qu’il y aurait matière à faire évoluer cette partie du logiciel.

En tout cas merci pour ton éclairage, toujours pertinent.

À bientôt,

Lionel

Hello Jean‑Pierre,

Je ne sais pas si tu suis encore cet échange, mais ta vision de modérateur historique est toujours appréciée.
Même si la discussion est devenue assez technique, ton regard “terrain” sur l’évolution du logiciel et sur les attentes des utilisateurs serait toujours utile.

Merci d’avance si tu souhaites apporter ton éclairage.

Bien cordialement, 

Lionel

Hello Lionel,
thank you for the clarification.
I can confirm that the behaviors you have described are intentional.
WebSite X5 is designed as a no-code/low-code website creation software, with the goal of allowing users to create and manage a website without having to write or customize HTML, JavaScript, or CSS code directly.
It is true that WebSite X5 provides several possibilities for adding and customizing code, for example through the HTML Object and other areas where custom code can be entered, however, these options are intended for specific cases and are not meant to be the standard way in which the software is used.
As a result, the software's internal mechanisms may impose certain constraints on how custom code interacts with the elements generated by WebSite X5. These behaviors are therefore not necessarily indicative of an obsolete or incomplete DOM implementation, but are part of how the software is designed to maintain control over the code it generates while still allowing a certain degree of customization.
I remain available.

Online translation:

Bonjour Lionel,
merci pour ces précisions.
Je peux confirmer que les comportements que vous avez décrits sont intentionnels.
WebSite X5 est conçu comme un logiciel de création de sites web no-code/low-code, avec pour objectif de permettre aux utilisateurs de créer et de gérer un site web sans avoir à écrire ou à personnaliser directement du code HTML, JavaScript ou CSS.
Il est vrai que WebSite X5 offre plusieurs possibilités d’ajouter et de personnaliser du code, par exemple via l'Objet HTML et d'autres sections dans lesquelles du code personnalisé peut être saisi. Toutefois, ces possibilités sont destinées à des cas spécifiques et ne sont pas conçues pour constituer la méthode d'utilisation standard du logiciel.
Par conséquent, les mécanismes internes du logiciel peuvent imposer certaines contraintes quant à la manière dont le code personnalisé interagit avec les éléments générés par WebSite X5. Ces comportements ne sont donc pas nécessairement le signe d'une implémentation obsolète ou incomplète du DOM, mais font partie de la conception du logiciel, qui vise à conserver le contrôle sur le code qu'il génère tout en permettant un certain degré de personnalisation.
Je reste à votre disposition.

Salut Lionel,

J'ai caché ton message en doublon...  ;o)

Quant au reste, je n'ai pas de formation technique comme toi, et je me dois de rester "impartial" vis à vis des utilisateurs et d'Incomedia.

Mon rôle de modérateur (depuis 2009) doit se limiter à conseiller ou orienter les utilisateurs confrontés à des soucis d'utilisation du produit, et/ou activer des demandes d'interventions de la part des techniciens d'Incomedia quand cela s'avère nécessaire.

Bonne continuation,

J.P.

Bonjour Éric,.

Merci pour votre réponse, qui éclaire mieux la philosophie no‑code/low‑code du logiciel.

Une question demeure toutefois : dans un marché où les solutions no‑code concurrentes offrent une plus grande liberté d’intégration, quel est l’intérêt stratégique de maintenir des limitations plus fortes que celles de vos concurrents ?

Ces contraintes réduisent en effet la marge de manœuvre des utilisateurs avancés, qui utilisent WX5 comme base de travail tout en personnalisant ensuite leurs projets avec du code.

Le forum montre régulièrement que ces utilisateurs se heurtent à ces limitations, et certains ont fini par se tourner vers d’autres solutions, principalement parce qu’ils se sentaient freinés par des comportements récurrents à chaque mise à jour. Ma question est donc simplement de savoir si une évolution graduelle de ces limitations est envisagée à moyen terme.

Il est vrai que les mises à jour successives centrées sur des correctifs peuvent parfois donner une image moins dynamique du logiciel, ce qui n’est jamais idéal dans un marché où les concurrents communiquent surtout sur des nouveautés.
Cela renforce d’autant plus l’intérêt d’une modernisation progressive du moteur, afin que les mises à jour puissent davantage valoriser l’évolution du produit plutôt que la résolution de problèmes récurrents.

Ce phénomène semble indiquer qu’il existe une attente réelle pour un assouplissement progressif du moteur, afin de mieux concilier les besoins des débutants et ceux des utilisateurs expérimentés.

Merci encore pour votre disponibilité et vos réponses.

Cordialement, 

Lionel

Hello Lionel

Client depuis 2019, j'ai déjà demandé à faire évoluer le e-Commerce via une full base de données, comme ils le font tous.

A ce jour rien, et je peux parier que cela ne changera pas. Ils sont parties sur le concept et ils restent dessus à mettre des rustines.

Il y a un tel travail à faire de réécriture et 'intégrer cela au coeur de WSX5. Peut être aussi qu'il y a un maque de compétence dans ce domaine.

Dommage car cela serait tellement mieux, et surtout de proposer un vrai Back Office pour changer juste un prix !..... sans avoir le logiciel.

Axel

Hello lionel

full agree

j'ai un outil révolutionnaire pour gérer les bases de donneées Vial html et surtout qui fait quoi sur la base. top niveau

https://afsoftware.fr/sgbd2web.html

dommage car on aurait pu faire de belles choses 

Axel

Hello Lionel

demain si tout est dans une base  je te fais un un GUi web en 8 jours. ils ne peuvent pas faire aussi vite  !!!!

pas de code. l'outil graphique permet de tout fabriquer dans une interface et ensuite il genere le  code html/php. tu exportes et bingo !

donc pas d'erreur de  code ecrit par un dev. 

c 'est donc super rapide 

Axel

Hello Axel,

Merci pour tes précisions, ça m’aide à mieux comprendre la logique de ton outil.

Si je résume bien : dès lors que la base SQL est propre et structurée, ton interface graphique permet de générer automatiquement l’ensemble des pages métiers, formulaires, validations et permissions, sans écrire une seule ligne de code.

C’est exactement ce qui manque dans les solutions statiques comme WX5 : un moteur dynamique capable de lire un schéma SQL et de produire un CRUD complet en quelques jours.

Je comprends mieux pourquoi tu peux aller aussi vite : tu t’appuies sur un framework interne déjà éprouvé, et l’outil fait le travail répétitif à ta place.

C’est une approche très efficace, et clairement différente de ce que proposent les outils du marché.

Merci pour ton éclairage, c’est toujours intéressant de voir comment tu as structuré ton workflow.

Lionel