Un build validé sur émulateur peut échouer sur le téléphone réel à cause du matériel, du système, des autorisations ou des conditions d’usage que l’environnement simulé reproduit mal. Une release candidate mobile ne devrait donc jamais partir en production sans un passage sur les appareils physiques que les clients utilisent réellement.
En avril 1970, à bord d’Apollo 13, Jack Swigert, Jim Lovell et Fred Haise avaient un problème de compatibilité au sens le plus concret du terme. Après l’explosion d’un réservoir d’oxygène, les trois astronautes s’étaient réfugiés dans le module lunaire Aquarius. Le dioxyde de carbone s’y accumulait, mais les cartouches d’hydroxyde de lithium du module de commande étaient carrées, tandis que les logements du module lunaire étaient ronds.
Les cartouches fonctionnaient. Les logements fonctionnaient. L’ensemble, lui, ne fonctionnait pas.
À Houston, les ingénieurs durent fabriquer un adaptateur avec les objets disponibles à bord, puis transmettre les instructions à l’équipage. L’épisode est documenté dans Lost Moon, le récit de Jim Lovell et Jeffrey Kluger. Avant que le montage soit assemblé et testé dans Aquarius, personne ne pouvait traiter sa réussite comme acquise.
Voilà le lien avec un lancement mobile du vendredi soir. Un composant peut être correct, un test peut être vert et une application peut démarrer sans erreur sur l’émulateur. Le système complet reste pourtant inconnu tant qu’il n’a pas rencontré le matériel réel.
Ce que l’émulateur laisse hors champ
L’émulateur répond à une question utile et limitée: le logiciel fonctionne-t-il dans cet environnement contrôlé?
Le téléphone du client en pose beaucoup d’autres. Que se passe-t-il lorsque l’appareil manque de mémoire, que le stockage est presque plein ou qu’une autorisation a déjà été refusée? L’appareil photo renvoie-t-il l’image dans l’orientation prévue? Le clavier masque-t-il le bouton principal? Une reprise après mise en veille conserve-t-elle l’état de l’écran? L’authentification biométrique revient-elle proprement dans l’application?
Le vendredi après-midi, le tableau de bord peut afficher une série rassurante de coches vertes. Le fichier est généré, le parcours principal passe et l’équipe commence à parler de publication. Puis quelqu’un installe la version sur un téléphone utilisé chaque jour. L’application se ferme au moment de joindre une photo, le bouton de confirmation disparaît derrière le clavier ou la session se perd après un passage dans une autre app.
Le défaut semble soudain. Il existait pourtant déjà. Le laboratoire ne lui avait simplement pas fourni les conditions nécessaires pour apparaître.
Un émulateur reste précieux pour exécuter rapidement de nombreux scénarios, vérifier plusieurs tailles d’écran et attraper les régressions courantes. Il devient dangereux lorsqu’une équipe confond vitesse de couverture et fidélité du test.
Le dernier test doit viser le risque, pas la démonstration
Une vérification sur téléphone physique ne consiste pas à ouvrir l’application, parcourir deux écrans et conclure que tout va bien. Elle doit chercher les endroits où le logiciel dépend du monde extérieur.
Commencez par les parcours qui engagent le plus le client ou l’entreprise: création de compte, connexion, paiement, import de fichier, capture photo, notification, partage et récupération après interruption. Ajoutez les permissions, la perte temporaire de réseau, le retour depuis l’arrière-plan et les appareils les moins confortables encore pris en charge.
Le choix des téléphones compte aussi. Le dernier modèle posé sur le bureau du fondateur ne représente ni l’ensemble du parc installé, ni les appareils conservés plusieurs années, ni ceux dont la batterie et le stockage ont déjà vécu. Une petite matrice fondée sur les données d’usage vaut mieux qu’une collection décorative d’appareils récents.
Attribuez enfin la validation à une personne précise. « Quelqu’un devrait tester le build» produit rarement une preuve exploitable. Le responsable doit savoir quelle version installer, quels scénarios exécuter et où consigner le résultat. Pour chaque passage, gardez le numéro du build, le modèle, la version du système, le scénario et l’issue observée.
Pourquoi le vendredi aggrave l’erreur
Le vendredi ne modifie pas le code. Il modifie les conditions de décision.
La fatigue réduit la patience accordée aux signaux faibles. L’envie de terminer transforme un comportement étrange en anomalie supposée mineure. Les personnes capables d’enquêter deviennent moins disponibles. Une publication tardive peut aussi repousser la découverte du problème jusqu’aux premiers usages réels.
La bonne règle n’est pas une interdiction superstitieuse des mises en production le vendredi. Il faut adapter le niveau de preuve au coût d’une correction tardive. Si personne ne peut observer le lancement, reproduire un défaut et diffuser une version corrigée, le build attend.
Une heure de calendrier gagnée ne compense pas un week-end passé à comprendre pourquoi le parcours principal casse uniquement sur le téléphone des clients.
Transformer le téléphone réel en porte de sortie
Ajoutez une porte simple avant publication: aucun build mobile ne part sans validation des parcours critiques sur au moins un appareil physique pertinent. Pour une audience variée, utilisez plusieurs appareils choisis selon les versions et modèles réellement observés dans vos données.
Les plateformes donnant accès à distance à des téléphones physiques peuvent élargir cette couverture, notamment lorsque l’équipe ne possède pas chaque modèle. Elles ne dispensent pas de choisir les bons scénarios ni d’examiner les résultats. Un test exécuté en parallèle reste inutile s’il évite précisément la permission, l’interruption ou le capteur qui déclenche le défaut.
À Houston, le problème d’Apollo 13 ne venait pas d’une cartouche défectueuse. Il venait d’une interface incompatible découverte au pire moment. Les équipes mobiles disposent d’un avantage considérable sur les ingénieurs de 1970: elles peuvent provoquer ces incompatibilités avant le lancement, sur le matériel réel, puis corriger le build sans improviser en vol.
Commentaires
Pas encore de commentaires.