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.
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.
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.
Les outils classiques regardent une seule chose : est-ce que le serveur répond. UptimeEZ en regarde cinq, et aucune n'est à configurer.
Code de réponse, DNS (domain name system, système de noms de domaine), 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.
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.
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.
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.
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.
Une page, une API (application programming interface, interface de programmation) 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.
À 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.
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.
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.
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.
La même interface au doigt, sans application à installer.
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.
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.
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.
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.
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.
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.
« 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, vous avez en face de vous une équipe qui opère ses propres produits, avec des tests qui tournent avant chaque livraison.
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.
L'optimisation Google Discover, pensée comme une discipline éditoriale.
Collectivités et institutionsLe signalement géolocalisé sur le terrain. Né chez Expertise France, essaimé à Liège, Welfarm, un industriel.
Conformité et accessibilitéL'audit conformité, sécurité, accessibilité automatisé. Avec corrections proposées par IA.
