Les LLM sont capables de faire tout et n’importe quoi, les nouveautés arrivent trop vite en promettant de tout changer l’existant.

La puissance requise pour utiliser ces jouets du futur est plus que problématique, autant essayer de ne pas faire n’importe quoi.

Client

Un LLM seul n’est pas utilisable, il faut passer par un agent.

La conversation est le moyen le plus courant de l’utiliser ; d’où le terme d’agent conversationnel.

L’utilisateur discute avec l’agent qui va répondre et agir.

Web

L’interface la plus simple est le chat, sur une page web. Il suffit de créer un compte gratuit pour commencer à discuter.

Application

Les agents sont plus que des robots aux connaissances encyclopédiques. Si vous vous contentez de l’utiliser comme un moteur de recherche luxueux, ou pour faire vos devoirs, il vous manque l’essentiel.

Un agent peut agir, consulter des pages web, lancer des commandes, utiliser des services tiers (MCP).

Quel agent ?

Chaque fournisseur de modèle propose un agent.

Je trouve plus sage d’utiliser un agent neutre qui se connectera à ce qu’il veut.

Il existe pléthore d’agents, plus ou moins éphémères, et il existe des outils pour gérer une flotte d’agents.

Opencode

Opencode est un choix sage. Il a le bon goût d’être utilisable en ligne de commande, ou depuis un éditeur (VSCode, Zed…) grâce à ACP. Il fonctionne en client/serveur et permet donc d’avoir plusieurs clients sur un même serveur (et partager une session par exemple). Le serveur peut être distant (un serveur, une VM locale…), et le client local. Il dispose d’un client pour le terminal, et d’un client web.

Des applications tierces proposent des interfaces avancées, comme OpenChamber, qui fonctionne sur Linux/Mac/Windows/iOS/Android/Browser+PWA et comme extension pour VSCode.

Quel que soit le client utilisé, le serveur est unique, c’est lui qui centralise la configuration (plugins, mcp, fournisseurs, skills, sessions…). Il est possible d’avoir un serveur configuré aux petits oignons, et de tester différents clients sans se soucier de la configuration du client.

Utilisations

Voici une sélection de types d’utilisations que j’ai avec des agents. Sélection partielle et partiale.

Assistance à l’écriture de textes non techniques (romans, courriers formels…)

Par principe, je refuse qu’un agent touche à mes textes.

Même sans écrire quoi que ce soit, il peut apporter une aide précieuse. Il faut créer un agent spécifique et lui interdire toute flagornerie ; quand il critique impitoyablement, il doit proposer des améliorations.

Il est d’une patience infinie, et il encaissera sans broncher autant de relectures que nécessaire, et commentera les évolutions (ce qui est mieux, ce qui ne s’est pas amélioré).

Les petits modèles utilisables localement (comme Gemma4:4B) sont étonnamment efficaces pour relire, commenter, proposer des améliorations sur des textes en français. Textes qui resteront privés.

Relecture

Il gère bien les fautes de frappe, les accords, les conjugaisons et autres joyeusetés de la langue française. Pour limiter le bruit, il faut commencer par faire une passe avec le modèle interne du Mac (relecture/proofread).

Analyse

• Validation du ton en fonction des lecteurs ciblés (familier, administratif, rigueur technique…)
• Analyse de la forme (article technique, lettre de motivation, cours…)
• Sur un roman, il peut repérer des personnages sous-utilisés, des incohérences, les parties manquantes d’un texte en cours d’écriture.
• J’ai peur de lui confier un Agatha Christie ou un Sherlock Holmes en supprimant la fin et de lui demander qui est le tueur. Enfin, il les a probablement déjà lus.

Code

Lecture

• Aide à la compréhension d’un logiciel (ou d’une bibliothèque). Description de son architecture, des choix techniques et des implémentations. En lui fournissant la documentation, les réponses seront plus précises et sourcées. Il peut utiliser le git log et les tickets (ouverts ou fermés) qui contiennent beaucoup d’informations sur les choix techniques et les discussions.
• Comparaison entre deux logiciels concurrents.
• Questions/réponses pour valider que l’on a bien compris, création de POC pour manipuler un point spécifique de l’application.

Corrections

Là, on franchit un palier, l’agent va écrire, et ce sera commité.

• Améliorer la couverture des tests unitaires, et surtout fonctionnels.
• Corriger en suivant les recommandations des outils d’analyse statique.
• Il est tout à fait capable d’analyser le code et de le corriger. Tout ce qui peut ressembler à une fuite de mémoire, par exemple. Valider que les noms de variables et de fonctions sont cohérents avec ce qu’ils font.

Création de tickets et de PR sur des projets tiers

Quand on tombe sur un bug dans un logiciel libre, l’agent pourra corriger (a minima, on vérifie la taille du patch), puis créer un ticket très formel qui suivra les recommandations du projet.

Par politesse, il faut demander (dans une skill) à l’agent de se contenter de décrire une piste pour la correction et proposer de créer une PR (même si elle est déjà prête).

L’agent pourra répondre aux questions dans le ticket. Attention à bien relire au fur et à mesure, parce que les conneries de l’agent seront faites en votre nom, en public, sur un projet qui a potentiellement une grosse visibilité.

Il est aussi possible de couper la poire en deux en corrigeant à la main et en laissant l’agent s’occuper des salamalecs de la PR.

Discussion préparatoire

L’agent peut débroussailler un nouveau projet (ou une nouvelle fonctionnalité importante) :

• Quelles sont les approches techniques ?
• Je veux faire ça, et je pense m’y prendre comme ça.
• Il peut proposer un POC

J’aime bien utiliser Claude avec l’abonnement gratuit pour ça. Il argumente, explique bien et source ses réponses.

Cette approche permet rapidement de savoir si son idée est naze, si elle est simplement mal définie, si elle est techniquement bancale. On n’est pas obligé de se contenter d’une réponse standardisée et sans âme, on peut lui préciser des contraintes (un langage précis, une machine exotique ou grand public, un persona d’utilisateur, un packaging rigoureux…).

On se garde la possibilité, pour la suite, de partir sur du cousu main, de l’industrialisation dystopique, ou quelque chose entre les deux.

Développement orienté spécifications

Laisser un agent tout coder est un tabou. Mais c’est aussi un outil d’une puissance difficilement imaginable.

Discussion

Tout commence par une discussion qui décrit le projet et demande à l’agent un retour critique sur l’idée, l’approche, tout. Il est possible de lui demander de créer un POC, pour vérifier si un point particulier est faisable/pertinent.

Spécifications

L’agent écrit les spécifications (le fichier SPECS.md). Il va poser des questions, demander des précisions. Il ne faut pas hésiter à préciser que certains points seront vus plus tard. On relit et itère autant de fois que nécessaire.

Un deuxième agent (avec un modèle différent pour éviter toute collusion) va critiquer (vigoureusement) le travail du premier ; il va essentiellement trouver des trous dans la raquette, mais aussi remettre en question des choix. C’est à un humain de trancher, et souvent de prendre en compte les deux avis. Il ne faut pas se rater, car l’âme du projet se trouve dans ces specs, tout le reste n’est que vulgaires implémentations.

Les spécifications sont découpées en lots. Ce qui est fun, c’est que l’agent va estimer le temps nécessaire en jour/homme, alors qu’il fera ça en quelques dizaines de minutes.

Exécution

Dans une nouvelle session, qui n’a donc que le SPECS.md comme contexte, l’agent va travailler sur le premier lot. Il faut lui demander de faire des commits bien bordés, et de travailler avec des pull requests, histoire de bien isoler les éléments du lot.

De manière pragmatique, si ça ne va pas, il sera possible de bazarder une pull request. Promis, il ne fera pas la gueule. S’il galère, il est possible de changer de modèle.

Par principe, c’est un humain qui valide la PR, mais dans la vraie vie, l’humain abandonne vite cette responsabilité et se contente d’un «oui, oui, on m’attend à la piscine ». Le terme consacré est «le petit théâtre de la validation de PR”. Techniquement, l’agent peut paralléliser son travail avec des « worktree », mais concrètement, il aura, comme tout le monde, à gérer des histoires de merge et de rebase (qu’il gère bien, globalement). Le piège est de valider plusieurs PR à la suite. Quand une PR est mergée, la PR suivante doit commencer par faire un rebase sur le main tout frais pondu par la PR précédente.

Avant chaque validation de la PR, on recette en l’utilisant l’application. On peut réclamer à ce moment-là des tests fonctionnels reprenant ce que l’on vient de faire à la main.

Itération

Un nouveau lot ou des corrections peuvent modifier le SPECS.md, qui est une description abstraite du projet. En théorie, on devrait pouvoir réécrire l’application, d’un coup, à partir du SPECS.md, voire même dans un autre langage.

Par principe, à la fin de chaque lot, on peut demander une relecture du travail fait (dans une session à part) par un modèle cher. On peut aussi lui demander d’écrire un fichier avec ses remarques pour que le modèle courant corrige.

Quand tous les lots décrits dans le SPECS.md sont terminés, on va pouvoir itérer pour les versions suivantes. L’agent va culpabiliser à l’idée d’amender le SPECS.md, c’est mignon, mais on va rester agiles et avancer.

Je trouve plus simple de créer une liste de tâches, non commitées, un document markdown avec quelques chapitres et surtout des listes de bugs, de nouvelles fonctionnalités et de changements. On perd rapidement le fil lors d’une discussion, autant commencer par lui confier ses notes. On demande ensuite, dans une discussion, à l’agent, d’ordonner et de découper ce bazar en lots cohérents. Il posera toutes les questions sur des points confus ou non cohérents. Hop, on passe d’une liste écrite sur un dos d’enveloppe, technique inavouable, à des spécifications formelles et rigoureuses.

##### Attention /!\

L’agent peut être trop enthousiaste et essayer de m’embrouiller avec une tempête de buzzwords ou des propositions incompréhensibles. Il ne faut JAMAIS se contenter de répondre dans ces QCM au premier de la liste, celui qui est « recommandé ». Il faut rester le patron, sinon l’agent va s’approprier le projet, qui va devenir un machin.

Cette maîtrise de l’architecture, de la description du besoin, des décisions à prendre au fur et à mesure de l’avancement est primordiale. C’est ce qui exclut les juniors (qui faisaient le travail que font maintenant les agents) et valorise les seniors (qui trouvent enfin du temps pour coder malgré les équipes à gérer).

Il ne faut pas non plus hésiter à lui fournir un bout de code décrivant un algorithme qu’il va critiquer puis implémenter. Il n’y a aucun problème à décrire l’algo dans un langage, et l’agent l’écrira dans un autre.

Le travail en équipe (d’humains) avec ce genre d’approche est compliqué, a priori ; 2 est la bonne taille.

Protection

Le constat est que cette approche donne des résultats impressionnants, mais les bugs qui passent entre les gouttes sont particulièrement vicieux.

Pour garder la maîtrise de tout ça, il faut encadrer l’ensemble avec une rigueur de paranoïaque exigeant. Couverture de tests (unitaires et fonctionnels) maximale, même attention pour la production (métriques, logs, traces…) et des rapports de bug à la Sentry.

L’agent doit être bordé (le terme technique est harness) : * des recommandations (sous forme de skills ou de AGENTS.md) * utilisation de KB locales plutôt que des pages random sur Internet ; * sandboxing ; * utilisation de MCP pour qu’il n’accède pas directement à des données potentiellement malignes (tout Internet en fait, il ne doit voir que la version markdown des pages qu’il lit) * protection des secrets et des actions dangereuses qu’il pourrait effectuer sur sa machine hôte.

Prolongation

Comme l’agent a des specs précises, il peut travailler sur des tâches longues. C’est un piège : ces tâches sont trop longues pour qu’un humain attende sans s’ennuyer. Il va donc vouloir faire autre chose et perdre le contexte. L’agent prendra un malin plaisir à s’interrompre pour poser une question. Une des tactiques est de lancer plusieurs agents et d’effectuer des tâches en parallèle (entre 5 et 10), et donc se cramer le cerveau en essayant de garder les contextes dans son petit cerveau, puis de répondre intelligemment aux questions.

Les agents modernes font des bruits quand ils ont fini ou posent une question. Il existe des outils qui regroupent les états de tous les agents qui tournent sur la machine et proposent une interface simple pour répondre aux questions.

Une autre approche est d’utiliser plusieurs «clients » pour une même session, et donc un pour le laptop, un autre sur un appareil mobile (et aller faire la vaisselle).

Modèles

Les modèles ont un coût (qui peut être énorme), mais aussi une personnalité, une attitude et des spécialités. Il faut les panacher. Pour qu’ils se challengent, et surtout utiliser le meilleur compromis efficacité/coût.

• Grok a un ton un poil trop familier, cause plutôt bien français, et critique comme un bourrin impitoyable.
• DeepSeek galère en français, mais il est positif sans être un gros niais enthousiaste. C’est une infâme pipelette, limite diarrhée verbale.
• Mimo est celui qui parle le mieux français et globalement positif.
• Kimi est un poil rigoriste, mais toujours constructif.
• Claude Sonnet est le top de ceux que j’ai utilisés, français nickel, et une impression hypnotique d’intelligence. Il tente régulièrement de t’embrouiller avec des réponses trop techniques. Il a un aplomb inébranlable et je le prends en faute de temps en temps. C’est l’interlocuteur le plus agréable.
• Mixtral est un gros teubé laborieux.
• Gemma4 est court des pattes, mais il est bluffant pour sa taille (j’ai testé en 4B). Il est tout à fait compétent pour relire du texte.

Vers l’infini et au-delà

Pour l’instant, les fournisseurs de modèles cassent les prix, les entreprises crament du token comme signe de puissance, une partie des nouveaux usages secoue violemment toute l’industrie informatique (entre autres). Pas grand monde ne se soucie des problèmes de sécurité («injection de prompt » essentiellement), ni de toutes ces données qui partent aux USA ou en Chine. C’est dangereux de se laisser distancer, de ne pas participer à la course.

Pour l’instant, la course pour devenir leader hégémonique permet tous les excès. Mais tous ces centres de données promis ne seront pas tous terminés. Ils devront rendre des comptes sur leurs nuisances, leur consommation en électricité (renouvelable, gaz, charbon, diesel), en eau et en foncier, en terres rares et autres joyeusetés.

Ce surinvestissement est une bulle, et à un moment, la facture va tomber. Le coût des LLM ne sera clairement plus le même. Quels usages vont perdurer ?