Surveillance automatique de l’accessibilité des sites clients

Le site web d’un de vos clients tombe. Il ne s’en rend pas compte tout de suite. Les modèles d’IA, eux, le constatent en quelques heures : leurs crawlers ne parviennent plus à récupérer les pages, leurs réponses cessent de citer la marque, et la visibilité IA décroche silencieusement. Quand vous lancez votre prochain audit trimestriel, les scores ont chuté de vingt points et personne ne sait depuis quand.

Cette situation, on l’a vue trop souvent. AI Labs Audit intègre désormais une surveillance automatique de l’accessibilité des sites clients, sur deux niveaux : vérification à la saisie, et contrôle quotidien en arrière-plan. Voici comment ça marche, et pourquoi c’est un filet de sécurité indispensable pour une agence GEO/AEO.

Niveau 1 — Vérification immédiate à la saisie

Quand vous ajoutez ou modifiez l’URL d’un client (formulaire de création rapide ou édition de fiche), la plateforme effectue un test HTTP en temps réel avant l’enregistrement. Le bouton "Enregistrer" se désactive si le site renvoie un code d’erreur, un timeout ou une URL malformée.

• Détection des fautes de frappe : exempel.fr au lieu de exemple.fr est intercepté avant de polluer la base.
• Détection des sites qui n’existent plus : un client qui a refait son site avec un nouveau domaine et oublié de vous prévenir, on s’en aperçoit à la saisie.
• Auto-prefix : si vous tapez exemple.com sans https://, on l’ajoute automatiquement avant de tester.
• Endpoint REST dédié : GET /api/client/check-url?url=... renvoie le statut ok / http_error / timeout / unreachable / invalid_url en moins de 6 secondes.

Résultat : aucune fiche client ne peut plus être enregistrée avec une URL cassée. Les audits planifiés sur ce client partent toujours d’une URL accessible le jour où vous l’avez ajoutée.

Niveau 2 — Contrôle quotidien en arrière-plan

Un site web peut être OK le jour de la création, et tomber trois mois plus tard. C’est pour ça qu’on rajoute un cron quotidien qui re-teste tous les sites clients actifs chaque nuit à 04h10 (heure du serveur).

Concrètement, la tâche Celery daily_check_client_websites :

1. Sélectionne tous les clients actifs avec un site_web non vide qui n’ont pas été checkés depuis plus de 20 heures.
2. Lance des requêtes HEAD en parallèle (10 workers, timeout 6s, fallback GET sur 405) pour ne pas saturer le serveur.
3. Met à jour trois colonnes sur la fiche client : site_web_status, site_web_last_check, site_web_unreachable_since.
4. Reset unreachable_since à NULL dès qu’un site répond à nouveau (rebond).

Si plus de 50 % des sites checkés dans la batch tombent en KO, la plateforme lève une alerte CRITICAL automatique dans system_alerts. C’est généralement un problème réseau ou DNS côté serveur, pas un problème côté clients — l’agence est notifiée avant de courir après un faux problème.

Niveau 3 — Badge visuel sur la fiche client

Sur la page fiche client, si un site web est inaccessible depuis plus de 7 jours, un badge rouge "Site KO" s’affiche à côté du nom du domaine, avec un tooltip détaillant le statut exact (timeout, http_error, unreachable...) et la date depuis quand le site est tombé.

Pourquoi 7 jours et pas immédiatement ? Pour éviter les fausses alertes sur des sites qui ont une maintenance programmée de quelques heures, ou un problème réseau temporaire. Au-delà d’une semaine, on est sûr d’un problème réel qui mérite une intervention de l’agence.

Cas concret : pourquoi ça change la donne

Une agence partenaire avait 80 clients actifs, audités mensuellement. Une fois par trimestre environ, un client refaisait son site sans prévenir : nouveau CMS, nouveau domaine, redirection oubliée. Avant cette fonctionnalité, l’agence le découvrait au moment du rapport — soit jusqu’à 30 jours après. Pendant tout ce temps, les crédits étaient consommés pour auditer un site qui renvoyait du 404.

Avec la surveillance intégrée, le cas est détecté dans les 24 heures. L’account manager appelle le client le lendemain, ajuste la fiche, et l’audit suivant part sur la bonne URL. Aucun crédit gaspillé, aucun rapport bidon livré, aucune mauvaise surprise.

Disponibilité et activation

La fonctionnalité est active par défaut sur tous les plans qui gèrent des clients (Consultant, Consultant+, Agent, Agence+). Aucune action de votre part : la vérification à la saisie est automatique, le cron tourne en arrière-plan, le badge apparaît dès qu’un client est concerné. Les checks consomment zéro crédit — c’est de l’infrastructure, pas un service IA payé.

L’historique du statut est consultable via les colonnes ajoutées à la table clients et exposé dans l’API REST (GET /api/clients/{id} renvoie les trois champs site_web_status, site_web_last_check, site_web_unreachable_since).

Conclusion

Surveiller l’accessibilité d’un site client n’est pas un sujet sexy, mais c’est la base d’une mesure GEO/AEO honnête. Auditer un site qui renvoie du 500 ne donne aucune information utile sur la visibilité IA de la marque — ça remplit juste le rapport avec du bruit. AI Labs Audit préfère vous prévenir avant de lancer l’audit que de vous facturer un rapport vide.

Vous pouvez tester la vérification immédiate dès aujourd’hui : créez un client avec une URL volontairement cassée dans votre liste de clients, et observez le bouton "Enregistrer" rester désactivé jusqu’à correction.

Article relu et mis à jour : mai 2026 — vérifié face aux comportements actuels de ChatGPT, Claude, Gemini et Perplexity.