Nous avons testé nos LLM auto-hébergés et créé un jeu par accident

Cela ressemble au début d’une blague : une entreprise de cybersécurité se lance dans le test de ses modèles d’IA et se retrouve avec un jeu. Mais c’est bel et bien ce qui s’est passé, et cela soulève une question légitime que j’attends de la part de nos partenaires dans la semaine qui suivra la publication de ce blog. Pourquoi construisez-vous un jeu alors que votre agent IA n’est même pas terminé ?

Laissez-moi y répondre avant que quiconque ne pose la question. Nous ne construisions pas du tout un jeu. Nous testions des grands modèles de langage, et c’est un jeu qui en est sorti.

Cette distinction compte davantage qu’il n’y paraît. La plupart des MSP et des responsables IT à qui je parle se posent les mêmes questions que nous : à quels grands modèles de langage pouvons-nous faire confiance, devrions-nous les héberger nous-mêmes, et que devraient faire nos équipes pendant que les agents de codage IA tapent le code ? Notre jeu accidentel, sous-produit d’un simple test de prompting one-shot, s’est révélé un prisme étonnamment utile sur ces trois questions.

Comment un test de modèle s’est-il transformé en jeu ?

Notre Lead SRE a un test standard pour chaque nouveau modèle. Il lui donne un prompt fixe : construire un jeu de plateforme complet en une seule fois. C’est du prompting one-shot ; une seule instruction, aucune correction de suivi, aucun accompagnement. La proximité du résultat obtenu par un modèle en dit long sur son raisonnement, la qualité de son code et sa capacité à tenir ensemble une tâche de grande ampleur. Nous appliquons ce test aux LLM open source auto-hébergés que nous utilisons, et comme nous remplaçons ces modèles régulièrement à mesure que de meilleurs apparaissent, un test qui reste exactement le même vaut davantage que n’importe quel classement.

Cette fois, il est allé plus loin. Plutôt que de s’arrêter au résultat one-shot, il a laissé le modèle s’appuyer sur notre site web public et sur les informations qu’il expose via le Model Context Protocol (MCP), et lui a demandé d’intégrer tout cela dans le jeu. Dans des sessions parallèles, pendant que d’autres sessions de codage IA tournaient, l’expérience s’est muée en Lighthouse Run : six niveaux et 24 zones remplies de références à notre secteur, des boss de fin, un rapport de scan à la fin de chaque niveau et un niveau Daily Scan généré de façon semi-aléatoire qui change chaque jour. Le jeu entier tient dans un unique fichier HTML autonome, et le projet qui l’entoure inclut des tests pour que l’IA puisse exécuter et vérifier ses propres modifications.

J’ai joué quelques niveaux. Ils ne sont pas faciles, ce que je dis comme un compliment. Vous pouvez l’essayer sur https://guardian360.net/lighthouse-run/ ; montez le son, et cela fonctionne aussi sur un téléphone ou avec une manette.

Pourquoi tester un LLM avec un prompt one-shot ?

Parce que nos impressions sur l’IA ne sont pas fiables. Dans une enquête menée auprès de 349 travailleurs techniques et publiée en mai 2026, METR a constaté que les participants rapportaient eux-mêmes une variation médiane de 1,4 à 2 fois de la valeur de leur travail grâce aux outils d’IA, et une variation de vitesse médiane de 3 fois. METR lui-même met en garde contre une lecture au pied de la lettre : son étude du début 2025 avait montré que les gens surestimaient en moyenne de 40 points de pourcentage l’effet de l’IA sur le temps consacré à leurs tâches.

Si des personnes techniques expérimentées se trompent sur les outils qu’elles utilisent tous les jours, une démo fournisseur soignée n’est pas une base solide pour choisir un modèle. Un prompt fixe et reproductible est rudimentaire, mais il est honnête. Même tâche, chaque modèle, résultats côte à côte. Un garage qui fait l’essai de chaque voiture sur le même parcours apprend davantage que celui qui se fie à la brochure.

Que font les ingénieurs pendant que les agents IA tapent le code ?

Le travail piloté par agents n’est plus une expérimentation. L’enquête 2026 de JetBrains sur l’écosystème des développeurs, menée auprès de plus de 15 000 développeurs professionnels, a révélé qu’entre mai et juillet 2026, 90 % utilisaient des agents de codage IA au travail au moins une fois par semaine, et 68 % les utilisaient quotidiennement.

Cela change la forme de la journée d’un ingénieur. Moins de temps passé à taper, davantage à instruire, à relire et à attendre. METR s’est heurté à cela en tentant de reproduire sa recherche sur la productivité. Il a observé une augmentation significative du nombre de développeurs refusant de participer parce qu’ils ne voulaient pas travailler sans IA, et a constaté que ses mesures de temps n’étaient pas fiables pour les développeurs utilisant plusieurs agents IA simultanément.

C’est exactement ainsi que travaille notre Lead SRE. Plusieurs sessions tournent en parallèle, et il y a des intervalles pendant que chacune se termine. Ce qui se passe dans ces intervalles est une question de leadership. Vous pouvez faire comme s’ils n’existaient pas, les remplir par plus de la même chose, ou laisser les équipes s’en servir pour tester des idées. Nous avons une culture du prototypage rapide : construire petit, tester vite, garder ce qui marche et jeter ce qui ne marche pas. Ces intervalles sont là où les hypothèses sont testées à moindre coût.

Pourquoi le choix du modèle est-il une décision de sécurité ?

Choisir un modèle d’IA n’est plus seulement une question de capacité ; c’est une question de sécurité. Le rapport 2026 de Veracode sur la sécurité du code GenAI a testé plus de 100 modèles et a constaté qu’ils obtenaient en moyenne un taux de réussite en matière de sécurité de 56 %, quasiment inchangé par rapport à 2025, alors même que les taux de réussite syntaxique approchaient les 100 %. Les modèles spécialisés dans le code n’étaient pas plus sûrs que les modèles généralistes. La conclusion même de Veracode est que le choix du modèle est discrètement devenu une décision de sécurité.

Pour une entreprise qui travaille dans la cybersécurité, cela tranche la question. Nous ne pouvons pas choisir des modèles sur la base de leur réputation ou de benchmarks publiés par leurs concepteurs. Nous devons voir par nous-mêmes comment un modèle se comporte face à une tâche conséquente, ce qui est précisément ce que montre un test one-shot. Héberger les modèles nous-mêmes nous donne le contrôle sur la destination de nos données. Et intégrer des tests dans le projet signifie que l’IA peut vérifier son propre travail, plutôt que de nous obliger à lui faire confiance. Comme le dit Veracode, le code généré par l’IA devrait être traité comme tout code non relu.

Que peuvent en retenir les MSP et les responsables IT ?

La première leçon est de tester avant de faire confiance. Choisissez une tâche conséquente et reproductible qui reflète votre propre travail et faites-y passer chaque modèle que vous envisagez. Il n’est pas nécessaire que ce soit un jeu ; il faut que ce soit la même chose à chaque fois.

La deuxième est de traiter la sortie de l’IA comme du code non relu. Intégrez la vérification dans le processus, idéalement de sorte que l’IA puisse exécuter des tests sur son propre travail, et gardez un humain responsable de ce qui passe en production.

La troisième est de donner à l’expérimentation des limites plutôt que de l’interdire. Petite, autonome, bornée dans le temps et avec un objectif clair. Dans ces limites, un résultat inattendu est un bonus bienvenu plutôt qu’une distraction inquiétante.

Les bonnes expériences donnent plus que ce que vous cherchiez

Nous cherchions une réponse fiable sur les modèles auxquels nous pouvons faire confiance. Nous l’avons obtenue, ainsi qu’un jeu dont nous sommes un peu trop fiers. Essayez-le ; il y a quelques extras cachés pour ceux qui savent où regarder, et pour ceux qui connaissent leurs mèmes Internet.

Et dites-moi ensuite : comment testez-vous les modèles d’IA sur lesquels votre équipe s’appuie avant de leur faire confiance ?