Refonte de DOMAutopsy en quatre heures, et les cinq choses que l'IA n'a pas pu décider
J’ai passé un dimanche après-midi à refondre DOMAutopsy, le harvester de locators visuels que je maintiens, en passant d’un outil desktop PySide6 à un serveur FastAPI avec UI web en direct. Le travail a pris environ quatre heures. Claude Code a écrit la majorité des ~4 000 lignes livrées.
Ce chiffre, seul, ne dit rien. C’est le genre de nombre que les gens citent sur LinkedIn pour vendre une prestation. Ce qu’il signifie réellement dépend entièrement des décisions qu’on laisse au modèle, et de celles qu’on garde pour soi.
Cinq décisions me sont restées de cette session. Aucune n’était techniquement difficile. Toutes auraient produit un code sensiblement moins bon si j’avais accepté la première suggestion du modèle.
1. Le système n’avait pas besoin de RAG
Section intitulée « 1. Le système n’avait pas besoin de RAG »La première proposition de l’agent pour capturer le contexte sur une longue session de navigation était d’embedder les snapshots de page, de les stocker dans un index vectoriel, et de récupérer les top-k chunks quand le LLM avait besoin de raisonner sur la trajectoire. C’est une suggestion raisonnable en 2026. Elle aurait aussi ajouté une dépendance à une base vectorielle, à un modèle d’embeddings, et à un pipeline de retrieval que personne du côté utilisateur n’a demandé.
Le vrai besoin était plus simple. L’agent observe le DOM en direct, le listener capture les sélecteurs, le rapport agrège tout à la fin. Il n’y a pas de problème de retrieval. Il y a un problème de context augmentation, et il se résout par un payload structuré passé au LLM à chaque étape.
Première décision d’architecture : retirer toute une couche que le modèle aurait construite sans broncher.
2. CDP screencast, pas noVNC
Section intitulée « 2. CDP screencast, pas noVNC »Pour l’UI web en direct, deux options viables sont apparues : streamer l’instance Chromium headless via CDP screencast, ou l’envelopper dans un serveur VNC et la servir via noVNC. Les deux fonctionnent. Le modèle a recommandé noVNC parce que la littérature sur laquelle il est entraîné le présente comme le standard.
En pratique, CDP screencast est plus léger, tourne dans le même process Playwright, et évite l’installation entière d’un serveur VNC dans l’image Docker. La voie noVNC aurait ajouté des pièces en mouvement dont personne n’a besoin une fois que Playwright expose déjà tout via CDP.
C’est le genre de décision qui prend trente secondes de jugement et que le modèle n’a aucun moyen de prendre seul. Il optimise pour la réponse moyenne de son jeu d’entraînement, pas pour l’architecture que vous êtes en train de construire aujourd’hui.
3. Une cascade à sept niveaux bat un matcher LLM unique
Section intitulée « 3. Une cascade à sept niveaux bat un matcher LLM unique »Plusieurs projets open source des douze derniers mois proposent de déléguer la génération de sélecteurs entièrement à un LLM à chaque interaction. Le modèle traite le DOM, choisit le sélecteur le plus stable, retourne le résultat. Élégant sur le papier.
DOMAutopsy utilise une approche différente : une cascade déterministe à sept niveaux dans un listener JavaScript de 372 lignes, le LLM n’intervenant qu’au nettoyage. Le tier 1 c’est data-testid, id, name. Le tier 7 c’est CSS court ou XPath texte. Le LLM ne voit jamais un sélecteur sauf si la cascade échoue ou produit des matchs ambigus.
La raison est simple. Un matcher purement LLM est non-déterministe, coûteux à l’échelle, et crée une dépendance dure à un tiers à chaque interaction. Une cascade statique est auditable, rejouable hors-ligne, et bon marché. Le LLM apporte de la valeur uniquement là où la logique déterministe cesse d’être efficace.
C’est une décision structurelle qu’aucun agent ne prendra à votre place, parce que tous les exemples qu’il a lus décrivent l’approche inverse.
4. Parser regex, pas parser AST, pour les scripts legacy
Section intitulée « 4. Parser regex, pas parser AST, pour les scripts legacy »DOMAutopsy peut faire du reverse engineering sur des scripts de test existants (Katalon, Playwright, Cypress, Selenium) pour les convertir en tâches structurées pour l’agent IA. La proposition du modèle était d’écrire un vrai parser AST par langage : Tree-sitter pour Groovy, ts-morph pour TypeScript, et ainsi de suite.
Pour environ 95 pour cent des scripts de test réels en production, regex suffit. Ils sont linéaires, mécaniquement générés, répétitifs. Le parsing AST aurait multiplié le coût d’implémentation par dix et déplacé la surface d’échec de “la regex rate un cas de syntaxe” à “le parser AST crashe sur un fichier legacy malformé”.
J’ai pris regex. J’ai aussi ajouté une note claire dans la documentation : ~95 pour cent de couverture, le reste passe en fallback manuel. Contrainte honnête, périmètre maîtrisable.
5. Pas de lock-in SaaS, même quand ça aurait été plus rapide
Section intitulée « 5. Pas de lock-in SaaS, même quand ça aurait été plus rapide »À un moment de la session, le modèle a proposé d’intégrer un service hébergé de diff de captures d’écran pour décharger le travail de comparaison visuelle. Cela aurait économisé un peu de temps d’implémentation.
OculiX et DOMAutopsy vivent tous les deux dans des environnements régulés. Banques, contractants défense, providers santé. Ajouter une dépendance SaaS tierce sans décision consciente fermerait des portes que je devrais ensuite forcer pour les rouvrir. J’ai refusé, le modèle a accepté, le diff de captures se fait localement.
C’est une décision non-technique habillée en décision technique. Le modèle ne sait pas qu’ajouter external-api.com au flux de données va doubler la longueur du dossier procurement pour un CISO en secteur régulé. Moi je le sais.
Ce que l’IA fait bien, et ce qu’elle ne fait pas
Section intitulée « Ce que l’IA fait bien, et ce qu’elle ne fait pas »En quatre heures, l’IA a produit du code propre, fonctionnel, majoritairement idiomatique. Le débit est réel. Le résultat n’est pas magique. C’est le produit d’un prompting structuré, d’un modèle mental clair côté architecte, et d’un flux continu de petits jugements qui ferment les mauvaises branches avant qu’elles ne grossissent.
La question intéressante n’est pas “l’IA peut-elle remplacer les architectes seniors”. C’est : quelles décisions allez-vous encore prendre vous-même, et lesquelles êtes-vous prêt à déléguer. Les cinq ci-dessus sont des décisions que je refuserais de déléguer même avec vingt ans d’expérience supplémentaires. Elles sont spécifiques au domaine, sensibles au contexte, et elles façonnent le reste du projet pendant des années.
Le reste, l’IA l’a livré.
—