Concevoir un site pour les réseaux mobiles du Bénin : 2G, 3G, 4G et ce que dit la documentation web

Concevoir un site pour les réseaux mobiles du Bénin : 2G, 3G, 4G et ce que dit la documentation web

Un site se juge sur le téléphone et le réseau de ceux qui l'ouvrent, pas sur l'ordinateur de celui qui l'a construit.

Réponse courte. Au 31 décembre 2025, selon l'ARCEP Bénin, 43,7 % des abonnements mobiles étaient en 2G, 18,6 % en 3G et 37,7 % en 4G (calcul sur les chiffres de l'observatoire). Ces chiffres comptent des abonnements, pas des visiteurs, et ils ne disent rien de la vitesse réelle. Ils suffisent pourtant à une décision de conception : prévoir qu'une part importante des visiteurs n'aura pas une connexion rapide. La documentation de référence en performance web (web.dev, MDN) donne des seuils et des pratiques précis pour y répondre. Voici ce que nous y avons lu, dans l'ordre d'une checklist pour un site de PME.

Transparence. BOVO Digital est une agence basée à Abomey-Calavi (Bénin) qui conçoit des sites web : nous avons un intérêt dans le sujet. Cet article ne repose sur aucune donnée, aucun client et aucun résultat de BOVO. Nous ne publions aucune mesure de vitesse de site : nous citons des chiffres de l'ARCEP et des documentations publiques, consultés le 7 novembre 2026. Ce qui relève de notre raisonnement est écrit comme tel.

Ce que disent les chiffres de l'ARCEP

L'observatoire de la téléphonie mobile du T4 2025 (tableau de bord au 31 décembre 2025, données des opérateurs) donne le total des abonnements mobiles actifs et leur répartition par technologie.

Les trois lignes de 2025 additionnent bien le total publié. En additionnant 2G et 3G, on obtient 11 316 289 abonnements, soit 62,2 % du total (calcul de notre part).

Comment lire ces chiffres, et comment ne pas les lire.

• Un abonnement n'est pas une personne. Une personne peut avoir plusieurs cartes SIM, et une carte peut ne servir qu'aux appels.
• La table classe les abonnements par technologie. Elle ne dit pas si le téléphone est capable de mieux, ni si la personne utilise le web mobile. Nous n'avons pas trouvé dans le document la règle de classement (par la carte SIM, par le terminal, par l'usage).
• La répartition varie beaucoup d'un trimestre à l'autre dans le document : la 3G passe de 6,80 millions au T4 2024 à 3,13 millions au T1 2025, quand la 4G passe de 4,45 à 6,84 millions. Nous ne savons pas pourquoi (migration réelle, changement de classement ou nettoyage de base) et nous ne commentons donc pas la tendance.
• Ces chiffres ne disent rien de la vitesse. web.dev, dans son modèle RAIL, avertit que la vitesse effective d'une connexion est souvent très inférieure à ce que laisse penser l'étiquette 2G, 3G ou 4G, à cause des pertes de paquets et des variations du réseau. La page ne porte pas de date.

Notre lecture, qui est un raisonnement et non un fait : une page conçue pour un réseau mobile moyen et un téléphone modeste sert aussi bien ceux qui ont mieux, alors que l'inverse est faux.

Les seuils de référence : Core Web Vitals

La page web.dev sur les Core Web Vitals (mise à jour du 31 octobre 2024) définit trois mesures et leur seuil « bon ».

La page précise que l'évaluation se fait au 75e centile des chargements de pages, séparément pour mobile et ordinateur. Autrement dit, ce n'est pas la moyenne qui compte : trois visites sur quatre doivent atteindre le seuil.

Checklist de PME, point par point

Chaque point reprend ce que la documentation recommande. Les pages citées sont consultées le 7 novembre 2026.

1. Images : la plupart du poids

• Choisir le format. La page web.dev sur le choix du format d'image dit que WebP et AVIF offrent en général une meilleure compression que les formats plus anciens et qu'il vaut mieux les utiliser quand c'est possible, avec un JPEG ou un PNG en solution de repli. Pour les photos, elle recommande JPEG, WebP avec perte ou AVIF, et d'essayer plusieurs niveaux de qualité JPEG pour trouver le bon compromis entre qualité et poids.
• Servir la bonne taille. D'après la page web.dev sur les images adaptatives, srcset avec des descripteurs de largeur donne au navigateur la largeur de chaque fichier, et sizes décrit la largeur d'affichage ; le navigateur choisit ensuite le plus petit fichier adapté. Autrement dit, ne servez pas à un téléphone l'image prévue pour un grand écran.
• Réserver la place. web.dev recommande d'ajouter width et height à toutes les balises img, ou de réserver l'espace avec la propriété CSS aspect-ratio, pour limiter les décalages de mise en page (CLS). Avec des images adaptatives, associez-les à height: auto.

2. Lazy loading : seulement hors de l'écran

• La page MDN sur le chargement différé (modifiée le 27 mars 2026) décrit l'attribut loading="lazy" : le navigateur diffère le chargement des ressources hors écran jusqu'à ce que l'utilisateur s'en approche, ce qui peut accélérer le chargement initial et réduire l'usage du réseau.
• La page web.dev sur le lazy loading des images précise de ne l'utiliser que pour les images hors de la zone visible au chargement, et de ne pas l'appliquer aux images probablement visibles, surtout l'image LCP.

3. Image principale (LCP) : la charger tôt

La page web.dev sur l'optimisation du LCP (mise à jour du 31 mars 2025) donne trois consignes.

• Si l'image LCP n'est référencée que depuis du CSS ou du JavaScript, la précharger dans le HTML.
• Mettre fetchpriority="high" sur l'image attendue comme LCP, sur une ou deux images au plus pour que cela garde son effet.
• Ne jamais lazy-loader l'image LCP.

La page donne aussi une répartition indicative du LCP en quatre parties : environ 40 % pour le délai avant le premier octet, moins de 10 % pour le délai avant le début du chargement de la ressource, environ 40 % pour sa durée de chargement et moins de 10 % pour le délai d'affichage. L'article précise que ce sont des repères approximatifs, à comparer entre eux, pas des budgets en millisecondes.

4. Polices : en limiter le nombre

La page web.dev sur les bonnes pratiques de polices recommande :

• le format WOFF2, présenté comme le plus compressé et le plus largement pris en charge ;
• de retirer les glyphes inutiles (sous-ensembles, avec unicode-range), en vérifiant la licence de la police ;
• de limiter le nombre de polices web, avec cette phrase : la police la plus rapide à livrer est celle qu'on ne demande pas ; des polices système pour le texte courant, ou une police variable si plusieurs graisses sont nécessaires ;
• de choisir font-display selon la priorité : optional limite le retard du texte à environ 100 ms mais peut ignorer la police si elle arrive tard, swap affiche le texte tout de suite mais peut provoquer des décalages de mise en page.

Sur l'hébergement des polices, la page nuance : l'auto-hébergement peut être plus rapide mais ce n'est « pas tranché » ; il faut comparer les temps de transfert avant de changer.

5. JavaScript : n'envoyer que le nécessaire

• La page web.dev sur le découpage de code recommande de scinder le paquet de JavaScript et de n'envoyer au départ que ce qui est nécessaire, avec des imports dynamiques pour les modules utiles plus tard.
• La page web.dev sur l'INP (mise à jour du 2 septembre 2025) explique que l'évaluation de scripts peut créer de longues tâches qui retardent la réponse aux interactions, et recommande de découper le travail en tâches séparées, de garder un DOM petit et d'éviter de produire de grandes quantités de HTML côté client en JavaScript.
• Nous n'avons pas lu de consigne chiffrée sur la taille maximale d'un paquet JavaScript dans ces pages, et nous n'en donnons donc pas. Notre raisonnement : chaque bibliothèque, chaque widget de chat, chaque pixel de suivi ajoute du code à télécharger et à exécuter ; la question à se poser est celle de leur utilité pour le visiteur.

6. Embeds et publicités : réserver l'espace

La page web.dev sur le CLS (mise à jour du 7 février 2025) recommande de réserver l'espace des publicités, embeds et iframes avec min-height ou aspect-ratio, et de placer plus bas dans la page le contenu qui arrive tard.

7. Mode économiseur de données (optionnel)

Save-Data est un en-tête de requête HTTP par lequel le client signale qu'il préfère moins de données. D'après MDN (modifiée le 17 décembre 2025), un serveur peut alors servir des images et vidéos plus petites, un balisage ou un style différents, ou désactiver les mises à jour automatiques. Le serveur doit renvoyer Vary: Save-Data pour que les caches distinguent les variantes. MDN classe cette fonction comme expérimentale et indique qu'elle n'est pas disponible dans certains navigateurs très répandus. Notre conclusion : à traiter comme un bonus, jamais comme la seule défense.

Mesurer : les outils et leurs limites

• PageSpeed Insights. La documentation explique que l'outil affiche des données de terrain issues du rapport CrUX (Chrome User Experience Report), sur les 28 derniers jours, au 75e centile, et des données de laboratoire produites par Lighthouse. En test mobile, le laboratoire émule un appareil moyen de gamme (Moto G4) sur un réseau mobile, depuis un centre de données de Google en Amérique du Nord, en Europe ou en Asie. Pas d'étiquette « Bénin ».
• Chrome DevTools et Lighthouse. Le modèle RAIL de web.dev indique que DevTools peut limiter le CPU et le réseau, et cite comme référence mondiale un Android moyen de gamme (Moto G4) sur une connexion 3G lente (400 ms de latence, 400 kbit/s) en l'absence de données sur vos propres utilisateurs. La page n'est pas datée et ce profil est un repère de test, pas une description des visiteurs béninois.
• WebPageTest. Outil de test de pages depuis différents appareils et connexions, selon la page RAIL de web.dev, qui cite la combinaison Moto G4 et 3G lente. Nous n'avons pas pu ouvrir sa documentation officielle (voir plus bas) et n'en décrivons donc pas les fonctions.

La limite à garder en tête. web.dev écrit que la mesure en laboratoire est essentielle mais n'est pas un substitut à la mesure sur le terrain, qui seule capture l'ensemble de la situation, y compris les appareils, les réseaux et les interactions des utilisateurs. Elle précise aussi que Lighthouse ne mesure pas l'INP, faute d'interaction réelle : il propose le Total Blocking Time (TBT) comme substitut de laboratoire. Un site qui obtient un bon résultat en laboratoire peut donc être lent pour ses visiteurs ; et un site avec trop peu de visites n'a parfois pas de données de terrain. Dans ce cas, nous n'avons rien à lire sur ses visiteurs réels.

Checklist de dix points

1. Les images sont en WebP ou AVIF avec solution de repli, à la taille d'affichage (srcset et sizes).
2. Toutes les images ont width et height (ou aspect-ratio).
3. Seules les images hors écran sont en loading="lazy" ; l'image LCP ne l'est jamais.
4. L'image LCP est préchargée si elle vient du CSS ou de JavaScript, et porte fetchpriority="high".
5. Une ou deux polices au plus, en WOFF2, sous-ensemble, avec un font-display choisi sciemment.
6. Le JavaScript est découpé ; chaque script tiers (chat, suivi, widgets) a une raison d'être.
7. Les embeds et iframes ont une place réservée.
8. Le site est testé avec une limitation CPU et réseau, sur un téléphone de gamme moyenne, pas seulement sur l'ordinateur de développement.
9. Les données de terrain (rapport CrUX dans PageSpeed Insights) sont consultées quand elles existent, au 75e centile.
10. Le parcours qui compte (par exemple payer ou demander un devis) est testé de bout en bout sur mobile.

Pour aller plus loin

Pour situer le contexte numérique béninois, voir la lecture du rapport BCEAO sur le Mobile Money. Sur le choix d'un socle technique et ses coûts, voir la comparaison des prix de sites sur mesure et la checklist Next.js pour PME. Si votre site doit surtout prendre des rendez-vous, voir vitrine ou prise de rendez-vous.

Ce que nous ne savons pas

• La vitesse réelle des visiteurs béninois. L'ARCEP publie des abonnements par technologie, pas des débits ni des temps de chargement. Nous n'avons trouvé aucune source ouverte que nous ayons relue sur ce point et n'avançons aucun chiffre.
• Le nombre de personnes derrière 18 178 786 abonnements, et la part qui navigue sur le web mobile.
• La règle de classement par technologie dans le document de l'ARCEP, et la cause des variations entre trimestres.
• Les performances de votre site. Nous n'avons testé aucun site pour cet article.
• La documentation de WebPageTest : docs.webpagetest.org présentait un certificat invalide le 7 novembre 2026 (échec de connexion) et webpagetest.org répondait 403 ; nous n'en décrivons donc pas les options.
• Une taille maximale de page ou de JavaScript recommandée par ces sources : nous n'en avons pas lu.
• L'âge de certaines pages. La page RAIL de web.dev, la page sur les polices et celle sur le lazy loading des images n'affichaient pas de date de mise à jour dans ce que nous avons lu. Leurs conseils peuvent avoir évolué.

Sources consultées le 7 novembre 2026

• ARCEP Bénin, observatoire de la téléphonie mobile T4 2025 (tableau de bord au 31 décembre 2025).
• web.dev, Web Vitals (mise à jour : 31 octobre 2024).
• web.dev, Optimize LCP (31 mars 2025), Optimize CLS (7 février 2025), Optimize INP (2 septembre 2025).
• web.dev, Choisir le bon format d'image, Images descriptives et adaptatives, Lazy loading des images, Bonnes pratiques de polices, Réduire le JavaScript par découpage, Modèle RAIL (pages sans date affichée).
• MDN, Lazy loading (27 mars 2026) et MDN, en-tête Save-Data (17 décembre 2025).
• Google, À propos de PageSpeed Insights (sans date affichée).
• WebPageTest : documentation non ouverte (voir ci-dessus).

Vous voulez un site pensé pour des visiteurs sur téléphone et réseau mobile, avec une mesure honnête de ses limites ? Découvrez notre expertise en création de site web au Bénin.