# Modele De Fiche Module WININFO

Ce document sert de trame de saisie pour creer une fiche Module dans le back-office WININFO sans repartir de zero a chaque fois.

Objectif :
- garder une structure commune sur toutes les fiches ;
- faciliter la saisie par l'administration ;
- conserver un rendu public coherent ;
- limiter les sections specifiques aux seuls cas vraiment necessaires.

## 1. Principe General

Une fiche module doit repondre simplement a ces questions :
- Quel est le nom du module ?
- A quoi sert-il concretement ?
- Pour qui est-il utile ?
- Quelles sont ses fonctionnalites principales ?
- Quels benefices apporte-t-il ?
- Comment s'integre-t-il dans l'environnement WININFO ?
- Quelle action souhaite-t-on proposer au lecteur ?

Le modele standard d'une fiche module est le suivant :
1. Hero
2. Positionnement
3. Fonctionnalites
4. Benefices
5. Cas d'usage / fonctionnement
6. FAQ
7. Composez votre environnement WININFO
8. CTA final

## 2. Blocs Du Modele

### 2.1 Hero

But :
Presenter immediatement le module et donner envie de continuer la lecture.

Champs :
- `Nom`
- `Accroche courte`
- `Description`
- `Icone`
- `CTA principal`
- `URL CTA principal`
- `CTA secondaire`
- `URL CTA secondaire`
- `Image hero` si disponible

Recommandations :
- L'accroche doit tenir idealement sur 1 ligne ou 2 maximum.
- La description doit rester courte : 2 a 4 phrases.
- Le CTA principal est souvent `Demander une demonstration`.
- Le CTA secondaire peut etre `Voir les modules Win@ERP`, `Voir les modules Win@WMS` ou `Nous contacter`.

Exemple de logique editoriale :
- nom : `Win@Transport`
- accroche : `Pilotez vos flux transport dans un environnement metier structure`
- description : expliquer en peu de phrases ce que le module couvre et pour quel type d'organisation.

### 2.2 Positionnement

But :
Expliquer a quoi sert le module dans le quotidien du client.

Contenu attendu :
- le besoin traite ;
- le contexte d'utilisation ;
- le type d'entreprise ou de service concerne ;
- le rattachement a la solution : Win@ERP ou Win@WMS.

Format conseille :
- 1 titre clair ;
- 1 a 3 paragraphes courts ;
- une illustration si disponible.

Questions a se poser :
- Quel probleme ce module aide-t-il a resoudre ?
- Dans quel environnement de travail intervient-il ?
- Pourquoi ne pas se contenter du socle seul ?

### 2.3 Fonctionnalites

But :
Lister les fonctions principales du module.

Structure recommandee :
- 4 a 6 fonctionnalites ;
- pour chaque fonctionnalite :
  - `Titre`
  - `Description`
  - `Icone`
  - `Ordre`

Bonnes pratiques :
- un titre court ;
- une description concrete ;
- ne pas redire la meme idee sous plusieurs formulations.

Exemple :
- `Planification des tournees`
- `Suivi des ordres de transport`
- `Gestion des statuts d'exploitation`

### 2.4 Benefices

But :
Exprimer la valeur concrete pour le client.

Structure recommandee :
- 3 a 5 benefices ;
- pour chaque benefice :
  - `Titre`
  - `Description`
  - `Icone`
  - `Ordre`

Formulation recommandee :
- parler resultat ;
- parler usage ;
- parler gains concrets.

Exemples de types de benefices :
- gain de temps ;
- fiabilisation des donnees ;
- meilleure visibilite ;
- reduction des ressaisies ;
- meilleure coordination des equipes.

### 2.5 Cas D'usage / Fonctionnement

But :
Rendre le module plus concret.

Deux approches possibles :
- un texte explicatif simple ;
- un parcours en etapes si cela a du sens.

Utilisation recommandee :
- pour expliquer comment le module s'utilise ;
- pour decrire un enchainement metier ;
- pour montrer comment il s'insere dans l'activite.

Exemples :
- demande -> planification -> execution -> suivi -> cloture ;
- reception -> controle -> mise en stock -> preparation -> expedition.

Regle :
- ne pas ajouter ce bloc si le module n'a rien de specifique a raconter ;
- utiliser les sections dynamiques uniquement si le socle standard ne suffit pas.

### 2.6 FAQ

But :
Lever les freins les plus frequents.

Structure recommandee :
- 3 a 5 questions.

Themes conseilles :
- a quoi sert exactement le module ;
- a qui s'adresse-t-il ;
- peut-il fonctionner avec d'autres modules ;
- faut-il un equipement particulier ;
- peut-il s'adapter a telle ou telle organisation.

Rappel important :
- les modules d'un meme environnement sont combinables entre eux ;
- les modules Win@ERP restent dans l'environnement Win@ERP ;
- les modules Win@WMS restent dans l'environnement Win@WMS.

### 2.7 Composez Votre Environnement WININFO

But :
Presenter les autres modules lies, sans creer de dependance artificielle.

Fonctionnement :
- bloc alimente dynamiquement ;
- ne pas l'utiliser pour imposer un ordre obligatoire ;
- il sert a montrer des briques compatibles du meme environnement.

Texte recommande :
- expliquer que le module peut etre combine avec d'autres modules de la meme solution selon l'organisation du client.

### 2.8 CTA Final

But :
Fermer la page avec une action claire.

Champs :
- `Eyebrow`
- `Titre`
- `Contenu`
- `CTA principal`
- `URL CTA principal`
- `CTA secondaire`
- `URL CTA secondaire`
- `Actif`

Usage recommande :
- CTA principal : `Demander une demonstration`
- CTA secondaire : `Nous contacter` ou `Voir les modules de la solution`

## 3. Niveau De Remplissage Minimum

Pour qu'une fiche soit deja propre et publiable, il faut au minimum :
- hero complet ;
- texte de positionnement ;
- 4 fonctionnalites ;
- 3 benefices ;
- 3 FAQ ;
- CTA final actif.

Si ce minimum est rempli, la fiche reste deja lisible et coherente.

## 4. Niveau De Remplissage Recommande

Pour une bonne fiche commerciale :
- hero complet avec image ;
- positionnement bien redige ;
- 4 a 6 fonctionnalites ;
- 4 benefices ;
- 4 ou 5 FAQ ;
- bloc fonctionnement ou parcours si pertinent ;
- CTA final complet ;
- illustration dans une ou deux sections.

## 5. Ce Qu'Il Faut Eviter

- des paragraphes trop longs ;
- des cartes qui repetent la meme idee ;
- des titres trop techniques sans explication ;
- des dependances obligatoires non justifiees ;
- des sections dynamiques ajoutees "au cas ou" ;
- du contenu trop generique qui pourrait s'appliquer a n'importe quel module.

## 6. Trame De Redaction Rapide

Quand on cree un nouveau module, on peut suivre cette sequence :

1. Ecrire le hero
- nom
- accroche
- description
- CTA

2. Ecrire le positionnement
- quel besoin
- pour quel metier
- dans quel contexte

3. Ajouter les fonctionnalites
- 4 a 6 fonctions principales

4. Ajouter les benefices
- 3 a 5 gains concrets

5. Rediger la FAQ
- 3 a 5 questions

6. Activer le CTA final

7. Ajouter seulement apres les blocs optionnels
- fonctionnement
- sections dynamiques
- contenus associes

## 7. Mini Check-list Avant Publication

- Le hero est-il clair en moins de 10 secondes de lecture ?
- Le module est-il bien rattache a la bonne solution ?
- Les fonctionnalites sont-elles concretes et distinctes ?
- Les benefices parlent-ils bien du resultat pour le client ?
- La FAQ repond-elle aux vraies objections ?
- Le CTA final est-il actif ?
- La fiche reste-t-elle lisible sans avoir besoin d'une section speciale ?

## 8. Regle De Gouvernance

Le modele standard doit suffire dans la majorite des cas.

Les sections dynamiques ou variantes plus riches ne doivent etre utilisees que si :
- le module a un vrai parcours metier a expliquer ;
- un visuel ou une mise en situation apporte une vraie comprehension ;
- le socle standard ne permet pas de bien presenter le module.

En resume :
- d'abord le modele commun ;
- ensuite seulement les exceptions utiles.