Lottie React Native

Vous êtes probablement dans l’une de ces deux situations. Soit un designer vous remet un JSON Lottie en demandant « On peut l’intégrer à l’app aujourd’hui ? », soit vous avez déjà branché l’animation et vous avez remarqué qu’elle fonctionne en développement, mais devient coûteuse dès qu’on parle d’appareils réels, de temps de démarrage et de builds de release.

C’est là que Lottie React Native devient intéressant. La démo de base est facile. Une implémentation prête pour la production, beaucoup moins. La différence tient souvent à la façon dont vous l’installez, à la façon dont vous contrôlez la lecture, et à la manière dont vous considérez les fichiers d’animation : de simples assets anodins, ou une part de votre budget de performance.

Table des matières

Pourquoi Lottie est indispensable pour les apps React Native
- Le design et l'ingénierie ne mènent plus le même combat
- Où Lottie est le plus pertinent
Configurer votre environnement de développement Lottie
Afficher votre première animation Lottie
Maîtriser les contrôles d'animation Lottie
Optimisation des performances des apps en production
Dépannage des problèmes Lottie courants

Pourquoi Lottie est indispensable pour les apps React Native

Si vous avez déjà essayé de recréer à la main une animation produit soignée dans React Native, vous connaissez la douleur. Les petits détails de mouvement se transforment en une pile de logique de timing, d'interpolations et de spécificités de plateforme. L'animation peut sembler proche, mais « proche » n'est généralement pas ce que le designer a livré.

Lottie a changé ce workflow. Airbnb a open source Lottie en 2016, et cette release a transformé l'animation mobile en permettant aux designers de livrer des animations directement, au lieu de forcer les ingénieurs à les reconstruire image par image. Dans certains contextes d'entreprise, ce changement a réduit les coûts de développement d'apps mobiles de jusqu'à 40 %, selon les Aperçu de Lottie par Airbnb.

Le design et l'ingénierie ne mènent plus le même combat

L'un des principaux atouts de Lottie React Native, ce n'est pas seulement de « jolies animations en JSON ». C'est la séparation des préoccupations. Les designers travaillent dans After Effects et exportent avec Bodymovin. Les développeurs restituent le résultat avec une lecture native au lieu de traduire le mouvement en code personnalisé.

C'est important, car le travail d'animation a tendance à s'étendre. Une seule animation d'état de célébration peut toucher la revue design, la revue produit, le comportement sur Android, le comportement sur iOS, l'accessibilité et les performances au démarrage. Lottie réduit cette surface d'impact.

Règle pratique : Utilisez Lottie lorsque l’animation fait partie de l’expérience produit, et non si vous avez seulement besoin d’une simple transition d’opacité ou de translation.

Il y a aussi un angle expérience utilisateur. Le mouvement donne un retour, confirme les actions et rend les états de chargement moins statiques. Si votre équipe réfléchit sérieusement au polish, à la rétention ou à la confiance dans l’interface, l’animation fait partie de cette réflexion. La discussion plus large sur l’expérience utilisateur des applications aboutit généralement au même constat : un retour rapide vaut mieux que des écrans statiques.

Où Lottie est le plus pertinent

Lottie React Native fonctionne le mieux pour :

Micro-interactions de marque comme les likes, les sauvegardes, les coches et les états de succès d’achat
Illustrations d’onboarding qui doivent paraître sur mesure sans envoyer de vidéo
États de chargement et vides où l’interface statique semble incomplète
Présentation de la fonctionnalité quand le produit veut du mouvement sans intégrer de GIF ou MP4

Ce qu’il ne résout pas, c’est tous les problèmes d’animation. Pour les transitions d’écran basiques, les outils d’animation de React Native sont souvent plus simples. Pour des systèmes de motion très volumineux ou hautement interactifs, le format JSON peut devenir un compromis plutôt qu’un avantage. Ce compromis prend de l’importance une fois en production, là où la plupart des tutoriels s’arrêtent trop tôt.

Configurer votre environnement de développement Lottie

Le chemin d’installation dépend d’abord d’une décision : Workflow Expo managé ou React Native bare. Ne mélangez pas les modèles mentaux. La plupart des problèmes de configuration surviennent quand les développeurs suivent un guide bare dans Expo, ou supposent qu’Expo abstrait chaque détail natif.

Un organigramme montrant les étapes de configuration des animations Lottie dans les projets Expo et React Native bare.

Choisissez le workflow avant d’installer

Si votre app est dans Expo et que vous voulez la configuration la plus rapide, restez sur le chemin Expo sauf si vous savez que vous avez besoin de travail natif personnalisé. Si vous êtes dans une app bare, ou si vous dépendez déjà de modules natifs nécessitant un contrôle direct, installez-le comme une dépendance native normale et validez immédiatement les builds iOS et Android.

Beaucoup d’équipes sous-estiment à quel point le débogage devient plus facile quand on garde sa configuration alignée avec le type de projet. C’est aussi pourquoi beaucoup d’équipes construisant des intégrations natives personnalisées comparent Capgo comme alternative à Expo EAS tôt, plutôt que d'attendre que l'app devienne plus difficile à modifier.

Configuration gérée par Expo

Pour les apps gérées par Expo, restez minimaliste.

Installer le package
```
npx expo install lottie-react-native
```
Redémarrer Metro
```
npx expo start -c
```
Vérifier sur un appareil ou un simulateur Commencez par un fichier JSON local et affichez d'abord une toute petite animation. Ne déboguez pas en même temps un asset volumineux et une nouvelle installation.

Quelques points pratiques à retenir avec Expo :

Privilégiez d'abord les fichiers locaux : Le débogage d'animations à distance ajoute du bruit réseau alors que vous essayez simplement de prouver que la librairie fonctionne.
Testez tôt le comportement en release : Le mode développement peut masquer des problèmes liés au timing et aux performances.
Chemin des assets : Les fichiers JSON mal placés sont l’une des causes les plus fréquentes du « rien ne s’affiche ».

Expo est le chemin le plus rapide vers « ça marche ». Mais pas forcément vers « ça scale ».

Configuration Bare React Native

Dans un projet bare, installez et validez les dépendances natives immédiatement.

Installer le package
```
npm install lottie-react-native
```
Installer les pods iOS
```
cd ios && pod install && cd ..
```

Recompiler l'application

npx react-native run-ios

npx react-native run-android

Voici l'étape que beaucoup de guides de démarrage rapide passent sous silence : après l'installation, effectuez un rebuild natif complet avant de conclure que quelque chose est cassé. Le hot reload ne sauvera pas une dépendance native qui n'a pas été correctement compilée dans l'app.

Vérifications Bare workflow qui font gagner du temps

Utilisez cette courte checklist avant de continuer :

Vérifier	Pourquoi c'est important
Recompiler après l'installation	Native modules need a fresh compile
Exécutez `pod install`	iOS ne sera pas fiable sans cela
Utilisez d’abord un JSON local simple	Isoler les problèmes d’installation des problèmes d’assets
Tester les deux plateformes tôt	Android et iOS peuvent échouer pour des raisons différentes

Si le package s’installe correctement mais que votre première animation ne s’affiche pas, ce n’est généralement pas un problème d’installation. C’est souvent le chemin de l’asset, la taille du composant ou la configuration de lecture.

Afficher votre première animation Lottie

La première animation fonctionnelle doit être ennuyeuse. Fichier local. Taille fixe. Lecture automatique activée. Boucle facultative. Ne démarrez pas avec une lecture conditionnelle, un JSON distant ou un export d’animation avec beaucoup de calques.

Un espace de travail de développeur moderne avec un ordinateur portable affichant code et un moniteur montrant une application d’animation mobile.

Ajouter un fichier d’animation local

Créez un dossier d’assets si vous n’en avez pas encore :

assets/
  animations/
    success.json

Gardez les noms simples. Évitez les espaces, la ponctuation inhabituelle et les dossiers trop imbriqués. Vous voulez require() chemins restent clairs.

Si vous utilisez Lottie pour un écran de chargement initial à l’image de la marque ou une transition après le lancement, réfléchissez bien avant d’insérer une grande animation dans le chemin de démarrage. C’est surtout vrai si vous ajustez aussi le comportement de l’écran de démarrage React Native.

L’afficher avec LottieView

Créez un composant dédié au lieu de l’insérer directement dans un fichier d’écran volumineux :

import React from 'react';
import { View, StyleSheet } from 'react-native';
import LottieView from 'lottie-react-native';

export function SuccessAnimation() {
  return (
    <View style={styles.container}>
      <LottieView
        source={require('../assets/animations/success.json')}
        autoPlay
        loop={false}
        style={styles.animation}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    alignItems: 'center',
    justifyContent: 'center',
  },
  animation: {
    width: 220,
    height: 220,
  },
});

Cela fait trois choses utiles :

cela prouve que la bibliothèque s’affiche correctement
elle prouve que le chemin de l’asset se résout correctement
elle vous offre un endroit isolé pour ajuster la lecture et la taille plus tard

Quelques pièges apparaissent immédiatement si vous sautez les bases :

Pas de largeur ni de hauteur : L’animation peut exister mais rester invisible.
Mauvais require() chemin : Metro ne trouvera pas le fichier.
Export invalide : Certains fichiers JSON sont techniquement valides mais incluent des fonctionnalités qui ne se comportent pas comme prévu sur mobile.

Gardez le premier rendu local et déterministe. Vous testez l’intégration, pas l’architecture.

Un meilleur test du premier écran

Placez le composant sur un écran simple avec un fond neutre :

import React from 'react';
import { SafeAreaView, StyleSheet } from 'react-native';
import { SuccessAnimation } from './src/SuccessAnimation';

export default function App() {
  return (
    <SafeAreaView style={styles.screen}>
      <SuccessAnimation />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  screen: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
  },
});

Si cela fonctionne sur les simulateurs iOS et Android, vous avez franchi le premier vrai obstacle. L’étape suivante ne consiste pas à ajouter plus d’animations, mais à savoir quand utiliser des props déclaratives et quand prendre le contrôle direct avec des refs.

Maîtriser les contrôles d'animation Lottie

La plupart des bugs Lottie React Native apparaissent quand l’animation doit réagir à l’état. L’autoplay est simple. « Jouer ce segment quand l’utilisateur like un élément, l’inverser quand il unlike, et éviter les saccades lors du re-render du composant » : c’est là que ça se complique.

Un tableau comparatif expliquant les méthodes de contrôle d’animation déclaratives et impératives dans Lottie, en mettant en avant leurs cas d’usage spécifiques.

Utilisez les props quand la lecture est simple

Pour une lecture non interactive, les props suffisent.

<LottieView
  source={require('../assets/animations/loading.json')}
  autoPlay
  loop
  speed={1}
/>

Ce style convient pour :

indicateurs de chargement
illustrations passives d’onboarding
états vides décoratifs

C’est déclaratif et lisible. Le composant monte, la lecture démarre, et React reste aux commandes. Si la logique d’animation peut être décrite entièrement par des props, gardez-la là.

Un cas déclaratif plus avancé est progress, où vous liez le frame d’animation à une autre valeur. Cela fonctionne bien lorsque le mouvement doit refléter une source de progression externe, mais c’est moins pratique pour des événements déclenchés ponctuellement.

Voici une comparaison visuelle rapide avant de passer aux refs :

Utilisez les refs quand l'état pilote l'animation

Lorsque l’utilisateur tape, bascule ou complète une action, une ref est généralement l’outil le plus sûr. Les données du terrain montrent que 68 % des développeurs utilisant des frameworks hybrides signalent des déclenchements d’animation échoués en raison d’un mauvais traitement des refs dans useEffect les hooks, ce qui explique pourquoi des patterns fiables construits autour de animation.current.play() comptent, comme le souligne cette discussion centrée sur Capacitor concernant les déclenchements échoués.

Ce problème ne se limite pas aux applications hybrides. Il apparaît aussi dans React Native pur, surtout lorsque les développeurs recréent des refs, déclenchent la lecture avant le mount ou lient les appels d’animation à des effets instables.

import React, { useRef, useState } from 'react';
import { Pressable } from 'react-native';
import LottieView from 'lottie-react-native';

export function LikeButton() {
  const animationRef = useRef<LottieView>(null);
  const [liked, setLiked] = useState(false);

  const onPress = () => {
    if (!animationRef.current) return;

    if (liked) {
      animationRef.current.play(60, 0);
    } else {
      animationRef.current.play(0, 60);
    }

    setLiked(!liked);
  };

  return (
    <Pressable onPress={onPress}>
      <LottieView
        ref={animationRef}
        source={require('../assets/animations/like.json')}
        loop={false}
        autoPlay={false}
        style={{ width: 96, height: 96 }}
      />
    </Pressable>
  );
}

Un pattern fiable pour le like et l’unlike

Ce modèl’est plus robuste en production que d’appeler play() à l'intérieur useEffect à chaque changement d’état.

Pourquoi ça marche :

L’événement possède le déclencheur de l’animation : Un événement de pression est un moment stable pour démarrer la lecture.
La ref reste locale et persistante : useRef évite les rerenders inutiles.
Le composant évite les conflits d’autoplay : You don’t want mount behavior fighting user-triggered behavior.

Erreurs courantes à éviter :

Déclencher avant que la ref n’existe
Si animationRef.current est null, la lecture ne se déclenchera pas. Protégez-le.
Utiliser autoPlay avec des contrôles impératifs
Choisissez un propriétaire par défaut pour la lecture.
Driving everything through useEffect
Les effets sont utiles, mais pour les actions UI, ils ajoutent souvent des problèmes de timing au lieu de les résoudre.

Si une animation réagit à un tap, déclenchez-la d’abord dans le handler du tap. Privilégiez useEffect uniquement lorsque la source de vérité se trouve en dehors de cette interaction.

Optimisation des performances des apps en production

Lottie React Native est de ces bibliothèques qui semblent légères jusqu’à ce que les équipes commencent à intégrer de gros fichiers JSON dans le bundle de l’app et se demandent pourquoi le démarrage a régressé. L’animation elle-même n’est pas toujours le problème. C’est la stratégie de livraison.

Une infographie détaillant trois avantages clés de l’optimisation des performances de Lottie : réduction de la taille du bundle, amélioration des fps et baisse de l’utilisation mémoire.

Où les équipes rencontrent des problèmes

L’erreur la plus courante consiste à intégrer toutes les animations directement dans le JavaScript et à les charger trop tôt. Selon ce guide sur une intégration incorrecte des fichiers Lottie JSON, surcharger les bundles JS avec des assets comme des JSON Lottie peut augmenter les temps de démarrage de l’app de 40 % ou plus sur les appareils milieu de gamme, et les déplacer vers des assets natifs pour un chargement à la demande est une optimisation essentielle.

Cela correspond à ce que beaucoup d’équipes constatent en pratique. Le problème ne vient pas d’une petite animation de succès isolée. C’est l’accumulation :

animations d’onboarding
états de chargement
réactions e-commerce
écrans vides personnalisés
fichiers de localisation et autres assets qui alourdissent le bundle, à côté

Si votre application a déjà un problème de budget au démarrage, les fichiers Lottie peuvent l’aggraver rapidement.

Quoi optimiser en priorité

Commencez par l’export lui-même. Un export d’animation bâclé entraîne une complexité que vous paierez plus tard en parsing, mémoire et stabilité du rendu. N’acceptez pas chaque export du designer tel quel.

Utilisez cette checklist de production :

Compressez le JSON avant de déployer : Des fichiers plus petits sont plus faciles à charger et moins susceptibles d’alourdir le démarrage.
Déplacez les animations non critiques hors du bundle JS : Concentrez le code de lancement sur ce dont l’application a immédiatement besoin.
Chargez les animations à la demande : Affichez l’animation quand l’écran ou l’action en a besoin.
Audit du comportement sur les anciens appareils : Un simulateur moderne peut masquer le coût de la lecture.
Évitez d'utiliser de gros fichiers Lottie comme décoration au démarrage : Si ce n'est pas critique pour la première interaction, cela ne doit pas ralentir le lancement de l'app.

Pour les équipes qui travaillent sérieusement sur la performance mobile, Le guide de la performance mobile d'AppLighter est une lecture complémentaire utile, car il replace les choix d'animation dans le contexte global du démarrage, du rendu et des compromis du framework.

Une vérité qui dérange : Une animation magnifique qui retarde la première interaction est généralement un bug produit, pas une victoire de design.

Ne vous limitez pas non plus à React Native seul. Les équipes qui travaillent sur des stacks hybrides rencontrent les mêmes problèmes de chargement d'assets, et les conseils de performance pour les animations des apps Capacitor s'appliquent aussi très bien aux choix Lottie.

Fichiers locaux vs livraison à distance

Les fichiers locaux sont prévisibles. Ils fonctionnent hors ligne, éliminent la variabilité du réseau et sont plus faciles à tester. Ils facilitent aussi le surdimensionnement des bundles.

La livraison à distance allège le binaire, mais votre animation doit désormais gérer la disponibilité, le cache et le fallback. Ce compromis est acceptable pour des animations non critiques. Il est risqué pour des états UX principaux comme la confirmation d'achat ou une authentification réussie.

Une répartition pratique fonctionne bien :

Type d'asset	Meilleur choix par défaut
Animation d'interaction principale	Local, optimisé, non surdimensionné
Animation promotionnelle occasionnelle	À distance avec fallback
Animation du parcours de démarrage	Local uniquement si absolument nécessaire
Illustration d'une fonctionnalité peu utilisée	Chargement à la demande

Si vous n’appliquez qu’une seule règle de cette section, choisissez celle-ci : treat Lottie JSONs as performance-sensitive assets, not harmless decoration.

Dépannage des problèmes Lottie courants

Quand Lottie plante, la cause est souvent banale. Mauvais chemin. Taille manquante. Timing de ref incorrect. JSON trop lourd. La façon la plus rapide de déboguer est de réduire les variables.

L'animation ne s'affiche pas sur Android

D’abord, vérifiez que le fichier JSON est bien résolu. Ensuite, donnez des dimensions explicites au composant.

<LottieView
  source={require('../assets/animations/success.json')}
  autoPlay
  style={{ width: 200, height: 200 }}
/>

Si ça échoue encore, remplacez-le par une autre animation connue pour fonctionner. Cela vous dira si le problème vient du fichier ou de la configuration.

La lecture est saccadée sur les anciens appareils

Cela pointe généralement vers l’asset, pas vers le composant API.

Essayez ces correctifs :

Réduisez la complexité de l’animation : Demander un export plus léger si le fichier source est lourd.
Charger plus tard : Ne pas concurrencer le travail sur l’écran initial.
Tester une version compressée : Si le fichier compressé se comporte mieux, vous avez trouvé le goulot d’étranglement.
Supprimer plusieurs vues Lottie simultanées : Plusieurs animations sur un même écran peuvent être trop lourdes.

La ref est null ou play ne fait rien

Les refs null indiquent généralement que le trigger se déclenche avant le montage, ou que le composant a été retiré conditionnellement.

if (animationRef.current) {
  animationRef.current.play();
}

Gardez la ref stable avec useRef, et ne recréez pas le composant animé inutilement. Si vous déboguez des bizarreries récurrentes dans les builds locaux, vider les caches obsolètes peut aider. Un simple nettoyage du cache Yarn suffit parfois à éliminer les comportements trompeurs des assets pendant le développement.

L'animation s'affiche mal selon la taille de l'écran

Ne laissez pas l’animation définir la mise en page. Placez-la dans un conteneur et dimensionnez-l’intentionnellement.

Utilisez des bornes fixes pour les icônes et les réactions
Utilisez des wrappers gérant le ratio pour les illustrations plus grandes
Évitez d’étirer en pleine largeur sans vérifier la composition prévue de l’export

La plupart des signalements « Lottie est cassé » se révèlent être des problèmes de layout, d’assets ou de timing. La bibliothèque fait généralement exactement ce que vous lui demandez.

Si vous avez besoin d’un raccourci final pour le débogage, supprimez toutes les props avancées, affichez une animation locale dans une vue centrée, puis reconstruisez à partir de là. Cette approche isole les problèmes plus rapidement que de fixer un écran de production encombré.

Capgo aide les équipes à déployer des correctifs JavaScript, d’assets et de configuration vers les apps Capacitor sans attendre la revue du store. Si vous maintenez une app hybride et avez besoin d’une méthode plus sûre pour pousser des mises à jour, gérer des déploiements progressifs et récupérer rapidement des problèmes front-end, Capgo vaut le coup d’œil.