Aller au contenu principal
Pour la restauration rapide

Déployez vos menus et promos le jour J

Envoyez la couche web de votre app de commande via votre CI dès que la promo est lancée. Gérez le routage par marché ou par marque avec les canaux, commencez par un pilote, et effectuez un rollback si la commande échoue.

Why restaurant teams add a live update lane

Les menus et promos changent plus vite que les releases sur les stores

Un bug le jour du lancement sur le parcours store-only

Un article à durée limitée est lancé à une date précise. Le matin du lancement, la QA remarque qu'il n'apparaît pas dans le menu de l'app.

Le correctif se situe dans la couche web, mais un processus passant uniquement par les stores impose un nouveau build et une revue, ce qui prend souvent 24 à 48 h, voire bien plus.

Même après l'approbation, les clients doivent installer la mise à jour, et les bornes en magasin nécessitent leur propre chemin de mise à jour.

Les promotions ont des dates fixes

Une offre limitée commence dès le lancement de la campagne. Un correctif sur la couche web ne devrait pas dépendre d'une release sur les stores.

Plusieurs marques et marchés

Chaque app de marque et chaque marché peut nécessiter des menus, des promotions et des textes légaux différents à partir du même codebase.

Les changements nécessitent un pilote

Un nouveau flux de commande doit être testé sur un marché ou quelques appareils avant d'être déployé partout.

Les heures de pointe n'autorisent aucune erreur

Un écran de commande défectueux au moment du déjeuner nécessite un rollback qui ne dépende pas d'une release sur les stores.

Cas d'usage

L'usage des live updates pour les apps de restauration

Commande et paiement

Corrigez les écrans de commande et de paiement via la couche web et déployez des changements de menu sans nouveau binaire.

Fidélité et récompenses

Mettez à jour les écrans de récompenses, l'affichage des points et les flux de conversion. Les valeurs de points issues de votre backend s'y modifient.

Localisation de restaurant et retrait

Mettez à jour les écrans d'infos de restaurant, les instructions de retrait et les options de curbside via la couche web.

Promotions

Lancez des bannières promo, des pages d'offres et des points d'entrée de campagne en un instant. Testez-les d'abord sur un seul canal.

Bornes en magasin

Les apps de bornes peuvent rester ouvertes toute la journée. Appliquez les mises à jour lors de vérifications périodiques ou au retour de l'écran d'attente.

Apps multi-marques

Regroupez chaque application de marque dans une seule organisation Capgo, chacune avec son propre ID d'app, ses canaux et son historique de release.

Ce que Capgo apporte aux équipes de restauration

Déployez selon votre planning, par marché et par marque

Envoyez depuis votre CI au moment voulu

Capgo n'a pas de planificateur de release. Votre CI déclenche l'upload : lors d'un merge, d'un run manuel ou via un cron que vous définissez pour le lancement.

  • Guides pour GitHub Actions, GitLab CI, Bitbucket et Azure DevOps
  • Conservez la clé API de Capgo dans vos secrets CI
  • Effectuez un rollback depuis la console ou CLI si le lancement échoue
# .github/workflows/capgo-launch.yml
on:
  workflow_dispatch:
  schedule:
    - cron: '0 6 15 11 *' # 06:00 UTC on 15 Nov, your launch time

jobs:
  upload:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: npm ci && npm run build
      - run: npx @capgo/cli@latest bundle upload --channel production --delta
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
# one app ID per brand, same web codebase
npx @capgo/cli@latest bundle upload com.yourgroup.brand-a --channel production
npx @capgo/cli@latest bundle upload com.yourgroup.brand-b --channel production

Plusieurs marques depuis un seul compte

Chaque application de marque est une app distincte dans Capgo, avec ses propres canaux et son historique de release. Gérez-les au sein d'une seule organisation avec des rôles par membre d'équipe.

  • Une organisation pour chaque application de marque
  • Canaux et historique séparés par ID d'app
  • Rôles d'accès pour l'organisation, l'app et le canal

Canaux pour les marchés et groupes pilotes

Créez un canal pour chaque marché, région ou groupe pilote. L'app rejoint un canal via setChannel() si l'auto-assignation est activée, et votre équipe peut épingler un appareil avec un override.

  • Canaux pour les marchés, régions ou stores pilotes
  • Les appareils rejoignent via setChannel() ou des overrides
  • Déploiement progressif au sein de chaque canal
// in the app, after the user or kiosk picks a market
import { CapacitorUpdater } from '@capgo/capacitor-updater'

await CapacitorUpdater.setChannel({ channel: 'market-uk' })
mises à jour des bornes
// capacitor.config.ts
CapacitorUpdater: { autoUpdate: 'onlyDownload' }

// kiosk app
let next
CapacitorUpdater.addListener('updateAvailable', ({ bundle }) => {
  next = bundle
})

// when the kiosk is back on its idle screen
if (next) await CapacitorUpdater.set({ id: next.id })

Des bornes qui restent actives toute la journée

Le mode par défaut applique les mises à jour quand l'app passe en arrière-plan, ce qu'une borne fait rarement. Téléchargez les mises à jour automatiquement et appliquez-les quand la borne est inactive.

  • le mode onlyDownload émet updateAvailable quand un bundle est prêt
  • Appelez set() sur votre écran inactif pour l'appliquer
  • Plugin Android kiosk mode pour verrouiller l'appareil sur votre app
Mises à jour livrées par mois
1 Md+
Latence API typique
~50 ms
Appareils atteints
90M+
Apps utilisant Capgo
4,7k+

Comment ça marche

How restaurant teams ship a menu change with Capgo

Un flux typique pour une promotion lancée sur un seul marché. Chaque commande ci-dessous provient de la doc Capgo CLI.

  1. Créer un canal par marché ou pilote

    Autoriser l'auto-assignation pour que l'app rejoigne le canal du marché où se trouve l'utilisateur ou le kiosque.

    npx @capgo/cli@latest channel add market-uk --self-assign
    Doc sur les canaux
  2. Envoyer la promo sur une partie du marché

    Exécutez ceci depuis votre CI au moment du lancement. Le déploiement progressif envoie le bundle à une partie des appareils du canal pendant que les autres restent sur la version stable.

    npx @capgo/cli@latest bundle upload --channel market-uk --delta --rollout 10
    Docs sur le déploiement progressif
  3. Promouvez dès que les commandes passent

    Quand le processus de commande fonctionne comme prévu, déployez le bundle sur tous les appareils du canal.

    npx @capgo/cli@latest channel set market-uk --rollout-promote
    Docs sur le déploiement progressif
  4. Faites un rollback en plein rush

    Si la commande échoue, revenez à la version stable ou choisissez le bundle précédent dans l'historique du canal via la console.

    npx @capgo/cli@latest channel set market-uk --rollout-rollback
    Doc sur les rollbacks

Apps développées avec Capacitor

Les apps de restauration changent menus et campagnes en continu

Les apps de restauration rapide peuvent mettre à jour les promotions, le contenu du localisateur de restaurants, les avis de commande et les points d'entrée des campagnes régionales sans attendre l'approbation des stores.

Icône de l'application BURGER KING® APPLICATION

BURGER KING®

App de restauration avec bons de réduction, localisateur et surfaces de campagne.

Installations Google Play
14,3 M
Note du store
3.9
Jack in the Box® - Icône de l'application Order Food Alimentation et boissons

Jack in the Box® - Commander de la nourriture

Application de commande où le menu, les récompenses et le tunnel d'achat peuvent évoluer rapidement.

Installations Google Play
2,7 M
Note du store
2.5
Icône de l'application Denny's NOURRITURE ET BOISSONS

Denny's

Restaurant app where loyalty and food-ordering paths need frequent polish.

Installations Google Play
1,7 M
Note du store
4.7

Témoignages clients

Ce que disent les équipes qui déploient avec Capgo

5.0/5 noté par les équipes de développeurs 9,400+ équipes Lire les avis

Kapil

Fondateur, NuTriQ

“Pouvoir pousser instantanément des mises à jour OTA en production sans attendre les cycles complets de validation de l’App Store est un avantage opérationnel énorme.”

Portrait de Sergiu S

Sergiu S

Lead Developer, drivolino GmbH

« Le plugin Capgo Capacitor Updater a totalement transformé notre façon de déployer les mises à jour. Ce qui prenait des jours ne prend plus que quelques minutes. »

no-tone @ Webincode

Développeur, Webincode

« Pouvoir ajouter des Device ID à certains groupes et n'envoyer les changements qu'à certains groupes, ça nous sauve la vie. »

FAQ

Questions des équipes de restauration

Délais, bornes, marchés et l'impact d'un live update.

Pouvons-nous planifier le lancement d'un menu ?

Capgo ne possède pas de planificateur de release. Déclenchez l'upload depuis votre CI au moment voulu, par exemple via un workflow GitHub Actions planifié ou un lancement manuel le matin du déploiement. Si la nouvelle UI doit rester cachée jusqu'à une date précise, gérez l'accès via votre app ou votre backend.

Guide GitHub Actions

How do kiosks get updates if the app never closes?

En mode par défaut, les mises à jour s'appliquent quand l'app passe en arrière-plan, ce qu'une borne fait rarement. Réglez autoUpdate sur 'always' pour appliquer les mises à jour lors de la vérification périodique (toutes les 10 minutes par défaut), ou sur 'onlyDownload' et appelez set() quand la borne revient sur son écran d'attente.

Doc sur le comportement des mises à jour

Chaque marché ou marque peut-il exécuter une version différente ?

Oui. Donnez à chaque marque son propre app ID dans Capgo, et attribuez à chaque marché ou groupe pilote son propre canal. Les appareils rejoignent un canal avec setChannel() lorsque l'auto-assignation est autorisée, ou via un device override.

Doc sur les canaux

Et si une release promo casse les commandes ?

Effectuez un rollback du déploiement progressif ou choisissez le bundle précédent dans l'historique du canal. Si le nouveau bundle ne parvient pas à démarrer et n'appelle jamais notifyAppReady(), l'appareil revient automatiquement au dernier bundle fonctionnel.

Doc sur les rollbacks

Un live update peut-il modifier les prix du menu ?

Les prix proviennent généralement de votre backend ou de votre intégration POS, modifiez-les donc à cette source. Un live update modifie les écrans web qui affichent le menu et les prix. Les plugins natifs, les SDK de paiement et les mises à jour Capacitor nécessitent une release sur les stores.

Docs de compatibilité native

Prêt à déployer selon votre calendrier ?

Configurez des canaux par marché et un upload CI sur votre propre app durant l'essai.