Sites LEJSD dev : fichiers et configuration

Déployer un site sur un serveur d'application, c'est fréquemment le moment où les développeurs perdent un temps précieux à chercher où atterrissent leurs fichiers. La documentation technique WEBDEV du 16/03/2026 lève le voile sur cette organisation, et franchement, comprendre cette arborescence change tout dans la gestion quotidienne d'un projet.

Structure des fichiers WEBDEV après déploiement sur serveur

Quand vous installez un site WEBDEV en mode Session ou AWP, les éléments se répartissent sur trois emplacements distincts. Ce découpage n'est pas arbitraire : chaque répertoire répond à une logique précise d'accès, de sécurité et de performance.

Le répertoire principal du site porte le nom choisi lors du déploiement (par défaut, celui du projet). Il regroupe l'ensemble des éléments présents dans le répertoire Exe du poste de développement, à l'exclusion des fichiers de données HFSQL Classic. On y trouve notamment les bibliothèques avec les extensions WDL et AWL.

Le sous-répertoire WEB mérite une attention particulière. Son nom suit une convention stricte : le nom du projet en majuscules, suivi de WEB. Ce dossier est déclaré comme alias dans le serveur web et reste accessible directement depuis Internet. C'est là que se concentrent les ressources visibles : pages HTML (fichiers HTM), pages dynamiques AWP, images, feuilles de style CSS et fichiers Javascript.

Troisième emplacement : le répertoire des données, situé dans le répertoire de données du compte WEBDEV. Il stocke exclusivement les fichiers HFSQL Classic, reconnaissables à leurs extensions FIC, NDX, MMO, FTX, SDX et VEX.

Le comportement varie selon le type de déploiement. Voici un comparatif synthétique :

Pour un webservice SOAP, le répertoire WEB accueille le fichier AWWS central et des pages HTML de test, tandis que le descripteur WSDL reste à la racine du site. Pour le REST, plus épuré, aucun répertoire WEB n'existe : les éléments du répertoire Exe se retrouvent directement à la racine.

Organiser sa documentation de développement avec un fichier HTML unique

Au-delà de la structure serveur, la gestion des fichiers de documentation pose un défi récurrent dans les projets dev. Une approche minimaliste mais redoutablement efficace repose sur un fichier index.html unique couplé à des fichiers markdown organisés dans un dossier docs/.

L'arborescence recommandée suit cette logique :

1. Un fichier index.html principal à la racine
2. Un dossier docs/ contenant des fichiers markdown numérotés (01-, 02-, 03-...)
3. Un fichier README.md au sommet, servant de table des matières
4. Des dossiers optionnels code-examples/ et reference/ pour les ressources complémentaires

Le rendu s'appuie sur marked.js (version 13.0.0) chargée depuis un CDN. Le routage utilise le hash de l'URL avec l'événement hashchange, ce qui évite toute configuration serveur complexe. Les liens relatifs internes sont réécrits pour fonctionner avec ce système de hash.

Côté CSS, la mise en page repose sur CSS Grid avec une colonne latérale fixe à 280 pixels et le contenu principal sur le reste de l'espace. La barre de navigation bénéficie d'un positionnement sticky et d'une hauteur de 100vh, ce qui garantit sa visibilité lors du défilement. Le mode sombre fonctionne via des variables CSS et la détection automatique de prefers-color-scheme.

Pour maintenir la qualité et la navigabilité, la limite recommandée est de 600 lignes par fichier markdown. Au-delà, la lecture devient laborieuse. L'organisation par but du contenu (plutôt que par type de fichier) améliore sensiblement la recherche d'informations.

JSON-LD et données structurées pour enrichir vos ressources web

Les fichiers d'un projet web ne se limitent pas aux assets visuels ou aux bibliothèques. Les données structurées représentent une couche fréquemment négligée, pourtant déterminante pour l'indexation par les moteurs de recherche.

JSON-LD (JSON for Linked Data) s'impose comme le format privilégié : léger, lisible par un humain, basé sur JSON, et compatible avec des environnements variés comme Apache CouchDB ou MongoDB. Il s'intègre via un élémentaire script de type application/ld+json dans la page, sans modifier le DOM existant. Un exemple concret : Google l'utilise pour ses données d'adresses de bureaux, structurées selon le standard schema.org avec des entités LocalBusiness.

Les avantages sont concrets : structuration claire des données selon schema.org, meilleure exploitation par les moteurs de recherche, génération d'extraits enrichis dans les résultats, et réutilisabilité des données dans des composants web personnalisés sans concevoir de nouvelle structure ad hoc.

Pour déboguer vos implémentations, le JSON-LD Playground reste l'outil de référence : visualisation en temps réel, détection d'erreurs, validation de la syntaxe. Les implémentations couvrent aujourd'hui pratiquement tous les langages : JavaScript, Python, Ruby, Go, Java, PHP, Rust, C#, Erlang/Elixir et TypeScript.

La JSON-LD Working Group du W3C pilote les spécifications formelles, avec une charte en vigueur jusqu'en janvier 2028. Pour contribuer ou suivre les évolutions, le JSON-LD Community Group anime une mailing list et des appels réguliers via son organisation GitHub. L'écosystème s'élargit avec YAML-LD pour un authoring plus lisible, et CBOR-LD pour les cas d'usage nécessitant une forte compression des données.