CDC-WEB-001Refonte du site institutionnel WININFOVersion : 0.1 – Document de travailProjet : Nouveau site wininfo.frCible technique : PHP / HTML5 / CSS / JavaScript / Base de donnéesSite cible : www.wininfo.fr1. Objet du projetLe 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. ContexteWININFO 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. ObjectifsLe nouveau site doit répondre à plusieurs objectifs.3.1 Présenter clairement WININFOLe 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 solutionsLe 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@ERPWin@ERP constitue une plateforme sur laquelle peuvent venir s'intégrer différents modules.Ces modules peuvent être de deux natures.Modules métierIls 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 fonctionnelsIls 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 solutionsWININFO 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'architecture4.1 Architecture généraleLe 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 produitsLe back-office doit permettre de gérer les produits proposés par WININFO.Chaque produit disposera au minimum des informations suivantes :ChampDescriptionIdentifiant interneIdentifiant unique et immuableNomNom commercialSlugIdentifiant utilisé dans l'URLDescription courtePrésentation synthétiquePrésentationTexte principalAccrocheMessage commercialImage principaleVisuel du produitGalerieImages complémentairesFonctionnalitésListe structuréeBénéficesListe structuréeModules associésModules rattachés au produitFAQQuestions/réponsesMeta TitleSEOMeta DescriptionSEOImage OpenGraphPartage réseaux sociauxStatutBrouillon / publié / archivéOrdrePriorité d'affichageLa structure doit permettre d'ajouter ultérieurement un troisième ou quatrième produit sans développement spécifique.6. Gestion des modulesLa gestion des modules constitue une fonction majeure du back-office.6.1 Fiche moduleChaque module disposera notamment des champs suivants :Identificationidentifiant interne ; nom ; slug ; produit de rattachement ; type de module ; catégorie ; statut. Présentationaccroche ; description courte ; présentation détaillée ; image principale ; galerie. Contenu fonctionnelfonctionnalités ; bénéfices ; cas d'utilisation ; secteurs concernés ; modules complémentaires ; produits ou services associés ; FAQ. RéférencementMeta Title ; Meta Description ; URL canonique ; image OpenGraph. 7. Typologie des modulesLe champ Type de module devra au minimum proposer :MÉTIERModule destiné à répondre aux besoins spécifiques d'une activité.Exemple :Win@TPType : MétierFamille : Travaux PublicsFONCTIONNELModule ajoutant une fonction transverse.Exemple :Win@TrésorerieType : FonctionnelFamille : Finance / PilotageLa liste des types devra être administrable afin de permettre une évolution future.8. Catégories et famillesLes 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 URLCette 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 AgentNovaLes 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 publiqueavec une fonction :Copier l'URLL'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'URLAprè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/ ↓ 301Nouvelle URL/modules/win-tresorerie/Ainsi, un ancien lien enregistré dans AgentNova, Google, un email ou un document continuera de fonctionner.12. Identifiants internesChaque élément important devra disposer d'un identifiant interne indépendant de son nom commercial et de son URL.Exemple :MOD-001 Win@TransportMOD-002 Win@ExpressMOD-003 Win@MessagerieMOD-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 pagesLe 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. CFICFI 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. MobilityScanMobilityScan 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 MobilityScanet 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 clientCette 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 éditorialLe 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 → Actionplutô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 fonctionnelLa 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 / contenusPAGES │ └── SECTIONS ├── Textes ├── Images ├── Cartes ├── CTA ├── Produits ├── Modules └── FormulairesACTUALITÉSRESSOURCESMÉDIASMENUSREDIRECTIONSPARAMÈTRESUTILISATEURSLe 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 productsCette entité contient les produits principaux de WININFO.Exemples actuels :Win@ERP ; Win@WMS. Principaux champs :ChampType logiqueObligatoireidIdentifiant techniqueOuireferenceEx. PROD-001OuinameNom du produitOuislugURLOuitaglineAccrocheOuishort_descriptionDescription courteOuicontentPrésentation détailléeOuimain_image_idMédia principalNonstatusBrouillon / publié / archivéOuidisplay_orderOrdre d'affichageOuipublished_atDate publicationNoncreated_atCréationOuiupdated_atModificationOuiLes informations SEO pourront être intégrées à cette table ou externalisées dans une table dédiée.21. Table modulesElle constitue l'une des tables centrales du site.Principaux champs :ChampDescriptionidIdentifiant techniquereferenceIdentifiant immuable, ex. MOD-001product_idProduit de rattachementmodule_type_idMétier / FonctionnelnameNom commercialslugSlug publictaglineAccrocheshort_descriptionPrésentation synthétiquecontentPrésentation détailléemain_image_idVisuel principalfeaturedModule à mettre en avantstatusBrouillon / publié / archivédisplay_orderOrdrepublished_atPublicationcreated_atCréationupdated_atModificationUn module devra pouvoir être rattaché à plusieurs catégories.22. Relations entre modulesLe système devra permettre d'établir des relations entre modules.Exemple :Win@ExpressModules associés possibles :Win@Tablette ; Win@Messagerie ; module EDI ; autres modules compatibles. Ces relations permettront d'afficher automatiquement sur une page :Complétez votre solutionDécouvrez également…Il ne faudra donc pas saisir manuellement ces liens dans le contenu HTML.23. Fonctionnalités et bénéficesIl 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éficeCe 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édiasLe 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 automatiqueLors 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 visuelsPour 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 WININFOIMG-ERP-001 Visuel principal Win@ERPIMG-WMS-001 Visuel principal Win@WMSIMG-MOD-001 Win@TransportIMG-MOD-002 Win@ExpressIMG-MOD-003 Win@MessagerieIMG-MOD-004 Win@TP...Cette référence ne sera pas nécessairement visible publiquement.26. Back-office WININFOLe 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 BORDCONTENUS├── Pages├── Produits├── Modules├── Actualités└── RessourcesORGANISATION├── Types de modules├── Catégories├── Menus└── RedirectionsMÉDIAS└── MédiathèqueSITE├── Paramètres généraux├── SEO└── Réseaux sociauxADMINISTRATION├── Utilisateurs└── Journal27. Tableau de bordAprès authentification, l'utilisateur accède à un tableau de bord simple.Il pourra notamment afficher :Contenusnombre de produits publiés ; nombre de modules métier ; nombre de modules fonctionnels ; pages publiées ; brouillons ; actualités. Actions rapidesAjouter un module Ajouter une actualité Ajouter une ressourceModifier l'accueil On pourra également afficher :Dernières modificationsavec 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.ModuleTypeCatégorieProduitStatutMOD-001Win@TransportMétierTransportWin@ERP🟢 PubliéMOD-002Win@ExpressMétierTransportWin@ERP🟢 PubliéMOD-003Win@MessagerieMétierTransportWin@ERP🟢 PubliéMOD-010Win@TrésorerieFonctionnelFinanceWin@ERP🟡 BrouillonDes filtres devront permettre de sélectionner :Produit · Type · Catégorie · StatutUne recherche permettra également de retrouver rapidement un module.29. Création d'un moduleLa création devra être volontairement simple.Étape 1 — IdentificationNom *[ 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ésentationAccroche[ __________________________________ ]Description courte[ __________________________________ ][ __________________________________ ]Présentation[ ][ ÉDITEUR DE CONTENU ][ ]Étape 3 — VisuelsImage principale[ Choisir dans la médiathèque ]Galerie[ + Ajouter ]Étape 4 — Contenu métierFonctionnalitésAjouter une fonctionnalité BénéficesAjouter un bénéfice FAQAjouter une question Étape 5 — RelationsModules complémentairesRechercher et sélectionner…Étape 6 — SEOMeta Title[ __________________________________ ]Meta Description[ __________________________________ ]Slug/modules/[ win-tresorerie ]Avec aperçu du résultat Google.Étape 7 — PublicationEnregistrer le brouillonPrévisualiserPublier30. PrévisualisationCette 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évisualiserLe 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 modificationsJe 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. CorbeilleLa 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 droitsMême si WININFO compte peu d'utilisateurs du back-office, je prévoirais les droits dès la conception.Au minimum :AdministrateurAccès complet :contenus ; configuration ; utilisateurs ; menus ; redirections. ÉditeurPeut :créer ; modifier ; publier les contenus. Ne peut pas modifier la configuration technique.ContributeurPeut :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érauxLes informations communes au site ne doivent jamais être répétées dans chaque page.Le back-office proposera notamment :WININFOraison sociale affichée ; adresse ; téléphone ; email général ; email commercial ; horaires éventuels. LiensHotline ; Espace client ; CFI ; MobilityScan. Réseaux sociauxLinkedIn ; 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 menusLe 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 importantTous 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 modulespermettra d'accéder au catalogue complet.36. Catalogue des modulesUne page dynamique devra afficher l'ensemble des modules publiés.Elle proposera notamment deux grandes entrées :Solutions métiersDes modules conçus autour de votre activité.et :Fonctionnalités complémentairesEnrichissez Win@ERP avec les fonctionnalités dont votre organisation a besoin.Le visiteur pourra filtrer les modules par :Type · Métier/catégorie · Produitet éventuellement utiliser une recherche.37. Page dynamique d'un moduleToutes 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 CTA02 LE BESOIN Problématique métier/fonctionnelle03 LA SOLUTION Présentation du module04 FONCTIONNALITÉS Cartes dynamiques05 BÉNÉFICES Gains pour l'entreprise06 FONCTIONNEMENT Processus / cas d'usage07 GALERIE Captures ou illustrations08 MODULES COMPLÉMENTAIRES Relations automatiques09 FAQ Questions dynamiques10 CTA FINAL Demande de démonstration / contactToutes 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 ProduitLe 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émonstrationLes 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 uneCela 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ésentationCodex 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-officeLe 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 + InnovationL'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 graphiquesLe 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éraleFond principal :Blanc / gris très clairCouleur principale :Bleu-vert / turquoise WININFOCouleur 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 WININFOCodex devra créer une petite bibliothèque de composants réutilisables.Elle comprendra au minimum :TypographieH1 ; H2 ; H3 ; H4 ; texte courant ; introduction ; petit texte ; légende. Boutonsprimaire ; secondaire ; contour ; lien texte. Composantscarte 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 DesignLe site sera conçu selon une approche responsive.Trois grandes plages devront au minimum être prévues :Mobile < 768 pxTablette 768 à 1199 pxDesktop >= 1200 pxLe 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 :DESKTOPTexte Image██████████ ███████████████████ █████████MOBILETexte████████████████Image████████████████45. Largeur et respirationLe contenu principal devra disposer d'une largeur maximale commune.Ordre de grandeur envisagé :1 200 à 1 300 pxLes 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. HeaderLe 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 :HotlineEspace clientIls 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 PRODUITSWin@ERPLa plateforme de gestion modulaireWin@WMSGestion et pilotage d'entrepôtSOLUTIONS MÉTIERSTransport Travaux PublicsExpress BTPMessagerie AtelierLogistique Traçabilité→ Toutes les solutions métiersFONCTIONNALITÉS COMPLÉMENTAIRESTrésorerie...→ Tous les modules fonctionnelsLe 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 mobileSur smartphone, le mega-menu sera remplacé par une navigation adaptée.Exemple :☰Solutions › Produits › Solutions métiers › Fonctionnalités complémentairesDéveloppement sur mesureCFIMobilityScanRessourcesÀ propos────────────HotlineEspace clientLes zones tactiles devront être suffisamment grandes.49. Header fixeLe 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. FooterLe footer devra également servir d'outil de navigation.Structure envisagée :WININFOCabinet d'ingénierie informatique[coordonnées]SOLUTIONSWin@ERPWin@WMSSolutions métiersModules fonctionnelsWININFOÀ proposDéveloppement sur mesureCFIMobilityScanActualitésASSISTANCEHotlineEspace clientContactLinkedIn Facebook ...──────────────────────────────────Mentions légales | Confidentialité | Cookies© WININFOLes coordonnées et liens seront issus des paramètres du back-office.51. Fil d'ArianeLes pages internes devront disposer d'un fil d'Ariane.Exemple :Accueil › Solutions › Modules › Win@AtelierImportant : 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 — AccueilLa 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 : HeroLe slider actuellement présent sur le site de développement ne sera pas repris.Le Hero principal sera fixe.Sur-titreCABINET D'INGÉNIERIE INFORMATIQUEH1Des solutions de gestion conçues autour de votre métierTexteWININFO 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 principalDécouvrir nos solutionsLien vers la section Solutions de l'accueil ou la page catalogue.CTA secondaireParler de votre projetLien vers le formulaire de contact.Élément de réassurancePlus 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 — VisuelLe 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 WININFOH2L'informatique au service de votre métierContenuDepuis 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 solutionsH2Des solutions conçues pour évoluer avec votre entrepriseIntroductionNos 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@ERPVotre gestion d'entreprise adaptée à votre métierUne 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@ERPWin@WMSPilotez et optimisez votre entrepôtUne 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@WMSLes informations pourront être issues directement des fiches products.57. Accueil — Section 04 : Vos métiersCette section est particulièrement importante.H2Nous connaissons votre métierIntroductionLes 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étiers58. Accueil — Section 05 : Modules fonctionnelsCette 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.H2Ajoutez les fonctionnalités dont vous avez besoinExemple 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és59. Accueil — Section 06 : Développement sur mesureCette partie doit fortement valoriser WININFO.H2Votre besoin ne rentre pas dans une case ?TexteToutes 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 besoinCette section permettra de différencier WININFO des éditeurs proposant uniquement un produit standard figé.60. Accueil — Section 07 : Écosystème WININFOC'est ici que nous intégrerons CFI et MobilityScan sans donner l'impression qu'ils constituent l'activité principale.H2Un accompagnement qui va au-delà du logicielTrois univers pourront être représentés.Solutions WININFOLogiciels de gestion et solutions métier.CFIFormation et accompagnement des utilisateurs.CTA :Découvrir CFIMobilityScanÉquipements professionnels et solutions de mobilité adaptés aux usages terrain.CTA :Découvrir MobilityScanPuis depuis la page MobilityScan :Accéder à la boutiqueCette organisation permet de montrer que WININFO peut couvrir :Logiciel + Compétences + MatérielC'est un positionnement particulièrement intéressant.61. Accueil — Section 08 : Pourquoi WININFO ?H2Un partenaire qui comprend votre organisationJe mettrais ici quatre valeurs principales.Expertise métierDes 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.ÉvolutionDes solutions qui progressent avec les besoins et les métiers.AccompagnementAnalyse, 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 approcheUne frise permettra de montrer que WININFO accompagne un projet dans la durée.COMPRENDRE ↓CONCEVOIR ↓INTÉGRER ↓FORMER ↓ACCOMPAGNER ↓FAIRE ÉVOLUERTexteNotre 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 ressourcesLe site devra pouvoir afficher automatiquement les derniers contenus publiés.Deux types pourront être mélangés ou distingués :ActualitésetRessourcesExemple :[ARTICLE] [GUIDE] [ACTUALITÉ]Titre Titre TitreRé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 finalLa page se terminera par une invitation claire.H2Parlons de votre projetTexteVous 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 contacterCTA secondaire :Demander une démonstration65. Ordre complet de la page AccueilNous 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│└── FOOTERJe 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'accueilUn 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 imagesNous 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 WININFOIMG-PROD-001 Win@ERPIMG-PROD-002 Win@WMSIMG-MET-001 TransportIMG-MET-002 ExpressIMG-MET-003 MessagerieIMG-MET-004 TPIMG-MET-005 LogistiqueIMG-MET-006 AtelierIMG-MET-007 BTPIMG-MET-008 TraçabilitéIMG-FCT-001 Trésorerie...IMG-CFI-001 CFIIMG-MOB-001 MobilityScanIMG-SUR-001 Développement sur mesureOn 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@ERPRéférence : WEB-P002Type : Page ProduitProduit : Win@ERPURL canonique : /solutions/win-erp/Objectif de la pageLa 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 commercialWin@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@ERPSur-titreSOLUTION DE GESTION MODULAIREH1Win@ERPVotre gestion d'entreprise adaptée à votre métierIntroductionWin@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.AccrocheUne seule plateforme. Les modules adaptés à votre entreprise.CTA principalDemander une démonstrationCTA secondaireDécouvrir les modulesLe deuxième CTA fera défiler la page jusqu'à la présentation des modules.VisuelRéférence provisoire :IMG-PROD-001 — Win@ERPLe 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 ?H2Centralisez 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éeClients, fournisseurs, produits, commandes, factures, documents et données métier sont regroupés dans un même environnement.Moins de ressaisiesUne information saisie peut être réutilisée par les différents processus et services concernés.Des processus plus fluidesLes 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@ERPCette section doit éviter une confusion importante : Win@ERP n'est pas uniquement un conteneur de modules.Il possède son propre socle fonctionnel.H2Un socle complet pour votre gestion quotidienneLes fonctions seront présentées sous forme de cartes.Gestion commercialeprospects ; clients ; contacts ; propositions commerciales ; commandes. Achats & fournisseursfournisseurs ; commandes fournisseurs ; réceptions ; factures fournisseurs. Facturation & règlementsfacturation clients ; factures fournisseurs ; règlements ; suivi des échéances. Produits & servicescatalogue ; tarifs ; produits ; prestations ; stocks lorsque nécessaires. Organisationagenda ; événements ; documents ; utilisateurs ; droits d'accès. Pilotagetableaux de bord ; statistiques ; indicateurs ; imports et exports. Cette liste sera administrable depuis la fiche Produit.73. Section 04 — La philosophie modulaireCette section est probablement la plus importante de la page.H2Votre entreprise est unique. Votre ERP doit s'y adapter.TexteToutes 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 fortVous n'avez pas à changer de logiciel lorsque votre entreprise évolue. Win@ERP évolue avec elle.74. Section 05 — Les modules métierH2Des solutions conçues autour de votre métierIntroductionLes 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@ERPtype = Métierstatus = 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étierSur 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 fonctionnelsCette section introduit la deuxième famille.H2Ajoutez les fonctionnalités dont votre organisation a besoinIntroductionLes 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ésorerieCentralisez 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@ERPtype = Fonctionnelstatus = Publié77. Section 07 — Combinez plusieurs activitésCette section constitue un différenciateur important.H2Plusieurs activités. Un seul environnement.TexteUne 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 COMMUNESCette illustration devra être conçue sous forme graphique responsive.78. Cas particulier Win@TP / Win@BTPLa 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é terrainWin@Tablette possède un positionnement particulier.Il ne correspond pas complètement à un métier unique et peut être utilisé par plusieurs activités.H2Reliez le terrain à votre gestion en temps réelTexteLes 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éficeL'information saisie sur le terrain devient immédiatement disponible pour les équipes concernées.80. Section 09 — ConnectivitéH2Win@ERP s'intègre à votre système d'informationTexteUne 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 │ ▼ PARTENAIRESLes exemples exacts seront ajustés selon les connecteurs réellement commercialisés.81. EDIL'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 électroniqueCompte 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.H2Préparez vos échanges de facturation électroniqueLa 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 électroniqueCette section devra pouvoir être activée/désactivée depuis le back-office.83. Section 11 — HébergementH2Un environnement hébergé et maîtrisé par WININFOTexteWin@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.ImportantLe 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 WININFOCette section doit clairement différencier le logiciel de la prestation WININFO.H2Un projet ERP ne se résume pas à installer un logicielIntroductionChaque 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 ÉVOLUERTexteLes équipes WININFO vous accompagnent depuis l'étude de votre besoin jusqu'à l'utilisation quotidienne de votre solution.85. Section 13 — Développement spécifiqueH2Et lorsque le standard ne suffit pas ?TexteCertaines 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 besoinLien vers la page Développement sur mesure.86. Section 14 — Une solution évolutiveH2Commencez avec vos besoins d'aujourd'hui. Préparez ceux de demain.TexteNouveau 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@ERPLa 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 finalH2Construisons le Win@ERP adapté à votre entrepriseTextePrésentez-nous votre activité, votre organisation et vos besoins. Nous étudierons avec vous les fonctionnalités et modules adaptés à votre projet.CTA principalDemander une démonstrationCTA secondaireNous contacter89. Structure complète WEB-P002La 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│└── FOOTERCela 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@ERPJe 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évoirNotre 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 :TRANSVERSALOn 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@WMSRéférence : WEB-P003Type : Page ProduitProduit : Win@WMSURL canonique : /solutions/win-wms/Objectif de la pageLa 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 → InventaireWin@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@WMSLe 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 — HeroSur-titreSOLUTION DE GESTION D'ENTREPÔTH1Win@WMSPilotez et optimisez les opérations de votre entrepôtIntroductionWin@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 principalDemander une démonstrationCTA secondaireDécouvrir le fonctionnementVisuelRéférence :IMG-PROD-002 — Win@WMSLe 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 besoinH2Gardez la maîtrise de chaque mouvementTexteDans 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 logistiqueCette section devra être très visuelle.H2Un seul outil pour piloter le cycle de l'entrepôtSchéma :RÉCEPTION ↓CONTRÔLE ↓MISE EN STOCK ↓STOCKAGE ↓MOUVEMENTS ↓PRÉPARATION ↓EXPÉDITION ↕ INVENTAIRESSur 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éceptionH2Réceptionnez et contrôlez les marchandisesLa 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 emplacementsH2Structurez votre entrepôtWin@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 │ │ │ │ │ │ │ └── EMPLACEMENTL'objectif commercial est simple :Savoir ce qui est stocké et où le trouver.100. Section 06 — Stock et mouvementsH2Suivez votre stock au fil des opérationsLes 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éparationH2Fiabilisez vos préparationsCette 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éditionH2Préparez vos marchandises au départLe 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 — InventairesH2Contrôlez la réalité de votre stockTexteLes 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.H2Le WMS accompagne les opérateurs sur le terrainTexteLes 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érationsH2Retrouvez l'historique des opérationsL'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 gestionCette section est essentielle pour bien positionner Win@WMS.H2Connectez l'entrepôt à votre système d'informationTexteWin@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ÔTLe 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 transporteursH2Automatisez les échanges avec vos partenairesLorsque 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 — MobilityScanIci, le lien avec MobilityScan devient particulièrement naturel.H2Des équipements adaptés aux opérations terrainTexteWININFO 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 MobilityScanPuis la page MobilityScan dirigera vers la boutique en ligne.Cela permet de montrer une capacité intéressante de WININFO :Logiciel + intégration + matérielsans transformer la page Win@WMS en boutique.109. Section 15 — Accompagnement WININFOH2Un WMS doit correspondre à la réalité de votre entrepôtTexteLa 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 ↓ACCOMPAGNEMENT110. Section 16 — FAQ Win@WMSPremiè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 finalH2Étudions ensemble les flux de votre entrepôtTextePré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émonstrationCTA secondaire :Nous contacter112. Structure complète WEB-P003HEADER│├── 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│└── FOOTER113. Une distinction importante dans notre modèle de donnéesEn rédigeant Win@WMS, je vois une amélioration intéressante à apporter au back-office.Il ne suffit pas de définir :Produit → ModulesIl 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 WMSJe 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@WMSJe 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 modulesMaintenant 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 ModuleCe 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ésorerieEt les futurs modules utiliseront exactement le même mécanisme.116. WEB-TPL-MOD-001 — Gabarit générique d'une page ModuleRéférence : WEB-TPL-MOD-001Type : Gabarit dynamiqueObjet : Présentation publique d'un moduleURL type : /modules/{slug}/ObjectifLe 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 modulesLe gabarit doit prendre en charge les trois classifications définies dans le CDC.Module métierIl 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 fonctionnelIl ajoute une fonction spécialisée à Win@ERP.Exemple :Win@Trésorerie. Module transversalIl 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ÉTIERMODULE FONCTIONNELMODULE TRANSVERSALLe libellé proviendra de la base et ne sera pas codé en dur.118. Rattachement à Win@ERPLes modules actuellement concernés sont rattachés à Win@ERP.La page devra clairement faire comprendre cette relation.Exemple :Module de Win@ERPLe 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éraleLe 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│└── FOOTERToutes les sections ne sont pas obligatoires.Une section sans contenu ne devra jamais générer une zone vide.120. Section 01 — Hero ModuleLe 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 FONCTIONNELWin@TrésoreriePilotez et anticipez votre trésorerieCentralisez les informations nécessaires au suivi de vos encaissements, décaissements et prévisions de trésorerie.CTA principal :Demander une démonstrationCTA secondaire éventuel :Nous contacter121. Adaptation du Hero selon le typeLe 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 besoinCette 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 solutionTitre par défautUne solution intégrée à Win@ERPLe 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ÉFICES124. Section 04 — FonctionnalitésLes 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 secondairesJe rajouterais une notion que nous n'avions pas encore définie.Une fonctionnalité pourra être marquée :PrincipaleCela 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éficesCette section doit être distincte des fonctionnalités.TitreCe que Win@[Module] apporte à votre organisationExemples 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 / ProcessusCertains modules se comprennent beaucoup mieux par leur processus.Exemple Win@Atelier :DEMANDED'INTERVENTION ↓ORDRE DERÉPARATION ↓PLANIFICATION ↓INTERVENTION ↓PIÈCES / TEMPS ↓CLÔTURE ↓FACTURATIONsi nécessaireExemple Win@Transport :COMMANDE ↓ORGANISATION ↓PLANIFICATION ↓AFFECTATION ↓EXÉCUTION ↓SUIVI ↓FACTURATIONLe back-office devra donc permettre de gérer une liste ordonnée d'étapes.128. Représentation des processusUne étape pourra comporter :titre ; description ; icône ; ordre. Sur desktop :① ───── ② ───── ③ ───── ④Sur mobile :①│②│③│④Le composant devra être responsive.129. Section 07 — Cas d'usageCertains modules peuvent répondre à plusieurs situations.Le back-office permettra de créer des cas d'usage.Exemple Win@Atelier :Atelier interneGestion de la maintenance et des réparations du parc de l'entreprise.Prestations pour des tiersGestion des interventions réalisées et facturées pour des clients.Autre exemple pour Win@Logistique :StockagePréparationPrestations logistiquesCes cas d'usage devront rester facultatifs.130. Section 08 — GalerieLes 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'écranLes 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émentairesCette section sera générée à partir des relations définies dans le back-office.H2Complétez votre solutionExemple 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@Tablettene signifie pas nécessairement que la page Win@Tablette doive automatiquement recommander Win@Transport.133. Section 10 — Ressources associéesCette 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 loinavec les ressources correspondantes.134. Section 11 — FAQChaque 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 finalToutes les pages modules devront se terminer par une action claire.Titre générique possible :Découvrez comment Win@[Module] peut s'adapter à votre organisationTexte :Présentez-nous votre activité et vos besoins. Notre équipe pourra vous accompagner dans l'étude de votre projet.CTA :Demander une démonstrationet éventuellement :Nous contacterLe 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-006Module : Win@AtelierURL : /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émonstrationProduit : Win@ERPModule : Win@TrésorerieOrigine : Page Win@TrésorerieLe visiteur n'aura pas à ressaisir ces informations.137. SEO des modulesChaque module disposera :d'une URL canonique ; d'un <title> ; d'une Meta Description ; d'un H1 unique ; d'une image OpenGraph ; d'un texte alternatif pour les images. Exemple :URL/modules/win-atelier/TitleWin@Atelier - Logiciel de gestion d'atelier | WININFOLe titre SEO devra être administrable et non généré obligatoirement selon cette formule.138. Partage AgentNovaCette partie reprend notre exigence précédente.Dans le back-office :URL publiquehttps://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évisualisationUn module en brouillon devra pouvoir être prévisualisé.Exemple :Win@TrésorerieSTATUT : BROUILLON[ Prévisualiser ][ Publier ]La prévisualisation ne devra pas être indexable par les moteurs de recherche.140. Publication incomplèteJe 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étudeOn pourrait aller un peu plus loin avec un indicateur simple :Fiche Win@TrésorerieComplétude : 75 %✓ Identification✓ Présentation✓ Image✓ Fonctionnalités⚠ Aucun bénéfice✓ SEO⚠ Aucune FAQLes é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 contenuC'est un principe important du projet.Une fiche module pourra être très simple :HeroPrésentationFonctionnalitésCTAou beaucoup plus complète :HeroBesoinPrésentationFonctionnalitésBénéficesProcessusCas d'usageGalerieModules associésRessourcesFAQCTALe 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 moduleJe prévoirais même dans le back-office :+ Création rapideavec uniquement :NomProduitTypeCatégorieDescription courteImage→ Créer en brouillonLa 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 produitEnfin, 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 PRODUITCela évitera beaucoup de duplication de contenu.145. Conclusion du gabarit ModuleWEB-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 — Suite146. WEB-P004 — Développement sur mesureRéférence : WEB-P004Type : Page institutionnelle / commercialeURL canonique : /developpement-sur-mesure/ObjectifCette 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 — HeroSur-titreDÉVELOPPEMENT SUR MESUREH1Transformons vos besoins métier en solutions concrètesIntroductionLorsqu'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.CTAParler de mon projetVisuel :IMG-SUR-001Il devra évoquer analyse + métier + développement, et éviter l'image cliché d'un écran rempli de code.148. Section 02 — Partir du besoinH2Le développement commence par la compréhension de votre métierTexteAvant 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 projetsH2Des développements adaptés à différents besoinsCartes administrables :Évolution d'une solution WININFOAjouter ou adapter une fonctionnalité à un environnement existant.Nouveau module métierConcevoir un module répondant à un processus ou à une activité particulière.Interface entre logicielsFaire circuler les informations entre plusieurs applications afin de limiter les ressaisies.AutomatisationAutomatiser des opérations répétitives ou des traitements de données.Application spécifiqueConcevoir 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éthodeH2Une démarche structurée, du besoin à la mise en serviceProcessus :ÉCOUTER ↓ANALYSER ↓SPÉCIFIER ↓CONCEVOIR ↓DÉVELOPPER ↓TESTER ↓DÉPLOYER ↓ACCOMPAGNERChaque é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 existantH2Faire évoluer l'existant plutôt que tout reconstruireTexteUne 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ÉES152. Section 06 — Du spécifique au moduleCette partie me paraît particulièrement intéressante pour WININFO.H2Un besoin client peut parfois devenir une solution métierTexteCertains 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 tempsH2Un développement doit pouvoir vivre et évoluerTexteLa 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 besoin154. WEB-P005 — CFIRé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.ObjectifsLa 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 — HeroSur-titreCFI — FORMATIONH1Développez les compétences de vos équipesIntroductionCFI 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 formationsCTA secondaire :Nous contacterLe contenu définitif pourra être adapté à la présentation institutionnelle actuelle de CFI.156. CFI — Les formationsLe 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 formationsUne formation pourra être associée à un produit ou à un module.Exemple :Formation Win@Atelier │ └── liée à → Win@AtelierLa page Win@Atelier pourra alors éventuellement afficher :Formation associéeet la fiche formation pourra afficher :Solution concernée : Win@AtelierCe mécanisme utilisera le système général de contenus associés défini précédemment.158. CFI — Location de salleSi 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 informationsLes tarifs, s'ils sont affichés, devront être administrables.159. CFI — Identité graphiqueCFI 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 — MobilityScanRéférence : WEB-P006Type : Page activité / passerelle commercialeURL canonique : /mobilityscan/ObjectifCette 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 — HeroH1Les équipements professionnels adaptés à vos usages terrainTexteMobilityScan 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 MobilityScanLe lien sera externe et administrable.162. MobilityScan — Familles de matérielsLa 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.ImportantLes 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 WININFOH2Le logiciel et le matériel pensés ensembleTexteDans 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ésURL : /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ésLa 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éesUne actualité pourra être reliée à :un produit ; un module ; CFI ; MobilityScan ; une thématique. Exemple :Nouvelle réglementationFacturation électronique │ └── associée à → Win@ERPLa page Win@ERP pourra ainsi afficher automatiquement certaines actualités pertinentes.167. WEB-P008 — RessourcesURL : /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 RessourceUne 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 siteDOCUMENT→ téléchargementRESSOURCE EXTERNE→ lien169. TéléchargementsPour 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 MoLe téléchargement ne devra jamais révéler le chemin physique réel du serveur.170. Facturation électroniqueJe 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 — ContactURL : /contact/Le formulaire Contact sera commun à plusieurs parcours.Champs proposéssocié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 demandesJe 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émonstrationUne 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éphoneSolution concernée[ Win@ERP ]Module[ Win@Atelier ]Votre besoin[ ][ Demander une démonstration ]Si l'utilisateur arrive depuis Win@Atelier :Solution = Win@ERPModule = Win@Atelierseront automatiquement renseignés.174. Traitement des formulairesLe 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 demandesPour 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 / autreCela évitera que le contrôleur du formulaire contienne directement une logique d'envoi figée.176. Enregistrement des demandesJe recommande également d'enregistrer les demandes dans la base avant l'envoi de l'email.Le back-office pourra disposer d'une rubrique :Demandes Webavec :date ; société ; contact ; type ; produit ; module ; statut. Statuts possibles :NOUVELLETRAITÉEARCHIVÉECela permet de ne pas dépendre exclusivement d'un email.177. Consentement et données personnellesLes 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-spamLe 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 confirmationAprè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. ErreursEn 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. HotlineLa 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 clientMê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 externesCFI, 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 404Le site disposera d'une véritable page 404.H1Cette page n'existe pas ou n'est plus disponibleElle 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 interneVu 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 rechercheURL proposée :/recherche/?q=transportLes 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 WEBEt surtout, toutes ces briques restent administrables et reliables entre elles.189. Référencement naturel — SEOLe 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 SEOChaque contenu indexable pourra disposer au minimum des champs suivants :Titre SEOMeta DescriptionURL / SlugURL canoniqueImage OpenGraphIndexation autorisée : Oui / NonLe back-office affichera un aperçu simple :Win@Atelier - Logiciel de gestion d'atelier | WININFOhttps://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éfautLorsqu'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 titresChaque 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équentesLe CSS gérera l'apparence ; le HTML conservera la structure sémantique.193. URLsLes 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_ATELIER194. URL canoniqueChaque 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 slugComme 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 XMLLe site générera automatiquement :/sitemap.xmlLe 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.txtLe site fournira un fichier :/robots.txtIl 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 productionC'est un point très important.Le futur site de développement ne devra pas être indexé.Sur DEV et TEST :noindex, nofollowdevra ê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éesLorsque 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 partageLes pages publiques devront fournir les métadonnées nécessaires au partage sur les principaux réseaux et outils de messagerie.Au minimum :og:titleog:descriptionog:imageog:urlog:typeUne image par défaut WININFO pourra être utilisée lorsqu'aucune image spécifique n'est définie.201. Page 404 et SEOUne page inexistante devra réellement retourner :HTTP 404et 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 clavierLes 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 alternatifsLes 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 accessiblesChaque 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éralesLe 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 responsiveLes 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. PerformanceLa 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 JavaScriptLe 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 LoadingLes 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. CacheL'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.1ou système équivalent.212. Sécurité applicativeLe 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 SQLToutes 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 XSSLes 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 CSRFToutes 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 administrateurLes sessions du back-office devront utiliser des cookies configurés avec les protections appropriées.Notamment selon l'environnement :HttpOnlySecureSameSiteL'identifiant de session devra être renouvelé après authentification.Une déconnexion devra invalider correctement la session.217. Mots de passeLes 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'administrationLe 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. UploadsLes 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'erreurEn 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 secretsLes 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. RGPDLe 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. CookiesLe site devra distinguer :Cookies strictement nécessairesExemple :session administrateur ; sécurité ; fonctionnement indispensable. Cookies non nécessairesExemple 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 inutileSi 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. StatistiquesLe 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. SauvegardesLes éléments nécessaires à la restauration du site devront être identifiés séparément :CODE→ GitBASE DE DONNÉES→ MariaDBMÉDIAS / UPLOADS→ stockage fichiersCONFIGURATION→ environnement sécuriséLa sauvegarde du dépôt Git ne constitue donc pas à elle seule une sauvegarde du site.229. EnvironnementsJe formaliserais trois environnements :DEVDéveloppementTEST / RECETTEValidation avant productionPRODwww.wininfo.frChaque 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. DockerLe 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 environnementLes éléments suivants devront notamment pouvoir varier sans modifier le code :APP_ENVAPP_URLDB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDMAIL_HOSTMAIL_PORTMAIL_USERMAIL_PASSWORDINDEXING_ENABLEDLOG_LEVELLes noms exacts pourront être adaptés à la convention déjà utilisée par Codex.232. DéploiementLe 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 service233. Évolution du schéma de baseC'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.sql002_module_features.sql003_content_relations.sql004_web_requests.sqlLe système devra savoir quelles migrations ont déjà été appliquées.234. Mise à jour sans perte de donnéesUne 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 siteAvant 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écifiqueOn ne remplacera donc pas simplement l'ancien site du jour au lendemain sans cartographie des URLs.236. Table de migration des URLsUne table de travail devra être constituée avant bascule.Exemple :Ancienne URLNouvelle URLActionancienne page ERP/solutions/win-erp/301ancienne page WMS/solutions/win-wms/301ancienne actualité conservéenouvelle URL301contenu sans équivalentà décider410/301 selon casCette table pourra ensuite alimenter le mécanisme de redirections du back-office.237. Aucun lien cassé après migrationAvant 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 fonctionnelleLa recette devra vérifier les fonctionnalités décrites dans le CDC.Les tests seront organisés par domaine :FRONT-OFFICEBACK-OFFICECONTENUSFORMULAIRESSEORESPONSIVESÉCURITÉPERFORMANCESMIGRATION239. Test critique — création d'un moduleCe test sera obligatoire avant validation.ScénarioConnexion 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 attenduUne 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 slugScénarioPublier :/modules/module-test/puis modifier le slug :/modules/nouveau-module-test/Résultat attenduL'ancienne adresse retourne :301vers la nouvelle.La nouvelle retourne :200L'URL canonique correspond à la nouvelle adresse.241. Test critique — brouillonUn 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 — suppressionLa 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 responsiveLes 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é navigateursLe 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 formulairesSeront 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-officeLe 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 techniqueLe dépôt devra contenir une documentation permettant à un autre développeur de reprendre le projet.Au minimum :README.mdavec :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éesLe 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 └── RELATIONSainsi que les tables communes :USERSMENUSPAGESNEWSRESOURCESREDIRECTSWEB_REQUESTSAUDIT_LOG249. Documentation back-officeUne 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 techniqueLe 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 externesToute 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 versionsLe projet devra disposer d'un historique des versions.Exemple :VERSION 1.0.0Socle initial du nouveau siteVERSION 1.1.0Nouveau gabarit ModuleVERSION 1.2.0Ressources et actualitésLe format pourra être adapté aux pratiques Git de WININFO.254. Critères de validation finaleLe 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 productionLa 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 └── ...