Horeca
Une question en apparence simple sur un canal propre de commande et de livraison en ligne s'est transformée en un travail de product discovery. Avant de construire ou de choisir quoi que ce soit, Simply Dom a étudié l'expérience client souhaitée, les solutions existantes, les architectures possibles et les conséquences opérationnelles — y compris les raisons pour lesquelles plusieurs pistes évidentes ont été écartées.
La situation
La question venait directement du terrain. Un entrepreneur de l'horeca voulait davantage de contrôle sur son propre canal de commande et de livraison en ligne, avec ses propres chauffeurs, sans pour autant renoncer à une expérience client devenue courante grâce aux grandes plateformes.
Un élément était particulièrement concret : le client devait pouvoir suivre réellement sa commande pendant la livraison. Pas un statut « en route », pas seulement une heure de livraison estimée, mais voir où se trouve la livraison.
À première vue, une question logicielle : quelle solution offre cela ? Les premières recherches ont vite montré que cette formulation était trop simple.
L’enjeu commercial
Il existe de nombreux systèmes de commande en ligne, et tout autant de systèmes de dispatch, d'itinéraires et de chauffeurs. Fait notable, beaucoup de fournisseurs emploient des termes comme « live tracking » ou « real-time delivery ». Sauf que ces mots ne signifient pas la même chose partout.
Parfois, le gérant peut suivre ses chauffeurs en direct, mais pas le client. Parfois, le client reçoit des mises à jour de statut sans carte. Parfois, l'expérience souhaitée n'existe que lorsqu'un partenaire coursier externe assure la livraison. Et parfois, une plateforme offre presque tout ce qu'il faut — sauf précisément l'élément qui avait motivé la recherche.
La difficulté ne résidait donc pas dans le fait de trouver des fournisseurs ; il y en avait assez. La difficulté consistait à démontrer quelle combinaison pouvait réellement offrir l'expérience demandée, avec des chauffeurs propres, une exploitation quotidienne viable et suffisamment de contrôle sur le canal client.
Les choix
La première étape a consisté à définir précisément l'expérience souhaitée. « Live tracking » n'a pas été accepté comme simple étiquette de fonctionnalité ; la question est devenue plus concrète : le client final doit-il pouvoir voir sur une carte une position mobile du chauffeur pendant que la commande est en route ? C'est devenu le critère de test.
Ensuite, les différentes couches du problème ont été séparées. D'une part, le canal commercial client : assortiment, commande, paiement, données client et communication. D'autre part, l'exécution : attribution des commandes, pilotage des chauffeurs, itinéraires, statut et localisation.
Cette séparation a fait apparaître différentes architectures possibles : une seule plateforme qui fait tout, une plateforme de commande couplée à un logiciel spécialisé de dernier kilomètre, une solution existante associée à un partenaire de livraison externe, ou davantage de sur-mesure autour de systèmes proposant chacun séparément des éléments déjà éprouvés.
Toutes les pistes n'ont pas reçu le même temps. Lorsqu'une condition essentielle n'était pas démontrablement supportée, la piste était écartée. Cela comptait plus que produire une longue shortlist.
Mon rôle
Mon rôle relevait du product discovery et de l'opportunity validation : décortiquer la demande initiale, formaliser l'expérience client souhaitée, étudier séparément les plateformes de commande existantes et les solutions de dernier kilomètre, et vérifier ce que les fournisseurs entendent réellement par « live tracking ».
Il a été explicitement consigné ce qui était démontré, ce qui relevait uniquement d'une allégation marketing, et ce qui restait une question ouverte.
Le volet opérationnel et commercial a également été pris en compte. Que voit le client final, que voit le chauffeur, que doit pouvoir faire le gérant ? Comment une commande passe-t-elle d'un système à l'autre, et où apparaît une manipulation supplémentaire ? Qui possède la relation client ? Et quelle part de dépendance se déplace réellement lorsqu'on remplace une seule marketplace par plusieurs fournisseurs logiciels ?
La question de savoir si l'avantage est assez grand pour justifier cette complexité supplémentaire est volontairement restée ouverte : elle ne peut être sérieusement tranchée qu'une fois établi quelle architecture peut seulement faire ce qui est demandé.
La recherche a ensuite été remise en question à nouveau — non pas pour conserver le plus grand nombre possible de solutions, mais pour écarter plus vite celles qui, après examen approfondi, ne faisaient pas ce qu'elles semblaient faire à première vue.
L’exécution
Le résultat de cette première phase de discovery n'était pas un logiciel, et ce n'était pas non plus le but. Il en est ressorti une image du problème beaucoup plus nette : un parcours client formalisé, un parcours distinct pour le chauffeur et le pilotage opérationnel, une comparaison des catégories de plateformes envisageables, et un aperçu des solutions écartées sur des points essentiels — avec la raison de chaque exclusion.
S'y ajoutait une première image d'architecture indiquant quels systèmes pourraient fonctionner ensemble, et surtout une liste de questions qui devraient encore être vérifiées lors d'un prochain cycle de recherche.
Cela a aussi permis de voir où une recherche plus poussée avait réellement du sens : non pas recontacter vingt fournisseurs, mais tester de façon ciblée un nombre restreint de pistes sur les conditions réellement décisives. Ce n'est qu'ensuite que la faisabilité technique, la viabilité opérationnelle et les aspects économiques pourront être évalués ensemble.
État des lieux — août 2026
Le deuxième cycle de recherche a surtout réduit le champ des possibles.
Les plateformes pour la commande en ligne, le dispatch et le support aux chauffeurs ne manquent pas. Seulement, « live tracking » ne recouvre pas une réalité univoque. Chez certaines solutions, l'exploitant peut suivre ses chauffeurs, mais pas le client. Ailleurs, le client reçoit des mises à jour de statut sans voir de carte. Et dans certains modèles, cette expérience n'existe que lorsqu'un partenaire de livraison externe assure la course. Ces pistes ont été écartées.
Parallèlement, la question opérationnelle s'est affinée. Plusieurs enseignes horeca doivent pouvoir fonctionner via leur propre canal direct, avec une équipe commune de chauffeurs internes. Les commandes doivent arriver au bon endroit, les chauffeurs doivent pouvoir être pilotés, et le client doit avoir pendant la livraison la même clarté qu'il connaît des grandes plateformes.
De la comparaison ne subsiste qu'une seule piste concrète : une plateforme de commande directe couplée à des fonctionnalités de dispatch et de gestion des chauffeurs. Sur papier, cette combinaison se rapproche le plus de ce qui est recherché. Mais l'élément à l'origine de la mission n'est pas encore établi : le client final peut-il, lors d'une livraison assurée par des chauffeurs internes, réellement voir la position de son chauffeur se déplacer sur une carte ?
Il reste par ailleurs à voir comment plusieurs enseignes seraient gérées au sein d'un même fonctionnement, à quoi ressemble le flux quotidien dans la pratique, quelles licences sont nécessaires et quel en est le coût total.
La prochaine étape reste donc volontairement modeste : une démonstration du système réel, la confirmation de ce flux critique, et une offre concrète. Pas d'implémentation, pas de sur-mesure, pas de business case fondé sur des allégations marketing. Ce n'est qu'une fois ces éléments sur la table que l'on pourra évaluer si cela tient techniquement et opérationnellement, et si c'est financièrement viable.
Le dossier n'est pas encore clos. Mais ce qui doit encore être prouvé est désormais précisément défini.
Délibérément écarté
Pas de « oui, c'est possible » simplement parce qu'un site mentionnait « live tracking » quelque part. Pas de plateforme recommandée sans vérifier qui pouvait réellement voir ce suivi. Pas de développement sur mesure proposé simplement parce que les solutions existantes ne correspondaient pas immédiatement à la perfection. Pas de choix de pile logicielle avant de savoir clairement comment elle devrait être utilisée au quotidien. Et pas de business case construit autour de fonctionnalités qui n'avaient pas encore été démontrées.
Il n'y avait, à ce stade, encore rien à vendre.
Le premier gain était déjà là : moins d'incertitude.
Certaines options ont ainsi été écartées, d'autres sont devenues plus intéressantes, et la question de départ est devenue beaucoup plus précise qu'au début.
C'est exactement ce que le product discovery doit faire.