SOURCES ET MÉTHODOLOGIE

Ce que signifie l’état.

Rapports, observations et données manquantes restent distincts.

Rapports officiels

Le répertoire comprend 56 services d’IA répartis entre assistants et recherche, programmation, médias créatifs, API de modèles, inférence et cloud GPU, et bases vectorielles. 37 ont des sources automatiques configurées, aux côtés de 11 services généraux. Il s’agit d’une sélection éditoriale, pas d’un classement de popularité mesurée ou d’un inventaire complet du secteur. Nous enregistrons les rapports fournisseur sans confirmer indépendamment la disponibilité des services d’IA.

Les résumés de Claude et GitHub comprennent composants, incidents et maintenance. D’autres points de terminaison compatibles peuvent omettre les listes d’événements ; cette omission est indiquée explicitement. Le point collecté d’OpenAI fournit actuellement des états de composants sans listes d’incidents ou de maintenance. Les résumés ChatGPT et API sont dérivés séparément d’identifiants de composants fixes et vérifiés ; les identifiants nouveaux ou manquants nécessitent un examen. Leur disponibilité ne constitue pas une affirmation sur un modèle, niveau ou compte particulier.

Copilot, v0, Replicate, Workers AI et AI Gateways sont lus à partir de leurs composants précis sur des pages fournisseur partagées. L’indicateur global de la page principale et les incidents sans rapport ne sont pas attribués à ces produits. L’absence d’un composant sélectionné empêche l’enregistrement d’un nouveau rapport.

Hugging Face, Together AI, Modal, Runpod et Qdrant utilisent le format JSON public Better Stack. Les ressources référencées et mises à jour du rapport doivent être présentes. Les rapports résolus sont exclus même sans heure de fin. Les heures de mise à jour des ressources ne sont pas inventées à partir de l’horodatage de page. Les états publiés des services et modèles DeepInfra sont des observations du fournisseur ; les réponses qu’il marque comme périmées sont rejetées. Cet adaptateur n’importe pas les détails d’incidents ou de maintenance.

Vercel et Cloudflare proposent des vues de rapports de plateforme et des vues distinctes propres aux produits. La vue de Supabase utilise l’indicateur publié de la plateforme et les composants actuellement listés ; ils peuvent ne couvrir qu’une partie de la plateforme et ne vérifient pas chaque région ou projet. Notion et Resend utilisent leurs domaines actuels vérifiés ; les résumés collectés omettent les listes d’incidents et de maintenance. L’API actuelle version 2 de Slack fournit état et incidents, avec noms de fonctionnalités affectées dans les mises à jour ; elle ne fournit pas de matrice complète de composants. Les enregistrements planifiés restent séparés sans inventer de fenêtres de maintenance.

Stripe utilise son nouveau domaine d’état vérifié pour les rapports de composants, incidents et maintenance. La page officielle Auth0 fournit du JSON intégré pour les résumés de dix régions publiques de production ; les scripts ne sont pas exécutés, et cloud privé, santé des tenants, détails d’incidents et maintenance ne sont pas importés. Les régions absentes ou une identité de page modifiée entraînent le rejet d’un nouveau rapport. AWS Health fournit des événements publics dans le format UTF-16 big-endian actuellement vérifié. Services, régions, mises à jour et codes numériques du fournisseur sont conservés, sans interpréter ces codes comme gravité ou résolution. L’agrégat reste neutre et ne prouve pas la santé des comptes ou la disponibilité globale d’AWS.

Le flux public d’incidents Google Cloud est vérifié avec son propre catalogue de produits. Les incidents terminés ou futurs ne deviennent pas actuels. Sans incident public actif, le résumé reste neutre ; il ne décrit pas Personalized Service Health et ne permet pas d’établir indépendamment la disponibilité d’un projet. Les noms de produits et d’emplacements du fournisseur sont conservés dans les mises à jour.

La source Gemini est le flux d’incidents Gemini de Google Workspace, vérifié avec son catalogue officiel. Les incidents terminés, futurs ou sans rapport ne deviennent pas des incidents Gemini actuels. Sans incident actif, l’étiquette est « Aucun incident signalé », pas une affirmation que Gemini est opérationnel. La dernière mise à jour d’incident Gemini diffère de l’heure de collecte ; un flux sans incident Gemini n’a pas d’heure publiée de mise à jour Gemini.

Grok / xAI lit quatorze composants vérifiés dans le JSON public utilisé par sa page officielle d’état et vérifie leurs identifiants, noms et l’ensemble sélectionné complet sans exécuter de scripts. Les graphiques en direct et détails d’incidents ne sont pas importés. DeepSeek importe le résumé structuré des changements actifs de sa page publique ; sans changement signalé, la disponibilité globale reste inconnue. Aucune page ne fournit d’heure de publication vérifiée pour ces champs collectés. fal utilise son résumé version 3 et sept composants vérifiés ; les deux réponses doivent être validées, et les détails d’avis ou heures de publication absents restent absents. CoreWeave utilise l’API publique Status.io avec codes d’état, composants et emplacements du fournisseur vérifiés ; les maintenances actuelle et future sont distinctes.

Midjourney utilise le flux JSON de production lié par sa page officielle d’état. Ses résumés de service sont distincts des estimations d’attente Fast et Relax. Les couleurs d’attente ne sont ni des pannes de service ni des mesures indépendantes de latence. L’horodatage du flux fournisseur est conservé, et les rapports de plus de quinze minutes ou de plus de trente secondes dans le futur sont rejetés.

Google Cloud AI filtre le flux public d’incidents cloud sur 23 identifiants de produits Vertex vérifiés. Les autres incidents Google Cloud sont exclus ; les produits sélectionnés manquants entraînent le rejet d’un nouveau rapport. Cette vue est distincte de l’application Gemini et de Gemini API / AI Studio. Codex collecte uniquement le composant Codex in ChatGPT Desktop du rapport OpenAI, qui ne permet pas d’établir la disponibilité de la CLI, de l’extension IDE ou des tâches cloud.

Gemini API, Google AI Studio et Google Cloud AI sont distincts de ce flux de l’application Gemini. Gemini API / AI Studio possède sa propre page officielle d’état ; la collecte automatique de cette page n’est pas implémentée. « Page officielle uniquement » désigne une page d’état liée sans collecte automatique. « Non connecté » signifie qu’aucune donnée d’état n’est disponible ; tout site produit lié est désigné comme site web.

Collecte et fraîcheur

Le processus de collecte vérifie chaque source configurée toutes les 120 secondes, avec jusqu’à 15 secondes de variation aléatoire. Les pages lisent les données enregistrées et s’actualisent toutes les 30 secondes lorsqu’elles sont visibles. L’actualisation manuelle lit aussi les données enregistrées.

Une collecte valide devient périmée après 6 minutes. Son dernier rapport connu reste visible avec un avertissement. L’heure de collecte correspond à la réception et à la validation des données. L’heure de mise à jour de la source est fournie par le fournisseur ou explicitement désignée comme la dernière mise à jour d’un incident ; un horodatage de source inchangé ne signifie pas à lui seul que la collecte est périmée.

Chaque collecte a un délai de 10 secondes et chaque réponse est limitée à 512 KiB. Gemini et Google Cloud exigent chacun la validation de leur propre catalogue fixe de produits et de leur flux d’incidents avant l’enregistrement d’un rapport. Les échecs de collecte entraînent un recul allant jusqu’à une heure, en tenant compte d’un Retry-After interprétable. Un échec est enregistré séparément et ne transforme jamais le rapport du fournisseur en panne.

Les valeurs d’état inconnues restent inconnues. Les champs d’incidents ou maintenance absents sont marqués comme non fournis. La maintenance future planifiée est affichée séparément et ne compte pas comme panne actuelle. L’absence d’un incident dans le flux ne prouve pas son historique complet et ne confirme pas indépendamment la reprise.

Historique quotidien et couverture

Le répertoire montre les sept dernières dates UTC ; les détails proposent trente ou sept jours. Chaque point représente l’état enregistré le plus grave du jour, distinct de l’état actuel. Le vert indique un rapport normal ou une vérification réussie ; le jaune, une dégradation ou une vérification en cours de répétition ; le rouge, une panne signalée ou un échec confirmé ; le bleu, une maintenance en cours. Le gris couvre les observations manquantes ou non concluantes ; l’explication indique la raison.

Un point à moitié rempli indique une couverture incomplète ou une journée inachevée. L’anneau en pointillés d’aujourd’hui signifie que la journée est en cours. La couverture des états connus compte les enregistrements interprétables sur la journée complète ou le temps écoulé aujourd’hui. Il s’agit de la couverture des enregistrements, pas d’une disponibilité mesurée.

Les états enregistrés sont bornés par l’observation suivante et leurs limites de fraîcheur existantes : six minutes pour les rapports officiels et quinze pour les vérifications. L’historique des sondes réutilise les règles d’échecs consécutifs et de reprise. Les échecs de collecte sont comptés séparément et ne deviennent jamais des états de panne. Les durées décrivent des états enregistrés de rapports ou de vérifications, pas des durées exactes d’incidents. Les dates antérieures à notre première observation restent grises ; nous n’importons pas et ne revendiquons pas l’historique complet d’incidents du fournisseur.

Observations régionales

Les agents de sondes indépendantes vérifient la page d’accueil publique GitHub et lisent les métadonnées d’un dépôt public via GitHub API. Ils utilisent HTTPS IPv4, valident le certificat et le contenu attendu, et enregistrent les durées de résolution, connexion, TLS, en-têtes et totale. Une vérification réussie de la page d’accueil ne prouve pas le fonctionnement de la connexion, des opérations Git ou d’Actions. Une lecture publique d’API ne prouve pas celui des opérations authentifiées.

Le résolveur sélectionné est indiqué avec chaque nœud. Les agents peuvent utiliser le résolveur système ou Cloudflare DNS sur HTTPS. Ce dernier ne teste pas le résolveur système et peut sélectionner d’autres adresses de destination. Les adresses privées ou spéciales sont rejetées ; les cibles sont fixes, les adresses publiques validées sont fixées pour la requête et les redirections ne sont pas suivies.

Chaque agent vérifie deux contrôles fixes de connectivité, exploités par Cloudflare et Mozilla. Au moins un doit réussir pour que les échecs des cibles comptent pour la confirmation. Si aucun ne réussit, les résultats indiquent « Connectivité de la sonde incertaine ». Ce test de connectivité limité ne prouve pas le bon fonctionnement du nœud ou de tous les chemins réseau.

Les vérifications s’exécutent toutes les 5 minutes, avec jusqu’à 15 secondes de variation aléatoire. Le premier échec indique « Nouvelle vérification de l’échec » ; deux échecs consécutifs confirment une vérification défaillante sur ce nœud. La reprise après un échec confirmé encore récent exige deux réussites ; après une lacune périmée, une vérification réussie établit une nouvelle référence. La confirmation exige des observations et réceptions espacées d’au moins 4 minutes, sans intervalle de 15 minutes ou plus. Les refus d’accès, limites de requêtes, redirections et adresses cibles rejetées sont non concluants et ne confirment pas une défaillance du service.

Les observations et signaux de présence deviennent périmés après 15 minutes. Les vérifications périmées ne conservent pas de badge actuel de réussite ou d’échec. L’heure d’observation est celle de la fin du cycle de l’agent ; l’heure de réception est celle de son acceptation par le serveur. Rapports absents, échecs de collecte et défaillances de service restent distincts.

Les vérifications de cibles de service s’exécutent sur des nœuds indépendants. Le centre collecte les rapports officiels et reçoit les résultats ; il ne sonde pas les cibles de service. Les emplacements non vérifiés n’apparaissent pas dans l’historique régional. Ashburn, Frankfurt et Tokyo nécessitent de vrais nœuds distants ; leur simple enregistrement ne prouve pas une couverture. L’emplacement et le réseau du nœud sont configurés par l’opérateur, sans vérification automatique. Nous ne déduisons pas l’accessibilité régionale d’un rapport officiel global, ne transformons pas les votes de nœuds en état global et ne déduisons pas la cause d’une panne.

Voir la couverture réelle

Dépendances et causalité

Aucun enregistrement vérifié de dépendances en amont n’est encore publié. Un incident fournisseur ne permet pas à lui seul d’établir l’application affectée ou la cause du problème d’un utilisateur.

Accès gratuit et mesure minimale

Les requêtes d’état sont gratuites et ne nécessitent pas de compte. Des notifications par e-mail sont prévues ; cette version n’envoie pas d’e-mails et ne collecte pas d’adresses.

Nous enregistrons visites de pages de services, clics sur les sources officielles et avis facultatifs avec un identifiant aléatoire dans le sessionStorage de cet onglet. Nous n’y stockons ni adresses IP, ni e-mails, ni User-Agent complet. Les actualisations automatiques ne comptent pas comme nouvelles visites. Les bots connus sont filtrés dans la mesure du possible.

Les événements de développement sont marqués comme internes. Les données sont stockées dans la base configurée par l’opérateur. Le nettoyage automatique lié à la conservation n’est pas encore implémenté ; un déploiement public exige une politique de conservation et son application.