Codex et développement assisté par IA
Codex est l’exemple guidé d’agent de développement. Un autre outil ou une proposition de code examinée manuellement peut servir aux exercices ; le laboratoire simule une revue et ne modifie aucun fichier réel.
Chapitres, TP et corrigés consultables ; les TP sont principalement à réaliser hors de la page. Trois questions d’entraînement interactif facultatif sont proposées dans ce module, sans note ni validation automatique. Le manuel de formation est également consultable depuis le lien en haut de page. Les durées sont des repères pour organiser le parcours ; les lectures, activités, travaux pratiques et évaluations ne doivent pas être additionnés deux fois.
Dans ce module — Accès rapide
MODULE 7 — Codex et développement assisté par IA (12 heures)
Bloc B — Développer et publier | Prérequis : modules 1 à 6 | Projet fil rouge : mon-premier-projet (index.html, style.css, script.js, README.md).
1. Compétences visées
• Décrire ce qu’est un agent de développement et distinguer un assistant conversationnel (par exemple ChatGPT) d’un agent de développement (par exemple Codex) pouvant intervenir sur des fichiers.
• Préparer un projet versionné (dépôt GitHub si disponible, sinon dossier local), une branche de travail si possible et une demande de modification vérifiable.
• Lire un diff et expliquer les changements ligne par ligne, y compris leurs conséquences.
• Tester un changement, reconnaître une régression et décider de conserver, corriger ou refuser une proposition.
• Documenter une décision et préserver la sécurité des données et des accès.
2. Parcours horaire
Séquence 1 (2 h) — Assistants conversationnels, agents de développement et notion d’agent : rôles et limites (ChatGPT et Codex comme exemples).
Séquence 2 (2 h) — Préparer le dépôt, le contexte et la branche de travail.
Séquence 3 (2 h) — Formuler une tâche bornée et examiner la proposition.
Séquence 4 (2 h) — Lire le diff, tester et vérifier l’accessibilité.
Séquence 5 (2 h) — Régressions, sécurité, refus et retour arrière.
Séquence 6 (2 h) — Travaux pratiques, autonomie et évaluation.
Comprendre et essayer — exemple guidé
Je vois : Le temps de revue et de test fait partie du travail, pas d'une étape facultative après la modification.
J’essaie : Répartissez les heures entre préparation, modification, revue et tests.
Je vérifie : Les quatre phases sont planifiées et un temps explicite est réservé à la revue et aux tests.
Autre façon de faire : Prévoyez une réserve de temps pour une anomalie découverte pendant les tests, puis ajustez les quatre phases sans supprimer la revue.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
3. Comprendre les outils
ChatGPT aide à clarifier les besoins, expliquer des concepts et concevoir des critères de réussite. Codex est un agent de développement susceptible, selon l’interface et les autorisations, de lire, modifier et tester les fichiers d’un projet. Git conserve l’historique local ; GitHub héberge le dépôt et facilite la revue. L’accès à un dépôt, les fonctionnalités et les quotas dépendent de la configuration du service : ne jamais présumer qu’une connexion est déjà autorisée.
Règle : l’agent propose et peut exécuter des actions dans le périmètre accordé ; l’apprenant reste responsable de la revue, des tests et de la décision de fusionner ou publier.
Comprendre et essayer — exemple guidé
Je vois : GitHub héberge et historise du code ; Codex aide à le modifier, sans remplacer la validation humaine.
J’essaie : Expliquez avec vos mots la différence entre dépôt GitHub et assistant Codex.
Je vérifie : GitHub est décrit comme dépôt/historique ; Codex comme assistant de modification, sans les assimiler.
Autre façon de faire : Sans Codex ni abonnement, comparez sur papier ou dans un document texte les rôles de l’éditeur, du dépôt GitHub et de l’assistant : indiquez pour chacun ce qu’il peut modifier et ce qu’il ne garantit pas.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
4. Préparer une base saine
Ouvrir le projet issu du module 6. Vérifier que index.html, style.css et script.js fonctionnent. Lire README.md et identifier les interactions existantes. Vérifier qu’aucun secret, jeton, donnée personnelle ou fichier inutile n’est présent. Sauvegarder les changements non enregistrés avant de créer une branche.
git status
git switch -c exercice-codex-message
git log --oneline -5Faire défiler horizontalement pour voir les lignes longues.
Lecture : status affiche les changements en cours ; switch -c crée une branche et s’y place ; log présente les derniers commits. En cas d’erreur, demander l’explication de la commande avant toute exécution supplémentaire.
Comprendre et essayer — exemple guidé
Je vois : Délimiter les fichiers protégés réduit le risque d'une modification non souhaitée.
J’essaie : Dressez la liste des fichiers à préserver avant toute intervention.
Je vérifie : Les fichiers critiques sont identifiés et une méthode de restauration est prévue.
Autre façon de faire : Dressez une liste des fichiers protégés et de leur rôle.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
5. Définir une tâche précise et mesurable
Demande d’exercice : ajouter, sur la page existante, un bouton « Afficher une astuce » qui fait apparaître une courte phrase. Le bouton doit fonctionner au clavier ; le texte doit rester lisible sur mobile. Ne modifier que les fichiers nécessaires, conserver le comportement du bouton de prénom et expliquer chaque modification.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Demande vague : « améliore mon site ». Demande vérifiable : « sur une copie, corrige le lien du menu vers #contact, sans modifier le style ; explique les lignes changées ».
J’essaie — petit geste : Comparez le fichier avant et après. Repérez chaque ligne modifiée et refusez toute modification hors périmètre.
Je vérifie — si cela ne fonctionne pas : Sans Codex, la même méthode fonctionne avec deux fichiers et une comparaison manuelle.
Comprendre et essayer — exemple guidé
Je vois : Une demande vérifiable décrit un élément précis et l'effet attendu.
J’essaie : Transformez « améliorer le site » en une modification observable d’un seul élément.
Je vérifie : La demande désigne un élément, une modification et un résultat que l’on peut constater.
Autre façon de faire : Remplacez une demande vague par un changement unique, observable et testable.
Pour reprendre plus tard : Conservez votre production de l’activité 4, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Modèle de prompt pour Codex
Contexte : site statique HTML/CSS/JS du module 6.
Objectif : ajouter un bouton « Afficher une astuce ».
Périmètre : index.html, style.css, script.js uniquement.
Contraintes : pas de dépendance, pas de refonte, conserver les interactions.
Accessibilité : vrai élément <button>, texte lisible, focus visible.
Validation : décrire les fichiers changés et les tests à réaliser.
Avant toute modification : résumer le plan en 3 étapes.
Un bon prompt précise l’objectif, les limites, les critères d’acceptation et les éléments à préserver. Un résultat qui semble joli mais casse une fonction existante n’est pas acceptable.
Comprendre et essayer — exemple guidé
Je vois : Le périmètre explicite permet de détecter toute modification hors sujet.
J’essaie : Rédigez une demande qui interdit de toucher aux fichiers hors périmètre.
Je vérifie : Le périmètre autorisé est explicite et les fichiers exclus sont nommés.
Autre façon de faire : Écrivez une consigne nommant les fichiers autorisés et ceux qui ne doivent pas changer.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
6. Lire et comprendre les différences (diff)
Un diff montre les lignes supprimées (–) et ajoutées (+). Examiner séparément HTML (structure), CSS (présentation) et JavaScript (comportement). Vérifier notamment : identifiants uniques, noms de classes cohérents, existence des éléments ciblés, ordre de chargement du script, styles mobile et absence de suppression accidentelle.
git diff
git diff --check
git statusFaire défiler horizontalement pour voir les lignes longues.
« git diff --check » repère notamment certains problèmes d’espaces ; il ne remplace ni les tests fonctionnels ni la vérification visuelle. Une absence de différence peut simplement signifier que les modifications ont déjà été préparées pour un commit.
Comprendre et essayer — exemple guidé
Je vois : Un diff distingue ce qui est ajouté, retiré ou conservé entre deux versions.
J’essaie : Lisez un diff et distinguez les lignes ajoutées, supprimées et inchangées.
Je vérifie : Les lignes ajoutées et retirées sont correctement distinguées ; le contexte n’est pas compté comme modification.
Autre façon de faire : Sur un diff fictif, marquez les lignes ajoutées et supprimées ; vérifiez ensuite un vrai diff si disponible.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
7. Tester de manière reproductible
□ Test A : ouvrir index.html et vérifier la présentation sur ordinateur.
□ Test B : réduire la largeur de la fenêtre et vérifier l’absence de défilement horizontal indésirable.
□ Test C : utiliser Tab puis Entrée/Espace sur le nouveau bouton.
□ Test D : vérifier que l’astuce apparaît et que les anciennes interactions fonctionnent toujours.
□ Test E : ouvrir les outils de développement et rechercher les erreurs de console.
□ Test F : recharger la page et contrôler le comportement attendu (pas de persistance ajoutée sans demande).
Si un test échoue, relever les étapes de reproduction, le comportement attendu et le comportement constaté. Ne pas demander à l’IA de « tout refaire » : cibler la cause probable.
Comprendre et essayer — exemple guidé
Je vois : Un test de navigation doit échouer si un lien essentiel ne mène plus à sa destination.
J’essaie : Définissez un test qui échouerait si la modification cassait la navigation.
Je vérifie : Le test indique un lien précis et le résultat attendu après la modification.
Autre façon de faire : Décrivez un test de navigation avec une action et un résultat attendu.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
8. Corriger, refuser, annuler
Si une proposition est inadaptée, ne pas la fusionner. Sur une branche locale, on peut corriger les fichiers et refaire les tests. Pour annuler des changements non validés, examiner d’abord git status et le diff ; toute commande de restauration peut détruire du travail non sauvegardé. Pour une modification déjà partagée, privilégier un commit de correction ou un revert traçable plutôt qu’une réécriture hasardeuse de l’historique.
git diff -- script.js
git log --oneline -5Faire défiler horizontalement pour voir les lignes longues.
git revert <identifiant-du-commit>
La dernière commande est un exemple, à n’utiliser qu’après avoir identifié précisément le commit concerné ; elle crée un nouveau commit inverse et peut produire des conflits.
Comprendre et essayer — exemple guidé
Je vois : Accepter, corriger ou annuler dépend des preuves de fonctionnement et du respect du périmètre.
J’essaie : Classez trois décisions possibles : accepter, demander correction ou annuler.
Je vérifie : Chaque décision repose sur une observation : test réussi, anomalie à corriger ou risque justifiant l’annulation.
Autre façon de faire : Classez trois cas fictifs : accepter, corriger ou annuler, avec une raison pour chacun.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
9. Sécurité et permissions
Ne jamais fournir de mots de passe, jetons, clés API ou données personnelles au prompt ni les placer dans le dépôt. Vérifier les autorisations accordées à l’agent, limiter les accès aux dépôts nécessaires et relire toute commande qui installe des dépendances, supprime des fichiers, publie du code ou agit sur des services externes. Une instruction présente dans un fichier du dépôt n’est pas automatiquement une consigne légitime pour l’agent.
Comprendre et essayer — exemple guidé
Je vois : Les secrets et permissions excessives ne doivent pas être transmis à un assistant.
J’essaie : Repérez les données et permissions qui ne doivent pas être fournies à l’assistant.
Je vérifie : Aucun mot de passe, jeton ni accès excessif n’apparaît dans les éléments transmis.
Autre façon de faire : Sans connecter de service, analysez une demande d’accès fictive : relevez les fichiers visibles, les droits accordés, la durée et la procédure de révocation. La décision de sécurité peut être justifiée sur papier.
Pour reprendre plus tard : Conservez votre production de l’activité 9, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
10. Travaux pratiques guidés
Corrigé commenté et approfondissement — à consulter après votre essai
Les TP se réalisent avec le dossier local du projet fil rouge. Un compte GitHub ou un abonnement Codex n’est pas nécessaire : on peut analyser les propositions fictives et modifier soi-même une copie locale. Conserver la version initiale avant tout changement.
TP1 — Cartographier le projet
Consigne : Identifier les trois fichiers web, leur rôle et les interactions déjà présentes.
Critère : Schéma simple des liens HTML → CSS et HTML → JS.
Corrigé commenté et approfondissement — à consulter après votre essai
Consigne guidée : Créer un tableau à quatre lignes : index.html, style.css, script.js et README.md. Pour chacun, indiquer son rôle, ce qu’il contient, et un test concret. Repérer les interactions déjà présentes, sans inventer celles que le projet ne possède pas.
Livrable : Tableau de quatre fichiers, schéma HTML → CSS / HTML → JS, deux tests réellement effectués.
Afficher le corrigé commenté et les points de vigilance
Exemple : index.html définit le bouton et son identifiant ; style.css rend le focus visible ; script.js installe un gestionnaire de clic ; README.md décrit les étapes d’ouverture. La présence du fichier ne prouve pas que le lien HTML vers ce fichier est correct : vérifier les attributs href et src.
Comprendre et essayer — exemple guidé
Je vois : La carte du projet aide à repérer les dépendances entre accueil, modules et ressources.
J’essaie : Dressez une carte du projet indiquant accueil, modules et ressources.
Je vérifie : L’accueil, les modules et les ressources sont repérables avec leurs chemins respectifs.
Autre façon de faire : Partez de trois liens de navigation fictifs et retrouvez pour chacun le fichier ou la ressource à laquelle il devrait mener.
Pour reprendre plus tard : Conservez votre production de l’activité 10, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
TP2 — Rédiger un prompt contrôlable
Consigne : Écrire une demande d’ajout de bouton avec périmètre, contraintes et tests.
Critère : Au moins quatre critères de réussite vérifiables.
Corrigé commenté et approfondissement — à consulter après votre essai
Consigne guidée : À partir du bouton « Afficher une astuce », rédiger une demande avec objectif, contexte, fichiers autorisés, comportements à préserver, accessibilité, critères d’acceptation et demande de plan préalable. Si aucun agent n’est disponible, rédiger simplement le prompt puis le contrôler.
Livrable : Prompt rédigé et liste de quatre tests observables, dont un test de non-régression.
Afficher le corrigé commenté et les points de vigilance
Exemple : « Dans le projet HTML/CSS/JS, ajoute un bouton natif Afficher une astuce ; ne modifie que index.html, style.css, script.js ; conserve le bouton de prénom ; le bouton fonctionne avec Tab puis Entrée ou Espace ; vérifie mobile, console et ancienne interaction ; présente d’abord un plan, puis un diff. » Refuser les demandes vagues comme « modernise tout le site ».
Comprendre et essayer — exemple guidé
Je vois : Une consigne utile associe changement demandé, limites et preuve attendue.
J’essaie : Écrivez une consigne avec objectif, périmètre et test attendu.
Je vérifie : La consigne précise le fichier cible, le changement et un test de non-régression.
Autre façon de faire : Jouez le rôle du destinataire : relevez les informations manquantes qui empêcheraient de vérifier le résultat demandé.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
TP3 — Examiner un diff
Consigne : Comparer la version de référence et une proposition de modification. À défaut de dossier pratique, utiliser ce diff fictif :
- <button id="astuce">Afficher une astuce</button>
+ <button id="astuce" type="button">Afficher une astuce</button>
+ <p id="texte-astuce" aria-live="polite"></p>
Corrigé attendu : le bouton précise son type ; le paragraphe recevra le message annoncé par JavaScript. Vérifier que le script cible exactement texte-astuce. Si aucun script ne le renseigne, le texte restera vide.
Critère : Expliquer les deux lignes HTML ajoutées ou modifiées dans le diff fictif ; indiquer ensuite quel comportement JavaScript serait nécessaire pour renseigner le paragraphe et quels styles CSS pourraient être utiles. Ne pas prétendre que ce diff modifie déjà CSS ou JavaScript.
Corrigé commenté et approfondissement — à consulter après votre essai
Consigne guidée : Lire le diff fictif fourni dans le cours, puis expliquer séparément les lignes supprimées, ajoutées et les comportements encore absents. Produire un mini-diff complémentaire JavaScript cohérent avec le nouvel identifiant. Ne pas prétendre qu’un fichier non montré a été modifié.
Livrable : Analyse des deux ajouts HTML et proposition JavaScript minimale.
Afficher le corrigé commenté et les points de vigilance
Le type="button" empêche la soumission accidentelle d’un formulaire ; le paragraphe aria-live="polite" pourra annoncer le texte. Exemple JS : document.querySelector("#astuce").addEventListener("click", () => { document.querySelector("#texte-astuce").textContent = "Une astuce utile."; }); Ce code suppose que les éléments existent et que le script s’exécute après leur création.
Comprendre et essayer — exemple guidé
Je vois : Lire chaque ligne modifiée évite d'approuver un changement incompris.
J’essaie : Comparez deux versions d’un petit extrait et expliquez chaque modification.
Je vérifie : Chaque ligne modifiée est expliquée et aucun changement hors périmètre n’est accepté sans justification.
Autre façon de faire : Comparez deux extraits sur papier et justifiez chaque ligne modifiée.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
TP4 — Détecter une régression
Consigne : Dans une copie du projet, introduire volontairement cette erreur : remplacer document.querySelector("#bonjour") par document.querySelector("#bonjou") dans script.js, sans modifier le HTML. Recharger la page, observer l’erreur dans la console du navigateur, puis rétablir #bonjour. Corrigé attendu : l’identifiant ne correspond plus à celui du bouton ; querySelector renvoie null et addEventListener échoue si on l’appelle sur null. Retester les interactions après correction.
Critère : Repérer l’identifiant erroné, expliquer et corriger sans refonte.
Corrigé commenté et approfondissement — à consulter après votre essai
Consigne guidée : Sur une copie du projet, remplacer volontairement #bonjour par #bonjou dans le sélecteur JavaScript indiqué. Observer le résultat et la console ; rétablir l’identifiant correct et retester le nouveau bouton ainsi que l’ancien. Si le fichier de départ diffère, adapter l’erreur à un identifiant réellement présent.
Livrable : Journal attendu / observé / cause / correction, avec résultat de deux retests.
Afficher le corrigé commenté et les points de vigilance
Le sélecteur incorrect renvoie null ; l’appel à addEventListener sur null provoque une erreur de type. La correction doit cibler le bon identifiant, pas supprimer l’interaction. Une console sans erreur ne suffit pas : cliquer et activer au clavier pour confirmer.
Comprendre et essayer — exemple guidé
Je vois : Un lien cassé se détecte en suivant son adresse et en contrôlant la page obtenue.
J’essaie : Imaginez une modification qui casse un lien et rédigez le test qui la révèle.
Je vérifie : Le test ouvre le lien visé et signale une destination manquante ou incorrecte.
Autre façon de faire : Imaginez un lien cassé et écrivez les étapes permettant de reproduire l’erreur.
Pour reprendre plus tard : Enregistrez une copie datée du fichier ou une capture du résultat, puis notez le contrôle technique restant à exécuter.
TP5 — Décider et documenter
Consigne : Rédiger une fiche de revue : accepter, demander correction ou refuser.
Critère : Décision motivée et liste de tests effectivement réalisés.
Corrigé commenté et approfondissement — à consulter après votre essai
Consigne guidée : À partir d’une proposition fictive qui ajoute le bouton mais supprime l’ancien gestionnaire de clic, décider : accepter, demander correction ou refuser. Justifier à partir du périmètre demandé et des tests. Rédiger une note de revue réutilisable.
Livrable : Fiche avec décision, preuve du défaut, modification demandée, quatre tests et résultat de chacun.
Afficher le corrigé commenté et les points de vigilance
Décision modèle : « demander correction » car le nouveau bouton fonctionne, mais le bouton de prénom ne répond plus. Conserver l’ajout conforme, restaurer l’ancien gestionnaire, puis retester les deux boutons, le clavier, la console et l’écran étroit. Ne pas approuver uniquement parce que le nouveau bouton marche.
Comprendre et essayer — exemple guidé
Je vois : Un GO exige des critères satisfaits ; un NO GO signale une condition bloquante documentée.
J’essaie : Rédigez un verdict GO/NO GO motivé par une preuve.
Je vérifie : Le verdict cite au moins un résultat de test et une anomalie éventuelle.
Autre façon de faire : Examinez un cas fictif avec un test réussi et un défaut bloquant ; expliquez pourquoi la décision reste NO GO.
Pour reprendre plus tard : Conservez votre production de l’activité 14, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
11. Étude de cas — Récits Vivants
Dans une œuvre immersive, une amélioration d’interface peut changer le sens de l’expérience. Exemple : automatiser une transition temporelle sans imposer une action au visiteur. Avant de modifier le code, formuler ce qui doit rester libre, ce qui peut être mémorisé et ce qui doit être vérifié après 20 jours. La qualité du changement est à la fois technique, ergonomique et artistique.
Comprendre et essayer — exemple guidé
Je vois : L'assistant peut proposer ; l'auteur décide de la pertinence et autorise la publication.
J’essaie : Sur un cas Récits Vivants, séparez création proposée et validation humaine.
Je vérifie : La proposition de l’IA et la décision finale de l’humain sont explicitement séparées.
Autre façon de faire : Séparez sur papier la proposition de l’IA et la décision de validation humaine.
Pour reprendre plus tard : Conservez votre production de l’activité 15, le point précis du critère non encore satisfait et la prochaine vérification à effectuer.
Entraînement interactif facultatif — V0.6.0
Ces questions complémentaires ne constituent ni une note ni une validation de compétence. Aucune réponse n’est enregistrée.
12. Évaluation et corrigés
Afficher le corrigé
1. Codex est-il identique à GitHub ?
Corrigé : Non. Codex intervient sur le développement ; GitHub héberge et organise le dépôt.
Pourquoi cette réponse ? Codex assiste le travail sur le code ; GitHub héberge et organise des dépôts. Leurs fonctions peuvent se compléter sans se confondre.
Exemple ou vérification autonome Décrivez séparément une demande de modification à l’IA et son enregistrement dans Git.
Afficher le corrigé
2. Pourquoi créer une branche ?
Corrigé : Pour isoler les changements avant revue et fusion.
Pourquoi cette réponse ? Une branche limite la portée des essais avant revue et fusion, ce qui facilite la comparaison et le retour arrière.
Exemple ou vérification autonome Créez une branche fictive pour une correction de bouton et précisez quand la fusion serait acceptable.
Afficher le corrigé
3. Que signifie le signe + dans un diff ?
Corrigé : Une ligne ajoutée dans la comparaison affichée.
Pourquoi cette réponse ? Dans un diff, le signe + indique une ligne ajoutée dans la comparaison ; ce n’est pas une preuve de qualité.
Exemple ou vérification autonome Comparez deux versions d’un fichier et identifiez une ligne ajoutée et une supprimée.
Afficher le corrigé
4. Un test réussi suffit-il ?
Corrigé : Non. Il faut vérifier les autres comportements et le périmètre.
Pourquoi cette réponse ? Un test ne couvre qu’un scénario ; une modification peut altérer une autre fonction ou l’accessibilité.
Exemple ou vérification autonome Après un test de clic réussi, contrôlez aussi le clavier et une largeur mobile.
Afficher le corrigé
5. Quel élément HTML choisir pour une action ?
Corrigé : Un bouton
Pourquoi cette réponse ? Le bouton HTML possède des comportements natifs au clavier et une sémantique d’action ; un élément détourné demanderait davantage de corrections.
Exemple ou vérification autonome Activez un vrai bouton avec Entrée et Espace, puis observez son focus.
Afficher le corrigé
6. Pourquoi vérifier la console ?
Corrigé : Pour détecter des erreurs JavaScript et obtenir des indices.
Pourquoi cette réponse ? La console révèle certaines erreurs d’exécution et leurs emplacements ; son silence ne prouve pas que tout est correct.
Exemple ou vérification autonome Provoquez une erreur JavaScript fictive et repérez son message dans la console.
Afficher le corrigé
7. Pourquoi limiter les fichiers modifiés ?
Corrigé : Pour réduire les risques de régression et faciliter la revue.
Pourquoi cette réponse ? Limiter le périmètre rend le diff compréhensible et réduit le nombre de fonctions susceptibles de régresser.
Exemple ou vérification autonome Demandez une correction CSS sans modifier HTML ni JavaScript, puis examinez le diff.
Afficher le corrigé
8. Que faire si Codex supprime une fonction existante ?
Corrigé : Refuser ou demander une correction ciblée, puis retester.
Pourquoi cette réponse ? Une suppression non demandée dépasse le périmètre : la proposition doit être refusée ou corrigée avant acceptation.
Exemple ou vérification autonome Comparez le comportement d’avant et d’après, puis exigez la restauration de la fonction supprimée.
Afficher le corrigé
9. Peut-on partager un jeton dans un prompt ?
Corrigé : Non. Les secrets doivent rester hors des échanges et du dépôt.
Pourquoi cette réponse ? Un jeton est un secret d’accès ; le placer dans un prompt expose potentiellement des droits sur des ressources.
Exemple ou vérification autonome Remplacez un jeton par une valeur fictive avant de soumettre un exemple de configuration.
Afficher le corrigé
10. Que prouve un commit ?
Corrigé : Qu’un état a été enregistré, pas qu’il est exempt de défauts.
Pourquoi cette réponse ? Le commit prouve qu’un état a été enregistré dans l’historique, non que les exigences et tests sont satisfaits.
Exemple ou vérification autonome Associez à un commit une courte liste de tests réellement exécutés.
13. Épreuve d’autonomie (sans IA) — 60 minutes
À partir du dossier pratique : 1) expliquer le rôle des trois fichiers ; 2) ajouter un bouton « Afficher une astuce » sans agent ; 3) tester au clavier et sur écran étroit ; 4) décrire un diff ; 5) écrire une note de validation de 150 mots. Barème /20 : compréhension (4), réalisation (6), tests (5), revue et justification (5). Réussite conseillée : 14/20 avec interaction fonctionnelle et sans régression majeure.
Comprendre et essayer — exemple guidé
Je vois : Le retour arrière est une mesure de maîtrise du risque, même sans IA.
J’essaie : Sans IA, identifiez un changement risqué et la procédure de retour arrière.
Je vérifie : Le risque est nommé et le retour arrière renvoie à une version connue comme fonctionnelle.
Autre façon de faire : Décrivez le risque et les étapes pour revenir à une copie stable ; testez le retour arrière sur des fichiers locaux.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
Atelier d’approfondissement — parcours guidé
Ce parcours complète les travaux pratiques du module. Il peut être réalisé sans abonnement payant et ne constitue pas une évaluation certifiante.
Ce que vous allez apprendre — Délimiter une correction assistée par IA et contrôler les changements proposés.
Matériel nécessaire — Ordinateur et fichiers de démonstration ; assistant de code facultatif.
Organisation sur deux écrans — Vous pouvez lire ce cours sur téléphone et effectuer les manipulations sur ordinateur. Gardez les deux appareils à portée de vue ; aucun transfert de données entre eux n’est obligatoire.
Encadrer une modification proposée par une IA
Comment procéder concrètement
- Créez une copie de index.html contenant volontairement href="#programmes".
- Vérifiez que la section cible porte id="programme".
- Rédigez la consigne ciblée du corrigé dans un document ; transmettez-la à l’outil seulement si vous le souhaitez.
- Comparez l’ancienne et la nouvelle ligne ; ne conservez que la correction href="#programme".
- Ouvrez la page et testez le lien ; notez quels fichiers ont réellement changé.
Si vous n’avez qu’un téléphone — Sans assistant de code ou sur téléphone, comparez manuellement les deux lignes du diff. L’objectif est de savoir contrôler une modification, pas d’ouvrir un compte.
Repères pratiques — Voir les différences sans outil spécialisé
À réaliser concrètement : Créez une copie « avant » et une copie « après » de index.html. Ouvrez-les côte à côte dans deux fenêtres d’éditeur et repérez la ligne du lien. Si vous disposez d’un outil de comparaison, son usage est facultatif. Une IA peut proposer la correction, mais la vérification vous appartient.
Si vous êtes bloqué : Si plusieurs lignes changent alors que seul un lien était demandé, conservez la version initiale et recommencez avec une consigne plus limitée.
Essai autonome, sans recopier le modèle : Corrigez un autre lien volontairement erroné et notez précisément la ligne modifiée.
Étape 1 — Définir le périmètre
À faire : Rédigez une instruction limitant l’intervention au lien du programme.
Exemple ou résultat modèle : « Modifie uniquement index.html pour corriger le lien #programme. Ne change ni CSS ni JavaScript. Montre le diff et les tests à exécuter. »
Vérification : Les exclusions sont explicites.
Étape 2 — Lire le diff
À faire : Comparez les lignes avant/après proposées.
Exemple ou résultat modèle : Avant : href="#programmes" ; après : href="#programme".
Vérification : Un seul attribut ciblé est modifié.
Étape 3 — Tester ou refuser
À faire : Ouvrez la page et activez le lien. Refusez tout changement hors périmètre.
Exemple ou résultat modèle : Le lien conduit au bon titre ; aucun autre fichier n’est touché.
Vérification : L’affirmation « testé » est appuyée par un contrôle réellement effectué.
Si cela ne fonctionne pas : pistes de dépannage
L’outil change plusieurs fichiers : rejetez le résultat et réaffirmez le périmètre. Le lien reste inactif : contrôlez le fragment et la cible.
Afficher le corrigé commenté
Corrigé modèle : corriger la cible du lien suffit. Un diff comportant une refonte de la page doit être rejeté ou justifié séparément.
Exemple complet à reproduire
Fichier ou livrable modèle : consigne-agent-et-diff.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
TÂCHE : Corriger un lien interne dans index.html.
PÉRIMÈTRE AUTORISÉ : index.html uniquement.
ERREUR : href="#programmes" alors que la cible est id="programme".
CHANGEMENT ATTENDU : href="#programme".
INTERDIT : refonte de page, modification CSS, ajout de dépendance.
SORTIE : afficher les lignes avant/après et les fichiers modifiés.
TEST À PROPOSER : ouvrir la page, activer le lien avec Entrée.
DIFF ATTENDU :
- <a href="#programmes">Consulter le programme</a>
+ <a href="#programme">Consulter le programme</a>Pourquoi ce corrigé est valable
Le diff attendu ne modifie qu'un attribut. L'agent ne doit pas prétendre avoir testé si aucun navigateur n'a été utilisé. Comparez la liste des fichiers touchés et refusez les modifications hors périmètre.
Preuve de vérification attendue
Après réalisation, conservez le fichier produit et une note indiquant la manipulation testée, le résultat réellement observé et les éventuelles limites. Ne cochez pas un test non effectué.
Bilan personnel : notez ce qui fonctionne, ce qui reste à vérifier et une amélioration possible. Aucun résultat de cet atelier n’est envoyé au site.
Complément de corrigé TP — exemple de vérification et diagnostic
Modification assistée — Comparer avant et après ligne par ligne, exécuter le scénario ciblé et noter tout effet inattendu. Une proposition générée ne constitue pas une preuve de fonctionnement.
Variante autonome : changer un seul élément de votre réalisation, prévoir le résultat, effectuer le test et consigner ce qui a réellement été observé. Plusieurs solutions sont acceptables si elles satisfont les critères du TP.
Laboratoire ludique facultatif — Le contrôle des propositions Codex
Examine un diff fictif, détecte les modifications hors périmètre, simule des vérifications et prépare une consigne réutilisable. Sans compte, sans score et sans modification de fichiers réels.
Ouvrir le laboratoire M07 — Codex et contrôle des changements →