Scraper IA Python : nettoyer le HTML puis répondre en Markdown

Un guide détaille la construction d’un scraper web en Python qui ne renvoie pas la page brute mais une réponse ciblée en Markdown. Le procédé nettoie le HTML, convertit en Markdown et interroge un modèle OpenAI léger, avec l’objectif explicite de gagner en lisibilité et d’économiser des tokens.

Le LLM répond sous contraintes et en Markdown propre

La fonction answer_query_from_page encapsule la logique d’interrogation du modèle. Le prompt y assigne au modèle le rôle d’assistant de scraping et lui fournit deux entrées : le Markdown extrait de la page et la requête utilisateur. Il impose un cadre strict : renvoyer uniquement du Markdown propre, s’appuyer exclusivement sur le contenu de la page et s’abstenir d’inventer des éléments manquants. Les liens de navigation, boutons, CTA, popups, labels décoratifs, légendes d’image et fragments marketing répétés doivent être ignorés, avec des exemples explicites comme « Start for free », « Contact Sales » et « Your AI Agent ». À l’inverse, l’accent est mis sur les en-têtes, les paragraphes, les descriptions de produit, les sections de fonctionnalités, les détails de tarification, le texte de documentation et les affirmations factuelles. Si la page ne contient pas la réponse, le modèle doit répondre « The page does not contain this information. », le tout en restant bref, clair et ciblé. L’appel se fait via client.responses.create avec le modèle défini, et la fonction retourne directement response.output_text. Ce format Markdown facilite l’affichage dans un notebook, l’enregistrement dans un fichier et la réutilisation dans d’autres chaînes de traitement IA. C’est l’étape où le scraper devient véritablement utile.

Réduire les tokens et viser l’essentiel plutôt que la page entière

Le cœur de la méthode consiste à ne pas envoyer la page complète au modèle. Le contenu est d’abord nettoyé puis converti en Markdown, avant d’être exploité pour répondre à une requête précise. Cette approche diminue l’usage de tokens et produit une sortie ciblée en Markdown plutôt qu’un renvoi de la page entière. Les bénéfices attendus sont une réponse plus claire, plus lisible et plus simple à intégrer dans d’autres flux. L’objectif opérationnel est explicite : lire le contenu épuré, comprendre la requête et renvoyer une réponse pertinente. Un modèle plus petit, défini ici comme "gpt-5.4-nano", est privilégié car la tâche ne réclame pas de raisonnement complexe. La démarche suppose donc un enchaînement assumé : nettoyer, convertir en Markdown, puis interroger le modèle.

Préparer l’environnement : packages, clé API et modèle

Le projet se mène dans Jupyter Notebook pour valider chaque étape avant d’en faire une API ou une application. Les dépendances requises couvrent la récupération HTTP (requests), le nettoyage HTML (BeautifulSoup), la conversion en Markdown (markdownify), la correction de texte (ftfy), le SDK d’appel au modèle (OpenAI) et le chargement sécurisé de la clé (python-dotenv). Les modules correspondants sont importés, y compris Markdown et display pour l’affichage dans le notebook. La clé OpenAI doit être fournie en variable d’environnement, idéalement via un fichier .env local contenant OPENAI_API_KEY=your_api_key_here, puis l’instance client est créée en lisant cette variable. Un contrôle lève une erreur explicite si la clé manque. Côté compte, la facturation doit être configurée ; des crédits prépayés peuvent être nécessaires sur un nouveau compte, et il est possible de sélectionner un autre modèle si celui choisi n’est pas disponible. Le projet fixe MODEL_NAME à "gpt-5.4-nano", un choix cohérent avec une tâche ne nécessitant pas un raisonnement complexe.

Récupérer la page avec un User-Agent et des garde-fous réseau

La fonction fetch_page réalise la requête HTTP avec un en-tête User-Agent explicite pour signaler l’origine et éviter des blocages que certains sites appliquent aux clients sans User-Agent. Un timeout de 15 secondes est fixé pour ne pas rester en attente si le serveur ne répond pas, et raise_for_status met fin à l’exécution en cas de code d’erreur, par exemple 404 ou 500. La fonction renvoie le corps texte de la réponse. Le guide illustre un appel réel en ciblant https://www.olostep.com/ et en affichant les 500 premiers caractères du HTML brut, ce qui permet de constater la quantité d’éléments superflus présents avant nettoyage.

Nettoyer le HTML : scripts, menus, formulaires et popups supprimés

L’étape de nettoyage commence par corriger d’éventuels problèmes d’encodage, puis par analyser la page avec BeautifulSoup. Les balises considérées bruyantes sont supprimées : scripts et styles, contenus graphiques et embarqués, éléments de navigation, en-têtes et pieds de page, zones latérales, formulaires et boutons. Au-delà de ces cas évidents, une passe supplémentaire parcourt les balises pour détecter des classes ou des IDs contenant des termes typiquement non pertinents comme popup, cookie, navbar, newsletter ou modal ; ces éléments sont collectés puis supprimés en sécurité. La fonction renvoie le corps de la page quand il existe, ou l’arbre HTML sinon, afin de fournir une base plus propre à la conversion en Markdown.

Convertir en Markdown et filtrer les scories récurrentes

La conversion s’effectue avec markdownify en mode d’en-têtes ATX, puis un second passage de correction d’encodage est appliqué. Le Markdown d’image est retiré par expression régulière pour ne conserver que le texte utile. Le traitement supprime aussi les espaces superflus et compacte les sauts de lignes afin de réduire encore le volume transmis au modèle. Une petite liste de chaînes récurrentes, du type messages de confirmation ou d’erreur de formulaire, est filtrée en ignorant ces lignes après normalisation en minuscules. Les lignes restantes sont jointes pour constituer un Markdown compact et lisible, avec en-têtes, paragraphes et listes réellement informatives.