TL;DR
- Le crawl s'adapte désormais à chaque site : la concurrence, les délais entre requêtes, les nouvelles tentatives et les délais d'attente s'ajustent automatiquement pour ne pas submerger les serveurs lents ou limités.
- Les exécutions de visibilité sont plus fiables : elles couvrent chaque prompt et chaque moteur actifs, répartissent les sujets de façon équilibrée et utilisent des points de contrôle et des verrous de tâche pour éviter tout travail ou toute facturation en double.
- La consommation est plus facile à gérer : les réglages de visibilité estiment l'usage mensuel d'unités gérées, le solde restant, les exécutions planifiées disponibles et le moment où les exécutions en pause reprendront.
- Moins de bruit dans les alertes et l'indexation : les alertes moteur exigent des échecs généralisés, le badge de la boîte de réception se met à jour immédiatement et l'indexation en arrière-plan limite l'usage du processeur tout en affichant sa progression.
- La prise en charge de l'IA hébergée a été rafraîchie : les forfaits payants et les clés personnelles prennent en charge les derniers modèles gérés, et Send Moose sélectionne et identifie de lui-même un modèle hébergé disponible.
Le crawler sent l'ambiance
Chaque site a un rythme qui lui convient. Certains sont derrière un réseau de diffusion de contenu qui met au défi tout ce qui récupère trop de pages trop vite. Notre crawler amélioré remarque sur quel type de site il se trouve et se comporte en conséquence.
Le crawler de Moose démarre avec deux requêtes en parallèle et en ajoute une toutes les douze pages propres et rapides, jusqu'à huit. Après chaque montée, il vérifie si les temps de page ont augmenté dans la même proportion. Si c'est le cas, le serveur est à sa limite de confort, alors le crawler recule d'un cran et retient ce plafond pendant un moment. Une réponse de limitation ou de défi divise les workers par deux, double l'intervalle entre les requêtes, attend quelques secondes et remet la page dans la file pour un nouvel essai. Une page lente fait pareil et allonge le délai d'attente par page pour s'aligner sur ce que le site nous montre.
Le résultat est ce qui compte le plus. Dans une rediffusion d'un site limité, le crawler a terminé toutes les pages avec deux courtes pauses. Dans une rediffusion d'un site à une page par seconde, il s'est stabilisé à trois workers et a terminé toutes les pages sans un seul délai dépassé. Votre inventaire de site revient complet, et le serveur en face remarque à peine notre passage.
Chaque prompt, chaque moteur, une seule exécution
Sur les forfaits gérés, les exécutions de visibilité planifiées se font (en option) dans le cloud. Cette semaine, l'exécuteur cloud a repris la même logique de construction d'exécution que celle du bureau : chaque prompt actif sur chaque moteur actif entre dans l'exécution, et les prompts sont entrelacés par sujet, de sorte que chaque sujet reçoit ses premières réponses tôt au lieu d'attendre derrière celui que vous avez modifié en dernier.
Pour un projet de 300 prompts sur sept moteurs, cela fait une seule exécution d'un peu plus de 2 100 paires prompt-moteur. L'exécuteur avait déjà ce qu'il faut pour une exécution de cette taille : une vérification du solde en amont, un budget de worker défini et des points de contrôle pour qu'une exécution reprenne là où elle s'est arrêtée si elle a besoin d'un second worker. Ces pièces servent enfin.
Longues exécutions, un seul worker
Une exécution de visibilité IA avec plusieurs centaines de prompts peut prendre du temps, alors le worker qui l'exécute prend désormais un verrou au démarrage et le garde jusqu'à la fin. Le délai de la file de tâches correspond au budget du worker, et toute redistribution qui trouve un verrou actif se retire.
La boîte de réception a eu droit au même traitement. Les éléments « moteur indisponible » sont désormais calculés à partir des observations de l'exécution terminée. Un élément n'apparaît que lorsqu'un moteur n'a donné aucune réponse, et il indique combien de prompts ont été touchés. Que Google choisisse de ne pas afficher d'AI Overview pour une requête est le choix de Google, pas une panne, et cela ne crée plus d'élément « moteur indisponible ».
Votre ventilateur
L'app construit un index de recherche sur vos pages, sur votre machine, pour que le chat et le graphe d'entités puissent retrouver les choses. Cet indexeur utilise désormais brièvement au plus un tiers des cœurs de votre processeur, plafonné à quatre, pour qu'une tâche d'arrière-plan reste en arrière-plan.
Modèles
Hi, Moose a gagné Gemini 3.8 Flash, Claude Fable 5.1 et Muse Spark 1.3, tous disponibles sur les forfaits gérés payants ou avec votre propre clé, et a retiré Gemini 3.5 Flash ainsi que les deux préversions de Gemini 3.1.
Petites choses
La page des réglages de visibilité indique désormais combien d'unités de solde géré cloud votre cadence demande par mois et combien il en reste (les modèles d'IA locale n'ont pas de solde, évidemment). Si le solde cloud ne couvre pas tout le mois, la bannière dit à peu près combien d'exécutions planifiées il reste et quand elles reprennent, sans surprise. Le badge de la boîte de réception se met à jour dès qu'une exécution cloud crée un élément. Et Send Moose choisit de lui-même un modèle hébergé quand l'IA locale est désactivée sur un forfait payant, et indique lequel à l'écran.
Moose le chien, dont je porte le nom, a supervisé tout ça depuis sous le bureau. Les yeux fermés, mais présent.
FAQ
Que fait le crawler quand mon site limite ses requêtes ?
Il lève le pied : il divise par deux le nombre de requêtes en parallèle, double l'intervalle entre elles, attend quelques secondes et remet la page dans la file pour un nouvel essai. L'attente s'allonge si le site continue de refuser, et le pied de page de l'app indique que le crawler ajuste son rythme pendant ce temps.
Les exécutions de visibilité planifiées dans le cloud couvrent-elles tous mes prompts ?
Oui. Chaque prompt actif sur chaque moteur actif entre dans une seule exécution, entrelacé par sujet, et une exécution qui a besoin de plus d'un worker reprend depuis son point de contrôle. Les exécutions sur le bureau avec votre propre clé OpenRouter fonctionnent de la même façon.
Quand un élément « moteur indisponible » apparaît-il dans la boîte de réception ?
Seulement quand un moteur n'a donné aucune réponse sur une exécution, ou quand la moitié ou plus de ses prompts sont revenus vides. L'élément indique combien de prompts ont été touchés. Le fait que Google n'affiche pas d'AI Overview pour une requête ne compte pas.
Celui qui est sous le bureau pendant tout ça.