Awwwards

Michaël Villeneuve

Développeur web à Bordeaux

Menu hover Clavier hover Clavier hover

Retourner à la liste des réalisations →

E-city, place de marché


Présentation

Initié à mon retour en entreprise en Avril 2016, ce projet est une réalisation interne à l’agence Awam.

Cette plateforme est une place de marché, permettant à n’importe quel petit commerçant de créer sa boutique et de commercialiser ses produits sur le site.


La première version de ce projet avait été mise en place dans la ville de Pau en 2015. Les évolutions du concept, et l’augmentation du nombre de fonctionnalités de la plateforme a accéléré la nécessité d’une refonte complète de cette dernière. En effet, au-delà de la vente en ligne, le site doit maintenant proposer de nombreux services : livraison express, gestion de « Cityzens » (auto-entrepreneurs qui s’occupent de la boutique d’un commerçant sur E-city en prenant une commission sur les ventes), API permettant aux commerçants d’intégrer E-city à leur propre site, etc.


Fondé sur base de Prestashop, le site précédent est ainsi devenu obsolète, sa maintenabilité est nulle, aucun test automatisé ne permet d’assurer son bon fonctionnement. Chaque modification était une perte de temps.




Réflexion

En amont du projet, j’ai été partie prenante des choix technologiques permettant de répondre au mieux aux spécifications de ce dernier. M’étant longuement formé à Ruby on Rails durant ma période au DUT (de Janvier à Avril 2016), j’ai pris le temps de venter les mérites de cette technologie pour un projet de ce type.


Choisir des technologies permettant de prototyper rapidement et de pouvoir mettre à l’échelle l’application simplement, était crucial.


En effet, au delà des attentes internes de l’équipe, le projet est financièrement lié à des entités telles que la Poste, la mairie de Pau et d’Oloron Saint-Marie. Ainsi, les contraintes temporelles et qualitatives sont d’autant plus importantes. Par exemple, les mairies de Pau et d’Oloron ont signé plusieurs contrats afin d’intégrer E-city à leur ville, avec pour délais Septembre 2016.


L’équipe

Étant un projet interne à l’agence, tout le monde a eu plus ou moins l’occasion d’apporter sa pierre à l’édifice. Contrairement au projet Neorev, j’ai eu cette fois à mes côtés deux développeurs. Aucun des deux ne connaissaient le framework Rails, j’ai donc passé du temps à les orienter sur les bonnes pratiques à adopter dans le but d’obtenir une base de code cohérente et maintenable au sein de l’agence.


Modélisation

La première grosse étape du développement fut la modélisation des éléments (Cf annexe 10). Avec différents types de diagrammes UML nous avons essayé d’étaler au mieux le fonctionnement de chaque fonctionnalité et de fournir un ensemble de tables répondant de manière optimisées et « scalable » aux besoins de notre application.


N’étant pas un projet avec un cahier des charges fixe, nous avons adapter notre code et modélisation pour supporter facilement les évolutions des spécifications du projet.

Au fil de la modélisation se sont posées de nombreuses questions relatives au fonctionnement global.


En général, mes patrons voyaient ce qu’ils attendaient d’une fonctionnalité, mais n’avaient pas pu réfléchir à toutes les contraintes techniques qu’elle posait, qui pouvaient soient l’impacter, soit la rendre obsolète.

Cette partie m’a permis à la fois de m’imprégner du projet, mais également de mettre en lumière beaucoup de zones d’ombre dans les spécifications.


En effet, étant une sorte de place de marché, le site doit pouvoir s’adapter à tout type de produit, de service, et fournir une expérience optimisée pour chaque commerçant.


Cette contrainte soulève énormément de problématiques, par exemple dans le processus de création d’un produit : quelle catégorie de produit ou de service doit pouvoir renseigner telle ou telle information ? Quelles sont les types de caractéristiques (taille, couleur, etc) qui peuvent faire varier le prix d’un produit ?


De même s’est posée la question de la livraison des produits, bien plus complexe que pour un site E-commerce classique.


En effet, un commerçant doit pouvoir envoyer lui même ses produits, et ainsi fixer différents tarifs de livraison à appliquer en fonction de plusieurs critère (prix, taille du colis, poids, etc), mais à l’inverse d’un site classique, cela s’applique uniquement à la livraison standard, et non à la livraison Express qui est elle régie par E-city.


Des livreurs indépendants viennent ainsi sur nos instructions collecter les produits chez les commerçants afin de les apporter aux clients. Comment doit alors se faire le processus décisionnel permettant de déterminer quel livreur doit récupérer le colis ? Si le colis est éligible ou non à une livraison express ? Est-ce qu’un livreur à vélo peut le transporter ?


Ce sont autant de problématiques auxquelles notre système d’informations devait être capable de répondre. La gestion d’erreurs, l’obligation de remplir certains champs, étaient cruciaux afin de garantir l’intégrité des données et la qualité de notre réponse.




Développement

Une fois la modélisation terminée, les fonctionnalités de base de la place de marché sont arrivées assez rapidement. Ruby et notamment son framework Rails m’ont permis de prototyper très vite. Ils proposent de nombreuses « gems » (comprenez « plug- in ») permettant de mettre en place simplement certaines choses assez fastidieuses et sensibles telles qu’une gestion d’utilisateurs, la gestion de mise en ligne de fichiers, etc.


Le site E-commerce initial a ainsi été terminé dans les temps après 3 semaines, avec comme fonctionnalités : la création d’une boutique par un commerçant, la mise en ligne de ses produits (avec les références associées – tailles, couleurs, dimensions –, les caractéristiques en tout genre, la traduction, la gestion des promotions, etc), la proposition de ses produits à la vente (Cf annexe 7), une gestion de panier pour les clients, et enfin la possibilité de payer par carte bancaire avec le crédit Agricole, ou avec Paypal.


Les semaines qui ont suivies, ont été principalement consacrées à l’intégration du site, et l’ajout de fonctionnalités secondaires (avis produits, réservation des produits, amélioration des filtres, etc). Ainsi, ces semaines ont permis aux membres non-développeurs de l’équipe de re-travailler l’expérience utilisateur, et les parcours au sein de l’application afin que nous puissions ensuite apporter les améliorations nécessaires.




Tests et intégration continue

Ayant souhaité garder l’ensemble le plus fonctionnel et maintenable possible, l’ensemble du site a été pensé en TDD (test driven development), ainsi, toutes des fonctionnalités du site sont soumises a des tests automatisés lors de chaque mise en ligne.


Ce processus, accompagné par de l’intégration continue, permet d’être sur que chaque version mise en ligne de l’application est exempt d’erreurs.

Coder les tests avant de coder la fonctionnalité en question m’a permis de mieux visualiser l’ensemble des étapes permettant d’arriver au résultat final.

Enfin l’obligation de passer par le processus d’intégration continue permet de palier l’oubli de vérifier ses tests lorsque l’on pousse des modifications en production (un script lance automatiquement les test et ne met en ligne que si ceux-ci sont au vert).


Malgré ces précautions, il nous ai souvent arrivé de mettre en ligne des fonctionnalités partiellement cassées, en effet, couvrir 100 % de son code par des tests est vraiment fastidieux et peu dégrader l’esprit agile lorsque l’on se trouve dans une phase de sprint intensif.


L’essentiel pour nous étant de se concentrer sur les fonctionnalités cruciales (panier, page produits, fonctionnement des paiements, de la mise en ligne des produits, etc).

Même si certains bogues peuvent subsister, faire tourner tous les tests après l’ajout de nouvelles fonctionnalités permet de garantir que les autres précédemment développées fonctionnent toujours.





Conclusions du projet

Étant passionné par le développement, par Ruby, et par le code de qualité, j’ai passé beaucoup de temps à refactoriser l’ensemble, afin d’obtenir une base la plus propre et maintenable possible.


Même si nous n’étions pas toujours en accord par rapport à l’expérience utilisateur et certains choix fonctionnel, je mettais aisément de côté mes préférences en me concentrant sur la qualité de mon code. Cela m’a permis de répondre au mieux aux attentes de mes patrons et de fournir un travail qualitatif dont je suis fier.


Bien qu’encore en cours, ce projet fût l’aboutissement de plusieurs mois d’auto-formation à Ruby on Rails. Après avoir refait mon site, puis plusieurs sites durant le 4ème semestre à l’IUT, j’avais enfin l’occasion de mettre à profit ces connaissances dans un cadre purement professionnel. 5 mois après l’initiation du projet, je ne regrette aucun choix technique que j’ai pu prendre et je travail encore avec grand plaisir sur ce projet qui me tient à cœur.


Pour la première fois depuis le début de mon alternance j’ai la sensation d’avoir atteint un niveau de professionnalisme qui me satisfait vraiment. De plus, j’ai pris beaucoup de plaisir à aider mes collègues et à pousser avec eux le niveau de qualité que l’on pouvait atteindre.

Nous avons énormément appris ensemble, ce fût probablement l’expérience la plus enrichissante de ma courte carrière.

Celle-ci m’a ouvert l’esprit sur le fait que j’aime transmettre mes connaissances, et j’aimerais à l’avenir avoir l’occasion de le faire à nouveau, éventuellement dans un contexte plus scolaire. C’est en tout cas une partie de mon métier que j’envisage de plus en plus, peut-être d’ici quelques années.  

swipe
Accueil - Contact - Mentions légales