0%

Leader Price : Courseur

Application mobile

Contexte

Création d’une application mobile pour LeaderPrice

Client

Leader Price / Courseur

Pôles

Application
Conseil

Une application orientée service

Partant du constat que de nombreuses personnes ont recours à leur véhicule pour s’approvisionner à l'hypermarché le plus proche de leur domicile, la société Courseur décide dans un souci environnemental de créer une application qui permet aux usagers de limiter leur déplacement. Pour ce faire lorsqu’un usager se trouve en hypermarché, il peut se charger d’acheter le panier de courses d’un autre usager à sa place puis lui livrer via l’application.

Adaptation et réactivité

Le délai de livraison étant particulièrement court, l’agence a procédé de manière agile en se libérant du traditionnel cahier des charges pour ce qui est de la méthode de travail. En ce qui concerne la partie technique, les développeurs ont eu recours à une technologie hybride mêlant Cordova et Ionic ce qui permit de coder en langage web tout en étant supporté par les langages natifs pour IOS et Android. L’agence a également utilisé un serveur dédié afin de stocker les données et créé une API (logique métier). Celle-ci fut conçue avec Ruby On Rails.

Des phases de tests très complètes

Pour que l’application fonctionne au mieux, les équipes techniques de l’agence ont mis en place de nombreuses séries de tests par le biais de Gitlab et d’un registry docker ainsi qu’en ayant recours à Selenium via Browerstack. Il fut également nécessaire de communiquer avec l’API dans sa version web app pour que Protractor puisse la tester sur tous les navigateurs.

La méthode itérative permit à chaque développeur de pouvoir modifier une partie du code, de l’envoyer sur notre serveur source Git (Gitlab) et de faire que ces tests se lancent automatiquement pour vérifier le bon fonctionnement de l’application. Bien que les développeurs aient été contraints d’avoir recours à cette méthode de test, ils apprécient expérimenter de nouvelles technologies, tel Appium ou AWS Device Farm.

Trois environnements pour une plus grande flexibilité

L'agence 148 a pu préconfigurer rapidement le serveur grâce aux différents scripts de la plate-forme Ansible et ainsi générer trois environnements. Un environnement dédié aux tests, un autre pour la production et un dernier pour mettre en place la démo de l’application. Cette méthode en silos permet d’agir sur l’un des environnements sans que cela n’impacte directement les deux autres. Ainsi, il fut beaucoup plus simple et rapide d’ajuster, de modifier les différentes composantes de l’application.

Rémi : lead developer sur l’application Courseur

Comment s'est déroulé le projet ?

Nous avons collaboré avec Sébastien Vray (connu au départ pour l'association Respire), le créateur de l’application et l’agence de branding Pixelis en méthode agile sur ce projet. Sébastien avait mis en place une étude pour bien connaître le marché et avait designé quelques écrans de l'application pour aiguiller notre réflexion. Avec mon équipe nous avons décliné ce travail sous forme de fonctions pour pouvoir estimer un ratio cout/temps pour chaque fonction de l'application comme par exemple la signature électronique sur le téléphone ou la manière dont un livreur dépose un colis par exemple.

Nous avons alors défini une version minimale de l'application, avec les fonctions fondamentales. Chaque nouvelle étape du projet a été alors envisagée comme une évolution décliné en V2, V3 etc.

Quel méthode as-tu utilisée pour la conception du parcours client ?

Les développeurs de l’agence ont ensuite travaillé en collaboration avec l’un de nos UX designer pour mettre en place des wireframes de tous les écrans de l'application afin de visualiser le parcours de l’utilisateur autant du point de vue du livreur que du client. Cette structure et ces fonctions se sont affinées au fil du projet de manière agile en échangeant régulièrement avec Sébastien et Pixelis.

Quel a été ton apport sur le projet ?

J’ai conçu une première mouture de l’application puis j’ai décliné les fonctions avec Amélie et Axel deux de nos développeurs back end. Nous avons ensuite fait valider l’ensemble par Mathias, le directeur technique de 148.

A partir de là le développement a pu commencer, j’étais notamment en charge du front : je m'occupais de développer l'application visible par l'utilisateur. Amélie et Axel ont géré la partie back : la base de données et l'API. Les deux développeurs se sont chargés de la mise en place des environnements (serveurs de staging, demo, production) avec Mathias.

Tout au long du développement, Sébastien a eu besoin de rajouter certaines fonctionnalités jugées essentielles, Mathias et moi-même supervisions cette partie afin d’agrémenter l’application des features additionnelles.

Et ensuite ?

Une fois la première version stable atteinte, je fus en charge d’adapter les applications pour les tester sur mobile (IOS et Android) pour finalement les déployer sur les stores. (Google Play Store, App Store).

148 n’a géré que le développement. Le logo ainsi que le design des écrans ont été fournis et intégrés par Courseur. »

Un projet ? On s'en parle ?

En vrai c'est encore mieux !

Contactez-nous

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considérerons que vous acceptez l'utilisation des cookies.