Before Skynet Took Over

Il y a quelques jours, je suis tombé sur le billet d’une chercheuse qui revenait sur l’évolution de sa manière de travailler depuis l’arrivée des grands modèles de langage. Je me suis assez vite reconnu dans une partie de son récit. Pas complètement : je ne suis pas chercheur à plein temps, je suis d’abord médecin, et la recherche doit se glisser dans le temps qu’il reste autour. Mais en repensant aux dernières années, je me suis rendu compte à quel point ma façon d’utiliser ces outils avait changé.

Mon premier contact avec tout cela remonte à bien avant ChatGPT. Je passais déjà du temps dans l’ancien Playground d’OpenAI, avec davinci et les autres modèles de complétion de l’époque. Le fonctionnement était beaucoup plus apparent qu’aujourd’hui : on écrivait un début de texte, le modèle le poursuivait, et l’on pouvait directement jouer avec la température, top_p et les différents paramètres d’échantillonnage.

J’ai passé pas mal de temps à faire exactement cela. Relancer le même prompt avec plusieurs températures, changer quelques mots, comparer les sorties, regarder à quel moment le modèle devenait plus créatif, plus répétitif ou partait complètement dans le décor. Je voulais surtout comprendre ce qu’il y avait derrière cette impression assez étrange d’avoir une machine capable d’écrire quelque chose de cohérent à partir de presque rien.

Ces paramètres sont beaucoup moins accessibles dans les applications grand public actuelles. On peut évidemment toujours les manipuler lorsqu’on utilise les modèles par API ou directement dans du code, mais, pour un usage général, je trouve que cela a perdu une bonne partie de son intérêt. Ils restent utiles lorsque l’on construit quelque chose de précis — un chatbot métier, un RAG documentaire, un assistant vocal ou n’importe quel système dont on souhaite contrôler plus finement le comportement — mais je ne passe plus mes soirées à chercher la température parfaite pour parler à un modèle. Il y a désormais beaucoup plus intéressant à regarder.

À l’époque de davinci, il fallait par ailleurs se méfier de tout. Les premiers modèles pouvaient produire une réponse parfaitement vraisemblable, très bien écrite, et complètement fausse. Dans mes domaines, c’était vite problématique : publications inventées, interprétations biologiques approximatives, fonctions Python imaginaires présentées avec une assurance remarquable. Le côté fascinant de l’outil était donc rapidement tempéré par une règle simple : tout vérifier.

Ce problème n’a pas disparu. Les modèles hallucinent toujours et ils peuvent encore produire des erreurs assez étonnantes. Mais prétendre qu’ils ne se sont pas énormément améliorés serait tout aussi faux. Les hallucinations sont devenues beaucoup moins fréquentes, les instructions complexes sont mieux suivies, les contextes manipulés sont sans commune mesure avec ceux d’il y a quelques années, et surtout les tâches qu’on peut leur confier ont complètement changé de nature.

L’explosion cambrienne

Lorsque ChatGPT est arrivé, je l’ai évidemment beaucoup utilisé, mais je ne suis jamais vraiment resté fidèle à une seule famille de modèles. J’ai testé les différentes générations d’OpenAI, pratiquement toutes les versions de Claude, Sonnet comme Opus, les Gemini successifs, et pas mal de modèles ouverts au passage.

Pendant longtemps, j’ai même pris l’habitude de soumettre exactement le même problème à plusieurs modèles, parfois simplement par curiosité. C’est probablement la meilleure manière de se débarrasser de l’idée qu’il existe « le meilleur modèle ».

À un moment donné, l’un pouvait être très au-dessus pour le code, un autre beaucoup plus agréable pour travailler sur un long document, un autre encore meilleur pour discuter d’une hypothèse scientifique ou repérer les faiblesses d’un raisonnement. Puis une nouvelle version sortait trois mois plus tard et rebattait complètement les cartes.

Je continue d’ailleurs à faire cela aujourd’hui. Quand un résultat est important, confronter plusieurs modèles reste souvent instructif. Ils ne se trompent pas nécessairement de la même façon. Et lorsqu’ils arrivent à des conclusions différentes, cela donne au moins une bonne raison d’aller vérifier soi-même ce qui se passe.

Avec le temps, mon intérêt s’est donc déplacé. Je regarde toujours les nouveaux modèles — je serais bien incapable de ne pas le faire — mais leur intelligence brute m’intéresse moins qu’avant. Ce qui commence à devenir vraiment déterminant, c’est ce qu’on construit autour d’eux : leur contexte, leurs outils, leur mémoire, les données auxquelles ils ont accès et la manière dont on organise leur travail.

Sortir un peu du cloud

Cette question avait pris une forme très concrète lors du workshop que nous avions organisé avec BioInfoDiag aux Assises de Génétique, en janvier 2026.

L’idée était notamment de montrer ce qu’il était possible de faire avec des modèles exécutés localement. En santé, la question est évidemment intéressante. Il ne s’agit plus simplement de savoir si GPT, Claude ou Gemini gagne quelques points supplémentaires sur un benchmark. Pouvoir conserver les données dans une infrastructure que l’on contrôle, maîtriser la chaîne technique et éventuellement spécialiser un système pour un besoin particulier présente des avantages assez évidents.

Les modèles ouverts que nous avions utilisés avaient déjà montré un potentiel très correct. Mais l’expérience rappelait aussi quelque chose qui disparaît souvent derrière le terme un peu magique de « modèle local » : il faut bien le faire tourner quelque part.

Cela demande des GPU, de la mémoire, une infrastructure capable d’absorber plusieurs utilisateurs, du déploiement, de la maintenance, de la sécurité, et surtout des personnes ayant les compétences nécessaires pour faire fonctionner tout cela. Installer les poids du modèle n’est que le début. À partir de là, on commence justement à comprendre que le modèle n’est qu’une pièce de l’ensemble.

Ce qu’il y a autour du modèle

C’est probablement pour cette raison que je m’intéresse de plus en plus aux agent harnesses. Je n’ai toujours pas trouvé de traduction française que je trouve satisfaisante. On peut les voir comme toute l’infrastructure qui entoure un modèle et lui permet de réellement travailler : la boucle agentique, les outils, le terminal, les fichiers, la mémoire, les permissions, les sous-agents, la gestion du contexte, les mécanismes de vérification, la reprise d’une tâche après un échec, etc.

C’est devenu particulièrement visible avec Codex, que j’utilise maintenant pratiquement tous les jours pour développer.

La différence avec les anciens assistants de programmation est assez radicale. Je ne lui demande plus simplement de m’écrire une fonction que je vais ensuite copier dans mon éditeur. Je peux lui confier un dépôt Git, lui demander de comprendre son organisation, de modifier plusieurs fichiers, de lancer les tests, d’observer ce qui casse, de revenir sur son implémentation et de continuer jusqu’à obtenir quelque chose de cohérent.

Évidemment, je supervise toujours le résultat. Mais on est très loin de l’époque où le workflow consistait à copier une traceback Python dans un chatbot, récupérer trois lignes de code, les remettre dans le terminal, constater que cela ne fonctionnait pas davantage, puis revenir copier la nouvelle erreur.

Codex illustre assez bien à quel point le harness compte lorsque le modèle a lui-même été entraîné à travailler dans ce type d’environnement. Le renforcement sur des tâches où il doit réellement modifier du code, utiliser des outils, exécuter quelque chose puis réagir au résultat donne un comportement très différent d’un modèle simplement posé derrière une fenêtre de chat.

J’utilise également Hermes, de Nous Research, plusieurs fois par semaine pour des tâches plus générales. Je l’aime justement pour une autre raison : mémoire persistante, outils, compétences réutilisables, tâches programmées, possibilité de changer de fournisseur de modèle ou d’utiliser du local. Ce n’est pas exactement le même usage que Codex et c’est aussi ce qui le rend intéressant.

Et puis il y a le nouveau harness de DeepSeek. Celui-là, je ne l’ai pas encore testé, donc je vais éviter d’en faire la critique depuis mon canapé. Mais son architecture me paraît particulièrement prometteuse.

L’idée de rendre presque chaque composant interchangeable — modèle, mémoire, outils, sandbox, session, boucle agentique, planification — me semble aller dans une direction assez logique. Les trajectoires peuvent également être enregistrées, reprises, bifurquées ou rejouées. Si cette approche tient ses promesses, elle pourrait surtout changer la manière dont on conçoit ces systèmes : plutôt que de considérer l’agent comme un bloc plus ou moins fermé, le harness devient lui-même quelque chose que l’on peut composer, modifier et expérimenter.

Je trouve cela potentiellement beaucoup plus intéressant qu’une nouvelle interface de chatbot.

Pendant plusieurs années, toute l’attention était portée sur le prochain modèle. Combien de paramètres ? Quelle taille de contexte ? Combien de points gagnés sur tel benchmark ? Je ne pense pas que ces questions soient devenues inutiles, mais elles commencent à ne raconter qu’une partie de l’histoire.

Un excellent modèle dans un mauvais environnement peut être assez médiocre. À l’inverse, un modèle un peu moins performant, mais entraîné à utiliser correctement ses outils et intégré dans un bon harness, peut devenir bien plus utile.

Et pour la recherche ?

Tout cela ne signifie évidemment pas que je dirige maintenant un laboratoire automatisé avec une armée d’agents qui travaille pendant que je bois mon café. Pas encore, en tout cas.

Je reste médecin, et cela impose une contrainte assez simple : le temps. Je n’ai pas celui d’un doctorant à plein temps ou d’un chercheur qui peut consacrer plusieurs journées successives à explorer une hypothèse, apprendre un nouvel outil ou refaire un pipeline jusqu’à ce qu’il fonctionne.

C’est précisément là que ces systèmes ont changé beaucoup de choses pour moi.

Une idée pouvait auparavant rester au stade de l’idée simplement parce qu’il fallait plusieurs soirées avant de savoir si elle avait réellement un intérêt. Récupérer les données, comprendre leur structure, écrire quelques scripts, découvrir que le format n’était pas celui attendu, corriger le pipeline, lire la littérature nécessaire, recommencer.

Une bonne partie de ce coût initial a aujourd’hui diminué.

Cela ne signifie évidemment pas qu’une étude scientifique puisse être réalisée en quelques prompts. Les données restent mauvaises quand elles sont mauvaises. Les biais restent des biais. Une cohorte mal construite ne devient pas correcte parce qu’un agent l’a analysée très vite.

Mais ces outils me permettent plus souvent d’arriver rapidement jusqu’au point où commence la question intéressante : est-ce que cette idée mérite réellement d’être poursuivie ?

Et contrairement à ce que l’on pourrait penser, cela ne me fait absolument pas regretter d’avoir appris à programmer et à faire de la bioinformatique.

Un agent peut maintenant produire en quelques minutes du code que j’aurais mis des heures, voire plusieurs jours, à écrire. Mais encore faut-il être capable de voir qu’il a fusionné les mauvaises tables, utilisé la mauvaise unité statistique, introduit une fuite entre deux groupes ou simplement répondu de manière impeccable à une question qui n’avait aucun sens.

Le code peut fonctionner parfaitement et l’analyse être fausse.

Au fond, c’est peut-être ce qui a le plus changé dans ma manière d’aborder ces outils.

Il y a quelques années, je passais beaucoup de temps à essayer de comprendre le modèle lui-même : sa température, son échantillonnage, ses hallucinations, les limites de son contexte.

Aujourd’hui, je continue évidemment à tester les nouveaux modèles, mais je regarde de plus en plus ce qu’il y a autour.

Dans quel environnement faut-il placer le modèle ? Quels outils faut-il lui donner ? Comment vérifier son travail ? Et surtout : quelle partie du problème vaut réellement la peine de lui être confiée ?

Je trouve finalement ces questions beaucoup plus intéressantes que de savoir qui a gagné trois points sur le benchmark de la semaine.