Pourquoi les sites web animés sont devenus si courants
Quand on construit une page d'accueil, on a envie qu'elle bouge. Ce réflexe est propre aux développeurs front, et chez Nualt, on n'y échappe pas. Une section qui reste à l'écran pendant que le visiteur fait défiler la page, une transition qui ouvre le contenu depuis le haut de page, une photo qui change au fil de la lecture : ces effets font une grande partie de ce qui distingue un site sur mesure d'un thème, et ils sont devenus accessibles à tout le monde.
Il y a quelques années, une animation au scroll un peu ambitieuse coûtait cher à écrire, et ce coût servait de garde-fou. Aujourd'hui, avec l'IA, on produit une section animée fonctionnelle en quelques minutes, avec un défilement fluide et des effets d'apparition par dessus. On en a parlé dans l'article sur les failles récentes de Next.js et lors de notre atelier sur les limites du vibe coding : plus un outil devient facile d'accès, plus il est utilisé sans que toute sa profondeur soit visible.
Ce que le responsive change pour un site animé
Pour un site web animé, cette profondeur apparaît au moment où la page est ouverte sur un autre écran que celui du designer. Un site classique se réorganise assez naturellement entre un grand écran, une tablette et un mobile. Une animation au scroll, elle, a besoin d'une certaine hauteur d'écran pour se dérouler, d'une souris pour certains effets, et d'une machine assez puissante pour rester fluide. Quand une de ces conditions manque, l'animation ne se dégrade pas toute seule : elle se casse.
Le responsive reste donc une contrainte permanente, et produire une animation en cinq minutes ne change rien au travail qu'il faut pour la faire tenir sur tous les écrans. On y pense simplement moins au moment de l'écrire.
Ce que nous avons observé sur un projet client
Le site en question est celui de L'Essence d'Être, un cabinet de coaching de dirigeants. Sa page d'accueil s'ouvre par une transition depuis le haut de page, puis enchaîne une section services qui reste à l'écran pendant le défilement et une colonne méthode dont la photo se remplace au fil de la lecture. Sur le MacBook où il a été construit, tout fonctionnait.
Puis le client l'a ouvert sur un ordinateur portable de 1366 × 768. La photo de la colonne méthode était coupée. Sur un iPad en paysage, la colonne fixe dépassait la hauteur de l'écran. Sur un autre portable, un bloc de couleur chevauchait la photo du haut de page. Avec les outils de développement ouverts sur le côté, la barre de navigation changeait de couleur au mauvais moment.
Chaque symptôme a reçu son correctif, une règle pour l'iPad en paysage, un plafond de hauteur pour le portable, un décalage manuel pour le bloc de couleur. Chaque correctif fonctionnait sur l'appareil visé et fragilisait le suivant. On a vite vu où cette logique menait : des seuils qui se multiplient, un JavaScript et un CSS qui ne s'activent plus tout à fait au même moment, et une liste d'appareils qui ne peut jamais être complète.
Le problème se trouvait en amont de la bibliothèque d'animation. La question de savoir où chaque animation devait exister n'avait pas été tranchée une fois pour toutes, et le JavaScript comme le CSS y répondaient chacun de leur côté.
responsive-motion : notre méthode pour des animations au scroll responsive, en open source
Plutôt que de continuer à empiler des correctifs, on a repris la question depuis le début et on en a fait une méthode. Restait à choisir la forme à lui donner. Les agents de code comme Claude Code, Codex ou Cursor font aujourd'hui partie du quotidien d'un développeur, et ils n'ont pas moins tendance que nous à ajouter une animation en cinq minutes et à oublier les petits écrans. Le format qui nous a paru le plus utile est donc un skill : un dossier de règles et de recettes que l'agent lit avant d'intervenir sur un site animé, et qui lui impose la même discipline qu'à nous.
Le résultat est publié dans responsive-motion, un dépôt public sous licence MIT. Il contient sept règles, un modèle en cinq niveaux, treize recettes de mise en page, des scripts de mesure pour six formats d'écran, et un fichier d'anti-patterns qui garde, pour chaque règle, l'erreur qui l'a produite. Les exemples sont écrits avec GSAP et Tailwind, mais chaque recette est d'abord une idée de mise en page et la syntaxe se transpose à d'autres bibliothèques.
Une fois installé, décrire le symptôme suffit à le déclencher, par exemple "la photo de la section fixe est coupée sur 1366 × 768". Le skill mesure d'abord, annonce les fichiers qu'il va toucher, intervient sur une section à la fois, puis vérifie sur les six formats. Il n'a pas le droit de reconstruire toute une page pour corriger une photo.
On le publie parce que ce problème n'est pas propre à notre projet, comme on l'avait fait pour la brique d'authentification de Medusa. Tous ceux qui construisent des sites animés avec un agent de code le rencontrent, et une méthode qui reste dans un dépôt privé ne sert qu'à un studio. C'est un travail en cours, issu d'un seul site avec une seule pile technique. Les recettes pour Framer Motion, Motion One ou les animations natives pilotées par le défilement manquent encore, et les résultats sur appareils réels qui contrediraient le modèle sont bienvenus. Le dépôt évoluera avec nos prochains projets, et avec ce que la communauté voudra y apporter.
Trois règles pour un site web animé qui tient sur tous les écrans
Le skill repose sur trois idées simples, que l'on peut appliquer à n'importe quel site animé, avec ou sans agent de code.
Raisonner en espace réellement disponible, pas en taille d'écran
On raisonne souvent en termes de résolution d'écran. En réalité, elle ne dit rien de l'espace dont dispose le site. Prenons un ordinateur portable vendu comme "15 pouces Full HD", soit 1920 × 1080. Windows y applique par défaut une mise à l'échelle de 125 % ou 150 % selon les modèles. À 150 %, le navigateur ne dispose plus que de 1280 × 720 pixels. Retirez la barre d'onglets, la barre d'adresse et parfois une barre de favoris, et la page dispose d'environ 1280 × 630 pixels. Une section pensée pour 800 pixels de haut ne tient pas. Un portable de 1366 × 768 ou un iPad en paysage perdent eux aussi une centaine de pixels de hauteur dans le navigateur.
Une liste d'appareils reste donc un indice insuffisant, puisque l'espace disponible dépend de l'échelle système, du navigateur et de ce que l'utilisateur a ouvert à côté. La méthode raisonne sur le plus petit espace possible dans chaque situation, et donne à chaque animation la hauteur en dessous de laquelle elle ne tient plus.
Décider une seule fois où une animation existe
Une animation existe ou n'existe pas selon un critère unique, qui combine la largeur de l'écran, sa hauteur, et la présence d'une vraie souris. Ce critère est écrit une fois, puis partagé entre le JavaScript qui lance l'animation et le CSS qui met la page en forme. C'est exactement ce qui manquait sur le site d'origine, où les deux décidaient chacun de leur côté.
À partir de ce critère, chaque section du site se trouve dans exactement un de cinq niveaux, et chaque niveau retombe sur une mise en page qui existe déjà.
- Scène. Grand écran, hauteur suffisante, vraie souris. L'animation joue en entier.
- Expansion seule. Grand écran et souris, mais hauteur insuffisante. La transition d'entrée joue à l'identique, ce qui suit défile normalement au lieu de rester fixe.
- Plat. Grand écran mais hauteur réduite ou écran tactile. La mise en page desktop, sans animation, une image par étape.
- Mobile. Écran étroit. La mise en page mobile, sans animation.
- Allégé. Réduction des animations activée dans le système, mode économie de données, ou machine peu puissante. Aucun effet, quel que soit le format.
Le niveau "expansion seule" est celui que l'on oublie. Sur un portable court avec une souris, on a tendance à tout couper. Or la transition d'entrée depuis le haut de page tient dans n'importe quel espace, puisqu'elle ne dépend pas de la hauteur de ce qui suit. Elle continue donc de jouer, et seule la section fixe lâche.
Le niveau "allégé" répond à une autre question que les quatre premiers. Eux parlent de format d'écran, lui parle de la machine et des préférences du visiteur. Un portable puissant mais court a droit à la transition d'entrée. Un visiteur qui a réduit les animations dans les réglages de son système n'a droit à aucun effet, même sur un grand écran. Mélanger les deux produit des sites qui coupent les animations sur un iPad Pro et les gardent sur un vieux PC de bureau.
Il n'y a pas de niveau "tablette", et c'est voulu. Quand une animation ne tient pas, elle retombe sur la mise en page desktop sans animation ou sur la mise en page mobile, deux versions qui existent déjà et qui ont déjà été testées.
Vérifier avec des chiffres, pas à l'œil
Regarder une page sur trois appareils et la trouver correcte ne suffit pas. Un chevauchement de quelques pixels passe inaperçu à l'œil et saute aux yeux du client sur son écran. Le skill vérifie donc chaque animation sur six formats d'écran, avec de petits scripts exécutés dans les outils de développement du navigateur. Ils mesurent les positions réelles des éléments et comparent les bords au pixel près, contrôlent que la section fixe tient dans la hauteur disponible, que les cartes d'une même ligne sont alignées, et que la barre de navigation prend la bonne couleur dans les deux sens de défilement.
On fait un tour complet des formats, on corrige tout ce qu'il révèle, on refait un tour de confirmation, et on s'arrête là. Sans cette borne, on retombe dans la boucle du correctif par appareil.
Chez Nualt, l'animation fait partie du projet, pas de la finition
Les animations au scroll ont leur place dans un site sur mesure. Elles participent à la première impression, elles guident la lecture et, comme on l'expliquait dans l'article sur l'impact du design, elles contribuent à la crédibilité que le visiteur accorde à une entreprise avant même de lire une ligne. Nous continuons donc d'en concevoir.
Ce projet a changé le moment où nous en décidons. La question de savoir sur quels écrans une animation existe se pose désormais au moment de la concevoir, avec les espaces réellement disponibles chez les visiteurs du client, et la réponse est écrite à un seul endroit du code. Sur les petits formats, le site retombe sur une mise en page qui a été dessinée et testée, jamais sur une version improvisée.
Le skill sert à conserver cette discipline d'un projet à l'autre, y compris quand une partie du code est produite avec un agent. Nous le mettrons à jour à mesure que d'autres sites nous apprendront quelque chose, et il est ouvert à ceux qui voudront y contribuer.
