Top 10 des erreurs de l'IA dans le développement Web

Philip Walton

Date de publication : 11 novembre 2026

Cette semaine, nous avons lancé la version 1.0 de Modern Web Guidance, un ensemble de compétences qui intègrent l'expertise de la plate-forme Web, les bonnes pratiques et les données de compatibilité des navigateurs directement dans vos agents de codage. Avec Modern Web Guidance, notre objectif est d'aider les développeurs qui utilisent des agents de codage IA à exploiter pleinement la puissance et les capacités de la plate-forme Web moderne, et ainsi à améliorer l'expérience Web des utilisateurs.

Depuis que nous avons lancé la preview anticipée de Modern Web Guidance en mai, les agents de codage se sont améliorés, et de nombreux modèles de frontière incroyables ont été publiés. L'une des questions qui revient le plus souvent est la suivante : ces nouveaux modèles de frontière ne suivent-ils pas déjà les bonnes pratiques de développement Web ?

Malheureusement, la réponse est non, et nous le savons, car nous avons testé cette hypothèse.

Chaque guide de Modern Web Guidance définit un ensemble d'attentes qui doivent être satisfaites si les bonnes pratiques du guide ont été correctement suivies. Notre suite d'évaluation teste ensuite ces guides en envoyant le même prompt à un agent exécuté avec Modern Web Guidance (l'agent guidé) et à un autre agent exécuté sans Modern Web Guidance (l'agent non guidé). Le résultat des deux exécutions est comparé aux attentes définies par le guide.

En comparant les taux de réussite guidés et non guidés, vous pouvez constater que les modèles d'IA, même les modèles de frontière les plus récents, ne suivent pas de manière fiable les bonnes pratiques de développement Web moderne par eux-mêmes.

En moyenne, les agents de codage non guidés ne réussissent qu'environ 50 % des vérifications de notre suite d'évaluation, contre environ 90 % lorsque Modern Web Guidance est utilisé.

Vous pouvez consulter notre tableau de bord d'évaluation pour voir la liste complète des vérifications spécifiques que nous effectuons pour chaque guide, ainsi que le score de chaque modèle.

Pour vous donner un aperçu général, cet article aborde 10 des domaines les plus problématiques dans lesquels les modèles d'IA se trompent systématiquement, dans des disciplines clés que les développeurs Web sont les plus susceptibles de rencontrer dans leur travail quotidien, comme l'accessibilité, l'expérience utilisateur, les performances et la sécurité.

1. Accessibilité : gestion du focus clavier et de inert

Pour les personnes qui naviguent à l'aide d'un clavier ou d'un lecteur d'écran, un ordre de sélection prévisible est ce qui rend les UI interactives utilisables. Sans cela, le curseur peut se déplacer vers du contenu masqué en arrière-plan ou se retrouver bloqué dans des dizaines de taquets de tabulation supplémentaires.

La gestion du focus et de inert est l'une des plus grandes lacunes en matière d'accessibilité dans nos évaluations, et l'un des domaines qui s'améliore le plus avec Modern Web Guidance. Voici les erreurs les plus courantes :

• Ne pas déplacer le curseur vers les vues nouvellement ouvertes et oublier de le replacer sur l'élément déclencheur lors du retour en arrière.
• S'appuyer sur des pièges de tabulation JavaScript manuels et aria-modal="true" sur des fenêtres modales personnalisées, au lieu d'utiliser une fenêtre modale <dialog> ou de marquer le contenu d'arrière-plan inert.
• Exposer chaque élément d'une barre d'outils ou d'une grille directionnelle en tant que point d'arrêt de tabulation distinct au lieu d'utiliser un seul point d'arrêt de tabulation avec un tabindex itinérant.
• Créer des contours :focus-visible personnalisés qui n'ont pas un rapport de contraste de 3:1 par rapport aux arrière-plans adjacents.

2. Accessibilité : prise en charge des mouvements réduits

Les mouvements de page inattendus et les animations à grande échelle ne sont pas seulement gênants. Pour les utilisateurs souffrant de troubles vestibulaires ou de sensibilité au mouvement, ils peuvent provoquer des vertiges, des nausées ou des maux de tête.

Les modèles d'IA n'oublient généralement pas de vérifier prefers-reduced-motion lorsqu'ils ajoutent des transitions CSS standards ou des animations d'images clés. Cependant, lorsqu'ils utilisent des fonctionnalités plus récentes telles que le défilement fluide, les transitions de vue ou les animations basées sur le défilement, ils oublient souvent l'animation réduite ou font des erreurs lors de son implémentation :

• Définir scroll-behavior:smooth de manière globale et inconditionnelle sur l'élément racine.
• Utilisation d'animations CSS liées au défilement sans vérification de la réduction des animations.
• Supprimer les durées transition sur les éléments du carrousel pour réduire les mouvements lors du défilement, mais oublier de supprimer également les propriétés de transformation, ce qui entraîne un changement de taille des éléments lors du défilement.
• Application d'une réinitialisation générale de la durée 0.01ms sur *, *::before et *::after lorsque l'option "Réduire les animations" est activée, ce qui supprime également toutes les transitions essentielles sans mouvement (nécessaires pour communiquer les changements d'état de l'UI).
• Activer les transitions de vue entre documents de manière inconditionnelle et ignorer les animations ::view-transition-* lorsque l'option "Réduire les animations" est activée, plutôt que de simplement limiter la règle @view-transition derrière une vérification de l'option "Réduire les animations".

3. Accessibilité : validation des formulaires, indications de format et états de saisie automatique

Les formulaires sont un élément essentiel de la plupart des critical user journeys sur le Web. Un problème mineur dans un formulaire de paiement peut avoir un impact majeur sur les résultats d'une entreprise.

Lors de la création de formulaires, les modèles d'IA maîtrisent de nombreux principes de base. Cependant, ils échouent souvent sur des détails mineurs, mais essentiels, tels que les erreurs de validation, l'emplacement approprié des espaces réservés et des indications de format, et l'intégration correcte avec les gestionnaires de mots de passe et les fonctionnalités de saisie automatique :

• Réimplémenter la validation CSS :user-invalid avec une validation JavaScript blur personnalisée, qui signale souvent les champs required non modifiés dès que les utilisateurs passent à l'onglet suivant.
• Laisser aria-invalid se désynchroniser des erreurs visibles, soit en définissant aria-invalid="true" prématurément sur blur, soit en appliquant un style à :user-invalid en CSS sans synchroniser aria-invalid en JavaScript.
• S'appuyer sur du texte placeholder qui disparaît pour afficher les formats requis (comme MM/YY sur un champ de saisie de date d'expiration de carte) au lieu d'afficher une indication persistante associée à aria-describedby.
• Placer les indications de format et les règles de mot de passe sous le champ <input> (au lieu de les placer au-dessus), où elles peuvent être masquées par les claviers mobiles et les fenêtres pop-up de saisie automatique au moment où l'utilisateur doit les lire.
• Mettre en surbrillance les entrées :autofill en modifiant uniquement la couleur de la bordure au lieu d'associer la couleur à un repère non coloré qui ne modifie pas la mise en page (comme un box-shadow en incrustation).

4. Expérience utilisateur : gestes de balayage et de toucher

Les agents sont capables d'implémenter des gestes tactiles à l'aide de JavaScript impératif et d'écrire leur propre logique physique personnalisée. Ces implémentations fonctionnent. Toutefois, les interactions tactiles basées sur JavaScript sont rarement aussi fluides que celles des applications natives.

Bon nombre de ces interactions peuvent être implémentées avec des API CSS et de défilement natives, ce qui permet au navigateur d'exécuter la physique des gestes en dehors du thread principal. Pourtant, lors de nos évaluations, les modèles d'IA négligent souvent ces caractéristiques :

• Implémenter des gestes de balayage pour ignorer ou afficher avec des écouteurs pointermove ou touchmove au lieu d'utiliser le défilement scroll-snap CSS.
• Omission de overscroll-behavior-x:none sur les interfaces de balayage d'onglets, ce qui peut déclencher accidentellement une navigation vers l'arrière ou vers l'avant dans le navigateur lors d'un balayage excessif.
• Générer des effets de progression de balayage sur le thread principal dans les rappels JavaScript au lieu d'utiliser des animations basées sur le défilement.
• Le focus clavier n'est pas correctement pris en charge sur les panneaux d'action de balayage basés sur le défilement.

5. Expérience utilisateur : boîtes de dialogue, popovers et transitions de la couche supérieure

Dans nos évaluations, les modèles ont souvent recours à des solutions de contournement JavaScript impératives pour animer, fermer ou contenir le défilement autour des boîtes de dialogue modales et des popovers.

Au lieu de s'appuyer sur les fonctionnalités HTML et CSS modernes conçues pour les superpositions de la couche supérieure, les agents créent souvent manuellement des machines d'état d'entrée et de sortie, des hooks d'historique et des verrous de défilement du corps, qui sont plus difficiles à gérer et sujets à des bugs d'UI subtils.

Lorsque vous réussissez ces interactions, vous pouvez transformer une expérience fragile en une expérience soignée à laquelle les utilisateurs font confiance. Voici les erreurs les plus courantes que nous constatons :

• Créer des superpositions position:fixed personnalisées avec des gestionnaires de clics extérieurs manuels pour la fermeture par clic extérieur, au lieu d'utiliser simplement popover.
• Créer des animations d'entrée et de sortie en activant/désactivant les classes de transition CSS et en les coordonnant avec les écouteurs requestAnimationFrame() et transitionend (avec des solutions de remplacement setTimeout()), au lieu de le faire en CSS pur avec @starting-style et transition-behavior.
• Verrouiller le défilement de la page derrière une fenêtre modale ouverte en définissant overflow:hidden sur <html> au lieu d'utiliser un élément <dialog> pour contenir le défilement hors limites.
• Ajout d'écouteurs popstate pour détecter les gestes de retour Android et fermer les fenêtres modales ouvertes, plutôt que d'utiliser la fonctionnalité de fermeture native du bouton Retour d'un élément modal <dialog>.

6. Expérience utilisateur : mode sombre et commandes adaptées au thème

Les utilisateurs activent le mode sombre pour réduire la fatigue oculaire et l'éblouissement. Un flash blanc vif lors du chargement de page, des commandes de formulaire sans thème ou un bouton d'activation/désactivation qui ne se synchronise pas avec les préférences de l'OS nuisent donc immédiatement à l'expérience.

Un bouton d'activation/de désactivation du mode sombre peut sembler simple, mais les modèles non guidés de nos évaluations passent systématiquement à côté des détails clés de la plate-forme nécessaires pour que le changement de thème et les commandes de formulaire natives fonctionnent correctement :

• <meta name="color-scheme" content="light dark"> manquant dans <head>, ce qui entraîne l'affichage d'un flash blanc pour les utilisateurs du mode sombre pendant le chargement des feuilles de style externes.
• Styliser des thèmes sombres ou des composants à surface sombre avec des couleurs personnalisées sans définir color-scheme, ce qui laisse les barres de défilement et les commandes de formulaire natives bloquées en mode clair.
• Oublier la fonction CSS light-dark() lors de la définition de jetons de couleur adaptatifs au thème qui suivent automatiquement le color-scheme actif.
• Fournir uniquement un bouton binaire clair ou sombre qui définit un remplacement explicite dans localStorage, sans possibilité de revenir à la valeur par défaut de l'OS.
• Oublier d'ajouter un écouteur d'événements storage, ce qui empêche la synchronisation des autres onglets ouverts lorsque l'utilisateur change de thème.

7. Performances : réactivité et fluidité de l'exécution

Les utilisateurs passent la majeure partie de leur temps sur une page Web une fois qu'elle a fini de se charger. Par conséquent, des interactions lentes et des transitions saccadées peuvent nuire à l'expérience utilisateur tout autant qu'un chargement initial lent.

Dans nos évaluations, les modèles suivent généralement les bonnes pratiques classiques de temps de chargement qui sont promues dans des outils comme Lighthouse depuis des années, et ils savent généralement décharger les boucles lourdes évidentes vers un Web Worker. En revanche, ils ont souvent du mal à optimiser la réactivité du thread principal, qui est essentielle pour optimiser l'INP : isoler le travail de mise en page, planifier les tâches par priorité et exploiter les nouvelles fonctionnalités HTML et CSS qui effectuent le rendu en dehors du thread principal.

Par exemple, nous voyons souvent des agents :

• Créer des files d'attente setTimeout() personnalisées pour les tâches en arrière-plan ou de faible priorité au lieu de prioriser les tâches visibles par l'utilisateur avec scheduler.postTask() ou de profiter de la continuation des tâches avec scheduler.yield() lorsque le navigateur le permet.
• Création de mises en page complexes (comme des grilles de données denses) sans appliquer content-visibility:auto et contain-intrinsic-size, ce qui signifie que les mises à jour après les interactions de l'utilisateur déclenchent un réajustement de la page entière.
• Masquer les vues SPA inactives avec display:none (ou les supprimer) au lieu d'utiliser content-visibility:hidden (associé à inert). La première option détruit l'état de rendu mis en cache. Par conséquent, le retour à l'état précédent déclenche une mise en page et un rendu complets.
• Mettre en pause les animations <canvas> hors écran et les boucles en arrière-plan avec des rappels Intersection Observer plutôt que d'associer content-visibility:auto à l'événement contentvisibilityautostatechange (le cas échéant), ce qui entraîne l'absence de la marge de prérendu du navigateur avant que les éléments ne défilent dans la vue.
• Créer des indices d'UI d'affordance de défilement à l'aide d'écouteurs d'événements scroll qui forcent des calculs de mise en page continus, plutôt que d'utiliser des requêtes d'état de défilement CSS lorsqu'elles sont disponibles (avec des solutions de remplacement Intersection Observer).

8. Performances : décalages de mise en page et scintillement visuel

Les changements de mise en page inattendus perturbent la concentration du lecteur et peuvent l'amener à cliquer sur des boutons inattendus, parfois avec des conséquences irréversibles.

Les modèles ajoutent de manière fiable les attributs width et height aux éléments <img> standards pour éviter les décalages de mise en page, mais ils ne détectent pas d'autres sources courantes de décalages de mise en page et de flashs de pré-affichage provenant d'éléments <video>, de changements de polices Web, de barres d'outils de navigateur mobile et de tests côté client, qui peuvent tous avoir un impact sur le CLS.

• Omission des attributs width et height explicites sur les éléments <video> (les lecteurs non chargés sont donc définis par défaut sur 300×150 et décalent la mise en page une fois les métadonnées chargées) ou application d'un style aux éléments de wrapper multimédia au lieu de définir aspect-ratio et object-fit directement sur les éléments multimédias.
• Associer des polices Web à des polices système de remplacement sans font-size-adjust, ce qui entraîne un réajustement visible des paragraphes et des titres lorsque les polices Web sont échangées.
• Dimensionnement des sections principales et des mises en page plein écran avec des unités vh statiques au lieu d'unités de fenêtre d'affichage dynamiques ou petites (dvh, svh), ce qui entraîne un saut de contenu lorsque les barres d'outils du navigateur mobile s'agrandissent et se rétractent.
• Masquer du contenu avec d'anciens extraits anti-clignotement opacity:0 ou visibility:hidden et des délais d'expiration de plusieurs secondes pour les tests A/B côté client (retardant le LCP et laissant les éléments invisibles cliquables), au lieu d'utiliser des scripts avec blocking="render" lorsqu'ils sont disponibles.
• Déclenchement des transitions de vue entre documents avant l'analyse du balisage critique au-dessus de la ligne de flottaison au lieu de conserver le premier rendu avec rel="expect" et blocking="render", ce qui entraîne l'apparition d'éléments à moitié analysés au milieu de la transition.

9. Sécurité : défenses contre les attaques XSS basées sur le DOM et nettoyage du code HTML

Une seule faille de script intersites (XSS) permet à un pirate informatique d'exécuter du code arbitraire dans le navigateur de vos utilisateurs, de voler des données de session ou d'effectuer des actions en leur nom. C'est pourquoi les défenses appliquées par le navigateur, comme la désinfection HTML sécurisée, les Trusted Types et les CSP strictes, sont si importantes.

Les modèles répondent rarement à ces problèmes de sécurité de manière proactive. Par exemple, pour toutes les tâches de notre suite d'évaluation complète, les modèles n'ont pas ajouté d'en-tête Content Security Policy (CSP) ou d'isolation multi-origine sans requête explicite.

Même lorsque les prompts demandent directement la sécurité, les modèles non guidés continuent d'échouer à plus de la moitié de nos contrôles de sécurité, en recourant à des solutions de remplacement personnalisées fragiles ou à des règles incomplètes. Cela est évident lorsque vous vous défendez contre les attaques XSS basées sur le DOM :

• Écrire des nettoyeurs de liste d'autorisation DOMParser personnalisés (soit comme solution de secours setHTML(), soit dans une règle Trusted Types) au lieu d'utiliser une bibliothèque validée comme DOMPurify lorsque le nettoyage natif n'est pas disponible.
• Regrouper DOMPurify de manière hâtive à chaque chargement de page au lieu d'utiliser setHTML() natif lorsqu'il est compatible et de charger DOMPurify de manière différée uniquement en tant que solution de secours.
• Enregistrement de règles de types de confiance permissives (input) => input qui nuisent à l'application des récepteurs.
• Associer des types de confiance sur des pages statiques à des CSP script-src 'self' avec liste d'autorisation d'hôtes au lieu de verrouiller les scripts intégrés avec des hachages SHA-256.
• Omission de 'strict-dynamic' et 'report-sample' lors de la configuration des Content Security Policies script-src basées sur un nonce.

10. Sécurité : connexion par clé d'accès, réauthentification et cycle de vie des identifiants

Les clés d'accès améliorent la sécurité des utilisateurs et les conversions de connexion pour les entreprises, mais leur implémentation (même avec l'aide d'agents) est difficile.

WebAuthn dispose d'API spécifiques de sérialisation, de détection des capacités et de signalement que les modèles non guidés ne détectent presque jamais dans nos évaluations. Si vous demandez à un modèle d'IA d'ajouter la connexion par clé d'accès, la gestion ou la réauthentification renforcée, il écrit souvent des assistants d'encodage d'octets manuels, ignore les vérifications de fonctionnalités sur l'UI de gestion ou ne synchronise pas les identifiants avec les gestionnaires de mots de passe :

• Créer manuellement des fonctions d'assistance pour la conversion Base64URL atob() et btoa() (soit comme chemin principal, soit comme code récurrent de remplacement redondant) au lieu de s'appuyer sur des méthodes de sérialisation intégrées telles que parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() et credential.toJSON().
• Omission de PublicKeyCredential.signalUnknownCredential() lors de la connexion lorsque le serveur signale un ID d'identifiant inconnu, laissant des clés d'accès supprimées ou révoquées dans les gestionnaires de mots de passe des utilisateurs.
• Ignorer PublicKeyCredential.getClientCapabilities() avant d'afficher l'UI de création et de gestion des clés d'accès.
• Omission d'un AbortController et d'un AbortSignal lors du démarrage des requêtes de réauthentification par clé d'accès renforcée.
• Transmettre l'option d'essai Origin Trial mediation:"immediate" au lieu de uiMode:"immediate" pour les invites de connexion simplifiées.

Combler ces lacunes

Ces 10 domaines sont loin de constituer une liste exhaustive, et nous nous attendons à ce que les lacunes spécifiques évoluent au fil du temps. Les modèles rattraperont leur retard et la plate-forme Web continuera d'évoluer.

La bonne nouvelle, c'est que Modern Web Guidance comble toutes ces lacunes et continuera d'évoluer en même temps que la plate-forme.

Pour commencer à utiliser Modern Web Guidance, exécutez la commande suivante ou recherchez-le dans la place de marché des plug-ins de votre agent :

npx modern-web-guidance@latest install

Avez-vous vu des modèles se tromper sur d'autres tâches de développement Web ? Merci de nous le signaler. Signalez un problème dans le dépôt GitHub Modern Web Guidance ou aidez-nous à combler ces lacunes pour d'autres développeurs en contribuant au projet.