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. Les réponses des activités guidées ne sont pas enregistrées automatiquement : utilisez les exports TXT proposés ou conservez une copie de vos saisies.
Dans ce module — Accès rapide
MODULE 9 — Plugins, connecteurs et écosystème IA
Durée : 8 heures | Niveau : débutants complets | Bloc B : Développer et publier
Compétences visées
Distinguer une application ChatGPT, une intégration entre services, un outil Codex et une automatisation.
Identifier les données consultables et les actions permises par une connexion.
Appliquer le principe du moindre privilège et savoir révoquer un accès.
Comparer les parcours gratuits et payants sans présumer de quotas fixes.
Contrôler une modification de code avant sa publication.
9.1 — Comprendre l’écosystème (1 h)
Une application ou un connecteur étend les possibilités de ChatGPT vers un service externe. Les fonctions exactes dépendent du service, du compte et des autorisations accordées.
Un outil Codex permet à un agent de travailler sur du code ou un environnement de développement. Une intégration GitHub–Netlify permet de déclencher des déploiements à partir d’un dépôt. Ces mécanismes ne sont pas interchangeables.
Exemple : lire un fichier du dépôt ne donne pas nécessairement le droit de modifier la branche principale ou de publier le site.
Comprendre et essayer — exemple guidé
Je vois : Un assistant, un dépôt de code et un hébergeur remplissent des fonctions différentes.
J’essaie : Classez trois outils en assistant, dépôt de code ou service de publication.
Je vérifie : Les trois catégories correspondent à des fonctions distinctes, sans assimiler hébergement et dépôt.
Autre façon de faire : Sans compte, classez sur papier trois outils selon leur fonction : assistance au code, conservation des versions et publication du site. Justifiez chaque classement en une phrase.
Pour reprendre plus tard : Gardez le tableau de classement avec les éléments qui vous ont fait hésiter et la distinction à revoir.
9.2 — GitHub, Codex et chaîne de travail (1 h 30)
Rappel du projet : index.html définit le contenu, style.css la présentation, script.js les interactions et README.md explique le projet.
Méthode : ouvrir une branche de travail, préciser les fichiers à modifier, demander une proposition à un assistant IA de développement (Codex, par exemple), examiner le diff, tester localement, puis décider si la modification doit être fusionnée.
Une connexion à GitHub peut être limitée à certains dépôts. Il faut vérifier dans les paramètres du service connecté les autorisations réellement consenties.
Une demande utile : « Dans une branche séparée, propose une amélioration de l’accessibilité du bouton d’astuce. Ne modifie pas les autres fonctionnalités. Explique chaque changement et indique les tests à réaliser. »
Comprendre et essayer — exemple guidé
Je vois : Une modification proposée doit passer par un contrôle des fichiers et du résultat obtenu.
J’essaie : Décrivez le trajet d’une modification de code entre demande, dépôt et vérification.
Je vérifie : La chaîne indique où la modification est proposée, enregistrée puis contrôlée.
Autre façon de faire : Dessinez demande → modification → dépôt → contrôle. Le schéma ne prouve pas une connexion réelle.
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.
9.3 — Permissions et accès aux fichiers (1 h 30)
Lecture : l’outil peut consulter les données autorisées. Écriture : il peut modifier des ressources. Administration : il peut parfois modifier des paramètres ou autorisations. Les intitulés varient selon le fournisseur.
Vérifier avant connexion : identité du fournisseur, liste des données accessibles, périmètre des dépôts, capacité d’écriture, modalités de retrait de l’accès.
Ne jamais donner un accès général à tous les dépôts si un seul dépôt suffit. Ne jamais accepter une action de suppression ou publication sans comprendre ses conséquences.
Exercice guidé : rédiger une fiche d’autorisation pour un connecteur hypothétique, en séparant ce qui est nécessaire, facultatif et interdit.
Comprendre et essayer — exemple guidé
Je vois : Une permission doit être limitée aux ressources nécessaires à la tâche.
J’essaie : Examinez une demande d’accès à des fichiers et limitez-la au strict nécessaire.
Je vérifie : Le droit demandé est limité aux fichiers nécessaires et une durée ou révocation est prévue.
Autre façon de faire : Sur un scénario fictif, indiquez les fichiers nécessaires, les droits minimaux et la date de retrait.
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.
9.4 — Sécurité, secrets et confidentialité (1 h 30)
Une clé API, un jeton d’accès ou un mot de passe est un secret : il ne doit jamais être placé dans index.html, script.js, un prompt public, une capture d’écran ou un dépôt GitHub.
Utiliser les paramètres sécurisés prévus par les services pour les secrets. Un fichier .gitignore empêche le suivi futur de fichiers correspondants, mais ne retire pas un secret déjà publié dans l’historique.
Si un secret a été publié : le révoquer ou le faire tourner immédiatement, puis traiter l’historique et examiner les accès.
Examiner aussi les risques d’instructions malveillantes dans les contenus externes : un fichier README ou une page web ne doit pas pouvoir imposer des actions non autorisées à l’agent.
Sauvegarder le projet avant toute intervention majeure ; vérifier les changements avant fusion et publication.
Comprendre et essayer — exemple guidé
Je vois : Un secret présent dans une consigne peut être divulgué à un service externe.
J’essaie : Repérez dans un exemple fictif un secret qui ne doit pas figurer dans une consigne.
Je vérifie : Le secret fictif est retiré de la consigne et remplacé par une valeur factice non exploitable.
Autre façon de faire : Comparez deux consignes fictives avant/après remplacement d’un faux secret. N’utilisez jamais de vrai secret.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
9.5 — Gratuit, payant et quotas (1 h)
Distinguer : accès au service, capacité de connecter une application, nombre de requêtes, fonctionnalités d’agent, minutes de déploiement et ressources d’hébergement.
Ces conditions évoluent. Ne pas annoncer qu’un outil est illimité ou gratuit pour toujours. Consulter les pages officielles de tarification et les limites affichées dans son compte.
Parcours pédagogique de repli : lecture manuelle du dépôt GitHub, copie locale des fichiers, demande de conseils à l’IA, modification contrôlée, puis déploiement manuel Netlify lorsque disponible.
Une formation solide doit rester réalisable même si certaines fonctions d’agent ou de connecteur sont absentes.
Comprendre et essayer — exemple guidé
Je vois : Gratuité, quota et accès sans compte sont des propriétés différentes qui peuvent évoluer.
J’essaie : Comparez un usage sans compte, gratuit limité et payant sans présumer de quotas illimités.
Je vérifie : La comparaison mentionne les limites possibles et ne promet aucun quota illimité.
Autre façon de faire : Comparez trois offres à partir de leurs conditions officielles datées, sans supposer des quotas illimités.
Pour reprendre plus tard : Notez le résultat attendu, l’observation obtenue et l’éventuel écart à reproduire à la prochaine séance.
Parcours d’activités guidées
Activités guidées du module 9. Les réponses saisies restent dans cette page jusqu’à leur export manuel en fichier TXT ; elles ne constituent pas une certification.
9.1 — Comprendre l’écosystème — 40 min indicatives
Travaillez sans compte connecté. Avancez à votre rythme et consultez le corrigé après votre réponse.
Activité 1 — Quatre fonctions à distinguer (10 min indicatives)
Situation ou cours : Une application connectée consulte ou agit sur un service autorisé ; un agent de code examine ou propose des modifications ; une intégration relie deux services ; une automatisation déclenche une action selon une règle. Un même outil peut remplir plusieurs fonctions.
À faire : Pour chacune des quatre fonctions, indiquez en une phrase : déclencheur, donnée utilisée et résultat attendu.
Voir le corrigé commenté
Exemple : application connectée — déclenchée par une demande de lecture, consulte un calendrier autorisé et renvoie des événements. Agent de code — reçoit une demande, examine des fichiers et propose un correctif. Intégration — un dépôt mis à jour déclenche une construction. Automatisation — un horaire déclenche un rappel.
Activité 2 — Démonstration — suivre une demande de bout en bout (15 min indicatives)
Démonstration guidée : Démonstration fictive : « Résume le README de mon projet ». Étape 1 : l’utilisateur formule la demande. Étape 2 : soit il copie le README public, soit il autorise une lecture ciblée. Étape 3 : l’assistant reçoit le texte. Étape 4 : il produit un résumé. Étape 5 : l’utilisateur compare le résumé au texte original. Rien n’est modifié ni publié.
À faire : Dessinez la chaîne en cinq étapes. À chaque étape, indiquez qui agit (humain, connecteur ou assistant) et si un accès externe est indispensable.
Voir le corrigé commenté
1 humain ; 2 humain, connecteur facultatif ; 3 connecteur si choisi ou copie manuelle ; 4 assistant ; 5 humain. L’accès externe n’est pas indispensable si le document public est copié manuellement.
Pourquoi cette réponse ? Le choix entre humain, assistant et connecteur dépend de l’action et des droits requis ; un accès externe n’est pas toujours nécessaire.
Exemple ou vérification autonome Pour chaque étape du scénario, notez l’acteur et justifiez pourquoi un connecteur est facultatif.
Activité 3 — Carte de décision (15 min indicatives)
Situation ou cours : Vous souhaitez simplement résumer la documentation d’un projet public.
À faire : Choisissez : copier le texte, connecter un compte, utiliser un agent de code ou automatiser. Justifiez le choix le moins complexe et proposez un cas où un connecteur deviendrait utile.
Voir le corrigé commenté
Copier le texte public suffit souvent. Un connecteur peut aider à consulter régulièrement des fichiers nombreux, à condition de limiter ses droits. Pas besoin d’agent ni d’automatisation pour une lecture ponctuelle.
Pourquoi cette réponse ? Une copie manuelle de contenu public évite d’ouvrir inutilement un accès permanent ; un connecteur se justifie par un besoin répété.
Exemple ou vérification autonome Comparez une copie ponctuelle et un connecteur en notant les permissions nécessaires.
9.2 — GitHub, Codex et chaîne de travail — 75 min indicatives
Travaillez sans compte connecté. Avancez à votre rythme et consultez le corrigé après votre réponse.
Activité 1 — Lire un projet sans le modifier (15 min indicatives)
Situation ou cours : Projet fictif : index.html contient les éléments de la page ; style.css gère l’apparence ; script.js gère les interactions ; README.md explique le projet.
À faire : Un bouton est illisible. Quel fichier inspecter d’abord ? Quels deux comportements doivent rester inchangés ?
Voir le corrigé commenté
Examiner style.css, puis les règles associées dans HTML si besoin. Préserver le clic du bouton et la navigation au clavier.
Pourquoi cette réponse ? Une modification de contraste doit cibler les styles sans casser l’action du bouton ni son accessibilité.
Exemple ou vérification autonome Vérifiez le contraste, le clic et l’activation clavier avant/après la modification CSS.
Activité 2 — Comprendre branche, diff et tests (20 min indicatives)
Situation ou cours : Une branche sert à isoler une proposition ; un diff montre les lignes modifiées. Un test vérifie le résultat et les régressions. Ces notions s’appliquent même si les changements sont réalisés manuellement.
À faire : Remettez dans l’ordre : publier, examiner le diff, créer une sauvegarde, tester, formuler une demande ciblée, décider. Expliquez pourquoi le test vient avant publication.
Voir le corrigé commenté
Sauvegarde → demande ciblée (sur une branche si possible) → examen du diff → tests → décision → publication éventuelle. Tester avant publication évite de diffuser une régression.
Pourquoi cette réponse ? Une proposition de code doit être revue et testée avant publication ; l’ordre des opérations réduit les risques.
Exemple ou vérification autonome Établissez un journal : sauvegarde, diff, test, décision et publication éventuelle.
Activité 3 — Démonstration — lire un diff CSS (20 min indicatives)
Démonstration guidée : Voici une modification fictive :
AVANT : .bouton { color: #ddd; background: #eee; }
APRÈS : .bouton { color: #111; background: #fff; }
Un « diff » signale ce qui a été retiré et ajouté. Ce changement concerne la couleur du texte et du fond, pas la logique du bouton.
À faire : Identifiez précisément les deux propriétés modifiées. Expliquez ce que ce diff ne permet PAS de vérifier et proposez un test au clavier.
Voir le corrigé commenté
Les propriétés color et background changent. Le diff ne prouve ni l’accessibilité du contraste dans tous les états, ni la navigation au clavier, ni l’absence d’autres effets. Tester Tab pour atteindre le bouton, puis Entrée ou Espace selon le type de contrôle.
Activité 4 — Écrire une demande limitée (20 min indicatives)
Situation ou cours : Un agent de code doit améliorer la lisibilité d’un bouton sans toucher aux autres fichiers. Aucun compte ni agent réel n’est nécessaire : rédigez seulement l’instruction.
À faire : Rédigez une instruction comprenant objectif, contexte, contraintes, livrable et vérification.
Voir le corrigé commenté
Exemple : « Dans style.css, améliore le contraste du bouton principal. Ne change ni HTML ni JavaScript. Fournis un diff et les étapes de test clavier, mobile et contraste. N’applique ni ne publie sans validation. »
Pourquoi cette réponse ? Une demande bornée au CSS permet d’évaluer la réponse sans changements inattendus dans les autres fichiers.
Exemple ou vérification autonome Contrôlez que le diff ne modifie ni HTML ni JavaScript et listez les tests du bouton.
9.3 — Permissions et accès aux fichiers — 75 min indicatives
Objectif : décider quels droits accorder à un connecteur fictif, expliquer son choix et savoir retirer l'accès. Prérequis : aucun compte à connecter. Utilisez les champs ci-dessous ou imprimez cette page. Important : les réponses saisies ne sont pas enregistrées automatiquement. Pour conserver la fiche de l’activité 4, utilisez son bouton de téléchargement ; les autres réponses peuvent être copiées manuellement.
Glossaire essentiel
Connecteur
Outil reliant un assistant à un autre service, selon les autorisations accordées.
Dépôt
Espace contenant les fichiers d'un projet, souvent avec l'historique de leurs modifications.
README
Fichier de présentation et d'instructions d'un projet.
Lecture
Consulter des données, sans les modifier.
Écriture
Créer, modifier ou parfois supprimer du contenu, selon les droits précis.
Administration
Gérer certains paramètres, membres ou autorisations.
Périmètre
Ensemble exact des fichiers, dépôts ou comptes accessibles.
Moindre privilège
Ne donner que les permissions indispensables à la tâche.
Révocation
Retrait d'une autorisation pour empêcher de futurs accès ; cela n'efface pas nécessairement les copies déjà reçues.
Activité 1 — Comprendre les droits (10 min indicatives)
Situation : un assistant doit seulement résumer un README public. Il n'a pas besoin de corriger le code.
Reformulez lecture, écriture et administration avec vos propres mots.
Pour chaque droit, donnez un exemple de risque s'il est accordé inutilement.
Expliquez en une phrase pourquoi la lecture ciblée suffit ici.
Corrigé commenté — activité 1
La lecture permet de consulter le README ; l'écriture pourrait modifier des fichiers sans nécessité ; l'administration pourrait donner accès à des réglages ou membres du projet. Pour résumer un document, aucune modification n'est requise. Une réponse est recevable si elle relie chaque risque au droit accordé.
Activité 2 — Comparer trois demandes (15 min indicatives)
Besoin unique : résumer le README d'un seul dépôt pédagogique.
Une seule décision par connecteur : « Autoriser pour cette mission » si les droits demandés sont adaptés ; « Refuser en l’état — droits trop larges » si le périmètre ou le niveau d’accès dépasse le besoin ; « Refuser en l’état — action dangereuse » si des droits de suppression ou d’administration injustifiés sont demandés. Une demande refusée peut être reformulée avec moins de droits.
Sur téléphone, chaque connecteur est présenté dans une fiche avec ses permissions et sa décision.
Connecteur fictif
Permissions demandées
Votre décision
A
Lecture du dépôt choisi
B
Lecture et écriture de tous les dépôts
C
Lecture du dépôt choisi et suppression de dépôts
Corrigé commenté — activité 2
A : « Autoriser pour cette mission », sous réserve de vérifier le fournisseur. B : « Refuser en l’état — droits trop larges », car la lecture et l’écriture de tous les dépôts dépassent le besoin. C : « Refuser en l’état — action dangereuse », car la suppression n’est pas justifiée. Pour B et C, ne pas accepter les permissions telles quelles ; rechercher une option limitée ou travailler sans connecteur.
Activité 3 — Trois scénarios progressifs (15 min indicatives)
Consulter : résumer un README public.
Proposer : suggérer un correctif CSS, sans modifier le dépôt.
Publier : mettre un changement en production (situation fictive, aucune publication à réaliser).
Pour chaque scénario, indiquez : le droit minimal, ce que la personne doit vérifier, et une solution sans connexion. Distinguez proposer une modification de l'enregistrer réellement.
Corrigé commenté — activité 3
1 : lecture du document seulement ; vérifier que le résumé correspond au texte ; repli : copier le README public. 2 : lecture des fichiers nécessaires ; l'outil peut proposer un extrait ou un diff sans écrire ; repli : copier les extraits utiles et appliquer manuellement après vérification. 3 : publier requiert des droits spécifiques, à limiter à l'environnement et au projet concernés ; prévoir revue humaine, tests, sauvegarde et retour arrière. Repli : publication manuelle après validation. Ne jamais supposer qu'une permission « écriture » implique automatiquement un droit de déploiement.
Activité 4 — Rédiger une fiche d'autorisation (25 min indicatives)
Mission : préparer l'accès fictif d'un assistant à un README public. Complétez tous les champs. Si une information manque, indiquez « à vérifier » plutôt que de l'inventer.
Le téléchargement est déclenché uniquement par votre clic. Aucune donnée n’est envoyée à un serveur ni sauvegardée automatiquement.
Exemple intégral de fiche corrigée
Fournisseur : service fictif, identité et documentation à vérifier.
Objectif : résumer le README d'un projet pédagogique.
Ressource : un README public identifié.
Données : texte de ce README uniquement.
Nécessaire : lecture du document ciblé, si connexion réellement nécessaire.
Facultatif : aucun droit supplémentaire.
Refusés : écriture, suppression, administration, accès à tous les dépôts.
Durée : limitée à la tâche, retrait ensuite.
Risque : exposition de fichiers hors périmètre.
Repli : transmettre manuellement le texte public utile.
Retrait : utiliser les réglages d'autorisations du service concerné ; procédure exacte à vérifier.
Après retrait : contrôler la liste des accès actifs ; ne pas présumer la suppression des données déjà copiées.
Activité 5 — Autoévaluation et bilan (10 min indicatives)
Répondez sans consulter les corrigés, puis ouvrez la vérification.
Lire un README exige-t-il un droit de suppression ?
Retirer un accès garantit-il l'effacement de toutes les copies déjà reçues ?
Que faire si le fournisseur ne permet pas de limiter les droits ?
Réponses et critères de réussite
1. Non. 2. Non, pas nécessairement. 3. Refuser l'autorisation excessive et utiliser une solution de repli, ou choisir un autre outil.
Compétence en progrès si : vous distinguez les trois niveaux de droits, justifiez le périmètre minimal, refusez les permissions disproportionnées, prévoyez un repli et distinguez révocation et effacement des copies. Ce contrôle est formatif et non certifiant.
9.4 — Sécurité, secrets et confidentialité — 60 min indicatives
Travaillez sans compte connecté. Avancez à votre rythme et consultez le corrigé après votre réponse.
Activité 1 — Reconnaître une donnée sensible (10 min indicatives)
Situation ou cours : Exemples fictifs : clé API, URL d’un site public, jeton d’accès, mot de passe, texte de présentation public, fichier de clients.
À faire : Classez chaque élément en public, secret ou donnée à protéger. Expliquez un cas ambigu.
Voir le corrigé commenté
Clé API, jeton et mot de passe : secrets. URL et présentation publique : publics si publiés volontairement. Fichier de clients : donnée à protéger ; même sans mot de passe, sa diffusion peut être problématique.
Pourquoi cette réponse ? Un jeton ou un mot de passe donne accès à des ressources ; une URL volontairement publique n’a pas le même statut.
Exemple ou vérification autonome Classez cinq exemples entre secret, donnée personnelle et information publique.
Activité 2 — Réagir à une fuite de secret (15 min indicatives)
Situation ou cours : Un élève a mis une clé fictive dans script.js puis poussé le fichier vers un dépôt public. Il ajoute ensuite le fichier à .gitignore.
À faire : Pourquoi cela ne suffit-il pas ? Classez les mesures urgentes et celles de suivi.
Voir le corrigé commenté
Le secret peut rester visible dans les commits passés. Priorité : révoquer ou renouveler la clé et contrôler son utilisation. Ensuite : nettoyer les emplacements exposés, traiter l’historique selon la procédure du fournisseur et vérifier les accès. Ne pas publier de clé réelle pendant l’exercice.
Activité 3 — Démonstration — assainir un extrait avant partage (20 min indicatives)
Démonstration guidée : Extrait fictif à NE PAS copier tel quel :
const apiKey = "EXEMPLE-SECRET-A-REMPLACER";
const contact = "personne@example.invalid";
console.log("Erreur de chargement");
Pour demander de l’aide, le message d’erreur et la structure du code suffisent souvent.
À faire : Réécrivez l’extrait partageable en remplaçant les valeurs sensibles par des marqueurs neutres. Expliquez ce que vous avez conservé et pourquoi.
Voir le corrigé commenté
const apiKey = "[CLE_MASQUEE]"; const contact = "[CONTACT_MASQUE]"; console.log("Erreur de chargement");. Garder la structure utile au diagnostic, supprimer les valeurs identifiantes. Même une valeur présentée comme fictive doit encourager la bonne pratique.
Activité 4 — Préparer un mini-plan incident (15 min indicatives)
Situation ou cours : Vous apprenez qu’un document non public a été transmis par erreur à un service externe.
À faire : Rédigez une procédure de cinq lignes : arrêter, identifier, signaler, limiter, apprendre.
Voir le corrigé commenté
Cesser les partages ; identifier ce qui est transmis et à qui ; prévenir le responsable adapté ; révoquer les accès et suivre les procédures de suppression applicables ; documenter et prévenir une répétition. Les copies déjà traitées ne sont pas nécessairement effaçables.
9.5 — Gratuit, payant et quotas — 55 min indicatives
Travaillez sans compte connecté. Avancez à votre rythme et consultez le corrigé après votre réponse.
Activité 1 — Identifier les coûts cachés (15 min indicatives)
Situation ou cours : Un service annonce un compte gratuit. Ses fonctions peuvent toutefois limiter les requêtes, les connexions, le stockage ou les publications. Les offres changent dans le temps.
À faire : Rédigez une grille avec quatre fonctions nécessaires, les limites à vérifier et une alternative sans abonnement.
Voir le corrigé commenté
Exemple : lecture de fichier → vérifier limite d’accès → copier le texte ; génération de code → vérifier quota → écrire ou adapter manuellement ; publication → vérifier quota → exporter ; historique → vérifier durée de conservation → sauvegarde locale.
Activité 2 — Démonstration — choisir un parcours résilient (20 min indicatives)
Démonstration guidée : Deux chemins pour corriger un bouton : A : autoriser un outil à accéder au dépôt et proposer une modification ; B : copier le CSS utile, obtenir une suggestion, tester localement et publier manuellement. Les tarifs et quotas réels ne sont pas supposés connus.
À faire : Complétez pour A et B : permissions, dépendance à un service, validation humaine, plan B en cas de quota. Décidez pour un débutant sans abonnement.
Voir le corrigé commenté
A : permissions ciblées à contrôler, dépendance plus forte, revue et tests nécessaires, repli local. B : aucun accès au dépôt nécessaire, tests et publication manuels, repli via documentation et éditeur local. B est souvent le plus accessible pour un débutant sans abonnement.
Activité 3 — Préparer un plan de continuité (20 min indicatives)
Situation ou cours : Votre quota est atteint au milieu d’un exercice de création web. Vous avez un fichier HTML local et une liste des changements souhaités.
À faire : Décrivez six actions pour continuer sans perdre le travail ni payer.
Voir le corrigé commenté
Sauvegarder les fichiers ; noter l’état du travail ; fractionner les tâches ; utiliser documentation locale et tests navigateur ; reporter les appels IA non indispensables ; reprendre plus tard ou utiliser un autre outil compatible avec les conditions applicables.
9.6 — Activités guidées d’intégration — 75 min indicatives
Travaillez sans compte connecté. Avancez à votre rythme et consultez le corrigé après votre réponse.
Activité 1 — Transfert — choisir une architecture pour un nouveau cas (15 min indicatives)
Démonstration guidée : Cas nouveau : une association veut mettre à jour une page d’information chaque mois. Elle dispose d’un fichier HTML local, d’un dépôt facultatif et d’un assistant gratuit à quota variable.
À faire : Proposez deux chaînes de travail, l’une entièrement manuelle et l’autre avec connexion facultative. Pour chacune, précisez les droits, la validation et une solution en cas d’indisponibilité.
Voir le corrigé commenté
Manuelle : éditer localement, tester, sauvegarder et publier après contrôle. Connectée : lecture ou écriture limitée au seul projet selon l’action réellement confiée, diff, tests et accord humain avant publication. En cas de quota, reprendre le chemin manuel.
Activité 2 — Transfert — arbitrer un compromis réel (20 min indicatives)
Démonstration guidée : L’association reçoit deux propositions : outil A rapide mais demande écriture globale ; outil B plus lent mais permet lecture ciblée. La mission est de préparer un résumé et un brouillon de correction, sans publier.
À faire : Choisissez une solution, décrivez les droits indispensables et expliquez ce que vous ne pouvez pas conclure sans consulter les conditions réelles des fournisseurs.
Voir le corrigé commenté
Privilégier B pour une lecture ciblée, ou copier manuellement le contenu. Aucun droit de publication n’est nécessaire. Sans documentation réelle, on ne peut pas conclure sur les quotas, la conservation des données ou la sécurité du fournisseur.
Activité 3 — Concevoir une chaîne de travail (25 min indicatives)
Situation ou cours : Projet fictif : corriger un contraste CSS, vérifier le résultat, puis éventuellement publier.
À faire : Rédigez une procédure de huit étapes avec un point de décision humaine et un plan de retour arrière.
Voir le corrigé commenté
Exemple : sauvegarde, définir le besoin, choisir les fichiers, proposer le changement, examiner le diff, tester clavier/mobile/contraste, approuver ou rejeter, publier avec possibilité de revenir à la sauvegarde.
Pourquoi cette réponse ? Le principe du moindre privilège exige de limiter les fichiers et opérations accessibles à ce qui est nécessaire.
Exemple ou vérification autonome Réduisez les droits d’un connecteur fictif et documentez le moyen de les révoquer.
Activité 4 — Produire votre bilan de compétences (15 min indicatives)
Situation ou cours : Reprenez les réponses précédentes. Ce contrôle n’est ni noté ni certifiant.
À faire : Écrivez trois acquis, deux points à revoir et une décision que vous sauriez justifier devant un pair.
Voir le corrigé commenté
Critères : distinguer les fonctions ; limiter les droits ; protéger les secrets ; prévoir validation et repli ; ne pas confondre gratuit et illimité. Les réponses personnelles varient : elles doivent être argumentées.
Pourquoi cette réponse ? Le succès dépend de la protection des secrets, de la maîtrise des droits et d’une validation humaine, pas du nombre d’outils connectés.
Exemple ou vérification autonome Vérifiez un scénario où aucun connecteur n’est requis et expliquez votre choix.
Travaux pratiques de synthèse — 9.6 (1 h 30)
TP 1 (15 min) : classer dix exemples d’outils en application, agent de code, intégration et automatisation.
Jeu de dix exemples fictifs à classer : (1) application de recherche documentaire dans ChatGPT ; (2) agent Codex chargé de proposer un correctif ; (3) liaison GitHub–Netlify déclenchant un déploiement ; (4) rappel hebdomadaire programmé ; (5) application de consultation d’un calendrier ; (6) agent chargé de modifier un fichier CSS ; (7) liaison entre un dépôt et un service de tests ; (8) rapport envoyé automatiquement chaque lundi ; (9) application de consultation de fichiers ; (10) agent chargé de préparer un diff. Corrigé : applications 1, 5, 9 ; agents 2, 6, 10 ; intégrations 3, 7 ; automatisations 4, 8. Certaines solutions réelles peuvent combiner plusieurs catégories : classer ici selon la fonction décrite.
TP 2 (20 min) : analyser une demande d’autorisation fictive ; cocher les permissions excessives et proposer une version minimale.
Cas fictif : un assistant doit uniquement lire le README d’un dépôt pédagogique pour en expliquer les consignes. Autorisations demandées : lecture du dépôt ciblé ; écriture sur tous les dépôts ; suppression de dépôts ; gestion des membres de l’organisation ; accès aux dépôts privés sans rapport avec le cours. Corrigé attendu : seule la lecture du dépôt ciblé est nécessaire ; toutes les autres permissions sont excessives. Si le fournisseur ne permet pas cette limitation, renoncer à la connexion et fournir un extrait non sensible du README.
TP 3 (20 min) : écrire un prompt de modification ciblée pour le site fil rouge, avec interdiction de toucher au stockage local.
TP 4 (20 min) : lire un diff fictif et détecter une modification non demandée.
Diff fictif à analyser (les lignes précédées de - sont retirées ; celles précédées de + sont ajoutées) :
- <button id="astuce">Afficher une astuce</button>
+ <button id="astuce" type="button">Afficher une astuce</button>
- localStorage.removeItem("prenom");
+ localStorage.clear();
Consigne : l'objectif autorisé est uniquement de préciser le type du bouton. Repérer la modification hors périmètre. Corrigé : l'ajout de type="button" est conforme ; remplacer removeItem("prenom") par clear() est non demandé et peut effacer toutes les données localStorage de cette origine. Refuser cette seconde modification et retester la mémorisation du prénom.
Évaluation (15 min) : expliquer oralement le circuit de validation et décrire la procédure de révocation d’un accès.
Étude de cas — Récits Vivants
Situation : une page de découverte doit être mise à jour sans casser son QR code ni sa navigation mobile. L’apprenant identifie le dépôt concerné, limite les fichiers autorisés, fait réaliser une proposition sur une branche, teste les liens et le responsive, puis valide la publication. Une capture de la version antérieure et un commit repérable facilitent le retour arrière.
Comprendre et essayer — exemple guidé
Je vois : Un connecteur ne devrait recevoir que les documents nécessaires à la tâche définie.
J’essaie : Pour Récits Vivants, choisissez quelles ressources peuvent être partagées avec un connecteur.
Je vérifie : Les ressources publiques sont distinguées des documents privés et des identifiants.
Autre façon de faire : Sur papier, classez les ressources partageables et confidentielles avant toute connexion.
Pour reprendre plus tard : Conservez la version ou le scénario utilisé, la preuve disponible et l’étape distante qui reste à tester réellement.
Grille de vérification avant autorisation
☐ Le fournisseur est identifié.
☐ Le périmètre des données est connu.
☐ Les droits de lecture et d’écriture sont distingués.
☐ Les accès sont limités au projet nécessaire.
☐ Les secrets restent hors du code et des prompts.
☐ La méthode de révocation est connue.
☐ Un retour arrière est possible.
Voir un exemple, essayer et vérifier
Je vois — exemple concret : Cas fictif : un outil demande la lecture de fichiers pour résumer un document. Lecture peut être pertinente ; écriture et suppression ne le sont pas pour ce besoin.
J’essaie — petit geste : Classez trois droits fictifs — lire, modifier, supprimer — en nécessaires ou non nécessaires. Justifiez chaque choix.
Je vérifie — si cela ne fonctionne pas : Si la portée d’un droit n’est pas compréhensible, n’autorisez pas l’accès ; recherchez une alternative sans connexion.
Comprendre et essayer — exemple guidé
Je vois : Une autorisation se juge par son périmètre, sa durée, ses risques et sa révocation.
Je vérifie : Les cinq champs sont renseignés ; la révocation est possible ou explicitement signalée comme incertaine.
Autre façon de faire : Sans compte, remplissez une grille locale avec l’outil envisagé, les données accessibles, la durée, les risques et la méthode de révocation. Ne donnez aucune autorisation réelle pour cet exercice.
Pour reprendre plus tard : Conservez votre production de l’activité 7, 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.
Autoévaluation — 10 questions
1. Que fait un connecteur ?
2. Une lecture GitHub autorise-t-elle forcément une écriture ?
3. Qu’est-ce que le moindre privilège ?
4. Pourquoi créer une branche ?
5. Qu’est-ce qu’un diff ?
6. Peut-on publier une clé API dans script.js ?
7. Un .gitignore efface-t-il un secret déjà commité ?
8. Pourquoi tester après une modification proposée par un assistant IA ?
9. Les quotas gratuits sont-ils garantis à vie ?
10. Que faire si une connexion n’est plus nécessaire ?
Afficher le corrigé
Corrigé de l’autoévaluation
1. Il relie un assistant à un service selon des capacités et permissions définies.
2. Non.
3. N’accorder que les droits strictement nécessaires.
4. Pour isoler une modification avant validation.
5. La comparaison des modifications entre deux états du code.
6. Non.
7. Non.
8. Pour vérifier la demande et détecter les régressions.
9. Non, ils peuvent changer.
10. Révoquer son accès et vérifier les autorisations restantes.
Épreuve finale sans IA — 30 minutes
Sur papier ou dans un éditeur de texte, construire une fiche de connexion pour un outil fictif ayant accès à un dépôt GitHub. Indiquer : objectif, données nécessaires, permissions acceptées/refusées, risques, tests de validation et procédure de révocation. Expliquer ensuite la fiche en cinq minutes.
Comprendre et essayer — exemple guidé
Je vois : Refuser une permission peut être une décision raisonnée même sans utiliser d'IA.
J’essaie : Sans IA, décidez si une autorisation fictive doit être accordée et justifiez.
Je vérifie : La décision cite un risque concret et un moyen de le réduire ou de refuser l’accès.
Autre façon de faire : Sans IA, traitez le cas proposé dans un document texte hors ligne et justifiez les permissions que vous refuseriez. Une simulation suffit ici pour évaluer le raisonnement, pas une connexion effective.
Pour reprendre plus tard : Conservez uniquement l’exemple anonymisé, la correction retenue et l’affirmation ou la donnée qu’il faudra contrôler.
Critères de réussite
Identifier correctement les quatre types d’outils (20 %).
Définir des permissions minimales (25 %).
Détecter et protéger les secrets (25 %).
Décrire une validation et un retour arrière (20 %).
Expliquer les limites des offres et quotas (10 %).
Comprendre et essayer — exemple guidé
Je vois : Une autorisation maîtrisée peut être revue et retirée, et cette décision doit être tracée.
J’essaie : Évaluez si votre décision est réversible et documentée.
Je vérifie : La réversibilité est décrite par une action concrète, pas seulement affirmée.
Autre façon de faire : Sur papier, indiquez comment révoquer l’accès et conserver une trace de la décision.
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.
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 — Choisir le partage minimal de données pour accomplir une tâche.
Matériel nécessaire — Téléphone ou ordinateur ; aucun connecteur à installer.
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.
Choisir un accès aux données proportionné
Comment procéder concrètement
Écrivez le besoin exact : résumer deux paragraphes non confidentiels.
Dressez trois possibilités : copier l’extrait, transmettre un fichier expurgé, connecter un service.
Pour chacune, notez les données visibles et les permissions nécessaires.
Choisissez l’option qui transmet le moins de données tout en permettant la tâche.
Rédigez une justification et les questions à vérifier avant toute connexion réelle.
Si vous n’avez qu’un téléphone — L’intégralité de l’activité peut être menée sur papier ou sur téléphone, sans autoriser d’accès à un compte.
Repères pratiques — Limiter puis retirer un accès
À réaliser concrètement : Cas d’exercice : une personne veut faire résumer deux paragraphes publics. Comparez la copie d’extrait, le fichier expurgé et le connecteur. Pour un connecteur réellement autorisé, consultez ses paramètres de permissions et la procédure de déconnexion ou de révocation propre au service ; ne connectez aucun compte pour cet exercice.
Si vous êtes bloqué : Si la portée d’accès ou la révocation est inconnue, notez « non vérifié » et choisissez l’option sans connexion lorsque cela suffit.
Essai autonome, sans recopier le modèle : Variante : un dossier contient aussi des données privées. Justifiez pourquoi transmettre uniquement un extrait non sensible est préférable.
Étape 1 — Identifier le besoin
À faire : Définissez précisément le contenu à analyser.
Exemple ou résultat modèle : « Résumer deux paragraphes non confidentiels. »
Vérification : Le besoin ne nécessite pas un accès général au stockage.
Étape 2 — Comparer les options
À faire : Évaluez copie d’extrait, fichier expurgé et connecteur.
Exemple ou résultat modèle : Extrait : portée minimale ; fichier : portée bornée ; connecteur : permissions à vérifier.
Vérification : Chaque option précise données, accès et révocation.
Étape 3 — Décider et documenter
À faire : Choisissez la solution la moins intrusive et notez pourquoi.
Exemple ou résultat modèle : « Copier l’extrait suffit ; aucun connecteur nécessaire. »
Vérification : Le choix satisfait le besoin sans permission excessive.
Si cela ne fonctionne pas : pistes de dépannage
Vous ne connaissez pas la portée d’une permission : ne validez pas la connexion ; recherchez la documentation et la procédure de révocation.
Afficher le corrigé commenté
Corrigé modèle : pour deux paragraphes non sensibles, la copie d’extrait peut suffire. Les permissions et les quotas doivent être vérifiés avant toute connexion réelle.
Exemple complet à reproduire
Fichier ou livrable modèle : matrice-permissions.txt. Copiez ou adaptez ce contenu dans votre propre dossier de travail.
BESOIN : résumer deux paragraphes non confidentiels.
OPTION A — Copier un extrait : accès aux deux paragraphes ; pas de connecteur.
OPTION B — Fichier expurgé : accès au seul fichier transmis ; vérifier sa conservation.
OPTION C — Connecteur : portée des permissions à vérifier ; révocation à prévoir.
CHOIX : option A si les paragraphes suffisent.
PREUVE : aucun document complet ni dossier privé transmis.
QUESTIONS AVANT CONNEXION :
- Quelles données sont accessibles ?
- Peut-on limiter et révoquer l'accès ?
- Quelles limites d'utilisation s'appliquent ?
Pourquoi ce corrigé est valable
La décision est proportionnée au besoin. Un connecteur n'est pas une obligation pédagogique. Si le document contient des informations sensibles, il faut d'abord les retirer ou renoncer au transfert.
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
Permissions des connecteurs — Décrire la donnée demandée, l’autorisation exacte et la manière de la retirer ; préférer le moindre privilège et ne jamais utiliser de secrets réels dans l’exercice.
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 — À qui donner accès ?
Justifier les permissions nécessaires dans un scénario fictif.
J’observe, j’essaie, je comprends. Aucune note ni classement. Cette activité facultative n’est pas nécessaire pour poursuivre le parcours et ne valide pas, à elle seule, une compétence. Tu peux recommencer autant de fois que tu le souhaites.
L’activité s’ouvre dans une page dédiée, adaptée au téléphone et utilisable au clavier. Le retour au module est prévu. Aucune donnée n’est envoyée à un serveur.