Installer Cline ne suffit pas pour en tirer le meilleur : un agent mal piloté part dans tous les sens, modifie trop de fichiers d’un coup et vous fait perdre le fil. La force de Cline tient à une idée simple — séparer la réflexion de l’action — incarnée par ses deux modes, Plan et Act. Bien les utiliser transforme l’agent d’un exécutant impulsif en un collaborateur méthodique. À la fin de ce tutoriel, vous saurez cadrer une tâche, fournir le bon contexte et garder la main à chaque étape.
📍 Guide principal de la série : Coder avec une IA en local : Cline, Ollama et les assistants souverains.
Ce que vous allez apprendre
- Distinguer et utiliser les modes Plan et Act ;
- Fournir le bon contexte à l’agent grâce aux mentions de fichiers ;
- Relire, valider ou refuser les modifications via les diffs ;
- Revenir en arrière grâce aux checkpoints ;
- Régler les approbations pour aller plus vite sans perdre le contrôle.
Ce que vous allez construire
Une vraie fonctionnalité du projet « carnet » : une commande qui liste les notes existantes, filtrées par mot-clé. Vous la ferez concevoir en mode Plan, puis réaliser en mode Act, en supervisant chaque diff. L’objectif n’est pas seulement le code produit, mais la méthode de pilotage que vous garderez pour tous vos projets.
Prérequis
- Cline installé et relié à Ollama (voir Installer Cline dans VS Code et le brancher sur Ollama) ;
- Le projet « carnet » avec sa structure de départ ;
- Niveau : intermédiaire débutant.
⏱️ Temps estimé : environ 25 minutes.
Étape 1 — Comprendre Plan et Act
La distinction est au cœur de Cline et mérite qu’on s’y arrête. En mode Plan, l’agent lit votre code, pose des questions et propose une stratégie, mais ne modifie rien. C’est la phase de réflexion : on s’aligne sur ce qu’il faut faire avant de toucher au projet. En mode Act, l’agent exécute le plan, fichier par fichier, en demandant votre approbation à chaque étape.
Pourquoi cette séparation change tout ? Parce qu’elle évite le travers classique des assistants qui se jettent sur le clavier et écrivent du code avant d’avoir compris le besoin. Avec Plan d’abord, vous corrigez le tir sur le papier — bien moins coûteux que de défaire des fichiers déjà modifiés. On bascule d’un mode à l’autre via un sélecteur dans le panneau de Cline.
✅ Point d’étape — Vous repérez le sélecteur Plan / Act dans le panneau Cline et comprenez que Plan ne modifie aucun fichier. Si l’agent commence à écrire en mode Plan, c’est qu’il est en réalité passé en Act : vérifiez le sélecteur.
Étape 2 — Concevoir en mode Plan
On attaque la nouvelle fonctionnalité par la réflexion. Passez en mode Plan et décrivez l’objectif sans entrer dans l’implémentation :
En mode Plan : je veux une commande "list" qui affiche
toutes les notes du fichier JSON, avec une option pour
filtrer par mot-clé dans le titre. Propose une approche.L’agent lit le code existant de « carnet », puis propose un plan : où ajouter la commande, comment lire le fichier, comment filtrer. Lisez attentivement. C’est le moment d’ajuster : « plutôt qu’une option, fais deux sous-commandes » ou « gère le cas où le fichier est vide ». Vous itérez sur la stratégie, gratuitement en termes de risque, puisque rien n’est encore écrit. Quand le plan vous convient, vous passez à l’action.
✅ Point d’étape — Vous avez un plan clair et validé, sans qu’aucun fichier n’ait été modifié. Si le plan reste flou, c’est souvent que la demande l’était : reformulez avec plus de précisions.
Étape 3 — Donner le bon contexte avec les mentions
Un agent ne devine pas ce qu’il ne voit pas. Pour une bonne réponse, il faut lui pointer les bons fichiers. Cline permet de mentionner explicitement des éléments de contexte avec le symbole arobase dans votre message : un fichier précis, un dossier entier, voire le contenu d’un problème affiché dans VS Code.
Par exemple, pour que l’agent travaille en connaissance de cause sur le bon fichier, écrivez quelque chose comme « modifie @carnet.py pour ajouter la commande list ». En ciblant le fichier, vous évitez que l’agent ne parte explorer tout le projet — ce qui, avec un modèle local à contexte limité, fait une vraie différence de qualité et de vitesse. La règle d’or du pilotage local : donner juste assez de contexte, pas plus.
Étape 4 — Exécuter en mode Act et relire les diffs
Le plan est prêt : basculez en mode Act et laissez l’agent réaliser. Il commence à écrire le code de la commande « list ». Chaque modification s’affiche en diff — l’ancien et le nouveau code côte à côte. C’est votre point de contrôle : relisez, et seulement alors validez. Si quelque chose ne va pas, refusez et expliquez ce qui cloche ; l’agent corrige.
Quand le code touche au but, l’agent propose souvent d’exécuter le programme pour vérifier. Autorisez la commande : il lance « carnet list », lit la sortie, et confirme que les notes s’affichent. Cette boucle « écrire, exécuter, observer » est exactement ce qui fait la valeur d’un agent — il ne se contente pas de proposer du code, il vérifie qu’il marche. À la fin, votre commande « list » fonctionne, conçue puis réalisée sous votre supervision.
✅ Point d’étape — La commande « list » affiche les notes, et le filtre par mot-clé fonctionne. Si un diff vous semble douteux, refusez-le : mieux vaut une itération de plus qu’un fichier cassé.
Étape 5 — Checkpoints et retour arrière
Même bien piloté, un agent se trompe parfois. Cline enregistre des checkpoints à chaque étape, comme des points de sauvegarde. Si une série de modifications a dégradé le projet, vous revenez à un checkpoint antérieur d’un clic, sans avoir à défaire les changements à la main ni à vous battre avec l’historique Git.
C’est un filet de sécurité précieux quand on explore. Vous pouvez tenter une approche audacieuse, constater qu’elle ne mène nulle part, et revenir à l’état d’avant en quelques secondes. Combiné aux diffs, ce mécanisme rend l’expérimentation sûre : vous gardez toujours un chemin de retour. Notez toutefois que les checkpoints de Cline ne remplacent pas vos commits : continuez à versionner votre projet normalement.
Étape 6 — Régler les approbations
Valider chaque action devient vite répétitif sur les tâches simples. Cline permet d’auto-approuver certaines opérations — par exemple la lecture de fichiers, ou l’exécution de commandes jugées sûres. Bien réglé, cela fluidifie le travail ; mal réglé, cela donne à l’agent trop de latitude.
Le bon dosage dépend de votre confiance et de la sensibilité du projet. Pour apprendre, gardez l’approbation manuelle sur les écritures de fichiers et les commandes terminal : vous voyez tout passer. Quand vous maîtrisez, auto-approuvez les lectures pour gagner du temps, mais restez prudent sur tout ce qui modifie ou exécute. Nous reviendrons en détail sur ces garde-fous dans le tutoriel consacré à la sécurité de l’agent.
✅ Point d’étape — Vous savez où régler les auto-approbations et avez choisi un niveau adapté à votre projet. En cas de doute, restez en approbation manuelle.
Cadrer durablement l’agent avec des règles
Répéter les mêmes consignes à chaque tâche est fastidieux. Cline permet de définir des règles persistantes qui s’appliquent automatiquement à toutes vos interactions sur un projet — l’équivalent d’un mode d’emploi que l’agent garde toujours sous les yeux. On y consigne les conventions du projet : style de code, langue des commentaires, bibliothèques à privilégier, ou interdictions.
Concrètement, vous placez ces instructions dans un fichier de règles à la racine du projet. Par exemple : « commente le code en français », « utilise uniquement la bibliothèque standard de Python », « écris un test pour chaque nouvelle fonction ». Dès lors, l’agent applique ces consignes sans que vous ayez à les rappeler. Pour le projet « carnet », une règle du type « toutes les données sont stockées en JSON, jamais en base de données » garantit la cohérence d’une session à l’autre. Ce cadrage durable est l’un des leviers les plus sous-estimés pour obtenir un travail régulier et conforme à vos attentes, surtout avec un modèle local qu’il vaut mieux guider précisément.
Un répertoire de bonnes consignes
La qualité du résultat dépend énormément de la façon dont vous formulez vos demandes. Quelques tournures reviennent et donnent presque toujours de meilleurs résultats avec un agent ; gardez-les en tête.
- Donner un critère de réussite : « ajoute la commande list ; elle est réussie si « carnet list » affiche les titres et les dates » — l’agent sait quand s’arrêter et peut vérifier lui-même ;
- Imposer le périmètre : « ne modifie que @carnet.py, ne touche pas aux autres fichiers » — on évite les débordements ;
- Demander d’abord le plan : « explique ton approche avant d’écrire » — utile même hors du mode Plan ;
- Faire vérifier : « lance le programme et montre-moi la sortie » — on transforme l’agent en testeur de son propre code ;
- Cadrer le style : « garde les fonctions courtes et nomme les variables en français » — cohérence du projet.
Ces habitudes paraissent évidentes une fois énoncées, mais elles font la différence entre un agent qui patine et un agent productif. Plus votre consigne est précise sur le quoi et le comment vérifier, moins l’agent improvise — un atout décisif quand on travaille avec un modèle local au contexte compté.
Pièges fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| L’agent modifie des fichiers en mode Plan | Vous êtes en réalité en mode Act | Vérifier le sélecteur Plan / Act |
| Réponses hors sujet | Contexte insuffisant ou trop large | Mentionner précisément le fichier concerné (@fichier) |
| L’agent ralentit et se perd | Contexte saturé sur un modèle local | Démarrer une nouvelle tâche, découper le travail |
| Un diff casse le projet | Modification erronée validée trop vite | Revenir à un checkpoint, relire avant de valider |
| L’agent agit sans demander | Auto-approbation trop permissive | Restreindre les auto-approbations |
Réalités du terrain
Sur un modèle local, le pilotage compte encore plus que sur un gros modèle cloud : un contexte maîtrisé et des tâches courtes compensent largement une puissance moindre. Prenez l’habitude de penser en petites missions enchaînées plutôt qu’en gros chantier confié d’un bloc. Cette discipline, qui semble lente au début, vous rend en réalité bien plus rapide : moins d’allers-retours, moins de code à défaire, et un agent qui reste réactif même sur une machine modeste. Le mode Plan, en particulier, est votre meilleur allié quand le modèle est limité : aligner la stratégie avant d’écrire évite de gaspiller des générations coûteuses.
Récapitulatif
Vous savez désormais séparer réflexion et action avec Plan et Act, fournir le bon contexte par les mentions, relire et valider les diffs, revenir en arrière grâce aux checkpoints, et doser les approbations. Vous avez conçu puis réalisé une vraie commande du projet « carnet » en gardant le contrôle. Ce pilotage méthodique est la compétence centrale de tout le parcours. Reste à étendre les pouvoirs de l’agent en lui branchant des outils externes — c’est l’objet du tutoriel suivant sur les serveurs MCP.
Aide-mémoire
| Élément | Rôle |
|---|---|
| Mode Plan | Réfléchir et proposer, sans modifier |
| Mode Act | Exécuter, avec approbation par étape |
| @fichier / @dossier | Cibler le contexte fourni à l’agent |
| Diff | Relire chaque modification avant validation |
| Checkpoint | Revenir à un état antérieur |
| Auto-approbation | Fluidifier les actions sûres (à doser) |
À vous de jouer
Défi : en mode Plan, demandez à Cline d’ajouter une commande « delete » qui supprime une note par son identifiant, en gérant le cas où l’identifiant n’existe pas. Validez le plan, puis réalisez-le en Act et testez le cas d’erreur.
Voir une piste de solution
En Plan : « ajoute une commande delete <id> à @carnet.py, qui retire la note correspondante et affiche un message clair si l’id est introuvable ». Affinez le plan (message d’erreur, code de sortie), basculez en Act, relisez le diff, puis testez avec un identifiant inexistant pour vérifier que le message d’erreur s’affiche sans planter le programme.
Tutoriels associés
- Installer Cline dans VS Code et le brancher sur Ollama — le point de départ.
- Sécuriser un agent de code local — pour cadrer les approbations en profondeur.
Pour aller plus loin
- 🔝 Revenir au guide principal : Coder avec une IA en local : Cline, Ollama et les assistants souverains.
- Documentation officielle : docs.cline.bot (Plan & Act, checkpoints).
FAQ
Dois-je toujours passer par le mode Plan ?
Pas pour une retouche triviale. Mais dès qu’une tâche touche plusieurs fichiers ou demande un choix d’architecture, Plan d’abord vous fait gagner du temps et évite les erreurs.
Les checkpoints remplacent-ils Git ?
Non. Ils servent à annuler rapidement le travail de l’agent en cours de session. Continuez à versionner votre projet avec Git normalement.
Pourquoi cibler les fichiers avec l’arobase ?
Parce qu’un modèle local a un contexte limité. Lui pointer le bon fichier améliore nettement la pertinence et la vitesse des réponses.
L’auto-approbation est-elle dangereuse ?
Elle l’est si elle couvre l’écriture de fichiers ou l’exécution de commandes. Réservez-la aux lectures tant que vous n’avez pas mis en place de garde-fous solides.