- L’agent de codage IA asynchrone de Google, Jules, a quitté la phase bêta et est désormais lancé officiellement
- Gemini 2.5 Pro est désormais intégré, ce qui permet une génération de code plus avancée et une meilleure planification des tâches
- Pendant la période bêta, des milliers de développeurs ont effectué des dizaines de milliers de tâches et partagé plus de 140 000 améliorations de code
- En se basant sur les retours utilisateurs, l’interface a été améliorée, des bugs corrigés, et de nouvelles fonctions ajoutées, comme la réutilisation des paramètres précédents, l’intégration GitHub Issues et la prise en charge multimodale
- En tirant parti des capacités de raisonnement avancé de Gemini 2.5 Pro, il est possible de proposer des plans de codage plus précis et une génération de code de meilleure qualité
- Introduction d’un nouveau palier d’abonnement : Introductory (prise en main de base), Pro (limite multipliée par 5), Ultra (limite multipliée par 20), avec une offre Pro gratuite pendant un an pour les étudiants
Lancement officiel de Jules et améliorations majeures
- L’agent de codage IA asynchrone de Google, Jules, a terminé la phase de test bêta et a été officiellement lancé
- Jules s’appuie sur la fonction de pensée avancée (Advanced Thinking) de Gemini 2.5 Pro pour établir un plan de codage (Plan) avant le travail, ce qui permet de générer du code de meilleure qualité
- Pendant la phase bêta, plusieurs milliers de développeurs ont réalisé des dizaines de milliers de tâches et partagé plus de 140 000 résultats d’amélioration de code
Expérience utilisateur et retours intégrés
- En s’appuyant sur les retours des développeurs, l’interface utilisateur (UI) a été repensée et plusieurs centaines de bugs ont été corrigés
- L’introduction de la réutilisation des paramètres précédents permet d’accélérer l’exécution des tâches répétitives
- Intégration à GitHub Issues pour une intégration du workflow de développement
- La prise en charge des entrées multimodales permet de traiter différents formats de données
Paliers d’abonnement et mode d’utilisation
- Jules est proposé avec des paliers d’abonnement structurés (Introductory, AI Pro, Ultra), et peut être choisi selon votre cas d’usage
- Introductory : orienté guidage et prise en main pour les utilisateurs de base
- Google AI Pro : 5 fois la limite de base, adapté au codage quotidien
- Google AI Ultra : 20 fois la limite de base, optimal pour les workflows multi-agents à grande échelle
- Les abonnements Google AI Pro et Ultra sont déployés progressivement à partir d’aujourd’hui, avec un AI Pro gratuit pendant un an pour les étudiants
Jules peut être démarré immédiatement via jules.google
1 commentaires
Avis de Hacker News
Je me demande pourquoi le modèle d’abonnement de Google est devenu si compliqué. Avec "Google AI Ultra", on a Jules, Gemini App, Notebook, etc., mais pour utiliser Gemini CLI il faut créer un abonnement séparé avec un compte de facturation GCP et acheter Google Code Assist, ce qui est vraiment pénible ; ensuite, dans ce cas, Gemini App n’est pas fourni non plus. Et, bizarrement, avec l’abonnement Google AI on obtient aussi YouTube Premium, je ne comprends pas pourquoi c’est lié.
Il semble qu’il existe chez Google deux équipes distinctes qui gèrent les produits IA. Dans l’entreprise, avec Workspace, Gemini, Veo 3 et Jules sont inclus, et avec un seul abonnement on peut les utiliser de façon (un peu) illimitée ; le point d’entrée principal est gemini.google.com. En revanche, pour les besoins d’API, il faut passer par GCP ; on peut y utiliser des modèles plus avancés comme Veo 3 et des fonctionnalités supplémentaires, mais c’est facturé selon l’usage. L’accès se fait via GCP Vertex AI. Les deux organisations paraissent assez séparées et semblent ne pas savoir précisément ce que fait l’autre.
Si l’on a créé un Workspace via Google for Domains auparavant, ça peut devenir très pénible : rien ne fonctionne correctement.
Je peux regarder des vidéos YouTube pendant que l’IA code.
Le vrai business de Google est la vente publicitaire et le maintien de sa domination de marché (Analytics, Chrome, Chromebook, Android, Google SSO, etc.) ; les produits destinés aux développeurs sont des activités périphériques de plusieurs blocs internes de Google, et ne peuvent pas être une priorité absolue.
Contrairement à certains éléments inclus dans l’abonnement Ultra, YouTube Premium ne se partage pas en famille. Il faut donc utiliser les deux séparément, et Google rappelle à plusieurs reprises de ne pas faire comme ça.
J’ai testé Jules récemment sur un side project (app React Native). En me promenant pour aller au travail ou rentrer chez moi, je réfléchissais à de nouvelles idées/fonctionnalités, je les planifiais, je faisais des modifications via l’app GitHub et j’ai confié quelques tâches à Jules ; en rentrant le soir, il y avait un PR généré. La qualité du code n’est pas parfaite, mais ça fonctionne généralement, donc je peux tester tout de suite puis corriger directement, ce qui permet d’itérer vite. La prochaine étape est d’ajouter un build automatique à chaque PR pour pouvoir vérifier les branches directement sur mon téléphone, même en rentrant.
Je ne sais pas si c’est pareil avec React Native, mais avec Vercel pour le déploiement et Neon comme base de données, c’est très pratique de pouvoir prévisualiser en live chaque branche/commit/PR. En venant de l’écosystème Python, cette chaîne commit-déploiement réduit vraiment les frottements pour le coding exploratoire/expérimental ; la question "quoi faire" se résout de plus en plus en testant ce qui a été construit. Bien sûr, ça marche correctement seulement quand la feature est assez simple pour être totalement réalisée en une fois par un LLM.
Le coding d’exploration asynchrone est une tendance actuelle ; je recommande aussi GitHub Copilot Coding Agent (ce n’est pas le plugin VSCode de GitHub Copilot, mais un Agent séparé).
J’ai déjà branché Jules à un repo GitHub peu entretenu pour lui confier de petites tâches — mise à jour de dépendances, refactoring, petites fonctionnalités, changements de style, etc. — et c’est plutôt bien dans ces cas-là, même si je ne lui confierais pas un dev important.
C’est justement pour cette raison que j’ai créé superconductor.dev. Une prévisualisation d’app en live est supportée par agent, avec Claude Code, Gemini, Codex et Amp. Si vous êtes intéressés, dites-moi votre pseudo lors de l’inscription HN, je vous inviterai en priorité.
J’ai utilisé Jules plusieurs fois pendant la période de préversion, et jusqu’à présent c’était le moins bon des assistants de codage cloud que j’ai testés. Je pensais qu’il serait abandonné après une courte phase expérimentale, et je n’imaginais pas qu’il serait réellement lancé en produit, un peu comme GH Copilot Spaces qui est devenu Copilot Agent. Jules fait à sa sauce, dit qu’il a "fini" puis, quand je pose des questions de suivi, il bafouille ; l’environnement n’est pas stable non plus et il arrive qu’il ne fonctionne pas du tout. En réalité, il n’y a eu qu’une seule PR mergée de mémoire ; pour les autres, j’ai tout annulé et réaffecté au prochain agent. Mon classement personnel est : Claude Code (via gh action) > ChatGPT Codex > GitHub Copilot Agent > Jules. J’ai reçu récemment une nouvelle période d’essai de 3 mois donc je vais réessayer aujourd’hui, mais si ça reste pareil, je ne mettrai ni argent ni temps dans Jules à l’avenir ; je recommande Codex ou GitHub Agent. Merci de comprendre mes critiques.
Je me suis encore une fois essayé à Jules de manière neutre aujourd’hui, et c’est toujours mauvais.
J’ai la même expérience ; personnellement je valorise plus un Codex avec une rate limit plus généreuse que Claude. Jules est trop dispersé, et le mode où il ne produit que des pull requests ne me plaît pas. L’option de copier-coller directement un git patch comme avec Codex, puis de l’ajuster et de committer comme je veux, est beaucoup plus utile.
Je n’ai pas encore testé en profondeur, mais je me demande si le mode agent asynchrone sera vraiment aussi utile que d’exécuter Claude Code en local. Comme il faut intervenir en permanence pour vérifier que tout fonctionne, ça semble demander un cycle complet pull, build, run, test, ce qui paraît lourd ; en local, vérifier sur un environnement chaud est bien plus efficace.
Je pense avoir vu la même chose dans le texte sur GH Copilot Spaces ; j’ai l’impression que Google prépare ça pour l’avenir. Même si l’IA ne peut pas encore tout gérer parfaitement, attendre qu’elle soit totalement au point pour implémenter une feature serait trop tard quand le changement arrivera. Personnellement, je doute que les LLM résolvent entièrement le problème ; il y aura toujours quelque chose au-delà du LLM.
Sur le plan gratuit, la limite quotidienne est passée de 60 à 15 tâches ; dans mon cas, qui en fait beaucoup, je ne l’ai même pas atteinte. Pour contacter directement l’équipe Jules, vous pouvez écrire sur discord.gg/googlelabs.
J’ai essayé Jules avec la consigne "écrire un raytracer basique en Rust" il y a un ou deux mois, puis à nouveau aujourd’hui. Il y a un mois, le code compilait au moins quelque chose ; cette fois, il ne push pas non plus la branche, et quoi que je demande il ne le fait jamais, donc impossible de vérifier que le code tourne vraiment. J’ai ensuite créé deux main.rs dans des répertoires différents en éparpillant le code au hasard ; après lui avoir expliqué le problème, il a exploré tout le système de fichiers avant d’abandonner.
Le modèle d’interaction pour le push des commits est incompréhensible, c’est vraiment déroutant.
Ce n’est pas un outil zero shot ; je ne comprends pas pourquoi tout le monde essaie en zero shot.
La montée en puissance face à Codex me plaît ; je pense que les agents asynchrones cloud comme Codex ou Jules sont meilleurs que les approches intégrées localement comme Claude Code, Aider ou Cursor. Ils sont complètement isolés de mon environnement local, donc beaucoup plus sûrs, et le fait d’envoyer seulement des commandes puis de faire autre chose sur mon PC en attendant de consulter le PR plus tard me semble préférable à la configuration d’un sandbox ou à l’usage de git worktree.
Codex et Jules sont totalement différents de CC et Cursor, un peu comme dans le débat Cathedral vs Bazaar en logiciel :
L’isolation complète est plus sûre, certes, mais c’est aussi plus lent et plus coûteux. Avec CC, on peut parfois arrêter immédiatement quand quelque chose tourne mal ; en asynchrone, on peut revenir quelques heures plus tard sur une catastrophe et consommer beaucoup de tokens.
Proposer des changements en mode PR sur une base de code existante est le mode d’adoption le moins dissonant pour un dev, car on est déjà habitué au workflow de review. Mais imposer un workflow humain classique à des propositions d’agents en masse atteint vite ses limites. Il faut donc un workflow de revue automatisé pour traiter plus efficacement un plus grand nombre de suggestions, et les approches CLI comme Claude, Aider exploitent selon moi le mieux l’échelle des agents async/parallèles.
À ce sujet, j’ai aussi créé une bibliothèque d’assistance pour Claude/Agro.
De plus, tout cet environnement dev devrait rester open source pour éviter une dépendance à l’infrastructure de MS, OpenAI, etc.
Je suis en train de compiler des tips de revue en CLI dans une documentation d’études de cas.
À noter, Claude code peut aussi faire de l’asynchrone via GitHub actions, et la commande slash de Claude code prend aussi en charge le setup automatique.
Le plus productif me semble être un setup hybride entre agents asynchrones cloud et approche locale interactive (Claude Code, Cursor, Aider). J’aimerais déléguer à Codex UI uniquement les tâches itératives et simples, et garder le reste en local. Ce qui me gêne sur la machine Codex, c’est la lenteur : compile, rebuild et cache de dépendances se répètent sans cesse. Si l’UI, les outils et l’état étaient gérés localement tandis que l’inférence LLM restait distante, le workflow serait bien plus rapide.
En utilisant Jules sur des side projects, j’ai trouvé la qualité du code nettement inférieure à celle de GH Copilot (Claude Sonnet), Gemini CLI et Claude Code, en particulier dans un monorepo où la logique de changement de répertoire se bloque en permanence : il est déjà dans backend mais exécute sans cesse des commandes cd, et semble incapable de bien raisonner sur la structure.
Mais Jules met en avant qu’il s’appuie désormais sur la capacité de planification avancée de Gemini 2.5 Pro, ça peut valoir la peine d’essayer à nouveau.
C’était ma première utilisation ; la refonte complète de la couche data a été étonnamment bien gérée, bien plus que je n’attendais. J’ai aussi été bluffé à un moment avec Copilot, mais à force d’usage l’IA ralentit et devient confuse, ce qui finit par faire perdre du temps. C’est le visage actuel des coding agents IA.
J’ai testé un petit changement pour ajouter une sortie colorée au terminal sur un side project, et le résultat de PR était excellent. Les agents de code LLM ont des points forts sur certains travaux et des points faibles sur d’autres, comme si les résultats étaient aléatoires ; malgré cela, avec un seul prompt j’obtiens un PR, même en cas d’échec la charge est faible, et le retrigger est simple.
Le concept et le terme "agent de coding asynchrone" me plaisent bien. J’ai trouvé l’article de LangChain sur l’introduction d’un async agent open-source et aussi un cas d’usage d’agent coding Copilot. J’espère que cette dynamique va s’ancrer.
En 2025, seul Claude Code est un agent à proprement parler. Gemini reste quand même puissant sur les contextes longs, cf. ce débat Reddit.
Je suis d’accord : Google fait bien sur les benchmarks et annonce des modèles comme World Models Genie 3, mais les recommandations/modifications de Gemini CLI sont trop rigides, obsédées par des détails de style comme les tabs/espace, avec une approche presque OCD. Par exemple, sur un projet récent, j’ai dépensé ma limite quotidienne de tokens sur des tâches futiles : réglages ESLint, modularisation de code inutile, etc. En revanche, Claude Code répond mieux à mes besoins et aide davantage au dev de features utiles. Peut-être une question de prompt, mais Claude Code semble mieux me comprendre.
Je partage cet avis ; je ne veux pas que le workflow de revue de PR intervienne en plein milieu. Le killer feature de Claude Code, c’est de pouvoir reprendre la main instantanément dès qu’il part de travers, avec une intervention facile via mon propre codage en direct. C’est un peu comme laisser un junior faire une full feature sans contrôle ponctuel.
Sourcegraph Amp est aussi assez bon ; il n’a pas la même maturité ni les mêmes features que Claude Code, mais en review de code je passe souvent par l’outil « oracle » avec o3.
Je ne comprends pas pourquoi les informations de prix sont aussi peu visibles : il faut parfois passer par Grok pour les trouver, et sur le site Google on doit accepter des conditions pour voir ne serait-ce qu’un aperçu du plan. Au passage, les plans/prix sont visibles sur gemini.google/subscriptions (une connexion peut être demandée).
Je pense que mentionner "Highest task limits" ou permettre de modifier ensuite les conditions d’usage comme le font Claude ou Cursor devrait être interdit légalement.
Je me demande ce que signifie qu’il ait fallu utiliser Grok : c’est qu’avec d’autres modèles ça ne marche pas, ou bien que tu l’utilises souvent ? Merci d’en dire plus.