Roo Code : l'agent de code local dans l'éditeur

#Ce que c'est

Entre la complétion de code, qui devine la ligne suivante pendant que vous tapez, et l'agent autonome, qui travaille seul dans un conteneur sans supervision continue, il existe une catégorie intermédiaire : l'agent dans l'éditeur. Il voit votre projet ouvert, comprend l'arborescence des fichiers et leurs dépendances, propose des modifications que vous validez avant qu'elles ne touchent le disque, et exécute des commandes dans votre terminal avec votre accord explicite à chaque fois. Roo Code appartient à cette famille, aux côtés de projets comme Cline dont il partage largement la philosophie.

L'intérêt par rapport à un assistant conversationnel est qu'il n'y a plus de copier-coller : les modifications arrivent sous forme de diff dans les fichiers concernés. L'intérêt par rapport à un agent autonome est que vous restez dans la boucle à chaque étape, ce qui compte d'autant plus que le modèle est petit. Le projet, publié sous licence Apache 2.0, avait dépassé 20 000 étoiles sur GitHub depuis son lancement fin 2024, un rythme d'adoption rapide dans une catégorie devenue très concurrentielle — avant l'annonce d'arrêt détaillée ci-dessous.

#L'extension est arrêtée depuis mai 2026 : ce que ça change

C'est l'information la plus importante de ce guide, et celle que beaucoup de tutoriels encore en ligne ne mentionnent pas. Matt Rubens, le fondateur, a annoncé le 21 avril 2026 l'arrêt de Roo Code : dernière publication le 15 mai 2026, dépôt GitHub ensuite archivé — verrouillé en lecture seule, sans plus aucun correctif, y compris de sécurité. Une vérification directe du dépôt le confirme : statut archivé, dernier commit daté du 15 mai 2026. L'équipe s'est entièrement redéployée sur Roomote, un agent cloud piloté depuis Slack, jugeant que l'éditeur de code n'est plus, selon elle, l'avenir du travail avec un agent IA.

#Les modes, et pourquoi c'est la bonne idée

La particularité de Roo Code est de séparer les personnalités. Cinq modes sont intégrés par défaut : Code, pour écrire et modifier avec un accès complet aux outils ; Ask, un assistant technique qui répond en détail mais ne touche à rien (lecture et MCP seulement) ; Architect, un planificateur dont les permissions d'écriture se limitent aux fichiers markdown, pensé pour concevoir avant d'agir ; Debug, orienté diagnostic systématique avec un accès complet ; et Orchestrator, aussi appelé « Boomerang Mode », qui découpe une tâche complexe et la délègue aux autres modes. Il reste possible d'en définir d'autres, avec leurs propres consignes et leurs propres permissions.

Sur un modèle local, c'est plus qu'un confort. Un mode Ask qui n'a pas le droit d'écrire supprime la catégorie d'incidents où un modèle trop petit modifie un fichier par excès de zèle. Restreindre les permissions par mode est le principal moyen de rendre un petit modèle utilisable sans risque, et c'est incidemment ce qui rapproche le plus Roo Code d'une bonne pratique de sécurité générale sur les agents : donner à chaque rôle uniquement ce dont il a besoin, jamais plus.

#Le brancher sur un modèle local

1. 01
   Servir le modèle

   Ollama ou tout point d'accès compatible OpenAI. Pour un usage individuel, Ollama suffit largement.
2. 02
   Choisir Ollama comme fournisseur dans l'extension

   Renseigner le nom ou le tag du modèle. L'adresse de base par défaut est http://localhost:11434 ; une clé d'API n'est nécessaire que si votre serveur Ollama en exige une.
3. 03
   Régler la fenêtre de contexte au bon endroit

   C'est le piège le plus documenté : par défaut, Roo Code se cale sur le réglage num_ctx défini dans le Modelfile du modèle Ollama, pas sur une valeur propre à l'extension. Augmenter le contexte se fait donc côté Ollama (Modelfile ou variable d'environnement), pas dans les réglages de Roo Code.
4. 04
   Commencer en mode Ask

   Poser trois questions sur le projet avant d'autoriser la moindre modification, avec un mode qui n'a que des permissions de lecture, donne une mesure honnête de ce que le modèle comprend réellement du code.

#Quel modèle, vraiment

Un modèle orienté code de taille moyenne bat presque toujours un modèle généraliste plus gros sur cet exercice, parce qu'il a vu davantage de formats stricts et de diffs pendant son entraînement plutôt que de la prose générale. La différence se voit surtout sur la capacité à produire un diff qui s'applique du premier coup, sans erreur de contexte ou de numéro de ligne — un détail technique qui compte plus, en pratique, que la qualité générale des réponses du modèle.

• Cline : l'autre agent d'édition, comparé
• Aider : la même idée, dans le terminal
• Faire relire son code par un modèle local

#Orchestrator : découper une tâche complexe

Le mode Orchestrator, aussi appelé Boomerang Mode dans la documentation officielle, change la façon d'aborder une tâche trop grosse pour un seul passage. Plutôt que de demander directement « ajoute l'authentification à mon application », vous décrivez l'objectif à Orchestrator, qui le découpe en sous-tâches et les délègue aux modes spécialisés : Architect pour poser le plan, Code pour l'implémentation, Debug si un test échoue en cours de route.

1. 01
   Décrire l'objectif, pas les étapes

   Donner le résultat attendu à Orchestrator plutôt que la liste des fichiers à modifier ; c'est justement ce découpage que le mode doit produire.
2. 02
   Laisser chaque sous-tâche revenir avant la suivante

   Le mode attend le résultat d'une délégation avant de lancer la suivante, ce qui donne des points d'arrêt naturels pour relire ce qui vient d'être fait.
3. 03
   Garder un œil sur le mode actif à chaque étape

   L'interface indique quel mode travaille à l'instant T ; un passage inattendu en mode Code sur une tâche censée rester en lecture est le signal à surveiller en priorité.

Sur un modèle local, ce découpage a un coût direct et mesurable : chaque sous-tâche déléguée est un nouvel appel au modèle, donc une nouvelle génération complète avec son propre temps de chargement du contexte. Orchestrator vaut la peine sur une tâche réellement composite, avec plusieurs fichiers et plusieurs préoccupations distinctes ; pour une modification simple, il ajoute des allers-retours sans rien apporter de concret, et un mode Code direct reste sensiblement plus rapide pour atteindre exactement le même résultat final.

#Bien s'en servir

Des tâches étroites

« Ajoute ce paramètre et propage-le dans les trois fonctions qui l'appellent », pas « améliore ce module ». Plus la demande est précise, moins le modèle a de place pour interpréter à sa façon, et c'est justement cette marge d'interprétation qui produit la majorité des diffs décevants.

Un dépôt propre

Travailler sur une branche dédiée avec un arbre de travail propre rend chaque diff lisible d'un coup d'œil et chaque erreur annulable en un commit reverted, sans avoir à démêler les modifications de l'agent de vos propres changements en cours.

Relire chaque diff

Un modèle local produit régulièrement des modifications plausibles qui compilent, passent la relecture rapide, et ne font pourtant pas ce que vous vouliez réellement. La compilation n'est pas une preuve de correction, seulement l'absence d'erreur de syntaxe.

Se méfier du contenu externe

Un ticket, un fichier de documentation d'une dépendance ou un commentaire déjà présent dans le code peut contenir une instruction destinée à l'agent plutôt qu'à vous — voir la section sécurité ci-dessous pour ce que ça change concrètement.

#Dépannage : les blocages les plus courants

La plupart des blocages avec un modèle local viennent de trois causes reconnaissables et faciles à distinguer, à vérifier systématiquement avant de mettre en cause la qualité intrinsèque du modèle lui-même.

Dans les trois cas, la première question à se poser n'est pas « quel meilleur modèle prendre » mais « qu'est-ce que le modèle a effectivement reçu comme contexte et comme permissions au moment où il a répondu ». Un contexte tronqué produit exactement les mêmes symptômes visibles qu'un modèle sous-dimensionné, pour un coût de diagnostic et une solution très différents une fois la vraie cause identifiée.

#Le risque propre à un agent qui lit votre projet

Un agent d'édition consulte, par nature, du contenu que vous n'avez pas rédigé vous-même : un README de dépendance tierce, un ticket collé dans la conversation, un commentaire déjà présent dans le dépôt cloné depuis ailleurs. Rien n'empêche l'un de ces contenus de porter une instruction destinée au modèle plutôt qu'à vous — c'est le principe même de l'injection de prompt, détaillé dans le guide dédié ci-dessous, et un agent doté d'un terminal et d'un accès en écriture est une cible autrement plus intéressante pour ce type d'attaque qu'un simple chatbot sans outils.

C'est précisément là que les modes de Roo Code cessent d'être un simple confort d'organisation pour devenir une mesure de sécurité concrète. Un mode Ask, cantonné à la lecture, ne peut tout simplement pas exécuter l'instruction cachée dans un ticket même s'il l'a lue et même si le modèle sous-jacent s'y est laissé influencer. La protection ne vient pas d'un modèle plus intelligent qui saurait reconnaître le piège, mais d'un périmètre de permissions qui rend l'exécution de l'instruction techniquement impossible, quel que soit ce que le modèle a décidé de faire.

• Injection de prompt : le local ne vous protège pas
• Source : documentation officielle des modes Roo Code
• Source : configuration officielle du fournisseur Ollama
• Source : dépôt officiel de Roo Code sur GitHub, statut archivé
• Source : récit de l'arrêt de Roo Code et des alternatives (presse spécialisée)

#FAQ