Une page web n'est plus lue uniquement par des personnes. Elle est parcourue par des moteurs de recherche, des crawlers IA, des systèmes de prévisualisation, des outils SEO et des automatisations qui ont souvent besoin de réponses différentes de celles pensées pour un navigateur humain.
Le web n'a plus un seul lecteur
Pendant des années, nous avons conçu des sites en imaginant un utilisateur devant un écran. Aujourd'hui, ce n'est qu'une partie de l'histoire. La même page peut être demandée par Googlebot, un crawler IA, un outil de prévisualisation ou un navigateur traditionnel.
Le problème est que ces clients ne lisent pas le site de la même manière. Un navigateur peut gérer JavaScript, les animations et les interactions. Un crawler IA peut préférer un contenu compact et lisible. Un moteur de recherche a besoin de métadonnées claires, de canonicals cohérents et de données structurées.
LLM Proxy Worker part de cette idée : ne pas modifier le site d'origine, mais ajouter devant lui une couche capable d'adapter la réponse selon le lecteur.
Un proxy edge comme couche intelligente
Le Worker tourne sur Cloudflare Workers et se comporte comme un middleware à l'edge. Il reçoit la requête, observe l'URL, les query params, le User-Agent et les headers, puis décide quel parcours appliquer.
Si la requête vient d'un navigateur humain, le site continue à répondre normalement, avec éventuellement un enrichissement SEO. Si elle vient d'un crawler IA ou d'une route de debug LLM, le Worker peut transformer le HTML en markdown. Si elle vient d'un crawler qui lit mal JavaScript, il peut servir du HTML prérenderisé.
Cette architecture est intéressante parce qu'elle ajoute des capacités transversales sans réécrire le CMS, le frontend ou le backend principal.
- navigateur : page originale ou enrichie avec des métadonnées
- crawler IA : version markdown plus propre et plus lisible
- crawler de recherche : HTML prérenderisé quand c'est nécessaire
- route de debug : réponses diagnostiques pour comprendre le comportement
Markdown pour LLM : moins de bruit, plus de contenu
Une page HTML complète contient beaucoup plus que ce qu'un modèle linguistique doit réellement lire : scripts, styles, footer, navigation, bannières, SVG, formulaires et autres éléments techniques.
Pour un crawler IA, ce bruit consomme des tokens et peut éloigner l'attention du contenu réel. La conversion en markdown sert à fournir une version plus compacte, ordonnée et proche du texte utile de la page.
Ce n'est pas un raccourci magique. C'est un choix d'interface entre le site et les systèmes automatiques : si le lecteur n'est pas humain, la réponse peut être adaptée à sa manière de traiter l'information.
SEO générée par IA, mais encadrée
La partie délicate n'est pas d'appeler un modèle. C'est d'éviter que le modèle devienne une boîte noire. Dans le projet, la génération SEO part de données réelles : HTML de la page, keyword, données SERP, intention de recherche, concurrents et contraintes calculées par le code.
OpenAI est le fournisseur principal, Claude sert de fallback, mais l'output n'est pas accepté aveuglément. Le résultat doit être un JSON valide et passer des contrôles sur title, description, Open Graph, canonical et JSON-LD.
Cela change le rôle de l'IA : elle ne décide pas seule de ce qui est important, elle travaille dans un périmètre défini par le système.
Prérenderiser seulement quand c'est utile
Beaucoup de pages modernes dépendent de JavaScript. Un navigateur humain les voit correctement, mais certains crawlers peuvent s'arrêter au HTML initial et perdre une partie du contenu.
Dans ces cas, le Worker peut utiliser Cloudflare Browser Rendering avec Puppeteer : il ouvre la page, laisse JavaScript s'exécuter et renvoie le HTML final. C'est puissant, mais plus coûteux qu'une requête normale.
C'est pour cela que le prérender n'est pas appliqué à tout le monde. Il s'active uniquement pour certains crawlers, des règles précises ou une demande de debug explicite. Les utilisateurs humains restent sur le parcours le plus léger.
Cache, fallback et durabilité
Une solution basée sur des LLM et Chromium peut devenir fragile si chaque requête déclenche un travail coûteux. Le projet utilise donc Cloudflare KV pour stocker les métadonnées SEO et le HTML prérenderisé.
La première requête peut générer le résultat. Les suivantes peuvent le réutiliser. Cela réduit les tokens, les appels externes, la latence et la variabilité de l'output.
Le plus important reste le comportement en cas d'erreur. Si DataForSEO ne répond pas, si OpenAI échoue, si Claude n'est pas disponible ou si Chromium part en timeout, le site ne doit pas casser. Le Worker revient à des fallbacks raisonnables ou à la page originale.
La partie senior : décider quoi ne pas faire
L'intérêt d'un projet comme celui-ci n'est pas d'utiliser le plus de services possible. C'est de décider quand ne pas les utiliser. Un LLM à chaque requête serait impressionnant, mais coûteux, lent et peu prévisible. Un navigateur headless pour chaque visite serait puissant, mais disproportionné. Une cache utilisée comme base de données deviendrait rapidement un problème de cohérence.
Le travail d'architecture consiste à tracer des limites claires : quelles requêtes méritent l'IA, lesquelles méritent le prérender, lesquelles doivent rester sur le parcours standard et ce qui se passe quand un fournisseur externe ne répond pas.
C'est la différence entre une démo qui fonctionne dans le cas idéal et un système capable de rester devant du trafic réel. Ajouter de l'intelligence ne suffit pas : il faut la contenir, la mesurer et la rendre remplaçable.
Un web lisible aussi par les machines
LLM Proxy Worker ne cherche pas à remplacer le site. Il cherche à le rendre plus lisible pour les différents lecteurs du web moderne : personnes, moteurs de recherche, crawlers IA et outils automatiques. C'est un petit exemple d'architecture adaptative : une même origine, des réponses différentes, des coûts contrôlés et des fallbacks toujours présents.
Continuer la lecture