Quand une commande Uber Eats apparaît dans votre caisse, c'est grâce à un dialogue entre plusieurs systèmes via des API (Application Programming Interfaces). Comprendre comment ça marche vous aide à mieux choisir vos outils et diagnostiquer les problèmes.
Qu'est-ce qu'une API ?
Une API est un protocole de communication entre logiciels. Concrètement, c'est une manière standardisée pour qu'un système puisse demander des données ou déclencher des actions sur un autre système.
Exemples concrets :
- L'API Uber Eats permet à un agrégateur de récupérer les nouvelles commandes
- L'API de votre POS permet à un agrégateur d'y injecter une commande
- L'API Stripe permet à votre POS de déclencher un paiement
Les API utilisent généralement HTTP/REST avec des données au format JSON.
Le flux complet d'une commande livraison
Voici ce qui se passe quand un client passe commande sur Uber Eats :
- Client commande : l'app Uber Eats envoie la commande aux serveurs Uber
- Notification au restaurant : Uber notifie votre restaurant via webhook (notification push)
- Réception par l'agrégateur : si vous utilisez Pepprio, c'est lui qui reçoit le webhook
- Injection dans votre POS : Pepprio appelle l'API de votre POS pour créer la commande
- Affichage en cuisine : votre KDS reçoit la commande de votre POS
- Confirmation préparation : quand vous "bumpez" la commande prête, votre POS en informe Pepprio
- Mise à jour Uber : Pepprio appelle l'API Uber pour signaler la commande prête
- Livreur informé : Uber informe le livreur que la commande peut être récupérée
Toute cette chaîne s'exécute en quelques secondes.
Les standards d'API en restauration
Webhooks
Notification asynchrone : le système A envoie une requête HTTP à une URL du système B dès qu'un événement se produit. Idéal pour les commandes : pas besoin que B vérifie en boucle.
REST API
Architecture standard pour les requêtes / réponses. Le système B "demande" à A des données ou des actions. C'est ce qu'on utilise pour mettre à jour le statut d'une commande, désactiver un article, modifier un prix.
Authentification
Les API restaurant utilisent généralement des clés API ou OAuth 2.0. Ce sont des "mots de passe machine" qui authentifient les requêtes. Critique pour la sécurité.
Les défis techniques
Latence
Chaque appel API prend du temps (50-500 ms). Sur une chaîne de 7-8 appels, ça peut représenter plusieurs secondes. En période de rush, cette latence peut s'accumuler.
Gestion des erreurs
Que se passe-t-il si l'API du POS est indisponible quand une commande arrive ? Les bons agrégateurs implémentent du retry (renvoi automatique) et du dead letter queue (mise en attente des messages échoués pour traitement ultérieur).
Évolution des API
Les plateformes mettent à jour leurs API régulièrement. Une mauvaise gestion des versions peut casser votre intégration sans préavis. Les bonnes intégrations incluent un monitoring qui détecte les changements et alerte avant qu'un problème impacte les clients.
Synchronisation
Si une commande est modifiée en cours de préparation côté Uber Eats, comment l'information remonte-t-elle ? Les API doivent gérer ces cas. Pas tous le font bien.
Pourquoi un agrégateur est plus fiable qu'une intégration directe
En théorie, vous pourriez intégrer directement Uber Eats à votre POS via API. Plusieurs limitations :
Les plateformes n'ouvrent pas leurs API à tous Uber Eats réserve l'accès à son API à des partenaires sélectionnés. Pepprio est un partenaire officiel.
La maintenance est lourde Chaque plateforme évolue indépendamment. Maintenir 4 intégrations directes (Uber, Deliveroo, Just Eat, Glovo) à jour est un travail à temps plein.
Les normes varient Une commande Uber n'a pas la même structure qu'une commande Deliveroo. Le travail de normalisation est important.
La tolérance aux pannes Un agrégateur professionnel a des serveurs redondants, du monitoring 24/7, des plans de continuité. Difficile à reproduire pour un restaurant indépendant.
C'est pour ça qu'un agrégateur comme Pepprio est non seulement plus simple, mais souvent plus fiable techniquement qu'une intégration directe maison.
Les éléments à vérifier dans une API
Quand vous évaluez un agrégateur ou un POS, questions à poser sur leur API :
- Quels événements sont synchronisés ? Création, modification, annulation, statut, paiement ?
- Quelle est la latence moyenne ? Combien de temps entre une commande sur Uber Eats et son apparition dans la caisse ?
- Comment sont gérées les erreurs ? Retry automatique ? Notification au restaurant ?
- L'API est-elle versionnée ? Une nouvelle version casse-t-elle l'ancienne ?
- Quel monitoring est en place ? Tableau de bord visible côté restaurant ?
- Quelle est la disponibilité (SLA) ? 99 % ? 99.9 % ? 99.99 % ?
Sur ce dernier point, la différence est importante. 99 % d'uptime = 7,3 heures d'indisponibilité par mois. 99.9 % = 43 minutes par mois. En heure de pointe, la différence se mesure en commandes manquées.
L'architecture moderne d'un restaurant connecté
Une stack technique restaurant moderne ressemble à :
[Plateformes Livraison] → [Agrégateur (Pepprio)] → [POS] → [KDS Cuisine]
↓
[Analytics consolidée]
↓
[Comptabilité, BI]
Chaque flèche est une intégration via API. La robustesse de l'ensemble dépend de la robustesse de chaque maillon.
Conclusion
Vous n'avez pas besoin de comprendre les détails techniques pour faire de la livraison. Mais comprendre l'architecture vous aide à poser les bonnes questions à vos fournisseurs et choisir des outils robustes.
Pepprio investit massivement dans la qualité de ses intégrations API : monitoring continu, retry automatique, SLA élevé. C'est invisible quand tout fonctionne, mais c'est ce qui fait la différence un vendredi soir à 20h30.