On parle du vibe coding comme d’un acte de création : une idée, un prompt, une app qui sort de terre, et la mise en ligne dans la foulée. C’est une vue de l’esprit. La réalité du développement, ce n’est pas la création, c’est la correction.
La plus grande partie du temps d’un développeur ne part pas dans les fonctionnalités. Elle part dans les edge cases, ces effets de bord qu’on n’avait pas anticipés : le champ laissé vide, le double clic, la connexion qui lâche au mauvais moment. Et tant qu’on crée seul avec une IA, on a un angle mort énorme. Votre agent ne vous dira jamais qu’il vient de casser autre chose en réparant un détail. C’est ce qu’on appelle une régression, et c’est le pain quotidien de quiconque code.
La vraie question n’est donc pas « comment je crée plus vite », c’est « comment je sais que je n’ai rien cassé à côté ».
Le vrai métier, ce n’est pas créer, c’est encaisser les bugs
Le scénario qui fait mal, on le connaît tous : un utilisateur vous écrit « quand je clique sur tel bouton, il ne se passe rien ». Sur un de nos sites, c’était exactement ça : une page formation où le bouton ne menait nulle part. Personne ne l’avait vu. Sauf l’utilisateur.
C’est là que tout se joue. Les bugs ne sont pas un accident du parcours, ils sont le parcours. Une app s’améliore en fonction de ce qui casse. Le problème, c’est de savoir qui le trouve en premier : vous, ou vos utilisateurs ? Parce que dans le second cas, ça coûte beaucoup plus cher → en confiance, en réputation, et en temps de correction à chaud.
La QA n’a jamais migré vers le vibe coding
Le monde professionnel a une réponse à ce problème depuis longtemps : la QA, le quality assurance. Et derrière, une discipline précise → les tests end-to-end, ces tests « de bout en bout » qui simulent le parcours réel d’un utilisateur, du premier clic à la validation finale, par opposition aux tests unitaires qui ne valident qu’une fonction isolée.
L’outil de référence pour ça s’appelle Playwright. Il pilote un vrai navigateur, clique, scrolle, remplit des formulaires, change de viewport pour passer en mobile, le tout automatiquement. Très connu chez les pros. Quasi absent chez ceux qui créent avec l’IA. Pas par manque d’outil : par manque de bonnes pratiques. On a importé la vitesse de production de l’IA sans importer la rigueur de test qui va avec.
Tester à la main, soyons honnêtes, personne ne le fait vraiment. Revenir cliquer partout après chaque fonctionnalité, c’est pénible, donc on déploie et on croise les doigts. C’est précisément ce trou-là qu’un agent vient combler.
Playwright, mais pas n’importe comment : CLI plutôt que MCP
Brancher Playwright tel quel sur un agent, ce n’est pas terrible. Même via le MCP, ce protocole qui expose des outils à l’agent, ce n’est pas ce qu’on recommande dans ce cadre.
La raison est concrète. Un serveur MCP a tendance à réinjecter à chaque étape un snapshot complet de la page → l’accessibility tree, la structure entière du DOM, dans le contexte de l’agent. Ce contexte se remplit vite, la consommation de tokens explose, et plus la fenêtre est saturée, moins l’agent raisonne bien. Le Playwright CLI fonctionne autrement : l’agent le pilote en ligne de commande, comme un développeur piloterait son terminal, et ne récupère que l’essentiel. Moins de tokens, plus de précision.
La pièce qui rend le tout opérationnel, c’est le skill Playwright. Un skill, ce n’est pas un plugin magique : c’est un jeu d’instructions structuré, une carte du monde qui apprend à l’agent comment se servir correctement de l’outil → quels sélecteurs privilégier, comment attendre qu’un élément soit vraiment chargé, comment lire la console. CLI pour l’exécution, skill pour le savoir-faire. Et ça reste agnostique de l’agent : Claude Code, Codex, Cursor, Antigravity, l’outil ne change pas, seul le pilote change.
Détail qui compte, et qu’on oublie souvent : Playwright teste sur deux plans à la fois. Le rendu, via des screenshots, ce que voit l’œil. Et le DOM, via les locators et l’arbre d’accessibilité, ce que voit le code. Les deux ne disent pas la même chose. Un bouton peut être bien visible à l’écran mais non cliquable dans le DOM. Un texte peut exister dans le markup mais rester masqué par un overflow. Tester un seul des deux plans, c’est rater la moitié des bugs.
Un utilisateur « foufou » qui ne dort jamais
C’est là que ça devient intéressant. Plutôt que d’écrire des scénarios rigides et déterministes, on bascule en test exploratoire : on demande à l’agent de se comporter comme un utilisateur un peu fou qui essaie tout, dans le désordre, là où ça fait mal.
Lancé sur une app interne de gestion vidéo, il commence par cartographier l’application, puis il la parcourt comme un arbre : fonctionnalité par fonctionnalité, sous-catégorie par sous-catégorie. Il teste la capture, le triage, la pipeline, il fait un drag and drop d’une carte. Il déclenche les raccourcis clavier qu’on avait nous-mêmes oubliés, le command + entrée, et autres. Et surtout, il teste les cas qu’on ne lui a pas demandés : valider un champ vide, juste pour voir si l’app encaisse ou si elle part en erreur.
Pendant ce temps, il documente tout. Il prend des screenshots de chaque écran. Il enregistre une vidéo chapitrée de la session entière. Il bascule en version mobile pour traquer les bugs d’affichage propres au responsive. Et il ouvre les dev tools pour lire la console et le réseau : ces erreurs JavaScript silencieuses qui ne crashent rien visuellement mais cassent une fonctionnalité sur deux. Le résultat ? Un rapport complet, ce qui marche et ce qui casse, captures à l’appui. Sur cette session, il a remonté un doublon de catégorie que personne n’avait repéré, un lien coupé sur le côté → typiquement du layout shift, le CLS des Core Web Vitals, et un souci d’image LCP en mobile, le Largest Contentful Paint, cet indicateur de performance perçue que Google surveille de près.
Une subtilité change tout. Par défaut, un agent cherche à optimiser : il va droit au but, le plus court chemin vers le succès. Pour qu’il trouve les vrais bugs, on l’oblige à faire l’humain → scroller pour de vrai, attendre, déplacer la souris comme un visiteur réel. Parce que vos bugs ne sont pas déclenchés par un script efficace, ils sont déclenchés par un humain maladroit.
Et le jour où c’est un iPhone sous Safari ?
C’est presque toujours là que ça casse : quelqu’un sur un vieil iPhone, en Safari, et votre site qui déraille pendant que tout allait bien sous Chrome. Playwright gère ça par sa matrice cross-browser : il simule Chromium, Firefox et WebKit, le moteur de Safari, et vous sort un rapport par navigateur.
Pas assez de puissance pour faire tourner tous ces navigateurs en local ? Les tests s’exécutent en mode headless, sans interface graphique, ce qui les rend légers et parallélisables. Et des services compatibles Playwright comme BrowserStack ou LambdaTest font tourner la batterie sur des dizaines de configurations réelles dans le cloud, pendant que votre machine respire.
On peut pousser plus loin encore : lancer plusieurs sous-agents en parallèle, un par fonctionnalité, chacun avec son propre navigateur. Le temps de test s’effondre. Tout devient possible. Mais il faut d’abord comprendre que c’est possible pour oser l’imaginer.
Vers une app qui s’auto-améliore
C’est peut-être ça, la vraie bascule. Jusqu’ici, on développait en spec-driven : on décrit une spécification, l’IA produit le code. Demain, on développe en bouclant la spécification avec un agent de test qui vient triturer l’application, remonter ce qui casse, et nourrir directement la correction.
On peut fermer la boucle entièrement : tests E2E à chaque déploiement, intégrés à la CI, vidéo générée automatiquement, et bugs renvoyés à l’agent qui code pour qu’il les corrige. On entre dans la logique du self-healing, l’app qui ne se contente plus d’exister mais qui se répare. Ce n’est plus un développeur qui code puis qui teste : c’est un système où la création et la critique tournent en continu, l’une alimentant l’autre.
Créer, c’est bien. Tester, c’est mieux. Reste une question à se poser avant le prochain déploiement : combien de bugs dorment déjà dans votre app, en attendant que ce soit un utilisateur, et pas vous, qui les réveille ?
