Checklist des opérations de production Expo avec exemples pratiques

Introduction

Gérer des applications Expo en production exige plus qu’un build réussi. Cela demande une approche disciplinée pour observer l’état actuel, apporter des modifications minimales et vérifier les résultats. Cette checklist vous offre une méthode structurée pour traiter les tâches opérationnelles courantes—de la vérification de la version du SDK Expo installé à la récupération après un échec de mise à jour OTA—avec des commandes concrètes et les résultats attendus.

Ce guide s’adresse aux développeurs, ingénieurs DevOps et responsables techniques qui gèrent des applications Expo en production. Il suppose que vous avez accès à un terminal, à l’interface CLI Expo et à la possibilité de déployer des mises à jour via EAS (Expo Application Services).

Nous mettons l’accent sur la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact de toute modification, protéger les secrets et toujours disposer d’un chemin de récupération testé. Chaque section suit un modèle cohérent : composant, version, prérequis, observation, modification, vérification et récupération.

Inventaire des versions et de l’environnement

Avant de toucher à quoi que ce soit, sachez avec quoi vous travaillez. Des données précises sur les versions et l’environnement évitent des commandes mal appliquées et vous aident à choisir les étapes de dépannage appropriées.

Identifier la version du SDK installé

Votre première tâche consiste à déterminer la version exacte du SDK Expo utilisée dans votre application de production. Cela affecte les commandes et les options de configuration disponibles. Utilisez une commande en lecture seule de la CLI Expo :

expo --version

Sortie attendue (exemple) :

6.3.10

Cela vous donne la version de la CLI Expo, mais vous avez également besoin de la version du SDK à partir du package.json de votre projet :

cat package.json | grep '"expo"'

Sortie attendue (exemple) :

"expo": "~51.0.0",

Vous savez maintenant que vous êtes sur le SDK 51. C’est votre référence de base. Enregistrez-la dans votre runbook avec un horodatage. Si vous devez déboguer un problème de build ou d’exécution, vous vous en remercierez plus tard.

Cartographier votre topologie de déploiement

Ensuite, déterminez comment votre application est distribuée. Utilisez-vous EAS Build ? EAS Update ? Les deux ? Vérifiez votre fichier eas.json :

cat eas.json

Sortie attendue (exemple) :

{
  "cli": {
    "version": ">= 5.0.0"
  },
  "build": {
    "production": {
      "channel": "production"
    }
  },
  "submit": {
    "production": {}
  }
}

Cela vous indique que les builds de production utilisent le canal « production ». Vérifiez maintenant la version d’exécution et le canal de votre application via EAS :

eas channel:list

Sortie attendue (exemple) :

channel: production
appVersion: 1.2.0
runtimeVersion: 1.2.0

Si vous avez plusieurs environnements (staging, production), notez-les. Cette topologie vous aide à limiter la portée des modifications et à comprendre le rayon d’impact.

Capturer l’état actuel en toute sécurité

Prenez toujours un instantané de l’état actuel avant d’apporter des modifications. Par exemple, si vous prévoyez de mettre à jour un fichier de configuration, copiez-le d’abord :

cp app.json app.json.bak.$(date +%Y%m%d%H%M%S)

Cela crée une sauvegarde horodatée, afin que vous puissiez toujours revenir en arrière. De même, enregistrez l’historique des mises à jour EAS actuelles :

eas update:list --platform android --limit 1

Sortie attendue (exemple) :

ID: 12345678-1234-1234-1234-123456789abc
Group ID: 87654321-4321-4321-4321-543210fedcba
Update Runtime Version: 1.2.0
Created: 2025-04-03T10:00:00.000Z

Conservez ces sorties dans votre journal d’incidents. Elles vous fournissent une base de comparaison.

Protéger les secrets

N’incluez jamais de clés API réelles, de jetons ou d’identifiants de production dans des commandes ou des journaux. Utilisez des variables d’environnement ou des espaces réservés. Par exemple, lors de l’exécution de commandes EAS, utilisez $EAS_TOKEN au lieu de coder en dur :

EAS_TOKEN=your_token_here eas whoami

Mais encore mieux, exportez le jeton depuis votre magasin de secrets CI/CD. Dans un terminal local, utilisez une invite shell :

read -s -p "Entrez le jeton EAS : " EAS_TOKEN
echo
echo "Jeton acquis (longueur : ${#EAS_TOKEN})"

Vous pouvez maintenant utiliser $EAS_TOKEN en toute sécurité dans les commandes suivantes.

Chemin de configuration sécurisé

Les modifications de configuration en production peuvent avoir un impact immédiat. Suivez ce chemin sécurisé pour minimiser les risques.

Prérequis pour les modifications de configuration

Avant de modifier app.json ou eas.json, vérifiez que vous avez la bonne version de la CLI et que vous êtes connecté à EAS :

expo whoami

Sortie attendue :

Vous êtes connecté en tant que [email protected]

Si vous n’êtes pas connecté, exécutez expo login. Vérifiez également que votre projet local correspond à la branche de production :

git status --short

Sortie attendue : arbre de travail propre (aucune sortie signifie propre).

Effectuer une modification petite et ciblée

Supposons que vous deviez changer le nom d’affichage de l’application dans app.json de MyApp à My App Pro. Effectuez la plus petite modification possible :

{
  "expo": {
    "name": "My App Pro",
    "slug": "my-app",
    ...
  }
}

Après la modification, validez la syntaxe JSON :

python -m json.tool app.json > /dev/null && echo "JSON valide"

Sortie attendue :

JSON valide

Vérification et retour en arrière

Après une modification, vérifiez que l’application passe toujours les contrôles de base. Si vous utilisez EAS Update, vous pouvez d’abord créer une mise à jour d’aperçu sur un canal de test :

eas update:configure --channel preview
eas update --channel preview --message "Test de modification de configuration" --auto

Installez ensuite le build d’aperçu sur un appareil et vérifiez que les paramètres s’appliquent. Si tout semble bon, reproduisez la modification sur le canal de production.

En cas de problème, vous pouvez revenir en arrière en restaurant votre fichier de sauvegarde :

cp app.json.bak.20250404120000 app.json

Puis redéployez la mise à jour précédente. C’est pourquoi nous conservons des sauvegardes avec horodatage.

Vérification et diagnostics

Même avec une configuration soigneuse, des problèmes surviennent. Cette section explique comment les diagnostiquer systématiquement.

Commandes de contrôle de santé

Commencez par un contrôle de santé de base de l’exécution de votre application. Utilisez la CLI Expo pour extraire les journaux d’un appareil connecté ou d’un émulateur :

expo start --dev-client

Dans un autre terminal, affichez les journaux :

adb logcat | grep -i expo

Sortie attendue (si sain) :

I/ReactNativeJS: Exécution de "main"

Vérification de l’état des mises à jour OTA

Si les utilisateurs signalent un contenu obsolète, vérifiez la mise à jour actuellement active sur un appareil :

eas update:list --platform ios --limit 1 --channel production

Sortie attendue (exemple) :

ID: 12345678-1234-1234-1234-123456789abc
Group ID: 87654321-4321-4321-4321-543210fedcba
Update Runtime Version: 1.2.0
Created: 2025-04-02T15:30:00.000Z

Comparez l’horodatage Created avec le moment où le problème a été signalé. Si la mise à jour est plus ancienne que prévu, les utilisateurs ont peut-être manqué la dernière version. Si c’est la dernière, le problème est peut-être ailleurs.

Diagnostics réseau et API

Si votre application dépend d’un backend, testez la connectivité depuis le point de vue de l’appareil. En utilisant un outil comme react-native-debugger ou simplement un console.log en développement, vous pouvez voir les échecs réseau. En production, activez la journalisation à distance vers un service comme Sentry ou LogRocket. Par exemple, avec Sentry :

import * as Sentry from 'sentry-expo';
Sentry.init({
  dsn: 'https://[email protected]/votre-projet-id',
  enableInExpoDevelopment: true,
});

Lorsqu’une erreur réseau se produit, Sentry la journalise avec la trace de pile. Pour vérifier si le point de terminaison API est joignable, utilisez un outil réseau depuis un terminal :

curl -I https://api.votrebackend.com/health

Sortie attendue :

HTTP/1.1 200 OK

Si vous obtenez une erreur 500, c’est un problème backend. Si vous obtenez un délai d’attente, c’est un problème réseau/pare-feu. Consignez ces constatations.

Contrôles de performance

Utilisez expo-dev-menu pour activer le suivi des performances. En développement, ouvrez le menu de développement et sélectionnez « Performance Monitor ». Cela montre les FPS, la mémoire et l’utilisation du processeur. Pour la production, intégrez react-native-performance :

import { initializePerformance } from 'react-native-performance';
initializePerformance();

Ensuite, journalisez les durées :

const perf = mesurePerformance('monOpération');
// ... opération
const resultat = perf.stop();
console.log(`L'opération a pris ${resultat.duration}ms`);

Utilisez ces données pour identifier les ralentissements ou les fuites mémoire.

Modes de défaillance et récupération

Examinons les scénarios de défaillance courants et leurs remèdes.

Échec de mise à jour OTA

Symptôme : Les utilisateurs restent bloqués sur une version plus ancienne, ou l’application plante au démarrage après une mise à jour.

Diagnostic : Vérifiez l’historique des mises à jour pour l’ID de mise à jour défaillant :

eas update:list --platform android --limit 5 --channel production

Sortie attendue : liste des mises à jour récentes avec leur statut. Si une mise à jour a status: failed, elle n’est jamais devenue active. Si elle est active mais plante, vous avez besoin d’un retour en arrière.

Récupération : Forcez les utilisateurs à revenir à la dernière mise à jour connue bonne en créant une nouvelle mise à jour qui annule les modifications problématiques. Ou, si votre application prend en charge les mises à jour incrémentielles, vous pouvez utiliser eas update:rollback (si configuré).

eas update:rollback --channel production --target 12345678-1234-1234-1234-123456789abc

Vérification : Après le retour en arrière, vérifiez que l’ID de mise à jour active est égal à la cible. Demandez à quelques testeurs bêta de confirmer que le plantage a disparu.

Perte de variable d’environnement

Symptôme : L’application se comporte différemment en production, manquant de clés API.

Diagnostic : Vérifiez que les variables d’environnement sont présentes dans la configuration de build. Pour EAS Build, les variables sont injectées au moment du build. Vérifiez votre eas.json :

{
  "build": {
    "production": {
      "env": {
        "API_URL": "https://api.exemple.com"
      }
    }
  }
}

Si la variable manque, ajoutez-la et reconstruisez.

Récupération : Si vous ne pouvez pas reconstruire immédiatement, vous pouvez utiliser EAS Update pour fournir une valeur de repli à l’exécution. Dans votre application, lisez à partir de process.env.API_URL avec un repli :

const API_URL = process.env.API_URL || 'https://defaut.exemple.com';

Vérification : Sur un appareil, ouvrez l’application et vérifiez qu’elle journalise la bonne URL API. Vous pouvez ajouter un console.log temporaire.

Expiration du certificat

Symptôme : La soumission à l’App Store/Play Store échoue ou l’application est désinstallée après l’expiration du certificat.

Diagnostic : Vérifiez les dates d’expiration des certificats via les identifiants EAS :

eas credentials --platform ios

Sortie attendue comprend les informations du certificat de distribution avec la date d’expiration. De même pour Android :

eas credentials --platform android

Récupération : Renouvelez le certificat. Pour iOS, créez un nouveau certificat de distribution dans le portail des développeurs Apple et téléversez-le vers EAS :

eas credentials --platform ios --cert-upload

Suivez les invites. Reconstruisez ensuite votre application avec le nouveau certificat.

Vérification : Après la reconstruction, vérifiez que le nouveau certificat est actif :

eas credentials --platform ios

Confirmez que la date d’expiration est mise à jour.

Checklist des opérations

Voici une checklist consolidée pour chaque modification de production que vous effectuez. Utilisez-la comme modèle pour vos runbooks.

1. Observer avant de modifier

• [ ] Enregistrez la version actuelle du composant (SDK Expo, CLI, CLI EAS).
• [ ] Vérifiez la topologie de déploiement actuelle (canaux, versions d’exécution).
• [ ] Capturez un instantané des fichiers de configuration (sauvegarde avec horodatage).
• [ ] Vérifiez que vous disposez des informations d’identification nécessaires (connexion EAS, jetons).

2. Délimiter la modification

• [ ] Définissez la plus petite modification nécessaire pour atteindre l’objectif.
• [ ] Listez tous les fichiers et services affectés.
• [ ] Évaluez le rayon d’impact (qu’est-ce que cela affectera en cas d’échec ?).
• [ ] Assurez-vous d’avoir un plan de retour en arrière.

3. Mettre en œuvre la modification

• [ ] Appliquez la modification exactement telle que définie.
• [ ] Utilisez des espaces réservés pour les secrets.
• [ ] Validez la syntaxe (par exemple, python -m json.tool pour JSON).
• [ ] Si possible, testez d’abord sur un canal d’aperçu.

4. Vérifier le résultat

• [ ] Exécutez la commande qui confirme l’état attendu.
• [ ] Comparez la sortie réelle avec la sortie attendue.
• [ ] Vérifiez les journaux pour détecter de nouvelles erreurs.
• [ ] Faites relire par une deuxième personne si la modification est à haut risque.

5. Documenter et récupérer

• [ ] Consignez ce que vous avez fait, quand et pourquoi.
• [ ] Rangez la commande de retour en arrière dans votre journal d’incidents.
• [ ] Si la vérification échoue, exécutez immédiatement le plan de récupération.
• [ ] Après la récupération, documentez l’incident et les leçons apprises.

Exemple de runbook : Modification de l’écran de démarrage de l’application

Illustrons avec un exemple concret. Vous devez mettre à jour l’image de l’écran de démarrage pour la production.

Composant : app.json -> expo.splash Prérequis : Avoir la nouvelle image dans assets/.

Observation :

cat app.json | grep -A 4 "splash"

Modification : Dans app.json, modifiez le chemin de l’image :

"splash": {
  "image": "./assets/nouveau-splash.png",
  "resizeMode": "contain",
  "backgroundColor": "#ffffff"
}

Vérification :

python -m json.tool app.json > /dev/null && echo "JSON valide"
eas update --channel production --message "Mise à jour de l'écran de démarrage" --auto

Cela pousse une nouvelle mise à jour. Utilisez eas update:list pour confirmer que la nouvelle mise à jour est active.

Récupération : Si l’écran de démarrage est incorrect, revenez en arrière en restaurant la sauvegarde :

cp app.json.bak.* app.json

Puis poussez une autre mise à jour.

Conclusion

Une checklist des opérations de production n’est utile que si chaque action est limitée à une version, observable et réversible. Copier aveuglément des commandes sans comprendre les prérequis et les résultats attendus peut causer plus de mal que de bien.

Commencez petit : choisissez une tâche de production à faible risque, comme vérifier la version de votre SDK Expo ou lister vos canaux EAS. Enregistrez l’état actuel, exécutez la vérification documentée et comparez le résultat avec le signal attendu. Ensuite, intégrez progressivement la checklist complète dans vos processus de déploiement et de réponse aux incidents.

Un flux de travail opérationnel fiable rend les défaillances visibles tôt, protège les informations d’identification sensibles, limite les modifications à la ressource visée et définit les étapes de récupération avant qu’une crise ne force une décision hâtive. Utilisez cette checklist comme fondation et adaptez-la à la pile technologique et à la tolérance au risque spécifiques de votre organisation.