Les IA abusent (un peu trop) avec le CSS

Le syndrome du code inutile

Le premier problème du CSS généré par les IA, c'est le volume. Pas la complexité, le volume. Quand vous demandez à un modèle de styliser un bouton, il ne vous donne pas les cinq propriétés pertinentes. Il vous donne vingt règles dont quinze redéfinissent des comportements déjà hérités, écrasent des valeurs qui n'avaient pas besoin d'être écrasées, ou déclarent explicitement ce que le navigateur applique de toute façon par défaut.

Ce comportement n'est pas un bug. C'est une conséquence directe de la façon dont ces modèles ont appris : en ingérant des millions de fichiers CSS de qualité très variable, souvent issus de projets anciens, de tutoriels approximatifs ou de bases de code mal entretenues. L'IA reproduit fidèlement les habitudes qu'elle a le plus observées, et ces habitudes sont rarement celles d'un développeur qui a les meilleures pratiques en tête.

Pourquoi l'IA crée des règles pour chaque élément

L'IA ne raisonne pas en termes de cascade ou d'héritage. Elle répond à une consigne localisée , "ce bouton doit avoir telle apparence" , sans intégrer le contexte global de votre feuille de styles. Résultat : elle génère des règles autonomes et autosuffisantes pour chaque composant, comme si chacun vivait dans le vide, sans parents, sans réinitialisation, sans thème global.

Un développeur expérimenté définit une règle à un niveau élevé et laisse la cascade faire le travail. L'IA définit la même règle à chaque niveau, pour être sûre. Ce n'est pas de la prudence, c'est du bruit. Et ce bruit rend la lecture du code fastidieuse, les modifications risquées, et la cohérence visuelle difficile à maintenir.

Ces propriétés redondantes qui alourdissent votre projet

Parmi les classiques que l'on retrouve systématiquement dans le CSS généré : box-sizing: border-box redéclaré sur chaque sélecteur alors qu'il est déjà défini globalement, display: block sur des éléments qui sont déjà des blocs par nature, ou encore margin: 0 et padding: 0 sur des éléments que personne n'avait touchés.

Ces propriétés ne cassent rien, mais elles polluent. Elles allongent les fichiers, elles ralentissent la lecture et elles brouillent les modifications ultérieures. Quand tout est déclaré partout, identifier ce qui est vraiment intentionnel devient un exercice de déduction.

L'IA ignore les variables CSS

Les custom properties CSS , les variables comme --color-primary ou --spacing-md , sont l'un des outils les plus puissants pour maintenir la cohérence d'un design system. Elles permettent de centraliser les valeurs qui se répètent et de les modifier depuis un seul endroit. L'IA les connaît. Elle ne les utilise quasiment jamais d'elle-même.

Par défaut, les modèles génèrent des valeurs hexadécimales codées en dur, des tailles en pixels absolus, des espacements arbitraires qui ne correspondent à aucun système cohérent. Si votre projet utilise déjà des variables CSS et que vous ne les mentionnez pas explicitement dans votre prompt, le code généré les ignorera complètement et introduira des doublons silencieux dans votre thème. Changer la couleur principale deviendra une opération chirurgicale à travers tout le fichier.

L'anarchie du z-index

Il existe un indicateur infaillible pour savoir si un fichier CSS a été généré ou mal maintenu : la présence de z-index: 9999. Ce chiffre est une capitulation. Il dit : "je ne comprends pas pourquoi mon élément passe derrière un autre, alors je mets une valeur assez grande pour être sûr". Les IA en abusent systématiquement, et elles nous ont transmis cette mauvaise habitude.

L'abus du z-index: 9999

Le z-index ne fonctionne pas globalement. Il s'applique à l'intérieur d'un contexte d'empilement, défini par certaines propriétés CSS comme position, opacity, transform ou isolation. Deux éléments dans des contextes différents ne se comparent pas directement, quelle que soit la valeur de leur z-index respectif.

Quand l'IA génère un z-index: 9999 sur une modale ou un tooltip, elle contourne le problème sans le résoudre. Le jour où un autre composant obtient lui aussi un z-index: 9999 , et ce jour arrive toujours , vous vous retrouvez avec deux éléments au même niveau et aucune logique pour décider lequel passe devant. Certains projets en arrivent à z-index: 99999, puis 999999. C'est une escalade sans fin.

L'IA ignore la structure des calques

La bonne façon de gérer les empilements, c'est de définir une échelle explicite dès le départ : les éléments de base à 1, les éléments flottants à 10, les menus déroulants à 20, les modales à 50, les notifications à 80. Ces valeurs peuvent même être stockées dans des variables CSS pour être centralisées. C'est simple, prévisible, maintenable.

L'IA ne fait pas ça. Elle génère chaque composant indépendamment, sans vision d'ensemble, et attribue des valeurs arbitraires qui ne s'inscrivent dans aucun système. Quand vous assemblez plusieurs composants générés séparément, les conflits d'empilement arrivent inévitablement. Et les corriger demande de comprendre une architecture que personne n'a jamais conçue.

L'enfer des positionnements arbitraires

Le positionnement CSS, c'est le domaine où l'IA révèle le plus clairement qu'elle produit du code qui marche sur son écran, pas du code qui tient la route dans un vrai projet. Les solutions générées sont souvent fonctionnelles pour un cas précis, dans des conditions précises, avec une taille de fenêtre précise. Changez une de ces conditions et tout se décale.

L'abus du positionnement absolu

Le positionnement absolu a sa place. Il est utile pour les overlays, les badges flottants, les éléments décoratifs qui doivent sortir du flux. Mais l'IA l'utilise comme outil universel, y compris là où flexbox ou grid seraient non seulement plus propres, mais plus robustes. Un élément positionné en absolu dans un conteneur de taille fixe se comporte correctement sur l'écran du développeur. Sur un mobile, dans un conteneur dynamique, ou après une modification du parent, il se retrouve au mauvais endroit.

Ce qui aggrave le problème, c'est que le positionnement absolu rend le code difficile à lire. Pour comprendre où se trouve un élément, il faut remonter jusqu'au premier ancêtre positionné, calculer l'offset, tenir compte des marges. C'est du CSS à déchiffrer plutôt qu'à lire.

L'IA préfère le calcul à la structure

Autre symptôme fréquent : l'utilisation de calc() pour compenser des décalages qui n'auraient pas dû exister. On voit régulièrement des constructions comme left: calc(50% - 120px) ou margin-top: calc(var(--header-height) + 16px) là où un conteneur flex avec justify-content: center ou un simple padding-top sur le bon élément aurait tout résolu.

Ces calculs fonctionnent, mais ils créent des dépendances fragiles. Si la hauteur du header change, si le conteneur parent est modifié, si la valeur de référence évolue, le calcul devient faux. Un layout fondé sur la structure du document est résilient par nature. Un layout fondé sur des calculs compensatoires est résilient jusqu'à la prochaine modification.

Le cadeau empoisonné du code généré

Le code CSS généré par une IA donne l'illusion d'un gain de temps. Et sur le court terme, c'en est un : en quelques secondes, vous avez un composant qui s'affiche correctement. Le problème n'apparaît pas immédiatement. Il s'accumule, silencieusement, à chaque composant ajouté, à chaque modification, à chaque fois qu'un développeur doit comprendre ce que le précédent a fait.

Pourquoi corriger un "brouillon" prend plus de temps que coder

Il existe un phénomène bien connu dans le monde du développement : il est souvent plus rapide d'écrire quelque chose from scratch que de corriger un code existant mal structuré. Lire du code prend du temps. Identifier ce qui est intentionnel et ce qui est accidentel ou comprendre des intentions qui n'ont jamais été explicitées aussi. Le CSS généré par l'IA cumule tous ces problèmes.

Vous héritez d'un code qui fonctionne, certes, mais que vous n'avez pas écrit, que vous ne comprenez pas entièrement, et que vous n'osez pas modifier sans risquer de casser quelque chose. C'est exactement la définition de la dette technique : du code dont le coût de possession augmente avec le temps, indépendamment de sa qualité apparente au moment de sa création.

Quand la maintenance se complique

Imaginez six mois après le lancement. Vous devez changer la couleur principale de votre interface. Dans un projet sain, vous modifiez une variable CSS et tout se met à jour. Dans un projet dont le CSS a été généré par accumulation, vous trouvez la même valeur hexadécimale à quarante endroits différents, parfois dans des formes légèrement différentes, parfois mélangée avec des opacités codées en dur. Chaque modification devient une opération à risque.

Le problème est encore plus flagrant quand plusieurs personnes travaillent sur le même projet. Un développeur qui reprend du code CSS généré sans documentation n'a aucun moyen de distinguer ce qui est structurant de ce qui est accidentel. Il va, lui aussi, ajouter des règles pour compenser, empiler les correctifs, et aggraver progressivement ce que le prochain développeur devra démêler.

Comment reprendre la main ?

Rien de tout cela ne signifie qu'il faut abandonner l'IA pour écrire du CSS. Ces outils ont un réel intérêt pour accélérer certaines tâches répétitives, explorer des approches ou générer une base de travail. Mais l'utiliser correctement demande de changer la façon dont on perçoit son output : non pas comme un livrable, mais comme un brouillon.

Le code généré n'est qu'un brouillon

Le changement de posture est simple à formuler et difficile à tenir sous la pression du temps : tout code CSS généré par une IA doit être lu, compris et validé avant d'être intégré. Pas survolé. Pas copié-collé parce que "ça marche dans l'aperçu". Lu ligne par ligne, avec la question systématique : est-ce que cette règle est nécessaire, et est-ce qu'elle s'intègre dans l'architecture existante ?

Cette étape de relecture a un coût immédiat, mais elle en évite un beaucoup plus élevé plus tard. Elle oblige aussi à mieux comprendre ce que l'on intègre, ce qui est la seule façon de rester maître de son propre code sur le long terme. Un développeur qui ne comprend pas son CSS ne peut pas le faire évoluer sereinement.

Apprendre à brider l'IA avec des prompts minimalistes

Le comportement de l'IA est en grande partie conditionné par la façon dont vous la sollicitez. Un prompt vague comme "génère le CSS pour une carte produit" produira un bloc autonome et surchargé. Un prompt précis comme "génère uniquement les propriétés spécifiques à ce composant, en utilisant les variables --color-primary et --spacing-md déjà définies, sans redéclarer les propriétés héritées du reset" produira quelque chose de beaucoup plus utilisable.

Plus vous donnez de contexte , votre architecture existante, vos conventions de nommage, vos variables, votre système de z-index , moins l'IA aura à inventer. Et moins elle inventera, moins vous aurez à nettoyer. C'est un investissement dans la qualité du prompt qui se rembourse à chaque composant généré.

Nettoyer son code

Si vous avez déjà un projet avec du CSS généré accumulé, un audit est souvent la première étape utile. L'objectif n'est pas de tout réécrire d'un coup , c'est rarement possible , mais d'identifier les sources de friction : les valeurs dupliquées qui mériteraient d'être des variables, les z-index anarchiques qui devraient être rationalisés, les positionnements absolus qui pourraient être remplacés par du flexbox.

Des outils comme PurgeCSS peuvent aider à supprimer les règles non utilisées. Un linter CSS comme Stylelint peut en détecter d'autres automatiquement. Mais aucun outil ne remplace la lecture humaine pour distinguer ce qui est superflu de ce qui est intentionnel. Le nettoyage est un travail artisanal, et c'est normal : il s'agit de redonner du sens à un code qui en manquait.

L'IA est un outil de travail, pas un collègue senior. Elle n'a pas de vision d'ensemble de votre projet, pas de souci de maintenabilité, pas de sensibilité à la dette technique. Elle répond à la consigne du moment. La responsabilité de ce qui entre dans votre codebase reste la vôtre, que le code ait été écrit par vous ou généré par un modèle. Et un CSS bien structuré, c'est un projet qu'on modifie sans angoisse.