L’article relate une expérience où des agents d’IA chargés de refondre une architecture logicielle ont involontairement effacé des mois de savoir-faire intégré dans le code, sans enfreindre aucune règle formelle. Les régressions apparues ensuite ont révélé que ces outils, bien que produisant un code propre et conforme aux patterns, avaient ignoré des ajustements empiriques cruciaux, non documentés et non testés, car sans valeur apparente pour un algorithme. Leur comportement par défaut, sans garde-fous explicites, a ainsi détruit une connaissance implicite accumulée sur des années.
Pour éviter de reproduire cette situation, l’équipe a restructuré son approche en s’appuyant sur des contraintes techniques strictes, notamment via ESLint, seul outil capable de bloquer efficacement les agents. L’architecture du nouveau dépôt a été repensée non pour son élégance conceptuelle, mais pour imposer des règles d’import et de modularité que les IA ne peuvent contourner, transformant ainsi des recommandations en obligations incontournables.
L’expérience illustre les limites des agents de codage en production : leur efficacité dépend entièrement des contraintes qu’on leur impose, et leur manque de compréhension contextuelle les rend incapables d’intégrer des savoirs informels. La solution retenue repose donc sur une délégation encadrée, où la qualité du code est garantie par des mécanismes automatiques plutôt que par une revue humaine systématique.
L’article explique comment détecter les régressions visuelles dans une CI en utilisant Playwright et Docker. L’idée principale est d’intégrer des tests de capture d’écran pour comparer l’apparence actuelle d’une page avec une référence, afin d’éviter des modifications CSS non détectées avant la mise en production. Playwright propose l’assertion toHaveScreenshot() qui compare les images et échoue si la différence dépasse un seuil configuré.
La mise en œuvre repose sur des tests simples couvrant les pages clés du site, mais nécessite un environnement déterministe pour éviter les faux positifs. L’équipe a dû éliminer les sources de variation, comme les images en lazy loading ou les polices web, en attendant que la page soit visuellement stable avant de capturer l’écran. Un helper stabilize() est utilisé pour attendre la fin du chargement des ressources et des polices.
Enfin, la solution est intégrée dans une CI via Docker pour garantir un rendu cohérent entre les machines, et les images de différence sont postées directement dans les commentaires des pull requests pour faciliter le diagnostic des régressions.
Tout est dans le titre
Un outil pour tester les régressions dans le code CSS