Si servir de la qualité, proposer une réelle expérience sont les premiers facteurs de réussite d’un restaurant, piloter son activité vient juste après. En effet, le modèle économique de la restauration ne laisse pas de place à la sous-optimisation. Il s’agit de maîtriser ses coûts, suivre son CA et de replacer tout cela dans un contexte général : météo, événements et reste du secteur.
Pour faire ce travail, les restaurateurs disposent de 3 ressources principales : eux-mêmes, Excel et encore un peu d’Excel. Là où ce n’est pas de la tarte, c’est que construire des tableaux de reporting à partir de plusieurs dizaines de milliers de tickets de caisse demande du temps et des compétences techniques. Or, le restaurateur n’a pas de temps. Et, s’il connaît parfaitement son métier, il n’est pas forcément un grand gouru du tableau croisé dynamique.
Intervient Resteo. Resteo propose aux restaurateurs d’automatiser leurs analyses de performance en se connectant directement à leurs caisses enregistreuses. Resteo leur permet donc de contrôler quotidiennement le bon fonctionnement de leurs restaurants et de planifier des modifications plus structurelles à apporter.
Si on vous parle de Resteo, c’est qu’en plus de développer l’application frontend nous accompagnons Grégory Derderian dans sa démarche produit depuis un peu plus d’un an maintenant. Le lancement de la v2 de l’application était l’occasion de revenir sur 3 enjeux.
Enjeu n°1 : Rester métier
En exploitant les tickets de caisses des restaurants vous disposez rapidement de beaucoup de données. Il est alors possible de tout mettre à plat puis d’observer les influences relatives de différents facteurs sur différentes grandeurs sur différentes périodes de temps pondérées par différents événements…
En gros, vous pouvez facilement étudier l’impact de la vente de pâtés de tête persillés par Michel les jeudis midi sur le nombre de crèmes brulées vendues sur la même période la semaine dernière de l’année dernière.
C’est stylé. Mais ça ne sert à rien.
L’écueil de la data est de faire de la data pour la data. Or la valeur à délivrer ici n’est pas la data mais essentiellement sa bonne exploitation métier. Grégory, avec son expérience et sa connaissance du milieu, le sait bien. Nous nous sommes appliqués à toujours rester métier. Pour cela, évidemment, rencontrer les restaurateurs est fondamental. Il faut s’imprégner de leurs problématiques et noter des verbatims. Que dit textuellement le restaurateur à son comptable le mardi matin ? Quelles questions se pose-t-il en regardant ses chiffres de la semaine ? C’est muni de ces verbatims qu’on sait quels traitements apporter à la data, quelles analyses mener et donc quelle UX proposer.
Enjeu n°2 : Prioriser, itérer
Rien de bien nouveau dans les fourneaux… Pour trouver son market fit, il faut pouvoir avancer sur le produit et les ventes de façon concomitante. Et pour faire cela rapidement, sous peine de brûler son cash et sa motivation, chaque avancement produit doit maximiser le ratio valeur apportée / coût de développement. Beaucoup plus facile à dire qu’à faire. Plutôt que de rester dans le théorique, on vous présente le chemin suivi par Resteo.
Enjeu n°3 : “Ingénierer” le frontend
Les utilisateurs d’une application consomment le frontend. Une application avec un backend extrêmement bien codé mais un frontend non fonctionnel (mauvaise UX, UI peu claire, lenteur) ne sera pas utilisée. Dans le cadre d’une application métier comme Resteo, l’enjeu frontend est d’autant plus présent que les restaurateurs achètent cette facilité d’utilisation. C’est justement la réponse à leur problème initial : pas pratique, pas facile, trop long d’extraire des conclusions des données de base sur Excel.
Par ailleurs, sur Resteo, une même donnée est utilisée dans des contextes différents : parfois sous forme de carte de synthèse, parfois sous forme de graphiques, parfois en tant que ratio, etc.
Sauf à concevoir une application frontend, non évolutive, non maintenable et lente, le frontend ne peut plus, aujourd’hui, être pensé comme une simple intégration HTML/CSS/JS : il doit être ingénieré. Qu’est-ce qui peut être calculé par le front ? Qu’est-ce qui peut être persisté côté front ? Comment signer la donnée ? Quel objet me permet de décrire l’état général de mon application ? Quels sont mes composants ?
Les réponses à ces questions techniques vont varier d’une application à l’autre en fonction du contexte technique et produit, des compétences de l’équipe de développeurs, de la criticité des calculs, etc. Il n’y a pas de réponses définitives mais il est impératif de se poser ces questions.
Pour Resteo, nous avons fait le choix de laisser côté backend l’ensemble des calculs statistiques et de minimiser le nombre de requêtes en persistant de la data côté front et et d’optimiser la polyvalence de nos composants. Resteo a donc pris la forme d’une application React-Redux échangeant avec un backend Rails qui orchestre lui-même un ensemble de micro-services Python.
Chez Poulpe, nous avons développé d’autres “pures” applications React-Redux mais aussi des monolithes Rails/React-Redux qui offrent certains avantages. On prévoit pour les plus geeks d’entre vous un article technique de comparaison sur le sujet. Stay tuned !
En attendant… longue vie à Resteo !
