JavaScript : chapitre 2 | Mise en pratique de l’axe 1 : générer, tester, et insérer du JavaScript avec l’aide d’une IA

Mise en contexte

Rappel de l’Axe 1, tel que défini dans la conclusion du chapitre 1 : le concepteur designer n’a pas besoin de savoir écrire du JavaScript à la main — il doit savoir faire générer un script par une IA, le tester, savoir où l’insérer dans un site réel, et surtout, ne jamais considérer le travail terminé sans être passé par un réflexe de sécurité et une conscience du poids ajouté à la page.

Ce chapitre vous propose 5 pistes différentes, chacune illustrant un effet concret qu’on peut ajouter à un site avec un peu de JavaScript généré par IA. Vous allez traiter les 5 — l’objectif est de répéter la méthode sur des cas variés, pas de n’en tester qu’un seul.

Co-construction, pas vibe coding

Il y a une différence essentielle entre demander directement du code à une IA (ce qu’on appelle parfois le « vibe coding » — on colle un résultat sans vraiment comprendre comment il fonctionne) et co-construire ce code avec elle.

Vous n’êtes pas développeur, et vous n’avez aucune raison de connaître le nom technique de la fonctionnalité qui permettra de réaliser l’effet souhaité. Ce n’est pas votre rôle. Mais cela ne vous exonère pas de garder la main sur le processus de co-construction ! Votre rôle est de décrire le besoin, en langage courant — exactement comme vous le feriez à l’oral avec un développeur. C’est ensuite à l’IA de :

reformuler et expliquer, elle aussi en langage courant, comment elle compte s’y prendre — avant de produire la moindre ligne de code
vous poser des questions si votre demande manque de précision

C’est cet échange — votre besoin, reformulé et expliqué par l’IA, éventuellement précisé par un aller-retour de questions — qui constitue le véritable prompt final, pas la première phrase que vous avez tapée.

Le squelette de prompt à utiliser pour chacune des 5 pistes

Je voudrais [décrivez ici le besoin, en langage courant, sans terme technique]. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non.

C’est quoi le CSP, et pourquoi ça bloque parfois tout ? Le CSP (Content Security Policy) est une règle de sécurité que certains sites activent pour se protéger contre l’injection de code malveillant — un peu comme un videur à l’entrée d’une salle, qui refuse tout ce qui n’est pas sur la liste autorisée. Concrètement, ça veut dire que sur certains sites (Wikipédia, par exemple), un script collé manuellement dans la console peut être purement et simplement ignoré par le navigateur, sans que rien ne se passe et parfois sans même de message d’erreur explicite. Ce n’est donc pas forcément votre script qui est en cause : c’est le site testé qui refuse de l’exécuter. C’est pour cette raison qu’on le précise dès le prompt : ça permet à l’IA d’anticiper cette limite, et de vous expliquer comment la contourner ou la tester malgré tout.

Les quelques mots-clés de fin (sécurisé, élégant, performant, pertinent) sont volontairement simples à comprendre, sans connaissance technique — mais ils orientent fortement la qualité de ce que l’IA va produire, sans que vous ayez besoin de juger vous-même la qualité du code.

La méthode commune, pour chacune des 5 pistes

1. Décrire le besoin à une IA, avec le squelette de prompt ci-dessus, et échanger avec elle jusqu’à obtenir une explication claire de ce qu’elle compte faire, avant tout code.
2. Tester le résultat via les DevTools — copiez le code généré directement dans l’onglet Console de votre navigateur (revoir le chapitre dédié aux DevTools si besoin), sur une vraie page web, pour observer si l’effet fonctionne réellement avant même de l’insérer où que ce soit.

Avant même de coller quoi que ce soit : la plupart des navigateurs bloquent par défaut le collage de code dans la console, par sécurité. Un message vous invite à taper une phrase de confirmation (souvent « allow pasting ») avant de pouvoir coller quoi que ce soit. Si rien ne se passe après un collage, vérifiez d’abord ce point, avant de chercher une autre explication.

Nous vous invitons à tester votre injection console en utilisant un article Wikipédia — ce site est à la fois représentatif d’un vrai contenu structuré (texte, titres, images) et compatible avec la plupart des scripts, ce qui en fait un bon terrain d’essai par défaut pour chacune des 5 pistes.

Juste après avoir collé un script : regardez toujours ce qui s’affiche immédiatement en dessous dans la console — s’il y a un message d’erreur, il apparaît à cet endroit précis. Avant de retourner voir l’IA, prenez le temps de le lire vous-même : le message est parfois suffisamment clair pour comprendre seul ce qui ne va pas (une faute de frappe dans le nom d’un élément, par exemple), ou au moins pour repérer la ligne concernée. Ce n’est qu’ensuite, si le message reste incompréhensible, qu’il faut le transmettre à l’IA.

Note importante sur le test en console : si rien ne se passe lors du test, ce n’est pas forcément une erreur dans le script. Certains sites (Wikipédia, par exemple) utilisent un cadre de sécurité strict appelé CSP (Content Security Policy), qui bloque volontairement l’exécution de scripts collés manuellement dans la console — pour des raisons de sécurité, justement. Si un test échoue sur un site précis, essayez-le sur un autre site avant de conclure que le script est mauvais.

Le protocole à suivre si vous n’obtenez pas de résultat, pour chacune des 5 pistes :

Vérifiez d’abord si l’onglet Console affiche un message d’erreur — c’est souvent la première information utile
Précisez à l’IA sur quel site précis vous avez fait le test
Expliquez-lui le problème rencontré, avec le message d’erreur si vous en avez un
Continuez la conversation avec elle jusqu’à obtenir un résultat qui fonctionne réellement — ne restez jamais bloqué sur un premier essai infructueux sans revenir vers l’IA pour ajuster

Un autre cas de figure, différent d’une erreur technique : le code fonctionne, mais il ne fait pas ce que vous avez demandé. Dans ce cas, un message générique à réutiliser à chaque fois :

Ton code ne respecte pas mon prompt ! Voici précisément ce qui n’a pas été respecté : [décrivez ici, en langage naturel, l’écart entre ce que vous vouliez et ce que vous avez obtenu].

Soyez aussi précis que possible dans la description de l’écart — plus votre explication est claire, plus l’IA pourra corriger exactement le bon point, sans repartir de zéro.

3. Analyser le résultat — est-ce que ça fonctionne comme attendu ? Est-ce que l’IA a pensé à un cas limite que vous n’aviez pas précisé ? Et surtout : posez systématiquement les deux questions de clôture de l’Axe 1 — ce script pose-t-il un problème de sécurité (peut-il être détourné, expose-t-il une donnée sensible), et quel est son poids réel sur la page ?

Une fois ces 3 étapes passées, et si le résultat vous intéresse : ce code pourrait être transformé en véritable plugin WordPress, installable en un clic sur n’importe quel site — un sujet qui sera traité dans un chapitre ultérieur. Pour l’instant, l’objectif de cet exercice s’arrête à la génération, au test, et à l’analyse.

Les 5 pistes

Piste 1 — Infobulle de partage sur sélection de texte

Le parcours, en langage naturel : le visiteur lit un article, et sélectionne un passage de texte avec sa souris (comme sur Medium.com). Une petite bulle apparaît aussitôt, juste au-dessus de la sélection, avec un bouton pour copier ce passage. Le visiteur clique dessus : le texte, accompagné du lien de la page, est copié dans son presse-papier. Une pop-up de confirmation s’affiche alors immédiatement, sans qu’il ait besoin de cliquer sur quoi que ce soit pour la faire apparaître, avec le message « Voici le contenu qui a été copié » et le texte copié affiché dedans. Elle reste visible tant que le visiteur ne clique pas sur sa croix de fermeture — il n’y a pas de disparition automatique après quelques secondes.

Je voudrais que, quand quelqu’un sélectionne un passage de texte avec la souris sur mon site (sur ordinateur uniquement, pas sur mobile), une petite bulle apparaisse juste au-dessus de ce texte, avec un bouton pour copier ce passage accompagné du lien de ma page — un peu comme sur Medium.com. Dès que la copie est effectuée, une pop-up de confirmation doit s’afficher automatiquement et immédiatement, sans que je n’aie besoin de cliquer sur quoi que ce soit pour la faire apparaître — elle ne doit pas être une simple notification cliquable qu’il faudrait ouvrir soi-même. Cette pop-up doit contenir le texte « Voici le contenu qui a été copié » suivi du texte réellement copié, ainsi qu’une croix (X) permettant de la fermer manuellement — c’est uniquement ce clic sur la croix qui doit la faire disparaître, pas un délai automatique. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non.

Points à vérifier lors de l’analyse : le script s’active-t-il bien uniquement sur ordinateur ? La bulle se positionne-t-elle correctement même si on sélectionne du texte tout en bas ou tout en haut de l’écran ? La pop-up de confirmation s’affiche-t-elle bien automatiquement après chaque copie, sans qu’il faille cliquer sur une notification pour l’ouvrir ? Se ferme-t-elle bien uniquement au clic sur sa croix, sans disparaître toute seule ? Si le test échoue sur un site précis, avez-vous pensé à vérifier s’il s’agit d’un vrai bug ou d’un blocage CSP du site lui-même ?

Piste 2 — Temps de lecture restant, en direct

Le parcours, en langage naturel : le visiteur arrive sur un article. Dès le chargement, un petit encart apparaît, fixé à l’écran en permanence (il ne disparaît pas quand on scrolle, contrairement à un texte simplement placé en haut du contenu), affichant le temps de lecture total restant. Au fur et à mesure que le visiteur fait défiler la page, ce temps diminue progressivement, recalculé selon la portion déjà lue — ce n’est pas un chronomètre qui décompte tout seul avec le temps qui passe, indépendamment de la lecture. En arrivant tout en bas de l’article, l’encart affiche un message clair indiquant que la lecture est terminée.

Je voudrais afficher, sur mes articles, un petit encart qui reste visible en permanence à l’écran pendant que le visiteur fait défiler la page — pas seulement positionné une fois en haut du texte, ce qui le ferait disparaître de l’écran dès qu’on scrolle. Cet encart doit indiquer le temps de lecture qu’il reste au visiteur avant d’arriver à la fin de l’article, recalculé automatiquement selon la position de défilement — ce n’est pas un chronomètre qui décompte tout seul avec le temps qui passe, mais une valeur liée à la portion du texte déjà parcourue. Au tout début de l’article, il doit afficher le temps de lecture total ; en arrivant tout en bas, il doit afficher un message clair indiquant que la lecture est terminée, plutôt que « 0 minute » sec. Je précise que je ne sais pas si mon site utilise une balise <article> spécifique, ou toute autre structure particulière, pour délimiter le texte de mes articles — sois proactif sur ce point : essaie de détecter automatiquement la zone de texte principale de la page (que ce soit une balise <article>, une zone de contenu identifiable, ou le plus gros bloc de texte visible sur la page), plutôt que de supposer qu’une balise précise existe forcément. Si tu ne parviens vraiment pas à déterminer cette zone de façon fiable, alors seulement, pose-moi la question. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non.

Points à vérifier lors de l’analyse : l’encart reste-t-il bien visible à l’écran en permanence pendant le défilement, plutôt que de disparaître après avoir scrollé un peu ? Le temps affiché diminue-t-il en fonction de la position de lecture, et non d’un simple décompte du temps écoulé (testez en ne scrollant pas du tout pendant 30 secondes : le temps ne doit pas bouger) ? Que se passe-t-il précisément en arrivant tout en bas ? Le script recalcule-t-il correctement si la fenêtre est redimensionnée ? A-t-il su détecter tout seul la bonne zone de texte sur le site testé, sans que vous ayez eu à préciser une balise particulière ?

Piste 3 — Bouton « écouter cet article »

Le parcours, en langage naturel : le visiteur arrive sur un article, et voit un bouton « Écouter cet article » — visible uniquement si son navigateur sait le faire, sinon rien ne s’affiche. Il clique dessus : la lecture démarre aussitôt, en français, avec une voix compréhensible, en lisant uniquement le texte de l’article (pas le menu, ni le pied de page). Le bouton se transforme pour proposer une mise en pause ; le visiteur peut interrompre la lecture, puis la reprendre exactement où elle s’était arrêtée. Un moyen clair permet aussi d’arrêter complètement la lecture. S’il clique une seconde fois sur le bouton principal pendant que ça lit déjà, le comportement est prévisible (pas de superposition de deux lectures, ni de plantage).

Je voudrais ajouter un bouton qui, une fois cliqué, lit à voix haute le texte de mon article — sans passer par un service payant ni un abonnement. La lecture doit se faire en français, avec une voix compréhensible, et le texte lu doit être celui de l’article, pas celui d’un menu ou d’un pied de page. Je précise que je ne sais pas si mon site utilise une balise <article> spécifique, ou toute autre structure particulière, pour délimiter le texte — sois proactif sur ce point : essaie de détecter automatiquement la zone de texte principale de la page, plutôt que de supposer qu’une balise précise existe forcément. Si tu ne parviens vraiment pas à déterminer cette zone de façon fiable, alors seulement, pose-moi la question. Une fois la lecture commencée, le bouton doit permettre de la mettre en pause, puis de la reprendre, et un second bouton (ou une action claire) doit permettre de l’arrêter complètement. Si le visiteur clique à nouveau sur le bouton pendant que la lecture est déjà en cours, précise-moi clairement ce que tu comptes faire (relancer depuis le début, mettre en pause, ou ignorer le clic) plutôt que de laisser un comportement imprévisible. Si le navigateur du visiteur ne sait pas faire ça du tout, le bouton ne doit tout simplement pas apparaître, plutôt que d’afficher une erreur. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non.

Points à vérifier lors de l’analyse : le bouton disparaît-il bien proprement si la fonctionnalité n’est pas disponible ? La voix utilisée est-elle bien en français et compréhensible ? A-t-il su détecter la bonne zone de texte sans que vous ayez précisé de balise ? La mise en pause et la reprise fonctionnent-elles correctement ? Que se passe-t-il si on clique plusieurs fois rapidement sur le bouton pendant la lecture ?

Piste 4 — Générateur de QR code local

Le parcours, en langage naturel : le visiteur clique sur un bouton « Afficher le QR code ». Un QR code apparaît aussitôt, assez grand pour être scanné facilement avec un téléphone, pointant vers l’adresse de la page actuelle — tout est généré directement dans le navigateur, sans passer par un service externe ni charger la moindre bibliothèque depuis un CDN. Le visiteur peut fermer l’affichage simplement, et s’il reclique sur le bouton, aucun second QR code ne vient s’empiler par-dessus le premier.

Je voudrais un bouton qui affiche un QR code renvoyant vers l’adresse de la page actuelle. Je veux que ce QR code soit généré directement dans le navigateur du visiteur, avec un script totalement autonome, sans charger aucune bibliothèque externe (pas de CDN, pas de fichier externe à télécharger) — l’adresse de ma page ne doit jamais être envoyée à un service extérieur, et le code doit fonctionner tout seul, sans aucune dépendance. Le QR code doit être affiché dans une taille suffisamment grande pour être scanné facilement avec l’appareil photo d’un téléphone. Si le visiteur clique plusieurs fois sur le bouton, le QR code ne doit pas s’empiler à l’écran — précise-moi comment tu gères ce cas (le QR code se met à jour à la même place, ou un second clic le referme). Prévois aussi un moyen simple de fermer l’affichage du QR code une fois qu’il est ouvert. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non.

Point de vigilance sécurité propre à cette piste : le besoin précise volontairement « sans envoyer l’adresse à un service extérieur » et « sans charger aucune bibliothèque externe » — deux contraintes distinctes, à ne pas confondre. Un script pourrait générer le QR code entièrement dans le navigateur (donc sans rien envoyer) tout en allant chercher une bibliothèque toute faite sur un CDN externe — ce qui fonctionnerait en théorie, mais échouerait justement sur les sites au CSP strict qu’on a déjà rencontrés, puisqu’il faudrait charger du code depuis l’extérieur. C’est pour ça que le prompt exige un script totalement autonome, sans aucune dépendance. Lors de votre analyse, vérifiez dans l’explication de l’IA qu’elle confirme bien les deux points : aucun envoi de données, et aucun chargement externe.

Piste 5 — Contenu masqué par « mot magique »

Le parcours, en langage naturel : le visiteur arrive sur une page, et découvre que tout le texte et toutes les images ont été remplacés par du faux contenu — la mise en page reste identique à l’originale à 100%, seuls les textes deviennent du latin et les images des placeholders. Un bouton, fixé en permanence au centre de l’écran, demande un mot magique. S’il se trompe, un message d’erreur clair s’affiche. S’il saisit le bon mot, le vrai contenu apparaît, et reste débloqué sur l’ensemble du site pendant 5 minutes — l’expiration n’est vérifiée qu’au moment où une page se recharge, pas en direct pendant la navigation. Tant que le contenu est verrouillé, aucun lien ni bouton de la page ne fonctionne réellement.

Je voudrais que, quand quelqu’un arrive sur ma page, tout le texte et toutes les images de la page soient remplacés par du faux contenu. Pour le faux contenu, ne construis pas une structure artificielle de ton cru : pars de la vraie structure HTML déjà présente sur la page, et remplace uniquement le texte de chaque élément par du lorem ipsum, en conservant la nature de chaque élément — un titre reste un titre, un paragraphe reste un paragraphe, une liste reste une liste, etc. Seules les balises d’image doivent être remplacées par des visuels de remplacement, en conservant leurs proportions d’origine. Les liens, boutons et formulaires présents dans la page verrouillée doivent être réellement neutralisés tant qu’elle est masquée, pas seulement cachés visuellement. Un bouton doit apparaître fixé au centre de l’écran, toujours visible peu importe le défilement, demandant un mot de passe pour révéler le vrai contenu. Utilise le mot de passe « lumosmaxima ». Stocke ce mot de passe comme une simple variable, en clair, directement visible dans le script — ce n’est pas un problème, l’objectif est justement pédagogique. Si le mauvais mot de passe est saisi, affiche un message d’erreur clair, plutôt qu’un échec silencieux. Une fois le bon mot de passe saisi, le contenu réel doit rester visible pendant 5 minutes, sur l’ensemble du site (pas seulement sur la page où le mot de passe a été saisi). Cette expiration doit être vérifiée uniquement au moment où une page est rechargée — je n’ai pas besoin que le contenu se remasque tout seul, en direct, sans rechargement. Je veux pouvoir tester ce script sur n’importe quel site, même ceux qui utilisent un cadre de sécurité strict (CSP – Content Security Policy) pouvant bloquer l’exécution de scripts collés manuellement dans la console. Avant de me donner du code, explique-moi en langage courant comment tu comptes t’y prendre, et pose-moi des questions si tu as besoin de précisions. Si tu me poses des questions, ne commence pas à générer de code tant que je n’y ai pas répondu. Je veux un code sécurisé, élégant, performant et pertinent par rapport à mon besoin. Et je vais tester ça dans la console DevTools. Enfin, à la fin de ta réponse, propose-moi un parcours utilisateur, pour que je puisse vérifier si, d’un point de vue UX/UI, nous sommes alignés ou non. Important : la page doit ressembler à 100% à l’originale — je ne veux surtout pas casser la mise en page (layout). Seuls les textes doivent être remplacés par du texte latin, et les images doivent être remplacées par des placeholders à leur place, sans que rien d’autre ne bouge dans la structure visuelle de la page.

Points à vérifier lors de l’analyse : la mise en page reste-t-elle identique à 100% à l’originale (rien ne bouge, ne se décale, ne casse) ? Chaque type d’élément conserve-t-il bien sa nature (les titres restent des titres, les paragraphes restent des paragraphes) ? Le bouton reste-t-il bien fixé au centre de l’écran pendant le défilement ? Un mauvais mot de passe affiche-t-il bien un message d’erreur ? Les liens de la page sont-ils réellement inactifs tant qu’elle est verrouillée, pas seulement masqués visuellement ?

Une leçon de prompting, découverte en construisant cette piste : une première version du prompt disait « pas un rendu type skeleton loader », pour écarter cette option. Résultat : l’IA a justement généré un skeleton loader (des barres grises à la place du texte). Nommer un exemple, même pour dire qu’on n’en veut pas, peut suffire à le faire apparaître quand même — l’IA retient le mot-clé, pas forcément la négation qui l’accompagne. La bonne pratique : décrire uniquement ce qu’on veut, jamais ce qu’on ne veut pas. C’est pour ça que le prompt final ci-dessus ne mentionne plus « skeleton loader » du tout.

Point de vigilance sécurité propre à cette piste, à tester activement : une fois le script généré et testé, ouvrez la console DevTools et essayez de débloquer le contenu sans jamais saisir le vrai mot de passe, en modifiant directement les informations que le script a stockées dans le navigateur. Si vous y parvenez, c’est la démonstration concrète qu’un mot de passe géré uniquement en JavaScript côté client n’est jamais une vraie protection — seulement un obstacle cosmétique. Demandez d’ailleurs à l’IA, dans votre échange, si cette limite existe pour la solution qu’elle vous propose.

Pour conclure

Le réflexe sécurité de la toute dernière minute

Sur les 5 pistes de ce chapitre, une bonne partie du temps a été passée à faire des allers-retours avec l’IA pour obtenir un résultat qui fonctionne correctement — corriger un skeleton loader qui n’aurait pas dû apparaître, préciser une zone de contenu, régler un comportement de clic répété. C’est normal, et c’est même l’essence de la co-construction.

Mais ce temps passé à chasser le bon fonctionnement fait naturellement perdre de vue la question de la sécurité — aussi bien de votre côté que de celui de l’IA, concentrée elle aussi sur le problème du moment. Ce n’est ni un oubli grave, ni une erreur : c’est juste l’effet naturel d’itérer sur un problème précis.

C’est justement pour ça qu’une dernière passe, entièrement dédiée à la sécurité, doit systématiquement clôturer le travail — une fois que le résultat fonctionne comme attendu, jamais avant. Reprenez le code final, et demandez explicitement à l’IA de l’auditer sous cet angle, sans rien d’autre en tête.

Le code testé en console n’est pas encore un code prêt pour un vrai site

Coller le code brut entre des balises <script>...</script> peut suffire, mais ce n’est pas garanti à chaque fois — deux différences importantes entre la console et une vraie page méritent d’être vérifiées avant de considérer le code prêt :

Le moment d’exécution. Dans la console, la page est déjà entièrement chargée quand on colle le script — tous les éléments HTML existent. Placé tel quel en haut d’une page, ce même script peut s’exécuter avant que les éléments qu’il cherche à manipuler n’existent encore, et échouer silencieusement. Il faut alors le placer juste avant </body>, ou l’entourer d’un DOMContentLoaded — une technique déjà croisée dans plusieurs chapitres HTML/CSS du cours.
L’exécution répétée. Un script collé en console ne s’exécute qu’une seule fois, sur commande. Une fois inséré dans une vraie page, il s’exécutera à chaque chargement — généralement le comportement voulu, mais à vérifier au cas par cas.

Le plus simple : redemander à l’IA d’adapter le script pour une intégration durable sur un site, plutôt que pour un simple test en console — et lui poser directement la question de ces deux points.

Note finale

Pour un site WordPress, la solution la plus propre reste, la plupart du temps, de transformer ce script en véritable plugin installable — un sujet qui sera traité dans un chapitre à part, en dehors de cette section.