Aller au contenu
Produit 04, en production

UptimeEZ. Un site peut répondre et être cassé.

Votre site renvoie 200 OK en 180 ms. Sa feuille de style a disparu au dernier déploiement, sa base de données ne répond plus derrière une jolie page d'erreur, et un noindex traîne depuis la mise en ligne. Tous les outils de surveillance du marché vous diront que tout va bien. UptimeEZ regarde ce que voit un visiteur, et vous rend une liste de choses à faire.

uptimeez.example / aujourd'hui
Capture réelle de l'interface, en français, à la vitesse d'usage. Rien n'est reconstitué pour cette page.
Le principe

Pas un tableau de bord. Une liste de choses à faire.

Les outils de supervision affichent des états. Vert, orange, rouge, et à vous de deviner ce que ça veut dire, sur quel site, et si c'est grave.

L'écran d'accueil d'UptimeEZ est trié par urgence et chaque carte dit quatre choses : la cause, pourquoi ça compte, ce qu'il y a à faire, et la preuve mesurée. Les boutons qui appliquent la réparation sont sur la carte, et cinq des six réparations s'annulent pendant dix minutes.

Pourquoi on l'a écrit

47 alertes un matin. 43 étaient fausses.

Le compte est celui d'une matinée, vérifié alerte par alerte, à la main.

On surveillait les sites de nos clients avec les outils du marché, puis avec notre propre moteur. Un matin, 47 alertes dans la boîte. On les a ouvertes une par une : 43 ne correspondaient à rien du tout.

La cause était chez nous, et elle était bête. Nos sondes interrogeaient les mêmes serveurs trop vite, les fichiers répondaient « trop de requêtes », et le moteur lisait cette réponse comme un fichier disparu. Il annonçait donc des mises en page cassées sur des sites parfaitement intacts.

Un outil qui crie au loup finit dans une règle de filtrage de la boîte mail. Et un outil filtré ne surveille plus rien : c'est pire que pas d'outil, parce qu'on croit être couvert.

On a repris le moteur de décision à zéro. Un problème d'apparence ne peut plus être annoncé comme une panne. Les pannes qui partagent une adresse IP deviennent une seule alerte. Rien ne part avant confirmation. Et chaque règle de décision a désormais sa propre suite de tests.

Le récit complet, avec le détail de ce qui était faux et des quatre corrections : 47 alertes un matin, 43 étaient fausses.

Le jour où j'ai vérifié 47 alertes à la main et que 43 étaient fausses, j'ai compris que le problème n'était pas la surveillance. C'était l'instrument.
Laurent Tulpan Cœur du Web
Ce qu'il regarde

Cinq couches sur chaque page, et sept types de sonde.

Les outils classiques regardent une seule chose : est-ce que le serveur répond. UptimeEZ en regarde cinq, et aucune n'est à configurer.

  • 01

    Est-ce que ça répond ?

    Code de réponse, DNS, connexion, poignée de main du certificat, premier octet, chaîne de redirections. Plusieurs vérifications avant d'alerter, pour ne pas confondre un à-coup de deux secondes et une panne.

  • 02

    Est-ce que la page est juste ?

    Chaque feuille de style, chaque script, chaque police : disponibilité, type réel, poids comparé à la normale apprise sur ce site, classes effectivement couvertes par le CSS. C'est la couche qui attrape une page qui répond parfaitement et s'affiche nue.

  • 03

    Est-ce que les données répondent ?

    41 signatures d'erreur de base de données, une sonde applicative qui traverse vraiment la base, et une phrase tirée du contenu du site qui prouve qu'elle a répondu. WordPress sait servir une page d'erreur avec un code 200 impeccable.

  • 04

    Est-ce rapide pour un visiteur ?

    Temps de réponse du serveur, fichiers qui bloquent le premier affichage avec leur poids exact, image du haut de page, scripts tiers. Les trois mesures officielles de Google en prime, quand une clé Chrome UX Report est fournie.

  • 05

    Est-ce que ça va casser bientôt ?

    Expiration du certificat et du nom de domaine, failles publiées sur les versions lues dans le HTML, et un signal de vie pour les tâches qui doivent tourner la nuit. Une sauvegarde qui s'arrête ne fait aucun bruit.

  • 06

    Et sept types de sonde

    Une page, une API JSON avec la valeur attendue au bon endroit, un fichier qui doit rester joignable et inchangé, un mot qui doit apparaître ou ne jamais apparaître, un signal de vie, un port, un enregistrement DNS. Chacun avec ses propres réglages, aucun à deviner.

La mise en page cassée

La page telle qu'un visiteur la voit. Pas une note sur cent.

À gauche, la page de référence apprise quand tout allait bien. À droite, la même page maintenant. La différence est mesurée, et elle se voit sans explication.

uptimeez.example / sondes / camping-des-pins
Deux silhouettes côte à côte : la page de référence avec son conteneur centré et ses trois colonnes, et la page actuelle où tout est empilé pleine largeur, marquée 71 % de différence avec la référence
Reconstitué depuis le HTML reçu et les feuilles de style réellement chargées. Aucun navigateur n'est lancé, donc la vérification coûte une requête et pas trente secondes de machine.

Et la cause exacte, fichier par fichier.

Un constat sans cause ne sert à personne. Sous la silhouette, UptimeEZ nomme le fichier fautif, son code de réponse, son poids par rapport à la normale, et les classes de la page qui ne sont plus couvertes par aucune règle CSS.

Il reconstitue même les messages que la console du navigateur aurait affichés. C'est ce bloc que votre prestataire technique lit, et il n'a pas besoin de vous poser de questions avant de corriger.

uptimeez.example / ressources de la page
Panneau des ressources de la page : feuille de style en échec avec son code 404, poids du CSS en chute de 71 %, couverture des classes à 31 % contre 96 % en référence, et les erreurs reconstituées de la console du navigateur
uptimeez.example / logiciels et failles connues
Tableau des logiciels détectés sur un site : WordPress, thème et extensions avec leur version installée, la dernière version disponible, et les failles publiées avec leur gravité
Les échéances

Ce qui va casser, avant que ça casse.

Les versions des logiciels installés se lisent dans le HTML que le site envoie déjà. UptimeEZ les compare aux failles publiées et vous dit laquelle est critique, sur quel site, depuis quand.

Même logique pour le reste des échéances : un certificat expire toujours un samedi, un nom de domaine se renouvelle toujours trop tard, et une sauvegarde qui s'arrête ne prévient jamais. Ces trois-là sont surveillées comme le reste.

La vue d'ensemble

Le mur, pour l'écran du bureau. Et pour votre poche.

Un site en difficulté remonte tout seul en haut de la vue, jamais sous la ligne de flottaison. Le reste est calme, et c'est le but : on doit pouvoir laisser cet écran allumé toute la journée sans le regarder.

uptimeez.example / mur
Vue mur d'UptimeEZ : une carte par site avec sa couleur d'état, sa disponibilité, son temps de réponse et sa courbe des 24 dernières heures, les sites en difficulté placés en haut
UptimeEZ sur un téléphone : le même écran d'accueil, la liste des sites à traiter d'abord, lisible sans zoomer

La même interface au doigt, sans application à installer.

Ce que vous recevez, vous

Un document pour votre direction. Pas une capture d'écran d'outil.

Le rapport de disponibilité s'imprime ou s'enregistre en PDF, sur la période que vous voulez. Il dit la disponibilité réelle, l'indisponibilité cumulée en heures et minutes, le temps de chargement moyen, et chaque interruption avec sa cause en français.

uptimeez.example / rapport client
Rapport de disponibilité imprimable : disponibilité sur la période, indisponibilité cumulée, temps de chargement moyen, bande verte jour par jour, courbe des temps de réponse et tableau des interruptions avec leur cause
Rapport de disponibilité sur 30 jours, prêt à envoyer.
uptimeez.example / espace client
Espace client d'UptimeEZ : la liste de vos sites avec leur état, leur courbe et leur disponibilité sur 30 jours, et les interruptions récentes
Espace en lecture seule, une adresse à vous, sans compte à créer.

Vous n'avez pas à nous demander si votre site tient. Vous avez une adresse à vous, en lecture seule, qui montre vos sites et leur historique. Rien d'autre, pas de compte, pas de mot de passe à retenir.

Et une interruption n'y est comptée que si le site a raté plusieurs vérifications d'affilée. Un à-coup d'une seule mesure n'entre pas dans le décompte, parce qu'un chiffre de disponibilité gonflé par des faux positifs ne veut plus rien dire.

Contrôles automatisés
1 720

quatre suites rejouées avant chaque livraison, zéro échec

Langues de l'interface
10

dont l'arabe et l'ourdou, écrits de droite à gauche

Canaux d'alerte
7

courriel, SMS, Slack, Teams, Discord, Telegram, webhook

Dépendance à installer
0

ni Composer, ni Node, ni Docker obligatoire

Les 1 720 contrôles sont la somme des quatre suites de tests du moteur, rejouées le 4 août 2026 : logique de détection, parcours de bout en bout, règles de décision, sécurité. Aucun échec. C'est ce qui nous autorise à livrer une correction un vendredi.

Ce que la licence vous garantit

Le code est public. Vous n'avez rien à en faire.

Licence MIT Hébergement mutualisé suffisant SQLite ou MySQL Vos données restent chez vous

Le moteur est publié sous licence MIT. Vous n'avez pas à ouvrir GitHub, ni à installer quoi que ce soit : l'offre hébergée existe pour ça, et c'est nous qui l'exploitons.

Ce que ça change quand même pour vous, et c'est la seule raison d'en parler ici : le code qui surveille votre site est lisible par n'importe quel prestataire, y compris celui qui nous remplacerait un jour. Vous pouvez faire auditer ce qu'on mesure, reprendre l'installation, partir avec l'historique. Ce n'est pas une promesse commerciale, c'est une conséquence de la licence.

Il s'installe sur un hébergement mutualisé ordinaire, sans Docker et sans dépendance à télécharger. On l'a vérifié en posant l'installation complète sur deux hébergeurs mutualisés différents avant de l'écrire nulle part.

Le produit, ses offres et sa démonstration publique sont sur uptimeez.com. Le code est sur GitHub, si vous voulez le montrer à votre équipe technique.

Pourquoi ça compte pour votre site

Une panne, ça se remarque. Le reste, non.

  • Le jour d'une mise en ligne

    Un noindex oublié

    La page dit à Google de ne pas l'indexer. Le site fonctionne, personne ne voit rien, et le trafic baisse trois semaines plus tard. UptimeEZ le signale le jour même.

  • Un vendredi soir

    Une page de commande nue

    Le tunnel d'achat répond, mais s'affiche sans mise en page. Ça ne se voit pas dans les statistiques de disponibilité. Ça se voit dans le chiffre d'affaires du mois.

  • En comité de direction

    Une question simple

    « Notre site a tenu combien de temps ce trimestre ? » Vous avez le document, avec la durée des interruptions et leur cause, sans avoir à le demander à qui que ce soit.

C'est l'outil qu'on utilise pour surveiller les sites qu'on maintient. On l'a écrit parce qu'on avait le problème, on le corrige parce qu'on le subit en premier, et il tourne sur nos propres serveurs avant les vôtres.

Quand on vous a livré un outil et que la mission est terminée, c'est lui qui tient la partie surveillance de notre filet de sécurité.

Pour creuser sans passer par nous : votre site répond, et il est cassé quand même explique pourquoi un code 200 ne prouve rien, sept pannes qu'un test de disponibilité ne voit pas en donne la liste avec la façon de les détecter, et le point 4 de notre grille de diagnostic technique pose la question à l'échelle d'un système entier.

Le bénéfice pour votre projet dépasse la supervision : quand vous nous confiez un développement sur-mesure ou un SaaS co-construit, vous avez en face de vous une équipe qui opère ses propres produits, avec des tests qui tournent avant chaque livraison.

Faire surveiller votre site

Vous voulez savoir ce qu'il attraperait sur votre site ?

On le branche sur vos pages importantes et on regarde ensemble ce qui sort. Vingt minutes suffisent pour voir si votre site cache quelque chose.