Quiz d'auto-évaluation

# Pendant que vous tapez, du texte grisé apparaît devant votre curseur. D'où vient-il ? 1. [ ] D'une recherche dans une base d'exemples de code > ❌ La suggestion n'est pas une recherche dans une base d'exemples : elle est prédite par un modèle. 1. [x] D'un modèle qui prédit la suite à partir de ce qui entoure le curseur > ✅ La complétion est déjà de l'IA : le modèle reçoit le fichier courant, souvent quelques fichiers ouverts à côté, et prédit la suite. 1. [ ] D'une simple autocomplétion de l'éditeur, sans IA > ❌ C'est justement la forme qu'on oublie de compter comme de l'IA, alors qu'elle est produite par un modèle, au même titre qu'une réponse de chat. # Qu'est-ce qui distingue fondamentalement les quatre formes d'assistance ? 1. [ ] La marque de l'outil > ❌ Les mêmes quatre formes existent chez Copilot, Continue, Cline, etc. La marque n'est pas la frontière. 1. [x] Le degré d'autonomie que vous accordez à l'outil > ✅ C'est la différence de degré mise en avant dans l'article : de la complétion, qui propose une ligne, au mode agent, qui modifie le projet de lui-même. 1. [ ] Le modèle utilisé derrière > ❌ Les extensions offrent les mêmes quatre formes avec d'autres modèles derrière : le modèle ne définit pas la forme. # Dans quelles formes l'outil se contente-t-il de proposer, en vous laissant appliquer ? - [x] La complétion > ✅ Elle propose la suite, que vous acceptez avec Tab ou refusez avec Échap. - [x] La discussion > ✅ Elle répond à côté du code ; c'est vous qui recopiez ce que vous retenez. - [x] L'édition en place > ✅ Elle propose un diff, que vous acceptez ou rejetez. - [ ] Le mode agent > ❌ Le mode agent agit : il crée et modifie des fichiers, lance des commandes, sans que vous validiez chaque étape. C'est le seul mode où l'outil modifie votre projet de lui-même. # Vous voulez ajouter un `try/except` autour de trois lignes. Quelle forme est la plus adaptée ? 1. [ ] La complétion > ❌ La complétion propose la suite de ce que vous tapez, elle ne transforme pas un bloc existant à la demande. 1. [ ] La discussion > ❌ Elle répondrait à côté du code, et il faudrait recopier le résultat vous-même. 1. [x] L'édition en place > ✅ C'est la forme la plus adaptée aux retouches : elle montre exactement ce qui change, sous forme de diff. Elle est plus rapide et plus sûre qu'un agent pour ce type de tâche. 1. [ ] Le mode agent > ❌ Un agent est disproportionné pour trois lignes, et demande de relire tout le diff et les commandes lancées. # Vous découvrez un projet existant et voulez comprendre comment il est organisé. Que faire ? 1. [x] Utiliser la discussion avec `@workspace` > ✅ Pour comprendre un projet qu'on découvre, la discussion avec `@workspace` est imbattable : la question porte sur l'ensemble du projet. 1. [ ] Lancer le mode agent pour qu'il réorganise le projet > ❌ Vous voulez comprendre le projet, pas le modifier. 1. [ ] Copier quelques fichiers dans un chat de navigateur > ❌ Le chat du navigateur ne voit que ce que vous lui collez, alors que l'assistant intégré peut voir votre projet. # Un agent a rendu vos tests verts en supprimant l'assertion qui échouait. Que faut-il en retenir ? 1. [ ] Les tests passent, donc le code est correct > ❌ Un test dont on a retiré l'assertion ne vérifie plus rien. 1. [ ] L'agent est défectueux > ❌ Il a fait exactement ce que vous lui avez demandé : faire passer les tests. 1. [x] Il faut lire le diff avant d'accepter, surtout quand il est long > ✅ C'est le seul moyen de repérer ce genre de modification. Plus l'outil est autonome, plus la relecture doit être serrée. # Au-delà de la qualité des réponses, quels critères comptent pour choisir une extension ? - [x] L'endroit où part votre code > ✅ Une extension envoie le contenu de vos fichiers à un serveur distant. Sur du code confidentiel, ce point n'est pas négociable. - [x] Ce que l'extension coûte > ✅ C'est l'objet de la fiche sur les crédits et le choix du modèle. - [ ] Le fait qu'elle soit installée par défaut > ❌ Copilot est fourni avec VS Code, mais rien ne vous y oblige : d'autres extensions s'installent depuis la même marketplace.

# Qu'est-ce qui fait varier le coût d'une demande ? - [x] La taille du modèle > ✅ Un gros modèle de raisonnement mobilise bien plus de calcul qu'un petit modèle entraîné pour répondre vite. - [x] La quantité de contexte envoyée > ✅ Envoyer trois fichiers coûte plus cher qu'envoyer trois lignes, parce que le modèle doit tout lire avant de répondre. - [ ] Le langage de programmation du code > ❌ Ce n'est pas un facteur : ce qui est facturé, c'est le temps de calcul, qui dépend de la taille du modèle et de la quantité de texte. # Qu'est-ce qu'un crédit ? 1. [ ] L'unité de découpage du texte, environ trois quarts d'un mot > ❌ Ça, c'est un jeton. 1. [ ] Un aller-retour avec le modèle > ❌ Ça, c'est une requête. 1. [x] Une requête pondérée par le modèle utilisé > ✅ Le même échange peut coûter 0,25 crédit avec un petit modèle et 10 crédits avec un gros. # Pourquoi la complétion au fil de la frappe est-elle illimitée dans la plupart des offres, alors que c'est elle qui déclenche le plus de requêtes ? 1. [ ] Parce qu'elle s'exécute entièrement sur votre machine > ❌ La complétion envoie bien des requêtes à un serveur. 1. [x] Parce qu'elle utilise un modèle spécialisé minuscule, dont le coût unitaire est négligeable > ✅ Comparé aux modèles du chat, ce modèle coûte très peu par requête. 1. [ ] Parce qu'elle n'est pas considérée comme de l'IA > ❌ La complétion est produite par un modèle, au même titre qu'une réponse de chat. # Pourquoi une session en mode agent peut-elle consommer beaucoup sans que vous vous en rendiez compte ? 1. [x] Parce que chaque tour (lancer une commande, lire l'erreur, corriger, relancer) est une requête > ✅ L'agent enchaîne ces tours de lui-même, et chacun est compté. 1. [ ] Parce que le mode agent est facturé au temps passé, même sans requête > ❌ Ce sont les requêtes qui sont comptées, et l'agent en enchaîne beaucoup. 1. [ ] Parce qu'il utilise toujours le plus gros modèle disponible > ❌ Le modèle se choisit dans le menu déroulant ; c'est le nombre de tours qui fait grimper la consommation. # Vous voulez écrire la docstring d'une fonction simple. Quel modèle choisir ? 1. [x] Un petit modèle rapide > ✅ Il convient pour compléter, renommer, écrire une docstring ou expliquer une erreur courante. Il répond en une seconde. 1. [ ] Le plus gros modèle de raisonnement disponible > ❌ C'est le réflexe naturel, mais rarement le bon : sur une tâche simple, les deux répondent juste, et le gros modèle coûte plus cher et répond plus lentement. # Dans quelles situations un gros modèle de raisonnement devient-il utile ? - [x] Concevoir une structure de données adaptée à trois usages différents > ✅ La tâche demande de tenir plusieurs contraintes à la fois. - [x] Trouver une erreur qui ne se manifeste qu'à la troisième itération d'une boucle > ✅ Ce type de recherche demande de raisonner sur plusieurs étapes qui interagissent. - [ ] Renommer une variable dans un fichier > ❌ Un petit modèle rapide suffit pour ce genre de tâche. - [ ] Expliquer un message d'erreur courant > ❌ Un petit modèle rapide suffit pour ce genre de tâche. # Un gros modèle produit un code bien structuré et bien commenté. Que peut-on en déduire ? 1. [ ] Que le code est probablement juste > ❌ La qualité de la présentation n'est pas un indice de la justesse du raisonnement. 1. [x] Rien sur sa justesse : un gros modèle qui se trompe se trompe de façon plus convaincante > ✅ L'erreur est simplement plus profondément enfouie. Il faut vérifier le code comme n'importe quel autre. # Pourquoi faut-il activer GitHub Education bien avant la séance ? 1. [ ] Parce que l'offre étudiante n'est disponible qu'en début d'année > ❌ Ce n'est pas la raison donnée dans la fiche. 1. [x] Parce que la validation du statut étudiant peut prendre de quelques heures à quelques jours > ✅ Sans validation le jour de la séance, vous n'aurez pas le choix du modèle, et la partie de l'activité qui y est consacrée perdra l'essentiel de son intérêt. 1. [ ] Parce qu'il faut d'abord installer une version spéciale de VS Code > ❌ Il suffit de vous connecter à votre compte GitHub depuis VS Code une fois la validation obtenue. # Quels sont les avantages d'un modèle exécuté localement, par exemple avec Ollama ? - [x] Il ne consomme aucun crédit > ✅ Le calcul est fait par votre machine. - [x] Il ne nécessite pas de connexion > ✅ Une fois le modèle téléchargé, tout se passe sur votre ordinateur. - [x] Il n'envoie votre code nulle part > ✅ C'est un point important en entreprise, sur du code confidentiel. - [ ] Il est aussi bon que les modèles en ligne > ❌ Les modèles qui tiennent sur un ordinateur portable sont nettement moins bons.

# Que retient le modèle de votre projet d'une requête à l'autre ? 1. [ ] Tout le projet, qu'il a appris à connaître au fil des échanges > ❌ Il n'y a pas de « l'assistant connaît mon projet » : le modèle ne conserve aucune mémoire d'une requête à l'autre. 1. [x] Rien : seul compte ce que l'extension a mis dans le message de la requête > ✅ À chaque requête, l'extension renvoie l'historique de la conversation et une sélection de morceaux du projet. La qualité de la réponse dépend largement de cette sélection. 1. [ ] Les fichiers ouverts lors de la première requête > ❌ Rien n'est conservé par le modèle : chaque requête construit un nouveau message, avec ce que l'extension choisit d'y mettre. # Quelle référence permet de joindre la dernière commande lancée dans le terminal et sa sortie ? 1. [ ] `#file` > ❌ `#file` joint un fichier que vous choisissez. 1. [ ] `#selection` > ❌ `#selection` joint la portion sélectionnée dans l'éditeur. 1. [x] `#terminalLastCommand` > ✅ C'est la référence prévue pour joindre la dernière commande et sa sortie, par exemple pour faire expliquer une erreur. 1. [ ] `@workspace` > ❌ `@workspace` sert à poser une question portant sur l'ensemble du projet. # Quelle est la différence entre `#file` et `#codebase` ? 1. [x] Avec `#file`, vous choisissez le fichier ; avec `#codebase`, l'outil va chercher lui-même des extraits dans le projet > ✅ Avec `#codebase`, vous déléguez la sélection du contexte à l'outil, et vous ne contrôlez plus exactement ce qui entre. 1. [ ] `#codebase` joint l'intégralité du projet, sans limite de taille > ❌ La taille du contexte est limitée, et un gros projet n'y tient pas : l'outil ne joint que des extraits. 1. [ ] Il n'y en a aucune > ❌ Les deux références ne remplissent pas le contexte de la même manière. # Que met-on dans un fichier d'instructions comme `.github/copilot-instructions.md` ou `AGENTS.md` ? - [x] La version de Python visée > ✅ C'est typiquement le genre d'information qu'on ne veut pas répéter à chaque demande. - [x] Les conventions de nommage et de documentation > ✅ Le fichier est joint à chaque demande, ce qui évite de les rappeler. - [x] L'interdiction d'ajouter des dépendances sans justification > ✅ Ce type de consigne impérative a toute sa place dans ce fichier. - [ ] Une copie du code des fichiers importants > ❌ Un fichier d'instructions utile est court et impératif : une dizaine de lignes suffisent. # Dans un onglet de navigateur, vous demandez à un chat une fonction qui calcule la distance entre deux points d'une carte, pour l'application de guidage GPS que vous développez. Quel est le résultat le plus probable ? 1. [ ] Une fonction qui appelle votre parcours de graphe existant > ❌ Le chat ne voit pas votre projet : il ne peut pas savoir que cette fonction existe. 1. [x] Une fonction correcte, mais qui fait doublon avec le code que vous aviez déjà écrit > ✅ C'est pour cette raison que copier-coller du code depuis un chat externe produit du code redondant. Ce n'est pas que l'outil soit moins bon : il ne voit pas votre projet. 1. [ ] Une fonction fausse, car les chats de navigateur utilisent de moins bons modèles > ❌ La différence ne tient pas au modèle, mais à ce que le modèle avait sous les yeux. # Les trois dernières fonctions de votre fichier sont annotées et documentées en français. Que va probablement proposer la complétion pour la quatrième ? 1. [x] Une fonction annotée et documentée en français > ✅ La complétion imite ce que vous venez d'écrire, car son contexte est ce qui entoure le curseur. 1. [ ] Une fonction documentée en anglais, la langue habituelle du code > ❌ La complétion n'applique pas de convention extérieure : elle reproduit celle de votre fichier. 1. [ ] Une fonction sans documentation, pour économiser des jetons > ❌ La complétion ne fait pas ce genre d'arbitrage : elle prolonge le style du code environnant. # Quelles sont les conséquences du fait que la complétion imite votre code ? - [x] Écrire soigneusement les premières fonctions d'un module aide à obtenir les suivantes dans le même style > ✅ C'est le moyen le plus efficace de faire produire du code dans le style voulu. - [x] Une convention bancale se propage dans les suggestions suivantes > ✅ La complétion n'a aucun jugement sur ce qu'elle imite. - [ ] La complétion corrige progressivement vos mauvaises habitudes > ❌ Au contraire, elle les reproduit. # Une réponse de l'assistant vous déçoit. Quelle question devez-vous vous poser en premier ? 1. [x] Le modèle avait-il l'information nécessaire ? > ✅ Neuf fois sur dix, c'est là que ça se joue : joignez le fichier concerné et recommencez. 1. [ ] Le modèle est-il assez gros ? > ❌ C'est la dernière question à se poser, pas la première. 1. [ ] Faut-il reformuler en étant plus poli ? > ❌ Ce qui compte est que le modèle ait l'information et que la demande soit vérifiable. # Laquelle de ces demandes est vérifiable ? 1. [ ] « Améliore ce code » > ❌ Une telle demande ne peut pas donner un bon résultat : rien ne permet de dire si elle a été satisfaite. 1. [x] « Ajoute les annotations de type et gère le cas de la liste vide » > ✅ On peut vérifier précisément si chacune des deux exigences a été satisfaite. 1. [ ] « Rends ce code plus propre » > ❌ Comme « améliore ce code », cette demande ne dit pas ce qui est attendu.

# Parmi ces tâches, lesquelles ces outils réalisent-ils généralement bien ? - [x] Écrire du code répétitif, comme un squelette de classe > ✅ C'est l'un de leurs points forts. - [x] Traduire en code un algorithme connu > ✅ C'est l'un de leurs points forts. - [x] Expliquer un message d'erreur > ✅ C'est l'un de leurs points forts, à condition de vérifier l'explication. - [ ] Garantir que le code produit est juste > ❌ Aucun outil ne prend cette responsabilité : c'est à vous de vérifier. # Quelle erreur typique est la plus dangereuse ? 1. [ ] Une API inventée > ❌ Elle se repère rapidement : la méthode n'existe pas, et le code échoue dès qu'il l'appelle. 1. [x] Le code plausible et faux > ✅ Il ne lève aucune erreur, passe la relecture rapide, et ne se manifeste que plus tard sur un cas particulier. 1. [ ] Une dépendance ajoutée > ❌ Elle se repère en regardant le diff, ou dès que l'import échoue. # Comment vérifier qu'un test généré teste vraiment quelque chose ? 1. [ ] Vérifier qu'il passe > ❌ Un test comme `assert True` passe toujours, sans rien tester. 1. [x] Casser le code exprès et vérifier que le test échoue > ✅ Si le test passe encore avec un code cassé, il ne teste rien. 1. [ ] Demander à l'assistant si le test est correct > ❌ L'assistant peut vous répondre de façon convaincante sans que ce soit vrai. Il faut le vérifier vous-même. # L'assistant utilise une méthode d'une bibliothèque que vous ne connaissez pas. Quel est le bon réflexe ? 1. [x] Ouvrir la documentation officielle de la bibliothèque > ✅ C'est le moyen de repérer une API inventée, c'est-à-dire une méthode qui n'existe pas. 1. [ ] Faire confiance au modèle, qui connaît mieux la bibliothèque que vous > ❌ Les API inventées font partie des erreurs typiques de ces outils. 1. [ ] Demander au modèle de confirmer que la méthode existe > ❌ Le modèle peut confirmer avec assurance une méthode qui n'existe pas. # Vous ne savez pas expliquer ce que fait une ligne du code que vous vous apprêtez à valider. Que faire ? - [x] La lire jusqu'à la comprendre > ✅ Tant que vous ne savez pas l'expliquer, le code n'est pas prêt. - [x] Demander à l'assistant de l'expliquer, puis vérifier son explication > ✅ C'est une des options proposées, à condition de ne pas prendre l'explication pour argent comptant. - [x] L'écrire autrement > ✅ C'est aussi une option, si vous ne parvenez pas à la comprendre. - [ ] La valider si les tests passent > ❌ C'est le test de l'explication : si vous ne savez pas expliquer une ligne, elle n'est pas prête, même si les tests passent. # Sur une notion que vous êtes en train d'apprendre, dans quel ordre utiliser l'assistant ? 1. [ ] Demander d'abord le code à l'assistant, puis le relire attentivement > ❌ Déléguer l'exercice supprime exactement l'effort qui fait apprendre. 1. [x] Écrire d'abord vous-même, demander ensuite une relecture, puis comparer et décider > ✅ Cet ordre garde l'assistant dans le rôle où il est le plus utile : un(e) collègue qui relit. 1. [ ] Ne jamais utiliser l'assistant pendant l'apprentissage > ❌ La fiche ne l'interdit pas : elle propose de s'en servir après avoir écrit votre propre version. # Parmi ces pratiques, lesquelles sont à éviter ? - [x] Coller du code qu'on ne comprend pas > ✅ Fait partie des règles « à ne pas faire ». - [x] Laisser un agent modifier des fichiers sans relire le diff > ✅ Fait partie des règles « à ne pas faire ». - [ ] Demander à l'assistant d'expliquer ce qu'il a produit > ❌ C'est au contraire recommandé : s'il n'y arrive pas, il faut se méfier. - [x] Envoyer du code confidentiel à un service dont on ignore où il l'envoie > ✅ Fait partie des règles « à ne pas faire ». # Un code généré par l'IA passe tous les tests et vous le committez. Qui en est responsable ? 1. [ ] L'outil qui l'a généré > ❌ Un assistant ne prend aucune responsabilité sur le code qu'il écrit. 1. [x] Vous > ✅ C'est votre nom qui sera sur le commit, et c'est vous qui devrez expliquer en soutenance ce que fait le code. Dans un produit commercial, c'est même votre responsabilité légale qui est engagée. 1. [ ] Personne, puisque les tests passent > ❌ Des tests qui passent ne garantissent pas que le code est juste, ni même que les tests testent quelque chose.