4.2 KiB
Exploitation
La question qui détermine tout : la sortie réseau
Une recherche standard émet 500 requêtes vers 500 domaines en quelques secondes. Depuis une IP unique — résidentielle ou de centre de données — cela déclenche des blocages : 403, CAPTCHA, 429.
Le moteur mesure ce taux. Au-delà de 30 % de sites non vérifiables, il émet un avertissement visible par l'utilisateur plutôt que de présenter des résultats partiels comme complets.
Sans proxy (LIMIER_PROXY_STRATEGY=none)
Viable pour un usage privé, quelques recherches par jour. Pour une ouverture publique, le taux de sites non vérifiables montera et la qualité se dégradera rapidement. C'est la raison pour laquelle Maigret lui-même et les services commerciaux comparables sont sponsorisés par des fournisseurs de proxies résidentiels.
Avec proxies
LIMIER_PROXY_STRATEGY=round_robin
LIMIER_PROXY_URLS=http://user:pass@p1:8000,http://user:pass@p2:8000
Le pool suit la santé de chaque proxy dans Redis, partagée entre workers. Au bout
de 5 échecs consécutifs, mise en quarantaine 15 minutes. L'état est visible sur
/api/admin/proxies, identifiants masqués.
C'est le poste de coût principal d'une instance publique. À chiffrer avant d'ouvrir, pas après.
Entretien de la base de sites
C'est ce qui distingue un outil vivant d'un outil qui dérive. Les plateformes changent leur HTML, la détection casse, et le scanner se met à produire des faux positifs sans que rien ne le signale.
Le worker exécute auto_controle_sites chaque nuit à 3 h. Maigret vérifie
chaque site avec un couple « pseudonyme connu / pseudonyme inexistant » : si le
site ne distingue plus les deux, sa détection est cassée et il est désactivé. La
base corrigée est écrite dans /data/sites/data.json, que les workers rechargent
automatiquement.
Indicateur à surveiller : le taux de sites désactivés, sur
/api/admin/sites. Au-delà de 15 %, la couverture se dégrade — relancer
l'auto-contrôle ou mettre la base à jour.
Le workflow maintenance.yml fait le même contrôle chaque lundi dans la CI,
mais sans désactivation : depuis un exécuteur de CI, blocages géographiques
et IP de centre de données font échouer des sites parfaitement sains.
Supervision
/api/metriques expose des compteurs Prometheus, sans aucune donnée
personnelle. Les libellés sont à faible cardinalité (kind, status,
confidence) : un libellé par site ferait exploser le nombre de séries.
Métriques utiles : limier_duree_recherche_secondes,
limier_sites_desactives, limier_refus_total{motif}.
Le journal sort en JSON, directement consommable par ton Graylog ou Wazuh.
Contraintes de dépendances à connaître
arq impose redis[hiredis]>=4.2,<6. Monter redis en 6.x ou 8.x casse
l'installation avec un ResolutionImpossible. La version retenue est 5.3.1.
Documenté dans pyproject.toml.
maigret tire networkx<3 et flask. Sans conséquence ici, mais cela
explique les avertissements de résolution si tu installes dans un environnement
partagé.
Pannes courantes
| Symptôme | Cause probable |
|---|---|
| Barre de progression figée | worker arrêté — relancer_recherches_bloquees libère après 2× le délai |
| Aucune progression, résultats d'un coup | mise en tampon SSE quelque part sur le chemin |
| « Redirect URI Error » à la connexion | URI saisie dans « URI de déconnexion » — voir 03-authentik.md |
| Beaucoup de sites non vérifiés | blocage de l'IP sortante — voir plus haut |
| crt.sh indisponible | normal, bascule automatique sur Certspotter |
| 451 sur une recherche | identifiant en liste d'exclusion (effacement appliqué) |
Vérifications de routine
curl -s https://limier.tips-of-mine.com/api/pret | jq
docker compose logs --since 24h limier-worker | grep -c echec_recherche
curl -s .../api/admin/sites | jq .taux_desactives # < 15
curl -s .../api/admin/tableau-de-bord | jq .conformite.demandes_en_attente