Dans la première partie de cet article, on vous a présenté les différentes caractéristiques des LLMs. Maintenant qu’on connaît les variables avec lesquelles on peut jouer, quelles sont nos options, concrètement ? Nous allons essayer de les lister par ordre de prix croissant, en insistant sur leurs points forts et leurs points faibles.
OpenRouter
| Avantages | Inconvénients |
|---|---|
| + 30+ modèles gratuits | - 200 requêtes par jour par modèle |
| + Intégré au workflow de Codage Agentique |
Nous avons cité cet outil plusieurs fois au cours de notre série d’articles, principalement car il permet d’utiliser n’importe quel modèle avec une seule clé API tout en évitant tout problème de rate limiting. Mais OpenRouter a un autre atout dans sa poche : des versions gratuites de certains modèles, comme Deepseek R1 ou Gemini Flash 2.0.
Évidemment, ces versions gratuites sont sujettes à une limitation du nombre d’appels, plus précisément : 20 requêtes / minute et 200 requêtes / jour. Mais bon, c’est gratuit et ça permet de tester le workflow qu’on vous a décrit dans les précédents articles, tout ça sans dépenser un centime.
On peut également optimiser son workflow en exploitant chaque jour ces 200 requêtes - il n'y a pas de petites économies.
Clé API Gemini
| Avantages | Inconvénients |
|---|---|
| + Gratuit | - Modèles Gemini uniquement |
| + 1500 requêtes par jour | |
| + Intégré au workflow de Codage Agentique |
On a déjà cité Gemini Flash 2.0 pour ses performances correctes, sa rapidité impressionnante et son prix défiant toute concurrence.
Ce n'est pas son seul point fort, puisqu'il est possible de générer une clé API via Google AI Studio, de l'importer dans l'outil de notre choix et de bénéficier de limites très généreuses pour une utilisation totalement gratuite.
On parle ici de 15 requêtes / minute et 1500 requêtes / jour, qu'on peut évidemment cumuler avec les requêtes gratuites d'OpenRouter. En pratique nous dépassons rarement les 500 requêtes / jour, le seul réel inconvénient de cette méthode se situe au niveau de la qualité des modèles Gemini. Ils sont bons, mais parfois il nous faut des modèles excellents.
Pour se lancer c'est la méthode que nous préconisons.
Abonnements (avec plan gratuit)
Certains outils de codage agentique permettent de souscrire à un abonnement et, la bonne nouvelle, c’est qu’ils ont tous un plan gratuit. Ces plans gratuits sont évidemment (très) limités, notamment à l’utilisation de modèles “premiums”, mais permettent au moins de faire quelques pas dans la pataugeoire avant de se lancer dans le grand bain.
Les plans payants sont également plus ou moins limités et ne permettent pas forcément de sortir des clous pour appliquer certaines des optimisations dont on va parler. Sur certains de ces outils, comme Cursor, nous avons aussi pu voir passer des plaintes sur des performances variables, au fur et à mesure que l’outil change ses prompts et/ou ajoute des méthodes de compression pour économiser des tokens (à prendre avec des pincettes).
Parmi ces outils, on peut notamment citer :
| Outil | Points Positifs | Points négatifs |
|---|---|---|
| GitHub Copilot Agent | + Choix parmi plusieurs modèles | - Rate Limits assez floues |
| + Option à 10$/mois plutôt généreuse | - Moins bon que d’autres outils avec les mêmes modèles | |
| Google Gemini Code Assist | + Offre gratuite généreuse | - Modèles Gemini uniquement |
| Cursor | + Mature | - Nouvel IDE (fork de VSCode) |
| + Possibilité d’utiliser nos propres Clés API | - Offre gratuite très limitée |
GitHub Copilot comme API Provider (VSCode Language Model API)
| Avantages | Inconvénients |
|---|---|
| + Meilleur rapport Qualité/Prix | - Intégration expérimentale |
Si vous avez un abonnement GitHub Copilot, vous pouvez l’utiliser en conjonction avec la plupart des outils de codage agentique en utilisant l’API de VSCode. Le prix à payer est une intégration expérimentale qui rend l’accès à certains modèles assez peu constants. Les modèles ont également une Context Window plus petite, mais pour 10€ par mois c’est probablement la meilleure option. D’autant plus que vous avez également accès à l'autocomplétion classique et à l’outil GitHub Copilot Agent.
Héberger son modèle
| Avantages | Inconvénients |
|---|---|
| + Souveraineté de la donnée | - Modèles OpenSource déjà très peu chers par leurs API |
| + OpenSource | - Investissement initial |
| + Impact environnemental | - Performances |
En plus de l’aspect “souveraineté de la donnée”, héberger un modèle OpenSource peut avoir du sens financièrement. Malheureusement rien n’est moins sûr, la consommation électrique des cartes graphiques à elle seule peut revenir plus chère que de passer par un fournisseur API du modèle concerné. D’autant plus qu’atteindre des performances similaires nécessite d’investir lourdement dans du matériel.
Mais il ne faut pas oublier l’impact environnemental dans ce calcul. Si notre électricité est issue de sources propres, on peut limiter l’impact environnemental monumental des LLMs à l’énergie dépensée pour leur phase d'entraînement.
Optimiser son workflow
On a vu des solutions qui permettent de payer moins cher, mais la contrepartie est qu’on le paie en qualité en utilisant des modèles moins performants, ou en rapidité, car il peut y avoir des limites à l’utilisation ou tout simplement de performances. Heureusement, d’autres options existent, tout bonnement parce qu'utiliser l’IA de manière plus pertinente vous permettra généralement de payer moins cher, d’aller plus vite tout en générant du code de meilleure qualité. Le triangle QCD est obsolète. Bon, en réalité pas vraiment parce que vous aurez investi du temps pour améliorer la qualité de votre production, ce qui devrait théoriquement faire que votre solution a plus de valeur. Vous aurez acquis de l’expérience.
Moins cher ne veut pas dire insuffisant
Oui, actuellement les meilleurs modèles coûtent cher. Mais non, les meilleurs modèles ne sont pas les plus chers. De manière similaire, de très bons modèles coûtent une fraction du prix des “flagships”. On peut notamment citer les modèles de DeepSeek ou Gemini. De la même manière qu’on ne va pas faire travailler Philippe Etchebest dans une cantine d’école primaire (bonjour l’ambiance sinon), on peut éviter d’assigner Claude à une tâche de documentation.
D’autant plus que la documentation est une tâche qui va avoir tendance à consommer beaucoup de tokens en sortie, surtout si on veut qu’elle soit exhaustive. Les tokens en output, c'est 15$ par million de tokens chez Claude 3.7 Sonnet, contre 0,4$ chez Gemini 2.0 Flash. Nous pouvons vous garantir que Claude n’est pas 35 fois meilleur que Gemini, par contre ce dernier est 3 fois plus rapide. Lequel choisir ? La question, elle est vite répondue.
Avec des outils comme OpenRouter, changer de modèle prend tout au plus quelques secondes, autant investir ces quelques secondes pour économiser quelques euros.
N’hésitez pas à tester plusieurs modèles pour avoir une idée de leurs limites, ça peut faire une grosse différence sur votre facture.
Ne pas se limiter à un seul modèle
Dans la continuité de la partie précédente, avoir une idée des forces de chaque modèle peut également faire une différence sur votre facture.
La plupart des outils supportent plusieurs “modes”. En fait, l'idée est de préciser le métier de chaque agent. Dans Cline, il n’y a que le “plan” et le “act”, respectivement l’architecte et le développeur. Mais certains outils, comme RooCode, un fork de Cline, vous permettent de vous rapprocher d’un véritable workflow agentique en créant vos propres modes. RooCode permet même désormais une forme édulcorée de workflow agentique complètement autonome où les “modes” communiquent entre eux. Chaque mode a sa propre “personnalité” et des instructions personnalisées permettant de spécifier son rôle. Vous pouvez ensuite choisir le mode le plus adapté à la requête que vous êtes en train de faire.
Imaginons par exemple un agent spécialisé en documentation. Comme dit précédemment, utiliser Claude pour générer de la documentation n’est pas optimal, d’autant plus qu’une large base de code implique une Context Window importante. Autant donc utiliser Gemini 2.0 Flash pour sa Context Window à 1 million de tokens et sa rapidité. On pourra ensuite choisir notre agent de documentation si une sous tâche de documentation se présente durant notre conversation avec l’IA :
Dans ce cas-là, la valeur est évidente puisque Gemini Flash coûte significativement moins cher, mais parfois, il s’agit d’améliorer la qualité du code généré. Reprenons les meilleurs modèles selon le benchmark Aider Polyglot :
J’aimerais que vous prêtiez attention au numéro 2, Deepseek R1 + Claude 3.5 Sonnet. On peut remarquer plusieurs choses :
- Deux modèles différents sont utilisés dans un même benchmark ;
- Les performances sont très proches de Claude 3.7 avec raisonnement, mais en utilisant Claude 3.5, son prédécesseur qui est un modèle sans raisonnement. D’ailleurs avant la sortie de Claude 3.7 et pendant plusieurs mois, ces modèles étaient numéro 1 du classement ;
- Cette combinaison de modèles coûte 3 fois moins cher que Claude 3.7 avec 32k tokens de raisonnement, et 25% moins cher que Claude 3.7 tout court (tout en étant meilleure).
Vous l’aurez deviné, ici l’idée est d’utiliser Deepseek R1 pour la planification de la tâche et Claude pour la rédaction du code, par exemple avec le système “plan” et “act” de Cline. C’est moins cher que Claude seul, car la planification est faite par DeepSeek R1, qui coûte significativement moins cher pour les tokens en sortie. Bref, c’est moins cher, et c’est mieux.
La sortie de Claude 3.7 m’a un peu embêté à la rédaction de cette partie. Pouvoir dire que les meilleures performances du milieu sont atteintes en combinant deux modèles, tout en coûtant 14 fois moins cher que la deuxième meilleure option, ça claque… Mais comme d’habitude, quand il s’agit d’IA, il suffit qu’un nouveau modèle sorte pour que le classement change, et avec un peu de chance ce modèle sera moins cher. Peut-être que même actuellement la combinaison DeepSeek R1 + Claude 3.7 Sonnet est meilleure, elle n’est pas présente dans le classement.
Optimiser le contexte
Au-delà du coût monétaire que représente une Context Window trop remplie, ça a également un gros impact sur les performances de votre modèle. Si les réponses que vous obtenez ont l’air de s’être significativement dégradées depuis le début de votre conversation, ça vient très probablement de là.
Pour des raisons complètement empiriques et sans réelle compréhension de ce qui se passe sous le capot du LLM, nous essayons d’éviter de dépasser 75% de la Context Window. Après analyse du code source de Cline dans le cadre de l’écriture de cet article, nous avons pu remarquer que l’outil ne garde que la moitié de la Context Window dès que celle-ci risque d’être dépassée :
On remarque aussi que la variable maxAllowedSize est à 80% de la contextWindow. On est pas si loin de nos conclusions empiriques.
Enfin, on remarque que c’est un peu le bazar avec beaucoup de code spécifique et qu’eux-mêmes ne semblent pas satisfaits de leur implémentation. Et encore, je vous ai caché beaucoup de commentaires. Ça nous rappelle qu’encore une fois les Coding Agents sont un aspect tout neuf du workflow de développement.
En bref, cela veut dire qu’en réalité, on ne dépassera jamais la Context Window, mais également qu’on ne sait pas si on a déjà perdu une certaine quantité d’informations. Une petite notification pour l’utilisateur ne serait pas de refus.
Pour des raisons empiriques et avec une certaine compréhension de ce qui se passe sous le capot de l’outil, essayer d’éviter de dépasser 80% de la Context Window semble donc être cohérent.
Est-ce que ça veut dire recommencer à zéro notre discussion si celle-ci dépasse le seuil fatidique ? Bien sûr que non. Comme souvent, pour nous sortir de cette situation délicate, il suffit de passer un peu de temps avec notre buzzword préféré : le Prompt Engineering.
Instructions personnalisées
Les instructions personnalisées sont une manière de modifier le comportement de l’IA pour qu’elle s’adapte à vos besoins spécifiques.
Ces besoins peuvent être spécifiques à vos préférences de développement. Par exemple, si vous préférez que l’IA compare votre base de code à des pâtes et vous réponde en français, vous pouvez le spécifier dans la plupart des outils.
Là où ça devient intéressant, c’est quand vos besoins spécifiques sont à l’échelle du projet. Vous utilisez un pattern architectural particulier ? Vous avez des conventions de nommage ? Vous structurez vos fichiers d’une certaine manière ? Autant de spécificités de votre projet qui sont toujours d’actualité peu importe la tâche. La solution ? Des fichiers de configuration.
Ils vous permettent de partager vos bonnes pratiques de codage agentique avec votre équipe via votre outil de versionnement préféré, tout en évitant d’avoir des prompts à rallonge dans votre conversation. Si on se penche sur l’anatomie d’un prompt plus en détail, en prenant l'exemple de Cline, ça ressemble à ça :
Cline supporte par défaut un fichier .clinerules ainsi qu’un fichier .clineignore. Par exemple, si on imagine un projet dans lequel on utilise une architecture hexagonale, on peut retrouver dans notre fichier .clinerules les lignes suivantes :
La plupart des outils “matures” supportent ces fichiers par défaut mais, en soi, ce n’est qu’un ajout au prompt. On peut donc spécifier directement dans les instructions utilisateur de respecter les règles décrites dans un fichier donné. C’est d’ailleurs une bonne pratique d’insister sur les fichiers de configuration dans la description de la tâche pour s’assurer que l’IA ne les ignore pas. C’est également une bonne pratique pour le prochain sujet dont on va traiter, la Memory Bank.
Memory Bank
Imaginons que vous ayez une mémoire douteuse dont la moitié risque de disparaître dès que vous apprenez quelque chose de nouveau. Tant que vous n’oubliez pas comment écrire, vous avez la possibilité de coller des post-its sur votre frigo avec quelques choses importantes à retenir. La Memory Bank, c'est ça, des post-its pour votre LLM.
Concrètement, le principe, c'est de laisser à l’outil le soin de noter le contexte qu’il trouve important dans des fichiers, et qu’il s’y réfère lors de chaque nouvelle tâche. Notre tâche sera donc :
- Lire la Memory Bank.
- Effectuer la tâche.
- Mettre à jour la Memory Bank.
Pour implémenter une Memory Bank, il faudra effectuer 2 actions :
- Apprendre à l’outil ce qu’est une Memory Bank et comment l’utiliser. Pour ça, il suffit de rajouter des instructions personnalisées à l’outil. La documentation de Cline donne un exemple de prompt de Memory Bank, mais n'hésitez pas à le modifier pour qu’il corresponde à vos besoins. Vous pouvez également intégrer ce prompt à votre fichier .clinerules mais assurez-vous que vos collègues soient au courant.
Nous avons aussi tendance à retirer quelques lignes dans les fichiers générés pour la memory bank de temps à autre, celle-ci étant parfois ambitieuse ;
- Adapter le prompt utilisateur pour dire à Cline de lire la Memory Bank et la mettre à jour après chaque fin de tâche. Selon les instructions que vous avez données, il peut être censé le faire de lui-même, mais il a tendance à l’ignorer. Notamment la partie mise à jour.
Serveurs MCP
Les serveurs Model Context Protocol permettent d’ajouter des fonctionnalités à Cline en intégrant des API de divers outils comme AirTable, Git, Spotify… Mais ce n’est pas pour ça que je vous en parle dans la section d’optimisation du contexte. En fait, Cline est capable de créer ses propres MCPs. Oui, l’IA peut s’améliorer toute seule (quelqu’un a dit Singularité ?). Sauf que pour faire ça, dans son prompt par défaut, il y a presque le code source entier d’un MCP. Si vous ne souhaitez pas créer un MCP, n’hésitez pas à changer la valeur de la variable “Mcp: Mode”. La différence est immédiate :
Conclusion
C’est bon, vous êtes de nouveau compétitif sur le marché du développement. Enfin presque, puisqu’on va terminer de vous rendre IA-ready en vous apprenant le Prompt Engineering dans notre dernier article sur les Coding Agents (jusqu’au suivant).
Et vous ne resterez pas compétitifs bien longtemps. Les concepts abordés dans cet article sont fortement liés aux outils utilisés. Au fur et à mesure que ceux-ci évoluent (et ils évoluent vite), ou que la communauté de développeurs apprend à mieux les utiliser (et les développeurs apprennent vite), ces concepts risquent l’obsolescence. Quand ça arrivera vous pourrez évidemment compter sur nous pour vous maintenir à jour, mais je ne peux que vous conseiller de rester aux aguets.
