Comment se servir de l’IA dans son apprentissage ?

Prédire le prochain token

Un LLM (Large Language Model) n’est ni une conscience artificielle, ni un programme magique (même si parfois, ça en donne l’impression). C’est un modèle statistique géant dont l’unique fonction est d’estimer la distribution de probabilité du token suivant à partir d’une suite de tokens précédents.

Un token n’est pas nécessairement un mot complet. C’est un fragment textuel (environ 4 caractères en anglais, souvent moins en français ou dans du code indenté). Par exemple, la ligne Python : print("Bonjour") sera découpée par le tokenizer en plusieurs unités distinctes : print, (, ", Bon, jour, ").

Les trois piliers d’un modèle

Une fonction pure sans mémoire

Une idée reçue fréquente consiste à croire que l’IA « se souvient » du début de la discussion. C’est techniquement faux. Une API de LLM est une fonction pure et sans état (stateless) : la réponse générée ne dépend de rien d’autre que des paramètres d’entrée. Une fois la réponse envoyée, rien ne reste en mémoire vive.

Le protocole standardisé en JSON

Pour donner l’illusion d’une interaction suivie, l’application cliente (IDE, interface web, script Python) renvoie à chaque tour l’intégralité des échanges sous la forme d’une liste de dictionnaires :

		[
		  {"role": "system", "content": "Tu es un tuteur pour un élève de NSI."},
		  {"role": "user", "content": "Comment inverser une liste en Python ?"},
		  {"role": "assistant", "content": "Quelle fonction native ou découpage par slicing connais-tu ?"},
		  {"role": "user", "content": "Je pensais au slicing avec des crochets."}
		]
	

Les trois rôles fondamentaux sont :

• system : le cadre d’exécution, la persona et les contraintes techniques imposées avant l’échange (souvent invisible pour l’utilisateur final dans l’interface grand public).
• user : le texte transmis par l’utilisateur.
• assistant : les réponses générées précédemment par l’IA, réinjectées artificiellement pour simuler la continuité.

Ce qui transite réellement sur le réseau

Envoi n°1 – Initiation de la conversation

		[
		  {"role": "system", "content": "Tu es un tuteur pour un élève de NSI."},
		  {"role": "user", "content": "Comment inverser une liste en Python ?"},
		]
	

Réponse du LLM : Quelle fonction native ou découpage par slicing connais-tu ?

Envoi n°2

Pour le LLM, ce deuxième envoie n’est pas « la suite » d’une conversation entamée. C’est un nouveau jeu d’entrées qui va générer une réponse.

		[
		  {"role": "system", "content": "Tu es un tuteur pour un élève de NSI."},
		  {"role": "user", "content": "Comment inverser une liste en Python ?"},
		  {"role": "assistant", "content": "Quelle fonction native ou découpage par slicing connais-tu ?"},
		  {"role": "user", "content": "Je pensais au slicing avec des crochets."}
		]
	

Réponse du LLM : Exactement. Pour rappel, le slicing s’écrit sous la forme `liste[debut:fin:pas]`. À ton avis, quelle valeur faut-il donner au paramètre `pas` pour reculer ?

Envoi n°3

		[
		  {"role": "system", "content": "Tu es un tuteur pour un élève de NSI."},
		  {"role": "user", "content": "Comment inverser une liste en Python ?"},
		  {"role": "assistant", "content": "Quelle fonction native ou découpage par slicing connais-tu ?"},
		  {"role": "user", "content": "Je pensais au slicing avec des crochets."},
		  {"role": "assistant", "content": "Exactement. Pour rappel, le slicing s’écrit sous la forme `liste[debut:fin:pas]`. À ton avis, quelle valeur faut-il donner au paramètre `pas` pour reculer ?"},
		  {"role": "user", "content": "Un pas de -1 ? Donc quelque chose comme `liste[::-1]` ?"}
		]
	

Et ainsi de suite…

Complexité algorithmique et explosion des coûts

Chaque échange ajoute des tokens à l’historique global. Si une requête individuelle au tour n possède une taille en O(n), la consommation cumulée de tokens sur une conversation de N tours suit une progression en O(N²)

Les couches de contexte

La réponse d’un LLM dépend uniquement des entrées fournies dans sa fenêtre de contexte. Plus ces entrées sont précises, pertinentes et bien structurées, plus la réponse sera exploitable.

Dans une interaction typique, ce contexte agrège trois éléments :

1. Les instructions structurelles (rôle system) : les préférences de l’utilisateur, le persona ou rôle attribué à l’IA, ainsi que les contraintes globales (technologies imposées, format de réponse attendu).
2. Les données de travail (fichiers et documents) : les extraits de code, fichiers joints ou documentations injectés pour donner de la matière au modèle.
3. L’historique de la session : les allers-retours textuels précédents (user et assistant) qui maintiennent la continuité du fil de discussion.

Le prompt utilisateur final (user) vient simplement s’ajouter au bout de cet empilement.

La taille de la fenêtre de contexte

Chaque modèle dispose d’une limite physique de tokens entrants (généralement entre 200.000 et 1 million de tokens). Lorsque l’historique cumulé dépasse cette limite, les implémentations logicielles doivent tronquer les messages les plus anciens (principe FIFO : First In, First Out), ce qui fait disparaître les premières contraintes fixées.

Le phénomène du « Lost in the Middle »

Un prompt ne doit pas être une bouillie informe de texte, sous peine de rendre la tâche du LLM plus difficile (et donc de réduire la pertinence de la réponse).

La supériorité du Markdown

Les LLMs ont été entraînés massivement sur des dépôts de code contenant du Markdown. Ce format structuré léger offre le meilleur ratio expressivité/consommation de tokens. L’utilisation explicite de délimiteurs aide le réseau de neurones à segmenter les rôles :

• Titres (#, ##) pour séparer les sections.
• Listes à puces.
• Blocs de code délimités par des triples accents graves (```python).

Le Markdown est très simple, il s’apprend en 5 minutes si on se limite à ce qui est utile pour interagir avec un LLM. Voir cette page.

La structure d’un prompt efficace

Un prompt efficace doit être rédigé comme une spécification algorithmique et comporter 3 éléments clés :

			Je travaille sur un algorithme de recherche dichotomique dans un tableau trié.
			Tu vas m’aider à débuguer mon code Python en **restant conforme au programme de NSI**.
		

			```Python
			def dicho(tab, cible):
				g = 0
				d = len(tab)
				while g <= d:
					m = (g + d) // 2
					if tab[m] == cible:
						return True
					elif tab[m] < cible:
						g = m + 1
					else:
						d = m - 1
				return False
			```
		

			- Identifie l’erreur d’indice (hors bornes) présente dans cette implémentation.
			- Propose la correction minimale sans modifier le reste de l’algorithme.
			- Rédige ta réponse de façon concise.
		

Copier l’énoncé d’un projet dans l’IA pour coller directement le code généré dans son éditeur crée l’illusion de la compétence. En pratique, vous ne développez aucune des structures mentales nécessaires à l’analyse algorithmique.

Transformer l’IA en tuteur

L’utilisation la plus rentable sur le plan pédagogique consiste à forcer l’IA à jouer le rôle d’un accompagnateur qui refuse de donner la solution brute. Voici une consigne système efficace :

		Je suis élève de spécialité NSI et tu vas agir comme mon tuteur.
		Ne fournis JAMAIS le code corrigé directement.
		Si mon code contient un bug, pose-moi des questions ciblées sur l’état
		des variables ou propose-moi un jeu de tests qui fait échouer mon
		programme pour me faire trouver l’erreur par moi-même.
	

Outils techniques recommandés : Google AI Studio

Pour dépasser les limitations des interfaces grand public (qui ajoutent des instructions systèmes cachées et réécrivent parfois vos requêtes), l’usage de plateformes comme Google AI Studio permet un contrôle technique total :

• Champ System Instructions totalement éditable.
• Réglage direct des paramètres du modèle (température, top-p, filtres de sécurité).
• Surveillance exacte du compteur de tokens consommés.
• Accès gratuit aux versions récentes des modèles sans fonctionnalités parasites.

L’architecture de sécurité à trois couches

Les modèles commerciaux n’utilisent pas de simples expressions régulières (regex) pour bloquer les contenus malveillants. Ils reposent sur une chaîne de validation :

1. Filtre d’entrée (Classifieur sentinelle) : Un modèle dédié, compact et rapide, analyse le prompt entrant. S’il détecte des catégories interdites (cyberattaques, contenus toxiques, armes), la requête est immédiatement rejetée.
2. Alignement interne (RLHF) : Lors de l’apprentissage par renforcement à partir de retours humains, le modèle principal est entraîné à privilégier des patterns de refus face à des requêtes dangereuses formulées de manière détournée.
3. Filtre de sortie : Le flux de tokens générés est contrôlé en temps réel. Si la génération dérive vers du contenu illégal ou dangereux, le flux est interrompu côté serveur.

Confidentialité des données et RGPD

• Interfaces web gratuites : Sauf mention contraire explicite dans les paramètres d’opt-out, l’intégralité du texte saisi peut être conservée et utilisée pour réentraîner les futures versions des modèles commerciaux.
• Règle absolue : Ne jamais copier-coller d’identifiants, de mots de passe, de clés d’API (tokens GitHub, etc.), ni de données personnelles relatives à des tiers.
• Différence avec les API : L’accès programmatique via API professionnelle garantit généralement l’absence de réentraînement sur les requêtes transmises (politique Zero Data Retention).

Sobriété numérique

Le calcul matriciel requis pour l’inférence d’un modèle de plusieurs dizaines de milliards de paramètres sollicite fortement les processeurs graphiques (GPU) et l’infrastructure de refroidissement des centres de données. Adopter une démarche d’éco-responsable consiste à :

• Purger ses conversations pour éviter de renvoyer inutilement des contextes massifs en O(N²).
• Choisir le modèle adapté : un modèle compact et rapide suffit largement pour analyser une fonction Python de 15 lignes, rendant disproportionné l’usage d’un modèle géant à forte consommation énergétique.

La distinction Cerveau vs Corps

Un LLM ne manipule aucun fichier, ne lance aucun compilateur et n’a aucun accès au système d’exploitation de votre machine. Il se contente de manipuler des représentations symboliques et de produire des chaînes textuelles.

La boucle algorithmique ReAct (Reason + Act)

L’orchestrateur exécute une boucle algorithmique classique (boucle while) qui articule la réflexion, l’action et l’observation :

		# Pseudo-code algorithmique d’un Agent local :

		historique = [ {
			"role": "system",
			"content": "Outils disponibles : ecrire_fichier(chemin, contenu), executer_commande(cmd)"
		}, {
			"role": "user",
			"content": "Génère un script tri.py et teste-le avec Python."
		} ]

		termine = False

		while not termine:
		|	# 1. Appel du LLM
		|	reponse = appeler_llm(historique)
		|
		|	# 2. Analyse de la réponse : demande-t-elle une action ?
		|	if reponse.demande_outil:
		|	|	nom = reponse.outil_nom
		|	|	params = reponse.outil_parametres
		|	|
		|	|	# 3. L’orchestrateur local exécute l’action réelle sur la machine
		|	|	sortie_terminal = executer_sur_machine(nom, params)
		|	|
		|	|	# 4. Le résultat est ajouté à l’historique pour l’itération suivante
		|	|	historique.append({"role": "assistant", "content": f"Appel de {nom}"})
		|	|	historique.append({"role": "tool", "content": sortie_terminal})
		|	else:
		|	|	# Aucun outil requis : le LLM a terminé la tâche
		|	|	print("Message de l’Agent :", reponse.texte)
		|	|	termine = True
	

Trace d’exécution pas à pas

1. L’utilisateur demande : « Corrige le fichier calcul.py et vérifie qu’il fonctionne. »
2. Le LLM inspecte l’état et émet : TOOL_CALL: lire_fichier("calcul.py").
3. L’orchestrateur lit le fichier sur le disque local et renvoie le code source au LLM sous le rôle tool.
4. Le LLM détecte une erreur de syntaxe et émet : TOOL_CALL: ecrire_fichier("calcul.py", code_corrige).
5. L’orchestrateur modifie le fichier sur la machine.
6. Le LLM émet : TOOL_CALL: executer_commande("python3 calcul.py").
7. L’orchestrateur lance la commande dans un terminal bash et renvoie la sortie standard (stdout: 42) au modèle.
8. Le LLM constate le succès d’exécution et répond à l’humain : « J’ai corrigé l’erreur de syntaxe, le script s’exécute correctement et renvoie 42. »

Risques et consommation de ressources

• Coût en tokens démultiplié : comme la boucle effectue plusieurs allers-retours et réinjecte à chaque étape les sorties d’outils (parfois des traces de terminal complètes de centaines de lignes), une seule consigne utilisateur en mode agent peut consommer 20 à 50 fois plus de tokens qu’un simple échange textuel.
• Sécurité du système hôte : un LLM soumis à une injection indirecte de prompt (par exemple en lisant un fichier de code piégé sur le web) pourrait émettre l’ordre d’exécuter une commande destructrice comme rm -rf ~. C’est pourquoi un orchestrateur rigoureux doit systématiquement exiger une confirmation humaine explicite avant d’exécuter des modifications critiques sur la machine.