Vous êtes-vous déjà demandé pourquoi votre spider Scrapy craché par une IA tourne comme une horloge sur une page démo, mais s’étouffe plus raide qu’un débutant en plongée à 30 mètres dès qu’on le lâche sur le web sauvage ?

Le problème ne vient pas des modèles. Ils sont des monstres aujourd’hui. Non, le coupable est toujours le même : un contexte pourri, des prompts paresseux, zéro compréhension des entrailles de Scrapy. Mais attendez. Imaginez une IA qui vit dans votre dossier de projet, qui scrute tous vos fichiers d’items.py à vos fixtures HTML, et qui pond des spiders vraiment déployables. C’est opencode. Et ça renverse la table du web scraping comme le navigateur l’a fait pour le dev web en 94.

Pourquoi Opencode surpasse-t-il tous les autres codeurs IA ?

Les agents génériques ? Ils sont comme ce pote qui vous fait un gâteau sur un vague « fais du chocolat » : ça a l’air bon, mais ça s’écroule tout seul. Opencode ? Natif terminal, indépendant des modèles, il insère chirurgicalement du code dans votre squelette Scrapy existant. Fini la loterie copié-collé. Il voit vos conventions AGENTS.md, vos objets de page scrapy-poet, et même cette clé Zyte API planquée dans .env. Résultat : les spiders ne sont plus des bidouilles, ce sont des machines de prod.

Et voilà mon avis bien senti, que personne ne crie encore sur les toits : opencode n’est pas qu’un outil, c’est le tueur d’IDE pour le scraping. Vous vous souvenez comment Vim et Emacs ont transformé le code en docs vivants ? Ça fait pareil pour les spiders. Prédiction : dans deux ans, tout pro du scraping initiera avec opencode, reléguant les sélecteurs fragiles au musée. On assiste à un changement de plateforme pour le scraping, les amis — l’IA comme copilote dans les tranchées du terminal.

Une ligne pour tout régner : curl -fsSL https://opencode.ai/install | bash. Boum. Ou via brew sur Mac/Linux pour des mises à jour qui collent. Les Windows, prenez WSL — choco marche, mais c’est comme scraper dans de la mélasse.

Branchez votre modèle. /connect dans le TUI. Choisissez des bêtes à gros contexte — 64k jetons minimum, vu que vos fixtures à elles seules bouffent 20k comme du pop-corn.

Squelette d’abord : scrapy startproject myproject, cd dedans, opencode init. Ça crache AGENTS.md. Remplissez-le. Commettez. Voici un exemple du playbook :

Conventions du projet

• Python 3.12, Scrapy 2.12
• Tous les spiders utilisent des objets de page scrapy-poet (jamais de parse dans la classe spider elle-même)
• Les classes Item sont définies dans items.py avec des dataclasses
• L’API Zyte est configurée via scrapy-zyte-api ; ZYTE_API_KEY est dans .env

Ça ? Votre sauce secrète. Plus jamais de contexte à répéter.

Peut-on vraiment pousser Opencode à la perfection Scrapy via des prompts ?

Demande générique : « Écris un spider pour books.toscrape.com. » Résultat ? Un script banal, pas du Scrapy. Corrigez. Soyez précis, impitoyable :

« Crée un spider Scrapy pour https://books.toscrape.com qui : - Utilise un objet de page scrapy-poet nommé BookListPage pour les pages de liste et BookDetailPage pour les détails - Extrait : titre, prix, disponibilité, note étoiles, et URL produit - Gère la pagination en suivant le lien « next » - Stocke les résultats dans un BookItem dataclass dans items.py - Ne met aucune logique de sélecteur CSS dans la classe spider elle-même. Commence par les objets de page dans pages.py, puis écris le spider dans spiders/books.py. »

Vous voyez la fin ? De l’or. Les agents adorent inline les sélecteurs — ça tue la testabilité, l’âme de scrapy-poet. Interdisez-le d’entrée.

Sélecteurs trop fragiles ? Exigez une justification : « Écris les sélecteurs CSS pour BookDetailPage. Pour chaque champ, explique pourquoi tu choisis ce sélecteur plutôt qu’une alternative. Privilégie les sélecteurs basés sur attributs (comme [itemprop] ou [data-*]) aux noms de classes quand les deux sont possibles. »

R