CDC-WEB-001 Refonte du site institutionnel WININFO Version : 0.1 – Document de travailProjet : Nouveau site wininfo.frCible technique : PHP / HTML5 / CSS / JavaScript / Base de donnéesSite cible : www.wininfo.fr 1. Objet du projet Le présent cahier des charges définit les spécifications fonctionnelles et techniques du nouveau site Internet de WININFO. Le projet consiste à remplacer le site institutionnel actuel par une plateforme moderne, évolutive et administrable permettant de présenter : WININFO et son savoir-faire ; les solutions logicielles éditées et intégrées par WININFO ; les différents modules disponibles ; les activités et métiers couverts ; les prestations de développement sur mesure ; l'activité de formation CFI ; l'activité MobilityScan ; les ressources, actualités et contenus proposés par WININFO ; les moyens de contacter les équipes commerciales et techniques. Le nouveau site ne doit pas être conçu comme un ensemble figé de pages HTML. Il doit constituer une plateforme éditoriale administrable, permettant à WININFO de faire évoluer son catalogue de solutions et de modules sans intervention sur le code source. 2. Contexte WININFO est un cabinet d'ingénierie informatique spécialisé dans la conception, le développement, l'intégration et l'accompagnement de solutions de gestion. L'offre WININFO s'est considérablement enrichie au fil des années. Le site Internet actuel ne reflète plus correctement : l'étendue des solutions proposées ; les différents métiers couverts ; le caractère modulaire de Win@ERP ; les nouveaux développements ; les interactions entre les solutions ; le savoir-faire métier de WININFO ; les activités complémentaires de formation et de mobilité. Le nouveau site doit devenir la vitrine de référence de l'écosystème WININFO. 3. Objectifs Le nouveau site doit répondre à plusieurs objectifs. 3.1 Présenter clairement WININFO Le visiteur doit comprendre rapidement : qui est WININFO ; ce que fait l'entreprise ; quels métiers elle maîtrise ; quelles solutions elle propose ; comment elle accompagne ses clients. 3.2 Valoriser les solutions Le site doit permettre de présenter clairement les produits principaux ainsi que les modules qui les complètent. À la date de rédaction du présent document, deux produits principaux sont identifiés : Win@ERPPlateforme centrale et modulaire de gestion. Win@WMSSolution spécialisée de gestion d'entrepôt. Cette liste doit pouvoir évoluer. 3.3 Valoriser la modularité de Win@ERP Win@ERP constitue une plateforme sur laquelle peuvent venir s'intégrer différents modules. Ces modules peuvent être de deux natures. Modules métier Ils permettent d'adapter Win@ERP à une activité ou à un secteur particulier. Exemples : Win@Transport ; Win@Express ; Win@Messagerie ; Win@TP ; Win@Logistique ; Win@Atelier ; Win@BTP ; Win@Traçabilité. Modules fonctionnels Ils ajoutent des fonctionnalités complémentaires ou transversales. Exemples : Win@Trésorerie ; modules liés à la facturation électronique ; modules financiers ; modules de communication ; modules documentaires ; autres fonctionnalités développées par WININFO. Cette distinction doit être gérée nativement par le site. 3.4 Faciliter l'ajout de nouvelles solutions WININFO développe régulièrement de nouveaux modules. La création d'un nouveau module ne doit donc pas nécessiter la création manuelle d'une nouvelle page PHP. Un utilisateur autorisé doit pouvoir créer une fiche depuis le back-office, renseigner les informations nécessaires puis publier le module. La page publique correspondante doit alors être générée automatiquement. 4. Principes fondamentaux d'architecture 4.1 Architecture générale Le projet comportera trois couches principales : ┌───────────────────────────────┐ │ SITE PUBLIC WININFO │ │ Front-office │ └───────────────┬───────────────┘ │ ┌───────────────▼───────────────┐ │ APPLICATION / MOTEUR │ │ PHP + composants métier │ └───────────────┬───────────────┘ │ ┌───────────────▼───────────────┐ │ BASE DE DONNÉES │ │ Produits / Modules / Pages... │ └───────────────────────────────┘ ▲ │ ┌───────────────┴───────────────┐ │ BACK-OFFICE WININFO │ │ Administration des contenus │ └───────────────────────────────┘ Le contenu éditorial ne devra pas être codé directement dans les templates lorsque celui-ci a vocation à être modifié depuis le back-office. 5. Gestion des produits Le back-office doit permettre de gérer les produits proposés par WININFO. Chaque produit disposera au minimum des informations suivantes : Champ Description Identifiant interne Identifiant unique et immuable Nom Nom commercial Slug Identifiant utilisé dans l'URL Description courte Présentation synthétique Présentation Texte principal Accroche Message commercial Image principale Visuel du produit Galerie Images complémentaires Fonctionnalités Liste structurée Bénéfices Liste structurée Modules associés Modules rattachés au produit FAQ Questions/réponses Meta Title SEO Meta Description SEO Image OpenGraph Partage réseaux sociaux Statut Brouillon / publié / archivé Ordre Priorité d'affichage La structure doit permettre d'ajouter ultérieurement un troisième ou quatrième produit sans développement spécifique. 6. Gestion des modules La gestion des modules constitue une fonction majeure du back-office. 6.1 Fiche module Chaque module disposera notamment des champs suivants : Identification identifiant interne ; nom ; slug ; produit de rattachement ; type de module ; catégorie ; statut. Présentation accroche ; description courte ; présentation détaillée ; image principale ; galerie. Contenu fonctionnel fonctionnalités ; bénéfices ; cas d'utilisation ; secteurs concernés ; modules complémentaires ; produits ou services associés ; FAQ. Référencement Meta Title ; Meta Description ; URL canonique ; image OpenGraph. 7. Typologie des modules Le champ Type de module devra au minimum proposer : MÉTIER Module destiné à répondre aux besoins spécifiques d'une activité. Exemple : Win@TPType : MétierFamille : Travaux Publics FONCTIONNEL Module ajoutant une fonction transverse. Exemple : Win@TrésorerieType : FonctionnelFamille : Finance / Pilotage La liste des types devra être administrable afin de permettre une évolution future. 8. Catégories et familles Les modules doivent pouvoir être regroupés par catégories. Exemples envisagés : Transport ; Logistique ; Travaux Publics ; BTP ; Maintenance ; Finance & Pilotage ; Mobilité ; Gestion documentaire ; Facturation ; Communication ; Interfaces & EDI. Un module pourra appartenir à plusieurs catégories. Les catégories ne doivent pas être utilisées pour construire l'URL permanente du module. Cette séparation permettra de réorganiser ultérieurement le catalogue sans casser les liens existants. 9. Gestion des URL Cette partie constitue une exigence forte du projet. Les URL publiques doivent être : compréhensibles ; courtes ; pérennes ; indépendantes de l'organisation du menu ; indépendantes des catégories. Convention proposée : /solutions/win-erp/ /solutions/win-wms/ /modules/win-transport/ /modules/win-express/ /modules/win-messagerie/ /modules/win-tp/ /modules/win-logistique/ /modules/win-atelier/ /modules/win-btp/ /modules/win-tracabilite/ /modules/win-tresorerie/ 10. Compatibilité avec AgentNova Les pages produits et modules du site Internet seront utilisées comme références depuis les fiches correspondantes dans AgentNova. Il est donc indispensable que leurs URL soient stables dans le temps. Chaque fiche produit ou module du back-office devra afficher clairement : URL publique avec une fonction : Copier l'URL L'URL copiée devra être l'URL définitive www.wininfo.fr et non celle de l'environnement de développement. Exemple : https://www.wininfo.fr/modules/win-transport/ Cette URL pourra être renseignée dans la fiche correspondante d'AgentNova. 11. Gestion des changements d'URL Après la première publication d'une page, la modification de son slug devra être considérée comme une opération sensible. Le back-office devra : avertir l'utilisateur ; conserver l'ancienne URL ; créer automatiquement une redirection permanente HTTP 301 ; enregistrer la nouvelle URL canonique. Exemple : Ancienne URL /modules/tresorerie/ ↓ 301 Nouvelle URL /modules/win-tresorerie/ Ainsi, un ancien lien enregistré dans AgentNova, Google, un email ou un document continuera de fonctionner. 12. Identifiants internes Chaque élément important devra disposer d'un identifiant interne indépendant de son nom commercial et de son URL. Exemple : MOD-001 Win@Transport MOD-002 Win@Express MOD-003 Win@Messagerie MOD-004 Win@TP ... Cet identifiant est immuable. Ainsi, si un produit ou module change de nom commercial, le système continuera de l'identifier comme le même objet. 13. Gestion dynamique des pages Le site devra également permettre la gestion des pages institutionnelles. Exemples : Accueil ; Qui sommes-nous ? ; Développement sur mesure ; CFI ; MobilityScan ; Contact ; ressources. Une page sera constituée de sections réutilisables. Types de sections envisagés : Hero ; texte ; texte + image ; image + texte ; grille de cartes ; produits ; modules métier ; modules fonctionnels ; fonctionnalités ; bénéfices ; chiffres clés ; processus ; témoignages ; galerie ; FAQ ; actualités ; appel à l'action ; formulaire. L'administrateur devra pouvoir : ajouter → supprimer → masquer → déplacer → paramétrer une section. 14. CFI CFI constitue une activité de WININFO et doit être intégré au site institutionnel. Une rubrique dédiée permettra notamment de présenter : le centre de formation ; les formations proposées ; l'accompagnement ; les informations pratiques ; la location de salle. CFI devra conserver une identité visuelle identifiable tout en restant intégré à l'univers WININFO. 15. MobilityScan MobilityScan dispose de son propre site marchand. Le site WININFO n'a donc pas vocation à dupliquer la boutique MobilityScan. Une page institutionnelle MobilityScan sera cependant présente sur wininfo.fr afin de : présenter l'activité ; présenter les familles de matériels ; expliquer leur utilisation avec les solutions WININFO ; valoriser l'accompagnement matériel et mobilité ; orienter les visiteurs vers la boutique MobilityScan. Le CTA principal sera : Accéder à la boutique MobilityScan et ouvrira le site marchand MobilityScan. 16. Première arborescence fonctionnelle À ce stade du projet, l'arborescence cible est la suivante : WININFO │ ├── Accueil │ ├── Solutions │ ├── Win@ERP │ │ │ ├── Solutions métiers │ │ ├── Transport │ │ ├── Express │ │ ├── Messagerie │ │ ├── TP │ │ ├── Logistique │ │ ├── Atelier │ │ ├── BTP │ │ └── Traçabilité │ │ │ ├── Fonctionnalités complémentaires │ │ ├── Trésorerie │ │ └── ... │ │ │ └── Win@WMS │ ├── Développement sur mesure │ ├── CFI – Formation │ ├── MobilityScan │ ├── Ressources │ ├── Actualités │ ├── Guides / Documentation │ └── Facturation électronique │ ├──À propos │ ├── WININFO │ ├── Expertise │ ├── Valeurs │ └── Contact │ ├── Hotline │ └── Espace client Cette arborescence ne doit pas être codée en dur. Le back-office devra permettre de faire évoluer les menus et l'organisation des contenus. 17. Principe éditorial Le futur site ne doit pas être une documentation technique des logiciels. Il doit répondre en priorité aux questions du prospect : Est-ce que WININFO connaît mon métier ?Avez-vous une solution pour mon besoin ?Que va-t-elle m'apporter ?Peut-elle évoluer avec mon entreprise ?Pouvez-vous l'adapter à mon organisation ?Qui va m'accompagner ? Les pages devront donc privilégier : Besoin métier → Solution → Fonctionnement → Bénéfices → Accompagnement → Action plutôt qu'une succession de listes de fonctionnalités. 18. Principe d'évolutivité Cette règle doit être considérée comme une exigence fondamentale : L'ajout d'un produit, d'un module, d'une actualité, d'une ressource ou d'une page courante ne doit pas nécessiter une modification du code source. Le développement réalisé par Codex doit fournir à WININFO un moteur de site pérenne, et non uniquement reproduire les pages connues au moment du projet. 19. Modèle de données fonctionnel La base de données constitue le référentiel des contenus du site. Le modèle devra être conçu pour permettre l'évolution du site sans remise en cause de sa structure. La base devra notamment gérer les relations suivantes : PRODUIT │ ├── MODULES │ ├── Type : Métier / Fonctionnel │ ├── Catégories │ ├── Fonctionnalités │ ├── Bénéfices │ ├── FAQ │ ├── Médias │ └── Modules associés │ └── Médias / FAQ / contenus PAGES │ └── SECTIONS ├── Textes ├── Images ├── Cartes ├── CTA ├── Produits ├── Modules └── Formulaires ACTUALITÉS RESSOURCES MÉDIAS MENUS REDIRECTIONS PARAMÈTRES UTILISATEURS Le modèle physique définitif pourra être proposé par le développeur, sous réserve de respecter les règles fonctionnelles du présent cahier des charges. 20. Table products Cette entité contient les produits principaux de WININFO. Exemples actuels : Win@ERP ; Win@WMS. Principaux champs : Champ Type logique Obligatoire id Identifiant technique Oui reference Ex. PROD-001 Oui name Nom du produit Oui slug URL Oui tagline Accroche Oui short_description Description courte Oui content Présentation détaillée Oui main_image_id Média principal Non status Brouillon / publié / archivé Oui display_order Ordre d'affichage Oui published_at Date publication Non created_at Création Oui updated_at Modification Oui Les informations SEO pourront être intégrées à cette table ou externalisées dans une table dédiée. 21. Table modules Elle constitue l'une des tables centrales du site. Principaux champs : Champ Description id Identifiant technique reference Identifiant immuable, ex. MOD-001 product_id Produit de rattachement module_type_id Métier / Fonctionnel name Nom commercial slug Slug public tagline Accroche short_description Présentation synthétique content Présentation détaillée main_image_id Visuel principal featured Module à mettre en avant status Brouillon / publié / archivé display_order Ordre published_at Publication created_at Création updated_at Modification Un module devra pouvoir être rattaché à plusieurs catégories. 22. Relations entre modules Le système devra permettre d'établir des relations entre modules. Exemple : Win@Express Modules associés possibles : Win@Tablette ; Win@Messagerie ; module EDI ; autres modules compatibles. Ces relations permettront d'afficher automatiquement sur une page : Complétez votre solution Découvrez également… Il ne faudra donc pas saisir manuellement ces liens dans le contenu HTML. 23. Fonctionnalités et bénéfices Il est important de distinguer les deux notions. Fonctionnalité Ce que fait le logiciel. Exemple : Affectation d'une mission à un chauffeur et à un véhicule. Bénéfice Ce que cela apporte au client. Exemple : Réduisez les ressaisies et améliorez la réactivité de votre exploitation. Les fiches Produit et Module devront permettre de gérer séparément ces deux types d'informations. Chaque élément pourra comporter : un titre ; une description ; une icône ; un ordre d'affichage ; un statut actif/inactif. 24. Gestion des médias Le back-office disposera d'une médiathèque centralisée. Elle permettra de stocker notamment : photographies ; illustrations ; captures d'écran ; logos ; schémas ; documents téléchargeables. Chaque média devra comporter : référence interne ; fichier original ; titre ; texte alternatif ; légende éventuelle ; type ; dimensions ; poids ; date d'ajout. Le texte alternatif devra être renseignable pour des raisons d'accessibilité et de référencement. Optimisation automatique Lors du dépôt d'une image, le système devra pouvoir générer les formats nécessaires au site. L'objectif sera notamment d'utiliser des formats modernes tels que WebP ou AVIF lorsque cela est pertinent. Le fichier original devra pouvoir être conservé. 25. Référencement des visuels Pour faciliter les échanges avec Codex, AgentNova et la documentation WININFO, les visuels importants pourront recevoir une référence fonctionnelle. Exemple : IMG-GEN-001 Hero principal WININFO IMG-ERP-001 Visuel principal Win@ERP IMG-WMS-001 Visuel principal Win@WMS IMG-MOD-001 Win@Transport IMG-MOD-002 Win@Express IMG-MOD-003 Win@Messagerie IMG-MOD-004 Win@TP ... Cette référence ne sera pas nécessairement visible publiquement. 26. Back-office WININFO Le site devra disposer de sa propre interface d'administration sécurisée. L'objectif n'est pas de construire un CMS généraliste comparable à WordPress. Le back-office doit être simple et directement adapté aux besoins de WININFO. Navigation envisagée : TABLEAU DE BORD CONTENUS ├── Pages ├── Produits ├── Modules ├── Actualités └── Ressources ORGANISATION ├── Types de modules ├── Catégories ├── Menus └── Redirections MÉDIAS └── Médiathèque SITE ├── Paramètres généraux ├── SEO └── Réseaux sociaux ADMINISTRATION ├── Utilisateurs └── Journal 27. Tableau de bord Après authentification, l'utilisateur accède à un tableau de bord simple. Il pourra notamment afficher : Contenus nombre de produits publiés ; nombre de modules métier ; nombre de modules fonctionnels ; pages publiées ; brouillons ; actualités. Actions rapides Ajouter un module Ajouter une actualité Ajouter une ressourceModifier l'accueil On pourra également afficher : Dernières modifications avec l'utilisateur, le contenu concerné et la date. 28. Écran « Modules » L'écran devra être conçu pour devenir réellement pratique lorsque WININFO disposera de plusieurs dizaines de modules. Exemple : Réf. Module Type Catégorie Produit Statut MOD-001 Win@Transport Métier Transport Win@ERP 🟢 Publié MOD-002 Win@Express Métier Transport Win@ERP 🟢 Publié MOD-003 Win@Messagerie Métier Transport Win@ERP 🟢 Publié MOD-010 Win@Trésorerie Fonctionnel Finance Win@ERP 🟡 Brouillon Des filtres devront permettre de sélectionner : Produit · Type · Catégorie · Statut Une recherche permettra également de retrouver rapidement un module. 29. Création d'un module La création devra être volontairement simple. Étape 1 — Identification Nom * [ Win@Trésorerie ] Produit * [ Win@ERP ▼ ] Type * [ Fonctionnel ▼ ] Catégorie [ Finance & Pilotage ▼ ] La référence interne pourra être générée automatiquement. Étape 2 — Présentation Accroche [ __________________________________ ] Description courte [ __________________________________ ] [ __________________________________ ] Présentation [ ] [ ÉDITEUR DE CONTENU ] [ ] Étape 3 — Visuels Image principale [ Choisir dans la médiathèque ] Galerie [ + Ajouter ] Étape 4 — Contenu métier Fonctionnalités Ajouter une fonctionnalité Bénéfices Ajouter un bénéfice FAQ Ajouter une question Étape 5 — Relations Modules complémentaires Rechercher et sélectionner… Étape 6 — SEO Meta Title [ __________________________________ ] Meta Description [ __________________________________ ] Slug /modules/[ win-tresorerie ] Avec aperçu du résultat Google. Étape 7 — Publication Enregistrer le brouillon Prévisualiser Publier 30. Prévisualisation Cette fonction me paraît indispensable. Un administrateur doit pouvoir visualiser une page avant sa publication, même si elle n'est pas accessible publiquement. Exemple : Win@Trésorerie — BrouillonPrévisualiser Le système générera une URL temporaire sécurisée ou réservée aux utilisateurs authentifiés. Cela permettra notamment de valider ensemble les futures fiches avant leur mise en ligne. 31. Historique des modifications Je demanderais une traçabilité minimale. Le système doit mémoriser : création ; modification ; publication ; dépublication ; modification d'URL ; suppression. Avec : date + utilisateur + action + contenu concerné Il n'est pas nécessaire dans la V1 de disposer d'un système complet de versionnement comparable à Git. En revanche, savoir qui a publié ou modifié quoi est important. 32. Corbeille La suppression d'un produit, module, page, actualité ou ressource ne devra pas provoquer immédiatement sa suppression physique. Le contenu passera d'abord dans une corbeille. Cela permettra une restauration en cas d'erreur. Une suppression définitive pourra ensuite être effectuée par un utilisateur disposant des droits nécessaires. 33. Utilisateurs et droits Même si WININFO compte peu d'utilisateurs du back-office, je prévoirais les droits dès la conception. Au minimum : Administrateur Accès complet : contenus ; configuration ; utilisateurs ; menus ; redirections. Éditeur Peut : créer ; modifier ; publier les contenus. Ne peut pas modifier la configuration technique. Contributeur Peut : créer ; modifier ses contenus ; enregistrer en brouillon. Ne peut pas publier. Cela pourrait être intéressant si, par exemple, une personne prépare une actualité ou une nouvelle fiche produit avant validation. 34. Paramètres généraux Les informations communes au site ne doivent jamais être répétées dans chaque page. Le back-office proposera notamment : WININFO raison sociale affichée ; adresse ; téléphone ; email général ; email commercial ; horaires éventuels. Liens Hotline ; Espace client ; CFI ; MobilityScan. Réseaux sociaux LinkedIn ; Facebook ; autres si nécessaires. Identité logo principal ; logo clair ; favicon ; image OpenGraph par défaut. Ainsi, un changement de numéro de téléphone sera réalisé une seule fois. 35. Gestion des menus Le menu ne doit pas être codé en dur. Le back-office permettra de construire : menu principal ; éventuellement menu secondaire ; footer. Un élément pourra être : une page ; un produit ; un module ; une catégorie ; un lien externe ; un sous-menu. Point important Tous les modules ne doivent pas nécessairement apparaître dans le menu principal. Avec plusieurs dizaines de modules, cela deviendrait inutilisable. Le menu pourra mettre en avant les grandes familles et les modules principaux, tandis qu'une page : Tous nos modules permettra d'accéder au catalogue complet. 36. Catalogue des modules Une page dynamique devra afficher l'ensemble des modules publiés. Elle proposera notamment deux grandes entrées : Solutions métiers Des modules conçus autour de votre activité. et : Fonctionnalités complémentaires Enrichissez Win@ERP avec les fonctionnalités dont votre organisation a besoin. Le visiteur pourra filtrer les modules par : Type · Métier/catégorie · Produit et éventuellement utiliser une recherche. 37. Page dynamique d'un module Toutes les pages modules seront générées à partir d'un gabarit commun. Structure de référence : 01 HERO Nom Type de module Accroche Description courte Image CTA 02 LE BESOIN Problématique métier/fonctionnelle 03 LA SOLUTION Présentation du module 04 FONCTIONNALITÉS Cartes dynamiques 05 BÉNÉFICES Gains pour l'entreprise 06 FONCTIONNEMENT Processus / cas d'usage 07 GALERIE Captures ou illustrations 08 MODULES COMPLÉMENTAIRES Relations automatiques 09 FAQ Questions dynamiques 10 CTA FINAL Demande de démonstration / contact Toutes les sections ne seront pas obligatoires. Une section vide ne devra pas apparaître. C'est très important : cela nous permettra de publier rapidement une première fiche simple, puis de l'enrichir progressivement. 38. Page Produit Le principe sera similaire, mais le gabarit Produit sera différent. Pour Win@ERP, par exemple : HERO ↓ Présentation de Win@ERP ↓ Fonctions principales ↓ Solutions métiers ↓ Modules fonctionnels ↓ Combinaison de plusieurs activités ↓ Connectivité / interfaces ↓ Hébergement ↓ Accompagnement WININFO ↓ FAQ ↓ Demande de démonstration Les listes Solutions métiers et Modules fonctionnels devront être générées automatiquement à partir de la base. Lorsque nous publierons un nouveau module Win@ERP, nous pourrons décider s'il apparaît automatiquement sur la page Win@ERP. 39. Statut « À la une » Les produits, modules, actualités et ressources pourront disposer d'un indicateur : ⭐Mettre à la une Cela permettra au site de sélectionner automatiquement certains contenus pour l'accueil. Par exemple, si demain Win@Trésorerie devient une nouveauté importante, tu pourras l'afficher sur l'accueil sans modifier le code de la page. 40. Principe important : contenu ≠ présentation Codex devra respecter une séparation stricte : Base de données→ contenu. Templates PHP→ structure. CSS→ apparence. JavaScript→ interactions. Un texte tel que : « Win@ERP est la solution de gestion modulaire de WININFO… » ne devra pas être inscrit directement dans un template PHP s'il s'agit d'un contenu administrable. Cette séparation est essentielle pour assurer la pérennité du site. À ce stade, le CDC commence à devenir beaucoup plus qu'un cahier des charges de site vitrine : on définit réellement un petit CMS spécialisé WININFO. Et je pense que c'est le bon choix. La prochaine partie que je rédigerais serait maintenant le front-office et l'expérience utilisateur, avec la charte graphique, le header, le mega-menu, le footer, le responsive et surtout la page d'accueil définitive section par section. 41. Principes du front-office Le front-office doit refléter le positionnement de WININFO : Une entreprise technologique proche de ses clients, disposant d'une forte expertise métier et capable de concevoir des solutions adaptées aux organisations qu'elle accompagne. Le site ne doit donner ni l'image : d'un simple revendeur de logiciels ; d'une société de développement généraliste ; d'un site catalogue ; ni d'un site institutionnel froid et impersonnel. Il doit associer quatre dimensions : Expertise métier + Technologie + Accompagnement humain + Innovation L'utilisateur doit rapidement comprendre que WININFO connaît les métiers de ses clients et développe ses propres solutions pour répondre à leurs problématiques. 42. Principes graphiques Le design devra être : moderne ; professionnel ; lumineux ; aéré ; sobre ; dynamique sans être démonstratif ; adapté à une clientèle professionnelle B2B. La nouvelle identité graphique pourra reprendre les couleurs historiques de WININFO tout en les modernisant. Orientation générale Fond principal : Blanc / gris très clair Couleur principale : Bleu-vert / turquoise WININFO Couleur texte : Anthracite très foncé Couleurs secondaires : Nuances dérivées de la couleur principale. Les couleurs exactes seront définies avant développement dans des variables CSS globales. Exemple : :root { --wi-primary: ...; --wi-primary-dark: ...; --wi-primary-light: ...; --wi-text: ...; --wi-text-light: ...; --wi-background: ...; --wi-background-alt: ...; --wi-border: ...; --wi-radius: ...; } Aucune couleur principale ne devra être dispersée en valeur hexadécimale dans les feuilles CSS. 43. Design System WININFO Codex devra créer une petite bibliothèque de composants réutilisables. Elle comprendra au minimum : Typographie H1 ; H2 ; H3 ; H4 ; texte courant ; introduction ; petit texte ; légende. Boutons primaire ; secondaire ; contour ; lien texte. Composants carte Produit ; carte Module ; carte Fonctionnalité ; carte Bénéfice ; carte Actualité ; badge ; CTA ; FAQ ; galerie ; breadcrumb ; formulaire ; message système. Un même type d'information doit avoir la même représentation graphique sur tout le site. 44. Responsive Design Le site sera conçu selon une approche responsive. Trois grandes plages devront au minimum être prévues : Mobile < 768 px Tablette 768 à 1199 px Desktop >= 1200 px Le développement devra néanmoins rester fluide entre ces valeurs. Le site devra être parfaitement utilisable : sur smartphone ; tablette ; ordinateur portable ; écran de bureau. Le responsive ne devra pas consister uniquement à réduire la taille des éléments. L'organisation des contenus pourra être modifiée selon le terminal. Exemple : DESKTOP Texte Image ███████████████████ ███████████████████ MOBILE Texte ████████████████ Image ████████████████ 45. Largeur et respiration Le contenu principal devra disposer d'une largeur maximale commune. Ordre de grandeur envisagé : 1 200 à 1 300 px Les grands fonds pourront occuper 100 % de la largeur de l'écran tandis que le contenu restera aligné dans un conteneur central. Les espaces verticaux devront être généreux. L'objectif est d'éviter l'effet actuel de certaines pages Web où trop d'informations sont concentrées dans un espace réduit. 46. Header Le header devra rester simple et identifiable. Structure desktop envisagée : ┌─────────────────────────────────────────────────────────────┐ │ LOGO Solutions Sur mesure CFI MobilityScan │ │ Ressources À propos Hotline Client │ └─────────────────────────────────────────────────────────────┘ Le logo WININFO sera situé à gauche. À droite pourront apparaître deux accès distinctifs : Hotline Espace client Ils devront être visuellement différenciés de la navigation commerciale. 47. Menu « Solutions » Le menu Solutions sera l'un des éléments les plus importants du site. Compte tenu du nombre de modules, un simple menu déroulant vertical n'est pas adapté. Un mega-menu sera privilégié sur desktop. Exemple fonctionnel : SOLUTIONS ──────────────────────────────────────────────────── NOS PRODUITS Win@ERP La plateforme de gestion modulaire Win@WMS Gestion et pilotage d'entrepôt SOLUTIONS MÉTIERS Transport Travaux Publics Express BTP Messagerie Atelier Logistique Traçabilité → Toutes les solutions métiers FONCTIONNALITÉS COMPLÉMENTAIRES Trésorerie ... → Tous les modules fonctionnels Le contenu du mega-menu devra provenir de la base. Les modules marqués comme « Afficher dans le menu » pourront y être présentés. Cela évitera d'afficher automatiquement 30 ou 40 modules. 48. Menu mobile Sur smartphone, le mega-menu sera remplacé par une navigation adaptée. Exemple : ☰ Solutions › Produits › Solutions métiers › Fonctionnalités complémentaires Développement sur mesure CFI MobilityScan Ressources À propos ──────────── Hotline Espace client Les zones tactiles devront être suffisamment grandes. 49. Header fixe Le header pourra rester visible lors du défilement. Il devra néanmoins réduire légèrement sa hauteur après le début du scroll afin de ne pas occuper inutilement l'écran. Le comportement devra rester discret. 50. Footer Le footer devra également servir d'outil de navigation. Structure envisagée : WININFO Cabinet d'ingénierie informatique [coordonnées] SOLUTIONS Win@ERP Win@WMS Solutions métiers Modules fonctionnels WININFO À propos Développement sur mesure CFI MobilityScan Actualités ASSISTANCE Hotline Espace client Contact LinkedIn Facebook ... ────────────────────────────────── Mentions légales | Confidentialité | Cookies © WININFO Les coordonnées et liens seront issus des paramètres du back-office. 51. Fil d'Ariane Les pages internes devront disposer d'un fil d'Ariane. Exemple : Accueil › Solutions › Modules › Win@Atelier Important : le fil d'Ariane est une aide à la navigation et ne doit pas déterminer l'URL physique de la page. 52. PAGE WEB-P001 — Accueil La page d'accueil constitue la principale vitrine de WININFO. Elle ne doit pas chercher à expliquer toutes les fonctionnalités. Elle doit permettre au visiteur de comprendre : Qui sommes-nous ?Que proposons-nous ?Connaissons-nous son métier ?Pourquoi travailler avec WININFO ?Quelle est la prochaine action ? 53. Accueil — Section 01 : Hero Le slider actuellement présent sur le site de développement ne sera pas repris. Le Hero principal sera fixe. Sur-titre CABINET D'INGÉNIERIE INFORMATIQUE H1 Des solutions de gestion conçues autour de votre métier Texte WININFO conçoit, développe et intègre des solutions de gestion adaptées aux besoins des entreprises du transport, de la logistique, des travaux publics, du BTP et de l'industrie. CTA principal Découvrir nos solutions Lien vers la section Solutions de l'accueil ou la page catalogue. CTA secondaire Parler de votre projet Lien vers le formulaire de contact. Élément de réassurance Plus de 15 ans d'expertise métier et de développement logiciel. Le nombre d'années ne devra idéalement pas être codé en dur si nous souhaitons qu'il évolue automatiquement. 54. Hero — Visuel Le Hero comportera sur desktop : ┌───────────────────────────────────────────────────┐ │ │ │ CABINET D'INGÉNIERIE [VISUEL WININFO] │ │ │ │ Des solutions de gestion │ │ conçues autour de │ │ votre métier │ │ │ │ Texte... │ │ │ │ [Nos solutions] [Votre projet] │ │ │ └───────────────────────────────────────────────────┘ Le visuel devra représenter l'écosystème WININFO plutôt qu'un seul logiciel. Il pourra évoquer : transport ; logistique ; travaux publics ; BTP ; gestion ; mobilité ; applications professionnelles. Il devra éviter l'apparence d'une banque d'images générique. Une illustration spécifique WININFO sera privilégiée. 55. Accueil — Section 02 : Présentation WININFO H2 L'informatique au service de votre métier Contenu Depuis 2007, WININFO accompagne les entreprises dans la conception, l'intégration et l'évolution de leurs solutions de gestion. Notre approche repose sur une conviction simple : ce n'est pas votre entreprise qui doit s'adapter au logiciel, mais le logiciel qui doit accompagner votre organisation et votre métier. Cette section doit installer le positionnement de WININFO avant de présenter les produits. 56. Accueil — Section 03 : Nos solutions H2 Des solutions conçues pour évoluer avec votre entreprise Introduction Nos solutions associent un socle de gestion solide, des fonctionnalités métier et la capacité d'évoluer avec votre organisation. Deux cartes principales seront présentées. Win@ERP Votre gestion d'entreprise adaptée à votre métier Une plateforme de gestion modulaire permettant de centraliser vos activités commerciales, administratives et opérationnelles et d'y associer les modules adaptés à votre activité. CTA : Découvrir Win@ERP Win@WMS Pilotez et optimisez votre entrepôt Une solution dédiée au pilotage des opérations d'entrepôt, de la réception des marchandises jusqu'à leur préparation et leur expédition. CTA : Découvrir Win@WMS Les informations pourront être issues directement des fiches products. 57. Accueil — Section 04 : Vos métiers Cette section est particulièrement importante. H2 Nous connaissons votre métier Introduction Les besoins d'une entreprise de transport ne sont pas ceux d'un atelier, d'un logisticien ou d'une entreprise de travaux publics. C'est pourquoi WININFO développe des modules métier qui adaptent Win@ERP aux réalités de chaque activité. La grille sera alimentée automatiquement par les modules de type Métier marqués « À la une ». Exemples : TransportExpressMessagerieTravaux PublicsLogistiqueAtelierBTPTraçabilité Chaque carte : image ; nom ; courte accroche ; lien vers le module. CTA final : Découvrir toutes nos solutions métiers 58. Accueil — Section 05 : Modules fonctionnels Cette partie introduira une idée importante : Win@ERP ne s'adapte pas uniquement à un métier. Il peut également être enrichi par des fonctions transversales. H2 Ajoutez les fonctionnalités dont vous avez besoin Exemple de présentation : Win@TrésoreriePiloter et anticiper les flux financiers. Facturation électroniquePréparer et automatiser les nouveaux échanges de factures. Et ultérieurement les autres modules fonctionnels. Cette section devra être entièrement dynamique. Si seulement deux modules sont publiés, deux cartes seront affichées. Si dix modules existent, le système pourra n'en présenter que les éléments marqués « À la une » et proposer : Voir toutes les fonctionnalités 59. Accueil — Section 06 : Développement sur mesure Cette partie doit fortement valoriser WININFO. H2 Votre besoin ne rentre pas dans une case ? Texte Toutes les entreprises ont leurs particularités. Lorsque les fonctionnalités existantes ne suffisent pas, notre équipe étudie vos processus et peut concevoir des développements, interfaces ou solutions spécifiques adaptés à votre organisation. Cette capacité à faire évoluer nos solutions fait partie intégrante du savoir-faire WININFO. CTA : Parler de votre besoin Cette section permettra de différencier WININFO des éditeurs proposant uniquement un produit standard figé. 60. Accueil — Section 07 : Écosystème WININFO C'est ici que nous intégrerons CFI et MobilityScan sans donner l'impression qu'ils constituent l'activité principale. H2 Un accompagnement qui va au-delà du logiciel Trois univers pourront être représentés. Solutions WININFO Logiciels de gestion et solutions métier. CFI Formation et accompagnement des utilisateurs. CTA : Découvrir CFI MobilityScan Équipements professionnels et solutions de mobilité adaptés aux usages terrain. CTA : Découvrir MobilityScan Puis depuis la page MobilityScan : Accéder à la boutique Cette organisation permet de montrer que WININFO peut couvrir : Logiciel + Compétences + Matériel C'est un positionnement particulièrement intéressant. 61. Accueil — Section 08 : Pourquoi WININFO ? H2 Un partenaire qui comprend votre organisation Je mettrais ici quatre valeurs principales. Expertise métier Des solutions conçues à partir de problématiques réelles rencontrées sur le terrain. Proximité Une équipe accessible qui connaît ses clients et leur environnement. Évolution Des solutions qui progressent avec les besoins et les métiers. Accompagnement Analyse, déploiement, formation, assistance et amélioration continue. Il ne faudra pas transformer cette section en une succession de slogans marketing génériques. Chaque engagement devra pouvoir être justifié par le fonctionnement réel de WININFO. 62. Accueil — Section 09 : Notre approche Une frise permettra de montrer que WININFO accompagne un projet dans la durée. COMPRENDRE ↓ CONCEVOIR ↓ INTÉGRER ↓ FORMER ↓ ACCOMPAGNER ↓ FAIRE ÉVOLUER Texte Notre intervention ne s'arrête pas à l'installation d'un logiciel. Nous accompagnons chaque solution dans son utilisation et son évolution. 63. Accueil — Section 10 : Actualités et ressources Le site devra pouvoir afficher automatiquement les derniers contenus publiés. Deux types pourront être mélangés ou distingués : Actualités et Ressources Exemple : [ARTICLE] [GUIDE] [ACTUALITÉ] Titre TitreTitre Résumé RésuméRésumé Lire → Télécharger → Lire → Cette section permettra notamment de valoriser les contenus liés à la facturation électronique. 64. Accueil — Section 11 : CTA final La page se terminera par une invitation claire. H2 Parlons de votre projet Texte Vous recherchez une solution de gestion, souhaitez faire évoluer votre système actuel ou avez un besoin métier particulier ? Présentez-nous votre projet. Notre équipe étudiera avec vous la solution la plus adaptée. CTA principal : Nous contacter CTA secondaire : Demander une démonstration 65. Ordre complet de la page Accueil Nous obtenons donc : HEADER │ ├── 01 HERO │ ├── 02 WININFO │ ├── 03 NOS SOLUTIONS │ Win@ERP / Win@WMS │ ├── 04 SOLUTIONS MÉTIERS │ ├── 05 FONCTIONNALITÉS COMPLÉMENTAIRES │ ├── 06 DÉVELOPPEMENT SUR MESURE │ ├── 07 ÉCOSYSTÈME WININFO │ Logiciels / CFI / MobilityScan │ ├── 08 POURQUOI WININFO ? │ ├── 09 NOTRE APPROCHE │ ├── 10 ACTUALITÉS & RESSOURCES │ ├── 11 CTA │ └── FOOTER Je trouve que cette page commence à raconter réellement ce qu'est WININFO aujourd'hui, plutôt que d'empiler les différents produits. 66. Gestion dynamique de l'accueil Un point important pour Codex : l'accueil ne doit pas être figé dans le code. Depuis le back-office, il faudra pouvoir décider par exemple : Afficher la section « Modules fonctionnels » : Oui/NonNombre de modules affichés : 4Source : modules fonctionnels « À la une » Même chose pour : solutions métiers ; actualités ; ressources ; CTA ; CFI ; MobilityScan. Les grands textes institutionnels pourront également être administrables. En revanche, je ne construirais pas un page builder complexe comme Elementor. Ce serait contradictoire avec notre volonté de simplicité. Je préfère que l'administrateur dispose de blocs prédéfinis propres et maîtrisés, qu'il peut paramétrer et ordonner. 67. Préparation des images Nous aurons besoin de constituer un véritable pack média du site avant de remettre le projet à Codex. Je propose une nomenclature de départ : IMG-HOME-001 Hero WININFO IMG-PROD-001 Win@ERP IMG-PROD-002 Win@WMS IMG-MET-001 Transport IMG-MET-002 Express IMG-MET-003 Messagerie IMG-MET-004 TP IMG-MET-005 Logistique IMG-MET-006 Atelier IMG-MET-007 BTP IMG-MET-008 Traçabilité IMG-FCT-001 Trésorerie ... IMG-CFI-001 CFI IMG-MOB-001 MobilityScan IMG-SUR-001 Développement sur mesure On pourra réutiliser certains visuels déjà créés, mais je pense qu'il faudra également produire des versions spécifiquement destinées au Web, plus horizontales et moins chargées en texte. 68. WEB-P002 — Page produit Win@ERP Référence : WEB-P002Type : Page ProduitProduit : Win@ERPURL canonique : /solutions/win-erp/ Objectif de la page La page Win@ERP doit permettre au visiteur de comprendre rapidement que Win@ERP est : une plateforme de gestion complète ; utilisable comme solution de gestion centrale ; modulaire ; adaptable aux différents métiers ; enrichissable par des modules fonctionnels ; évolutive avec l'entreprise ; intégrable au système d'information du client ; accompagnée, hébergée et maintenue par WININFO. Le visiteur ne doit pas percevoir Win@ERP comme une juxtaposition de modules. Le message central est : Win@ERP constitue le socle. Les modules permettent de construire la solution adaptée à l'entreprise. 69. Positionnement commercial Win@ERP doit être présenté comme la plateforme de gestion centrale de WININFO. Il permet de couvrir les fonctions communes de gestion de l'entreprise et d'y associer des modules métier ou fonctionnels. La page doit faire comprendre deux dimensions : WIN@ERP │ ┌──────────────┴──────────────┐ │ │ GESTION D'ENTREPRISE EXTENSIONS WIN@ERP │ │ Clients / Fournisseurs ┌────────┴────────┐ Devis / Commandes │ │ Facturation MODULES MÉTIER MODULES FONCTIONNELS Produits / Services │ │ Stocks │ │ Documents Transport Trésorerie Agenda Express Facturation... Utilisateurs Messagerie GED... Pilotage TP ... Logistique Atelier BTP Traçabilité Ce schéma devra être retravaillé graphiquement pour le site. 70. Section 01 — Hero Win@ERP Sur-titre SOLUTION DE GESTION MODULAIRE H1 Win@ERPVotre gestion d'entreprise adaptée à votre métier Introduction Win@ERP centralise les activités commerciales, administratives et opérationnelles de votre entreprise dans un environnement unique. Sa conception modulaire permet d'y associer les solutions métier et les fonctionnalités dont votre organisation a réellement besoin. Accroche Une seule plateforme. Les modules adaptés à votre entreprise. CTA principal Demander une démonstration CTA secondaire Découvrir les modules Le deuxième CTA fera défiler la page jusqu'à la présentation des modules. Visuel Référence provisoire : IMG-PROD-001 — Win@ERP Le visuel devra évoquer la centralisation des activités et la modularité plutôt qu'une simple capture d'écran. 71. Section 02 — Pourquoi Win@ERP ? H2 Centralisez votre gestion. Simplifiez votre organisation. Introduction À mesure qu'une entreprise se développe, les outils, fichiers et applications ont tendance à se multiplier. Les informations sont dispersées et les mêmes données peuvent être ressaisies plusieurs fois. Win@ERP permet de regrouper les principales informations de gestion dans un environnement commun et de faciliter leur circulation entre les différents services. Quatre bénéfices seront mis en avant. Une information centralisée Clients, fournisseurs, produits, commandes, factures, documents et données métier sont regroupés dans un même environnement. Moins de ressaisies Une information saisie peut être réutilisée par les différents processus et services concernés. Des processus plus fluides Les différentes fonctions de l'entreprise travaillent à partir d'informations communes. Une meilleure visibilité Tableaux de bord et indicateurs facilitent le suivi et le pilotage de l'activité. 72. Section 03 — Le socle Win@ERP Cette section doit éviter une confusion importante : Win@ERP n'est pas uniquement un conteneur de modules. Il possède son propre socle fonctionnel. H2 Un socle complet pour votre gestion quotidienne Les fonctions seront présentées sous forme de cartes. Gestion commerciale prospects ; clients ; contacts ; propositions commerciales ; commandes. Achats & fournisseurs fournisseurs ; commandes fournisseurs ; réceptions ; factures fournisseurs. Facturation & règlements facturation clients ; factures fournisseurs ; règlements ; suivi des échéances. Produits & services catalogue ; tarifs ; produits ; prestations ; stocks lorsque nécessaires. Organisation agenda ; événements ; documents ; utilisateurs ; droits d'accès. Pilotage tableaux de bord ; statistiques ; indicateurs ; imports et exports. Cette liste sera administrable depuis la fiche Produit. 73. Section 04 — La philosophie modulaire Cette section est probablement la plus importante de la page. H2 Votre entreprise est unique. Votre ERP doit s'y adapter. Texte Toutes les entreprises n'ont ni les mêmes métiers, ni les mêmes processus, ni les mêmes besoins. Win@ERP repose sur une architecture modulaire permettant de construire une solution cohérente autour de votre organisation. Vous commencez avec les fonctionnalités dont vous avez besoin aujourd'hui et pouvez faire évoluer votre environnement lorsque votre activité se développe. Message fort Vous n'avez pas à changer de logiciel lorsque votre entreprise évolue. Win@ERP évolue avec elle. 74. Section 05 — Les modules métier H2 Des solutions conçues autour de votre métier Introduction Les modules métier enrichissent Win@ERP avec les processus et fonctionnalités propres à votre activité. Cette partie sera 100 % dynamique. Le système sélectionnera : product = Win@ERP type = Métier status = Publié Les modules actuellement identifiés sont notamment : Win@TransportGestion des activités de transport de marchandises. Win@ExpressGestion des courses directes et du transport express. Win@MessagerieGestion de la messagerie, des tournées et du dernier kilomètre. Win@TPGestion de la location d'engins avec ou sans chauffeur et des transferts de matériels. Win@LogistiqueGestion des prestations logistiques réalisées pour le compte de clients. Win@AtelierGestion de la maintenance d'un parc et des prestations d'atelier. Win@BTPGestion des projets, chantiers et spécificités de facturation du BTP. Win@TraçabilitéGestion de la traçabilité de production et des lots dans la nouvelle génération intégrée à Win@ERP. Le contenu affiché sur les cartes proviendra des fiches modules et non du template Win@ERP. 75. Affichage des modules métier Sur desktop, une grille de cartes sera privilégiée. Chaque carte comportera : visuel ; badge Module métier ; nom ; description courte ; lien. Exemple : ┌───────────────────────────────┐ │ [IMAGE] │ │ │ │ MODULE MÉTIER │ │ Win@Atelier │ │ │ │ Gérez la maintenance, │ │ les réparations et votre │ │ activité atelier. │ │ │ │ Découvrir Win@Atelier → │ └───────────────────────────────┘ La grille ne devra pas être limitée à huit modules. 76. Section 06 — Les modules fonctionnels Cette section introduit la deuxième famille. H2 Ajoutez les fonctionnalités dont votre organisation a besoin Introduction Les modules fonctionnels complètent Win@ERP avec des outils spécialisés qui peuvent être utilisés quel que soit votre métier. Exemple : Win@Trésorerie Centralisez et exploitez les flux nécessaires au suivi et au pilotage de votre trésorerie. D'autres modules seront ajoutés progressivement. La liste sera automatiquement générée avec : product = Win@ERP type = Fonctionnel status = Publié 77. Section 07 — Combinez plusieurs activités Cette section constitue un différenciateur important. H2 Plusieurs activités. Un seul environnement. Texte Une entreprise peut exercer plusieurs métiers. Un transporteur peut par exemple disposer d'une activité Express, assurer des tournées de Messagerie et proposer des prestations Logistiques. Win@ERP permet d'associer plusieurs modules tout en conservant un environnement commun. Illustration fonctionnelle WIN@ERP │ ┌────────────┼────────────┐ │ │ │ EXPRESS MESSAGERIE LOGISTIQUE │ │ │ └────────────┼────────────┘ │ DONNÉES & GESTION COMMUNES Cette illustration devra être conçue sous forme graphique responsive. 78. Cas particulier Win@TP / Win@BTP La complémentarité entre les modules devra pouvoir être expliquée à travers des exemples. Exemple : Une entreprise de BTP peut utiliser Win@BTP pour gérer ses projets et chantiers et compléter son environnement avec Win@TP pour organiser ses propres engins, chauffeurs et interventions. Cette information ne doit pas nécessairement être codée directement dans la page Win@ERP. Le système devra permettre de gérer des cas d'usage ou associations de modules depuis le back-office. Cela pourra être généralisé à d'autres combinaisons. 79. Section 08 — Mobilité terrain Win@Tablette possède un positionnement particulier. Il ne correspond pas complètement à un métier unique et peut être utilisé par plusieurs activités. H2 Reliez le terrain à votre gestion en temps réel Texte Les collaborateurs terrain peuvent recevoir leurs missions et transmettre directement les informations nécessaires à l'exploitation. Selon les modules utilisés, Win@Tablette accompagne les chauffeurs, logisticiens et techniciens dans leurs opérations quotidiennes. Fonctions pouvant être mises en avant : réception des missions ; horodatage ; géolocalisation ; signatures ; photographies ; réserves ; contrôles ; comptes rendus ; transmission des informations. Message bénéfice L'information saisie sur le terrain devient immédiatement disponible pour les équipes concernées. 80. Section 09 — Connectivité H2 Win@ERP s'intègre à votre système d'information Texte Une solution de gestion ne fonctionne pas isolément. Win@ERP peut échanger des données avec les outils, partenaires et plateformes nécessaires à votre activité afin de limiter les ressaisies et d'automatiser les flux. Éléments à représenter : CLIENTS │ ▼ COMPTABILITÉ ◀─────── WIN@ERP ───────▶ FOURNISSEURS │ ┌────────────┼────────────┐ ▼▼▼ EDI API BANQUE │ ▼ PARTENAIRES Les exemples exacts seront ajustés selon les connecteurs réellement commercialisés. 81. EDI L'EDI mérite une mise en avant spécifique dans cette partie. Texte proposé Les échanges EDI permettent d'intégrer automatiquement des commandes, missions ou informations provenant de clients et partenaires et de transmettre les données attendues sans ressaisie manuelle. Le site pourra ultérieurement disposer d'une page ou d'un module fonctionnel dédié à l'EDI. Le lien ne devra donc pas être codé en dur. 82. Section 10 — Facturation électronique Compte tenu de l'évolution réglementaire, cette fonction devra pouvoir être mise en avant sans rendre la page Win@ERP dépendante d'informations susceptibles d'évoluer. H2 Préparez vos échanges de facturation électronique La page Win@ERP présentera seulement une introduction générale. Les détails réglementaires et fonctionnels seront gérés dans une page dédiée, afin de pouvoir les faire évoluer indépendamment. CTA : Découvrir la facturation électronique Cette section devra pouvoir être activée/désactivée depuis le back-office. 83. Section 11 — Hébergement H2 Un environnement hébergé et maîtrisé par WININFO Texte Win@ERP est proposé en hébergement sur les infrastructures gérées par WININFO. Cette organisation permet à nos équipes de maîtriser l'environnement technique nécessaire au fonctionnement, à la maintenance et à l'évolution de la solution. Important Le site ne devra pas afficher de promesses techniques non documentées telles que : « sécurité maximale » ; « disponibilité 99,99 % » ; « sauvegarde temps réel » ; « haute disponibilité » ; sans éléments contractuels permettant de les justifier. 84. Section 12 — L'accompagnement WININFO Cette section doit clairement différencier le logiciel de la prestation WININFO. H2 Un projet ERP ne se résume pas à installer un logiciel Introduction Chaque projet commence par la compréhension de votre activité, de votre organisation et de vos objectifs. Frise : ANALYSER ↓ CONSEILLER ↓ PARAMÉTRER ↓ INTÉGRER ↓ FORMER ↓ ASSISTER ↓ FAIRE ÉVOLUER Texte Les équipes WININFO vous accompagnent depuis l'étude de votre besoin jusqu'à l'utilisation quotidienne de votre solution. 85. Section 13 — Développement spécifique H2 Et lorsque le standard ne suffit pas ? Texte Certaines organisations disposent de processus particuliers qui constituent parfois leur propre valeur ajoutée. Lorsque les fonctionnalités existantes ne permettent pas de répondre correctement à un besoin, WININFO peut étudier la réalisation d'un développement ou d'une interface spécifique. CTA : Parler de mon besoin Lien vers la page Développement sur mesure. 86. Section 14 — Une solution évolutive H2 Commencez avec vos besoins d'aujourd'hui. Préparez ceux de demain. Texte Nouveau métier, nouveau collaborateur, nouveau processus, automatisation ou connexion avec un nouvel outil : votre système de gestion doit pouvoir accompagner les évolutions de votre entreprise. L'architecture modulaire de Win@ERP permet d'enrichir progressivement votre environnement sans reconstruire l'ensemble de votre système de gestion. 87. Section 15 — FAQ Win@ERP La FAQ sera entièrement administrable. Premières questions proposées : Win@ERP peut-il être utilisé sans module métier ? Oui. Win@ERP dispose de son propre socle de gestion et peut être utilisé indépendamment des modules métier. Peut-on utiliser plusieurs modules métier ? Oui. Plusieurs modules peuvent être associés au même environnement afin de couvrir différentes activités de l'entreprise. Peut-on ajouter un module plus tard ? Oui. La conception modulaire permet de faire évoluer la solution avec les besoins de l'entreprise. Win@ERP peut-il communiquer avec d'autres logiciels ? Selon les besoins, des imports, exports, API, échanges EDI ou interfaces spécifiques peuvent être mis en œuvre. Où est hébergé Win@ERP ? Win@ERP est proposé en hébergement sur les infrastructures gérées par WININFO. 88. Section 16 — CTA final H2 Construisons le Win@ERP adapté à votre entreprise Texte Présentez-nous votre activité, votre organisation et vos besoins. Nous étudierons avec vous les fonctionnalités et modules adaptés à votre projet. CTA principal Demander une démonstration CTA secondaire Nous contacter 89. Structure complète WEB-P002 La page cible sera donc : HEADER │ ├── 01 HERO │ ├── 02 POURQUOI WIN@ERP ? │ ├── 03 SOCLE DE GESTION │ ├── 04 PHILOSOPHIE MODULAIRE │ ├── 05 MODULES MÉTIER │ ├── 06 MODULES FONCTIONNELS │ ├── 07 PLUSIEURS ACTIVITÉS │ ├── 08 MOBILITÉ TERRAIN │ ├── 09 CONNECTIVITÉ / EDI │ ├── 10 FACTURATION ÉLECTRONIQUE │ ├── 11 HÉBERGEMENT │ ├── 12 ACCOMPAGNEMENT WININFO │ ├── 13 DÉVELOPPEMENT SPÉCIFIQUE │ ├── 14 ÉVOLUTIVITÉ │ ├── 15 FAQ │ ├── 16 CTA │ └── FOOTER Cela paraît long sur le papier, mais toutes les sections n'auront pas la même taille. Certaines seront des blocs visuels très courts. 90. Administration spécifique de Win@ERP Je voudrais ajouter quelque chose au back-office que nous n'avions pas encore prévu : la possibilité de choisir les modules mis en avant sur la page Produit. Pour chaque relation Produit ↔ Module : actif pour ce produit ; ordre ; afficher sur la page Produit ; afficher dans le mega-menu ; mettre à la une ; éventuellement texte spécifique de présentation. Cela nous donne beaucoup de souplesse sans modifier le code. 91. Point important : Win@Traçabilité Le site doit considérer le futur Win@Traçabilité comme un module de Win@ERP. L'ancien produit autonome développé sous Visual FoxPro ne doit pas être présenté comme un produit actuel de la nouvelle gamme. Toutefois, pendant la période de transition, il faudra décider si le site doit expliquer que la nouvelle version succède à une solution historique WININFO. Je ne mettrais pas cette information en avant commercialement tant que ce n'est pas utile au prospect. 92. Win@Tablette : classification à prévoir Notre modèle Métier / Fonctionnel révèle ici un cas intéressant. Win@Tablette n'est pas réellement un module métier comme Win@Express, mais ce n'est pas non plus simplement une fonction comme Win@Trésorerie. Je pense qu'il faut donc prévoir dès maintenant un troisième type de module : TRANSVERSAL On aurait alors : MÉTIERAdapte Win@ERP à une activité. FONCTIONNELAjoute une fonctionnalité. TRANSVERSALApporte un service ou une capacité utilisable par plusieurs modules métier. Win@Tablette serait le premier exemple évident. Et probablement que EDI pourrait également entrer dans cette catégorie selon la manière dont nous déciderons de le commercialiser. Je trouve cette classification plus fidèle à l'architecture réelle de Wininfo que de forcer tous les modules dans seulement deux catégories. 93. WEB-P003 — Page produit Win@WMS Référence : WEB-P003Type : Page ProduitProduit : Win@WMSURL canonique : /solutions/win-wms/ Objectif de la page La page doit présenter Win@WMS comme une solution spécialisée de gestion et de pilotage des opérations d'entrepôt. Le visiteur doit comprendre que la solution accompagne les marchandises sur l'ensemble du cycle : Réception → Stockage → Mouvements → Préparation → Expédition → Inventaire Win@WMS est un produit autonome. Il ne doit donc pas être présenté comme un module de Win@ERP. Il peut néanmoins être interfacé avec Win@ERP ou avec le système de gestion utilisé par l'entreprise. 94. Positionnement de Win@WMS Le message central proposé est : Pilotez votre entrepôt, de la réception à l'expédition. Win@WMS doit être présenté comme l'outil opérationnel permettant de : connaître les marchandises présentes ; connaître leur emplacement ; organiser les mouvements ; guider les opérations ; fiabiliser les préparations ; suivre les expéditions ; réaliser les inventaires ; assurer la traçabilité des opérations. Le site devra privilégier une présentation par flux logistique plutôt qu'une longue liste de fonctionnalités. 95. Section 01 — Hero Sur-titre SOLUTION DE GESTION D'ENTREPÔT H1 Win@WMSPilotez et optimisez les opérations de votre entrepôt Introduction Win@WMS accompagne et coordonne les opérations logistiques, de la réception des marchandises jusqu'à leur préparation et leur expédition. Stocks, emplacements, mouvements et opérations terrain sont centralisés dans un environnement conçu pour faciliter le travail quotidien des équipes. CTA principal Demander une démonstration CTA secondaire Découvrir le fonctionnement Visuel Référence : IMG-PROD-002 — Win@WMS Le visuel devra associer : entrepôt ; racks ; palettes ou marchandises ; terminal mobile ; information numérique. Il devra donner l'impression d'une interaction entre le logiciel et l'entrepôt réel. 96. Section 02 — Le besoin H2 Gardez la maîtrise de chaque mouvement Texte Dans un entrepôt, la fiabilité du stock dépend de la qualité des opérations réalisées au quotidien. Une réception mal enregistrée, un déplacement non tracé, une erreur d'emplacement ou une mauvaise préparation peut rapidement créer des écarts et perturber toute la chaîne logistique. Win@WMS permet de structurer et de tracer les opérations afin que le stock informatique reste cohérent avec la réalité du terrain. 97. Section 03 — Le cycle logistique Cette section devra être très visuelle. H2 Un seul outil pour piloter le cycle de l'entrepôt Schéma : RÉCEPTION ↓ CONTRÔLE ↓ MISE EN STOCK ↓ STOCKAGE ↓ MOUVEMENTS ↓ PRÉPARATION ↓ EXPÉDITION ↕ INVENTAIRES Sur desktop, le développeur pourra privilégier une représentation horizontale. Sur mobile, elle deviendra verticale. Chaque étape pourra être sélectionnable et conduire à la partie correspondante de la page. 98. Section 04 — Réception H2 Réceptionnez et contrôlez les marchandises La réception constitue le point d'entrée du stock. La solution devra être présentée autour de fonctions telles que : identification des marchandises ; contrôle des quantités ; enregistrement de la réception ; affectation des emplacements ; traçabilité des opérations. Le texte détaillé de cette section devra rester administrable afin d'être adapté aux fonctionnalités effectivement disponibles dans la version commercialisée. 99. Section 05 — Organisation des emplacements H2 Structurez votre entrepôt Win@WMS doit permettre de représenter l'organisation physique du stockage. Le site pourra illustrer une structure du type : ENTREPÔT │ ├── ZONE │ │ │ ├── ALLÉE │ │ │ │ │ ├── RACK │ │ │ │ │ │ │ └── EMPLACEMENT L'objectif commercial est simple : Savoir ce qui est stocké et où le trouver. 100. Section 06 — Stock et mouvements H2 Suivez votre stock au fil des opérations Les mouvements réalisés dans l'entrepôt devront alimenter le suivi du stock. Exemples : entrée ; sortie ; transfert ; déplacement ; correction ; inventaire. Le visiteur doit comprendre que Win@WMS ne fournit pas uniquement une quantité théorique : il accompagne les opérations qui expliquent l'évolution du stock. 101. Section 07 — Préparation H2 Fiabilisez vos préparations Cette partie présentera le processus de préparation des marchandises avant expédition. Selon les fonctions effectivement disponibles, la fiche Produit pourra faire apparaître : ordres de préparation ; localisation des articles ; quantités à prélever ; validation des prélèvements ; regroupement ; contrôle avant expédition. Le détail sera piloté depuis la base. 102. Section 08 — Expédition H2 Préparez vos marchandises au départ Le processus d'expédition doit assurer la continuité entre la préparation et la sortie effective des marchandises. Le site pourra notamment présenter : validation des marchandises préparées ; sortie de stock ; informations d'expédition ; transmission aux systèmes concernés ; échanges avec les transporteurs lorsqu'une interface existe. 103. Section 09 — Inventaires H2 Contrôlez la réalité de votre stock Texte Les opérations d'inventaire permettent de comparer le stock enregistré avec les marchandises réellement présentes dans l'entrepôt et d'identifier les éventuels écarts. La page pourra distinguer, si la solution les gère : inventaire global ; inventaire partiel ; inventaire tournant. Là encore, aucune fonction non confirmée ne devra être ajoutée automatiquement par le développeur. 104. Section 10 — Mobilité Cette section est importante pour différencier un WMS d'une simple gestion de stock administrative. H2 Le WMS accompagne les opérateurs sur le terrain Texte Les opérations peuvent être réalisées au plus près des marchandises à l'aide d'équipements mobiles adaptés à l'environnement de l'entrepôt. Selon les équipements et fonctions retenus : lecture de codes-barres ; identification des produits ; identification des emplacements ; réception ; déplacement ; préparation ; inventaire. Le visuel devra montrer un terminal professionnel en situation d'utilisation, et non simplement un smartphone grand public. 105. Section 11 — Traçabilité des opérations H2 Retrouvez l'historique des opérations L'objectif est de permettre d'identifier : le mouvement réalisé ; la marchandise concernée ; l'emplacement ; la date et l'heure ; l'opérateur lorsque cette information est disponible. Cette partie devra rester suffisamment générique pour ne pas annoncer un niveau de traçabilité supérieur à celui réellement fourni par le produit. 106. Section 12 — Connexion avec le système de gestion Cette section est essentielle pour bien positionner Win@WMS. H2 Connectez l'entrepôt à votre système d'information Texte Win@WMS peut fonctionner comme solution spécialisée de pilotage de l'entrepôt tout en échangeant les informations nécessaires avec le système de gestion de l'entreprise. Schéma conceptuel : SYSTÈME DE GESTION / \ / \ Win@ERP ERP tiers \ / \ / ↕ ÉCHANGES │ WIN@WMS │ OPÉRATIONS ENTREPÔT Le site pourra citer des systèmes tiers réellement supportés dans les contenus administrables, mais le template ne devra contenir aucune dépendance à un éditeur particulier. 107. Section 13 — EDI transporteurs H2 Automatisez les échanges avec vos partenaires Lorsque les interfaces correspondantes sont mises en œuvre, Win@WMS peut échanger avec les systèmes des transporteurs ou partenaires concernés. L'objectif est notamment de réduire les ressaisies et de fluidifier le passage entre préparation et expédition. Cette section devra pouvoir être activée ou masquée depuis le back-office. 108. Section 14 — MobilityScan Ici, le lien avec MobilityScan devient particulièrement naturel. H2 Des équipements adaptés aux opérations terrain Texte WININFO peut également accompagner les entreprises dans le choix des équipements mobiles nécessaires à l'utilisation de leurs solutions logistiques : terminaux professionnels, lecteurs et matériels adaptés aux usages terrain. CTA : Découvrir MobilityScan Puis la page MobilityScan dirigera vers la boutique en ligne. Cela permet de montrer une capacité intéressante de WININFO : Logiciel + intégration + matériel sans transformer la page Win@WMS en boutique. 109. Section 15 — Accompagnement WININFO H2 Un WMS doit correspondre à la réalité de votre entrepôt Texte La mise en œuvre d'une solution de gestion d'entrepôt nécessite de comprendre l'organisation des zones, les flux de marchandises et les méthodes de travail des opérateurs. WININFO accompagne le projet depuis l'analyse du fonctionnement de l'entrepôt jusqu'au déploiement et à l'utilisation de la solution. Frise possible : ANALYSE DES FLUX ↓ ORGANISATION ↓ PARAMÉTRAGE ↓ INTERFACES ↓ DÉPLOIEMENT ↓ FORMATION ↓ ACCOMPAGNEMENT 110. Section 16 — FAQ Win@WMS Première base administrable : Win@WMS peut-il fonctionner sans Win@ERP ? Oui. Win@WMS constitue une solution indépendante de gestion d'entrepôt et peut être interfacée avec Win@ERP ou avec d'autres systèmes de gestion. Quelle est la différence entre Win@WMS et Win@Logistique ? C'est une question que je mettrais absolument dans la FAQ, car elle permettra de lever une confusion naturelle. Win@WMS est une solution spécialisée de pilotage des opérations et du stock d'un entrepôt. Win@Logistique est un module de Win@ERP destiné à gérer une activité de prestations logistiques réalisée pour le compte de clients. Cette formulation pourra être affinée lors de la rédaction définitive des fiches. Peut-on utiliser des terminaux mobiles ? Oui, les opérations terrain peuvent être réalisées avec des équipements mobiles adaptés aux fonctions mises en œuvre. Win@WMS peut-il communiquer avec un autre ERP ? Des interfaces peuvent être mises en œuvre afin d'échanger les informations nécessaires avec le système de gestion de l'entreprise. 111. CTA final H2 Étudions ensemble les flux de votre entrepôt Texte Présentez-nous votre organisation, vos volumes et vos processus logistiques. Nous pourrons étudier avec vous la mise en œuvre d'une solution adaptée à votre environnement. CTA principal : Demander une démonstration CTA secondaire : Nous contacter 112. Structure complète WEB-P003 HEADER │ ├── 01 HERO ├── 02 LE BESOIN ├── 03 CYCLE LOGISTIQUE ├── 04 RÉCEPTION ├── 05 EMPLACEMENTS ├── 06 STOCK & MOUVEMENTS ├── 07 PRÉPARATION ├── 08 EXPÉDITION ├── 09 INVENTAIRES ├── 10 MOBILITÉ ├── 11 TRAÇABILITÉ ├── 12 INTERFAÇAGE ERP ├── 13 EDI TRANSPORTEURS ├── 14 MOBILITYSCAN ├── 15 ACCOMPAGNEMENT ├── 16 FAQ ├── 17 CTA │ └── FOOTER 113. Une distinction importante dans notre modèle de données En rédigeant Win@WMS, je vois une amélioration intéressante à apporter au back-office. Il ne suffit pas de définir : Produit → Modules Il faut également pouvoir définir des relations entre tous les contenus. Par exemple : Win@WMS │ ├── associéà→ MobilityScan ├── peut être interfacé avec → Win@ERP ├── contenu associé→ EDI └── ressource associée → Guide WMS Je créerais donc un mécanisme générique de contenus associés. Cela nous permettra ensuite de faire apparaître automatiquement les bons contenus en bas des pages sans écrire les relations dans le PHP. 114. Point à ne pas oublier : Win@Logistique ≠ Win@WMS Je pense que cette distinction devra être très claire sur le futur site. Nous avons deux propositions différentes : Win@Logistique→ module métier de Win@ERP pour une entreprise réalisant des prestations logistiques pour des clients. Win@WMS→ produit spécialisé dans le pilotage opérationnel d'un entrepôt et de son stock. On pourra même créer plus tard une petite page ou un encart : Win@Logistique ou Win@WMS : quelle solution correspond à votre activité ? Cela peut être très utile commercialement et également intéressant pour le référencement. 115. Gabarit générique des modules Maintenant que les deux produits principaux sont définis, je pense qu'il ne faut surtout pas rédiger Win@Transport, puis Win@Express, puis Win@Atelier comme 10 pages indépendantes dans le CDC. On va faire mieux. La prochaine partie sera : WEB-TPL-MOD-001 — Gabarit générique d'une page Module Ce gabarit définira une seule fois toute la structure d'une page module. Ensuite, nous créerons pour chaque module une fiche de contenu, par exemple : WEB-MOD-001 — Win@TransportWEB-MOD-002 — Win@ExpressWEB-MOD-003 — Win@MessagerieWEB-MOD-004 — Win@TPWEB-MOD-005 — Win@LogistiqueWEB-MOD-006 — Win@AtelierWEB-MOD-007 — Win@BTPWEB-MOD-008 — Win@TraçabilitéWEB-MOD-009 — Win@TabletteWEB-MOD-010 — Win@Trésorerie Et les futurs modules utiliseront exactement le même mécanisme. 116. WEB-TPL-MOD-001 — Gabarit générique d'une page Module Référence : WEB-TPL-MOD-001Type : Gabarit dynamiqueObjet : Présentation publique d'un moduleURL type : /modules/{slug}/ Objectif Le gabarit Module constitue le modèle commun utilisé pour générer automatiquement les pages de tous les modules enregistrés dans le back-office. Aucune page PHP spécifique ne devra être créée lors de l'ajout d'un nouveau module. Exemples : /modules/win-transport/ /modules/win-express/ /modules/win-atelier/ /modules/win-tracabilite/ /modules/win-tresorerie/ utiliseront tous le même moteur de rendu. Le contenu, les visuels et les sections affichées dépendront exclusivement des informations enregistrées dans la base de données. 117. Les trois types de modules Le gabarit doit prendre en charge les trois classifications définies dans le CDC. Module métier Il répond aux besoins d'une activité ou d'un secteur. Exemples : Win@Transport ; Win@Express ; Win@Messagerie ; Win@TP ; Win@Logistique ; Win@Atelier ; Win@BTP ; Win@Traçabilité. Module fonctionnel Il ajoute une fonction spécialisée à Win@ERP. Exemple : Win@Trésorerie. Module transversal Il apporte une capacité utilisable par plusieurs modules ou métiers. Exemple : Win@Tablette. Le type devra pouvoir être affiché sous forme de badge : MODULE MÉTIER MODULE FONCTIONNEL MODULE TRANSVERSAL Le libellé proviendra de la base et ne sera pas codé en dur. 118. Rattachement à Win@ERP Les modules actuellement concernés sont rattachés à Win@ERP. La page devra clairement faire comprendre cette relation. Exemple : Module de Win@ERP Le visiteur doit comprendre que Win@Transport ou Win@Trésorerie n'est pas un logiciel isolé. Le nom du produit de rattachement devra être cliquable : Module de Win@ERP → /solutions/win-erp/ Cette relation sera générée depuis product_id. 119. Structure générale Le gabarit de référence comprendra les sections suivantes : HEADER │ ├── FIL D'ARIANE │ ├── 01 HERO ├── 02 LE BESOIN ├── 03 PRÉSENTATION ├── 04 FONCTIONNALITÉS ├── 05 BÉNÉFICES ├── 06 FONCTIONNEMENT / PROCESSUS ├── 07 CAS D'USAGE ├── 08 GALERIE ├── 09 MODULES COMPLÉMENTAIRES ├── 10 RESSOURCES ASSOCIÉES ├── 11 FAQ ├── 12 CTA │ └── FOOTER Toutes les sections ne sont pas obligatoires. Une section sans contenu ne devra jamais générer une zone vide. 120. Section 01 — Hero Module Le Hero constitue la carte d'identité du module. Il comportera : produit de rattachement ; type de module ; nom ; accroche ; description courte ; image principale ; CTA. Exemple : MODULE DE WIN@ERPMODULE FONCTIONNEL Win@Trésorerie Pilotez et anticipez votre trésorerie Centralisez les informations nécessaires au suivi de vos encaissements, décaissements et prévisions de trésorerie. CTA principal : Demander une démonstration CTA secondaire éventuel : Nous contacter 121. Adaptation du Hero selon le type Le gabarit restera identique, mais le discours pourra varier. Pour un module métier : Une solution adaptée à votre activité. Pour un module fonctionnel : Une fonctionnalité complémentaire pour enrichir votre gestion. Pour un module transversal : Une capacité commune à plusieurs activités. Ces formulations devront idéalement rester administrables. 122. Section 02 — Le besoin Cette section répond à : Quel problème le module permet-il de résoudre ? Elle est particulièrement importante commercialement. Exemple Win@Trésorerie : Suivre sa trésorerie à partir de fichiers, d'extraits bancaires et d'informations dispersées rend difficile l'anticipation des besoins financiers. Win@Trésorerie permet de regrouper les informations nécessaires au suivi des flux dans l'environnement de gestion de l'entreprise. Exemple Win@Atelier : Entre les demandes d'intervention, les réparations, les véhicules immobilisés, les pièces et les techniciens, la gestion quotidienne d'un atelier nécessite une vision claire des opérations en cours. Cette zone devra accepter : titre ; introduction ; texte ; éventuellement une illustration. 123. Section 03 — Présentation de la solution Titre par défaut Une solution intégrée à Win@ERP Le titre pourra être personnalisé. Cette partie explique comment le module répond au besoin précédemment exposé. Elle ne devra pas être une simple répétition de la description courte du Hero. La logique éditoriale sera : PROBLÈME ↓ RÉPONSE WININFO ↓ FONCTIONNEMENT ↓ BÉNÉFICES 124. Section 04 — Fonctionnalités Les fonctionnalités seront issues de la base de données. Chaque fonctionnalité pourra comporter : icône ; titre ; description ; ordre ; statut. Exemple : ┌─────────────────────┐ │ [ICÔNE] │ │ │ │ Suivi des échéances │ │ │ │ Description... │ └─────────────────────┘ Le nombre de fonctionnalités ne devra pas être limité artificiellement. L'affichage s'adaptera automatiquement. 125. Fonctionnalités principales et secondaires Je rajouterais une notion que nous n'avions pas encore définie. Une fonctionnalité pourra être marquée : Principale Cela permettra de mettre en avant les 4 à 6 fonctions essentielles sans afficher immédiatement une liste de 20 éléments. Exemple : Fonctionnalités principales [Carte] [Carte] [Carte] [Carte] [Carte] [Carte] Voir toutes les fonctionnalités ↓ Cette possibilité sera particulièrement utile pour les modules importants comme Win@Transport. 126. Section 05 — Bénéfices Cette section doit être distincte des fonctionnalités. Titre Ce que Win@[Module] apporte à votre organisation Exemples de bénéfices : réduire les ressaisies ; centraliser les informations ; améliorer la visibilité ; fiabiliser les opérations ; faciliter le suivi ; gagner du temps. Les bénéfices seront administrables individuellement. Codex ne devra jamais déduire automatiquement un bénéfice d'une fonctionnalité. 127. Section 06 — Fonctionnement / Processus Certains modules se comprennent beaucoup mieux par leur processus. Exemple Win@Atelier : DEMANDE D'INTERVENTION ↓ ORDRE DE RÉPARATION ↓ PLANIFICATION ↓ INTERVENTION ↓ PIÈCES / TEMPS ↓ CLÔTURE ↓ FACTURATION si nécessaire Exemple Win@Transport : COMMANDE ↓ ORGANISATION ↓ PLANIFICATION ↓ AFFECTATION ↓ EXÉCUTION ↓ SUIVI ↓ FACTURATION Le back-office devra donc permettre de gérer une liste ordonnée d'étapes. 128. Représentation des processus Une étape pourra comporter : titre ; description ; icône ; ordre. Sur desktop : ① ───── ② ───── ③ ───── ④ Sur mobile : ① │ ② │ ③ │ ④ Le composant devra être responsive. 129. Section 07 — Cas d'usage Certains modules peuvent répondre à plusieurs situations. Le back-office permettra de créer des cas d'usage. Exemple Win@Atelier : Atelier interne Gestion de la maintenance et des réparations du parc de l'entreprise. Prestations pour des tiers Gestion des interventions réalisées et facturées pour des clients. Autre exemple pour Win@Logistique : Stockage Préparation Prestations logistiques Ces cas d'usage devront rester facultatifs. 130. Section 08 — Galerie Les captures d'écran ont une réelle valeur pour nos logiciels. Le module pourra disposer d'une galerie comprenant : captures d'écran ; photos ; schémas ; illustrations. Chaque élément comportera : image ; titre ; légende ; texte alternatif ; ordre. Sur desktop, un clic pourra ouvrir une visualisation agrandie. Sur mobile, l'affichage devra être adapté au tactile. 131. Gestion des captures d'écran Les captures d'écran de logiciels peuvent contenir beaucoup d'informations. Le système devra donc conserver une version suffisamment grande pour permettre une consultation détaillée. Les miniatures utilisées dans la page seront optimisées afin de ne pas charger inutilement l'image originale. Le clic ouvrira une version haute définition dans une lightbox. 132. Section 09 — Modules complémentaires Cette section sera générée à partir des relations définies dans le back-office. H2 Complétez votre solution Exemple pour Win@Transport : Win@TabletteWin@Trésorerieautres modules compatibles. Chaque module associé apparaîtra sous forme de carte. La relation devra pouvoir être bidirectionnelle ou unidirectionnelle. Exemple : Win@Transport ↓ recommande ↓ Win@Tablette ne signifie pas nécessairement que la page Win@Tablette doive automatiquement recommander Win@Transport. 133. Section 10 — Ressources associées Cette section permettra de valoriser le futur contenu éditorial du site. Exemples : fiche produit PDF ; guide ; article ; vidéo ; documentation commerciale ; actualité ; cas client. Le back-office permettra d'associer ces ressources au module. La page pourra afficher : Pour aller plus loin avec les ressources correspondantes. 134. Section 11 — FAQ Chaque module pourra disposer de sa propre FAQ. Les questions seront administrables. L'affichage utilisera un composant accordéon accessible. Exemple : Win@Atelier permet-il de gérer le parc interne ?Réponse… Les FAQ pourront également être exploitées pour le référencement structuré lorsque cela est pertinent et conforme aux règles des moteurs de recherche. 135. Section 12 — CTA final Toutes les pages modules devront se terminer par une action claire. Titre générique possible : Découvrez comment Win@[Module] peut s'adapter à votre organisation Texte : Présentez-nous votre activité et vos besoins. Notre équipe pourra vous accompagner dans l'étude de votre projet. CTA : Demander une démonstration et éventuellement : Nous contacter Le formulaire devra savoir depuis quelle page la demande provient. C'est important. Si le prospect clique depuis Win@Atelier, la demande enregistrée devra contenir : Origine : WEB-MOD-006 Module : Win@Atelier URL : /modules/win-atelier/ 136. Formulaire contextualisé Je formaliserais cette fonction dès maintenant. Lorsqu'un CTA ouvre le formulaire de contact ou de démonstration, le site transmettra automatiquement : page source ; produit éventuel ; module éventuel ; type de demande. Exemple : Demande : Démonstration Produit : Win@ERP Module : Win@Trésorerie Origine : Page Win@Trésorerie Le visiteur n'aura pas à ressaisir ces informations. 137. SEO des modules Chaque module disposera : d'une URL canonique ; d'un ; d'une Meta Description ; d'un H1 unique ; d'une image OpenGraph ; d'un texte alternatif pour les images. Exemple : URL /modules/win-atelier/ Title Win@Atelier - Logiciel de gestion d'atelier | WININFO Le titre SEO devra être administrable et non généré obligatoirement selon cette formule. 138. Partage AgentNova Cette partie reprend notre exigence précédente. Dans le back-office : URL publique https://www.wininfo.fr/modules/win-atelier/ [ Copier l'URL ] Cette adresse sera utilisée dans la fiche correspondante AgentNova. Une fois publiée, elle devra être considérée comme pérenne. 139. Prévisualisation Un module en brouillon devra pouvoir être prévisualisé. Exemple : Win@Trésorerie STATUT : BROUILLON [ Prévisualiser ] [ Publier ] La prévisualisation ne devra pas être indexable par les moteurs de recherche. 140. Publication incomplète Je rajouterais une protection intéressante. Le back-office devra vérifier avant publication la présence des informations minimales : nom ; slug ; produit ; type ; accroche ; description courte ; image principale ; Meta Title ; Meta Description. Si une information obligatoire manque : ⚠ Cette fiche n'est pas prête à être publiée. Mais elle pourra toujours être enregistrée en brouillon. 141. Indicateur de complétude On pourrait aller un peu plus loin avec un indicateur simple : Fiche Win@Trésorerie Complétude : 75 % ✓ Identification ✓ Présentation ✓ Image ✓ Fonctionnalités ⚠ Aucun bénéfice ✓ SEO ⚠ Aucune FAQ Les éléments non obligatoires ne bloquent pas la publication. Cette fonction serait très pratique lorsque vous ajouterez progressivement les nombreux modules déjà développés. 142. Un seul gabarit, plusieurs niveaux de contenu C'est un principe important du projet. Une fiche module pourra être très simple : Hero Présentation Fonctionnalités CTA ou beaucoup plus complète : Hero Besoin Présentation Fonctionnalités Bénéfices Processus Cas d'usage Galerie Modules associés Ressources FAQ CTA Le même gabarit devra gérer les deux situations. Ainsi, nous ne serons pas obligés de rédiger immédiatement une page extrêmement complète pour chacun des dizaines de modules existants. 143. Création rapide d'un module Je prévoirais même dans le back-office : + Création rapide avec uniquement : Nom Produit Type Catégorie Description courte Image → Créer en brouillon La fiche pourra ensuite être enrichie. Cela répond parfaitement à ton problème initial : vous avez déjà beaucoup de modules qui ne sont actuellement pas représentés sur le site. 144. Héritage du produit Enfin, une page Module pourra récupérer certaines informations du produit parent. Exemple : Win@Transport → Win@ERP. Il n'est donc pas nécessaire de répéter sur toutes les fiches : certaines informations d'hébergement ; certains CTA ; certains éléments d'accompagnement ; certains éléments de marque. Le gabarit pourra utiliser les paramètres hérités de Win@ERP, sauf lorsqu'une valeur spécifique est définie sur le module. Principe : VALEUR MODULE ? │ OUI│ NON │ │ ▼▼ MODULE PRODUIT Cela évitera beaucoup de duplication de contenu. 145. Conclusion du gabarit Module WEB-TPL-MOD-001 doit permettre à WININFO de publier un nombre important de modules tout en conservant : une identité graphique homogène, une structure commerciale cohérente, des URL pérennes, et surtout aucune dépendance à un développement supplémentaire pour créer une nouvelle page module. CDC-WEB-001 — Suite 146. WEB-P004 — Développement sur mesure Référence : WEB-P004Type : Page institutionnelle / commercialeURL canonique : /developpement-sur-mesure/ Objectif Cette page doit présenter la capacité de WININFO à analyser un besoin spécifique et à concevoir une réponse adaptée lorsque les fonctionnalités standards des solutions existantes ne suffisent pas. Elle doit également montrer que le développement sur mesure ne signifie pas systématiquement créer un logiciel entièrement nouveau. Il peut s'agir : d'une évolution d'une solution WININFO ; d'un nouveau module ; d'une automatisation ; d'une interface avec un logiciel tiers ; d'un échange de données ; d'une application métier spécifique ; d'une adaptation d'un processus existant. Le message central sera : Votre organisation a ses particularités. Vos outils doivent pouvoir les accompagner. 147. Section 01 — Hero Sur-titre DÉVELOPPEMENT SUR MESURE H1 Transformons vos besoins métier en solutions concrètes Introduction Lorsqu'une solution standard ne répond pas complètement à votre organisation, WININFO analyse vos processus et conçoit les développements nécessaires pour adapter, connecter ou enrichir votre système d'information. CTA Parler de mon projet Visuel : IMG-SUR-001 Il devra évoquer analyse + métier + développement, et éviter l'image cliché d'un écran rempli de code. 148. Section 02 — Partir du besoin H2 Le développement commence par la compréhension de votre métier Texte Avant de parler de technologie, nous cherchons à comprendre le fonctionnement de votre entreprise, les utilisateurs concernés, les informations manipulées et le résultat attendu. Cette analyse permet de déterminer s'il est préférable de paramétrer une fonction existante, d'adapter une solution, de créer un module ou de développer une interface spécifique. C'est important commercialement : WININFO ne doit pas donner l'impression de vouloir développer systématiquement quelque chose dès qu'un client exprime un besoin. 149. Section 03 — Types de projets H2 Des développements adaptés à différents besoins Cartes administrables : Évolution d'une solution WININFO Ajouter ou adapter une fonctionnalité à un environnement existant. Nouveau module métier Concevoir un module répondant à un processus ou à une activité particulière. Interface entre logiciels Faire circuler les informations entre plusieurs applications afin de limiter les ressaisies. Automatisation Automatiser des opérations répétitives ou des traitements de données. Application spécifique Concevoir une solution dédiée lorsqu'un besoin ne peut pas être couvert correctement par les outils existants. Mobilité Étendre certains processus aux collaborateurs terrain lorsque cela est nécessaire. 150. Section 04 — Notre méthode H2 Une démarche structurée, du besoin à la mise en service Processus : ÉCOUTER ↓ ANALYSER ↓ SPÉCIFIER ↓ CONCEVOIR ↓ DÉVELOPPER ↓ TESTER ↓ DÉPLOYER ↓ ACCOMPAGNER Chaque étape pourra disposer d'une description. Le site doit montrer que le développement n'est pas seulement une activité de programmation. 151. Section 05 — Intégration au système existant H2 Faire évoluer l'existant plutôt que tout reconstruire Texte Une entreprise dispose déjà de logiciels, de données, d'habitudes et de processus. Lorsque cela est pertinent, WININFO privilégie l'intégration avec l'environnement existant : API, imports, exports, EDI ou interfaces spécifiques permettent de connecter les différents outils. Schéma possible : WIN@ERP │ ┌────────────┼────────────┐ │ │ │ ▼▼▼ LOGICIEL CLIENT PARTENAIRE TIERS │ │ └────────────┼──────────────┘ │ ÉCHANGES DE DONNÉES 152. Section 06 — Du spécifique au module Cette partie me paraît particulièrement intéressante pour WININFO. H2 Un besoin client peut parfois devenir une solution métier Texte Certains modules WININFO sont issus de besoins concrets rencontrés auprès de nos clients. Lorsqu'une problématique présente un intérêt plus large, une évolution spécifique peut devenir une fonctionnalité ou un module pouvant bénéficier à d'autres entreprises confrontées au même besoin. Cela montre une logique d'innovation issue du terrain sans entrer dans des considérations techniques internes. 153. Section 07 — Accompagnement dans le temps H2 Un développement doit pouvoir vivre et évoluer Texte La mise en production n'est pas la fin du projet. Les usages évoluent, les métiers changent et de nouveaux besoins apparaissent. WININFO peut accompagner les évolutions fonctionnelles et techniques des solutions mises en place. CTA : Nous présenter un besoin 154. WEB-P005 — CFI Référence : WEB-P005Type : Page activitéURL canonique proposée : /formation/ CFI doit apparaître comme une activité de l'écosystème WININFO tout en conservant son identité propre. Objectifs La page permettra : de présenter CFI ; d'expliquer l'activité de formation ; de présenter les formations ; d'orienter vers les contenus correspondants ; de présenter la location de salle si cette activité est maintenue ; de faciliter les demandes d'information. 155. CFI — Hero Sur-titre CFI — FORMATION H1 Développez les compétences de vos équipes Introduction CFI accompagne les entreprises et leurs collaborateurs dans l'acquisition et le développement de compétences à travers des actions de formation adaptées à leurs besoins. CTA : Découvrir nos formations CTA secondaire : Nous contacter Le contenu définitif pourra être adapté à la présentation institutionnelle actuelle de CFI. 156. CFI — Les formations Le système devra permettre de présenter des formations sous forme de fiches dynamiques. Je ne créerais pas nécessairement dès la V1 un véritable logiciel de gestion de formation dans le site. En revanche, une fiche pourra contenir : intitulé ; catégorie ; objectifs ; public ; prérequis ; programme ; durée ; modalités ; image ; document PDF ; contact ; statut. Cela évitera de devoir créer manuellement une nouvelle page lorsqu'une formation est ajoutée. 157. Relation entre solutions et formations Une formation pourra être associée à un produit ou à un module. Exemple : Formation Win@Atelier │ └── liée à → Win@Atelier La page Win@Atelier pourra alors éventuellement afficher : Formation associée et la fiche formation pourra afficher : Solution concernée : Win@Atelier Ce mécanisme utilisera le système général de contenus associés défini précédemment. 158. CFI — Location de salle Si l'activité est conservée, une section ou une page spécifique permettra de présenter : la salle ; sa capacité ; ses équipements ; les services disponibles ; les photographies ; les modalités de demande. CTA : Demander des informations Les tarifs, s'ils sont affichés, devront être administrables. 159. CFI — Identité graphique CFI pourra utiliser : son propre logo ; certaines couleurs spécifiques ; ses propres visuels. Cependant, l'utilisateur devra toujours comprendre qu'il se trouve dans l'écosystème WININFO. Le site ne devra donc pas charger un design complètement différent. Le Header et le Footer principaux resteront cohérents avec wininfo.fr. 160. WEB-P006 — MobilityScan Référence : WEB-P006Type : Page activité / passerelle commercialeURL canonique : /mobilityscan/ Objectif Cette page ne constitue pas une boutique en ligne. La vente des produits reste assurée par le site marchand MobilityScan. La page wininfo.fr a pour fonction : d'expliquer l'activité MobilityScan ; de présenter les grandes familles de matériels ; de montrer le lien entre matériel et solutions WININFO ; de diriger vers le site marchand. 161. MobilityScan — Hero H1 Les équipements professionnels adaptés à vos usages terrain Texte MobilityScan complète l'expertise logicielle de WININFO en proposant des équipements de mobilité et d'identification adaptés aux environnements professionnels. CTA principal : Accéder à la boutique MobilityScan Le lien sera externe et administrable. 162. MobilityScan — Familles de matériels La page pourra présenter des familles et non le catalogue complet. Par exemple : terminaux mobiles ; lecteurs codes-barres ; tablettes professionnelles ; imprimantes ; accessoires ; autres équipements. Ces catégories devront pouvoir être administrées. Important Les prix, stocks et références commerciales ne seront pas dupliqués sur wininfo.fr. La boutique MobilityScan reste la source commerciale correspondante. 163. MobilityScan — Relation avec les solutions WININFO H2 Le logiciel et le matériel pensés ensemble Texte Dans les environnements terrain, le choix du matériel est directement lié aux usages : mobilité, lecture de codes-barres, conditions d'utilisation, autonomie ou ergonomie. WININFO peut accompagner ses clients dans le choix des équipements adaptés aux solutions mises en œuvre. Cette section pourra notamment être reliée à : Win@WMS ; Win@Tablette ; Win@Logistique ; Win@Traçabilité ; d'autres solutions utilisant du matériel terrain. 164. WEB-P007 — Actualités URL : /actualites/ Les actualités seront administrables depuis le back-office. Une actualité comportera : référence ; titre ; slug ; résumé ; contenu ; image principale ; auteur ; date ; catégorie ; contenus associés ; SEO ; statut. 165. Page liste des actualités La page affichera les actualités publiées par ordre chronologique décroissant. Elle devra proposer : image ; date ; catégorie ; titre ; résumé ; lien « Lire la suite ». Une pagination sera prévue. Le nombre d'articles par page sera configurable. 166. Actualités associées Une actualité pourra être reliée à : un produit ; un module ; CFI ; MobilityScan ; une thématique. Exemple : Nouvelle réglementation Facturation électronique │ └── associée à → Win@ERP La page Win@ERP pourra ainsi afficher automatiquement certaines actualités pertinentes. 167. WEB-P008 — Ressources URL : /ressources/ La notion de ressource sera distincte d'une actualité. Une ressource est un contenu ayant vocation à rester utile dans le temps. Exemples : guide ; fiche pratique ; livre blanc ; fiche produit ; document PDF ; vidéo ; tutoriel ; documentation commerciale. 168. Fiche Ressource Une ressource comportera : référence ; titre ; type ; description ; image ; contenu éventuel ; fichier éventuel ; lien externe éventuel ; produits/modules associés ; statut ; SEO. Le système devra pouvoir gérer : RESSOURCE INTERNE → page du site DOCUMENT → téléchargement RESSOURCE EXTERNE → lien 169. Téléchargements Pour les documents proposés en téléchargement, le système devra pouvoir conserver : fichier ; nom public ; type MIME ; taille ; date de mise à jour. Le site pourra afficher par exemple : Fiche de présentation Win@ERPPDF — 2,4 Mo Le téléchargement ne devra jamais révéler le chemin physique réel du serveur. 170. Facturation électronique Je créerais une thématique forte dans les ressources plutôt que de figer toutes les informations réglementaires dans Win@ERP. URL proposée : /facturation-electronique/ Cette page pourra évoluer indépendamment du produit. Elle pourra présenter : principes de la réforme ; calendrier ; préparation des entreprises ; fonctionnement avec les solutions WININFO ; ressources ; actualités ; FAQ. Ainsi, lorsqu'une règle réglementaire change, nous modifions une seule page de référence. 171. WEB-P009 — Contact URL : /contact/ Le formulaire Contact sera commun à plusieurs parcours. Champs proposés société ; nom ; prénom ; email ; téléphone ; objet ; message. Le formulaire recevra également des données contextuelles invisibles : URL source ; produit ; module ; campagne éventuelle ; type de demande. 172. Types de demandes Je prévoirais une liste administrable. Exemples : Demande d'information ; Demande de démonstration ; Projet de développement ; Formation ; MobilityScan ; Autre. Cela facilitera ultérieurement le routage des demandes. 173. Formulaire de démonstration Une demande de démonstration ne doit pas nécessairement afficher exactement les mêmes champs qu'un contact général. Exemple : Société * Nom * Prénom * Email * Téléphone Solution concernée [ Win@ERP ] Module [ Win@Atelier ] Votre besoin [ ] [ Demander une démonstration ] Si l'utilisateur arrive depuis Win@Atelier : Solution = Win@ERP Module = Win@Atelier seront automatiquement renseignés. 174. Traitement des formulaires Le traitement doit être réalisé côté serveur. Les contrôles JavaScript amélioreront l'expérience utilisateur mais ne constitueront jamais la seule validation. Le système devra notamment contrôler : champs obligatoires ; format email ; longueurs ; valeurs autorisées ; données contextuelles ; protection CSRF ; soumissions automatisées. 175. Destination des demandes Pour la V1, les demandes pourront être envoyées par email à une ou plusieurs adresses configurées dans le back-office. Mais je prévoirais dès maintenant une abstraction : FORMULAIRE │ ├── EMAIL │ └── CONNECTEUR FUTUR │ ├── Win@ERP ├── CRM └── Win@AI / autre Cela évitera que le contrôleur du formulaire contienne directement une logique d'envoi figée. 176. Enregistrement des demandes Je recommande également d'enregistrer les demandes dans la base avant l'envoi de l'email. Le back-office pourra disposer d'une rubrique : Demandes Web avec : date ; société ; contact ; type ; produit ; module ; statut. Statuts possibles : NOUVELLE TRAITÉE ARCHIVÉE Cela permet de ne pas dépendre exclusivement d'un email. 177. Consentement et données personnelles Les formulaires devront comporter une information claire sur l'utilisation des données. Une case de consentement ne devra être utilisée que lorsqu'elle est juridiquement nécessaire selon la finalité concernée. Le texte de confidentialité et le lien vers la politique correspondante devront être administrables. Les données collectées devront être limitées à celles nécessaires au traitement de la demande. 178. Anti-spam Le système devra intégrer une protection contre les soumissions automatisées. Je privilégierais une approche peu intrusive : champ honeypot ; contrôle du temps de soumission ; limitation du nombre de requêtes ; validation serveur. Un CAPTCHA externe ne devra être ajouté que si cela devient nécessaire. 179. Messages de confirmation Après soumission réussie : Votre demande a bien été transmise. Notre équipe reviendra vers vous dans les meilleurs délais. Le texte devra être administrable. Le système ne devra pas confirmer l'envoi si l'enregistrement ou la transmission a échoué. 180. Erreurs En cas d'erreur : Votre demande n'a pas pu être transmise. Les informations techniques détaillées ne devront jamais être affichées au visiteur. L'erreur sera enregistrée dans les logs. 181. Hotline La Hotline ne doit pas être confondue avec le formulaire commercial. Le bouton Hotline du Header dirigera vers le dispositif d'assistance défini par WININFO. Son URL devra être un paramètre global administrable. Ainsi, le système pourra évoluer sans modifier le Header. 182. Espace client Même principe pour Espace client. Le lien sera stocké dans les paramètres du site. Il pourra pointer vers une application externe. Le site institutionnel n'a pas vocation à reproduire les fonctions de l'espace client. 183. Liens externes CFI, MobilityScan, Hotline ou Espace client pourront comporter des liens vers d'autres domaines ou applications. Les liens externes devront être identifiables dans le back-office. Pour les liens ouvrant un nouvel onglet, les attributs de sécurité appropriés devront être appliqués. 184. Page 404 Le site disposera d'une véritable page 404. H1 Cette page n'existe pas ou n'est plus disponible Elle proposera : retour Accueil ; Nos solutions ; recherche éventuelle ; Contact. Si l'URL correspond à une ancienne adresse connue, la redirection 301 devra intervenir avant l'affichage de la 404. 185. Recherche interne Vu le nombre futur de modules et de ressources, je pense qu'il faut prévoir une recherche interne. Elle pourra rechercher au minimum dans : produits ; modules ; pages ; actualités ; ressources. Elle ne recherchera pas dans les contenus non publiés. 186. Résultats de recherche URL proposée : /recherche/?q=transport Les résultats indiqueront leur nature : MODULE — Win@TransportRESSOURCE — Guide…ACTUALITÉ — … Le moteur pourra rester simple en V1 : recherche SQL correctement indexée sur les principaux champs. Il n'est pas nécessaire d'introduire Elasticsearch ou un moteur externe. 187. Architecture fonctionnelle désormais obtenue À ce stade, le site commence à former un véritable écosystème : WININFO.FR │ ┌───────────────────┼───────────────────┐ │ │ │ SOLUTIONS SERVICES CONTENUS │ │ │ Win@ERP / WMS Sur mesure Actualités │ Formation Ressources Modules CFI │ │ MobilityScan Facturation │ électronique └───────────────────┬───────────────────┘ │ CONTACT / CTA │ DEMANDES WEB Et surtout, toutes ces briques restent administrables et reliables entre elles. 189. Référencement naturel — SEO Le futur site devra être conçu dès l'origine pour permettre un référencement naturel correct. Le SEO ne devra pas être ajouté après le développement sous forme d'une surcouche. Il devra faire partie du fonctionnement normal du moteur du site. Les éléments SEO seront gérés depuis le back-office pour tous les contenus publics concernés : produits ; modules ; pages institutionnelles ; actualités ; ressources ; formations ; pages thématiques. 190. Champs SEO Chaque contenu indexable pourra disposer au minimum des champs suivants : Titre SEO Meta Description URL / Slug URL canonique Image OpenGraph Indexation autorisée : Oui / Non Le back-office affichera un aperçu simple : Win@Atelier - Logiciel de gestion d'atelier | WININFO https://www.wininfo.fr/modules/win-atelier/ Gérez les demandes d'intervention, les ordres de réparation... L'administrateur conservera la maîtrise des valeurs. 191. Valeurs SEO par défaut Lorsqu'aucune valeur spécifique n'est renseignée, le système pourra utiliser des règles de repli. Exemple : Titre SEO spécifique ? │ OUI │ NON │ ▼ Nom du contenu + " | WININFO" Même principe pour l'image OpenGraph. En revanche, aucun texte marketing ou Meta Description ne devra être inventé automatiquement. 192. Hiérarchie des titres Chaque page devra respecter une structure HTML cohérente. Principes : un H1 principal ; H2 pour les grandes sections ; H3 pour les sous-sections ; pas de titres utilisés uniquement pour leur apparence graphique. Exemple : H1 Win@Atelier H2 Gérez votre activité atelier H3 Demandes d'intervention H3 Ordres de réparation H3 Planification H2 Les bénéfices H2 Questions fréquentes Le CSS gérera l'apparence ; le HTML conservera la structure sémantique. 193. URLs Les URLs devront rester : lisibles ; courtes ; stables ; sans identifiant technique visible ; sans extension .php. Exemples : /solutions/win-erp/ /solutions/win-wms/ /modules/win-atelier/ /modules/win-tresorerie/ /actualites/facturation-electronique-entreprises/ /ressources/guide-facturation-electronique/ À éviter : /module.php?id=17 /page.php?ref=WIN_ATELIER 194. URL canonique Chaque contenu indexable devra déclarer son URL canonique. Cette fonction sera particulièrement importante lorsqu'un contenu peut être accessible depuis plusieurs parcours. Le moteur devra éviter que plusieurs URLs différentes retournent volontairement la même page publique sans gestion canonique ou redirection appropriée. 195. Modification d'un slug Comme défini précédemment, la modification d'un slug devra provoquer automatiquement : création de la nouvelle URL ; conservation de l'ancienne ; création d'une redirection HTTP 301 ; mise à jour de l'URL canonique ; journalisation de l'opération. Exemple : ANCIENNE /modules/tresorerie/ 301 ↓ NOUVELLE /modules/win-tresorerie/ Cette règle est également essentielle pour les liens utilisés dans AgentNova. 196. Sitemap XML Le site générera automatiquement : /sitemap.xml Le sitemap contiendra uniquement les contenus : publiés ; indexables ; disposant d'une URL publique valide. Les contenus en brouillon, supprimés ou désindexés ne devront pas apparaître. Si le volume le justifie ultérieurement, le système pourra générer plusieurs fichiers Sitemap. 197. Robots.txt Le site fournira un fichier : /robots.txt Il devra permettre l'indexation du front-office tout en évitant notamment l'exploration des zones administratives. Les environnements DEV et TEST devront être configurés différemment de la production. 198. Environnements hors production C'est un point très important. Le futur site de développement ne devra pas être indexé. Sur DEV et TEST : noindex, nofollow devra être appliqué globalement. Le robots.txt complétera cette protection, mais ne sera pas considéré comme le seul mécanisme. La mise en production devra permettre d'activer explicitement l'indexation. 199. Données structurées Lorsque cela est pertinent, le site pourra générer des données structurées Schema.org. Priorités : Organization ; BreadcrumbList ; Article pour les actualités ; types adaptés aux contenus lorsque leur usage est justifié. Le moteur ne devra pas ajouter automatiquement des données structurées correspondant à des informations inexistantes. 200. OpenGraph et partage Les pages publiques devront fournir les métadonnées nécessaires au partage sur les principaux réseaux et outils de messagerie. Au minimum : og:title og:description og:image og:url og:type Une image par défaut WININFO pourra être utilisée lorsqu'aucune image spécifique n'est définie. 201. Page 404 et SEO Une page inexistante devra réellement retourner : HTTP 404 et pas 200 OK. De même : redirection permanente → 301 ; page normale → 200 ; erreur serveur → code 5xx approprié. Codex devra respecter les codes HTTP et ne pas simplement afficher des pages visuellement différentes. 202. Accessibilité Le site devra viser un niveau d'accessibilité raisonnable conforme aux bonnes pratiques Web modernes. L'accessibilité devra être prise en compte dès la création des composants. Elle concernera notamment : navigation clavier ; contraste ; formulaires ; menus ; boutons ; images ; modales ; accordéons ; galerie ; messages d'erreur. 203. Navigation clavier Les fonctions essentielles devront être utilisables sans souris. L'utilisateur devra pouvoir : parcourir le menu ; ouvrir les sous-menus ; accéder aux liens ; utiliser les formulaires ; ouvrir/fermer une FAQ ; fermer une lightbox ; atteindre les CTA. L'indicateur de focus ne devra pas être supprimé par CSS. 204. Images et textes alternatifs Les images porteuses d'information devront disposer d'un texte alternatif pertinent. Le champ alt sera administrable dans la médiathèque. Une image purement décorative devra pouvoir être identifiée comme telle afin de ne pas générer une description inutile pour les technologies d'assistance. 205. Formulaires accessibles Chaque champ devra disposer d'un véritable label associé. À éviter : [ Votre email... ] comme seule indication. Préférer : Adresse email * [ ] Les erreurs devront identifier précisément le champ concerné. Exemple : Veuillez renseigner une adresse email valide. 206. Responsive — règles générales Le site devra fonctionner sur : smartphone ; tablette ; ordinateur portable ; écran desktop. Le responsive ne devra provoquer : aucun défilement horizontal involontaire ; aucune superposition de texte ; aucun bouton inaccessible ; aucune image dépassant de son conteneur. Les tableaux, lorsqu'ils existent, devront disposer d'un comportement adapté aux petits écrans. 207. Images responsive Les images devront être servies dans des dimensions adaptées à leur contexte. Le système devra éviter d'envoyer systématiquement une image de plusieurs milliers de pixels à un smartphone. Les formats modernes pourront être utilisés lorsque l'environnement le permet. Le système devra conserver l'original pour les besoins de la médiathèque et produire des variantes optimisées pour le front-office. 208. Performance La performance fait partie des exigences fonctionnelles du site. Le développement devra limiter : dépendances JavaScript ; bibliothèques inutiles ; fichiers CSS multiples non nécessaires ; images non optimisées ; requêtes SQL répétitives ; chargement de ressources inutilisées. Le choix actuel de PHP/HTML/CSS/JS sans framework lourd est cohérent avec cet objectif. 209. Chargement JavaScript Le contenu essentiel d'une page ne devra pas dépendre entièrement de JavaScript. Les textes, titres et liens principaux devront être présents dans le HTML généré côté serveur. JavaScript sera utilisé pour les interactions : menu mobile ; accordéons ; lightbox ; animations raisonnables ; autres composants interactifs. 210. Lazy Loading Les images situées sous la ligne de flottaison pourront utiliser le chargement différé. En revanche, l'image principale du Hero ne devra pas être inutilement retardée lorsqu'elle constitue un élément important de l'affichage initial. 211. Cache L'architecture devra permettre la mise en cache des ressources statiques : CSS ; JavaScript ; images ; polices éventuelles. Le versionnement des assets devra permettre d'invalider le cache après une mise à jour. Exemple : /app.css?v=2026.08.1 ou système équivalent. 212. Sécurité applicative Le back-office et le front-office devront suivre les principes fondamentaux de sécurité Web. Les contrôles seront réalisés côté serveur. Les données provenant : des formulaires ; des URLs ; du back-office ; des paramètres ; des uploads seront considérées comme non fiables jusqu'à validation. 213. Requêtes SQL Toutes les données dynamiques devront utiliser des requêtes préparées PDO. Aucune concaténation directe d'une donnée utilisateur dans une requête SQL ne sera autorisée. 214. Protection XSS Les contenus affichés devront être échappés selon leur contexte. Une distinction devra être faite entre : texte simple ; URL ; attribut HTML ; contenu HTML volontairement autorisé. Si le back-office permet du HTML enrichi, le contenu devra être filtré selon une liste maîtrisée de balises et attributs autorisés. 215. Protection CSRF Toutes les actions modifiant des données devront être protégées contre les attaques CSRF. Cela concerne notamment : création ; modification ; suppression ; publication ; formulaires publics ; changement de mot de passe. 216. Sessions administrateur Les sessions du back-office devront utiliser des cookies configurés avec les protections appropriées. Notamment selon l'environnement : HttpOnly Secure SameSite L'identifiant de session devra être renouvelé après authentification. Une déconnexion devra invalider correctement la session. 217. Mots de passe Les mots de passe ne devront jamais être stockés en clair. PHP devra utiliser les mécanismes standards : password_hash() password_verify() Le premier administrateur de production ne devra pas conserver le mot de passe de démonstration utilisé pendant le développement. 218. Protection de l'administration Le répertoire logique /admin/ ne devra jamais permettre l'accès à une page protégée sans authentification. La sécurité devra être appliquée au niveau du contrôleur/router et non uniquement par masquage des liens dans l'interface. 219. Uploads Les fichiers envoyés depuis le back-office devront faire l'objet de contrôles : extension ; type MIME ; taille maximale ; nom du fichier ; destination autorisée. Le nom fourni par l'utilisateur ne devra pas être utilisé directement comme nom physique sur le serveur. Les fichiers exécutables ne devront pas pouvoir être téléversés dans une zone publique exécutable. 220. Journalisation de sécurité Les événements importants pourront être journalisés : connexion réussie ; échec de connexion ; déconnexion ; changement de mot de passe ; publication ; suppression ; modification de configuration. Les logs ne devront jamais contenir de mot de passe ou secret. 221. Messages d'erreur En production, aucune erreur technique détaillée ne devra être affichée au visiteur. À éviter : PDOException... SQLSTATE... /var/www/html/app/... Le visiteur recevra un message générique. Les informations techniques seront enregistrées dans les logs. En DEV, un mode de diagnostic plus détaillé pourra être activé. 222. Configuration et secrets Les informations sensibles ne devront pas être versionnées dans Git. Exemples : mot de passe MariaDB ; identifiants SMTP ; clés API ; secrets futurs. Le projet devra utiliser des variables d'environnement ou un fichier local exclu du dépôt. Le mécanisme déjà prévu pour la configuration MariaDB va dans cette direction. 223. RGPD Le site devra respecter le principe de minimisation des données. WININFO ne collectera que les informations nécessaires à la finalité du formulaire ou du service concerné. Chaque traitement devra pouvoir être documenté. 224. Politique de confidentialité Une page publique devra présenter les informations nécessaires concernant les traitements de données du site. URL proposée : /confidentialite/ Le contenu juridique définitif sera fourni ou validé par WININFO. Le développeur ne devra pas inventer les mentions juridiques. 225. Cookies Le site devra distinguer : Cookies strictement nécessaires Exemple : session administrateur ; sécurité ; fonctionnement indispensable. Cookies non nécessaires Exemple potentiel : mesure d'audience externe ; marketing ; vidéos ou services tiers déposant des traceurs. Le comportement du bandeau dépendra des services réellement activés sur le futur site. 226. Pas de bandeau inutile Si le site ne dépose que des cookies strictement nécessaires, il ne faudra pas afficher artificiellement un énorme bandeau « Accepter les cookies ». Si des traceurs soumis au consentement sont ajoutés, le mécanisme correspondant devra être mis en œuvre. Cette règle évite de développer dès maintenant une usine à gaz dont nous n'avons peut-être pas besoin. 227. Statistiques Le système de statistiques devra être choisi ultérieurement. Le site ne devra pas dépendre techniquement de Google Analytics ou d'un service particulier. L'outil pourra être ajouté via la configuration globale ou un mécanisme maîtrisé d'intégration de scripts. 228. Sauvegardes Les éléments nécessaires à la restauration du site devront être identifiés séparément : CODE → Git BASE DE DONNÉES → MariaDB MÉDIAS / UPLOADS → stockage fichiers CONFIGURATION → environnement sécurisé La sauvegarde du dépôt Git ne constitue donc pas à elle seule une sauvegarde du site. 229. Environnements Je formaliserais trois environnements : DEV Développement TEST / RECETTE Validation avant production PROD www.wininfo.fr Chaque environnement disposera de sa propre configuration et de sa propre base. Aucune base de production ne devra être utilisée directement pour les développements. 230. Docker Le projet devra pouvoir être exécuté dans l'environnement Docker WININFO. Le dépôt ne devra pas dépendre : d'un chemin absolu du poste d'un développeur ; d'une configuration locale non documentée ; d'une extension PHP exotique non identifiée. Les prérequis devront être documentés. 231. Configuration par environnement Les éléments suivants devront notamment pouvoir varier sans modifier le code : APP_ENV APP_URL DB_HOST DB_PORT DB_NAME DB_USER DB_PASSWORD MAIL_HOST MAIL_PORT MAIL_USER MAIL_PASSWORD INDEXING_ENABLED LOG_LEVEL Les noms exacts pourront être adaptés à la convention déjà utilisée par Codex. 232. Déploiement Le déploiement devra être reproductible. Il ne devra pas nécessiter de modifier manuellement plusieurs fichiers PHP après chaque mise en ligne. Le processus devra être documenté. Exemple conceptuel : Git ↓ Déploiement ↓ Configuration environnement ↓ Base / migrations ↓ Permissions ↓ Tests ↓ Mise en service 233. Évolution du schéma de base C'est un point que j'ajouterais maintenant que Codex a déjà créé le premier schéma. Une fois le site utilisé, il ne sera plus acceptable de réexécuter un schema.sql destructif à chaque évolution. Le projet devra disposer d'un mécanisme de migrations de base de données versionnées. Exemple : 001_initial_schema.sql 002_module_features.sql 003_content_relations.sql 004_web_requests.sql Le système devra savoir quelles migrations ont déjà été appliquées. 234. Mise à jour sans perte de données Une nouvelle version du site ne devra jamais nécessiter de supprimer puis recréer la base de production. Les évolutions du modèle devront préserver : produits ; modules ; textes ; médias ; utilisateurs ; demandes ; SEO ; redirections. C'est une exigence fondamentale. 235. Migration de l'ancien site Avant la mise en production, un inventaire des URLs actuellement indexées sur www.wininfo.fr devra être réalisé. Pour chaque ancienne URL : ANCIENNE URL │ ├── contenu repris │ ↓ │ NOUVELLE URL │ ↓ │ 301 │ └── contenu supprimé ↓ décision spécifique On ne remplacera donc pas simplement l'ancien site du jour au lendemain sans cartographie des URLs. 236. Table de migration des URLs Une table de travail devra être constituée avant bascule. Exemple : Ancienne URL Nouvelle URL Action ancienne page ERP /solutions/win-erp/ 301 ancienne page WMS /solutions/win-wms/ 301 ancienne actualité conservée nouvelle URL 301 contenu sans équivalent à décider 410/301 selon cas Cette table pourra ensuite alimenter le mécanisme de redirections du back-office. 237. Aucun lien cassé après migration Avant la mise en production, un contrôle automatique devra rechercher : liens internes cassés ; images absentes ; ressources introuvables ; redirections incorrectes ; boucles de redirection. Le remplacement de l'ancien site devra viser à conserver au maximum la continuité des liens existants. 238. Recette fonctionnelle La recette devra vérifier les fonctionnalités décrites dans le CDC. Les tests seront organisés par domaine : FRONT-OFFICE BACK-OFFICE CONTENUS FORMULAIRES SEO RESPONSIVE SÉCURITÉ PERFORMANCES MIGRATION 239. Test critique — création d'un module Ce test sera obligatoire avant validation. Scénario Connexion au back-office. Création d'un module fictif. Rattachement à Win@ERP. Type : Fonctionnel. Ajout d'une image. Ajout de fonctionnalités. Ajout d'un processus. Ajout d'une FAQ. Configuration SEO. Publication. Résultat attendu Une nouvelle page publique doit être disponible sans création ni modification d'un fichier PHP. C'est le test fondamental de l'architecture retenue. 240. Test critique — modification du slug Scénario Publier : /modules/module-test/ puis modifier le slug : /modules/nouveau-module-test/ Résultat attendu L'ancienne adresse retourne : 301 vers la nouvelle. La nouvelle retourne : 200 L'URL canonique correspond à la nouvelle adresse. 241. Test critique — brouillon Un module en brouillon : ne doit pas apparaître dans le catalogue ; ne doit pas apparaître dans le menu ; ne doit pas apparaître dans la recherche ; ne doit pas apparaître dans le Sitemap ; ne doit pas être indexable. Une prévisualisation authentifiée doit néanmoins être possible. 242. Test critique — suppression La suppression depuis le back-office devra respecter la logique de corbeille définie dans le CDC. Une suppression accidentelle ne devra pas immédiatement détruire définitivement les contenus associés. La restauration devra être testée. 243. Test responsive Les pages principales seront au minimum contrôlées sur : smartphone ; tablette ; desktop. Les tests devront notamment vérifier : Header ; mega-menu ; cartes ; formulaires ; images ; processus ; FAQ ; Footer ; galeries. 244. Compatibilité navigateurs Le site devra fonctionner correctement sur les versions modernes des principaux navigateurs : Chrome ; Edge ; Firefox ; Safari. Il n'est pas demandé de supporter d'anciens navigateurs obsolètes. 245. Recette des formulaires Seront notamment testés : formulaire valide ; champ obligatoire absent ; email invalide ; double soumission ; protection CSRF ; spam élémentaire ; erreur SMTP ; enregistrement en base ; contexte Produit/Module ; affichage du message de confirmation. 246. Recette back-office Le back-office devra notamment permettre de vérifier : création ; modification ; duplication ; brouillon ; publication ; archivage/corbeille ; restauration ; recherche ; tri ; médias ; relations ; SEO ; menus ; redirections ; journal. 247. Documentation technique Le dépôt devra contenir une documentation permettant à un autre développeur de reprendre le projet. Au minimum : README.md avec : prérequis ; installation ; configuration ; base de données ; lancement ; structure des dossiers ; migrations ; déploiement ; gestion des environnements. 248. Documentation du modèle de données Le modèle de données devra être documenté. Je demanderais à Codex de fournir un schéma simple des principales relations : PRODUCT │ └── MODULE │ ├── FEATURES ├── BENEFITS ├── PROCESS STEPS ├── FAQ ├── MEDIA └── RELATIONS ainsi que les tables communes : USERS MENUS PAGES NEWS RESOURCES REDIRECTS WEB_REQUESTS AUDIT_LOG 249. Documentation back-office Une courte documentation utilisateur devra également être prévue. Elle expliquera notamment : créer un module ; publier une fiche ; ajouter une image ; modifier le SEO ; créer une actualité ; créer une ressource ; modifier un menu ; créer une redirection ; consulter les demandes Web. Il ne s'agit pas d'un manuel de 100 pages. Une documentation concise et illustrée suffira. 250. Propriété et indépendance technique Le code source du site devra être entièrement disponible dans le dépôt WININFO. Le fonctionnement du site ne devra pas dépendre d'un constructeur propriétaire de pages. Le site ne devra pas nécessiter Elementor, Beaver Builder ou WordPress pour fonctionner. Les contenus seront stockés dans la base du site et les médias dans les espaces prévus par l'application. 251. Dépendances externes Toute dépendance externe éventuellement ajoutée devra : avoir une utilité clairement identifiée ; être maintenue ; être documentée ; disposer d'une licence compatible avec le projet. Une bibliothèque ne devra pas être ajoutée pour une fonction pouvant raisonnablement être réalisée avec quelques lignes de code natif. 252. Maintenabilité Le développement devra privilégier : noms explicites ; classes et fonctions raisonnablement dimensionnées ; responsabilités séparées ; absence de duplication importante ; configuration centralisée ; composants réutilisables. Les règles métier ne devront pas être dispersées directement dans les templates HTML. 253. Journal des versions Le projet devra disposer d'un historique des versions. Exemple : VERSION 1.0.0 Socle initial du nouveau site VERSION 1.1.0 Nouveau gabarit Module VERSION 1.2.0 Ressources et actualités Le format pourra être adapté aux pratiques Git de WININFO. 254. Critères de validation finale Le futur site pourra être considéré comme prêt à remplacer l'ancien lorsque : les contenus prioritaires sont intégrés ; les pages produits fonctionnent ; les pages modules sont dynamiques ; le back-office est opérationnel ; les formulaires fonctionnent ; les URLs et redirections sont validées ; les tests responsive sont réalisés ; les contrôles de sécurité sont effectués ; le SEO technique est en place ; la migration des anciennes URLs est préparée ; les sauvegardes sont définies ; la recette WININFO est validée. 255. Principe de mise en production La mise en production ne devra pas être considérée comme la fin du projet. Le nouveau site est conçu pour devenir un outil vivant permettant à WININFO d'ajouter progressivement : nouveaux modules ; nouvelles fonctionnalités ; nouvelles formations ; ressources ; actualités ; nouveaux cas d'usage ; nouvelles intégrations. sans reconstruire le site. 256. Fin du socle général du CDC À ce stade, je considère que nous avons terminé le cahier des charges général de l'application Web. On peut maintenant séparer clairement deux documents intellectuels : CDC-WEB-001 │ ├── CH. 1 → 256 │ │ Architecture │ Back-office │ Front-office │ Gabarits │ SEO │ Sécurité │ Exploitation │ Recette │ └── FICHES DE CONTENU │ ├── WEB-MOD-001 Win@Transport ├── WEB-MOD-002 Win@Express ├── WEB-MOD-003 Win@Messagerie ├── WEB-MOD-004 Win@TP ├── WEB-MOD-005 Win@Logistique ├── WEB-MOD-006 Win@Atelier ├── WEB-MOD-007 Win@BTP ├── WEB-MOD-008 Win@Traçabilité ├── WEB-MOD-009 Win@Tablette ├── WEB-MOD-010 Win@Trésorerie └── ...