Pronostip - Leader des Pronostics Gratuits : Architecture et Développement

Pronostip : 2 ans de collaboration sur un site à fort trafic

Pronostip est l'un des leaders français des pronostics sportifs gratuits, avec plus de 120 000 visiteurs uniques par jour les jours de grands matchs. Cette audience massive impose des contraintes techniques extrêmes : haute disponibilité absolue (les utilisateurs vérifient leurs pronostics au moment même des matchs, en temps réel), performance à charge maximale (pics à 50 000 requêtes/minute), et latence minimale sur les données sportives en direct.

INNOSYS a accompagné Pronostip pendant 2 ans sur deux missions complémentaires : la refonte de l'architecture réseau et serveur pour atteindre 99,97 % de disponibilité, et le développement de fonctionnalités Drupal avancées dont le module de flux en temps réel.

Architecture production Pronostip — 120 000 visites/jour, 99.97% uptime

Problématiques initiales

Indisponibilités lors des pics de trafic

Lors des Coupes d'Europe ou des grandes compétitions, le site subissait des coupures de 5 à 30 minutes précisément aux moments où le trafic explosait. L'architecture initiale mono-serveur ne supportait pas les pics. Les utilisateurs découvraient le site indisponible exactement quand ils en avaient le plus besoin — une catastrophe pour la fidélisation et la réputation.

Données sportives en retard

Les résultats et statistiques des matchs n'étaient actualisés que toutes les 5 minutes par un cron job. Sur une plateforme de pronostics, 5 minutes de retard est inacceptable : les utilisateurs s'attendaient à une mise à jour quasi-instantanée.

Architecture haute disponibilité déployée

CDN Cloudflare — première ligne de défense

L'intégration de Cloudflare en front a résolu 60 % du problème de performance : le cache CDN sert les pages HTML statiques (pronostics de la veille, analyses historiques) directement depuis les 300 points de présence mondiaux de Cloudflare, sans toucher les serveurs d'origine. Le WAF Cloudflare filtre également le trafic malveillant (bots de scraping, attaques DDoS).

Load Balancer + 2 nœuds Drupal

Deux serveurs d'application Drupal identiques derrière un load balancer HAProxy répartissent la charge. La session utilisateur est stockée dans Redis (session partagée), permettant à n'importe quel nœud de servir n'importe quelle requête. En cas de panne d'un nœud, le load balancer bascule immédiatement sur l'autre, de façon transparente pour l'utilisateur.

MySQL avec réplication Primary-Replica

La base de données MySQL est configurée en réplication primary-replica asynchrone. Les lectures (90 % des requêtes) sont routées vers le replica, le primary recevant uniquement les écritures. En cas de panne du primary, le basculement vers le replica est possible en moins de 5 minutes. Cette architecture divise par 5 la charge sur le serveur de base de données.

Redis pour le cache et les sessions

Redis sert à deux usages critiques : cache des requêtes SQL fréquentes (classements, statistiques d'équipes — invalidation automatique à chaque mise à jour) et stockage des sessions utilisateur partagées entre les deux nœuds d'application.

Développement Drupal : le module de flux temps réel

Le module personnalisé développé par INNOSYS utilise les WebSockets (via un serveur Node.js) pour pousser les mises à jour de scores en temps réel vers les navigateurs des utilisateurs. Dès qu'un score est mis à jour dans la base de données (via une API de données sportives), le serveur Node.js notifie tous les clients connectés en moins de 200ms. Les utilisateurs voient les scores se mettre à jour en direct, sans rafraîchir la page.

Résultats

Disponibilité mesurée (Zabbix, 24 mois) : 99,97 % — soit moins de 3 heures d'indisponibilité totale sur 2 ans. Latence de mise à jour des scores : de 5 minutes à moins de 200ms. Performance (temps de réponse moyen) : 180ms en charge normale, 380ms lors des pics à 50 000 req/min. Aucune indisponibilité lors des Coupes d'Europe 2022 et 2023.