IA : état des lieux d'une petite entreprise

La valeur de l'IA ne repose plus seulement sur la performance d'un modèle, mais sur notre capacité à l'exploiter, à l'orchestrer et à en garder la maîtrise. C'est la conviction qui traverse cet état des lieux.

L'écosystème de l'IA évolue plus vite qu'on ne peut le suivre. Entre les nouveaux modèles, les environnements agentiques, les benchmarks et les annonces, il devient difficile de distinguer les véritables avancées des simples évolutions de produit.

Cet article n'est ni un classement ni une vérité définitive. C'est un regard de terrain, construit à partir de ma veille et de mes usages quotidiens.

Je l'ai organisé en quatre temps, du modèle vers l'infrastructure qui l'entoure :

• Les modèles : arrêter de tout miser sur la taille, apprendre à les combiner.
• Le harness : ce qui fait réellement travailler un modèle, et la sandbox où il agit.
• Le contexte : ne pas faire reconstruire à l'agent ce que l'infrastructure sait déjà, de la recherche dans le code jusqu'à Git.
• La maîtrise : mesurer en continu, contrôler les flux.

Partie 1 — Les modèles : la taille ne fait pas tout

Faut-il vraiment toujours repartir de zéro ?

Je commence par un petit coup de gueule.

Des acteurs comme Mistral sont parfaitement légitimes dans cette course. L'Europe doit développer ses compétences et proposer des alternatives aux acteurs américains et chinois.

Mais je m'interroge de plus en plus sur cette volonté de construire systématiquement des modèles from scratch. Nous mobilisons des ressources considérables pour reconstruire des produits dont les architectures et les capacités ont déjà été largement explorées.

Un exemple : Mistral Large 4, c'est environ 1 000 milliards de paramètres, dont une cinquantaine de milliards actifs. En face, GLM-5.3, avec environ 753 milliards de paramètres dont 40 milliards actifs, obtient un meilleur score sur l'Intelligence Index d'Artificial Analysis (comparaison consultée en novembre 2026). Les deux modèles diffèrent sensiblement en vitesse et en coût, à l'avantage de Mistral sur ces deux points, mais le constat tient : augmenter la taille d'un modèle ne garantit pas de meilleures performances.

Le prix au token trompe tout autant. Lors d'une discussion animée par Simon Willison à l'AI Engineer World's Fair 2026, Thariq Shihipar, aux côtés de Cat Wu, souligne qu'un modèle plus grand peut, sur un problème difficile, consommer moins de tokens qu'un modèle plus petit. Le modèle le moins cher au token n'est donc pas forcément le moins cher pour accomplir une tâche. À l'inverse, un petit modèle spécialisé, doté du bon contexte et des bons outils, peut devenir très compétitif sur un besoin ciblé.

L'enjeu n'est donc pas seulement de réduire la taille des modèles, mais de réduire le travail inutile qu'on leur demande.

Je pense que Mistral devrait suivre la course comme le font les laboratoires chinois. Pourquoi tout reconstruire quand on peut capitaliser sur les capacités développées ailleurs, et concentrer l'effort sur la spécialisation, l'optimisation et l'exploitation ? C'est aussi comme cela, à mes yeux, que nous pouvons gagner cette bataille.

L'objection idéologique pèse moins qu'on ne le dit. Nous Research vient de publier Arete-27B, un ré-entraînement de Qwen3.8-27B d'Alibaba : d'après ses propres mesures, la part de réponses qui reprennent la ligne officielle de Pékin y tombe de 22 % à 0,9 %, avec des capacités quasi inchangées sur ses tests. On peut donc partir d'un modèle chinois et en réduire fortement la propagande : ce n'est pas sur ce terrain que Mistral peut se démarquer.

Orchestrer plusieurs modèles plutôt qu'en construire un seul

À l'opposé de la course à la puissance brute, l'approche de Fugu, de Sakana AI, me semble très prometteuse. Plutôt que de viser un modèle capable de tout faire, Fugu orchestre plusieurs modèles performants : il décompose les tâches et délègue chacune selon les capacités qu'elle demande.

D'autres approches existent autour du routage, comme RouteLLM ou Not Diamond, qui sélectionnent le modèle le plus adapté à une requête. Les modèles de décision (decision models) vont dans le même sens : Jev, de TypeSafe AI, ne rédige pas de texte, il rend une décision, par exemple le modèle à qui confier une requête, accompagnée d'un niveau de confiance. Aucun de ces routeurs ne sait découper une tâche comme le fait Fugu : ils choisissent, ils n'orchestrent pas. Mais la logique est voisine : ne plus dépendre d'un seul modèle.

Cette philosophie concilie trois objectifs : performance, rapport qualité/prix et souveraineté. Maîtriser l'orchestration, c'est choisir quelles informations transmettre à quels modèles, filtrer ce qui doit l'être et répartir les traitements selon les exigences de confidentialité. Cela demande une architecture adaptée, et ne rend pas les modèles déterministes pour autant.

L'avenir ne reposera pas seulement sur le meilleur modèle individuel, mais sur notre capacité à faire travailler intelligemment plusieurs modèles ensemble.

Auto-héberger quand le volume l'exige

Combiner plusieurs modèles, c'est aussi choisir où ils tournent. Avec une API commerciale, dès que plusieurs agents travaillent en parallèle, on se heurte vite aux limites de débit, et la facture grimpe avec chaque agent ajouté. Auto-hébergé, le modèle n'est plus limité que par le matériel : on provisionne le débit de tokens selon le nombre d'agents à faire tourner en parallèle, et les moteurs d'inférence comme vLLM regroupent les requêtes concurrentes pour en tirer le meilleur rendement. Le coût devient celui de l'infrastructure, et non plus celui de chaque token.

Ce qui pose immédiatement la question de la couche qui fait travailler ces modèles.

Partie 2 — Le harness : ce qui fait réellement travailler un modèle

Le harness, pièce maîtresse

J'aime l'analogie du cavalier et de son cheval : le modèle apporte ses capacités, le harness permet de les guider et de les exploiter.

Le harness ne se limite pas à exécuter une commande ou à appeler un outil. Il gère la communication entre agents, la transmission du contexte, l'interprétation des résultats, les erreurs et la continuité d'exécution. C'est flagrant quand plusieurs agents collaborent : une information mal transmise ou une orchestration bancale suffit à dégrader les résultats, même avec d'excellents modèles.

Construire un harness fiable est long et complexe. Plutôt que de développer systématiquement le sien, je préfère maintenir une veille régulière et choisir la solution adaptée à chaque usage. J'en utilise principalement deux :

• Claude Code, au quotidien : petites tâches de développement, exécution de commandes, mises en production. Il reste très efficace sur ces usages. Mon principal reproche porte sur la gestion des permissions, que je trouve parfois trop prudente : j'aimerais des réglages plus modulaires et plus faciles à ajuster selon l'environnement et le niveau de confiance.
• Prime Agent, de Prime Intellect, pour les sessions longues et les travaux qui demandent davantage de coordination. Ce qui m'intéresse, c'est sa gestion de la communication entre agents, son kernel Python persistant et l'usage d'un Python REPL comme environnement principal d'interaction. On y manipule le contexte, on appelle des outils, on pilote des sous-agents, et l'état d'exécution se maintient sur la durée : une philosophie particulièrement adaptée aux tâches longues et aux systèmes multi-agents.

Le harness n'est pas un simple outil pour envoyer des prompts : c'est la couche qui transforme les capacités d'un modèle en un système capable de réellement travailler.

La sandbox, brique d'exécution modulaire

Un agent qui agit a besoin d'un endroit où agir. À mesure que les tâches se complexifient, il faut pouvoir lui fournir des environnements isolés, configurables et créés à la demande.

Tout l'intérêt est dans la modularité. Une sandbox devrait se créer à la volée, avec les ressources, les outils et les permissions nécessaires à une tâche précise : très fermée (réseau limité, outils restreints, règles strictes) ou beaucoup plus ouverte quand l'environnement et le cas d'usage le permettent. Pare-feu, outils disponibles, accès au système de fichiers, ressources externes : chaque élément devrait être configurable.

Une même architecture pourrait alors servir à développer du code, lancer des tests, manipuler des fichiers ou piloter un navigateur et une interface graphique via du Browser Use ou du Computer Use.

C'est avec les essaims d'agents (Agent Swarms) que l'approche prend toute sa valeur. Un harness superviseur découpe une tâche, distribue le travail et fournit à chaque agent un environnement adapté : ses outils, ses règles réseau, ses ressources. Il coordonne les exécutions, récupère les résultats et organise la suite. Plus besoin de préparer chaque environnement à la main.

Prenons un cas concret : des tests d'intrusion autorisés, conduits par un essaim d'agents qui s'appuie sur un modèle auto-hébergé aux garde-fous retirés, comme les variantes communautaires Uncensored de GLM-5.3. L'orchestrateur découpe le périmètre (reconnaissance, énumération des services, analyse des applications, vérification des pistes) et confie chaque tâche à un agent, dans sa propre sandbox, avec ses outils et des accès réseau strictement limités au périmètre autorisé.

L'auto-hébergement a ici deux intérêts : lancer autant d'agents en concurrence que le matériel le permet, et s'appuyer sur une variante Uncensored, sans les barrières que les modèles grand public opposent aux tâches offensives, même dans un cadre légitime.

Des dizaines d'agents peuvent ainsi explorer un périmètre en parallèle sous la supervision de l'orchestrateur. Cela ouvre des possibilités importantes pour l'automatisation des tests, la recherche technique et l'exécution de workflows complexes.

La sandbox n'est plus seulement un environnement isolé : c'est une brique d'exécution que l'infrastructure doit savoir provisionner dynamiquement.

Partie 3 — Le contexte : ne pas refaire ce que l'infrastructure sait déjà

Chercher plutôt qu'indexer

On parle énormément de la taille des fenêtres de contexte. Mais disposer d'une grande fenêtre ne signifie pas qu'il faille y verser toute l'information disponible. La qualité du contexte, et la façon de le récupérer, comptent autant que les capacités du modèle. Et c'est le harness qui en décide.

Boris Cherny, créateur de Claude Code chez Anthropic, raconte dans un entretien avec The Pragmatic Engineer que les premières approches de recherche dans le code reposaient sur des bases vectorielles locales et des mécanismes d'indexation. L'équipe a finalement constaté que la recherche agentique, avec des outils bien plus simples comme Glob et Grep, donnait de meilleurs résultats dans ses expérimentations.

La raison est intéressante. Un index vectoriel devient obsolète quand le code évolue, et il ajoute des contraintes de synchronisation et de permissions. Un agent qui recherche dynamiquement, parcourt le code et ajuste ses recherches aux résultats construit progressivement le contexte dont il a besoin. La recherche vectorielle n'est pas inutile pour autant : elle n'est simplement pas toujours la meilleure solution.

L'adressage par contenu, que le modèle réinvente seul

Trouver l'information ne suffit pas, il faut aussi s'en souvenir. Je le constate directement sur mes sessions Prime Agent. Son REPL Python persistant donne au modèle un état qu'il conserve d'un tour à l'autre, et un modèle comme Claude Opus 5.5 s'en empare spontanément : il calcule des empreintes SHA-256 du contenu des fichiers et des données qu'il manipule, les garde en mémoire, puis compare. Il ne retraite que ce dont l'empreinte a bougé, détecte les dérives (j'ai vu passer des vérifications explicites de module drift) et contrôle l'intégrité de ce qu'il a déjà vu. Il s'en sert aussi pour dédupliquer des enregistrements par le hash de leur forme canonique, ou pour fabriquer des identifiants courts.

Autrement dit, l'adressage par contenu, le principe sur lequel repose Git, n'est pas qu'une idée d'infrastructure : c'est déjà une technique que le modèle adopte de lui-même pour gérer sa mémoire et son suivi, dès qu'un environnement persistant le lui permet. Reste à remonter cette logique dans l'infrastructure elle-même, partagée entre les agents et conservée au-delà d'une session, plutôt que de la laisser se réinventer dans chaque kernel.

La gestion du contexte doit devenir une capacité de l'infrastructure, et non une responsabilité laissée au seul modèle.

Git et SDLC : une infrastructure pensée pour des humains

Git est essentiel. Mais le Software Development Life Cycle (SDLC) tel que nous le connaissons a été construit autour du travail humain : un développeur récupère un dépôt, crée une branche, modifie du code, réalise des commits, ouvre une pull request, puis des pipelines CI/CD valident et déploient. Ces mécanismes ont largement fait leurs preuves.

Que se passe-t-il quand ce développeur est remplacé par des dizaines, voire des centaines d'agents capables de travailler simultanément ? Volumes de modifications, besoins en environnements d'exécution, opérations de validation : tout change d'échelle.

Anthropic et OpenAI l'ont déjà constaté, et y répondent de deux façons :

• Scion, chez Anthropic : un système de gestion de versions interne conçu pour un développement où les agents produisent du code en permanence. L'accès aux fichiers, aux commits et aux métadonnées a été repensé : clients plus légers, architecture orientée serveur, possibilité de travailler sans matérialiser systématiquement l'ensemble du dépôt.
• Pando, chez OpenAI : une infrastructure qui poursuit un objectif comparable, mais en restant compatible avec Git. Il ne s'agit pas de remplacer les usages existants, mais de faire évoluer l'infrastructure sous-jacente pour absorber un volume bien plus important de lectures, d'écritures et de modifications concurrentes.

Deux philosophies, un même constat : les infrastructures de développement pensées pour une production humaine commencent à atteindre leurs limites face au rythme des agents.

Le sujet dépasse Git. Il touche directement les pipelines CI/CD, les runners et l'ensemble du cycle de vie logiciel :

• Faut-il vraiment effectuer un checkout complet à chaque exécution ?
• Faut-il relancer les mêmes suites de tests quand un agent ne modifie qu'une petite partie du projet ?
• Comment éviter que des agents travaillant en parallèle saturent l'infrastructure avec des opérations redondantes ?

Ces questions ne remettent pas en cause leur utilité, au contraire. Git et les pipelines CI/CD sont précisément ce sur quoi le harness peut s'appuyer pour garder la pleine maîtrise de ce qu'il réalise : chaque modification est tracée, attribuée et réversible, et chaque étape est validée avant de passer à la suivante. Plus les agents travaillent en autonomie, plus ce filet compte.

Git au cœur du harness

Une partie de la réponse se trouve déjà dans Git lui-même. Git identifie ses objets par une empreinte (SHA) calculée sur leur contenu : on sait exactement ce qui a changé, on peut vérifier l'intégrité d'un objet et réutiliser ce qui est resté identique. C'est exactement la technique que le modèle réinvente seul dans son kernel. Un SHA ne dit pas ce qui est pertinent, mais il dit ce qui est encore valide.

Git doit donc être pleinement intégré au harness des agents, plutôt que de rester un outil de versioning appelé ponctuellement. Le harness devrait comprendre l'état du dépôt, gérer les modifications concurrentes, interroger l'historique et tenir à jour, de façon incrémentale, ce qu'il sait du projet : dépendances, symboles, résultats de tests. Un agent qui connaît précisément les fichiers modifiés et les tests associés ne relit pas tout le dépôt et ne relance pas tout : tests, validations et déploiements suivent les modifications réellement apportées.

Pourquoi faire reconstruire sans cesse à un agent un contexte que notre infrastructure connaît déjà ? Le lui fournir réduit les coûts et la consommation de tokens, et facilite le travail parallèle de plusieurs agents.

Le Super-agent de DeepSeek, un prototype de recherche publié fin octobre avec un essai, donne un aperçu de ces deux idées : un contexte tenu par l'infrastructure, et Git comme canal de travail. Dans l'essai, la fenêtre de contexte est traitée comme un cache, et chaque objet porte un identifiant que le modèle suit pour retrouver ce dont il a besoin, au lieu de tout garder en mémoire. Et l'agent n'y attend pas qu'on lui parle : une demande déposée sur GitHub ou un résultat de CI devient un déclencheur, le travail s'exécute dans une session dédiée, et le résultat revient sous forme de pull request. Git et la CI n'y sont plus des outils que l'agent appelle ponctuellement : ce sont le canal par lequel le travail arrive, se trace et se valide.

Il ne s'agit pas d'abandonner Git, mais de repenser la façon dont nous l'intégrons à nos systèmes. Nous devons passer d'un SDLC auquel on ajoute des agents à un SDLC réellement conçu autour de leur fonctionnement.

Partie 4 — La maîtrise : mesurer en continu, contrôler les flux

Benchmarks : mesurer les modèles, mais surtout continuer à les mesurer

Les benchmarks occupent une place centrale dans la comparaison des modèles : ils révèlent leurs forces et leurs faiblesses et permettent de suivre l'évolution des performances. Je pense pourtant que nous avons encore beaucoup de travail sur ce sujet, en particulier dans les entreprises IT qui proposent des services autour de l'IA.

Je ne prétends pas être exemplaire. Aujourd'hui, ma veille passe surtout par Artificial Analysis, dont je relaie régulièrement les résultats dans la rubrique Veille de Nexsit. Mais ces résultats ne remplacent pas des mesures faites sur ses propres usages, avec des scénarios plus proches de ce que l'on rencontre réellement.

Car nous avons tendance à regarder les performances annoncées sans toujours mesurer ce qui se passe réellement en production. La quantification en est un bon exemple : selon la technique employée, la configuration d'inférence et les ressources disponibles, les performances peuvent évoluer sensiblement.

Un modèle passe les premiers benchmarks de validation, part en production, puis n'est plus évalué régulièrement. Pourtant, son environnement continue de bouger : les modèles sont mis à jour, les prompts changent, les harness évoluent, les configurations d'exécution sont modifiées. Comment garantir que les résultats restent satisfaisants si on ne les mesure plus ?

Un retour d'expérience publié par Shane Melaugh sur X m'a notamment interpellé. Ce type d'observation mérite d'être étudié plus sérieusement, avec des protocoles reproductibles plutôt que de simples impressions.

Pour une entreprise qui propose des solutions IA, la question est fondamentale. Nous devrions mesurer en continu la qualité des réponses, la réussite des tâches, les coûts, les temps d'exécution et la stabilité des comportements. Et pas seulement pour les modèles : aussi pour les harness, les stratégies de routage, les environnements d'exécution et les workflows de développement.

Un benchmark ne devrait pas être uniquement un outil de sélection avant la mise en production, mais un dispositif de contrôle continu.

Passerelles IA : reprendre la maîtrise des flux

C'est le sujet qui concentre aujourd'hui une grande partie de mon attention.

De nombreuses entreprises adoptent progressivement différents outils d'IA : abonnements ChatGPT, Claude, Claude Code ou autres, souscrits parfois individuellement, parfois à l'échelle d'une équipe. Chaque service a ses avantages, mais cette multiplication pose une question importante : qui maîtrise réellement les échanges entre les collaborateurs, les applications de l'entreprise et les modèles d'IA ?

C'est là que la passerelle IA (AI Gateway) prend tout son sens : un point de passage central qui supervise les interactions entre les utilisateurs, les agents et les fournisseurs de modèles. Elle contrôle les requêtes et les réponses, route les demandes vers les modèles adaptés et applique des règles de sécurité selon les utilisateurs, les applications ou la sensibilité des données.

Je pense en particulier à la protection des secrets d'entreprise, des données personnelles (PII), des documents internes et des informations sensibles présentes dans les dossiers traités. Une passerelle bien conçue doit pouvoir les identifier et les filtrer avant leur transmission à un modèle externe, appliquer des politiques d'accès et conserver une traçabilité maîtrisée des échanges.

Elle doit surtout s'intégrer aux équipements et aux outils que les services IT utilisent déjà. Je ne crois pas qu'il faille construire un écosystème de sécurité parallèle pour l'IA : il faut au contraire exploiter les mécanismes existants, à savoir la gestion des identités, les pare-feu, les politiques réseau, la journalisation, la supervision et le contrôle des accès.

Des solutions existent déjà. Amazon Bedrock, par exemple, donne accès à différents modèles et propose un routage intelligent qui choisit, pour chaque requête, entre deux modèles d'une même famille. Mais une question persiste : celle de la souveraineté. Même avec des mécanismes de contrôle et des options de résidence des données, nous restons dépendants de l'infrastructure, des services et des décisions d'un hyperscaler. Nous avons centralisé les accès, mais avons-nous réellement retrouvé notre indépendance ?

D'où mon intérêt pour une passerelle plus ouverte et maîtrisable. L'objectif n'est pas d'ajouter une API devant les modèles, mais de construire une couche capable de s'interfacer avec différentes infrastructures et de laisser l'entreprise définir ses propres règles. Elle permettrait de combiner des modèles hébergés localement, des fournisseurs européens et des services externes, tout en contrôlant les informations transmises à chacun. On retrouve ici l'orchestration de la première partie, appliquée aux flux de l'entreprise.

Le véritable enjeu est de reprendre la maîtrise du routage et des flux, sans enfermer l'entreprise dans une plateforme unique.

Cette réflexion prend forme chez Nexsit : une première version alpha d'une passerelle IA y sera prochainement présentée. C'est une première étape pour explorer cette approche, confronter les choix techniques à des usages réels et avancer vers une gestion de l'IA en entreprise plus accessible, modulaire et souveraine.

Conclusion : au-delà du modèle, c'est l'infrastructure qui compte

Les nouveaux modèles continuent de m'intéresser : leurs progrès sont impressionnants et ouvrent de nouvelles possibilités. Mais je suis de moins en moins convaincu que la bataille se joue sur leur seule puissance brute. Ce qui m'intéresse désormais, c'est l'ensemble des composants qui transforment ces capacités en systèmes réellement exploitables.

La passerelle est le sujet le plus avancé. Les autres sont ceux sur lesquels je travaille aujourd'hui :

• orchestration : faire travailler plusieurs modèles ensemble plutôt que tout attendre d'un seul ;
• harness et contexte : remonter dans l'infrastructure la mémoire et le suivi que les modèles bricolent déjà seuls ;
• sandboxes : provisionner des environnements à la demande pour des essaims d'agents ;
• Git et SDLC : intégrer Git, les harness et les runners dans un cycle véritablement agentique ;
• benchmarks : mesurer sur ses propres usages, et en continu.

Cet article reste un point d'étape : certaines positions évolueront probablement avec les prochaines avancées et mes expérimentations. Mais une conviction se renforce : la prochaine bataille de l'IA ne se jouera pas seulement sur le meilleur modèle, mais sur la maîtrise de toute l'infrastructure qui le fait travailler.