WhatsApp Cloud API vs On-Premises : notre guide 2026

Meta a déprécié l'API WhatsApp Business On-Premises le 27 octobre 2023, avec une fin de vie officielle fixée au 23 octobre 2025 (source : annonce officielle Meta for Developers). Si votre boutique Shopify ou votre fournisseur WhatsApp Business exécute encore un container auto-hébergé en 2026, vous tournez sur un logiciel non supporté. Ce guide reprend le comparatif Cloud API vs On-Premises que je fais avec chaque marchand qui me pose la question, le vrai scope de migration, et les rares cas où l'auto-hébergement peut encore se défendre.

La réponse en 30 secondes

Le WhatsApp Business Platform se décline en deux produits : Cloud API (Meta héberge le serveur, vous appelez graph.facebook.com) et On-Premises API (vous exécutez un container Docker, gérez une base MySQL, renouvelez les certificats TLS et patchez les failles de sécurité). L'On-Premises est apparue en 2018 et a été dépréciée le 27 octobre 2023. Cloud API est la configuration par défaut depuis mi-2022 pour chaque nouveau numéro WhatsApp Business.

En 2026, Cloud API est moins cher, plus rapide à mettre en place et monte jusqu'aux mêmes limites de taux que l'On-Premises sans aucune infrastructure à gérer. Pour un marchand Shopify, la vraie question n'est pas "quelle API choisir" mais "si j'ai hérité d'un On-Premises, à quelle vitesse dois-je migrer". Pour la majorité, la réponse est ce trimestre.

WhatsApp Business Platform : les deux architectures

Cloud API (hébergée par Meta, la configuration par défaut)

Votre application Shopify envoie une requête POST à https://graph.facebook.com/v21.0/{phone_number_id}/messages. Meta la reçoit, route le message via son backend WhatsApp, le livre au client, puis pousse les accusés de réception et les réponses entrantes vers votre URL de webhook. Vous ne touchez à aucun serveur. L'authentification se fait par jeton d'accès, pas par certificat client.

On-Premises API (auto-hébergée, dépréciée)

Vous ou votre BSP exécutez une image Docker fournie par Meta (whatsapp/coreapp et whatsapp/web) sur votre propre infrastructure. Le coreapp ouvre une connexion sortante vers le relais Meta, met en cache les messages dans une base MySQL, expose une API REST sur le port 443 que votre application appelle, et reçoit les webhooks sur votre serveur. Vous gérez la rotation de certificat, la réplication MySQL, le stockage des médias, les sauvegardes, et vous déployez chaque patch de sécurité Meta.

Meta avait créé l'On-Premises pour permettre aux entreprises soumises à des règles strictes de conserver les métadonnées de message dans leur propre VPC. Le prix : 400 à 1 200 USD par mois d'infrastructure, une astreinte dédiée, et une migration récurrente à chaque version cassante publiée par Meta.

Comparatif côte à côte

Pour la spécification exacte, Meta documente chaque endpoint et payload webhook dans sa référence Cloud API. La référence On-Premises est figée à la version finale 2.53.x et n'est plus mise à jour.

La timeline de l'arrêt On-Premises

Sources : l'annonce officielle de dépréciation Meta citée en début d'article et le changelog Meta for Developers.

Dans les conversations que j'ai eues avec des marchands Shopify au Q1 2026, les équipes restées sur On-Premises tombent dans trois catégories : des BSP qui n'ont pas terminé la migration de leur parc, des messageries internes enfermées dans un VPC verrouillé, et des marchands dont l'agence précédente a disparu avec les identifiants. Dans les trois cas, migrer dans les 90 prochains jours règle la dette.

Limites de taux et débit : ce qui change vraiment

Les niveaux de messagerie sont identiques entre Cloud et On-Premises, parce que les deux dépendent du scoring qualité de numéro Meta :

• Tier 1 : 1 000 clients uniques business-initiated par 24 heures (défaut pour les nouveaux numéros)
• Tier 2 : 10 000 clients uniques par 24 heures
• Tier 3 : 100 000 clients uniques par 24 heures
• Tier 4 : illimité par 24 heures

Les messages de session, qui répondent dans la fenêtre des 24 heures d'un client, n'ont pas de plafond journalier, quel que soit le niveau.

Là où Cloud API prend l'avantage, c'est sur le plafond de débit par seconde. Cloud API tient 80 messages par seconde par numéro en configuration de base, extensible sur demande jusqu'à 1 000 messages par seconde pour les gros broadcasters. L'On-Premises est aussi plafonnée à 80 messages par seconde par défaut, mais seulement si votre container Docker a assez de CPU et d'IOPS MySQL pour suivre. En pratique, sur une VM 4 vCPU en monospace, les marchands atteignent 30 à 50 messages par seconde avant que le coreapp ne commence à renvoyer des erreurs 429.

Pour une campagne WhatsApp qui envoie 100 000 messages sur une heure en Black Friday, Cloud API absorbe la charge, alors qu'On-Premises demande un déploiement multi-nœuds, une réplique MySQL et un load balancer devant le coreapp.

Tarification par conversation : même grille, charges fixes différentes

Meta facture par conversation, pas par message. Une conversation est une fenêtre de 24 heures ouverte par le premier message échangé entre votre entreprise et un client. Dans cette fenêtre, vous échangez un nombre illimité de messages pour un seul coût de conversation. Le prix dépend de la catégorie (marketing, utilité, authentification, service) et du pays.

Tarifs extraits de la grille publique WhatsApp Business Platform d'avril 2026 :

Ces tarifs s'appliquent à l'identique à Cloud API et On-Premises. La différence se joue sur les charges fixes en dessous :

Pour un marchand Shopify qui envoie 50 000 conversations marketing par mois en France, la ligne Meta est identique : 2 250 euros. La différence entre Cloud et On-Premises, ce sont les 400 à 1 400 USD de surcoût infra par mois que le Cloud efface.

L'arbre de décision pour les marchands

Neuf marchands Shopify sur dix aboutissent à Cloud API via un BSP comme Kanal ou une intégration directe. Déroulez ces quatre questions dans l'ordre :

1. Quel est votre volume mensuel de conversations ?

• Moins de 200 000 conversations : Cloud API avec n'importe quel BSP. L'économie d'infrastructure paie à elle seule les frais du BSP.
• 200 000 à 5 millions : Cloud API avec un BSP qui gère les augmentations de débit par seconde et les pools de numéros partitionnés. Kanal, Gupshup et Twilio savent faire.
• Plus de 5 millions : Cloud API reste la bonne réponse, mais vous calez avec votre BSP une stratégie de numéros multiples et des limites de taux sur tier partenaire.

2. Avez-vous des contraintes RGPD ou de résidence de données ?

• Non : Cloud API. Point.
• Oui, données personnelles ou financières générales : Cloud API reste en général suffisant parce que le contenu du message transite de toute façon par Meta, et Cloud API est conforme RGPD, ISO 27001 et SOC 2 Type II selon le trust center Meta. Pour un e-commerce européen, la sous-traitance est couverte par les clauses contractuelles types Meta.
• Oui, santé stricte ou service public : étudiez d'abord Cloud API avec un BSP capable d'attester la chaîne de conformité avant de retomber sur On-Premises. Dans 99 % des revues juridiques, l'équipe conformité valide Cloud API quand elle comprend que Meta héberge les deux endpoints de toute façon.

3. Quelles compétences infrastructure avez-vous en interne ?

• Aucune : Cloud API avec un BSP. Zéro ligne de Docker à écrire.
• Équipe DevOps solide et envie d'une plateforme de messagerie maison : vous pouvez déployer Cloud API vous-même avec un wrapper léger sur graph.facebook.com. L'On-Premises n'a plus d'avantage dans ce scénario en 2026.

4. Combien vous coûte l'On-Premises aujourd'hui ?

Si vous avez un déploiement On-Premises existant, additionnez les coûts fixes : VM, MySQL, monitoring, astreinte, forfait agence, et les heures passées sur chaque montée de version cassante Meta. La plupart des marchands que j'audite trouvent 500 à 2 000 USD d'économies mensuelles en migrant, sans compter l'écart de fonctionnalités (Flows, catalogue intégré, indicateur de frappe).

Migration : ce qui casse, ce qui reste

Si vous tournez sur On-Premises aujourd'hui, voici le scope honnête du chantier :

Ce qui reste

• Votre numéro, le nom d'affichage, le profil business et le score qualité se transfèrent automatiquement.
• Les templates approuvés passent sans resoumission.
• La forme des webhooks (messages, statuses) est assez proche pour que la plupart des handlers n'aient qu'à changer l'URL et la signature.
• Le tarif par conversation est identique.

Ce qui casse et demande du travail

• L'authentification passe du certificat client au jeton d'accès permanent. Tout code qui lit le cert sur disque doit être réécrit.
• Les endpoints /v1/contacts, /v1/messages, /v1/media sont remplacés par https://graph.facebook.com/v{version}/{phone_number_id}/{resource}.
• Les URL de médias sont désormais hébergées par Meta avec rétention de 90 jours. Si vous stockiez les médias dans votre propre bucket S3, vous devez les télécharger et les archiver dans la fenêtre de rétention.
• Les endpoints admin (/v1/users, /v1/settings) n'ont pas d'équivalent Cloud. La gestion des utilisateurs passe par l'interface Business Manager.
• L'historique de messages MySQL ne se transfère pas. Conservez un snapshot en lecture seule pour audit.

Runbook de migration

1. Gelez les changements de templates deux semaines avant la bascule pour éviter les conflits d'approbation.
2. Enregistrez votre application sur Cloud API, générez un jeton d'accès permanent et configurez le nouveau webhook.
3. Utilisez l'endpoint de migration de numéro Meta pour transférer le numéro. L'appel est POST /{phone_number_id}/request_code puis POST /{phone_number_id}/register.
4. Faites pointer votre client sortant vers Graph API. Chez les clients Kanal, c'est une modification de 10 lignes dans un seul service.
5. Réenregistrez votre webhook et validez la vérification de signature.
6. Faites tourner 24 à 72 heures de trafic en shadow, pendant lesquelles Cloud API gère le réel et le container On-Premises reste en lecture seule.
7. Éteignez le container On-Premises. Gardez le snapshot MySQL 180 jours.

Comptez 30 à 90 minutes de coupure messagerie par numéro sur la bascule réelle. Pour les marchands Shopify, je planifie hors heures de pic commandes et je mets en pause les flows de relance de panier abandonné pendant la fenêtre.

Quand On-Premises a-t-elle encore du sens en 2026 ?

Quasiment jamais. Les rares scénarios qui tiennent :

1. Réseau air-gapped sans aucune sortie Internet : vous ne pouvez pas appeler graph.facebook.com, donc Cloud API est hors-jeu. Dans ce cas, la recommandation Meta (et la mienne) est de mettre un proxy bastion léger plutôt que de maintenir l'On-Premises.
2. Messagerie d'entreprise interne avec obligation juridique que les métadonnées ne transitent pas par le CDN Meta : rare, et résolu en général quand le juridique comprend que les deux API se terminent sur l'infrastructure Meta.
3. Déploiement bancaire ou assurantiel grandfathered avec approbation explicite du régulateur sur l'architecture On-Premises : ces équipes ont déjà planifié la migration Cloud avec le support entreprise Meta.

Si vous êtes une boutique Shopify, une marque DTC ou un e-commerce de moins de 100 salariés, rien de tout cela ne vous concerne. Cloud API est la bonne réponse, et plus la migration est rapide, moins vous accumulez de dette.

Comment Kanal traite ce sujet pour les marchands Shopify

Chez Kanal, chaque nouveau marchand est onboardé sur Cloud API par défaut. Nous n'avons jamais provisionné d'On-Premises pour une boutique Shopify, et nous avons migré 37 marchands d'anciens BSP On-Premises vers Cloud API sur le Q1 2026, avec une coupure médiane sous les 45 minutes par numéro.

Le pitch est simple : vous connectez Shopify en moins de 10 minutes, nous gérons la vérification Meta Business, et vous lancez vos campagnes WhatsApp et notifications de commande le jour même. Meta Cloud API s'occupe de l'infrastructure. Nous, nous fournissons la couche marchande : synchronisation Shopify, bibliothèque de templates, chatbot IA, et le tarif est forfaitaire avec le coût Meta de conversation en pass-through.

Si vous tournez encore sur On-Premises et voulez un devis de migration honnête, réservez une démo ou lisez d'abord mon guide complet WhatsApp Business API.

FAQ

WhatsApp On-Premises API est-elle dépréciée ?

Oui. Meta a déprécié l'API On-Premises le 27 octobre 2023 et annoncé la fin de vie au 23 octobre 2025. Depuis cette date, Meta ne publie plus de correctifs de sécurité ni de nouvelles fonctionnalités, et le Business Platform est désormais exclusivement Cloud API pour les nouveaux numéros. Les installations existantes reçoivent encore techniquement du trafic en 2026, mais sans mises à jour ni support Meta.

Qu'est-ce qui change avec Cloud API par rapport à On-Premises ?

Meta héberge lui-même le serveur de messagerie dans ses data centers, donc vous n'exécutez plus de container Docker, de base MySQL ni de certificat. Votre application parle directement à graph.facebook.com avec les mêmes schémas Graph API que Messenger et Instagram. Les limites de taux dépendent désormais du niveau de qualité de votre numéro, pas de votre infrastructure, et montent de 1 000 à illimité conversations par 24 heures.

Puis-je migrer d'On-Premises vers Cloud API sans perdre mon numéro ?

Oui. Meta a prévu un flux de migration qui conserve votre numéro, votre nom d'affichage et vos templates approuvés. Le numéro est transféré en un appel API, le container On-Premises est ensuite éteint, et le webhook est réenregistré sur les nouveaux endpoints Graph. Comptez 30 à 90 minutes de coupure par numéro et refactorez tout ce qui dépendait d'un certificat client.

Quelles sont les limites de taux Cloud API en 2026 ?

Meta calibre les messages business-initiated par qualité de numéro : Tier 1 envoie à 1 000 contacts uniques par 24 heures, Tier 2 monte à 10 000, Tier 3 à 100 000, et Tier 4 est illimité. Les messages de session répondant dans la fenêtre des 24 heures n'ont pas de plafond journalier. La limite applicative est 80 messages par seconde par numéro, extensible sur demande jusqu'à 1 000 messages par seconde.

Est-ce que certaines entreprises ont encore intérêt à s'auto-héberger en 2026 ?

Quasiment jamais. Des banques et des acteurs de santé invoquent encore la résidence des données, mais Cloud API est hébergé dans les mêmes data centers Meta qui traitent les messages de toute façon, donc l'auto-hébergement ne met pas le contenu WhatsApp hors de l'infrastructure Meta. Les rares cas valides sont les plateformes de messagerie internes qui ne peuvent pas appeler graph.facebook.com en sortie.

Cloud API coûte-t-il plus cher qu'On-Premises en 2026 ?

Non. Meta a supprimé les frais d'hébergement. Vous payez le même tarif par conversation qu'en On-Premises, plus les frais de votre BSP comme Kanal pour la couche produit. Une installation auto-hébergée coûte typiquement 400 à 1 200 USD par mois d'infrastructure avant frais plateforme, soit l'économie complète que réalise la migration Cloud.

Pour conclure

En 2026, le comparatif WhatsApp Cloud API vs On-Premises a une seule bonne réponse pour un marchand Shopify : choisir Cloud. Meta a acté la fin de vie, les limites de taux sont alignées, le tarif par conversation est identique, et le surcoût d'infrastructure n'existe que d'un côté. La seule question intéressante qui reste, c'est la vitesse de migration si vous avez hérité d'un On-Premises.

Pour un second avis sur votre stack, explorez l'intégration Shopify Kanal ou comparez les fournisseurs dans notre comparatif des fournisseurs WhatsApp Business API avant de vous engager.