Vibe Coding: limites et opportunités

Avec la généralisation de l'expression “Vibe Coding”, une nouvelle ère s’ouvre pour les entreprises pour donner à leurs utilisateurs l'opportunité de créer des applications afin de mieux tester leurs hypothèses avant de lancer des développements lourds et coûteux.

Chez Ippon Technologies, en tant que stagiaire, j’ai eu comme mission d'étudier comment des solutions alimentées par de l’IA peuvent permettre à un individu non-technique de créer ses applications pour résoudre ses problèmes quotidiens et lui permettre d’innover sans avoir recours à des équipes IT.

Dans le cadre de mon stage, je me suis attachée à tester différents outils et différents LLM afin de les comparer, d'identifier leurs limites communes et de déterminer quelles sont les connaissances de base indispensables au “Vibe coding”. Cet article résume mes conclusions et mes conseils.

Qu'est-ce que le Vibe Coding ?

Le Vibe Coding est avant tout un concept relativement nouveau inventé en 2025 qui s'appuie sur un programme piloté par l'IA afin de convertir les besoins exprimés verbalement par un utilisateur en application exploitable par la machine. Cela permet aux personnes n'ayant pas de compétences en code d'utiliser les solutions existantes pour développer leurs idées d'applications – idéalement, d'accroître l'efficacité et de réduire les coûts en automatisant les processus longs. Malheureusement, la réalité est bien plus complexe, compte tenu des nombreuses limites et de la maturité des outils disponibles. Cependant, au fil de mes expérimentations, avec une courbe d’apprentissage relativement rapide, j'ai pu identifier certaines pratiques qui permettent d'accélérer la création d’application. Les aspects les plus cruciaux à considérer sont :

  • travailler les scénarios business (positifs et négatifs)
  • avoir une réflexion d’architecture (besoin de se connecter à des applications externes, besoin de sauvegarder des informations, besoin d’authentification, …)

Ingénierie rapide

Afin d’illustrer mes propos, nous allons mettre en place ces éléments en créant un jeu de pêche sous-marine, « Coral City Racers ». Cette application fut un fil rouge tout au long de mon stage. Le but d’un point de vue technique était de mettre en place des éléments d’interface, un système d'autorisation ainsi que la persistance du résultat des différentes courses pour pouvoir rejouer et améliorer son classement global.

Afin de se mettre dans la peau de personnes non techniques, je n’ai pas cherché à influencer les choix de langage de programmation ou le choix d’un framework particulier. Mon approche a été uniquement d’utiliser des termes issus de tous les jours.

Le but de l’application « Coral City Racers » est simple : une course en 2D, où il faut essayer de finir le plus rapidement possible en évitant les obstacles et ainsi participer au score global. Le fait d’utiliser un jeu pour illustrer mes propos permet de mieux illustrer les difficultés rencontrées.

Les premières frustrations :

Après plusieurs essais, je me suis très vite rendue compte d’un certain nombre de limitations.

  • Nécessité de maîtriser l'art du prompt : N'ayant aucune connaissance en ingénierie des prompts, j'ai passé des heures à modifier les fonctionnalités ajoutées ou mal interprétées par la solution. En développement logiciel, c’est la définition des besoins et leur orchestration.

  • Limitations des versions gratuites : Les versions gratuites des outils m'ont rapidement fait manquer de tokens, m'empêchant de modifier mon projet avant le renouvellement de la limite. On parlera d'efficacité de prompt.

  • Problèmes techniques récurrents : Malgré l'accès à l'abonnement payant, j'ai été fréquemment bloquée par des pannes système et une saturation du moteur - certaines interfaces ou des connections avec des systèmes externes ne fonctionnaient pas

  • Impact sur les délais : N’ayant pas opté pour une stratégie claire au début, je me suis vite retrouvée bloquée avec des corrections qui tournaient en rond pour pouvoir mener à bien mon projet et devoir ainsi le recommencer de zéro - on appelle ceci la maintenabilité et l'évolutivité.

  1. Première étape importante : bien s'adresser à la machine.

Le "prompt engineering" est essentiel pour obtenir le produit souhaité à partir des IA génératives. Sans cette maîtrise, les résultats sont souvent imprécis, entraînant une perte de temps et d'argent. Des problèmes courants incluent le temps passé à combler les lacunes et la surconsommation de tokens.

Pour améliorer les prompts, suivez la structure :

  • Rôle, format, contexte, référence, évaluer, et répéter. Définir un rôle, un public cible, spécifier les caractéristiques, fournir le contexte et des exemples, limite l'ambiguïté. D'autres pratiques incluent la correction par l'IA, demander à l'IA la meilleure invite, et tester le produit.
  • Séparer clairement les idées par paragraphes et titres, et rafraîchir la fenêtre après chaque saisie, sont aussi des conseils utiles.

  1. Etape 2 : Sélectionner votre solution

Une fois votre sujet perfectionné, le facteur le plus important est le choix de la solution. Afin d'évaluer équitablement les résultats de mes expériences, j'ai toujours testé mes sujets avec plusieurs solutions et j’ai mis en place une grille de lecture pour les comparer (table 1). Afin de les évaluer de la façon la plus objective possible, j’ai utilisé les mêmes prompts à chaque fois en prenant compte de mes erreurs.

Table 1 :


1 - Non satisfaisant

2 - Besoin d'amélioration

3 - Satisfaisant

4 - Bon

5 - Excellent

A - Utilisation

Le produit n'a pas pu être fabriqué par LLM

La production du produit s'est avérée complexe et a nécessité de nombreuses tentatives et modifications du modèle initial. Le LLM était difficile à manipuler et manquait d'instructions claires.

Le produit a été réalisé du premier coup, mais l'utilisation de LLM n'était pas intuitive, mais des instructions claires ont été fournies

Le produit a été réalisé du premier coup et LLM était assez simple à parcourir

Le produit a été réalisé du premier coup et l'utilisation de LLM était extrêmement claire

B - Rapidité

Le LLM a souvent rencontré des pannes de système qui ont entravé la production des produits

Le LLM traitait les informations très lentement et la sortie était parfois obstruée par des pannes du système

Le LLM a traité les informations lentement, mais de rares pannes système se sont produites

Le LLM a traité les informations dans un délai acceptable et aucune panne du système ne s'est produite.

Le LLM a traité les informations rapidement et aucune panne du système n'a eu lieu

C - Précision

Le produit différait/ne contenait pas beaucoup d'éléments essentiels par rapport à ce qui était demandé dans le prompt initial

Le produit différait/ne contenait pas un aspect crucial de l'invite

Le produit différait/ne contenait pas beaucoup d'aspects banals de l'invite

Le produit différait/ne contenait pas une petite quantité d'aspects banals de l'invite

Le produit contenait exactement ce qui était demandé par le client.

D - Qualité visuelle

Le produit avait une qualité visuelle extrêmement faible et manquait de profondeur cruciale pour le contexte de l'application.

Le produit avait une faible qualité visuelle et le contexte est difficile à déduire

Le produit avait une qualité visuelle satisfaisante et le contexte du jeu restait évident

Le produit avait une bonne qualité visuelle et le contexte du jeu est évident

Le produit a une excellente qualité visuelle et le contexte du jeu est évident

E - Jouabilité

Le produit n'était pas utilisable

Le produit était techniquement utilisable mais de nombreux aspects cruciaux manquaient ou manquaient de fluidité.

Le produit était utilisable mais des détails manquaient et la fluidité pourrait être améliorée

Le produit était utilisable et seuls quelques petits détails manquaient

Le produit était utilisable et aucun détail ne manquait

Table 2 : Résultat en prompt - solution pure LLM


A - Utilisation

B - Rapidité

C - Précision

D - Qualité visuelle

E - Jouabilité

Score total

Deep Seek R1

5

2

3

3

3

16

Gemini 2.5

5

5

4

3

4

21

Firebase Studios (emini Flash 2.0)

5

4

2

2

2

15

Claude Sonnet 3.7

5

4

2

4

2

17


Résultat par Google AI Studios


Résultat en utilisant Claude

Table 3 : Résultat après ajustement en mode discussion


A - Utilisation

B - Rapidité

C - Précision

D - Qualité visuelle

E - Jouabilité

Score total

DeepSeek

5

3

4

4

4

20

Google AI Studios*

5

4

4

3

1

17

Firebase Studios

5

4

2

4

2

17

Claude

5

4

4

4

5

22

J'ai découvert par exemple que Google AI Studios a eu la meilleure performance lorsqu'on lui a donné l'invite brute, mais une fois cette invite améliorée, Claude donne un rendu plus satisfaisant. Ces 2 outils ont obtenu d'excellentes notes car ils ont permis de maintenir un temps de traitement rapide tout en préservant un résultat qualitatif, plus respectueux des délais que les autres LLM.

  1. Etape 3 : une solution SAAS de vibe coding 

J'ai ensuite approfondi mes recherches en testant des solutions spécialisées dans la création d'applications sur le web en utilisant la genIA. Je souhaitais élargir mon champ d'investigation, passant des outils courants, comme ceux créés par Google, à des outils indépendants, parfois même dotés de leurs propres LLM. À l'aide de Bolt.new et de version0, j'ai analysé et comparé leurs forces et leurs limites de telles solutions, ainsi que leurs versions gratuites et payantes par abonnements.

Table 4 : Comparaison des solutions gratuites vs payantes et des plateformes

Aspect

Solution gratuite

Solution payante Bolt Pro (~20$)

Solution payante v0 Premium (~20$)

Points forts

Accessible à tous

Utile pour un travail quotidien limité

Navigation simple et claire


Instructions détaillées fournies

Capacité de tokens beaucoup plus grande

Fonctionnalités externes avancées

Configuration Firebase (classements, profils, authentification)


Système d'amis (codes d'accès, demandes, classements)

~20$ de crédits mensuels inclus

Limite de taille de pièce jointe 5x plus élevée

Import depuis Figma

Accès à v0-1.5-lg


Accès à l'API v0

Limites

Capacité d'entrée quotidienne limitée

Consommation rapide des tokens


Analyse superficielle des réponses

Plus de tokens n'impliquent pas nécessairement plus de possibilités

Saturation serveur après ajout de fonctionnalités


Problèmes récurrents (IA qui s'arrête, chronomètre défaillant, victoire non enregistrée)

Ne remplit pas certains aspects visuels automatiquement

Difficile d'obtenir le résultat souhaité

Bugs fréquents rendant le jeu injouable


Produit uniquement des pistes carrées basiques

Critiques sur l'accessibilité

Navigation simple et claire

Bot n'effectue pas toutes les actions automatiquement

Compétence technique requise mais étapes détaillées fournies


Nécessité de version pro dépend du contexte

Configuration simple et réussie des fonctionnalités Firebase

Problèmes de boucle de jeu et détection de collision


Serveur saturé après modifications

Manque d'autonomie mais plus d'espace de personnalisation

Fonction "conception" disponible mais résultats erronés


Utilisation incorrecte des images téléchargées

Recommandations

Planifier les entrées avec le moins d'ambiguïté possible


Éviter les ajustements multiples pour réduire le gaspillage de tokens

Effacer et relancer le serveur après ajout de fonctionnalités

Se concentrer sur le perfectionnement de la base avant d'ajouter des fonctionnalités


Gérer la saturation serveur

Utiliser les crédits mensuels inclus efficacement

Profiter des fonctionnalités premium (API, import Figma)


Comprendre les limitations de l'outil

Expérience personnelle

Utilisation rapide des tokens gratuits

Manque d'analyse approfondie des réponses rapides


Problèmes de sursaturation après ajout de fonctionnalités externes

Problèmes de sursaturation après modifications

IA incapable de résoudre certains bugs techniques


Fonctionnalités avancées mais instables

Résultats visuels limités et parfois incorrects

Personnalisation possible mais complexe


Accès premium étendu mais utilisation limitée pour non-programmeurs

Conclusion

L'abonnement vaut son prix selon :

Fréquence d'utilisation

Nature du projet (personnel/professionnel)

Complexité de l'application


Contraintes de délai

Solution complète mais instable

Idéal pour projets complexes avec intégrations externes


Nécessite une gestion attentive des ressources serveur

Outil premium avec fonctionnalités étendues

Plus adapté aux développeurs expérimentés


Limites inhérentes à la plateforme

Captures d'écrans de la solution finale

Remarques importantes :

  • Ces solutions doivent être utilisées avec précaution car des problèmes imprévus et des erreurs système sont susceptibles de se produire
  • En tant que non-développeur, vous ne pouvez pas auditer et contrôler entièrement la qualité et l'efficacité de votre projet
  • Ces solutions ne sont qu'un moyen de créer un prototype, et non un produit final
  • La maturité des solutions est adaptée aux idées simples, mais l'IA se perd avec trop de complexité

Comment optimiser ses tokens ?

  • Afin de pouvoir mieux gérer la consommation des tokens, le mieux est d'éviter de demander à l'IA de faire des aller-retours. Pour ce faire, je me suis aperçue que l'écriture de scénarios utilisateurs simples (que nous appelons User-Story) avec les différentes exceptions permet de mieux diriger l'IA. Il vaut mieux passer du temps (en utilisant soit votre outil soit une IA générique - table 3) pour bien définir tous les cas dans un premier temps.
  • Le deuxième avantage de cette approche est la capacité d'auditer la solution et de vérifier que tout a été bien implémenté par l'IA avant de commencer ses tests utilisateurs.
  • Par contre, j'ai eu plus de mal à influencer le design de l'interface (notamment avec des tests sur une solution de Scraping).

Logique de développement de l’application :

Ce que j’ai appris en partageant avec mes collègues et que je conseillerais à mettre en oeuvre : 

  1. Définir le but de votre application
  2. Définir la liste des services nécessaires à cette application (identification, base de données, connexions extérieures à des services de style API, connexion à des modèles de LLM, …)
  3. Définir la liste détaillée de vos cas d’usage
  4. Tester
  5. Distribuer

Une fois que vous avez choisi votre outil, une version payante sera nécessaire dans la plupart des cas (surtout si vous voulez partager votre application et pouvoir plus ou moins facilement faire des évolutions).

Quelle que soit l'attention portée par un concepteur d'applications aux bonnes pratiques à suivre pour optimiser l'utilisation d'une solution, certaines limites sont inévitables :

  • ne pas vouloir trop faire : la maturité des solutions toute faites est bonne si l’on veut mettre en place des idées simples, dès qu’il y a trop de choses, l’IA se perd
  • les capacités de correction si l’on ne touche pas au code, restent limitées et deviennent très vite frustrantes.
  • se référencer dans son prompt a quelque chose qui existe permet de gagner du temps ( example marketplace Amazon ou shopify, style de jeu vidéo, … ) 

Conclusion

Au cours de cette mission, j’ai donc pu voir et creuser davantage comment fonctionne une solution de vibe coding ainsi que les limitations. Grâce aux conseils de mes collègues développeurs, j’ai pu mettre en place une méthodologie qui m’a permis de générer des applications plus rapidement tout en contrôlant davantage la consommation de token (plus on consomme, plus ça tourne en rond). Sans leur support ni leur approche structurelle, j’aurais perdu beaucoup de temps et d'énergie - voire je doute d'être arrivé à ce résultat final. 

 Si les solutions de marche aujourd’hui semblent magiques à première vue, je trouve que l’on se retrouve très vite coincés et qu’une aide un peu plus technique est nécessaire pour sortir de l’impasse. Les outils SAAS restent des boîtes noires qui certe facilitent pleins de choses - mais dont on contrôle très peu :

  • Où et comment sont stockés les informations personnelles (si l’on décide de faire un login par exemple)
  • Qui garantie que mon application va fonctionner sur le long terme et que faire en cas de bug ? 

En guise de proof of concept, j'ai ensuite appliqué la même méthode pour la création d'une application web de scraping de documentation API - avec le résultat suivant :

En moins de 2 jours, j'ai pu mettre une application déployable sur internet qui savait télécharger la documentation technique, le remettre en forme pour être lisible par un utilisateur lambda et la rendre téléchargeable sous plusieurs formats. L'application permettait aussi de gérer les erreurs en informant l'utilisateur des possibles actions à mener.


Sources 

Liens utiles

Outils de Vibe Coding testés

  • Bolt.new - Plateforme de création d'applications alimentée par l'IA
  • v0 - Outil de génération de code et d'interfaces utilisateur
  • Google AI Studio - Plateforme de développement d'applications IA de Google
  • Firebase - Plateforme de développement d'applications de Google

Modèles de langage (LLM) évalués

Ressources d'apprentissage

Outils de développement et intégration

  • Faveod - Solution historique utilisant le NLP pour la génération de code
  • Figma - Outil de design pour l'import dans v0
  • Firebase - Authentification, base de données et hébergement


Annexes : 

Prompt 1 : Pour la création du jeu 

"Game Design Document: Coral City RacersStudio: AquaPlay StudiosTarget Audience: Children, Ages 6-10Platform: Web Browser (PC/Mac)

Monetization: None (Premium, or Free with no ads/IAPs)

I. Executive Summary

Logline : A vibrant and cheerful 2D underwater racing game where kids race as customizable fish through beautiful ocean landscapes, mastering precision control to stay on the path, out-swim a rival, and dodge grumpy sharks.

Core Pillars :

  1. Intuitive Precision: Simple, responsive controls are easy to learn but require focus to master the winding race tracks.
  2. Positive Reinforcement: The game celebrates effort. Win/loss states are immediate and clear, but always encourage another try with a positive tone.
  3. A World of Wonder: Visually rich and imaginative environments spark curiosity and a desire for discovery.

II. Game Flow & User Experience (UX)

The player's journey is designed to be simple and seamless.

  1. Splash Screen: AquaPlay Studios logo.
  2. Main Menu:
    • Large, friendly "PLAY" button.
    • "CUSTOMIZE" button (initially locked).
    • "OPTIONS" button (Sound On/Off).
    • Instructions Box: A prominent, clear visual guide on the main screen:
      • Icon of Arrow Keys / Finger Dragging -> "Use to Move!"
      • Icon of Player Fish on a path -> "Stay on the Glowing Path!"
      • Icon of Grumpy Shark -> "Avoid the Sharks!"
      • Icon of Player Fish ahead of AI Fish -> "Beat the Other Racer!"
  3. Level Select Screen:
    • Displays unlocked environments as large, clickable icons.
    • Locked levels are shown as greyed-out with a padlock icon.
  4. Race Countdown:
    • Once a level is selected, the race screen appears.
    • A large "3... 2... 1... GO!" visual counts down in the center of the screen. Player and AI are frozen during the countdown.
  5. Gameplay (Race): The player controls their fish on the track. (See Sec IV for details).
  6. End of Race Screen:
    • On Win: "YOU WIN!" banner. The player's fish does a happy victory loop.
      • Displays rewards: "+10 Shiny Shells".
      • Buttons: "Next Race", "Retry", "Level Select".
    • On Loss (AI Wins): "NICE TRY!" banner. The player's fish looks slightly disappointed but shrugs it off.
      • Displays rewards: "+3 Shiny Shells".
      • Buttons: "Retry", "Level Select".
    • On Loss (Off Path): "WHOOPS! OFF PATH!" banner. The game freezes, highlighting the fish outside the track boundary.
      • Displays rewards: "+1 Shiny Shell".
      • Buttons: "Retry", "Level Select".

III. Setting & Art Direction

  • Art Style: Clean, 2D vector art. Saturated, bright colors. Use colored outlines instead of harsh black ones to maintain a soft, friendly look.
  • Visual Priority: The race track path must have the highest visual contrast against the environment to ensure it is always perfectly clear.
  • Character Design:
    1. Player/AI Fish: Cute, expressive designs with oversized eyes.
    2. Sharks: Grumpy, bored-looking obstacles, not menacing predators.
  • Environments (Levels):
    1. Coral City Speedway: Pinks, oranges, blues.
    2. Kelp Forest Rally: Greens, yellows, teals.
    3. Sandy Treasure Run: Golds, sandy browns, aquas.
    4. Volcano Vents Velocity: Reds, purples, magentas.

IV. Core Gameplay Mechanics (Technical Specifications)

  • Player Control:
    • Keyboard: 4-way movement (Up, Down, Left, Right). The fish moves at a constant speed.
    • Mobile: The fish's center point instantly moves to the player's finger position (direct 1:1 touch-drag).
    • Player Speed: Player_Base_Speed = 100 units/sec. Movement must feel exceptionally fluid and responsive to allow for precise path-following.
  • The Racetrack:
    • Path Definition: The race path is a visually distinct texture (e.g., glowing algae on a darker seabed). It has a defined width of 1.5x the player fish's height.
    • Path Boundary - CRITICAL MECHANIC: The race path is a hard boundary.
      • Loss Condition: If the player fish's center point moves outside the defined path area at any time after the race starts, the player instantly loses the race.
      • Implementation: The game will continuously check if PlayerFish.CenterPosition is within the path's polygon. If false, trigger the "Off Path" loss state immediately.
  • AI Opponent:
    • Base Behavior: The AI follows a perfect, pre-defined spline path down the center of the track.
    • AI Speed: AI_Base_Speed = 98 units/sec (slightly slower than the player).
    • Rubber-Banding (Fairness Mechanic):
      • If Player is >3 sec behind, AI speed reduces to 90 units/sec.
      • If Player is >3 sec ahead, AI speed increases to 105 units/sec. This ensures the AI remains a visible challenger, adding to the pressure of staying on the path.
  • Obstacles: Grumpy Sharks
    • Behavior: Sharks move on simple, predictable paths (horizontal, vertical, circular).
    • Collision Consequence: If the player touches a shark, the player is knocked back a short distance and stunned (cannot move) for 1.5 seconds. A "Bonk!" sound and "Dizzy Stars" visual will play. This is a time penalty, not an instant loss.

V. Win/Loss Conditions & Progression

  • Winning a Race:
    1. Condition: Cross the finish line before the AI opponent. The player must have remained on the race path for the entire duration of the race.
    2. Reward: +10 Shiny Shells. Unlocks the next level (if applicable).
  • Losing a Race (3 Scenarios):
    1. AI Finishes First: The AI opponent crosses the finish line before the player.
      • Reward: +3 Shiny Shells.
    2. Going Off-Path: The player fish's center point leaves the defined race path.
      • Feedback: The race immediately stops. A "WHOOPS! OFF PATH!" message appears on screen. A specific "error" or "slip" sound effect plays.
      • Reward: +1 Shiny Shell.
    3. Timer Runs Out (Optional Fallback): For development, implement a generous race timer of 90 seconds. If the timer runs out, it counts as a loss. This prevents any potential game-breaking stalls.

VI. Progression & Replayability

  • Level Unlocking: Unlocked by winning the previous race, or by purchasing access.
  • Currency System: "Shiny Shells"
    • Earning: Win (+10), Lose to AI (+3), Go Off-Path (+1). This tiered reward encourages skillful play while still rewarding any attempt.
    • Spending:
      • Unlock Level: Purchase access to the next level for 100 Shells.
      • Customization: Spend shells in the "CUSTOMIZE" menu for new fish colors (25 shells) and fin patterns (40 shells), providing a constant goal for players.

VII. Required Asset List

  • Sprites & Animations:
    • Player/AI Fish (Idle, Swim, Stunned, Victory, Defeat animations)
    • Shark Obstacle (Patrol animation)
    • Environment and Background assets for all 4 levels.
    • Race Track Textures (path and off-path).
    • Finish Line Banner & "Shiny Shell" icon.
  • UI Elements:
    • Buttons (Play, Customize, etc.).
    • Level Select Icons (Active, Locked).
    • HUD Race Progress Bar.
    • Countdown Numerals (3, 2, 1, GO!).
    • End-of-Race Banners: "YOU WIN!", "NICE TRY!", "WHOOPS! OFF PATH!"
  • Audio:
    • Music: Main Menu Theme, 4 unique Race Themes.
    • Sound Effects (SFX):
      • UI Clicks, Countdown Beeps.
      • Shark Collision/"Bonk" & Player Stun.
      • "Off-Path" Failure sound (distinct from other sounds, e.g., a cartoon slip/slide sound).
      • Finish Line, Victory Stinger, Loss Stinger, Shell Collection."

Prompt 2: "Web Scraping App" 

  • Each found link now appears in a styled card with better visual hierarchy
  • Links are displayed with proper truncation and hover effects
  • Added external link icon for opening links in new tabs
  • Added a "Scrape" button next to each link with a search icon
  • Button shows loading state with spinner when scraping is in progress
  • Disabled state prevents multiple simultaneous scrapes of the same link

3. Seamless Integration

  • Clicking "Scrape" automatically switches to the scraper tab
  • Initiates the full scraping process for the selected link
  • Results appear in the results tab just like manual URL entry

4. Enhanced User Experience

  • Visual feedback during scraping with loading indicators
  • Proper error handling for failed link scrapes
  • Maintains all existing functionality (analytics, history, etc.)
  • Only shows the first 15 links to avoid overwhelming the interface
  • Displays count of additional links if more than 15 are found
  • Each link is clickable for external viewing or scrapable for analysis

How to Use:

  1. Scrape any webpage as usual
  2. View results in the Results tab
  3. Expand the "Found Links" section
  4. Click the "Scrape" button next to any interesting link
  5. The system automatically processes the new URL and shows results"