Notre méthode
Chaque réponse de Flyder vient d'exécutions que nous avons faites nous-mêmes. Cette page explique comment fonctionne une exécution, ce que nous publions et comment contester un résultat.
Découverte et disponibilité
Notre robot trouve des apps sur les déploiements de constructeurs, GitHub, les sites de lancement et les soumissions d'auteurs. Une app est considérée en ligne si elle répond, n'est pas une page d'attente du constructeur et affiche un vrai contenu. Deux vérifications ratées de suite la retirent de toutes les réponses.
Scénarios par type de tâche
Chaque question a un type de tâche (widget de site, bot de messagerie, générateur, intégration). Le scénario vient du type de tâche, jamais de l'app ni de son auteur, et les données de test sont générées à chaque exécution.
L'exécution
Un agent ouvre l'app dans un navigateur vierge, s'inscrit avec une adresse générée, réalise la tâche sur notre site de test et enregistre chaque étape avec une capture. Une étape d'évaluation séparée tranche selon les critères du scénario : fonctionne, partiel, échoue ou bloqué.
Publication et fraîcheur
Une question n'est publiée que si au moins trois apps fonctionnent ou fonctionnent partiellement, testées depuis moins de 90 jours. Les preuves expirent après 60 à 120 jours selon le trafic et sont testées à nouveau.
Ce que l'argent n'achète jamais
Les paiements achètent de la rapidité de test, un profil Pro ou du volume d'API. Ils ne changent jamais un résultat ni une position ; un test automatique désactive tous les indicateurs payants et vérifie que l'ordre reste identique.
Corrections et contestations
Les auteurs peuvent contester toute exécution. Une contestation lance une nouvelle exécution avec de nouvelles données ; l'ancienne reste publique et est marquée comme remplacée. Signalez les erreurs à corrections@flyder.com.