Étude : la performance des sites web tunisiens en 2026

Tout le monde répète que les sites tunisiens sont lents. Personne ne l'avait mesuré sérieusement. Nous avons donc conduit, en septembre 2026, la première étude systématique de la performance du web tunisien : 205 sites soumis à l'analyse, 120 mesurés intégralement, douze secteurs couverts, une dizaine d'indicateurs relevés pour chacun, en conditions mobiles et ordinateur.

Cette étude est publiée sans nommer aucun site. Notre objectif n'est pas de désigner des responsables, mais de donner au marché un point de repère qui lui manquait. Les résultats individuels sont communiqués gratuitement à tout responsable technique qui en fait la demande.

Ce que nous avons trouvé n'est pas ce que nous attendions. Le problème du web tunisien n'est ni l'hébergement, ni le budget, ni même le poids des pages. Il est ailleurs, et il est réparable.

1. Les résultats d'ensemble

Le tableau contient déjà toute l'histoire de cette étude. Deux lignes sont excellentes : le temps de réponse du serveur, à 89 millisecondes, et la stabilité visuelle médiane. Toutes les autres sont mauvaises, et l'écart entre l'ordinateur et le mobile est spectaculaire.

Autrement dit : les serveurs tunisiens répondent vite. Ce sont les pages qu'ils servent qui sont lourdes, bavardes et mal optimisées pour un téléphone.

2. Quinze pour cent des sites seulement sont dans le vert

Google classe les sites en trois zones selon le temps d'affichage du contenu principal sur mobile : bon sous 2,5 secondes, à améliorer jusqu'à 4 secondes, mauvais au-delà. Nous avons ajouté une quatrième tranche, au-delà de 8 secondes, parce que le panel l'imposait.

Quarante-quatre pour cent des sites mesurés dépassent les huit secondes. Pour situer l'enjeu : les études d'audience mobile montrent qu'une majorité de visiteurs abandonne une page qui met plus de trois secondes à s'afficher. À huit secondes, le trafic mobile est, pour l'essentiel, perdu avant d'avoir vu quoi que ce soit.

Le site le plus lent du panel n'a jamais terminé son chargement : notre outil a coupé la mesure à 45 secondes.

3. Le grand écart : un web conçu pour le bureau

C'est le résultat le plus net de l'étude. Sur ordinateur, le panel affiche une médiane de 1,2 seconde — une performance parfaitement honorable, au niveau des standards internationaux. Sur mobile, la même médiane grimpe à 6,7 secondes, soit 5,5 fois plus.

L'écart ne vient pas du réseau. Il vient de la façon dont les sites sont conçus et validés : sur l'écran du concepteur, avec une connexion en fibre et une machine puissante. La version mobile est ensuite obtenue par adaptation visuelle — les colonnes se replient, le menu devient un bouton — mais rien n'est allégé techniquement. Les mêmes images sont téléchargées, les mêmes scripts s'exécutent, sur un processeur dix fois moins rapide.

Ce constat est d'autant plus préoccupant qu'en Tunisie, la majorité du trafic web est mobile. Le web tunisien est donc optimisé pour la minorité de ses visiteurs.

4. Le coupable n'est pas celui qu'on croit

Nous nous attendions à trouver une relation forte entre le poids des pages et leur lenteur. Les données disent autre chose.

La corrélation entre le poids total d'une page et son temps d'affichage est de 0,03 sur notre panel — c'est-à-dire nulle. La corrélation avec le nombre de requêtes réseau, en revanche, atteint 0,46. Et le temps de blocage par le JavaScript, médian à 558 millisecondes pour un seuil recommandé de 200, confirme la piste.

Deux secteurs illustrent parfaitement ce mécanisme, et ils se contredisent en apparence :

• La santé et la pharmacie affichent le poids médian le plus faible de toute l'étude, à 1,4 Mo, et pourtant un temps d'affichage de 9,2 secondes — parmi les pires du panel.
• L'enseignement transporte 8,8 Mo par page, soit six fois plus, et s'affiche pourtant en 5,5 secondes, dans la première moitié du classement.

La conclusion est contre-intuitive mais solide : ce qui tue la performance, ce n'est pas le nombre de mégaoctets, c'est le nombre de fichiers à aller chercher et le temps que le téléphone passe à exécuter du JavaScript avant de pouvoir afficher quoi que ce soit.

Une grande image bien compressée se télécharge d'un bloc et s'affiche. Quarante petits scripts tiers — mesure d'audience, chat, bandeau de consentement, carrousel, polices, pixels publicitaires — déclenchent quarante allers-retours réseau et bloquent le fil d'exécution principal, pendant que l'écran reste blanc.

Trente-cinq pour cent des sites du panel dépassent les 100 requêtes réseau, et un site atteint 271 requêtes pour une seule page. C'est là que se joue la partie.

5. Le paradoxe du budget : les plus riches sont les plus lents

Le classement sectoriel est le résultat le plus commenté de cette étude, et le plus difficile à expliquer par les moyens.

Les télécommunications ferment la marche à 18,8 secondes, suivies des banques à 14,1 secondes et des entreprises publiques à 13,1 secondes. En tête, on trouve les sites d'emploi et d'immobilier à 4,2 secondes, le tourisme à 4,8 secondes et le commerce en ligne à 5,3 secondes.

L'explication n'est pas technique, elle est organisationnelle. Plus une organisation est grande, plus sa page d'accueil devient un territoire disputé : la direction marketing veut sa bannière vidéo, la communication son carrousel, l'analytique ses trois outils de mesure, le juridique son bandeau de consentement, le service client son module de chat. Chaque demande est légitime prise isolément. Personne n'est responsable du total, et personne ne le mesure.

À l'inverse, les secteurs en tête partagent une caractéristique : leur chiffre d'affaires dépend directement de la vitesse. Un site d'annonces dont les pages mettent huit secondes perd ses visiteurs, donc ses annonceurs. La performance y est un sujet de direction générale, pas un sujet technique.

Deux secteurs présentent en outre un temps de réponse serveur anormalement élevé : l'enseignement à 708 millisecondes et les télécommunications à 346 millisecondes, contre 89 millisecondes pour la médiane du panel. Dans ces deux cas, l'infrastructure fait bel et bien partie du problème — ce qui reste l'exception.

6. Un site sur deux est inaccessible sans le « www »

Au-delà de la vitesse, nous avons testé sur un sous-échantillon de 94 sites les quatre adresses possibles d'un même domaine : avec et sans « www », en http et en https. Ce test simple a produit le résultat le plus brutal de l'étude.

Quarante-sept sites sur 94 — exactement la moitié — ne répondent pas lorsque l'adresse est saisie sans le « www ». Le site fonctionne parfaitement en « www », mais l'internaute qui tape le nom de domaine seul, comme le fait la majorité des gens, obtient un message d'erreur de son navigateur. Aucune redirection n'a été configurée pour rattraper le cas.

Dans le même sous-échantillon, 22 sites ne redirigent pas automatiquement le http vers le https, et 9 sites n'ont pu être mesurés qu'en http, faute de version sécurisée exploitable. Treize sites servent la même page sur plusieurs adresses sans en désigner une comme canonique — une configuration qui divise le référencement d'un site entre plusieurs versions de lui-même.

Ce n'est pas un détail cosmétique. Un visiteur qui obtient une erreur ne recommence pas avec une autre orthographe : il retourne aux résultats de recherche et clique sur le concurrent. Un lien partagé sans le « www » dans un message ou sur un réseau social ne mène nulle part. Et un moteur de recherche qui trouve deux versions d'un même site répartit la valeur entre elles au lieu de la concentrer.

La correction prend une dizaine de minutes : déclarer les deux entrées DNS, choisir la version canonique, rediriger l'autre en 301 permanent, forcer le https. C'est le meilleur rapport entre temps investi et trafic récupéré de toute cette étude.

7. Ce que vous pouvez corriger dès cette semaine

Nos mesures désignent des causes précises, donc des corrections précises. Dans l'ordre d'efficacité constaté sur le panel.

Réduire le nombre de requêtes avant de réduire le poids

C'est la variable la plus corrélée à la lenteur. Inventoriez les scripts tiers chargés par votre page d'accueil : outils de mesure installés puis oubliés, widgets de réseaux sociaux, polices importées depuis plusieurs sources, modules de chat inactifs. Sur la plupart des sites que nous auditons, un tiers des requêtes peut être supprimé sans qu'aucun utilisateur ne s'en aperçoive.

Différer le JavaScript non essentiel

Un temps de blocage médian de 558 millisecondes signifie que le téléphone passe plus d'une demi-seconde à exécuter du code avant de pouvoir dessiner l'écran. Les attributs de chargement différé, le découpage du code et la suppression des bibliothèques utilisées à 5 % de leurs capacités règlent l'essentiel du problème.

Traiter les images pour ce qu'elles sont : le premier poste de poids

Format moderne type WebP ou AVIF, dimensions réelles d'affichage et non dimensions d'origine, chargement différé pour tout ce qui se trouve sous la ligne de flottaison. Une page d'accueil n'a pas besoin de télécharger huit visuels de carrousel dont l'utilisateur ne verra que le premier.

Vérifier vos quatre adresses

Tapez votre domaine avec et sans « www », en http et en https. Les quatre doivent aboutir à la même page, sur la même version canonique, en https. Si ce n'est pas le cas, corrigez-le aujourd'hui.

Activer ce qui est gratuit côté serveur

Compression, cache navigateur, HTTP/2 ou HTTP/3. Ces réglages ne coûtent rien et sont souvent inactifs par défaut. Notre étude montre que l'infrastructure est rarement le goulot d'étranglement, mais quand elle l'est — comme dans l'enseignement, avec 708 millisecondes de temps de réponse — le gain est immédiat.

Mesurer sur mobile, et pas sur votre écran

C'est la règle qui résume toutes les autres. Le décalage de 5,5 fois entre l'ordinateur et le mobile constaté dans cette étude vient d'abord du fait que personne ne regarde la version mobile avec les yeux d'un vrai téléphone sur un vrai réseau.

Le lien entre vitesse et classement est détaillé dans vitesse d'un site et référencement Google, et le cas particulier de WordPress dans pourquoi votre WordPress est lent. Ce que l'hébergement change réellement — et ce qu'il ne change pas — est décrit sur notre page datacenters.

8. Méthodologie

Précision de lecture : la distribution par tranche porte sur les 117 sites dont la mesure d'affichage mobile est complète, tandis que le classement sectoriel porte sur les 120 sites mesurés. Trois sites ont une mesure sectorielle exploitable sans temps d'affichage mobile utilisable.

Cette étude sera reconduite chaque année, avec le même panel, afin de mesurer l'évolution réelle du web tunisien. Si vous êtes responsable technique de l'un des sites analysés et souhaitez connaître vos résultats individuels, écrivez-nous : nous vous les transmettons gratuitement et sans contrepartie.

Les graphiques de cette étude peuvent être repris librement, sous réserve de citer la source et de faire un lien vers cette page.

9. Pourquoi un hébergeur publie cette étude

La question est légitime, et il vaut mieux y répondre que la laisser flotter.

Nous sommes hébergeur, et le premier enseignement de cette étude dit que l'hébergement n'est pas le problème : 89 millisecondes de temps de réponse médian, c'est un web tunisien correctement servi. Si nous avions cherché à vendre, nous aurions publié l'inverse.

Ce que nous y gagnons est plus simple : après dix-sept ans dans ce métier, nous pensons qu'un hébergeur doit aussi documenter l'état du web qu'il héberge. Et parce qu'un chiffre public, reproductible et daté vaut mieux qu'une conversation où chacun affirme ce qu'il croit.

Les deux autres volets de ce travail sont publiés en même temps : les tendances du web tunisien en 2026, croisées avec les relevés de notre parc, et trente ans d'hébergement web en Tunisie.