API Cloud WhatsApp vs API On-Premise :Laquelle choisir en 2026 ?
21 mai 2026
·
12 min de lecture
Dans cet article : La réponse en 60 secondes · Deux architectures · Tableau comparatif complet · Calendrier de dépréciation · Débit et limites de requêtes · Analyse détaillée des coûts · Le webhook entrant dont personne ne parle · Ce qui change lors de la migration · FAQ
La réponse en 60 secondes
En 2026, ce n'est pas un choix. L'API WhatsApp On-Premise a atteint sa fin de vie officielle le 23 octobre 2025. Meta a cessé de publier des correctifs de sécurité, a arrêté d'accepter les nouveaux enregistrements de numéros le 15 janvier 2024, et a signalé la pile On-Premise comme logiciel non pris en charge. Si vous exécutez toujours un conteneur Docker auto-hébergé, vous êtes sur une infrastructure obsolète.
L'API Cloud WhatsApp — où Meta héberge le serveur, gère la montée en charge, publie les correctifs et envoie les messages entrants à votre URL de webhook — est le paramètre par défaut pour chaque nouveau numéro WhatsApp Business depuis mi-2022. L'API Cloud est moins chère, plus rapide à provisionner, offre un débit plus élevé et reçoit les nouvelles fonctionnalités en priorité. Il n'existe aucun scénario en 2026 où l'On-Premise constitue la bonne réponse pour une nouvelle intégration.
Fin de vie On-Premise : 23 oct. 2025Aucun nouveau correctif — jamaisAPI Cloud : par défaut depuis 2022Coût infrastructure API Cloud : 0 $Débit Cloud : 1 000 msg/sPic On-Premise : ~30–50 msg/s
Deux architectures, un seul nom de plateforme
L'API Cloud et l'API On-Premise font techniquement partie de la « WhatsApp Business Platform ». Le branding est identique. L'architecture est complètement différente — et comprendre l'architecture est le seul moyen de comprendre pourquoi l'API Cloud l'a emporté.
WhatsApp Cloud API (hébergée par Meta)
Votre application envoie une requête HTTP POST à https://graph.facebook.com/v21.0/{phone_number_id}/messages. Meta la reçoit, achemine le message via son backend WhatsApp, le livre au client, et renvoie le statut de livraison ainsi que les réponses entrantes à votre URL de webhook enregistrée. Vous ne touchez jamais à un serveur. L'authentification repose sur un jeton d'accès permanent plus des signatures de charge utile HMAC-SHA256. Les médias sont hébergés sur le CDN de Meta avec une rétention de 90 jours.
WhatsApp On-Premise API (auto-hébergée, dépréciée)
Vous — ou votre BSP — exécutez deux images Docker publiées par Meta (whatsapp/coreapp et whatsapp/web) sur votre propre infrastructure. Le coreapp se connecte en sortie au relais de Meta, met en cache les messages dans une base de données MySQL et expose une API REST sur le port 443. Votre équipe gère la rotation des certificats, la réplication MySQL, le stockage des médias, les sauvegardes et chaque correctif de sécurité publié par Meta. La configuration matérielle minimale était de 4 vCPU et 8 Go de RAM par numéro de téléphone.
Si vous êtes toujours sur On-Premise : Le dernier correctif de sécurité a été publié le 23 octobre 2025. Aucun correctif futur n'est prévu. Vous exécutez un logiciel avec des vulnérabilités connues et non corrigées, aucune mise à jour de fonctionnalité et aucun support de Meta. La migration n'est pas optionnelle — elle est en retard.
Tableau comparatif complet
Dimension
Cloud API
On-Premise API
Statut en 2026
Active — par défaut
Fin de vie 23 oct. 2025
Qui héberge le serveur
Meta
Vous ou votre BSP
Empreinte matérielle
Aucune
4 vCPU + 8 Go de RAM minimum par numéro
Temps de configuration (via BSP)
Moins de 10 minutes
2–6 semaines (déploiement de conteneur + installation de certificat)
Authentification
Jeton d'accès + HMAC-SHA256
Certificat client + jeton bearer admin
Débit (par défaut)
80 msg/s par numéro
30–50 msg/s (limité par le matériel)
Débit (max)
1 000 msg/s sur demande
80 msg/s avec multi-nœuds + équilibreur de charge
Webhooks entrants
HTTP POST vers votre URL — format Graph API
HTTP POST vers votre URL — format REST On-Premise
Correctifs de sécurité
Publiés par Meta automatiquement
Récupération et déploiement manuels — aucun depuis oct. 2025
Hébergement des médias
CDN Meta, rétention de 90 jours
Votre stockage, votre politique de rétention
Nouvelles fonctionnalités (Flows, etc.)
Dès le premier jour
Rétroportés tardivement — ou jamais
Coût infrastructure/mois
0 $
400 $–1 200 $ par numéro de téléphone
Coût par conversation
Grille tarifaire Meta identique
Grille tarifaire Meta identique
Unification Graph API
Oui — surface partagée avec FB + IG
Non — surface REST séparée
Résidence des données
Centres de données Meta (États-Unis/UE)
Votre choix
Enregistrement de nouveau numéro
Ouvert
Fermé depuis le 15 janv. 2024
Calendrier de dépréciation
La plupart des articles comparatifs passent sous silence les dates. Ces dates constituent toute l'histoire. Si vous êtes toujours sur On-Premise, connaître précisément le moment où chaque porte s'est fermée vous indique à quel point votre situation est urgente.
1er août 2018
Lancement de l'API On-Premise
L'API WhatsApp Business est livrée exclusivement en version On-Premise. Conteneurs Docker auto-hébergés requis. L'histoire WhatsApp pour les entreprises commence.
19 mai 2022
Disponibilité générale de l'API Cloud
Annoncée au F8 2022. L'API Cloud devient accessible à toutes les entreprises. Meta recommande immédiatement Cloud comme voie d'intégration privilégiée pour tous les nouveaux numéros.
27 octobre 2023
API On-Premise officiellement dépréciée Dépréciée
Meta publie l'avis de dépréciation. Date de fin de vie fixée au 23 octobre 2025. Le compte à rebours commence. Chaque opérateur On-Premise est placé sur un calendrier de migration obligatoire.
15 janvier 2024
Fermeture des enregistrements de nouveaux numéros sur On-Premise
Meta cesse d'accepter les nouveaux numéros WhatsApp Business sur la pile On-Premise. Tous les nouveaux numéros doivent utiliser l'API Cloud. Les numéros On-Premise existants peuvent toujours fonctionner — temporairement.
23 octobre 2025
Fin de vie officielle — dernier correctif de sécurité Fin de vie
Le dernier correctif de sécurité a été publié. Les conteneurs On-Premise sont désormais un logiciel non pris en charge. Aucun correctif futur, aucune correction de bug, aucun rétroport de fonctionnalité. Tout opérateur On-Premise fonctionnant encore en 2026 exécute une base de code figée et non corrigée.
2026 et au-delà
API Cloud — la seule voie prise en charge Active
L'API Cloud est la seule intégration WhatsApp Business API prise en charge. WhatsApp Flows, Calling API (lancée en juillet 2025), nouveaux types de messages interactifs — tous arrivent d'abord sur Cloud, et exclusivement sur Cloud à l'avenir.
Débit et limites de requêtes : les chiffres qui comptent vraiment
Les paliers de messagerie quotidiens sont identiques entre Cloud et On-Premise — ils sont définis par le système de notation de la qualité des numéros de téléphone de Meta, et non par l'API que vous utilisez. Les deux API partagent les mêmes quatre paliers :
Palier 1 : 1 000 clients uniques initiés par l'entreprise par 24 heures (par défaut pour tous les nouveaux numéros)
Palier 2 : 10 000 clients uniques par 24 heures
Palier 3 : 100 000 clients uniques par 24 heures
Palier 4 : Illimité par 24 heures
Les messages de session (réponses dans une fenêtre de 24 heures ouverte par un client) n'ont aucune limite quotidienne à aucun palier. Là où l'API Cloud surpasse nettement l'On-Premise, c'est le débit par seconde :
API Cloud
1 000 msg/s
par numéro de téléphone (sur demande)
80 msg/s en configuration par défaut. Évolutif jusqu'à 1 000 msg/s sur demande pour les expéditeurs à haut volume. Meta absorbe la charge — aucune modification d'infrastructure requise de votre côté.
API On-Premise
30–50 msg/s
limite pratique (nœud unique)
La limite de 80 msg/s s'applique en théorie, mais Docker sur un seul nœud avec une VM 4 vCPU sature généralement à 30–50 msg/s. Atteindre 80 msg/s nécessite un réplica MySQL, une configuration multi-nœuds et un équilibreur de charge.
Pour une campagne Black Friday envoyant 100 000 messages en une fenêtre d'une heure, l'API Cloud absorbe la charge sans configuration. L'On-Premise nécessite un travail d'ingénierie en amont — déploiement multi-nœuds, réplication MySQL, équilibreur de charge devant le coreapp — et atteint malgré tout un plafond rigide que l'API Cloud supprime entièrement.
Ce que vous payez réellement
La tarification par conversation de Meta est identique pour les deux API. La différence réside entièrement dans les coûts fixes d'infrastructure. La plupart des articles comparatifs ignorent cet aspect car il est peu flatteur pour les BSP qui exploitent encore des piles On-Premise.
API Cloud — coût mensuel par numéro
Hébergement serveur0 $
Base de données (MySQL)0 $
Gestion des certificats0 $
Correctifs de sécurité / DevOps0 $
Stockage des médias0 $ (CDN Meta)
Frais de conversation MetaSelon volume
Surcoût infrastructure fixe0 $ / mois
API On-Premise — coût mensuel par numéro
Hébergement serveur (4 vCPU / 8 Go)150 $–400 $
MySQL (répliqué)80 $–200 $
Gestion des certificats TLS20 $–60 $
Ingénierie en astreinte150 $–400 $
Stockage des médias / CDN30 $–140 $
Frais de conversation MetaSelon volume
Surcoût infrastructure fixe430 $–1 200 $ / mois
Ces coûts d'infrastructure s'appliquent par numéro de téléphone. Une agence gérant 10 numéros WhatsApp clients en On-Premise brûlait 4 300 $–12 000 $/mois avant même de payer un seul frais de conversation à Meta. L'API Cloud élimine entièrement ce poste de dépense.
L'élément que tous les articles comparatifs oublient : les webhooks entrants sur l'API Cloud
Tous les articles sur l'API Cloud vs On-Premise se concentrent sur l'envoi sortant — campagnes, modèles, diffusions. Presque aucun n'explique ce qui arrive aux messages entrants sur l'API Cloud, et c'est là que la plupart des équipes rencontrent des problèmes après la migration.
Lorsqu'un client envoie un message à votre numéro WhatsApp Business connecté via l'API Cloud, l'infrastructure de Meta envoie une requête HTTP POST à votre URL de webhook enregistrée. Cela se produit en quelques millisecondes. La charge utile est un objet JSON structuré au format Graph API de Meta. Votre serveur — ou une plateforme de webhooks — doit :
Être accessible publiquement en HTTPS en permanence
Être capable de répondre avec un HTTP 200 dans les 20 secondes (sinon Meta réessaie)
Vérifier la signature HMAC-SHA256 dans l'en-tête X-Hub-Signature-256 avant tout traitement
Analyser le format de charge utile Graph API — qui diffère du format REST On-Premise
Voici à quoi ressemble une charge utile de message entrant de l'API Cloud lorsqu'elle est normalisée via l'intégration de webhook WhatsApp de SocialHook — livrée à votre point de terminaison dans un format cohérent quel que soit le type de message :
cloud-api-inbound-payload.json — livré <50ms via SocialHook
{ "platform":"whatsapp", "event":"message.received", "timestamp":1747123456, "from":"+44 7700 900 123", "conversation_id":"conv_4m9x...", "message": { "type":"text", "body":"Je viens de passer à l'API Cloud. Quand commence l'intégration ?", "id":"wamid.HBgL..." }, "delivery": { "status":"delivered", "latency_ms":38 } }
Le rôle de SocialHook dans une pile API Cloud : L'API Cloud de Meta livre les événements entrants à un seul point de terminaison. SocialHook s'intercale entre Meta et votre serveur — gérant la vérification des webhooks (HMAC-SHA256), normalisant le format de charge utile Graph API, ajoutant une reprise automatique 3x avec backoff exponentiel si votre serveur retourne un code non-200, et journalisant chaque livraison avec un historique complet des statuts. Votre serveur reçoit un événement JSON propre et cohérent. Peu importe que le message provienne de WhatsApp, de Facebook Messenger ou des Messages Directs Instagram — le format de charge utile est identique pour les trois. Un seul point de terminaison. Trois canaux. Forfait 50 $/mois.
Ce qui change réellement lors de la migration de l'On-Premise vers l'API Cloud
La migration de votre numéro de téléphone de l'On-Premise vers l'API Cloud est prise en charge et préserve votre numéro — les clients ne remarquent aucun changement. Mais votre code côté serveur nécessite des mises à jour à trois endroits précis que la plupart des guides de migration enterrent en notes de bas de page.
1
Méthode d'authentification Changement critique
L'On-Premise utilisait des certificats TLS client et un jeton bearer admin. L'API Cloud utilise un jeton d'accès permanent pour les requêtes sortantes et HMAC-SHA256 pour la vérification des charges utiles entrantes. Vous devez mettre à jour vos en-têtes d'authentification et implémenter la vérification de signature dans votre gestionnaire de webhook avant la mise en production.
2
Structure de la charge utile entrante Changement critique
L'API REST On-Premise et l'API Graph Cloud utilisent des structures JSON différentes pour les événements de webhook entrants. Les noms de champs, l'imbrication et les métadonnées diffèrent. Votre analyseur de charge utile nécessitera une réécriture complète — ou vous utilisez une couche de normalisation comme SocialHook qui abstrait totalement cet aspect de votre code applicatif.
3
Logique de téléchargement des médias
L'On-Premise stockait les médias entrants sur votre serveur. L'API Cloud stocke les médias sur le CDN de Meta avec une politique de rétention de 90 jours. Lorsqu'un client envoie une image ou un document, votre charge utile de webhook contient un ID de média. Vous devez appeler l'API Cloud pour récupérer l'URL de téléchargement, puis récupérer le fichier. Tout code existant lisant depuis un chemin local cessera de fonctionner.
4
Point de terminaison de l'API sortante
L'On-Premise exposait une API REST sur le port 443 de votre conteneur. L'API Cloud utilise le point de terminaison Graph API de Meta à graph.facebook.com. Le format de requête, l'en-tête d'authentification et la structure d'URL diffèrent tous. Mettez à jour la configuration de votre client HTTP et les corps de requête en conséquence.
5
Arrêt de l'infrastructure
Après migration et validation, décommissionnez vos conteneurs Docker, votre instance MySQL et la surveillance associée. C'est là que vous récupérez les 400 $–1 200 $/mois. Vérifiez qu'aucun code applicatif ne pointe encore vers l'ancien point de terminaison local avant le décommissionnement.
L'On-Premise est-il jamais la bonne réponse en 2026 ?
Nous avons examiné chaque argument en faveur du maintien de l'On-Premise en 2026. Voici l'analyse honnête :
Exigences de résidence des données
L'argument historique le plus solide pour l'On-Premise était la souveraineté des données — conserver les métadonnées des messages dans votre propre VPC, dans une juridiction spécifique. L'API Cloud fait transiter les données via l'infrastructure de Meta (centres de données aux États-Unis et dans l'UE). Pour les entreprises soumises à certaines réglementations gouvernementales ou financières, il s'agissait d'une contrainte réelle. En 2026, la plupart de ces scénarios sont résolus grâce aux paramètres de résidence des données conformes au RGPD de Meta dans l'UE, ou via les niveaux API Entreprise de Meta avec des accords de traitement des données explicites. L'argument de la résidence des données résiste rarement à un examen juridique aujourd'hui — et il ne résiste pas à l'argument de sécurité consistant à exécuter un logiciel non corrigé.
Piles BSP héritées
Certains BSP n'ont pas terminé la migration de l'ensemble de leur flotte On-Premise vers l'API Cloud. Si votre pile WhatsApp est gérée par un BSP et qu'ils ne vous ont pas encore migré, faites pression. Fortement. Ils exploitent un logiciel non pris en charge en votre nom. Tout incident de sécurité sur leur pile On-Premise après octobre 2025 engage leur responsabilité — et potentiellement la vôtre.
Le verdict
Il n'existe aucun scénario de nouvelle construction en 2026 où l'On-Premise constitue le choix correct. Pour les déploiements On-Premise existants avec des contraintes de résidence des données — consultez votre équipe juridique concernant les conditions de l'accord de traitement des données de Meta et les options de centre de données dans l'UE, puis migrez aussi rapidement que cet examen le permet. Exécuter un logiciel non corrigé ne constitue pas une posture de conformité valide pour aucun secteur réglementé.
Si vous construisez une nouvelle intégration WhatsApp aujourd'hui : Commencez par l'API Cloud. Utilisez un BSP ou une plateforme de webhooks pour la configuration. Enregistrez votre numéro de téléphone, configurez votre point de terminaison webhook et faites parvenir votre premier message entrant à votre serveur. L'ensemble du processus — y compris la connexion à SocialHook pour que votre webhook reçoive du JSON propre — prend moins de 15 minutes. Consultez le guide de démarrage rapide.
FAQ
Questions fréquentes
L'API WhatsApp On-Premise est-elle encore prise en charge en 2026 ?
Non. Meta l'a officiellement dépréciée le 27 octobre 2023, et la date de fin de vie finale était le 23 octobre 2025. Aucun correctif de sécurité n'a été publié depuis cette date, aucun nouveau numéro de téléphone ne peut être enregistré sur On-Premise (fermé depuis le 15 janvier 2024), et aucune nouvelle fonctionnalité ne sera jamais rétroportée. Toute personne exécutant encore un conteneur auto-hébergé en 2026 utilise un logiciel non pris en charge et non corrigé.
Qu'est-ce que l'API Cloud WhatsApp et en quoi diffère-t-elle de l'On-Premise ?
L'API Cloud WhatsApp est la version hébergée par Meta de la WhatsApp Business Platform. Vous appelez graph.facebook.com pour envoyer des messages — Meta gère toute l'infrastructure. L'On-Premise vous obligeait à exécuter des conteneurs Docker sur vos propres serveurs, à gérer MySQL, à faire tourner les certificats TLS et à déployer vous-même les correctifs de sécurité. L'API Cloud élimine toute cette charge opérationnelle.
Quelles sont les limites de débit de l'API Cloud WhatsApp ?
L'API Cloud prend en charge 80 messages par seconde par numéro de téléphone par défaut, évolutive jusqu'à 1 000 messages par seconde sur demande pour les expéditeurs à haut volume. Les paliers de messagerie quotidiens (1K / 10K / 100K / illimité de clients uniques par 24h) sont identiques entre Cloud et On-Premise — ils sont contrôlés par le système de notation de qualité de Meta, et non par la version de l'API.
Ai-je besoin de mon propre serveur pour recevoir des messages WhatsApp entrants sur l'API Cloud ?
Oui — ou vous avez besoin d'une plateforme de webhooks. Lorsqu'un client envoie un message à votre numéro, l'API Cloud envoie une requête HTTP POST à votre URL de webhook enregistrée. Vous avez besoin d'un serveur accessible publiquement (ou d'un service comme SocialHook) pour recevoir, vérifier la signature HMAC-SHA256 et traiter la charge utile. Sans un point de terminaison webhook fonctionnel, les messages entrants ne vous parviennent jamais de manière programmatique.
Comment la tarification de l'API Cloud se compare-t-elle à celle de l'On-Premise ?
La tarification par conversation de Meta est identique pour les deux. La différence réelle réside dans le coût fixe d'infrastructure. L'On-Premise nécessitait 400 $–1 200 $/mois par numéro de téléphone en hébergement, MySQL, surveillance et ingénierie. L'API Cloud a un coût d'infrastructure de 0 $ — Meta l'absorbe entièrement. Le coût total de possession sur l'API Cloud est généralement 30 à 60 % inférieur à celui de l'On-Premise pour un même volume de messages.
Qu'est-ce qui change sur mon serveur lors de la migration de l'On-Premise vers l'API Cloud ?
Trois changements critiques : (1) Authentification — l'On-Premise utilisait des certificats client ; l'API Cloud utilise un jeton d'accès et une vérification de signature HMAC-SHA256. (2) Structure de la charge utile — l'API Cloud utilise le format JSON Graph API, qui diffère de la structure REST de l'On-Premise. (3) Gestion des médias — l'On-Premise stockait les médias sur votre serveur ; l'API Cloud les stocke sur le CDN de Meta, nécessitant un appel API pour récupérer les URL de téléchargement. Votre gestionnaire de webhook, votre analyseur de charge utile et votre logique de gestion des médias nécessitent tous une mise à jour.
L'API Cloud est en ligne. Commencez à recevoir des webhooks.
Connectez votre numéro WhatsApp Cloud API à SocialHook et recevez chaque message entrant livré à votre serveur sous forme de JSON propre — vérifié, normalisé, réessayé en cas d'échec — en moins de 50 ms. Aucune infrastructure. Aucun Docker. Aucune astreinte.
Arrêtez de gérer les API Meta. Commencez à construire.
Connectez votre premier compte Facebook, Instagram ou WhatsApp en moins de 2 minutes. Votre webhook reçoit son premier payload avant que votre café refroidisse.
