Le 18 novembre 2025, une panne majeure de Cloudflare a perturbé une grande partie d’internet. Des millions d’utilisateurs à travers le monde se sont soudainement retrouvés face à leurs sites préférés devenus inaccessibles, leurs tableaux de bord introuvables, et leurs services en ligne qui renvoyaient des messages d’erreur. Pendant quelques heures, internet semblait complètement cassé.

Cloudflare étant l’un des partenaires clés de WebWork en matière de sécurité et d’infrastructure réseau, de nombreux utilisateurs ont posé la question : WebWork est-il tombé ? Nos données de suivi ont-elles été perdues ? Le tracking a-t-il été interrompu ?
Voici une explication claire et factuelle de ce qui s’est passé — et pourquoi WebWork a continué à enregistrer le temps sans interruption.

Qu’est-ce que Cloudflare et pourquoi est-il si important ?

Cloudflare est l’un des plus grands fournisseurs d’infrastructure internet au monde. La plupart des utilisateurs ne le voient jamais, mais il fait fonctionner en coulisses une part significative du web mondial.

Cloudflare fournit :

• Un CDN (Content Delivery Network) pour accélérer le chargement des sites
• Des services DNS qui acheminent le trafic
• Des services de sécurité, dont la protection contre les attaques DDoS et un WAF
• La gestion des bots et le filtrage du trafic
• Le routage intelligent, pour maintenir la stabilité des sites sous forte charge

Il est utilisé par des millions de sites web, des petits blogs aux grandes entreprises du Fortune 500. Selon les estimations du secteur, Cloudflare gère environ 20 % de l’ensemble du trafic internet mondial. Autrement dit, une page sur cinq passe par le réseau Cloudflare.

Compte tenu de son rôle central, lorsque Cloudflare tombe en panne, les répercussions se font sentir sur l’ensemble d’internet — y compris sur des sites que les utilisateurs pensent totalement indépendants.

Ce qui s’est réellement passé : la chronologie

La panne a débuté sans prévenir aux alentours de 11h17 UTC. Presque immédiatement, les plateformes de monitoring et les tableaux de bord publics ont commencé à signaler des pics d’erreurs : des statuts 500, 502 et 503 sont apparus sur des milliers de sites.

Les points clés de la chronologie

• 11h17 UTC : les services Cloudflare commencent à tomber à l’échelle mondiale
• 11h30–13h30 UTC : les sites et APIs du monde entier deviennent lents ou inaccessibles
• 14h00–16h00 UTC : les équipes réseau de Cloudflare déploient des correctifs et effectuent des rollbacks de configuration
• 16h55 UTC : les services mondiaux reprennent progressivement
• Après 17h00 UTC : la grande majorité des sites touchés se rétablissent complètement

Durant cette fenêtre, de nombreux grands services — réseaux sociaux, outils SaaS, sites gouvernementaux, portails bancaires, applications de communication — ont signalé des performances dégradées ou une indisponibilité totale.

Il s’agit de l’une des pannes Cloudflare les plus impactantes de ces dernières années, tant par son ampleur que par sa soudaineté.

Pourquoi c’est arrivé

Cloudflare a confirmé par la suite la cause racine de l’incident :
Un bug dans la manière dont Cloudflare générait un fichier de configuration de gestion des bots.

Ce fichier — utilisé pour distinguer le trafic légitime du trafic malveillant — est devenu trop volumineux ou corrompu à cause du bug. Les services internes critiques qui en dépendent n’ont pas pu le traiter, entraînant des défaillances au niveau de la couche réseau.

Pour comprendre simplement ce qui s’est passé :

Imaginez votre téléphone en train de télécharger une mise à jour système corrompue.
Au moment où la mise à jour se charge, votre appareil plante.
C’est exactement ce qui est arrivé à Cloudflare — mais sur des milliers de serveurs à travers le monde.

Cloudflare a d’abord envisagé la piste d’une cyberattaque, avant de confirmer qu’il ne s’agissait pas d’une attaque, mais bien d’une erreur interne.

Une fois que les ingénieurs ont annulé la configuration défectueuse et régénéré correctement le fichier, le réseau a progressivement retrouvé son état normal.

Comment la panne a impacté internet

L’effet a été spectaculaire parce que Cloudflare se positionne entre les sites web et leurs utilisateurs. Lorsque Cloudflare cesse de gérer le trafic, les sites deviennent inaccessibles même si leurs propres serveurs fonctionnent parfaitement.

Ce que les utilisateurs ont vécu :

• Des sites qui ne se chargent plus du tout
• Des tableaux de bord et panneaux d’administration inaccessibles
• Des applications incapables de se synchroniser
• Des systèmes de connexion en échec
• Des systèmes de paiement qui expirent
• Des APIs inaccessibles
• En résumé : la sensation que « tout internet est en panne »

En réalité, internet n’était pas en panne — c’est la couche de routage de Cloudflare qui défaillait.
Mais comme Cloudflare est si largement utilisé, cela a créé un effet domino qui a touché quasiment tous les secteurs.

Cloudflare est partenaire de WebWork — qu’est-il arrivé à WebWork ?

WebWork utilise Cloudflare comme partenaire de sécurité et de performance. Concrètement, Cloudflare prend en charge :

• Le trafic de WebWork
• Le routage réseau
• La protection par pare-feu
• L’accélération CDN

Ainsi, pendant la panne Cloudflare, le site WebWork est devenu temporairement inaccessible pour certains utilisateurs.

Ce qui a été impacté

• L’accès au tableau de bord WebWork
• La consultation des rapports, tâches et présences
• La connexion aux panneaux web
• L’accès aux pages d’administration et de paramètres

Ce qui n’a pas été impacté

• Le suivi du temps
• L’enregistrement de l’activité
• Les captures d’écran
• Le suivi de l’utilisation des applications
• Le stockage des données
• La synchronisation du tracker bureau

De nombreux utilisateurs n’ont pas pu accéder au tableau de bord pendant une courte période, mais le moteur principal de WebWork est resté pleinement opérationnel.

Pourquoi le suivi du temps WebWork a continué à fonctionner (avantage architectural)

Malgré la panne mondiale de Cloudflare, WebWork n’a pas interrompu le suivi du temps.
C’est parce que l’architecture de WebWork est intentionnellement conçue pour la résilience.

Voici pourquoi le tracking n’a jamais cessé :

✔ Le tracker bureau utilise des routes réseau de secours

Le client de tracking de WebWork communique avec les serveurs backend via plusieurs chemins réseau, pas uniquement les routes gérées par Cloudflare.
Si la route A tombe, le tracker bascule automatiquement sur la route B.

✔ Le suivi et le reporting sont complètement découplés

Même si le tableau de bord est indisponible, le tracker n’en dépend pas.
L’interface peut tomber — le moteur de tracking continue d’enregistrer localement et de synchroniser.

✔ WebWork intègre une mise en mémoire tampon et un replay natifs

En cas de problème réseau temporaire, le tracker stocke les données en toute sécurité et les synchronise dès que la connexion est rétablie.

✔ Le suivi du temps est traité comme une fonction critique

L’infrastructure de WebWork repose sur un principe fondamental : les utilisateurs ne doivent jamais perdre de données de temps, même en cas de panne ou d’indisponibilité d’un partenaire externe.

Le résultat :

Pas une seule minute de temps suivi n’a été perdue pendant la panne Cloudflare.