Le contexte
Vincent est un entrepreneur dans lâĂąme. Fort dâune expĂ©rience dâune dizaine annĂ©es dans le domaine du Service Ă la personne, il souhaite crĂ©er une plateforme de mise en relation entre jardiniers et particuliers. Lâobjectif de cette plateforme est de disrupter ce marchĂ© de niche en proposant aux particuliers dâobtenir une demande rapide de rendez-vous et aux professionnels, une augmentation de leur chiffre dâaffaires. Ce projet a Ă©tĂ© particuliĂšrement intĂ©ressant de par le profil du porteur de projet dâune part: un entrepreneur ayant dĂ©jĂ eu des sociĂ©tĂ© et rompu Ă la nĂ©cessitĂ© de gĂ©nĂ©rer de la rentabilitĂ© rapidement et ouvert aux modifications de son pĂ©rimĂštre fonctionnel. Dâautre part le projet en lui-mĂȘme qui permet de rĂ©soudre une problĂ©matique forte sur un marchĂ© trĂšs bien travaillĂ© ⊠sans digitalisation.

Notre Démarche
Nous avons effectuĂ© un premier budget qui devait couvrir lâintĂ©gralitĂ© du pĂ©rimĂštre fonctionnel demandĂ©. NĂ©anmoins, le planning qui en dĂ©coulait nous amenait Ă livrer le projet dans un dĂ©lai de 12 mois. Ce qui entraĂźne par dĂ©finition un budget consĂ©quent sans la capacitĂ© dâapprendre des utilisateurs. Compte tenu de la nĂ©cessitĂ© dâobtenir un retour sur investissement rapide, nous avons fait le choix de reporter certaines fonctionnalitĂ©s dites secondaires, afin de nous concentrer exclusivement sur celles qui crĂ©ent rĂ©ellement de la valeur pour lâutilisateur.
Ainsi, lorsque le systĂšme devait ĂȘtre constituĂ© de 4 applications natives (2 applications Jardinier et 2 applications Particulier), nous avons fait le choix de 2 applications natives Jardinier et dâun site web responsive pour les Particuliers. En Ă©tudiant le public, nous avons compris que la rĂ©servation dâune prestation de jardinage est un moment solennel et quâune vraie comparaison entre les prestataires Ă©tait nĂ©cessaire. Le choix dâun site web simple et performant a donc Ă©tĂ© largement plĂ©biscitĂ© par lâĂ©quipe UX.
Durant la phase de dĂ©veloppement, nous avons fait le choix exotique de dĂ©couper les modules par plateformes. Ainsi, lâapplication iOS reprĂ©senterait un module. Le serveur, un autre module. Et ainsi de suite. PlutĂŽt que de dĂ©velopper ces modules en parallĂšle, nous les avons rĂ©alisĂ©s lâun Ă la suite de lâautre. Cette dĂ©marche prĂ©sente un dĂ©savantage certain : elle impose une conception et une architecture initiale sans faille afin de garantir que lâintĂ©gration de tous les modules entre eux se ferait dans les meilleures conditions. En revanche, en ayant imposĂ© cette dĂ©marche, les Ă©quipes ont naturellement documentĂ© et testĂ© leur code bien au-delĂ de ce que nous effectuons dâhabitude.

Les Résultats
IntĂ©grer plusieurs blocs techniques dĂ©veloppĂ©s par des ingĂ©nieurs diffĂ©rents prĂ©sente un fort risque dâincompatibilitĂ©. GrĂące Ă lâinvestissement des Ă©quipes dâarchitectes, les diffĂ©rents modules se sont intĂ©grĂ©s entre eux sans rĂ©gression fonctionnelle, ce qui Ă©tait notre inquiĂ©tude majeure. En outre, le projet ayant Ă©tĂ© dĂ©marrĂ© le 1er mars 2017, la livraison sâest effectuĂ©e fin juillet 2017, soit 5 mois de Conception et DĂ©veloppement ! La phase de tests rĂ©els a quant Ă elle Ă©tĂ© effectuĂ©e dĂšs la rentrĂ©e 2017. A ce jour (novembre 2017), nous avons intĂ©grĂ© un ensemble de SDK dâanalyse dans les apps et sur le site web afin dâidentifier les points de blocage des utilisateurs et optimiser le systĂšme. Celui-ci dĂ©gage dâores et dĂ©jĂ du chiffre dâaffaires, 3 mois seulement aprĂšs sa mise en production.