Aller au contenu principal

Scenario Engine — CardFeed

Objectif​

Décrire une architecture où l’interface n’est plus pensée d’abord comme une page figée, mais comme l’exécution d’un scénario utilisateur qui produit un feed ordonné de cartes métier.

Cette architecture ne remplace pas immédiatement l’existant.

Elle sert de cadre pour les futurs POC et pour les parcours à forte dimension contextuelle ou assistée par IA.

Vocabulaire​

Page​

Une Page reste la couche d’entrée web classique :

  • URL ;
  • SEO ;
  • droits d’accès ;
  • métadonnées ;
  • analytics ;
  • contraintes de routing.

Une page ne décrit pas en détail la logique métier du contenu qu’elle affiche.

Elle héberge un scénario.

Scénario​

Un Scénario représente l’intention utilisateur.

Exemples :

  • “je veux suivre mon village” ;
  • “je veux trouver rapidement quelque chose” ;
  • “je veux explorer un acteur” ;
  • “je veux ouvrir mon espace personnel”.

Le scénario décide :

  • quelles familles d’informations sont utiles ;
  • dans quel ordre elles apparaissent ;
  • quelles cartes doivent être présentes, absentes ou prioritaires.

Feed​

Le Feed est une liste ordonnée de CardDescriptor.

Il ne contient pas directement du JSX.

Il décrit :

  • quelle carte afficher ;
  • avec quelles données ;
  • avec quelle priorité ;
  • avec quelles contraintes d’affichage éventuelles.

Card​

Une Card est un composant métier indépendant.

Une carte :

  • a une responsabilité claire ;
  • connaît uniquement son propre contrat ;
  • peut être réutilisée dans plusieurs scénarios ;
  • ne connaît pas la page complète ;
  • ne décide pas seule de l’ordre global du feed.

IA​

L’IA est un composeur de scénarios, pas un générateur d’UI.

Elle peut :

  • proposer un scénario ;
  • réordonner des cartes ;
  • sélectionner des sources pertinentes ;
  • adapter un parcours à une intention.

Elle ne doit pas :

  • inventer librement des composants ;
  • générer du JSX produit ;
  • contourner les règles de design système ;
  • modifier la structure UI sans cadre produit explicite.

Modèle cible​

Page
  ↓
Scenario
  ↓
Feed<CardDescriptor>
  ↓
Cards métier

Exemple de contrat mental​

Page = "où suis-je ?"
Scénario = "qu’est-ce que l’utilisateur veut faire ici ?"
Feed = "dans quel ordre dois-je lui montrer les blocs ?"
Card = "comment un bloc métier donné se rend-il ?"
IA = "comment choisir/composer le bon scénario ?"

Règles strictes​

1. La page ne porte pas la logique métier fine​

La page gère :

  • URL ;
  • SEO ;
  • droits ;
  • shell global éventuel.

La logique métier détaillée doit vivre dans le scénario, les sources ou les cartes.

2. Le scénario décrit une intention, pas un layout arbitraire​

Un scénario n’est pas un nom de page technique.

Un bon scénario exprime un besoin utilisateur.

Exemples acceptables :

  • follow_my_village
  • search_local_results
  • discover_actor
  • open_my_space

3. Le feed décrit, il ne rend pas​

Le feed produit des descripteurs, pas du HTML ni du JSX libre.

Un CardDescriptor doit rester typé, contrôlé et compatible avec les widgets réels disponibles.

4. Les cartes sont finies et contrôlées​

Une carte doit appartenir à un catalogue explicite de composants métier.

L’IA ou le scénario ne créent pas une nouvelle carte “à la volée”.

5. L’IA ne décide jamais seule de l’UI​

L’IA peut composer.

Elle ne peut pas sortir du cadre des cartes, règles de tri, droits et scénarios autorisés.

6. Le produit reste déterministe​

À données égales et règles égales, le rendu doit rester explicable, testable et audit-able.

7. Aucun contournement de la règle de parité MurVille​

Tant que MurVille public repose sur son architecture stabilisée actuelle :

  • il est interdit de migrer MurVille immédiatement vers ce modèle ;
  • aucun POC Scenario Engine — CardFeed ne doit dégrader la parité atteinte ;
  • MurVille ne sert pas de terrain d’expérimentation initial.

Avantages​

  • sépare clairement intention utilisateur et rendu ;
  • facilite la composition de parcours personnalisés ;
  • rend l’IA utile au niveau métier, sans lui déléguer l’UI ;
  • permet de réutiliser une même carte dans plusieurs surfaces ;
  • favorise une architecture mobile-first orientée feed ;
  • simplifie la priorisation et la réorganisation des blocs ;
  • ouvre la voie à des expériences “Mon espace”, recherche ou mini-sites plus modulaires.

Limites​

  • demande un catalogue de cartes bien défini ;
  • introduit une couche d’orchestration supplémentaire ;
  • peut devenir abstrait si appliqué trop tôt à des pages simples ;
  • nécessite des règles de tri, priorité et fallback explicites ;
  • ne remplace pas le besoin de design produit ;
  • ne doit pas devenir un prétexte pour laisser l’IA piloter l’interface.

Exemples DMV​

1. MurVille​

Lecture recommandée :

  • MurVille actuel reste un mur public stabilisé ;
  • son architecture est aujourd’hui gouvernée par la parité et la non-régression ;
  • il ne doit pas être la première cible du Scenario Engine — CardFeed.

Usage éventuel plus tard :

  • un scénario public follow_commune_feed ;
  • un feed de cartes alerte, publication, agenda, collecte, acteur.

Mais ce n’est pas la phase actuelle.

2. Recherche​

La recherche est une bonne candidate :

  • intention claire ;
  • résultats potentiellement hétérogènes ;
  • besoin naturel de réordonner par pertinence ;
  • bonne compatibilité avec une IA composeuse de scénario.

Exemple :

  • scénario search_local_results
  • feed mélangeant cartes publication, acteur, événement, commune, service.

3. Mon espace​

Mon espace V2 est aussi une bonne candidate :

  • intention fortement contextuelle ;
  • besoin de composition selon la personne, la commune, les favoris, les signaux ;
  • architecture déjà proche d’un moteur de contexte.

Exemple :

  • scénario open_my_space
  • feed combinant cartes contexte personnel, publication, favori, événement, recommandation plus tard.

4. Mini-site acteur​

Un mini-site acteur peut bénéficier de cette approche :

  • intention “découvrir cet acteur” ;
  • blocs hétérogènes mais connus ;
  • ordre potentiellement piloté par usage ou type d’acteur.

Exemple :

  • scénario discover_actor
  • feed de cartes hero, infos, publications, événements, services, contact.

Stratégie POC recommandée​

Option 1 — Mon espace V2​

Avantages :

  • terrain déjà expérimental ;
  • architecture Context Engine déjà présente ;
  • pas de contrainte SEO forte ;
  • personnalisation naturelle.

Option 2 — Recherche intelligente​

Avantages :

  • forte valeur produit ;
  • très bonne compatibilité avec une logique scénario + cartes ;
  • bon terrain pour l’IA composeuse.

Recommandation​

Le meilleur POC initial est :

  • Mon espace V2 si l’objectif est d’explorer la composition contextuelle ;
  • Recherche intelligente si l’objectif est d’explorer la composition pilotée par intention et pertinence.

Dans les deux cas :

  • garder un périmètre restreint ;
  • définir un petit catalogue de cartes ;
  • éviter tout couplage immédiat avec MurVille public.

Interdiction explicite​

Il est interdit de migrer MurVille immédiatement vers Scenario Engine — CardFeed.

Motifs :

  • MurVille public vient d’atteindre sa parité ;
  • le chantier MurVille est désormais gouverné par la non-régression ;
  • ce nouveau modèle doit être éprouvé ailleurs avant toute bascule.

Décision pratique​

Avant tout nouveau développement basé sur cette architecture, poser la question suivante :

Sommes-nous en train de définir une nouvelle Page, un nouveau Scénario, un nouveau Feed ou une nouvelle Card ?

Si la réponse est floue, l’architecture n’est pas encore suffisamment définie pour être implémentée.