Module 07 · Leçon 1

Les différentes formes d'outils de programmation IA

Complétion, conversation, agent dans l'éditeur, agent en ligne de commande – les outils de programmation IA se rangent grosso modo en ces quatre formes. Ce que fait chacune, à quelles tâches elle convient, et comment contrôler ce qu'un agent peut toucher sur votre ordinateur.

  • Environ 30 minutes
  • Niveau : Débutant
  • Testé : 2026-09-14, fonctions des produits selon leur documentation officielle, aucune exécution nécessaire

Le code et les sorties des programmes sont reproduits tels qu’ils ont tourné : commentaires et sorties sont donc en chinois.

Les noms des outils de programmation IA changent vite ; tous les quelques mois arrivent de nouveaux produits et de nouvelles fonctions. Mais si on les classe selon « tout ce qu'ils peuvent faire à votre place », il n'y a en gros que quatre formes. Comprendre ce que fait chaque forme est plus utile que retenir quel produit a quel bouton : quand vous changez d'outil, ces jugements restent valables.

1. La complétion

Vous tapez dans l'éditeur, et derrière le curseur, en gris, il prédit ce que vous allez écrire ensuite ; Tab pour accepter, continuez à taper pour ignorer. GitHub Copilot a été le premier à familiariser beaucoup de gens avec cette forme, aujourd'hui intégrée à la plupart des éditeurs. Chez Cursor, par exemple, la complétion s'appelle Tab ; selon la description officielle, elle fait ses suggestions d'après vos modifications récentes, le code environnant et les erreurs signalées par l'analyse du code.

Du point de vue du module 01, c'est l'application la plus directe de « prédire le token suivant » : le code avant et après le curseur sert d'entrée, et le modèle prédit la suite.

Adaptée : vous savez ce que vous voulez écrire, vous ne voulez simplement pas le taper caractère par caractère. Compléter le reste d'une fonction, écrire du code répétitif, écrire la ligne suivante sur le modèle de la précédente.

Pas adaptée : vous ne savez pas encore clairement ce que vous voulez écrire. La complétion ne fait que prolonger ce que vous avez commencé ; elle ne réfléchit pas à une solution pour vous.

Attention : elle complète vite et de façon convaincante, et on appuie facilement sur Tab sans réfléchir. Les noms de paramètres et de fonctions complétés sont « prédits » par le modèle et n'existent pas forcément (les hallucinations de la leçon 2 du module 01).

2. La conversation

Poser des questions dans une fenêtre de discussion : « Que signifie cette erreur ? », « Écris-moi une fonction qui analyse un CSV. » Ce peut être un chatbot dans le navigateur, ou un panneau de discussion dans la barre latérale de l'éditeur.

La différence avec la complétion : vous décrivez le besoin, il fournit un bloc de code entier ou une explication, et c'est vous qui décidez de l'utiliser. Il ne voit que ce que vous lui collez (les panneaux de discussion des éditeurs joignent généralement automatiquement le fichier courant).

Adaptée : expliquer du code incompréhensible, demander une notion, écrire une petite fonction indépendante, discuter des avantages et inconvénients de plusieurs solutions.

Pas adaptée : les tâches qui demandent de comprendre et de modifier de nombreux fichiers à la fois. Il faut lui coller à la main tous les fichiers concernés, puis reporter à la main sa réponse dans les bons fichiers, et on en oublie facilement.

3. L'agent dans l'éditeur

Vous lui donnez une tâche dans l'éditeur, et il lit lui-même les fichiers du projet, décide quoi modifier, modifie directement les fichiers, et certains peuvent aussi exécuter des commandes (lancer les tests, installer des dépendances). Le mode Agent de Cursor et les « modes agent » de divers éditeurs en font partie.

C'est l'agent du module 05 : un modèle plus un ensemble d'outils (lire des fichiers, chercher dans le code, modifier des fichiers, exécuter des commandes), qui décide lui-même dans une boucle de l'étape suivante. La boucle d'un peu plus de cent lignes de la leçon 2 du module 05 en est le cœur.

Adapté : les modifications qui touchent plusieurs fichiers, les tâches qui demandent de comprendre le code avant d'agir, les tâches qui doivent être vérifiées par des tests après modification.

Attention : il modifie directement vos fichiers. Les modifications s'affichent dans l'éditeur, et vous pouvez les accepter ou les annuler une par une. Dès qu'elles sont nombreuses, il faut git pour les gérer (leçon 3).

4. L'agent en ligne de commande

Un agent comme le précédent, mais qui tourne dans le terminal au lieu de l'éditeur. En septembre 2026, on trouve couramment Claude Code d'Anthropic et Codex CLI d'OpenAI, entre autres. Pour Claude Code, selon la documentation officielle, on l'installe sous macOS ou Linux, puis on le lance dans le dossier du projet :

curl -fsSL https://claude.ai/install.sh | bash
cd 你的项目
claude

Codex CLI s'installe notamment avec npm install -g @openai/codex, puis se lance avec codex.

Les agents en ligne de commande ne sont liés à aucun éditeur ; vous pouvez utiliser l'éditeur de votre choix. Ils s'intègrent aussi plus facilement dans des scripts et des processus automatisés, par exemple pour leur faire exécuter une tâche fixe en intégration continue.

Adapté : les tâches plutôt grosses, les tâches qui demandent d'exécuter beaucoup de commandes (lancer des tests, consulter des journaux, manipuler git), les tâches sur lesquelles on veut le faire travailler un moment d'affilée.

Attention : il peut exécuter des commandes sur votre ordinateur. C'est ce qui le rend le plus utile, et c'est aussi là qu'il faut être le plus prudent.

Contrôler ce qu'un agent peut faire

Les deux dernières formes sont des agents : ils peuvent toucher à vos fichiers et exécuter des commandes. La leçon 8 du module 05 l'a dit : un agent capable d'agir doit avoir des droits limités. Heureusement, ces outils proposent tous des moyens de contrôle. Exemple avec les deux outils en ligne de commande (documentation officielle de septembre 2026) :

Les modes d'autorisation de Claude Code, qu'on bascule avec Maj+Tab ou qu'on fixe au lancement avec --permission-mode :

Mode Ce qu'il peut faire sans vous demander
default (appelé Manual dans l'interface) Seulement lire des fichiers ; tout le reste demande votre confirmation
acceptEdits Lire et modifier des fichiers, et les opérations de fichiers courantes comme mkdir et mv
plan Lecture seule : il propose d'abord un plan et ne modifie aucun fichier avant votre accord
auto Toutes les opérations, avec un contrôle de sécurité en arrière-plan par un modèle distinct
dontAsk Seulement les outils autorisés à l'avance, tout le reste est refusé ; adapté aux scripts automatisés
bypassPermissions Toutes les opérations, sans aucun contrôle ; selon la documentation officielle, à n'utiliser que dans un conteneur ou une machine virtuelle isolés

Le bac à sable et les approbations de Codex CLI, réglés séparément sur deux axes. Le bac à sable décide de ce qu'il peut toucher : read-only (lecture seule), workspace-write (écriture seulement dans le dossier de travail, valeur par défaut), danger-full-access (aucune limite, déconseillé officiellement). La politique d'approbation décide quand il vous demande : le on-request par défaut vous demande quand il veut écrire hors du dossier de travail ou accéder au réseau, never ne demande jamais.

Les noms précis des modes changeront peut-être, mais la logique est générale, et concorde parfaitement avec la conclusion de la leçon 8 du module 05 :

  • Projet inconnu ou modification importante : d'abord le mode plan ou lecture seule. Il lit le code et propose une solution ; une fois que vous l'avez examinée, vous lui donnez plus de latitude.
  • Ne le laisser écrire que dans le dossier de travail. Il ne doit pas pouvoir modifier à sa guise d'autres fichiers de votre ordinateur.
  • Quand il faut « tout ouvrir », le placer dans un conteneur ou une machine virtuelle. En cas de problème, votre véritable environnement n'est pas touché.
  • Les opérations dangereuses demandent votre confirmation. Pousser du code, supprimer des fichiers, accéder au réseau, installer des dépendances : il ne doit pas en décider seul.

Comment choisir

Tâche Forme adaptée
Compléter au fil de l'écriture Complétion
Comprendre un bout de code ou une erreur Conversation
Écrire une petite fonction ou un script indépendant Conversation
Modifier une fonctionnalité touchant trois à cinq fichiers Agent dans l'éditeur
Corriger un bug qui ne se confirme qu'en relançant les tests à plusieurs reprises Agent dans l'éditeur ou en ligne de commande
Refactoring de grande ampleur, mise à jour de dépendances Agent en ligne de commande, sur une branche git dédiée

La plupart des gens en utilisent plusieurs à la fois : la complétion activée en écrivant, la conversation face à un problème, un agent pour les tâches plus grosses.

La différence entre ces formes tient au fond à la part de contrôle que vous cédez : la complétion n'écrit que quelques caractères, que vous confirmez chacun avec Tab ; la conversation écrit un bloc, et vous décidez de l'utiliser ou non ; l'agent décide à votre place quels fichiers modifier et quelles commandes exécuter. Plus vous cédez de contrôle, plus vous gagnez de travail, et plus vous avez de choses à vérifier. La leçon suivante montre comment lui faire mieux comprendre votre projet, la leçon 3 comment vérifier ce qu'il a fait.

Exercices

  1. Prenez une petite fonctionnalité que vous avez écrite récemment, et faites-la réaliser par l'IA une fois en conversation, une fois en agent. Comparez : combien de temps avez-vous passé à décrire le besoin, combien à vérifier le résultat ?
  2. Dans l'outil de programmation IA que vous utilisez, trouvez les réglages d'autorisation ou de bac à sable. Que lui permet-il par défaut ? Pour quoi vous demande-t-il ? Réglez-le au niveau qui vous semble adapté.
  3. Dans un projet sans importance, donnez une tâche à un agent en mode plan (ou en ne l'autorisant qu'à lire, pas à modifier), et ne regardez que la solution qu'il propose, sans le laisser agir. En quoi sa solution diffère-t-elle de ce que vous auriez imaginé ?

Auto-test

1. Quelle est la différence la plus fondamentale entre complétion, conversation et agent ?

La part de contrôle cédée. La complétion ne prédit que les quelques caractères suivants, que vous confirmez à chaque fois ; la conversation fournit un bloc de code, et vous décidez de son usage ; l'agent décide lui-même quels fichiers lire, quoi modifier et quelles commandes exécuter. Plus de contrôle cédé, plus de travail gagné, et plus de choses à vérifier.

2. La première fois qu'on confie un projet inconnu à un agent, quels réglages d'autorisation faut-il utiliser ?

D'abord le mode plan ou lecture seule : il lit le code et propose une solution, et ce n'est qu'après votre examen qu'il est autorisé à modifier. Limiter l'écriture au dossier de travail, et soumettre à votre confirmation les opérations comme pousser du code, supprimer, accéder au réseau ou installer des dépendances.

3. Pourquoi dit-on que le mode « tout ouvert » d'un agent ne doit s'utiliser que dans un conteneur ou une machine virtuelle ?

Dans ce mode, aucune commande n'est vérifiée. S'il prend une mauvaise décision, ou s'il est manipulé par un contenu qu'il a lu (l'injection de prompt de la leçon 8 du module 05), il peut supprimer des fichiers, divulguer des clés ou endommager le système. Dans un environnement isolé, un problème ne touche ni votre véritable ordinateur ni vos données.