Peut-on coder à 0 $ ? Mon retour d'expérience sans concession entre IA Cloud et IA locale

1. Introduction : La quête du « Zéro Dollar »

Est-il possible aujourd’hui, pour un développeur d’applications mobiles, de mener à bien un projet important en se passant totalement des services d’intelligence artificielle payants dans le Cloud ? C’est le défi personnel que je me suis lancé il y a de cela trois semaines.

L’objectif était double et ambitieux : concevoir et développer une fonctionnalité majeure sur une application mobile existante avec un budget d’assistance par IA de 0 $, mais surtout confronter ces outils à un cas d’usage concret et métier complexe, plutôt qu’à des benchmarks théoriques ou synthétiques.

Le contexte de l’expérience

L’application en question est un outil sur lequel travaillent au quotidien des chauffeurs-livreurs pour le compte d’un grand groupe international spécialisé dans la logistique et la gestion de la chaîne d’approvisionnement. Cette application est développée avec Flutter, une technologie qui permet de créer des applications mobiles à la fois pour Android et iOS.

La fonctionnalité à développer était un cas classique, mais complexe, de la vie d’un projet mobile. Il s’agissait d’implémenter un système de déclaration d’arrivée tardive : 

• Auparavant, lorsqu’un chauffeur arrivait en retard chez un client, il saisissait un texte libre pour s’expliquer. 
• Le but de la feature était de remplacer ce texte libre par un questionnaire structuré proposant 15 motifs de retard prédéfinis (panne, météo, attente au chargement, etc.), avec des étapes supplémentaires adaptées (comme demander le nom de l’autoroute si le chauffeur sélectionne « embouteillage »). 
• La difficulté majeure était de faire fonctionner l'application en mode hors-ligne, ce qui imposait de sauvegarder la déclaration de retard localement sur le téléphone du chauffeur pour l'envoyer automatiquement dès qu'il récupérait du réseau.

L’échelle du projet en chiffres

Pour mesurer l’envergure technique, le projet entier représente pas moins de 132 676 lignes de code Dart (répertoires lib/ et test/), soit un volume global estimé entre 350 000 et 450 000 tokens (l’unité de mesure de texte pour les IA). Pour développer la seule fonctionnalité d’arrivée tardive, le contexte de code nécessaire (fichiers liés, logique métier, mappers, stockage local, dépendances, prompts) représentait déjà un volume de 30 000 à 60 000 tokens par envoi de prompt.

Pour tenter de digérer une telle masse d’informations en local, j’ai dû configurer manuellement Ollama à une limite de 64 000 tokens de contexte (context length) en rapport avec mon matériel.

Pour mener cette expérience de manière rigoureuse, j’ai divisé mon environnement de travail en deux projets identiques : 

1. L’approche 100 % locale : Interdiction d’utiliser internet pour interroger des IA. L’intelligence artificielle tourne directement sur mon ordinateur de travail (un MacBook Pro M3 Pro avec 36 Go de mémoire vive). 
2. L’approche 100 % Cloud : Utilisation des IA connectées d’acteurs majeurs du secteur (comme Gemini de Google et Claude d’Anthropic), dont les serveurs distants effectuent tous les calculs.

Afin d’assurer une comparaison la plus juste et objective possible, les prompts étaient strictement identiques d’un projet à l’autre. La seule et unique différence résidait dans leur traduction en anglais pour la version locale, afin de maximiser ses chances de réussite face à ses lacunes de compréhension du français.

Pourquoi ce benchmark concret me tient-il à cœur ?

Ce test en conditions réelles répond à une vision prospective forte, partagée par de nombreux collègues : les entreprises risquent d’allouer de moins en moins de crédits ou de budgets IA Cloud à leurs développeurs au fil du temps. En parallèle, les politiques tarifaires et les quotas des grands acteurs (Google, Anthropic, etc.) évoluent sans cesse, réduisant de fait notre liberté d’utilisation à quota équivalent.

Or, il est absolument hors de question pour nous de faire marche arrière et de revenir trois ans en arrière, avant l’arrivée massive des LLM et l’avènement du « développeur augmenté » (voire, dans mon cas, d’une délégation complète des tâches aux outils). Il est donc vital d’identifier et de faire mûrir dès à présent des alternatives viables en local pour ne pas se retrouver au pied du mur le jour où le Cloud deviendra inaccessible ou trop restreint.

Après trois semaines de test au quotidien, alors que je touche à la fin de cette expérience, le bilan est sans appel : l’objectif de dépenser 0 $ pour implémenter cette fonctionnalité est un échec. Dans ce retour d’expérience, je vous propose de plonger dans les coulisses de ce test pour comprendre pourquoi l’IA locale n’est pas encore prête à remplacer le Cloud pour les projets d’envergure.

2. L’expérience de l’IA en local : Une liberté séduisante, mais un quotidien éprouvant

Faire tourner un modèle d’intelligence artificielle directement sur son propre ordinateur est une idée très séduisante sur le papier : cela garantit une confidentialité absolue (le code de l’application ne quitte jamais la machine) et promet un usage totalement gratuit et illimité.

Malheureusement, la réalité physique et technique du terrain est bien différente.

Une machine à genoux

Pour espérer obtenir des réponses d’une qualité acceptable sur une application mobile professionnelle, il faut utiliser des modèles d’IA volumineux et complexes. Dans mon cas, seuls les modèles Qwen3-Coder (30B) et Qwen3.6 (27B) ont fourni un travail digne d’intérêt. Mais charger de tels mastodontes à l’aide d’Ollama exige d’allouer entre 18 et 22 Go de mémoire vive unifiée (RAM). 

L’impact est immédiat et dévorant : 

• Saturation du matériel : L’IA locale accaparait en permanence plus de 90 % de la mémoire de mon ordinateur (soit 32 à 34 Go d’occupation brute sur les 36 Go de la machine). Ollama tournait intensément en arrière-plan pendant plusieurs heures par jour, couvrant une grande partie de mes journées de travail. Sur ces 15 jours d’expérimentation, cela représente plus de 75 heures de calcul intensif imposées à mon MacBook Pro, faisant chauffer le processeur, saturant la RAM et forçant le système à utiliser le swap, ce qui a ralenti toutes mes autres tâches (VS Code, simulateurs mobiles, commandes Flutter). 
• Une lenteur d’un autre temps : L’IA locale écrivait le code à une vitesse d’escargot (péniblement 4 à 5 tokens par seconde). Lorsqu’on lui soumettait des explications détaillées sur le fonctionnement de l’application, le modèle mettait plusieurs minutes rien que pour lire et ingérer la demande. J’estime avoir perdu environ 3 à 4 heures par semaine d’attente purement passive devant mon écran, comparé à la réponse quasi instantanée du Cloud.

Des comportements imprévisibles et frustrants

Au-delà de la lenteur, l’ergonomie s’est révélée particulièrement frustrante au quotidien : 

• Le syndrome de la panne de courant : Très souvent, l’indicateur visuel de chargement de l’IA s’articulait mal et le « spinner » d’OpenCode s’arrêtait brutalement en plein milieu de sa réflexion ou juste après l’envoi d’une consigne, sans laisser de message. Impossible alors de savoir s’il fallait lui demander de continuer, reformuler la question ou tout effacer pour recommencer la discussion depuis le début. 
• Une mémoire à court terme : Au-delà de la lenteur, l’IA locale perdait rapidement le fil de la conversation sur des tâches longues. Sa mémoire (la fenêtre de contexte) étant très limitée, elle oubliait les instructions précédentes ou le code qu’elle venait d’écrire, l’empêchant de mener à bien des raisonnements complexes sur l’ensemble du projet. 
• La barrière de la langue : Ces IA locales comprennent très mal le français. Pour obtenir des résultats corrects, j’ai dû traduire toutes mes consignes en anglais. 
• Une surconfiance aveugle : L’IA locale affirmait régulièrement, avec un aplomb déconcertant, que sa tâche était terminée et que tout fonctionnait parfaitement. En réalité, le code généré empêchait l’application de démarrer. Pire encore, dès que l’IA cassait un élément existant, elle s’enfermait dans des boucles de correction infinies, répétant les mêmes erreurs sans jamais parvenir à stabiliser l’application. 
• Le piège de l’outil inadapté : On pourrait être tenté d’utiliser des clients avancés comme Claude Code pour piloter les modèles locaux. C’est une erreur : ce type d’application est optimisé pour les modèles du Cloud et effectue en arrière-plan des vérifications complexes qui font systématiquement échouer les modèles locaux. Pour ce test, il a donc été impératif d’utiliser des outils plus directs et moins « magiques » comme OpenCode. J’ai découvert une méthode pour contourner cette limitation, mais trop tard pour l’intégrer au protocole du benchmark, et de toutes façons OpenCode répondait parfaitement à mes besoins : l’utilisation de Claude Code pour l’IA locale n’était plus nécessaire.

3. L’expérience de l’IA dans le Cloud : L’efficacité stratégique sous perfusion de quotas

En repassant sur les outils connectés au Cloud, l’expérience change du tout au tout. C’est le jour et la nuit en termes de rapidité et d’intelligence.

Le confort et la complémentarité des « cerveaux »

Sur la version Cloud, les calculs sont déportés sur des serveurs distants. Mon ordinateur respire enfin, ne chauffe plus, et je peux faire travailler deux IA différentes en même temps sur le projet :

• L’IA exécutante (Gemini de Google) : Elle est redoutable pour rédiger rapidement et proprement des morceaux de code bien précis. C’est une excellente ouvrière qui respecte scrupuleusement les consignes d’écriture. En revanche, elle manque cruellement de recul, ne prend aucune initiative et a tendance à s'autocongratuler en permanence, passant parfois à côté de gros problèmes logiques.
• L’IA superviseur (Claude d’Anthropic) : Elle apporte la hauteur de vue qui manque à la première. Claude possède une véritable capacité d’autocritique. C’est elle qui valide la cohérence globale de l’application, repère les pièges dans lesquels l’autre IA s’est engouffrée et garantit que la logique du mode hors-ligne reste robuste.

Cette complémentarité montre qu’aucun de ces outils ne devrait travailler seul : l’un code avec efficacité, l’autre supervise avec sagesse.

Le revers de la médaille : La guerre des quotas

Cette efficacité remarquable a cependant une contrepartie de taille : elle consomme énormément de tokens. Si j’avais dû payer mes requêtes au tarif standard des APIs professionnelles (Claude 5 Sonnet / Gemini 3.6 Flash) à hauteur de mon utilisation intensive réelle d’assistant de développement (environ 100 requêtes par jour avec renvoi régulier de contextes de code volumineux), cela représenterait un coût réel de 15 $ à 20 $ par jour. Sur les 15 jours de l’expérimentation, cela équivaut à un budget d’environ 250 $ (soit environ 230 €) d’API Cloud pour développer entièrement la fonctionnalité.

• Claude, pour s’assurer de la qualité de son travail, n’hésite pas à relire et analyser plusieurs fois le code existant. C’est formidable pour la sécurité de l’application, mais cela épuise les quotas d’utilisation à vitesse grand V.
• C’est notamment le cas avec Antigravity, la nouvelle interface recommandée par Google. Bien qu’elle permette d’utiliser des modèles très récents de Google (comme 3.6 flash), ses quotas d’utilisation de base sont si restreints qu’il est impossible de dépasser une demi-journée de travail sans se faire bloquer.
• Pour ne pas me retrouver bloqué, mon écran ressemblait à un poste de contrôle : plusieurs fenêtres de discussion ouvertes en parallèle pour répartir les demandes sur différentes IA Cloud et économiser les quotas.

4. Face-à-Face : Tableau Comparatif Synthétique

5. Conclusion & Recommandations : Trouver le juste équilibre

Trois semaines après le début de cette quête du « Zéro Dollar », la conclusion s’impose d’elle-même.

La nouvelle fonctionnalité de déclaration de retard - avec son parcours de questions à choix multiples, sa gestion de la saisie des autoroutes et sa sauvegarde en mode hors-ligne - a été entièrement finalisée, testée et livrée par la version développée avec l’IA Cloud.

Une semaine après cette livraison réussie, la version développée en local est toujours inachevée et instable. Malgré des instructions claires et répétées, l'IA locale ne vérifie pas que les tests unitaires passent avant de considérer son travail comme terminé. Cela limite la confiance que l'on peut lui donner. En règle générale, je laisse une demi-douzaine de chances d’autocorrection à l’IA locale avant de faire intervenir le Cloud. Mais ici, face à des tests brisés qu’elle était incapable de corriger, elle s’est enfermée dans des boucles de modification infinies et incohérentes. Pour débloquer la situation et ramener le répertoire local vers un état compilable, j’ai dû faire intervenir Claude en secours à plusieurs reprises.

Mes recommandations pour nos équipes

L’usage de l’intelligence artificielle pour nous accompagner dans le développement de nos applications n’est plus un gadget : c’est un levier de productivité majeur. Mais pour que cette aide soit réelle, il faut être pragmatique :

1. Investir dans des accès Cloud professionnels est indispensable : Pour travailler sereinement sur des projets clients d’envergure, nous devons disposer de quotas d’accès aux IA Cloud solides et fournis par l’entreprise. Se contenter d’accès gratuits ou limités nous force à un jonglage permanent de fenêtres et coupe notre productivité. Sans ces outils professionnels, nous revenons trois ans en arrière, à l’époque de la simple correction d’orthographe de code.
2. Le local doit être réservé à des tâches très simples : En l’état actuel de la technologie, même avec un ordinateur professionnel de pointe, utiliser des IA locales pour coder ne fait pas gagner de temps. Au contraire, cela en fait perdre. L’IA locale peut éventuellement servir d’appoint pour des micro-tâches très isolées afin d’économiser quelques centimes (créer des petits scripts, répondre à des questions ponctuelles basiques), mais elle est aujourd’hui incapable de mener à bien l’architecture d’un projet de bout en bout.

Vouloir économiser le coût des licences d’IA Cloud en utilisant des IA locales est un calcul financièrement perdant : le coût salarial des journées de travail perdues en lenteurs et en corrections manuelles dépasse de très loin l’argent économisé en abonnements. En 2026, pour coder efficacement et sereinement, l’intelligence reste définitivement dans le Cloud.

6. Perspectives : Vers une revanche inéluctable de l’IA locale

Si la domination du Cloud en 2026 est une réalité incontestable, elle ne constitue qu’une étape transitoire. La question n’est plus de choisir son camp entre deux mondes, mais d’anticiper la prochaine rupture : l’IA hybride.

L’insuccès de ma tentative de « Zéro Dollar » ne signe pas l’arrêt de mort de l’IA locale, mais pointe plutôt les limites d’une utilisation calquée sur les modèles distants. L’avenir se dessine autour d’architectures intelligentes et spécialisées :

1. L’orchestration et le routage automatisé : Un agent intelligent intégré à l’IDE pourrait qualifier chaque requête. S’agit-il d’une simple suggestion de code ? Le traitement est confié à un modèle local véloce. 
2. À l’inverse, pour une refonte structurelle, le système basculerait de manière fluide vers le Cloud. Le développeur se concentrerait sur sa valeur ajoutée, laissant l’outil arbitrer le compromis coût/performance.
3. La boucle d’autocorrection intégrée : Le talon d’Achille des modèles locaux réside dans leur incapacité à valider leurs propres travaux. La prochaine étape cruciale consiste à coupler l’IA au terminal de commande. 
4. En exécutant elle-même flutter test ou flutter analyze avant de soumettre une modification, l’IA gagnerait en fiabilité par un dialogue itératif autonome. C’est cette autonomie qui la rendra enfin exploitable en milieu professionnel.

Si le « Zéro Dollar » demeure utopique pour l’heure, il indique une trajectoire claire. Pour nos équipes, la stratégie doit marcher sur deux jambes : sécuriser notre productivité immédiate via le Cloud, tout en mûrissant nos compétences sur ces nouvelles architectures locales.

L’organisation qui saura allier la puissance brute des serveurs à la réactivité confidentielle de la machine physique détiendra un avantage tactique majeur le jour où ces briques logicielles atteindront leur pleine maturité.