Combien de numéros de call tracking faut-il ? Dimensionner un pool DNI en 2026

Technique · 28 juillet 2026 · 10 min

C'est l'une des premières questions qu'on nous pose au moment d'activer le call tracking dynamique : « il me faut combien de numéros ? ». La réponse intuitive — « un numéro par visiteur » — est fausse, et coûteuse. Vous n'avez pas besoin d'autant de numéros que de visiteurs dans la journée, mais d'autant de numéros que de visiteurs présents en même temps sur votre site. Or ces deux chiffres n'ont rien à voir : un site à 500 visites par jour dépasse rarement une quinzaine de sessions réellement simultanées.

Mal poser ce calcul a deux conséquences opposées, toutes deux pénalisantes. Trop peu de numéros, et une partie de vos appels retombe sur le numéro par défaut, sans source : ils quittent votre attribution. Trop de numéros, et vous payez chaque mois une location de lignes qui ne servent à rien. Cet article vous donne les formules exactes, un tableau de dimensionnement par volume de trafic, et le coût réel d'un mauvais calibrage.

Pourquoi utiliser un pool de numéros plutôt qu'un seul numéro ?

Parce qu'un seul numéro ne permet d'attribuer l'appel qu'à une source globale, jamais à un visiteur précis. La différence tient à la granularité de l'attribution, et c'est tout le cœur du sujet des numéros de tracking dynamiques.

Dans le call tracking statique, vous attribuez un numéro fixe à un canal : un numéro pour Google Ads, un pour le SEO, un pour l'affichage. Simple, mais grossier : vous savez qu'un appel vient de Google Ads, pas de quelle campagne ni de quel mot-clé. Dans le call tracking dynamique par session, une réserve de numéros — le pool — tourne entre les visiteurs. Quand un internaute arrive, le script d'insertion dynamique (DNI) lui affiche un numéro libre du pool, rattaché à sa session complète : source, campagne, mot-clé, page d'entrée. Tant que ce visiteur navigue (ou pendant une fenêtre définie après sa visite), ce numéro lui est réservé.

C'est exactement pour cette réservation temporaire qu'il faut plusieurs numéros. Si deux visiteurs arrivent en même temps, ils ne peuvent pas voir le même numéro — sinon un appel entrant serait impossible à rattacher à l'un ou à l'autre. Le pool doit donc contenir assez de numéros pour couvrir tous les visiteurs présents simultanément, plus une marge. La taille du pool n'est donc pas une question de volume total, mais de simultanéité.

Un pool de numéros, ce n'est pas un stock à consommer sur la journée : c'est un vestiaire. Vous n'avez pas besoin d'un casier par visiteur du jour, mais d'un casier par visiteur présent en même temps.

Combien de numéros de call tracking faut-il vraiment ?

La règle de référence, partagée par la plupart des plateformes de call tracking en 2026, tient en une phrase : un numéro de tracking pour 8 à 10 visiteurs simultanés sur les sources couvertes par le pool. Cette recommandation, documentée notamment par WhatConverts et Dexem, part d'un constat pratique : la probabilité que plus de 8 à 10 visiteurs partagent la même fenêtre de session sans qu'aucun numéro ne se libère est faible pour un trafic de PME.

La confusion la plus fréquente vient de la base de calcul. On raisonne en visiteurs quotidiens (« j'ai 500 visites par jour, il me faut donc 50 numéros ! ») alors qu'il faut raisonner en visiteurs simultanés. Or les deux diffèrent d'un ordre de grandeur : un site à 500 visites/jour, avec une session moyenne de 3 minutes, présente en moyenne une quinzaine de sessions actives à un instant donné aux heures de pointe — et donc un besoin d'environ 20 numéros seulement, marge comprise.

Trois repères simples pour la plupart des sites :

• Petit site (moins de 100 visites/jour) : 4 à 6 numéros suffisent.
• Site moyen (100 à 1 000 visites/jour) : 8 à 15 numéros.
• Site à fort trafic (1 000+ visites/jour) : 15 à 30 numéros et plus, selon les pics.

Ces fourchettes valent pour un pool couvrant l'ensemble du trafic web. Si vous ne mettez le call tracking dynamique que sur une partie des sources (par exemple Google Ads uniquement), c'est le pic de simultanéité de ces sources qui compte — presque toujours bien plus bas que le trafic global.

Comment calculer la taille exacte de votre pool ?

Les fourchettes ci-dessus donnent un ordre de grandeur ; deux formules éprouvées permettent d'affiner. Elles convergent, mais partent d'angles différents.

Méthode 1 — Le pic horaire divisé par quatre (CallRail)

La plus rapide. Ouvrez votre outil d'analyse (GA4), regardez l'heure la plus chargée d'une semaine normale, et relevez le nombre de sessions issues des sources suivies pendant cette heure. Divisez ce chiffre par 4. Une heure de pointe à 40 sessions donne un pool cible d'environ 10 numéros. La logique : sur une heure, les sessions se répartissent, et diviser par quatre approxime le nombre de sessions réellement chevauchantes.

Méthode 2 — La formule de simultanéité (Nimbata)

Plus précise, car elle intègre la durée de session. La formule est : (visiteurs par heure ÷ (60 ÷ durée moyenne de session en minutes)) × 1,3. Le facteur 1,3 est une marge de sécurité de 30 % pour absorber les pics. Exemple : 60 visiteurs sur l'heure de pointe, session moyenne de 4 minutes. On calcule 60 ÷ (60 ÷ 4) = 60 ÷ 15 = 4 visiteurs simultanés, puis × 1,3 = 5 à 6 numéros.

Notre conseil de terrain : calculez avec les deux, et retenez le résultat le plus élevé, arrondi au numéro supérieur. Il vaut toujours mieux un numéro de marge qu'un appel perdu. Et n'oubliez pas la fenêtre de session : plus vous conservez longtemps un numéro réservé à un visiteur après sa visite (pour capter les rappels différés), plus le numéro reste « occupé » longtemps, et plus il vous en faut. Une fenêtre de rétention longue augmente mécaniquement la taille de pool nécessaire.

Quel pool selon la taille de votre trafic ?

Voici le tableau de dimensionnement que nous utilisons pour cadrer un pool en fonction du trafic réel d'un site, en supposant une session moyenne de 3 à 4 minutes et une répartition classique du trafic dans la journée.

Deux nuances importantes. D'abord, ces chiffres supposent que tout le trafic passe par le pool. Si vous ne suivez en dynamique que le trafic payant — le cas le plus rentable, car c'est là que l'attribution rapporte le plus — divisez d'autant. Ensuite, un trafic très concentré (une campagne d'emailing qui envoie tout le monde en même temps, un passage TV, un pic saisonnier) casse ces moyennes : dimensionnez sur le pic, pas sur la moyenne. Ce raisonnement rejoint directement notre analyse du coût des appels manqués : un appel non tracké est aussi grave qu'un appel non décroché, il représente du revenu que vous ne pouvez plus rattacher ni optimiser.

Que se passe-t-il si le pool est mal dimensionné ?

Les deux erreurs — trop petit et trop grand — ont des symptômes opposés mais coûtent l'une comme l'autre.

Pool sous-dimensionné : la fuite d'attribution. Quand tous les numéros du pool sont « occupés » et qu'un nouveau visiteur arrive, il ne reste plus de numéro à lui attribuer. La plupart des plateformes affichent alors le numéro par défaut du site, celui qui n'est rattaché à aucune source. Si ce visiteur appelle, son appel entre bien — mais sans origine. Il tombe dans le « direct / non attribué » et disparaît de vos rapports par source. Aux heures de pointe, précisément quand vos meilleures campagnes tournent à plein, ce sont vos appels les plus qualifiés qui échappent à la mesure. C'est le pire moment pour perdre la donnée.

Pool sur-dimensionné : le budget gaspillé. Chaque numéro de tracking se loue au mois. Un pool deux fois trop grand, c'est une facture deux fois trop élevée, sans aucun gain d'attribution : au-delà de votre pic réel de simultanéité, les numéros supplémentaires ne captent rien de plus. Sur-dimensionner peut aussi diluer la lecture des données si des numéros restent inutilisés pendant des semaines.

Le bon réflexe : surveiller votre taux d'appels non attribués une fois le pool en place. S'il grimpe, votre pool déborde. S'il est nul et que des numéros ne sont jamais assignés, vous payez trop. Le pool idéal maintient un taux d'appels non attribués proche de zéro avec le plus petit nombre de numéros possible.

Faut-il un pool par source ou un pool global ?

Cela dépend du niveau de granularité que vous visez. Les deux approches coexistent, et le bon choix dépend de vos enjeux d'attribution.

Un pool global couvre tout le trafic web avec une seule réserve de numéros, et distingue les sources grâce aux paramètres de session (le script sait d'où vient chaque visiteur). C'est l'approche standard, la plus économique : un pool unique bien dimensionné suffit à attribuer chaque appel à sa source, sa campagne et son mot-clé. Elle convient à la quasi-totalité des PME.

Un pool par source (voire par campagne) réserve une réserve de numéros distincte à chaque canal. C'est plus lourd et plus coûteux, mais utile dans deux cas : quand vous voulez cloisonner strictement le budget d'un canal à fort volume, ou quand une source génère à elle seule un pic de simultanéité qui justifie son propre dimensionnement — typiquement une grosse campagne Google Ads dont vous importez les conversions d'appels pour nourrir le Smart Bidding.

Dans les faits, commencez par un pool global bien calibré. Ne passez à des pools par source que si un canal précis sature ou si vous avez besoin d'un cloisonnement budgétaire net. Et quelle que soit l'architecture, la règle reste la même : le pool se dimensionne sur le pic de visiteurs simultanés des sources qu'il couvre, jamais sur le total quotidien. Une fois ce réflexe acquis, dimensionner un pool devient une opération de dix minutes dans GA4 — et vous cessez définitivement de perdre des appels dans l'angle mort de votre attribution.