Il n’a pas fallut attendre longtemps. Tout récemment (on parle de 48h à peine), un nouveau modèle a été dévoilé et la situation illustre bien ce que je disais. Souhaitons la bienvenue à Kimi K3, le nouveau nouveau meilleur.

Comme d’habitude, ça fait sensation. Si on regarde les créateurs de contenu, les influenceurs et même certains médias (ce qui est ecnore plus triste), tout le monde lâche ses plus beaux superlatifs : “C’est le meilleur”, “Ça va tout tuer”, “Fable 5 est déjà dépassé”. Bon, si on regarde dans le passé, c’est systématiquement la même chanson à chaque sortie de grand modèle.

J’ai envie d’en profiter pour prendre tout ça à contrepied, apporter de la nuance et sortir de cette logique de faire du sensationnel pour avoir des vues.

Un point sur les benchmarks

Qu’est-ce que ça veut dire concrètement, “être meilleur” ?

Souvent, l’élément phare cité dans les articles/vidéos/newsletter est un benchmark. Un tel est le nouveau meilleur parce qu’il a gagné plus de points que l’autre.

Mais rappellons quelques éléments :

• les benchmarks sont plus ou moins fiables, ils mesurent une fration des capacités et sont parfois purement subjectifs,
• c’est arrivé que certains modèles ont été (in)volontairement entraînés sur des benchmarks, ce qui fausse la donne,
• on a vu plusieurs fois des modèles devenir “moins bon” un peu après la release,
• le classement bouge sans cesse, pas de quoi se précipiter à changer.

Donc le benchmark, oui c’est un moyen de comparer, mais il ne faut pas rester dessus. Je pense qu’il faudrait plutôt garder ça comme un moyen d’avoir un aperçu, un tri rapide.

Là comme ça, j’ai l’idée de l’atelier eXtreme quotation qui me traverse l’esprit - ce modèle fait partie da la famille du top top (XL), ou non plutôt basique (du M).

Kimi K3, en surface

Parlons maintenant de Kimi K3 pour donner du contexte. C’est un modèle open-source de 2,8 billions de paramètres, qui rivalise avec les géants propriétaires sur certains tests de programmation, et qui occupe même la première place du classement Arena.ai pour le code front-end.

Il est devant Fable 5, qui était jusque-là le nouveau roi avec GPT 5.6 Sol, et tout ça, pour un prix bien inférieur.

Donc en résumé, on a mieux et moins chère. Que demander de plus ?

En profondeur

Ce qui m’a donné envie d’écrire, c’est une vidéo du créateur Chase AI. Il a sorti une comparaison intéressante entre Kimi K3, Claude Fable 5 et GPT 5.6 (ou ChatGPT).

Déjà, on commence à voir de la nuance - il y a d’autres aspects qui sont analysés. Par exemple, la rapidité, les hallucinations, l’économie des tokens, etc. On ne reste pas juste sur le classement de quelques benchmarks. Et c’est intéressant car on voit que ça pêche sur certains points.

Je ne vais pas tout détailler, car mon but n’est pas de descendre Kimi K3 ou d’encenser Fable 5, on s’en fout. Mais plutôt de montrer que la réponse est plus complexe qu’il n’y paraît. Donc rapidement, quelques aspects :

• La “consommation de token” : Pour une même tâche, pour un même prompt, chaque modèle va consommer plus ou moins de tokens. Kimi est réputé pour en gaspiller beaucoup plus.
• Le “coût par tâche” : Un comparaison du coût réel pour accomplir une tâche complexe. Kimmy K3 (0,95 $) est légèrement moins cher que GPT 5.6 (1,04 $), mais Fable 5 est beaucoup plus onéreux (2,75 $). Malgré le “coût par token” très faible de Kimi, le coût réel ne se démarque pas autant des autres à cause d’une plus grande consommation d’un côté / d’un meilleur optimisation de l’autre côté.
• L’ “index d’omniscience” : C’est une mesure sur la fiabilité des réponses et la quantité d’hallucinations. Fable score 40 points sur 100, GPT score 22, Kimi score 18.
• La “vitesse d’exécution” : Kimi est plus lent que ses copains Fable et GPT.

On s’éloigne finalement un peu de la hype qui entoure sa sortie et de tous les superlatifs. Finalement, il y a du bon et du moins bon, on nuance, on mitige. On n’est plus trop sur le fameux “Fable-killer”.

Le cas pratique

J’aime bien aussi l’expérience que montre Chase AI dans sa vidéo. Il a fait créer un dashboard de voyage avec la planète en 3D aux trois modèles, avec les mêmes instructions. On obtient des informations concrètes à analyser.

Dans ce cadre là, Kimi K3 s’avère être un énorme consommateur de tokens. Pour la même demande, il a englouti 21,5 millions de tokens là où Fable 5 n’en a consommé que 3,5 millions. Donc oui, Fable coûte plus cher au token mais il a été drastiquement plus efficace. Le prix final ne reflète pas la simple grille tarifaire. GPT 5.6 s’avère même être le moins cher des trois.

Le temps d’exécution est un autre indicateur. Là où Kimi K3 a ramé pendant plus d’une heure et demie, Fable 5 a plié l’affaire en 17 minutes et ChatGPT en 25 minutes.

Attention, cette expérience est imparfaite et unique. Ça ne vaut aucune vérité. Il faut aussi voir la qualité du rendu (subjectif) et surtout avoir bien plus d’expériences. Et probablement avoir une approche plus scientifique. Je m’appuie simplement sur ces résultats pour démontrer qu’il faut relativiser.

Retour à la base

Tout ça pour rappeler quelque chose que j’aime bien dire : quel est notre besoin ? Selon ce que l’on souhaite entreprendre, on aura besoin d’un outil moins cher, d’un modèle qui hallucine moins, d’une exécution plus rapide ou d’une plus grande qualité. Et puis, il y a différents domaines - un modèle peut exceller en design frontend et être à la traîne sur des questions scientifiques ou de la rédaction pure.

Donc sortons du sensationnalisme facile. Apportons de la nuance et restons centrés sur nos besoins réels.

Avec les agents IA, on ne demande plus seulement une réponse dans une conversation. On installe l’agent quelque part avec des fichiers, du contexte, des règles, des pouvoirs. Et là, il peut commencer à travailler dans un environnement, pas seulement répondre dans une fenêtre de chat.

C’est ce qui m’intéresse dans cet article : faire un premier pas concret. Pas devenir expert en automatisation, gestion de la mémoire, ou autres concepts qui gravitent autour. Non, juste créer un premier workspace IA, lancer une vraie tâche, et comprendre pourquoi ça change autant de choses.

Derrière ce titre à double sens, je vous propose donc un début accessible pour tous. Pas besoin d’être tech.

Rappel important : les IA (agent ou chat) peuvent réutiliser vos données. Faites attention au service et type d’abonnement que vous utilisez, et aux informations que vous communiquez.

Du chat à l’agent, il manque surtout un espace de travail

Dans l’article précédent sur les agents IA, je donnais l’image d’une boucle pour définir un agent : observer, décider, agir, observer à nouveau.

Un chat classique répond à ce qu’on lui donne. Si on oublie un contexte, il ne l’a pas. Si on veut qu’il reformate un fichier, il faut lui donner, expliquer la structure, récupérer le résultat, et le ranger quelque part. Ça marche, mais on finit vite par être l’assistant de notre propre assistant IA.

Un agent, lui, devient vraiment intéressant quand il a un endroit où travailler. Un dossier, des fichiers, des consignes, des exemples, du contexte, des notes, etc. Il devient davantage autonome pour atteindre un objectif.

Et c’est là-dessus qu’on va se concentrer. Notre premier pas avec les agents IA, ce ne sera pas d’écrire le prompt parfait, ni de trouver le meilleur modèle ou plateforme. Ce sera de créer un espace où l’agent peut comprendre notre contexte, poser les bonnes questions, puis produire quelque chose qui nous correspond.

Ah, et bonne nouvelle, ce premier espace est très simple à préparer.

Choisir une application, sans en faire une religion

Pour travailler avec un agent sur notre ordinateur, il faut généralement une application qui peut accéder à un dossier local, lire et manipuler des fichiers, lancer des commandes. C’est ce qui permet de passer du “chat” à un “agent qui travaille dans un projet”.

Aujourd’hui, on trouve plusieurs outils grand public dans cette famille : Claude Cowork côté Anthropic, ChatGPT Codex côté OpenAI, Antigravity côté Google, Cursor en précuseur pour les devs, et sûrement d’autres au moment où vous lirez ces lignes. Ce sont des applications à télécharger et installer sur un ordinateur.

Lequel choisir ? Honnêtement, pour commencer, je trouve que c’est moins important que le système que vous mettez en place autour.

Les modèles progressent vite, les abonnements changent, les limites bougent, et chacun aura ses préférences selon ses usages. J’en parlais déjà dans mon article sur le “meilleur” modèle IA : la bonne réponse dépend du contexte. Pour mes besoins actuels, j’ai une préférence pour Codex, avec Claude pas loin derrière. Mais ce n’est pas une véritée absolue.

L’important, pour ce premier exercice, c’est surtout de choisir un outil capable d’ouvrir un dossier de travail et d’agir sur des fichiers. Faites votre choix puis installez l’application sur votre ordinateur. Une fois que vous avez ça, on peut préparer l’espace de travail.

Préparer un premier workspace IA

On va partir sur une structure volontairement simple pour notre espace de travail. Ce n’est pas la bonne structure. C’est une structure pour commencer, que vous adapterez ensuite à votre façon de travailler et au fil de vos découvertes.

Une précision. Quand je parle d’espace de travail ou workspace, c’est tout simplement un dossier que vous ouvrirez avec votre application. L’agent pourra jouer avec tout ce qu’il y a à l’intérieur.

Vous allez donc devoir créer un dossier “workspace” où bon vous semble (sur votre bureau, dans vos documents) et avec le nom que vous souhaitez. Il faudra ensuite créer cet ensemble de dossiers et fichiers à l’intérieur du dossier workspace, qui correspond à notre structure :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Ici, plusieurs solutions. Via votre explorateur de fichier / Finder. Via Obsidian. Via un IDE ou en terminal. Peu importe. Ou sinon… pourquoi ne pas demander à un agent ? Après tout, on vient de dire qu’il peut manipuler des fichiers dans son espace de travail, alors profitons-en.

Faisons notre toute première tâche avec un agent :

• Lancez donc votre application (pour rappel, il s’agit de Claude Cowork, ChatGPT Codex, etc).
• Ouvrez votre dossier “workspace” (selon l’application, il faut créer un projet en ciblant le dossier).
• Démarrez une nouvelle conversation (en ciblant bien le dossier/projet) et demandez lui de travailler durement !

Crée l'arborescence de dossiers et les fichiers vides suivants dans mon workspace actuel :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Et voilà. J’en profite pour une rapide explication, à quoi servent chacun de ces dossiers ?

• 00-contexte contient ce que vous ne voulez pas répéter à chaque fois : qui vous êtes, comment vous travaillez, votre style, vos règles.
• 01-projets contient les informations et documents propres à chaque projet en cours. On peut imaginer des projets ma newsletter jardinage et ma super entreprise de plomberie par exemple.
• 02-templates garde la définition de vos formats à réutiliser. Le template d’une newsletter par exemple (les sections, la description de chaque section, etc), ou d’un mail de prospection.
• 03-livrables sert à ranger ce que l’agent produit.

Vous pouvez évidemment faire autrement. Ajouter un dossier archives pour les projets terminés. Un dossier ressources pour capturer des articles, posts, vidéos ou notes. On peut aussi définir des règles et styles par projet plutôt que pour tout le workspace. Ou partir sur une structure plus proche d’un wiki, comme le wiki proposé par Andrej Karpathy.

Ce qui compte, c’est que ça corresponde à vos besoins et que l’agent puisse se repérer sans que l’on doive tout réexpliquer à chaque prompt.

Les premières informations de contexte

Dans le dossier 00-contexte, on va créer trois fichiers Markdown.

Petite parenthèse sur Markdown : c’est un format de texte très simple, avec quelques symboles pour la mise en forme (gras, titre, liens). Vous pouvez apprendre le Markdown en 5 minutes avec mon guide. Au pire, vous écrivez du texte sans aucune mise en forme ou n’utilisez que des titres avec # et des listes avec -.

Son gros avantage, c’est qu’il est lisible partout. C’est du texte. On reste propriétaire de nos fichiers, et les modèles IA comprennent parfaitement ce format.

a-propos-de-moi.md

Ce fichier sert à donner le contexte humain, perso et professionnel. Qui vous êtes, ce que vous faites, vos sujets, vos objectifs, vos contraintes, vos rôles, vos domaines, etc.

L’idée n’est pas d’écrire une autobiographie complète. L’idée est d’éviter de répéter à chaque demande : “je suis indépendant”, “je suis expert en”, “mes clients sont”, etc. Pensez donc à tout ce qui sera utile à l’agent pour réussir les objectifs que vous lui donneraient.

Commencez simplement, et améliorez-le au fil du temps.

Pour donner des exemples tout au long de cet article, imaginons un personnage fictif :

# À propos de moi

Je suis Arthur, président de l'association "La Table Ronde".

Je gère une équipe de chercheurs sur le terrain (les "chevaliers"). 

Mon rôle est de suivre leurs avancées et de valider l'utilisation de notre budget annuel (financement de l'association).

Mes priorités quotidiennes :
1. Cartographier précisément les zones explorées pour éviter les doublons.
2. Suivre les indices concrets (sources historiques, pistes archéologiques).
3. Surveiller les dépenses logistiques (frais de déplacement, tavernes, équipement).

mon-style.md

Ce fichier décrit votre façon d’écrire et communiquer. Le ton, niveau de détail, structure, mots à éviter. Ajoutez aussi des exemples et contre-exemples pour aider l’agent à comprendre votre plume. Les exemples sont très puissant, mettez-en !

J’en profite pour glisser une astuce : utilisez votre agent pour vous aider à remplir ce type de fichiers. Vous pouvez lui demander de vous aider avec une suite de questions/réponses par exemple. Ou vous pouvez lui fournir des textes que vous avez rédigés. À vous de voir.

# Mon style

- **Ton :** Direct, pragmatique, professionnel mais accessible.
- **Structure :** Toujours utiliser des listes à puces et des tableaux pour les chiffres. Pas de longs paragraphes.
- **Niveau de détail :** Synthétique.
- **Formulations à éviter :** 
    - Supprimez toutes les formules de politesse excessives (pas de "noble roi", "Sire", "seigneur") 
    - Aucune expression vague ("on a cherché partout", "pas mal d'argent"). Je veux des faits précis.

regles.md

Ce fichier pose les règles de fonctionnement de l’agent. Ce qu’il doit faire, éviter, demander, où il doit écrire les résultats, comment nommer les fichiers. Et aussi comment fonctionne notre espace de travail.

# Règles de fonctionnement de l'agent

Tu dois respecter strictement les règles suivantes :

- **Limites de connaissances :** 
   - Si une information importante manque, pose une question plutôt que de supposer.
   - Dis explicitement quand tu n'es pas sûr.
- **Gestion du workspace :**
   - Ne modifie jamais les fichiers du dossier `00-contexte` sans me demander.
   - Mes projets en cours sont situés dans `01-projets`.
   - Mes templates sont dans `02-templates`.
   - Écris toutes les synthèses générées exclusivement dans le dossier `03-livrables`.
- **Traitement des données :** 
   - Ignore systématiquement les anecdotes personnelles, les histoires de taverne, les plaintes sur la météo ou la nourriture.
   - Ne conserve que : la zone géographique explorée, les indices concrets, et le montant total des dépenses.

Ajouter des instructions globales

Il faut savoir que les agents ne lisent pas automatiquement nos fichiers - son contexte exploserait sinon. Il faut soit directement les mentionner dans un prompt, soit que l’agent estime de lui-même qu’il doit lire le contenu de nouveaux fichiers pour réaliser son objectif.

Il y a quelques exceptions. Il est possible de créer des instructions globales. On peut les ajouter dans les paramètres de l’application, ou en créant un fichier spécial à la racine de notre workspace : AGENTS.md (pour la plupart) sinon CLAUDE.md (pour Claude).

C’est comme un brief permanent pour l’agent, il chargera ces instructions à chaque conversation. Et ça nous intéresse. On a au moins envie de lui indiquer de prendre en compte nos fichiers de contexte pour éviter de devoir lui rappeler à chaque fois.

Avant chaque tâche, commence par lire les fichiers du dossier `00-contexte`.

Je conseille d’utiliser les fichiers de type AGENTS.md/CLAUDE.md plutôt que les paramètres de l’application. Si demain vous changez d’outil, vos fichiers restent là. Vous n’avez pas tout caché dans les réglages d’un compte ou d’une app.

Autre chose à savoir, vous pouvez être granulaire. Une instruction globale à la racine du workspace, puis des instructions locales dans un dossier projet. On a des informations, règles, styles qui ont du sens uniquement pour un projet.

AGENTS.md
01-projets/
└── graal/
    └── AGENTS.md

Première mission

Ça y est, la base est prête. Vous pouvez commencez à utiliser un agent personnalisé avec votre contexte, dans votre projet.

Mettons-nous à la place d’Arthur. Que pourrait-il faire ? Il reçoit de nombreux rapports de quêtes de la part de ses chevaliers. Des rapports très longs, bourrés de détails inutiles, de plaintes, d’anecdotes de tavernes, etc.

• Rapport de Perceval et Karadoc
• Rapport de Lancelot

Il n’a pas de temps à perdre, il a déjà beaucoup de responsabilités. Il aimerait bien avoir des synthèses avec les informations essentielles pour prendre des décisions. Et ça tombe bien, dans son contexte, il a déjà indiqué son style et ses règles.

Il lui suffirait de mettre les fichiers texte contenant les rapport dans le dossier 01-projets/graal/rapports et de faire une simple demande à un agent :

Pour le projet Graal, je veux une synthèse des rapports des chevaliers.

Et ça suffit. On voit tout de suite la différence avec un chat. Ici, l’agent possède tout le contexte utile. Il peut décider d’aller chercher d’autres informations (les rapports). Puis il va réaliser la tâche demandée à l’origine : faire une synthèse. Le prompt est d’ailleurs assez court, car l’espace de travail a été préparé en amont.

• Synthèse générée par l’agent

C’est un cas d’usage simple, mais il permet de voir la puissance des agents. On pourrait lui demander de générer des slides sur Google Sheet pour faire une présentation des avancées. Ou de tenir à jour notre fichier Excel des dépenses.

Ce qu’il vous faut maintenant, c’est détecter quels sont tout vos process, ceux que vous répétez le plus et qui pourraient vous apporter rapidement de la valeur.

Les vérifications restantes

Une ia peut toujours se tromper, haluciner, mal interpréter une note, oublier une contrainte, etc. Vérifiez toujours le résultat. Puis, éventuellement, améliorez votre espace de travail.

Par exemple, si l’agent écrit toujours trop long, améliorez mon-style.md. S’il modifie des fichiers qu’il ne devrait pas toucher, précisez regles.md. S’il oublie une section dans chaque livrable, modifiez votre template.

C’est là que le workspace devient intéressant. Il s’améliore avec l’usage.

Pour aller plus loin

Nous voilà avec une bonne base de départ. Avec le temps, vous pourrez l’améliorer de nombreuses manières :

• en retravaillant le workspace, la structure,
• en ajoutant du contexte sur vous et vos projets,
• en connectant l’agent à d’autres outils et services (mails, drive, calendrier, slack, notion, …),
• en créant des SKILLS pour rendre réutilisable des process que vous faites régulièrement,
• en créant des tâches récurrentes,
• en creusant des concepts comme la mémoire, la gestion ducontexte, les tokens, etc.

Mais d’ici là, pratiquez, jouez avec votre nouvel espace de travail !

Sauf que non. C’est une mauvaise question. Ou plutôt, c’est une question trop large pour donner une réponse utile. Le meilleur modèle pour écrire du code n’est pas forcément le meilleur pour analyser une image. Le meilleur pour raisonner longuement sur un problème complexe n’est pas forcément celui qu’on veut appeler 200 fois par jour dans une automatisation de tri et résumé d’emails.

Ça ne veut pas dire qu’il ne faut pas comparer. Au contraire. Mais il faut comparer pour un usage, avec des contraintes, et en acceptant que la réponse soit temporaire.

Le meilleur… quand ?

Le premier problème avec la quête du graal meilleur modèle, c’est que la réponse bouge sans arrêt. Pas seulement dans les benchmarks. Aussi dans les usages, au sein des communautés, des développeurs qui testent des agents toute la journée, des créateurs, etc.

On le voit très bien dans les conversations autour de l’IA. Pendant plusieurs semaines, tout le monde ne jure que par Claude Code. Puis des restrictions s’ajoutent, un nouveau modèle GPT arrive avec une mise à jour de Codex et les retours changent. Puis Gemini redevient très présent. Les évolutions des modèles vont très vite en ce moment, la concurrence est féroce, tous se battent à coup de milliards pour essayer d’être le grand gagnant à la fin. C’est parfois dur à suivre si on y passe pas plusieurs heures chaque semaine.

Et puis, ce n’est pas toujours très objectif. Dans le tas, il y a les effets mode, des personnes qui montrent un cas impressionnant mais très ciblé pour un usage, des influenceurs qui montrent un système hyper complexe et impressionant à voir mais sans réel valeur dans la vraie vie. Un peu comme si on achetait une machine chirurgicale révolutionnaire à un million d’euros avec des nanos robots pour couper une pomme en deux. C’est à la fois over-engineered, et extrêmement cher pour le besoin. Et as-t-on vraiment besoin de quelque chose pour ça ?

Au moment où j’écris ces lignes, Anthropic a le vent en poupe avec ses modèles, notamment Opus. Mais c’est la photo du jour, elle changera très probablement. Et puis, c’est un ressenti global, ça ne concerne pas tous les usages.

Le meilleur… pour quoi faire ?

La vraie question commence ici : pour quoi faire ?

Pour un simple chatbot du quotidien, je veux surtout un modèle agréable, rapide, pas trop cher, capable de répondre correctement, rapidement, sans trop se tromper et sans faire de thèse. Dans ce cas, les modèles “basiques” de chacun des labs fait très bien le café - GPT-5.5 Instant, Claude Sonnet voire Haiku ou Gemini Flash 2.5. Le “meilleur” ici, ce n’est pas forcément le plus intelligent. C’est celui qui répond bien, vite, et sans coûter un bras pour résumer une recette de tarte à la myrtille. Les versions gratuites ou le premeir tier payant suffisent amplement.

Pour le code, on a besoin de quelque chose d’assez pointu. Une bonne maîtrise technique certes mais aussi un bon contexte, du raisonnement, de l’itération, etc. Aujourd’hui, Anthropic est très fort sur ce terrain, notamment avec les modèles Opus. C’est le chouchou des développeurs. Claude Code, qui vient avec l’abonnement payant, est un très bon plus. À côté, il y a toujours Codex, Copilot, et Cursor qui restent très pertinent.

Pour la recherche web, je mettrais plutôt Perplexity (même si je commence à moins aimer) et Gemini avec Deep Research dans la discussion. Là, le modèle compte, mais la capacité et l’outillage de recherche compte également beaucoup dans la balance : quelles sources sont trouvées, leurs fraicheurs, comment elles sont citées, etc.

Pour la rédaction et l’idéation, c’est encore une autre sensibilité. Certaines personnes préfèrent Claude pour le ton, d’autres GPT pour la structure. Et puis il y a aussi Google avec Gemini + NotebookLM + la suite Drive qui offre une immense contexte et capacité à absorber beaucoup de matière.

Pour l’image et la vidéo, on s’éloigne de la matière première textuelle. GPT Image 2 (OpenAI) et Nano banana 2 (Google) sont le top “grand publics” à mon avis, et puis il y a les très bons Flux et Midjourney. Côté vidéo, Veo (Google), Sora (OpenAI), Seedance, Kilng, reviennent souvent dans les discussions selon ce que l’on cherche à produire. Même là il faut encore diviser pour trouver le “meilleur”.

Et dans les automatisations ? Pareil, il faut encore découper plus fin. Je ne vais pas utiliser le même modèle pour résumer un article, classer un ticket support, extraire trois champs d’un email, … ou raisonner pendant dix minutes sur un incident de production. Pour des tâches simples, les modèles légers comme Claude Haiku ou Gemini 2.5 Flash me semble plus pertinents que les monstres de raisonnement. On pourrait même utiliser des petits modèles open-source en local (Llamma, Mistral). Pour une décision complexe, on prendra du plus haut de gamme avec les frontier models.

Le meilleur… à quel prix ?

Deuxième question intéressante, qui pique un peu : combien ça coûte ?

Il y a le prix par token, bien sûr. Un modèle très intelligent peut être pertinent pour débloquer un problème compliqué, mais disproportionné pour reformater un JSON ou résumer trois paragraphes. Utiliser Opus pour une tâche simple à la place de Haiku par exemple, c’est un peu comme sortir le bazooka contre ces foutus moustiques tigres (ça y est, ils commencent à repointer leur nez). Ça va coûter très cher en munitions.

Qu’on soit au sein d’un abonnement officiel, ou par API, ou via un aggrégateur (Mammouth, Abacus, …), utiliser un modèle haut de gamme va coûter beaucoup plus d’argent ou de quota.

Et justement, il y a ces fameuses limites. Quotas, fenêtres de contexte, nombre de requêtes, accès aux outils, restrictions selon les abonnements. C’est différent de partout, et ça bouge très très vite. Ces dernières semaines par exemple, je vois beaucoup critique envers Anthropic qui a durci un peu fort les conditions d’utilisations et réduit les limites. De l’autre côté, OpenAI donne l’impression d’avoir un peu plus d’air pour un abonnement équivalent.

Le meilleur… mais bien accompagné

On parle beaucoup du modèle parce que c’est la partie visible. La porte d’entrée. C’est avec lui qu’on discute au final. Mais aujourd’hui, dans un usage avancé, le modèle n’est qu’une partie du système. On dit que c’est le cerveau. Autour, il y a le reste : outils, instructions, mémoire, RAG, permissions, MCP, fichiers accessibles, et bien d’autres. Ça forme le corps.

C’est aussi appelé harness, c’est un des sujets chaud du moment je trouve - comment bien équiper notre modèle pour répondre à nos besoins spécifiques ?

Un bon modèle accompagné d’un bon harness devient beaucoup plus utile qu’un très bon modèle mal branché. Si mon agent a accès au repository, sait lancer les tests, connaît les conventions, se rappelle des décisions prises et peut lancer des commandes, il part avec un énorme avantage. À l’inverse, un excellent modèle isolé dans sa fenêtre de chat avec peu de contexte et outils va plus facilement haluciner en plus d’être limité en capacités.

On le voit très bien avec les agents de code. Le modèle compte beaucoup, mais les capacités de l’agent aussi : comment il explore le projet, relance les tests, se connecte à d’autres outils, sa gestion de la mémoire, etc. Deux environnements utilisant le même modèle peuvent donner une expérience très différente.

C’est pour ça que je trouve nul de réduire le choix à un simple “alors, Claude ou GPT ? c’est qui le dieu absolu ?”.

Choisir, c’est renoncer

Au final, je pense qu’il ne faut pas être loyal à un modèle ou entreprise. Parce que ça change trop vite, parce que ça dépend trop de nos usages et besoins. Et aussi parce que pour le moment, on a la chance de pouvoir facilement passer de l’un à l’autre. On ne se retrouver pas enfermé chez l’un si on commence à l’utiliser pour nos projets. On a encore un peu de chances de voir des concepts se retrouver en commun voire open-source (MCP, Agents.md, …).

La bonne stratégie, c’est plutôt de rester agile et de s’adapter quand ça change. Et de choisir ce qui se trouvera le plus adapté pour notre contexte. Probablement même d’en avoir plusieurs dans notre sac - un modèle rapide pour les tâches simples, un modèle très solide pour les raisonnements difficiles. Un bon outil de code. Peut-être que selon les mois on change d’abonnement. Ou qu’on en cumule deux petits plutôt qu’un Max.

Donc, la prochaine fois qu’on vous demande “c’est quoi le meilleur modèle IA ?”, vous pouvez répondre : ça dépend. Pas pour esquiver. Pour poser les vraies questions. Qu’est-ce que tu veux faire ? Quel budget ? Quelle confidentialité ? Avec quels outils ?

Un mois après cet article, un nouveau “meilleur modèle” a été dévoilé : Kimi K3. J’en ai profité pour aller plus en profondeur et m’en servir comme exemple et suite ce que j’ai raconté ici -> Kimi K3, le nouveau meilleur modèle IA de tous les temps (ou pas).

Je force un peu le trait, mais il faut bien compenser un peu le discours de certains :). Le mot agent est devenu un mot magique. On le colle sur un produit, un workflow, une démo, un chatbot un peu amélioré, et hop, ça donne l’impression qu’on a remplacé un humain.

Sauf que si on veut comprendre ce que c’est, il faut retirer vernis marketing et influenceur. Un agent IA, ce n’est pas une usine autonome qui tourne 24h/24 dans un coin. Je le définirais plutôt comme ça : un agent est un système qui utilise un modèle d’IA pour observer une situation, décider des prochaines étapes, utiliser des outils si besoin, puis recommencer en fonction du résultat obtenu.

Observer, décider, agir, observer à nouveau. C’est cette boucle qui change beaucoup de choses. On ne demande plus seulement une réponse à un chat. On demande d’avancer dans une tâche, d’atteindre un objectif.

Revenons un peu en arrière

Au départ, il y a les modèles de langage (LLM). Les modèles GPT permettaient de “prédir la suite probable d’un texte” (je prends un raccourci, mais l’idée de base est là). Ça marchait bien, et on s’est aperçu qu’en ajoutant un peu de contexte avant, ça permettait d’influencer le fond et la forme de la réponse.

À partir de là, il n’a pas fallu longtemps pour voir arriver la naissance de ChatGPT. C’est encore un modèle GPT dans l’arrière-boutique, mais cette fois avec une interface web par-dessus et un gros prompt système pour créer ce semblant de conversation. Et c’était déjà impressionnant. On pouvait demander une explication, reformuler un texte, générer du code, résumer un document, etc. Mais le fonctionnement restait assez simple : une demande, une réponse. Puis une autre demande, une autre réponse.

Plus tard, on voit apparaitre de premières connexions avec des outils, et même un protocole pour standariser cela (MCP). Les agents arrivent.

Ce qui change avec un agent

Un agent IA ajoute trois choses fondamentales. La première, c’est la capacité à utiliser des outils. L’agent peut lire des fichiers, les modifier, lancer une commande, chercher une information, suivre une todo-list, … Ça dépend évidemment de l’environnement qu’on lui donne, mais l’idée est là : il ne produit plus seulement une réponse directe, il peut agir dans cet environnement.

Agent : Je vais récupérer tes rendez-vous de la journée sur ton Google Calendar.

La deuxième, c’est la capacité à enchaîner plusieurs étapes. On ne lui demande plus uniquement “réponds à cette question”, mais plutôt “atteins ce résultat”. Il peut inspecter un fichier, constater qu’il manque une information, lire un autre fichier, lancer un test, corriger une erreur, puis revenir avec le résultat.

Agent : Je met à jour l’outil que tu m’a demandé. C’est fait. Oh, ça ne compile plus. Ok je viens de voir qu’il faut modifier ce fichier pour l’adapter avec la nouvelle façon de faire. Cette fois, c’est bon.

La troisième, c’est une forme de mémoire de travail. Parfois, c’est simplement l’état de la tâche en cours : à quelle étape il est, ce qu’il a déjà essayé, ce qu’il a observé, les erreurs rencontrées. Mais cette mémoire suffit déjà à créer une différence importante avec un simple prompt isolé. L’agent peut suivre un plan.

Agent : Je viens de comparer trois sources, j’ai gardé les points communs en tête, je vais maintenant pour voir générer un résumé.

Dans un usage technique, c’est très parlant. On peut demander “corrige ce bug”. Un chat classique va souvent répondre avec des hypothèses et du code à copier. Un agent, lui, peut lire le code existant, modifier un fichier, exécuter les tests, voir que ça casse ailleurs, ajuster, recommencer cette boucle trois fois jusqu’à avoir des tests OK, puis expliquer ce qu’il a fait.

On passe de “je te réponds” à “je peux avancer dans la tâche avec toi”. L’agent décide quoi faire en fonction de l’état, et il agit.

Comment on utilise un agent, concrètement ?

Le premier contact, pour beaucoup de monde, peut venir des chats web comme ChatGPT, Claude, Perplexity et bien d’autres. Aujourd’hui, ils ne cherchent plus à seulement répondre tout de suite. Ils ont beaucoup plus d’outils et de capacités - des connecteurs, du raisonnement, de la recherche profonde, etc. Ils peuvent analyser un document, faire une multitude de recherches sur le web, puis produire une analyse détaillée.

La frontière entre un agent et un chat devient un peu plus floue d’ailleurs. Ce qui est intéressant à observer maintenant, c’est si le chat / le service permet de réaliser des tâches, d’atteindre des objectifs. Et dans quel environnement.

Là où ça prend davantage forme, à mon sens, c’est avec les outils qui ont accès à un environnement permettant une plus grande liberté. Cursor, Claude Code, OpenAI Codex, et d’autres outils du même genre peuvent lire un projet sur notre machine, chercher dans les fichiers, créer ou modifier du code, lancer des commandes, puis se corriger selon le résultat.

La différence est assez marquante. Dans un chat web classique, on peut demander : “explique-moi comment réorganiser ce projet” ou “écris-moi un script pour faire ça”, et on devra ensuite le faire manuellement. En espérant avoir donné tous les bons détails et fichiers. Avec un agent lancé dans le dossier du projet, on va directement lui demander d’effectuer l’action, et il cherchera les informations lui-même. Il ne travaille plus seulement sur une description du problème, il travaille dans le contexte réel.

Note : j’ai pris l’exemple d’un projet de code, mais on peut également imaginer un dossier avec un ensemble de fichiers de comptabilité, d’idées pour une chaîne YouTube, etc. Cela reste des fichiers et du texte, c’est très facilement manipulable par un agent.

Les avantages d’un agent

On a vu qu’un agent peut utiliser des outils, premier bon avantage. On pourra lui demander de lire ou envoyer des mails, chercher une information sur le web, lister les retours clients sur Zendesk, etc. A priori tout ce qu’on pouvait faire à la main et qui contient une interface web / api / cli.

Autre gros avantage que l’on a aussi vu, c’est la possibilité d’enchaîner des étapes. Même si elles ne sont pas très complexes, c’est un gain d’autonomie. On n’est plus obligé de micro-manager un chat en lui disant étape par étape quoi faire. Ici, l’agent peut atteindre un objectif en trouvant lui-même le chemin.

Dit autrement, on pourrait parler de travailler dans l’incertitude. Si on veut créer un script ou une automatisation, on doit connaitre chaque étape au moment de créer cette automatisation, et il faudra que ça se passe bien comme on l’a prévu, sinon ça casse. L’agent, lui, peut réussir à s’adapter en cours de route.

Au final, l’agent a cette capacité de s’adapter. Et c’est peut-être là son plus gros avantage. On en revient à la boucle : observer, décider, agir, observer à nouveau.

Les limites à garder en tête

Un agent peut coûter plus cher à utiliser, même si ce n’est pas une règle absolue. Un agent léger, avec peu d’outils et peu d’allers-retours, peut rester raisonnable. Mais dans l’idée, un agent est plus autonome, il décide quoi faire, il explore, utilise une commande, lit un fichier ou un résultat, etc. Et tout ça, eh bien ça consomme plus de tokens. Avant, une partie de ces actions étaient du côté de l’humain alors que maintenant, l’agent doit le verbaliser.

Il y a aussi un côté moins prévisible. Un agent peut décider de faire dix étapes au lieu de trois. De charger un énorme fichier que l’on avait pas prévu. De reboucler car il n’est pas encore satisfait d’après sa compréhension du succès. On n’est plus sur un simple une demande, une réponse.

Il faut donc surveiller le contexte, les quotas, les tokens, et parfois simplement la pertinence de le lancer pour une petite tâche. Sinon, à la fin on obtient une facture salée (si on passe par l’API) ou une limite atteinte prématurément (paie-t-on l’abonnement supérieur pour continuer ?). Sachant qu’en plus, tout ça bouge beaucoup. C’est par exemple au tour d’Anthropic de mettre le feu à la communauté en ce moment avec un abaissement des limites et des nouvelles contraintes autour l’exécution autonome des agents (claude -p pour ceux qui suivent).

À côté de cela, il y a également la question du contrôle. Plus on donne d’outils à un agent, plus il peut faire de choses utiles et plus il peut faire de bêtises : modifier le mauvais fichier, envoyer une requête au mauvais endroit, mal comprendre une consigne, ou bien pire. La suppression de la base de données de production et des backups d’une entreprise par exemple ?

Ce qu’un agent n’est pas

Un agent IA, en lui-même, ce n’est pas forcément un système qui tourne tout seul 24 h/24. Si vous voulez quelque chose qui se réveille tous les matins, surveille une boîte mail, lance une analyse, envoie un rapport et recommence demain, il faut quelque chose autour.

Ça peut être un serveur. Un cron. Un outil comme n8n. Un outil d’orchestration. Un setup avec OpenClaw. Un Agentic OS (sûrement le prochain mot à la mode). Peu importe la forme exacte, mais il faut un mécanisme qui déclenche le travail, garde l’état, gère les erreurs, relance si besoin, stocke les résultats.

L’agent peut être une brique dans ce système. Par exemple, n8n peut déclencher un workflow toutes les heures ou selon un événement, récupérer des données, puis appeler un modèle d’IA pour analyser. Là, l’agent ou le modèle intervient à une étape précise. Mais l’autonomie globale vient surtout de l’orchestration qu’il y a autour. Autre exemple avec OpenClaw, c’est lui qui maintient en vie les agents avec un système de heartbeat et une communication par les messageries type Telegram, Discord, etc.

C’est une distinction importante. Sinon on finit par appeler “agent” n’importe quel automatisme un peu sexy.

Est-ce qu’on en a vraiment besoin ?

Pas toujours. Justement parce que parfois on a besoin d’une automatisation plus que d’un agent IA. Un truc prédictif qui est un enchainement de tâches définies et d’outils selon un déclencheur, par exemple. C’est “moins vendeur”, “moins à la mode”, mais c’est ce qui réponds au besoin.

“À chaque fois qu’un retour client arrive sur notre outil de support, on veut répondre automatiquement qu’on s’en occupe, puis l’ajouter dans sur notre board d’équipe et nous notifier sur Teams”.

Nul besoin d’un agent ici, un workflow sur n8n ou similaire fera l’affaire. Et vraiment si besoin, on peut y glisser un noeud IA (pour analyser le message par exemple), ce qui coûtera moins cher que si un agent faisait tout.

Et je pense que c’est le point le plus pratique à garder en tête. Un agent IA est intéressant quand la tâche est moins prédictible, demande plus d’adaptation ou d’autonomie. Qu’on ne connait pas le chemin. L’exploration pour corriger un bug est un bon exemple qu’on a vu précédemment, une boucle d’écriture/critique/réécriture d’un script de vidéo YouTube pourrait en être un autre.

Et puis parfois, peut-être même qu’un simple prompt pourrait suffire. Si on garde une bibliothèque de côté et/ou quelques fichiers d’instructions, on pourrait dans certains cas revenir à un mode de chat demande/réponse plus classique quand il n’y a pas un long chemin à parcourir.

Plusieurs questions à se poser donc, sauf si on n’a aucun problème avec l’argent et l’énergie :

• est-ce qu’on connait le chemin ? est-ce qu’il faudra s’adapter ?
• est-ce qu’on est sur une boucle d’actions / observations ?
• est-ce qu’on veut de la reproductibilité ?
• est-ce qu’une simple demande sur un chat suffirait ?

Bref

Un agent IA, ce n’est pas un nouveau collègue virtuel totalement autonome. C’est d’abord un modèle d’IA placé dans un système qui lui permet d’observer, de décider, d’utiliser des outils, puis de réagir au résultat pour continuer.

C’est puissant, surtout quand la tâche dépasse le simple échange question-réponse. Mais ce n’est pas magiquement autonome, fiable, économique ou nécessaire. Il faut encore un cadre, des permissions, dans certains cas une orchestration, et surtout un peu de jugement.

Donc avant de mettre un agent partout, je trouve plus sain de comprendre ce que c’est, puis partir du besoin. C’est ma culture produit qui parle. Parfois, l’agent est exactement la bonne brique. Parfois, un prompt suffit. Parfois, un script ou workflow fera mieux le travail. Le besoin avant la solution.

On a envie d’associer les deux, d’avoir notre IA de poche. En tant que créateur d’applications mobiles (Product Owner, Développeur, Designer), on peut y participer !

J’en profite pour expliciter les différentes interactions qu’il peut y avoir avec l’IA sur un smartphone :

• Un utilisateur peut jouer avec l’IA du système qui est intégré dans divers composants pour par exemple reformuler une phrase, générer une image, faire une action, etc. Le développeur n’a pas la main dessus, c’est le système qui gère.
• Le développeur peut apprendre à l’IA du système comment interagir avec son application, en exposant certaines données et intentions. L’utilisateur pourra par exemple lancer une action réalisée par l’application via Siri.
• Le développeur peut créer des fonctionnalités boostées à l’IA au sein de son application. L’utilisateur pourra s’en servir depuis l’application.

Aujourd’hui, on va se concentrer sur le dernier cas : créer des fonctionnalités augmentées par l’IA. On va se donner un aperçu de ce que l’on pourrait faire dans nos applications et des options pour y arriver.

Quelques exemples d’usages

Ce que l’on voit le plus souvent, ce sont des fonctionnalités qui manipulent un contenu textuel déjà présent. On propose de résumer l’article actuellement affiché dans une application de news, par exemple. On pourrait aussi sélectionner un paragraphe et demander plus d’explications. Ou même traduire. On peut également proposer à l’utilisateur d’améliorer le contenu qu’il a créé - il pourrait reformuler, corriger, compléter.

Générer du contenu grâce aux données personnalisées est un autre usage intéressant. Une application de liste de courses pourrait par exemple proposer des idées de recette en fonction des aliments ajoutés par l’utilisateur. Peut-être même que des recommandations pourraient apparaître autour de la nutrition.

Et pourquoi pas un champ de texte voire un chat pour trouver et utiliser des fonctionnalités existantes dans l’application ? Sur une application complexe avec beaucoup de pages et de profondeur, ce pourrait être pratique. L’utilisateur pourrait demander de “réserver un aller-retour à Valence pour demain” ou “envoyer 100€ à ma mère” avec ses propres mots.

De nombreuses possibilités existent aussi du côté des jeux. En faisant varier des dialogues, ou en les créant pleinement. En générant des niveaux, des parties, des quiz. Peut-être même que l’utilisateur pourrait indiquer un thème, non prévu initialement, et le modèle d’IA ferait le reste. On commence tout juste à gratter la surface, à imaginer de nouveaux usages.

État des lieux

Les innovations et les possibilités qui tournent autour de l’IA vont vite (sauf chez Apple, qui a à la fois du retard et un cycle de release long - petite balle perdue gratuite :)). Où en est-on aujourd’hui ?

Commençons du côté de la pomme. Le flagship actuel est l’iPhone 16 Pro. iOS est en version 18.2.1. Apple Intelligence est disponible à partir de iOS 18.1 sur l’ensemble des modèles d’iPhone 16, ainsi que le 15 Pro et le 15 Pro Max. En Europe, on doit cependant attendre le mois d’avril pour accéder au système Apple Intelligence.

Sur Android, la dernière version est actuellement la 15 (API 35). Gemini est l’actuel modèle d’IA de Google, et d’autres constructeurs comme Samsung ajoutent aussi leur propre couche d’intelligence (Galaxy IA). Certains smartphones récents ont le droit à Gemini nano pour une exécution locale : c’est à partir du Google Pixel 8 Pro et Samsung S24, et d’autres appareils s’ajoutent progressivement.

Les deux systèmes proposent bien aux utilisateurs des fonctionnalités augmentées par l’IA. Mais côté développement, on est très limité pour créer. iOS ne propose que les App Intents pour faire découvrir nos applications à Siri et Spotlight. Et sur Android, Gemini nano est au stade expérimental. Il y a très peu d’appareils compatibles et les possibilités sont limitées.

À côté de cela, on voit d’autres solutions légères qui émergent pour être exécutées sur un smartphone. On trouve par exemple les ensembles de modèles Gemma de Google, Phi de Microsoft ou encore Llama de Meta. Ces trois familles de modèles sont d’ailleurs open-source. Plus étonnant, on trouve également des outils comme PicoLLM qui permettent de compresser les modèles !

Évidemment, tout ce que je raconte au-dessus changera avec le temps. Il y aura de nouveaux appareils, des nouvelles versions d’OS, des LLMs, etc. Un prochain rendez-vous que l’on peut prévoir : mai et juin pour les keynotes d’Apple et de Google, puis quelques temps après la sortie des nouvelles majeures d’OS.

Comment avoir accès à un modèle ?

Actuellement, pour créer des fonctionnalités augmentées par l’IA dans une application mobile, il faut interagir avec un modèle. On va créer des prompts adaptés à nos cas d’utilisations puis interpréter la réponse. Une réponse que l’on aura forcée dans un standard (du JSON par exemple).

Pour que notre application communique avec un modèle, nous avons plusieurs options.

Via notre serveur et une API tierce

C’est actuellement un des choix les plus répandus et les plus efficaces. Les applications mobiles ont déjà l’habitude de discuter avec des serveurs - on aura simplement de nouvelles routes pour obtenir des inférences. Notre serveur fait la passerelle vers OpenAI par exemple, et ce sont ces derniers qui hébergent le modèle.

Les intérêts sont multiples. On peut cibler tous les appareils (puissant ou entrée de gamme, récent ou vieux) et tous les systèmes (Android, iOS) peu importe la version (la toute dernière comme la plus vieille). Eh oui, il ne s’agit là que de requêtes HTTP et de stream de données.

On s’assure au passage d’avoir le même comportement entre les différents appareils et systèmes, puisque c’est le même modèle qui est utilisé en bout de chaîne. Les règles métiers et prompts sont aussi partagées. On pourra facilement et rapidement les modifier à distance sans mettre à jour les applications mobiles.

D’ailleurs, on peut aussi changer le modèle utilisé par un autre (une nouvelle version ou un concurrent) sans devoir redéployer notre application. Tout comme on pourrait utiliser plusieurs modèles en parallèle.

Le coût sera cependant élevé. La charge principale viendra de l’utilisation d’un service tiers comme OpenAI. Le coût augmentera selon deux vecteurs : le nombre d’utilisateurs et le nombre d’usages. En effet, les API tiers facturent au nombre de token généré pour l’utilisation de leurs LLMs.

C’est d’autant plus important que notre serveur agisse en tant qu’intermédiaire : une communication directe entre les applications et le service tiers impliquerait d’exposer en public nos clés d’APIs. Il serait alors très facile pour une personne d’utiliser nos clés, augmentant ainsi notre facture.

Quelques solutions : OpenAI, Anthropic, Gemini. On peut ajouter Firebase qui est une rare solution à proposer un accès direct (sans serveur) sécurisé à une LLM (Gemini en l’occurrence).

Via notre serveur qui héberge un modèle

Le second choix qui est également très répandu est celui d’héberger soi-même un modèle sur nos serveurs. On garde ainsi les avantages de passer par notre serveur (compatibilités avec tous les appareils, facilité de changement du modèle, utilisation de plusieurs modèles, …) tout en ayant plus de contrôle.

Un des aspects les plus intéressant concerne les données. En hébergeant un modèle open-source, on s’assure un meilleur contrôle sur nos données et la manière dont elles sont utilisées, et surtout par qui.

Le coût sera aussi maîtrisé différemment. Exit un prix au token via une API tierce, cette fois on paie l’hébergement du modèle.

Maintenant, comment choisir entre utiliser une API tierce et héberger un modèle ? Quelques insight possibles pour décider :

• passer par une API tierce pour prototyper rapidement, quand on est une petite entreprise, qu’il n’y a pas de données confidentielles.
• héberger un modèle quand on est une plus grande entreprise, quand on veut mieux contrôler l’usage des données.

Quelques solutions : Mistral qui est open-source et français, se balader sur le marketplace de Hugging Face.

En local avec les solutions natives

Il existe aujourd’hui des modèles plus légers qui peuvent fonctionner sur nos ordinateurs et nos téléphones, et certains appareils les intègrent par défaut. On peut donc les utiliser directement pour faire des inférences « on-device ».

Il y a plusieurs avantages à cette exécution locale. Premièrement, le coût. Il n’y en a tout simplement pas. Pas besoin de payer un service tiers ou d’héberger une solution existante, le modèle est déjà présent sur le téléphone. En fait, c’est l’utilisateur qui porte le coût : c’est la puissance de son smartphone, via sa puce et sa batterie, qui réalisera toutes les opérations. On pensera alors à ménager sa batterie.

Deuxièmement, la confidentialité. Le modèle étant sur l’appareil, les données sensibles n’ont pas besoin de transiter sur internet ou d’être lues par un serveur tiers. C’est une des promesses phares de ces modèles. On restera méfiant tout de même s’il faut utiliser des données très sensibles - l’inférence est peut-être locale, mais des logs et données pourraient très bien remonter à des serveurs.

La rapidité est un potentiel troisième avantage. L’inférence locale s’oppose à une inférence sur un serveur distant qui nécessite des aller-retour sur internet. La communication réseau prenant du temps, on tient là un gain intéressant. Je parlerais d’ailleurs plutôt de meilleure latence de réponse. D’une certaine manière, les serveurs d’OpenAI (par exemple) sont bien plus puissants que les puces de nos smartphones. Ce n’est pas l’inférence qui est plus rapide, mais plutôt le délai pour obtenir les réponses (grâce à des étapes en moins). À condition bien sûr d’avoir un smartphone haut de gamme.

Tient-on alors la solution parfaite ? Aujourd’hui en tout cas, on en est loin. On est très limité en termes de cibles compatibles. Il n’y a rien sur iOS, Apple ne permet pas de prompter avec son Apple Intelligence. C’est réalisable seulement sur Android, et même là, les smartphones disposant d’une solution intégrée (Gemini Nano) sont peu nombreux, récents, et chers. Le pourcentage d’utilisateurs que l’on pourrait atteindre est faible.

C’est également toujours marqué par Google comme expérimental, et selon les smartphones, le modèle n’est pas pleinement intégré par défaut, il faut effectuer quelques actions.

Un point d’attention qu’il faudra garder en tête le jour où les modèles embarqués seront plus répandus : leurs différences. Apple et Google proposeront chacun leurs solutions, et il sera difficile (impossible ?) de reproduire avec certitude les mêmes comportements.

scope.launch {
  // Single string input prompt
  val input = "I want you to act as an English proofreader. I will provide you
    texts, and I would like you to review them for any spelling, grammar, or
    punctuation errors. Once you have finished reviewing the text, provide me
    with any necessary corrections or suggestions for improving the text: These
    arent the droids your looking for."
  val response = generativeModel.generateContent(input)
  print(response.text)

  // Or multiple strings as input
  val response = generativeModel.generateContent(
  content {
    text("I want you to act as an English proofreader. I will provide you texts
      and I would like you to review them for any spelling, grammar, or
      punctuation errors.")
    text("Once you have finished reviewing the text, provide me with any
      necessary corrections or suggestions for improving the text:")
    text("These arent the droids your looking for.")
    }
  )
  print(response.text)
}

En local avec un modèle à intégrer

En attendant qu’une grande majorité des appareils Android et iOS embarquent au sein de leurs systèmes des modèles accessibles aux développeurs, une solution pour avoir une exécution locale serait d’intégrer soi-même un modèle existant dans l’application.

Ainsi, on peut théoriquement cibler bien plus d’appareils et de systèmes / versions ; tant que ceux-ci sont assez puissants. On garderait alors la plupart des avantages d’une inférence locale : la rapidité sur les bons appareils, la confidentialité, et le coût réduit.

Réduit, mais pas inexistant. Le modèle n’étant pas embarqué dans le système de l’appareil, il faut le rendre téléchargeable… et donc l’héberger. On aura un coût de stockage et de bande passante. La bonne nouvelle, c’est que le téléchargement ne doit se faire qu’une seule fois par l’utilisateur au moment où l’application en aura besoin. Chaque usage sera ensuite totalement local et n’aura pas d’impact sur les coûts.

Cette contrainte a un second désavantage : elle requiert un effort pour l’utilisateur. Il devra télécharger un modèle. Même si l’application fait tout le travail, l’utilisateur va devoir patienter - un modèle étant lourd. Il devra aussi réserver de la place sur son appareil pour stocker ce modèle. Modèle qui ne fonctionnera que sur cette application.

Imaginons que plusieurs applications optent pour cette solution, cela représenterait des gigaoctets de téléchargement et de stockage. Ce n’est pas viable.

Quelques solutions : Gemma de Google, Phi de Microsoft, Llama de Meta. PicoLLM pour la compression.

final gemma = FlutterGemmaPlugin.instance;

// Async response
String response = await gemma.getResponse(prompt: 'Tell me something interesting');
print(response);

// Stream response
gemma.getAsyncResponse(prompt: 'Tell me something interesting').listen((String? token) => print(token));

En bref

Les LLMs ne sont plus seulement utilisés à travers des applications de chat où l’utilisateur écrit des prompts. On est dans une phase d’exploration où beaucoup de possibilités restent à être imaginée et testée, mais des premiers usages existent déjà au sein d’applications mobiles.

Et cela va très vite. Les idées fusent, les PoC se multiplient, et les appareils avec des modèles on-device vont se répandre. Les fonctionnalités augmentées par l’IA pourraient devenir un incontournable. Il nous est déjà possible d’en créer, il ne tient qu’à nous d’explorer.

Ça y est, dès le premier paragraphe, le mot est lâché. Les IA vont nous remplacer. C’est en tout cas ce qui est annoncé pour l’année prochaine de manière tonitruante sur LinkedIn et Twitter, c’est donc forcément vrai ! Juste à côté des révélations sur ces pourcentages incroyables de productivité gagné grâce à ces nouveaux outils.

Mais quelle est donc la vérité vraie ? Quel sera le jour exact de notre mise à la retraite ? Qu’allons-nous faire ensuite ? Eh bien je n’en sais rien. Je n’ai pas cette compétence en divination que d’autres semblent avoir acquis.

Pour autant, je trouve qu’il y a des réflexions intéressantes sur notre métier face à l’IA, et j’ai envie de poser mes pensées et de les partager.

Les outils actuels

Avant de s’amuser à parler du futur, regardons ce que l’on a aujourd’hui en termes d’outils pour le développeur. Je ne vais pas faire une liste exhaustive, mais plutôt un rapide tour d’horizon de quelques types d’usages aujourd’hui possible afin d’être aligné - les nouveautés vont vite.

Des chats. Avec ChatGPT comme le plus répandu et Claude comme son concurrent le plus sérieux. Il nous est possible de générer du code à partir d’un énoncé, d’apprendre un concept, de donner du code pour le modifier, de résoudre un problème en collant un morceau de code voire même un lot d’erreur ou une stacktrace. Bref, beaucoup de possibilités pour être assisté.

De la complétion de code. GitHub Copilot a ouvert le bal de l’intégration d’une IA dans les IDE pour générer la suite du code que l’on est en train d’écrire. Tantôt une simple ligne, tantôt tout le contenu d’une fonction.

Des IDEs dopés. Explique-moi ce code, refactor ce morceau, créé cette fonction, intègre ma codebase, … Ce sont quelques exemples de nouveaux usages arrivés avec des IDEs construits autour de l’IA comme Cursor.

Des sandbox. D’abord des usages simples avec ChatGPT Canvas et Claude Artifacts pour prompter sur un fichier qui se modifie au fur et à mesure, on voit maintenant des solutions comme Bolt.new qui vont générer et assembler du code puis le déployer.

Des agents. Ici, on est encore plus dans l’expérimental avec de multiples tentatives d’avoirs des agents IA qui réalisent des tâches. Puis il y a Claude qui propose depuis peu de contrôler un PC à distance pour automatiser des tâches via des prompts grâce à sa fonctionnalité Computer Use.

Des intégrations à d’autres systèmes. Les données sont très importantes pour obtenir des réponses plus pertinentes. Très récemment, Claude MCP a été dévoilé : c’est un protocole pour connecter l’IA à des services externes (notre Filesystem, Google Drive, Slack, …) et agir dessus !

Notre métier va changer

Je suis convaincu que notre métier de développeur va évoluer. Deux choses me font penser cela.

Il y a un changement extérieur - l’arrivée de l’IA. Elle apporte des nouveaux outils, de nouvelles pratiques, de nouvelles façons de faire. Il y a et aura donc des impacts. On va s’y adapter, et on va donc évoluer.

Quand on regarde le passé, c’est au final ce qu’il se passe depuis que notre métier existe - il n’a cessé d’évoluer. Entre les cartes perforées et nos postes de travail actuel, il s’en est passé des choses ! Assembleur, langages bas niveau, modernes, éditeurs de texte, IDEs, linters, frameworks, gestionnaires de version, extreme programming, etc.

C’est d’ailleurs un des aspects que j’aime dans ce métier, il évolue en permanence et on a continuellement à apprendre.

Si on est plutôt confiant sur le fait que ça va bouger, la question suivante est vers quoi va-t-on se diriger ?

Plusieurs étapes de changement

On ne passera pas d’un coup de « les devs codent » à « les IA sont magiques, construisent un produit complexe entièrement et dominent le monde ». Non, il y aura au moins plusieurs étapes avant d’y arriver (si on y arrive).

Je verrais bien quelque chose de ce genre :

• Les humains codent,
• Les humains codent et sont assistés par des IA,
• Les IA sont assistés par des humains,
• Les IA sont autonomes.

Et il y aura plusieurs sous-étapes dans « Les IA sont autonomes ». On n’arrivera pas du jour au lendemain avec des IA et des robots qui fabriquent des choses avant même que nous humains ayons conscience d’avoir besoin de quelque chose.

Je dirais qu’aujourd’hui on est dans « Les humains codent et sont assistés par des IA ». J’aime bien le nom que Microsoft a donné à GitHub Copilot d’ailleurs, ça représente bien cette étape.

J’explicite un peu avant de passer à la suite. J’ai en tête la création de produits complexes. Oui, aujourd’hui, on peut déjà créer des landing page ou des todo list basiques à l’aide de quelques prompts seulement, sans (trop) toucher au code. Mais on est loin de pouvoir faire créer le site de la Fnac, le système d’exploitation de nos smartphones, les systèmes bancaires, etc.

L’adoption est pour l’instant faible ?

Je me questionne sur le taux d’adoption auprès des développeurs. Si on met de côté le bruit créé par les influenceurs - forcément davantage en lumière que la masse - et qu’on regarde aussi de plus près la fréquence et les cas d’utilisation, j’ai l’impression que les développeurs adoptent lentement ces nouveaux outils.

J’imagine une pyramide, où plus on considère une utilisation régulière et avancée, moins il y a d’utilisateurs :

• Ceux qui connaissent,
• Ceux qui ont utilisé une fois ou deux,
• Ceux qui utilisent quelques fois chaque mois,
• Ceux qui utilisent quelques fois chaque jour,
• Ceux qui utilisent en permanence de multiples IA pour tout un tas d’usages.

C’est très subjectif par rapport à ce que je peux observer bien sûr, je n’ai aucune statistique. Mais je dirais que peu de développeurs ont un usage fort de l’IA. On est plutôt dans une phase Early Adopters. Beaucoup ont donc encore à s’équiper, apprendre, expérimenter.

Et ce n’est pas tout. Jusque-là, on parlait de l’IA à travers un prisme consommateur, mais il y a d’autres angles à considérer dans l’écosystème de l’IA avec également de moins en moins de personnes :

• Ceux qui consomment l'IA (clients),
• Ceux qui créent des fonctionnalités et des outils augmentés par de l'IA (développeurs),
• Ceux qui personnalisent une IA existante avec du fine-tuning, LoRA, RAG... (data/développeurs),
• Ceux qui créent l'IA (chercheurs).

La qualité du code sera moins importante

Les IA font aussi grincer quelques dents. « La qualité du code est nulle. Il y a des hallucinations. On va finir par ne rien comprendre. ». Il y a du vrai là-dedans. Ce n’est juste pas autant noir ou blanc comme certains laissent penser. Il faut nuancer, et ajouter une temporalité.

Je pense qu’il y a une partie d’ego qui est touchée. C’est nouveau, ça dérange, ça change, ça fait peur. Il y a de la résistance, les problèmes sont principalement mis en avant.

Mais ces problèmes existent bel et bien. Aujourd’hui, les IA génèrent des choses utiles tout comme elles vont écrire de belles conneries. Du code bien écrit, qui fonctionne mais illisible, qui ne compile même pas, qui provoque des bugs. On a un peu de tout.

Et il faut interagir avec ce code généré. On doit (un minimum) le comprendre, l’intégrer aux bons endroits dans une plus grande base de code existante. On devra le retoucher, le brancher avec d’autres composants. Il vit rarement tout seul dans son coin.

Même si on est un enthousiaste de l’IA, il ne faut pas se mettre des œillères et continuer à réfléchir. La qualité a son importance. Aujourd’hui.

Elle a son importance car on a encore besoin de lire le code, le comprendre, le manipuler. Une bonne qualité nous permet de faciliter le changement. On a besoin de faire évoluer et de maintenir notre base de code et nos fonctionnalités. Mais demain ?

S’il suffit d’écrire un prompt, ou modifier un fichier de « spécifications-prompt » pour effectuer un changement, et que l’IA est la seule à interagir avec le code, à quel point a-t-on besoin d’une grande qualité de code ?

D’un côté, le changement est facile, il suffit d’écrire des prompts. De l’autre côté, on ne met plus les mains dedans. De multiples fichiers et composants seront probablement régénérés à chaque fois par l’IA elle-même, qui n’aura pas les mêmes problématiques de compréhension de code que nous.

Un langage de programmation d’encore plus haut niveau ?

J’hypothèse qu’à un moment, la manière de communiquer avec les modèles d’IA deviendra notre nouveau langage de programmation. Quelque chose de très haut niveau, qui a de moins en moins d’aspect technique.

On peut l’observer si on regarde dans le passé. On a aujourd’hui de multiples langages de haut niveau, qui embarquent davantage de possibilités (faire des fonctions, des classes versus faire des sauts) et qui permettent de cacher / moins se soucier de certaines problématiques techniques (gérer des registres, avoir des pointeurs).

Code machine, assembleur, C, Java, Kotlin. Le prompt (peu importe sa forme et son nom) serait-il un prochain nouveau langage encore plus haut niveau ?

Il faudrait connaître sa syntaxe - facile, c’est du français, anglais, etc - et on y ajouterait quelques concepts techniques. Qui seront d’ailleurs probablement de plus en plus abstrait.

Peut-être qu’au début il faudra guider davantage, avoir les concepts et certains mots-clés assez précis « Enregistres tous les appels réseaux entrant, les erreurs HTTP, les temps de réponse. Branches sur Datadog. Je veux un Dashboard. » Puis un jour simplement « Ajoutes du monitoring, je veux un Dashboard ».

Le futur est difficilement prévisible

Je vais finir sur ce que l’on ne peut pas finir, la suite. Le futur est difficilement prévisible. Je ne suis pas devin, et personne ne l’est. Ce ne sont ici que mes réflexions à voix haute.

Ça avance tellement vite que ça pourrait arriver demain. Les IA pourraient aussi être très différentes pour que toutes nos projections soient fausses. Ou il pourrait soudainement y avoir un énorme mur. Une grosse limitation technique très dure à franchir. Une énorme régulation mondiale. Ou une grande guerre, dans un monde avec encore moins de ressources et plus de problèmes.