site-motion : Évaluation de l'animation de site et sélection de…

site-motion : Évaluation de l'animation de site et sélection de version

Lorsqu'un utilisateur dit que le site est « rigide », le problème n'est généralement pas le manque d'animation, ni forcément la lenteur de chargement, mais le fait que chaque action nécessite de quitter la page et de recommencer, et que la page est constituée de blocs sans lien les uns avec les autres. Il faut donc d'abord identifier le problème, puis décider quoi animer.

Répondez dans le langage de l'utilisateur. Conservez les termes techniques en anglais.

Principes

1. Ne pas toucher au code de production avant la sélection : fournissez d'abord un diagnostic, des solutions et un prototype ; ne commencez l'implémentation qu'après que l'utilisateur a clairement choisi une version.
2. Ne pas modifier la mise en page par défaut : sans demande explicite, ne changez ni les couleurs, ni la typographie, ni la mise en page. Seulement les interactions. Changer le style global du site est une autre tâche.
3. Mobile-first : évaluez et validez sur une largeur de 375 px ; le bureau est un ajout.
4. Une animation doit être cliquable pour compter : les images statiques ne rendent pas compte de la sensation. Les versions doivent être des prototypes fonctionnels.
5. Chaque animation doit avoir un but : il faut pouvoir expliquer à quel problème de l'utilisateur elle répond, par exemple « Ai-je cliqué ? », « D'où viens-je ? », « Les données ont-elles été mises à jour ? ». Si ce n'est pas le cas, supprimez-la.
6. Pour les sites qui vivent de la recherche et de la publicité, le SEO et la monétisation priment sur l'esbroufe : l'animation ne doit pas remplacer les URL indépendantes, le contenu HTML de la première page ni la visibilité des annonces. Les backends et outils internes après connexion ne sont pas concernés par cette règle.
7. Changement de contenu = vraie page ; ajustement du même contenu = reste sur place : voir un autre article nécessite une nouvelle page (nouvelle URL et demande de pub) ; le développement, le filtrage et le tri se font sur place.
8. L'animation ne doit pas franchir les limites du site : vérifiez d'abord les directives et les contraintes légales du projet. N'utilisez pas de champs vides pour des effets visuels, n'utilisez pas l'animation pour suggérer des informations non fondées.

Procédure

Étape 1 : Déterminer de quel type de dynamique il s'agit

« Dynamique » peut recouvrir quatre choses, avec des solutions complètement différentes.

Type	Ce que l'utilisateur pourrait dire	Ce qu'il faut réellement faire
Dynamique de données	Le contenu doit se mettre à jour tout seul, en temps réel	Cron, API, polling : travail backend principal, accompagné de signaux de mise à jour
Dynamique de feedback	Je ne sens pas le clic, c'est trop mort	Effet d'enfoncement, changement d'état, scintillement de mise à jour
Dynamique continue	Ça saute de page en page, c'est primitif, on dirait un ensemble d'objets	Transitions de page, déploiement sur place, éléments partagés, gestes
Animation narrative	La page d'accueil doit avoir de l'impact, effet de défilement, GSAP	Animation Hero, narration au défilement, moment de marque

S'il s'agit clairement d'une dynamique de données, expliquez directement que ce n'est pas un problème d'animation et optez pour une solution de données. Dans les autres cas, ne posez pas de questions, passez directement à l'étape 2 et répondez avec des observations concrètes.

Étape 2 : Observer l'état actuel

Lorsque vous avez accès au code source du projet, exécutez depuis le répertoire racine de ce skill :

python3 scripts/motion_audit.py <chemin_du_projet>

Les résultats du script sont des indices, pas un verdict : vérifiez chaque élément trouvé.

Si vous pouvez ouvrir un navigateur, parcourez le parcours principal en 375 px : page d'accueil, page intérieure, changement d'onglet, clic sur un élément de liste, retour en arrière. Notez les sensations réelles :

• Quelles actions entraînent un rechargement complet de la page, et lesquelles sont des changements sur place
• La page forme-t-elle un tout, ou un ensemble de blocs indépendants
• L'utilisateur voit-il les mises à jour de données
• Le feedback est-il retardé, y a-t-il des animations qui vont à contresens (par exemple, des chiffres qui sautent à chaque entrée dans la page)

Si le site n'existe pas (nouveau site), ou si le projet n'est qu'une coquille vide sans pages réelles : lisez les documents de planification, déterminez le type de site, passez à l'étape 3, et précisez qu'il est impossible de diagnostiquer l'écran réel à ce stade.

Si vous n'avez ni le site ni le code : utilisez les informations fournies par l'utilisateur pour continuer, en indiquant clairement que les « problèmes » sont des déductions, et en listant les données manquantes sous « non vérifié ». N'inventez pas d'observations.

Étape 3 : Définir le ton en fonction du type de site

Type de site	Objectif principal	Éviter
Sites de données et d'outils (scores, requêtes, tableaux de bord)	Dynamique continue, signaux de mise à jour, densité	Apparition progressive au défilement, animations qui cachent les données
Sites de contenu et d'articles	Feedback léger, lecture ininterrompue	Toute animation qui gêne la lecture ou pousse les publicités
Pages de marque et marketing	Un moment de narration soigné	Animer partout
Services de type application	Gestes, opérations sur place, continuité d'état	Changer la peau sans modifier l'interaction
Backend et outils internes après connexion	Feedback, changements d'état, réduction des changements de page	Animations qui ralentissent les actions répétitives

Étape 4 : Concevoir 2 à 3 versions

Consultez references/recipes.md pour choisir les effets et les paramètres, et references/pitfalls.md pour évaluer les risques.

Passez d'abord par la porte de navigation : elle détermine quelle méthode de changement de page peut être proposée :

Situation du site	Méthode de navigation
Le site a ou aura des publicités display (ex. AdSense)	Par défaut, utilisez @view-transition cross-document, conservez les vraies pages ; le comportement des publicités et des analyses reste inchangé
Le site a déjà des publicités automatiques, ancrées, interstitielles, ou l'on ne peut pas vérifier le comportement des annonces après un changement de page	La navigation douce dans le même document n'est pas recommandée ; si elle est listée, elle doit être assortie d'une mention de test réel et d'une solution de repli
Pas de publicité, ou publicité et analyse déjà vérifiées	Navigation douce dans le même document ou routage framework autorisé ; vérifiez tout de même que les analyses et l'état de connexion sont normaux après un changement de page

Si un site existant utilise déjà une navigation douce et se prépare à mettre des publicités, mentionnez ce point dans la section « Où est le problème », ne le considérez pas comme résolu.

Les versions doivent présenter des différences substantielles, et ces différences doivent porter sur le périmètre des interactions, pas sur les couleurs. L'échelle part de l'état actuel du site ; ne répétez pas les éléments déjà en ligne. Échelle par défaut :

• A : Version légère et tactile : ne touche pas à l'architecture de navigation, ajoute seulement du feedback et des signaux de mise à jour. Risque le plus faible, réalisable dans la journée.
• B : Version continue : A + transitions de page, éléments partagés, déploiement sur place. La méthode de navigation est déterminée par la porte. Généralement la version recommandée.
• C : Version complète « sensation d'application » : B + gestes de glissement, changement de données sur place, notifications en temps réel, ou moment narratif pour les sites de marque. Sensation la plus forte, coût et risque les plus élevés.

Les versions doivent passer le filtre du type de site à l'étape 3 : un site de contenu et d'articles s'arrête généralement à A ou à un B léger. Si deux versions seulement diffèrent vraiment, donnez-en deux ; n'en rajoutez pas pour faire du nombre. Si A couvre déjà tous les besoins, dites-le clairement. Le coût de l'ingénierie d'animation doit être proportionné aux revenus du site.

Étape 5 : Créer un prototype cliquable

Suivez references/prototype.md. Le prototype utilise des données réelles et l'apparence existante, avec un fichier permettant de basculer entre les versions, et doit être testé physiquement en largeur mobile avant d'être livré. Commencez par assets/prototype-template.html.

Étape 6 : Proposer

Répondez selon le « Format de sortie » ci-dessous, puis demandez à l'utilisateur de choisir une version. Utilisez un outil de sélection si l'environnement le permet ; sinon, listez les options numérotées, la version recommandée en premier. La règle « ne pas poser de questions » de l'étape 1 s'applique uniquement à la phase de diagnostic ; ici, il faut marquer une pause et attendre le choix.

Étape 7 : Implémenter et valider

Ne commencez qu'après que l'utilisateur a fait son choix. Suivez l'ordre de references/acceptance.md pour implémenter et effectuer la validation. Lorsque vous passez le relais à un autre agent, utilisez le modèle de transition de ce fichier.

Format de sortie

La proposition utilise cette structure, courte et concrète :

## Évaluation de l'animation : <nom du site>

**Où est le problème**
<2 à 4 points, chacun étant un phénomène observé, avec l'emplacement dans la page. Ne dites pas « manque d'interaction » de manière vague.>

**Comparaison des versions**
| | A : Légère et tactile | B : Continue | C : Complète « sensation d'application » |
|---|---|---|---|
| Ce que l'utilisateur ressentira | | | |
| Principales modifications | | | |
| Volume de travail | Nombre de fichiers et temps approximatif | | |
| Risque SEO et CWV | Faible / Moyen / Élevé, avec une raison | | |
| Impact sur la publicité et les analyses | Préciser la méthode de navigation et les prérequis | | |
| Coût de maintenance | | | |

**Recommandation** : <lequel choisir, avec une seule raison ; s'il y a des prérequis, les mentionner>

**Prototype** : <lien ou chemin, et lister 3 à 5 actions à tester>

**Modifications de mise en page** : <éléments nécessitant l'accord de l'utilisateur ; écrire « Aucun » s'il n'y en a pas>

**Non proposé** : <éléments demandés par l'utilisateur mais non réalisés cette fois, avec la raison ; omettre s'il n'y en a pas>

**Ne sera pas touché** : <mise en page, couleurs, URL, limites SEO, etc.>

**Non vérifié** : <éléments non testés, ex. comportement réel des publicités, sensation sur un vrai appareil>

Si vous ne proposez que deux versions, supprimez les colonnes inutiles du tableau. Indiquez des chiffres concrets pour le volume de travail, par exemple « modifier 4 à 5 fichiers », et expliquez clairement la raison du risque, ne vous contentez pas d'écrire « faible ». Précisez si les chiffres sont mesurés ou estimés. Lorsque la demande de l'utilisateur est bloquée par une condition, expliquez clairement ce qui bloque, dans quelles conditions elle peut être reprise, et donnez une alternative. La version recommandée doit être basée sur la porte de navigation et les conditions de performance ; elle ne doit pas nécessairement être B.

Fichiers de référence

Fichier	Quand le lire
references/recipes.md	Étape 4 : choisir les effets et les paramètres
references/pitfalls.md	Étape 4 : évaluer les risques ; Étape 7 : implémenter
references/prototype.md	Étape 5
references/acceptance.md	Étape 7 : y compris le modèle de transition
assets/prototype-template.html	Modèle de départ pour le prototype