Comment accéder aux modèles IA de codage gratuits ?

J’accède aux modèles IA de codage gratuits avec OpenCode, Codex, Kilo Code, OpenRouter et Google Antigravity. Le vrai sujet, ce n’est pas juste le prix. C’est de savoir quel outil utiliser selon votre contexte, votre IDE, vos limites d’usage et le niveau de contrôle dont vous avez besoin.

Quel outil gratuit choisir en premier ?

Je choisirais d’abord selon votre environnement de travail, pas selon le modèle IA le plus à la mode. C’est le piège classique. On voit passer un benchmark, on installe l’outil du moment, puis on se rend compte qu’il ne colle pas au dépôt, à l’éditeur, aux règles de sécurité ou juste à la façon dont l’équipe travaille.

Pour moi, les cinq options gratuites à regarder en premier sont assez simples à positionner. OpenCode, si vous aimez travailler dans le terminal. OpenAI Codex, si vous êtes déjà dans ChatGPT et que vous voulez avancer sur des petits projets ou des bouts de code. Kilo Code, si vous voulez un assistant plus intégré dans VS Code, JetBrains, le terminal ou même le cloud. OpenRouter, si votre sujet c’est surtout de prototyper via API, c’est-à-dire appeler des modèles depuis votre propre application. Google Antigravity, si vous voulez tester plusieurs familles de modèles dans un environnement de développement plus expérimental.

Le codage assisté par IA a vraiment changé. On n’est plus juste sur un chat qui écrit une fonction isolée. Les bons outils savent inspecter un dépôt, comprendre plusieurs fichiers, proposer des modifications, lancer des commandes, lire les erreurs, puis corriger. C’est là que ça devient intéressant. Et aussi là que ça peut faire des bêtises, soyons honnêtes.

Sur des missions client, le gain vient rarement du modèle seul. Le vrai gain vient du bon branchement entre l’outil, le dépôt Git, les règles de sécurité, les tests, et votre capacité à relire les changements. Gratuit ne veut pas dire illimité. Vous aurez souvent des quotas, des modèles moins puissants, des lenteurs, ou des contraintes sur la confidentialité.

Outil	Meilleur usage	Point fort gratuit	Limite à surveiller
OpenCode	Travailler dans le terminal sur un dépôt local	Simple, direct, proche du workflow développeur	Demande d’être à l’aise avec la ligne de commande
OpenAI Codex	ChatGPT, petits projets, corrections rapides	Très accessible pour démarrer vite	Moins adapté aux gros dépôts sans intégration propre
Kilo Code	VS Code, JetBrains, terminal, cloud	Bonne couverture des environnements de dev	Il faut bien configurer les permissions et le contexte
OpenRouter	Prototyper avec des modèles via API	Comparer plusieurs modèles facilement	Les coûts et limites varient selon les modèles
Google Antigravity	Tester plusieurs familles de modèles dans un IDE	Intéressant pour comparer les comportements	Écosystème encore à valider selon vos usages réels

Pourquoi OpenCode est utile en terminal ?

OpenCode est utile quand je veux un agent open source directement dans le terminal, proche de mon dépôt, de mes fichiers et de mes commandes. Je le vois surtout comme un outil pour développeurs qui aiment garder la main. On reste dans son environnement, on voit ce que l’agent propose, on peut refuser, ajuster, relancer. C’est moins magique qu’un IDE très intégré, mais parfois c’est justement ce qu’on veut.

L’intérêt principal, pour un usage gratuit, c’est OpenCode Zen. Il donne régulièrement accès à des modèles gratuits comme MiMo-V2.5, Deepseek v4 Flash, Laguna S 2.1, Nemotron 3 Ultra ou North Mini Code. Je dis bien régulièrement, pas définitivement. La gratuité peut bouger. Un modèle gratuit aujourd’hui peut devenir payant demain, être limité, ou disparaître temporairement. C’est un point à garder en tête si vous voulez l’utiliser dans un workflow critique.

Pour l’installation, je pars toujours de la documentation officielle du projet, parce que les commandes peuvent changer. Si une installation npm est proposée, ça peut ressembler à ça :

npm install -g opencode-ai — Cette commande installe OpenCode globalement avec npm, le gestionnaire de paquets de Node.js.

cd mon-projet — Cette commande me place dans le dépôt sur lequel je veux travailler.

opencode — Cette commande lance l’agent dans le terminal, au plus près du code du projet.

Mes bons réflexes sont simples, et franchement ils évitent beaucoup de dégâts. J’ouvre OpenCode dans un dépôt versionné avec Git. Git, c’est l’outil qui garde l’historique du code et permet de revenir en arrière. Je crée une branche avant toute modification. Je demande toujours un plan avant l’édition. Je relis les diffs, c’est-à-dire les différences entre l’ancien code et le nouveau. Puis je lance les tests.

Un prompt que j’utilise souvent ressemble à ça :

Analyse ce dépôt, propose une correction minimale pour ce bug, ne modifie rien sans me montrer le plan.

C’est simple, mais ça force l’agent à réfléchir avant d’agir. Chez un client, c’est exactement ce qui a évité une grosse réécriture inutile d’un module. Le bug venait d’une condition mal placée, pas d’une refonte complète.

Choisir OpenCode	Éviter OpenCode
Quand je veux travailler dans le terminal, avec un agent open source proche du dépôt.	Quand j’ai besoin d’une disponibilité stable et garantie des modèles gratuits.
Quand je veux comprendre ce que l’agent fait et valider chaque étape.	Quand je cherche une expérience très intégrée, clé en main, sans configuration.

Quand utiliser Codex gratuitement ?

J’utilise Codex gratuitement quand je veux avancer vite sans sortir l’artillerie lourde. C’est surtout utile pour apprendre, explorer un petit projet, comprendre un fichier un peu dense ou accélérer une tâche simple de développement. Codex est décrit comme accessible dans le plan gratuit de ChatGPT, sans clé API et sans crédit API, donc c’est pratique pour tester sans gérer une facturation ou une configuration technique.

Ce que j’aime bien, c’est qu’il peut inspecter des fichiers, proposer des modifications de code, lancer des commandes et m’accompagner sur une tâche de dev assez concrète. Par exemple comprendre pourquoi un test casse, nettoyer une fonction, ajouter une validation, ou repérer où passe une donnée dans le code. Mais je garde une limite en tête. Le plan gratuit a des limites d’usage, donc je ne le prends pas pour un gros dépôt, une session de refacto de trois heures ou un usage intensif en continu. Là, ça devient vite frustrant.

Pour comprendre une fonction existante, je lui donne une demande très cadrée. “Lis ces fichiers et explique-moi le flux métier avant de proposer une modification. Ne change rien tant que tu n’as pas résumé ce que fait le code, les dépendances importantes et les risques.” C’est le genre de prompt qui évite les réponses trop rapides, surtout sur du code que je découvre.

Pour corriger un bug localisé, je préfère demander petit. “Voici l’erreur, le fichier concerné et le comportement attendu. Trouve l’hypothèse la plus probable, modifie uniquement les fichiers nécessaires et donne-moi la liste des changements.” Ça marche bien quand le problème est clair, pas quand tout le projet est en feu.

Pour ajouter un test simple, je vais droit au but. “Ajoute un test unitaire pour ce cas précis. Garde le style des tests existants, ne refactorise pas le code métier et explique-moi comment lancer le test.” C’est basique, mais très efficace.

Mon mini workflow ressemble souvent à ça dans la vraie vie. Je colle le contexte utile, pas tout le projet. Je demande une hypothèse. Je demande ensuite un patch minimal. Je vérifie le diff, je lance les tests, puis je relance Codex avec le résultat si ça casse encore. Ça évite de partir dans des modifications trop larges.

Je relis toujours le code généré. Je regarde aussi les commandes qu’il veut lancer, surtout si elles touchent aux fichiers, aux dépendances ou à la base de données. Et je fais attention aux extraits que je partage. Pas de secrets, pas de clés, pas de données client sensibles. Codex peut faire gagner du temps, mais ça reste mon code et ma responsabilité.

Kilo Code simplifie quoi exactement ?

Kilo Code simplifie surtout un truc très concret : le choix des modèles. Avec l’option kilo-auto/free, il peut router automatiquement mes requêtes vers des modèles gratuits disponibles, sans que je passe 20 minutes à comparer OpenRouter, tel modèle de code, tel quota, tel fournisseur. Franchement, quand je veux juste avancer sur un bug ou refactoriser une fonction, c’est exactement ce que j’attends.

Kilo Code est un agent open source compatible avec VS Code, JetBrains, le terminal et le cloud. Ça change pas mal de choses pour un développeur. Je peux rester dans mon environnement habituel, ouvrir mon projet, puis demander à l’agent d’analyser un fichier, proposer une modification, expliquer une erreur ou m’accompagner sur une tâche plus large. Je n’ai pas besoin de copier-coller mon code dans dix interfaces différentes.

Dans VS Code, le plus simple c’est d’installer l’extension Kilo Code depuis le marketplace. Ensuite, j’ouvre un projet, je sélectionne kilo-auto/free comme modèle ou comme routeur quand l’option est disponible, puis je lance une première demande sur un fichier simple. Par exemple, un vieux helper JavaScript, une fonction trop longue, ou un test qui casse. Pour JetBrains, le terminal et le cloud, je resterais prudent : je suivrais l’installation officielle selon l’environnement, parce que les options peuvent bouger vite.

Les bons prompts font une vraie différence. Je vois souvent des équipes demander “corrige ce bug”, puis s’étonner d’une réponse trop vague. Je préfère donner un cadre clair :

• Refactorise cette fonction sans changer le comportement et ajoute des tests lisibles.
• Analyse ce module et trouve les fichiers probablement liés à ce bug.

Je précise aussi les contraintes. Les fichiers à éviter, le style attendu, les tests à lancer, les conventions du projet. Plus l’agent comprend le terrain, moins il part dans tous les sens.

Il y a quand même des limites. Les modèles gratuits peuvent avoir des limites de débit, donc un nombre de requêtes limité sur une période donnée. Leur disponibilité varie aussi. Un modèle peut être accessible le matin et saturé l’après-midi. Il peut aussi y avoir de la journalisation des prompts selon le routeur ou le fournisseur utilisé. Moi, je n’enverrais pas de secrets, tokens, données clients ou informations sensibles dans ce type de routeur gratuit.

Bons usages	Usages à éviter
Refactoriser du code non sensible.	Envoyer des clés API ou tokens.
Comprendre un module ou une erreur.	Partager des données clients.
Générer des tests et pistes de correction.	Coller du code propriétaire critique sans contrôle.

Pourquoi passer par OpenRouter ?

Quand je veux tester un agent de code sans me battre avec dix SDK différents, OpenRouter est pratique. Je le vois comme une passerelle unique vers des modèles IA de plusieurs fournisseurs. Au lieu d’intégrer Anthropic, Google, Meta, Mistral ou d’autres un par un, j’appelle une seule API, avec un format assez proche d’OpenAI.

Le modèle openrouter/free est intéressant pour ça. C’est un routeur, pas juste un modèle fixe. Il sélectionne automatiquement des modèles gratuits selon ce que je demande, par exemple si j’ai besoin d’un appel d’outils, c’est-à-dire laisser le modèle déclencher une fonction externe, ou d’une sortie structurée, comme un JSON propre. La limite à garder en tête est simple : environ 50 requêtes gratuites par jour. C’est largement suffisant pour prototyper. Ce n’est pas sérieux pour une prod avec des utilisateurs.

Voici un exemple Node.js minimal. Il sert à envoyer une demande simple à OpenRouter, avec la clé API lue depuis la variable d’environnement OPENROUTER_API_KEY.

// On récupère la clé API depuis les variables d'environnement
const apiKey = process.env.OPENROUTER_API_KEY;

if (!apiKey) {
  console.error("OPENROUTER_API_KEY est manquante");
  process.exit(1);
}

// Fonction principale asynchrone pour appeler l'API OpenRouter
async function main() {
  const response = await fetch("https://openrouter.ai/api/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      // Le routeur choisit automatiquement un modèle gratuit disponible
      model: "openrouter/free",
      messages: [
        {
          role: "user",
          content: "Génère une fonction JavaScript simple qui additionne deux nombres."
        }
      ]
    })
  });

  const data = await response.json();

  // On affiche le texte généré par le modèle
  console.log(data.choices?.[0]?.message?.content);
}

main().catch(console.error);

Pour un agent de code, je demande souvent une sortie structurée avant de modifier quoi que ce soit. Ça évite le côté “je fonce dans le repo et on verra”. Le modèle doit d’abord planifier.

{
  "filesToEdit": ["src/utils/math.js", "tests/math.test.js"],
  "riskLevel": "low",
  "summary": "Ajouter une fonction d'addition et son test unitaire."
}

Les champs sont simples. filesToEdit liste les fichiers à toucher. riskLevel donne une estimation du risque. summary résume le plan. Dans la vraie vie, j’ai déjà vu des agents modifier cinq fichiers pour un changement ridicule. Ce genre de JSON calme un peu le jeu.

Je vois OpenRouter comme une brique d’expérimentation. C’est parfait pour tester une idée d’agent, un prototype ou une petite automatisation. C’est moins adapté si vous avez besoin de SLA, de stabilité forte, de confidentialité stricte ou d’un gros volume gratuit.

Que vaut Google Antigravity pour coder ?

Google Antigravity vaut le coup si je veux tester plusieurs grandes familles de modèles dans un même environnement de développement, sans me créer trois comptes, trois configs et trois habitudes différentes. Son offre individuelle à 0 dollar par mois est intéressante pour ça : comparer vite, dans un contexte proche du vrai travail de dev.

Ce qui m’intéresse surtout, c’est l’accès à plusieurs modèles de Google, Anthropic et au modèle open-weight GPT-OSS-120B. Open-weight veut dire que les poids du modèle sont disponibles sous certaines conditions, ce qui le rend plus ouvert qu’un modèle 100 % fermé. L’offre individuelle indique aussi un usage illimité, mais je garde toujours une nuance. Il faut vérifier les conditions exactes, les limites pratiques, les files d’attente, les quotas cachés possibles et les changements d’offre. Sur ce genre de produit, ça peut bouger vite.

Dans mon quotidien, je l’utiliserais pour des tâches très concrètes. Explorer un dépôt que je connais mal. Demander pourquoi une feature casse. Comparer la qualité des réponses entre familles de modèles. Faire produire un plan de refactoring, c’est-à-dire une proposition pour restructurer le code sans changer son comportement. Générer des tests. Faire relire une modification avant de la pousser. C’est là que l’outil devient utile, pas juste quand il répond à une question théorique.

Mon mini protocole de test serait simple. Je prends le même dépôt, la même tâche, la même contrainte. Par exemple : “Corrige ce bug sans changer l’API publique et ajoute les tests nécessaires”. Puis je compare sur trois critères :

• Justesse du diagnostic : Est-ce que le modèle comprend vraiment la cause du problème ?
• Taille des modifications : Est-ce qu’il change trois lignes utiles ou la moitié du projet ?
• Qualité des tests proposés : Est-ce que les tests couvrent le bug réel ou juste un cas facile ?

C’est souvent là qu’on voit la vraie différence entre les modèles. Certains expliquent très bien mais modifient trop. D’autres codent vite mais ratent le contexte. J’ai déjà vu ça chez un client sur un vieux backend Node : le meilleur modèle n’était pas celui qui écrivait le plus de code, c’était celui qui touchait le moins de fichiers.

Outil	Point fort	À surveiller
Antigravity	Environnement intégré pour tester plusieurs modèles dans le même flux de dev.	Conditions exactes de l’offre gratuite, limites pratiques, évolution des modèles disponibles.
OpenRouter	API pratique pour comparer beaucoup de modèles avec une seule intégration.	Coûts par modèle, latence, qualité variable selon le fournisseur derrière.
Kilo Code	Extension IDE utile pour coder directement dans son éditeur.	Dépendance à la configuration locale, choix du modèle, limites de l’API utilisée.

Au fond, je ne chercherais pas “le meilleur outil” dans l’absolu. Je choisirais selon le besoin. Antigravity pour comparer dans un environnement intégré. OpenRouter pour tester via API. Kilo Code pour rester dans l’IDE.

Alors, lequel je garderais pour coder gratuitement ?

Je garderais plusieurs options, pas une seule. OpenCode me plaît pour travailler en terminal avec un agent open source. Codex est pratique pour apprendre et débloquer de petites tâches sans API. Kilo Code simplifie le choix des modèles dans l’IDE. OpenRouter est très utile pour prototyper des agents avec une API unifiée. Google Antigravity sert bien à comparer plusieurs familles de modèles dans un même environnement. Le point clé, c’est de rester lucide : gratuit veut dire limites, débit, stabilité variable et prudence sur les données. En choisissant selon votre usage, vous gagnez du temps sans perdre le contrôle.

FAQ

• Quel est le meilleur modèle IA de codage gratuit ?
  Je ne choisirais pas un seul meilleur modèle. Pour coder gratuitement, le bon choix dépend surtout de votre contexte. OpenCode est solide si vous aimez le terminal, Codex est pratique pour apprendre et tester vite, Kilo Code simplifie le travail dans l’IDE, OpenRouter sert à prototyper via API et Google Antigravity aide à comparer plusieurs familles de modèles.
• Est-ce que les agents IA gratuits peuvent modifier un projet complet ?
  Certains agents peuvent analyser un dépôt, modifier plusieurs fichiers, lancer des commandes et proposer des tests. Mais je conseille de toujours travailler sur une branche Git, de demander un plan avant modification et de relire les diffs. Un agent gratuit peut aider, mais il ne remplace pas la responsabilité du développeur.
• OpenRouter gratuit suffit-il pour créer un agent de code ?
  OpenRouter gratuit suffit pour prototyper un agent, tester des appels d’outils ou expérimenter des sorties structurées. La limite d’environ 50 requêtes gratuites par jour devient vite bloquante si vous voulez industrialiser. Je l’utiliserais pour valider une idée, pas pour faire tourner un workflow de production.
• Faut-il envoyer son code client dans un modèle gratuit ?
  Je l’éviterais si le code contient des secrets, tokens, données clients ou éléments sensibles. Les offres gratuites peuvent impliquer des limites, du routage automatique et parfois de la journalisation des prompts. Le bon réflexe : nettoyer le contexte, masquer les informations sensibles et vérifier les conditions de l’outil utilisé.
• Quelle option gratuite est la plus simple pour débuter ?
  Pour débuter, Codex dans ChatGPT ou Kilo Code dans un IDE sont souvent les plus accessibles. Vous restez dans une interface familière et vous pouvez demander des explications, des corrections simples ou des tests. Quand vous voulez aller plus loin côté agent, terminal ou API, OpenCode et OpenRouter deviennent plus intéressants.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent brancher l’IA sur de vrais workflows, pas juste faire des démos. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos usages IA, automatiser vos process ou former vos équipes, contactez-moi.