Combien de numéros WhatsApp pour un agent IA : la formule

Sur whasp, le nombre de numéros WhatsApp dont votre agent IA a besoin est le plus grand de trois quotients, chacun arrondi à l’entier supérieur : utilisateurs actifs divisés par 80, inscriptions de votre jour le plus chargé divisées par 32, et messages envoyés lors de votre jour le plus chargé divisés par 1 200. Ce sont 80 % des limites par numéro. Ajoutez un ou deux numéros de réserve pour les bannissements.

Quelles limites a un numéro ?

Un numéro whasp est un vrai compte WhatsApp personnel sur son propre téléphone cloud et sa propre IP : ses limites s’appliquent donc par numéro. La référence de l’API les liste :

Un numéro est marqué at_risk quand une limite dépasse 80 %, donc les plafonds de planification sont 80 utilisateurs, 32 nouveaux chats et 1 200 envois. Deux autres faits comptent dans un plan. Les messages d’un même numéro partent un par un, à environ une seconde d’écart : une file de 120 réponses met donc environ deux minutes à se vider. Et le compte autorise 100 requêtes d’API par 10 secondes, soit 10 par seconde, le rythme de 10 numéros qui envoient à fond. Au-delà, mettez les envois en file d’attente de votre côté.

Comptez les utilisateurs actifs comme le fait whasp : les personnes qui ont écrit sur 30 jours glissants, pas le total des inscrits. Celles qui se taisent sortent du compte après 30 jours. GET /v1/numbers/{number}/chats liste qui a écrit et quand, ce qui vous permet de le mesurer.

Comment calculer le nombre de numéros nécessaires ?

Le calcul prend trois entrées tirées de vos propres données : les utilisateurs actifs (U), les nouveaux utilisateurs de votre jour le plus chargé (S), et les messages que vous envoyez lors de votre jour le plus chargé (M). Chaque limite donne un nombre, et le plus grand l’emporte :

• par utilisateurs : U / (100 × 0,8) = U / 80
• par inscriptions : S / (40 × 0,8) = S / 32
• par envois : M / (1 500 × 0,8) = M / 1 200

Ajoutez ensuite une réserve de 10 %, au moins un numéro. Quand un numéro passe critical (banni, déconnecté, téléphone hors ligne depuis plus de 10 minutes, ou envois en échec), /numbers/pick cesse de le proposer et sa part des nouvelles inscriptions retombe sur les autres. Le remplaçant arrive gratuitement mais vide, et votre propre logique déplace les utilisateurs. La réserve leur laisse de la place le temps de la bascule. Chaque numéro coûte $49 par 30 jours.

// Limites par numéro d'après la référence de l'API whasp, et la charge visée.
const LIMITS = { users: 100, signups: 40, sends: 1500 };
const PLAN = 0.8; // au-delà de 80 % d'une limite, un numéro est marqué at_risk

export function numbersNeeded(users: number, busiestDaySignups: number, busiestDaySends: number) {
  const byUsers = Math.ceil(users / (LIMITS.users * PLAN));
  const bySignups = Math.ceil(busiestDaySignups / (LIMITS.signups * PLAN));
  const bySends = Math.ceil(busiestDaySends / (LIMITS.sends * PLAN));
  const base = Math.max(byUsers, bySignups, bySends);
  const spare = Math.max(1, Math.ceil(base * 0.1)); // de la place pour un numéro qui passe critical
  return { byUsers, bySignups, bySends, base, spare, total: base + spare, monthlyUsd: (base + spare) * 49 };
}

À quoi ressemblent trois plans réalistes ?

Les trois plans ci-dessous reposent sur des hypothèses que nous avons choisies, pas sur des mesures. Remplacez-les par les chiffres de vos propres journaux.

Un tuteur de langues avec 3 000 utilisateurs actifs

Supposons que 25 % des utilisateurs actifs écrivent un jour donné, que l’agent envoie 12 messages à chacun, que le jour le plus chargé vaut le double d’un jour moyen, et qu’un lancement amène 400 nouveaux utilisateurs en un jour.

• Envois : 3 000 × 0,25 × 12 = 9 000 un jour moyen, 18 000 le jour le plus chargé.
• Par utilisateurs : 3 000 / 80 = 37,5, donc 38. Par inscriptions : 400 / 32 = 12,5, donc 13. Par envois : 18 000 / 1 200 = 15.
• Le plus grand est 38. Réserve : 10 % de 38 = 3,8, donc 4. Total 42 numéros, 42 × $49 = $2 058 par mois, soit $0,69 par utilisateur actif.

Ici, ce sont les utilisateurs qui décident.

Un compagnon bavard avec 1 200 utilisateurs actifs

Supposons que 50 % écrivent un jour donné, que l’agent envoie 40 messages à chacun, que le jour le plus chargé vaut 1,5 fois un jour moyen, et que 100 nouveaux utilisateurs arrivent ce jour-là.

• Envois : 1 200 × 0,5 × 40 = 24 000 un jour moyen, 36 000 le jour le plus chargé.
• Par utilisateurs : 1 200 / 80 = 15. Par inscriptions : 100 / 32 = 3,1, donc 4. Par envois : 36 000 / 1 200 = 30.
• Le plus grand est 30. Réserve 3. Total 33 numéros, 33 × $49 = $1 617, soit $1,35 par utilisateur actif.

Ici, ce sont les messages qui décident. À 80 utilisateurs par numéro, 1 200 envois par jour permettent 15 messages par utilisateur actif et par jour. Ce compagnon en envoie 30 par utilisateur actif le jour le plus chargé : il lui faut donc deux fois plus de numéros que ne le suggère son nombre d’utilisateurs.

Un lancement avec 1 000 inscriptions en un jour

Supposons 1 000 utilisateurs au total et 6 000 messages envoyés ce jour-là.

• Par utilisateurs : 1 000 / 80 = 12,5, donc 13. Par inscriptions : 1 000 / 32 = 31,25, donc 32. Par envois : 6 000 / 1 200 = 5.
• Le plus grand est 32. Réserve 4. Total 36 numéros, $1 764 par mois.

Étalons maintenant les mêmes 1 000 inscriptions sur cinq jours, 200 par jour, avec 1 200 envois le jour le plus chargé :

• Par utilisateurs : 13. Par inscriptions : 200 / 32 = 6,25, donc 7. Par envois : 1 200 / 1 200 = 1.
• Le plus grand est 13. Réserve 2. Total 15 numéros, $735 par mois.

Une liste d’attente ou des codes d’invitation économiseraient 21 numéros et $1 029 par mois. Dans cet exemple, c’est la limite de nouveaux chats par jour qui joue, pas celle des utilisateurs.

Comment router les nouveaux utilisateurs et les garder sur un numéro ?

GET /v1/numbers/pick renvoie le numéro sain et en ligne qui a le plus de place pour un nouvel utilisateur, et un lien wa.me qui ouvre le chat. Passez text et le lien s’ouvre avec ce message prérempli. Mettez-y l’identifiant de votre utilisateur, pour que l’agent sache qui écrit (plus de détails sur les liens d’accueil).

const API = "https://api.whasp.ai/v1";
const headers = { Authorization: `Bearer ${process.env.WHASP_API_KEY}` };

/** Le lien à montrer à un nouvel utilisateur, ou null quand tous les numéros sont pleins. */
export async function signupLink(userId: string): Promise<string | null> {
  const params = new URLSearchParams({ text: `Salut, mon code est ${userId}` });
  const res = await fetch(`${API}/numbers/pick?${params}`, { headers });
  if (res.status === 409) return null; // no_capacity : mettre l'inscription en attente, ajouter un numéro
  if (!res.ok) throw new Error(`pick failed with ${res.status}`);
  const { wa_link } = (await res.json()) as { number: string; wa_link: string };
  return wa_link;
}

Un chat reste sur son numéro. Quand vous envoyez sans from, whasp utilise le numéro auquel la personne a écrit en dernier, ce que vous voulez. Un from différent renvoie 409 chat_not_open, sauf si cette personne a aussi écrit à ce numéro.

Quand signupLink renvoie null, affichez un écran d’attente et ajoutez des numéros. Ajoutez-les avant d’en avoir besoin : POST /v1/numbers peut répondre 503 no_capacity quand aucun n’est prêt (rien n’est débité), et un numéro mis en place de zéro prend environ 30 minutes.

Comment surveiller la marge et ajouter des numéros ?

Interrogez GET /v1/numbers toutes les quelques minutes. Chaque numéro renvoie ses stats et ses limits : vous pouvez ainsi additionner la place restante jusqu’à 80 % sur les numéros sains et déclencher une alerte pour tout numéro qui n’est pas healthy. Le webhook number.status_changed vous prévient dès que la santé ou online change (gestion des webhooks).

type Num = {
  number: string;
  status: "provisioning" | "active" | "retired";
  health: "healthy" | "at_risk" | "critical";
  stats: { active_chats_30d: number; new_chats_24h: number; outbound_24h: number };
  limits: { active_chats_30d: number; new_chats_24h: number; outbound_24h: number };
};

/** Place libre sur les numéros sains, comptée jusqu'à 80 % de chaque limite. */
export async function headroom() {
  const res = await fetch(`${API}/numbers`, { headers });
  const { data } = (await res.json()) as { data: Num[] };
  const live = data.filter((n) => n.status === "active");
  const sick = live.filter((n) => n.health !== "healthy").map((n) => n.number);
  const room = { users: 0, signups: 0, sends: 0 };
  for (const n of live.filter((n) => n.health === "healthy")) {
    room.users += Math.max(0, Math.floor(n.limits.active_chats_30d * PLAN) - n.stats.active_chats_30d);
    room.signups += Math.max(0, Math.floor(n.limits.new_chats_24h * PLAN) - n.stats.new_chats_24h);
    room.sends += Math.max(0, Math.floor(n.limits.outbound_24h * PLAN) - n.stats.outbound_24h);
  }
  return { numbers: live.length, sick, room };
}

/** Ajoute un numéro. Cela débite $49 immédiatement : appelez-le derrière un plafond. */
export async function addNumber(label: string): Promise<Num> {
  const res = await fetch(`${API}/numbers`, {
    method: "POST",
    headers: { ...headers, "Content-Type": "application/json" },
    body: JSON.stringify({ label, profile: { name: "Ava", about: "Ton amie IA" } }),
  });
  if (res.status === 402) throw new Error("balance too low: top up first");
  if (res.status === 503) throw new Error("no_capacity: nothing charged, retry later");
  if (!res.ok) throw new Error(`add failed with ${res.status}`);
  return (await res.json()) as Num;
}

Appelez addNumber quand room.users tombe sous le nombre d’inscriptions que vous attendez dans les deux prochaines semaines, ou room.signups sous votre jour le plus chargé, et plafonnez le total pour qu’un bug ne puisse pas dépenser votre solde. Gardez le solde au-dessus de numéros × $49 : un numéro se renouvelle tout seul tant que le solde le couvre, et quand le solde est épuisé, il bénéficie de 3 jours de grâce, puis il est retiré.

Plusieurs produits ou clients

Un compte n’a qu’une URL de webhook : faites donc tourner un pool par produit, persona ou client, et distinguez-les vous-même. Donnez à chaque numéro un label tel que tutor-fr-1, réglez son profil (nom, à propos, photo) sur la persona, et routez chaque événement d’après son champ number. Lancez numbersNeeded par pool. La facturation passe par un solde unique : facturez donc chaque client de votre côté pour son nombre de numéros × $49.

Comment se comparent les limites de l’API Business ?

Meta limite le nombre de personnes différentes qu’une entreprise peut contacter hors de la fenêtre de service client de 24 heures, par période glissante de 24 heures et par portefeuille d’entreprise, partagé par tous ses numéros. Les nouveaux portefeuilles démarrent à 250. La vérification, ou l’envoi de 2 000 messages livrés de haute qualité, porte la limite à 2 000. Ensuite, elle monte automatiquement à 10 000, 100 000 puis illimité quand vos messages sont de haute qualité et que vous avez utilisé au moins la moitié de la limite au cours des 7 derniers jours.

La plateforme officielle passe à l’échelle par quotas, whasp par téléphones. Les réponses dans la fenêtre ne font pas partie du palier de Meta et nous n’avons trouvé aucun plafond d’utilisateurs actifs par numéro officiel : pour un agent que Meta admet, un seul numéro officiel peut donc servir une très large audience. La première question est de savoir si votre IA y est autorisée, et la comparaison des prix montre ce que coûte la voie officielle.

Que faire ensuite ?

Tirez trois chiffres de vos propres journaux : les utilisateurs actifs sur 30 jours glissants, les inscriptions de votre jour le plus chargé et les messages envoyés ce jour-là. Lancez numbersNeeded et ajoutez les numéros un lancement à l’avance. Branchez la vérification de marge, et lisez pourquoi les numéros se font bannir pour dimensionner votre réserve.