Optimisation Ecommerce : comment améliorer les performances de votre application

Les développeurs sont souvent confrontés à la nécessité de procéder à une optimisation ecommerce, notamment en ce qui concerne le stockage local d’une application. Ce processus peut impliquer de nombreux facteurs : du remplacement d’une bibliothèque à la refonte complète de l’architecture du projet. Dans cet article, nous allons vous montrer, à travers une étude de cas concrète, les éléments à prendre en compte et la démarche à suivre pour améliorer drastiquement les performances d’une application ecommerce.

Le Contexte du Projet

Un client nous a contactés avec une mission claire : analyser l’architecture de son application mobile et l’optimiser. L’application a été conçue comme un outil pour les vendeurs, conseillers et experts en magasin, afin de les aider à interagir plus rapidement et plus efficacement avec les clients.

Elle permet aux employés de consulter les produits disponibles sur l’ensemble du réseau, de vérifier les stocks en entrepôt ou dans d’autres magasins, d’ajouter des articles au panier et de finaliser des commandes (en « click and collect » ou en livraison). L’objectif du client était sans équivoque : une optimisation ecommerce pour booster la performance de l’application et, par conséquent, l’efficacité de ses équipes.

Notre Plan d’Action pour l’optimisation optimale

Pour aborder cette mission de manière structurée et exhaustive, nous avons divisé notre travail en plusieurs étapes clés :

1. Analyse de l’architecture existante et identification des problèmes majeurs d’UX (expérience utilisateur).
2. Évaluation des options pour l’organisation de la base de données de l’application.
3. Analyse du fonctionnement global de l’application.
4. Phase d’optimisation et de refactoring.

Analyse de l’Architecture Initiale

Lors de notre audit, nous avons constaté que l’application reposait sur des informations entièrement dynamiques. Elle affichait les produits, leur disponibilité en stock, et les points de fidélité de l’utilisateur, le tout récupéré via des interactions avec un serveur.

Pour affiner les recherches, une fonctionnalité de filtres avancés était disponible. Ces filtres se mettaient à jour dynamiquement en interrogeant le serveur. Les données des produits arrivaient au format JSON, étaient traitées puis affichées à l’utilisateur via un système de pagination.

Les Problèmes Rencontrés en Développement

Le développement initial de l’application avait rencontré plusieurs obstacles, limitant à la fois l’ergonomie et l’évolutivité.

• Absence de base de données locale : L’idée de départ était que l’application n’avait pas besoin de sa propre base de données, les informations provenant directement du serveur. Seul un cache temporaire avait été implémenté. Or, les vendeurs se déconnectaient souvent, ce qui vidait le cache et les forçait à attendre de nouveau le chargement de requêtes « lourdes ». À l’inverse, lors d’une utilisation prolongée, le cache finissait par s’expirer, entraînant les mêmes temps d’attente frustrants.
• Manque de tests : L’absence de tests automatisés (approche TDD – Test-Driven Development) durant la conception avait fragilisé la fiabilité globale de l’application.

Ces problèmes ont rendu évidente la nécessité de revoir l’approche architecturale et d’entreprendre un refactoring complet pour une véritable optimisation ecommerce.

Une Structure Devenue Trop Complexe

Initialement, l’architecture MVC (Modèle-Vue-Contrôleur) semblait parfaite. Les données étant dynamiques, une couche complexe de gestion et de stockage de données ne paraissait pas nécessaire.

Cependant, au fil des mises à jour, le projet a pris de l’ampleur. De nombreuses fonctionnalités et de nouveaux écrans ont été ajoutés. La structure s’est complexifiée, avec des interactions entre les composants bien plus poussées que prévu. L’architecture MVC initiale n’était plus en mesure de gérer cette complexité. De plus, la mise en cache s’est avérée insuffisante, provoquant des plaintes du personnel concernant la lenteur de l’application et les chargements constants.

La décision a donc été prise : il fallait modifier l’architecture et intégrer une base de données locale.

Quelle Base de Données Locale pour une Application Ecommerce ?

Pour l’application, comme pour beaucoup d’autres, les données provenaient de plusieurs serveurs. Pour synchroniser les requêtes, le système utilisait des « répertoires » qui contenaient les informations de connexion à chaque serveur. Pour éviter de re-télécharger ces répertoires à chaque fois, ils étaient stockés localement.

Face à la croissance des données et à la nécessité de conserver les informations même en cas de perte de réseau, le cache simple (implémenté avec NSCache) ne suffisait plus. L’utilisation d’une base de données locale s’imposait pour stocker un grand volume d’informations de manière persistante, optimiser l’utilisation de la mémoire et éviter de re-solliciter des données qui changent rarement.

Les deux options les plus populaires pour iOS sont Realm et Core Data.

• Avantages de Core Data :
  • Natif à l’écosystème Apple (« disponible d’emblée »).
  • Framework très stable.
  • Performant sur les recherches textuelles et les grands volumes de données.
• Avantages de Realm :
  • Syntaxe simple et concise.
  • Support du chiffrement et de la synchronisation.
  • Très rapide sur des volumes de données relativement petits à moyens.

Nous avons choisi Realm. Sa simplicité d’implémentation et de maintenance future était un atout majeur. De plus, ses optimisations intégrées promettaient d’accélérer le fonctionnement de l’application, un point crucial pour l’optimisation ecommerce.

Choix d’une Nouvelle Architecture Applicative

La nouvelle architecture devait intégrer ce stockage local tout en conservant les points forts du projet existant, comme l’utilisation de Swinject (un framework d’injection de dépendances) et les principes de la Clean Architecture.

Après une analyse comparative (MVC, MVP, VIPER, et MVVM-C), l’architecture MVVM-C (Model-View-ViewModel-Coordinator) s’est imposée comme la solution la plus optimale. Elle offrait un excellent équilibre :

• Simplicité de maintenance pour l’équipe.
• Résolution des problèmes de navigation grâce au « Coordinator ».
• Bonne séparation des responsabilités, ce qui améliore la testabilité des modules.

La Phase d’Optimisation en Pratique

L’intégration de Realm a permis de réduire drastiquement le temps de démarrage de l’application, passant de 12 à environ 5 secondes. Elle a également éliminé le rechargement de données déjà vues, fluidifiant l’expérience globale.

Un autre axe majeur de cette optimisation ecommerce a été de s’attaquer aux fuites de mémoire. L’architecture précédente utilisait massivement le pattern de délégation. Bien qu’efficace, il peut facilement créer des cycles de rétention et donc des fuites de mémoire difficiles à tracer.

Pour résoudre ce problème, nous sommes passés des délégués aux bindings, en utilisant la bibliothèque ReactorKit. Les bindings fonctionnent sur un principe d’abonnement à des événements. Si un objet est libéré de la mémoire, son abonnement est automatiquement supprimé, évitant ainsi les fuites.

Cette nouvelle approche a permis de :

• Mettre en place une structure « Clean » avec des couches bien définies, simplifiant la maintenance du code.
• Respecter le principe de responsabilité unique pour chaque module.
• Améliorer la réactivité de l’interface, notamment sur les listes et tableaux contenant de nombreuses données.

Le Résultat Final

Grâce à cette refonte architecturale et technique, notre équipe a rempli toutes les exigences du client. L’optimisation ecommerce a été un succès total : l’application est devenue nettement plus rapide, plus stable et plus agréable à utiliser pour les vendeurs. La nouvelle structure est également plus robuste et prête pour les évolutions futures.

Vous avez un projet d’application et souhaitez garantir ses performances ? Contactez-nous pour discuter de votre projet et de la manière dont nous pouvons vous aider à l’optimiser !