Certaines grandes chaînes développent effectivement leur logiciel traiteur en interne. Waitrose, au Royaume-Uni, exploite depuis des années son propre service « Food Made To Order ». Cela peut fonctionner. Mais les vrais arbitrages ne sont généralement pas ceux que suppose le business case initial.
La ligne du business case dit généralement « projet de développement à 800 K€ ». La réalité, tirée des références publiques de projets internes en grande distribution, ressemble plutôt à ceci :
| Phase | Réalité typique | Coût indicatif |
|---|---|---|
| Cadrage + cahier des charges | 3 à 6 mois d’entretiens, de visites de magasins, d’évaluation de fournisseurs. Produit souvent un document de 200 pages re-spécifié 12 mois plus tard. | 100–200 K€ |
| Développement du MVP (année 1) | Catalogue, commande, planification des retraits, administration de base. Soit une équipe interne de 6 à 8 personnes, soit un intégrateur. Glisse de 3 à 9 mois. | 0,8–1,5 M€ |
| Moteur de règles (année 2) | Capacité, date de retrait, heure de retrait, prix, bons. Toujours sous-estimé dans le plan initial ; nécessite généralement une refonte d’architecture. | 0,6–1,2 M€ |
| Déploiement multi-magasins (années 2-3) | Interfaces de configuration par magasin, formation des responsables, pilote, extension. Chaque vague de déploiement fait remonter de nouveaux cas particuliers exigeant du travail produit. | 400–800 K€ |
| En continu (année 3+) | Équipe plateforme de 4 à 6 personnes à perpétuité : corrections, mises à jour réglementaires, nouvelles intégrations caisse, compatibilité navigateurs, correctifs de sécurité. | 0,6–1 M€ / an |
| Total jusqu’à une plateforme mature | 3 à 4 ans pour atteindre la parité fonctionnelle avec ce que DeliChain livre aujourd’hui, plus un coût récurrent permanent. | 3–5 M€ une fois + 0,6–1 M€/an |
Fourchettes indicatives, issues de références publiques de projets retail-tech. Les plateformes traiteur développées en interne sont rarement documentées publiquement, car rarement considérées comme des avantages concurrentiels à divulguer.
Pour une chaîne de 50 magasins partant de zéro aujourd’hui.
Les cahiers des charges internes supposent que le domaine du traiteur est plus simple qu’il ne l’est. Voici les points qui remontent systématiquement en année 2 et imposent une refonte d’architecture.
Pas un chiffre unique par magasin, mais par jour, par famille de produits, par équipe. Plus des dérogations saisonnières. Plus des plafonds d’urgence quand le personnel est malade.
Un délai de 3 jours à 18 h n’est pas le même qu’à 9 h le lendemain matin. Les dates doivent basculer correctement à travers les fuseaux horaires, les week-ends et les jours fériés propres à chaque magasin.
B2B vs particuliers. Remise famille cumulable avec un bon mais pas avec une promo saisonnière. Le moteur de règles de prix représente à lui seul généralement 20 % de la plateforme.
Cinq vues différentes (fiche de production, bon de livraison, commande complète, impayées, toutes). Chacune a des conventions de format que les responsables de magasin attendent de l’ancien processus papier.
Produits à composer avec plus de 30 options, sélections dépendantes, prix dynamiques, champs de texte libre (prénom sur le ruban de pâte d’amande du Kagemand). Les générateurs de formulaires génériques ne gèrent pas cela.
Le client annule 6 heures avant le retrait ; la production a déjà commencé. Que fait la politique de remboursement, et comment la plateforme l’applique-t-elle sans qu’un humain tranche au cas par cas ?
Nous ne sommes pas contre le développement interne. Il existe de vraies situations où c’est le bon choix :
Si deux critères ou plus s’appliquent, la voie interne mérite d’être sérieusement modélisée. Si aucun ne s’applique, le calcul penche presque toujours pour l’achat.
Pour les chaînes de moins de 200 magasins, construire en interne n’est presque jamais le bon choix — le coût de développement dépasse le résultat de l’activité traiteur.
Pour les chaînes de 200 à 1 000 magasins, construire peut se justifier, mais seulement avec une équipe plateforme stratégique déjà en place et une patience de plus de 3 ans.
Pour tous les autres — y compris l’ambition « nous avons une DSI, nous pourrions le faire » qui surgit souvent en comité de pilotage — DeliChain raccourcit d’au moins deux ans le chemin entre la décision et l’exploitation.
Ce que demandent réellement les comités de pilotage une fois les chiffres du vrai coût sur la table.
Probablement pas arrêter, mais recadrer. Le travail déjà réalisé sur le schéma traiteur, le moteur de règles ou l’outillage d’administration est rarement perdu — les enseignements se transfèrent. La vraie question est de savoir s’il faut continuer jusqu’à la v1, ou basculer vers DeliChain et réutiliser le développement interne pour ce qui est réellement unique à votre chaîne (intégration fidélité, plomberie ERP, logique de bons sur mesure). La plupart des chaînes constatent que le catalogue, la commande, la gestion des créneaux et l’isolation des entités ne sont pas là où elles veulent passer les 18 prochains mois.
Pas aujourd’hui. DeliChain est proposé comme un produit configuré, pas comme une bibliothèque de composants. Les chiffres du vrai coût de cette page supposent que vous achetez toute la plateforme et intégrez aux bords (authentification, ERP, paiement, fidélité). Si vous voulez une relation composants uniquement, c’est une autre conversation et presque certainement la mauvaise forme — le modèle d’entités, le moteur de règles et la chaîne de commande sont profondément imbriqués.
Oui — dans les surfaces d’extension de la plateforme. Vous disposez d’une API publique, de webhooks pour chaque événement significatif, de moteurs de règles configurables et d’un accès à votre propre réplique Postgres pour l’analyse. Ce que vous n’avez pas, c’est un accès en écriture direct au schéma opérationnel, car cela romprait le contrat de mise à jour. Si vos besoins de personnalisation imposaient des changements au niveau du schéma, le développement interne est réellement envisageable — voir la section « Quand construire » ci-dessus.
Les besoins semblent souvent uniques mais se révèlent être des variantes des six mêmes formes de règles (capacité, délai, créneau, prix, bon, assortiment). Le moteur de règles répond à la plupart des objections du type « mais notre chaîne fait X différemment ». Les exceptions concernent généralement la fidélité, l’ERP et la facturation franchisée — c’est du travail d’intégration, pas de plateforme, et c’est de toute façon là que votre DSI devrait passer son temps.
De références publiques : les dépenses de Waitrose pour sa plateforme traiteur, la refonte de Tesco F&F et plusieurs grands programmes digitaux de la grande distribution relayés par la presse conseil. Chez DeliChain, nous avons aussi chiffré ce que nous coûterait une reconstruction de zéro — les chiffres tombent dans la même fourchette. Ce ne sont pas des prévisions précises par chaîne ; c’est l’ordre de grandeur que tout comité de pilotage devrait intégrer à une comparaison honnête du coût total.
Oui — c’est le modèle de déploiement prévu. Nous ne cherchons pas à être votre fournisseur d’identité, votre ERP, votre moteur de fidélité ni votre passerelle de paiement. L’intégration à ces systèmes passe par l’API et les webhooks, et c’est exactement là que votre DSI apporte de la valeur. Un premier projet d’intégration représente typiquement 4 à 8 semaines de travail pour une chaîne de 50 magasins, dont une bonne part de conduite du changement interne plutôt que de code.
Nous vous présenterons le plan de déploiement réel d’une chaîne de 50 magasins — ce qui se passe aux mois 1, 4 et 9.
Demander une démoOu écrivez-nous directement à hello@delichain.com