Comment fonctionne le travail sur le système FoodSoul : de l’idée au résultat
- Temps de lecture: 6 min
- Auteur : Équipe FoodSoul

Comment fonctionne le travail sur le système FoodSoul : de l’idée au résultat
Nous apprécions la confiance de nos partenaires et souhaitons donc faire preuve de la plus grande transparence. Dans cet article, nous vous expliquons comment fonctionne notre équipe, comment les idées se transforment en fonctionnalités, comment nous établissons nos priorités et ce qui se passe en coulisses lorsque quelque chose ne se déroule pas comme prévu.
FoodSoul — un système vivant
FoodSoul n’est pas simplement une application. Derrière elle se trouve une vaste infrastructure : CRM, stockage et protection des données, modèles de sites web et d’applications mobiles, ainsi que des milliers de restaurants partenaires, chacun avec ses propres besoins et scénarios de fonctionnement.
Nous sommes à l’écoute en permanence : nous recueillons les idées de nos partenaires via le support technique, lors d’échanges directs avec les clients et grâce à nos propres analystes du département IT. Tout cela est centralisé dans un backlog — une liste de tâches constamment mise à jour, qui sert de base à la feuille de route du développement du produit.
Comment l’équipe et la structure de travail sont organisées
Plusieurs groupes de spécialistes travaillent sur FoodSoul, chacun ayant son domaine de responsabilité et sa propre logique d’interaction avec les autres.
Le support technique est la première ligne de contact avec les partenaires. Il reçoit les demandes, analyse la nature du problème et le résout soit immédiatement, soit le transmet à un spécialiste connaissant la partie concernée du système.
Les spécialistes de second niveau sont des ingénieurs qui maîtrisent en profondeur certains modules : intégrations, applications mobiles, CRM, paiements. Ce sont eux qui vérifient si la demande relève d’une particularité fonctionnelle ou d’une véritable erreur.
Les analystes recueillent et structurent les souhaits des partenaires, évaluent la demande pour chaque modification et son impact sur les autres clients, avant que la tâche ne soit transmise au développement.
Les développeurs et testeurs réalisent les tâches et les vérifient avant la mise en production — qu’il s’agisse de petites corrections ou de grandes évolutions fonctionnelles.
Les chefs de projet gardent les priorités en ligne de mire : ils surveillent le backlog, répartissent les tâches entre les équipes et veillent à ce que l’essentiel ne se perde pas parmi les tâches courantes.
Le travail est organisé de façon cyclique : l’équipe revoit régulièrement le backlog, évalue les nouvelles demandes et souhaits, planifie les tâches à venir et suit le statut de celles déjà en cours. Ce rythme permet de ne perdre de vue ni les problèmes urgents, ni le développement à long terme du produit, tout en maintenant la prévisibilité : le partenaire peut toujours savoir, via le support technique, à quelle étape se trouve sa demande.
Comment nous établissons les priorités
Lorsqu’un problème survient, nous agissons selon l’un des scénarios suivants.
Panne majeure — une erreur rencontrée simultanément par plusieurs clients en quelques heures ou dans la journée. C’est la priorité la plus élevée : testeur et développeurs interviennent immédiatement.
Bogue critique chez un client — si l’erreur impacte directement le chiffre d’affaires ou la réputation du partenaire, la priorité est tout aussi élevée. Nous mobilisons les ressources clés et résolvons le problème dans les plus brefs délais.
Bogue standard — une demande reçue par le support technique qui ne semble pas catastrophique. Elle est prise en charge par un spécialiste de second niveau, qui connaît bien le système. Deux issues sont possibles : soit il s’avère qu’il s’agit d’une particularité fonctionnelle non prise en compte, auquel cas la solution est expliquée au client ; soit le problème existe réellement, il est alors transmis au chef de projet, enregistré dans le système de gestion des tâches avec une priorité et un responsable, puis traité dans l’ordre. Le spécialiste du support technique suit le statut et informe le client une fois la tâche accomplie.
Bogue mineur — une erreur qui n’affecte pas le fonctionnement du système mais nécessite une correction : faute de frappe, élément d’interface déplacé, couleur de bouton incorrecte. Ces tâches sont traitées lorsqu’il n’y a pas de demandes plus prioritaires parmi celles mentionnées ci-dessus.
Suggestions — nous prêtons une attention particulière aux demandes des partenaires. Lorsqu’une même demande émane de plusieurs clients, sa priorité augmente et nous l’analysons. Toute modification affecte immédiatement tous les partenaires, pas seulement celui qui l’a demandée ; c’est pourquoi, avant la mise en œuvre, nous recueillons les retours de différents clients afin que l’amélioration pour certains ne crée pas d’inconvénients pour d’autres. C’est une étape supplémentaire, mais elle permet d’aboutir à une décision plus équilibrée.
Pourquoi les bogues apparaissent-ils
Le développement de tout produit complexe implique que les erreurs font partie intégrante du processus, et non une exception. Voici ce qui rend cette complexité inévitable.
Le système évolue. Plus il y a de fonctionnalités, d’intégrations et de scénarios d’utilisation, plus il existe de points d’interaction entre les différentes parties du système. L’équipe teste les scénarios les plus courants, mais il est physiquement impossible, même pour l’équipe la plus expérimentée, de couvrir à l’avance toutes les combinaisons.
Chaque partenaire utilise le système à sa manière. Des milliers d’établissements, ce sont des milliers de processus de travail uniques. Le comportement des utilisateurs en conditions réelles est toujours plus riche que ce que l’on peut prévoir dans les scénarios de test, et certaines anomalies n’apparaissent qu’avec des données réelles.
Une modification en impacte une autre. Lorsqu’un développeur améliore un module, cela peut affecter une fonctionnalité connexe. Plus le système est vaste, plus les chaînes de dépendances entre ses parties sont longues, et plus il faut vérifier chaque changement avec attention.
L’environnement évolue en permanence. Les navigateurs, systèmes d’exploitation et services tiers avec lesquels nous sommes intégrés sont régulièrement mis à jour. Ce qui fonctionnait hier peut se comporter différemment après une mise à jour d’un prestataire externe, et nous surveillons ces changements pour réagir rapidement.
Les exigences se précisent en cours de route. Parfois, une fonctionnalité est réalisée exactement comme prévu, mais l’utilisation réelle montre qu’il faut la retravailler. Ainsi, le produit devient plus précis à chaque itération.
Nous considérons cela comme une étape normale dans la croissance d’un système complexe et nous travaillons sans relâche à le rendre plus stable, plus rapide et plus pratique pour chaque partenaire — grâce à des tests approfondis, une structure d’équipe claire et un retour constant de nos clients.
Si vous rencontrez un problème ou souhaitez partager une idée, écrivez au support technique de FoodSoul. Chaque demande est transmise au bon spécialiste et n’est jamais perdue. Nous sommes à vos côtés !
Cordialement,
Chef de projet FoodSoul




