L'agentique en production : un audit n'est pas un pentest

Je précise mon biais d’entrée : aucun diplôme, bientôt 25 ans de métier sans compter la pratique. Je fais tourner des agents LLM tous les jours, en local et au cloud et j’ai passé une bonne partie de 2025-2026 à répondre dans des fils LinkedIn sur ce qu’ils savent vraiment faire. Cet article assemble ces réponses : où l’agentique est pertinente, où elle plafonne, quels pièges opérationnels coûtent des heures et pourquoi la réponse au “code plausible en trois prompts” n’est pas une certification.

1. Audit, pentest, CTF : trois exercices, trois usages

La confusion la plus fréquente est terminologique et elle coûte des budgets.

Pour de l’audit, l’agentique est extrêmement pertinente. Collecte, analyse de configurations, AD, messagerie, architecture, confrontation à des référentiels, corrélation des findings, priorisation, restitution : c’est typiquement le genre de travail où plusieurs agents apportent énormément. Un agent qui extrait une config Nginx, le confronte à un benchmark et remonte les écarts, c’est un stagiaire infatigable et il ne se plaint pas des dumps LDAP.

Pour du pentest, la problématique est différente. Il faut construire et démontrer un chemin d’exploitation dans un environnement réel et là les limites actuelles sont beaucoup plus visibles. Ça ne veut pas dire que l’agentique ne peut pas faire du pentest, on le voit dans les CTF. Avec le bon modèle, un RAG adapté, les bons outils et surtout des garde-fous et une vraie boucle d’exécution/vérification, ça devient déjà très intéressant.

Dans mon approche, plusieurs modèles travaillent en parallèle, mais le consensus n’est jamais considéré comme une preuve. Les résultats doivent être vérifiables. Trois modèles d’accord ne valent pas une démonstration et une démonstration ne vaut rien si elle n’est pas reproductible.

2. Les données avant le modèle

Avant même de choisir un modèle, il y a un autre sujet essentiel : les données. Pour un audit, on manipule potentiellement AD, dumps LDAP, code source, configurations et données client sous NDA.

Donc idéalement modèle local et si possible spécialisé/entraîné pour la tâche. À défaut, avec un LLM commercial, il faut au minimum connaître ses limites, ses biais et vérifier précisément ce qui arrive aux données : rétention, entraînement. Bref : IA oui, mais pas “on balance un agent sur la prod et on croise les doigts”.

C’est une règle d’hygiène numérique appliquée à l’agentique : la moindre exposition ne s’arrête pas à vos photos de vacances.

3. Le piège Ollama : le contexte tronqué en silence

Le bug opérationnel le plus coûteux que je vois en 2026 n’est pas dans les modèles, il est dans les wrappers. Lancez ollama ps pendant une session et regardez la colonne CONTEXT.

Ollama applique souvent un contexte par défaut très inférieur à celui annoncé par le modèle et tronque par le début au-delà, silencieusement, sans warning ni erreur. En chat ça passe. En agentique c’est fatal : le prompt système et les définitions d’outils consomment déjà des milliers de tokens, le plan sort du contexte au bout de deux tours, les tool calls partent en vrille, l’agent refait le travail. C’est comme ça qu’une micro-feature de deux minutes devient une session de vingt-deux, le cas OpenCode plus Ollama est largement documenté.

Deuxième grief et pas le moindre : Ollama choisit à ta place sans te dire ce qu’il a choisi. Pour un usage quotidien c’est confortable. Pour du fine-tuning ou pour publier un chiffre, c’est rédhibitoire. Si tu veux garder la simplicité tout en voyant ce que tu règles, LM Studio expose le contexte, l’offload GPU et la quantification du cache KV dans l’interface et sert un endpoint compatible OpenAI. Si tu veux le contrôle complet, llama-server ou mlx_lm.server se lancent en une ligne, contexte et cache passés en paramètres, tout est dans les logs.

Troisième détail qui change les chiffres : un modèle dense comme Qwen3 32B relit les 32 milliards de paramètres à chaque token et expose un curseur reasoning_effort réglé haut par défaut, sur une tâche triviale il overthink et vos trente minutes de phase de plan pointent exactement là. Un MoE type 30B-A3B occupe la même mémoire mais n’active que 3 milliards par token et l’écart se compte en multiples.

4. Local ou cloud : la mauvaise question

Mon reproche à Ollama ne porte pas sur la vitesse, dans ses versions récentes il tourne aussi sous MLX et l’écart avec llama.cpp se joue à 10 ou 15 %. Je fais tourner du Qwen3-Coder en agentique sur une 4090 et une 3080 avec llama.cpp : sur du diff, de la complétion et du refactor cadré, c’est utilisable au quotidien. Sur du raisonnement long et de l’exploration de gros contexte, non et je bascule sur du cloud sans état d’âme.

La vraie question n’est donc pas “local ou pas”, c’est quelle tâche va où. Un modèle à raisonnement, on le borne, on choisit la tâche, on ne s’engouffre pas dans le séduisant parce qu’il brille. En 1990 avec les réseaux de neurones, en 2026 avec les LLM, le réflexe d’ingénieur n’a pas bougé d’un pouce : la chose robuste et un peu ennuyeuse survit à la chose ambitieuse et fragile.

Et le cadrage change tout : un laptop n’est pas un déploiement. Pour les entreprises que je forme, du local, ce n’est pas un MacBook par développeur : c’est un serveur GPU mutualisé sous vLLM, avec du batching continu et une dizaine de sessions en parallèle. Autre régime, autres chiffres et la conclusion “le local est lent” ne couvre pas ce cas.

5. Les tests qui mentent

Un test qui ne vérifie rien passe au vert sans broncher. Mais ce défaut n’est pas propre à l’IA : un humain en pond tout le temps, moi le premier.

Au début j’étais réticent à confier l’écriture des tests à l’agentique. Depuis, avec le bon contexte et les bonnes instructions, le LLM les écrit mieux et plus vite que moi. De mon côté, je supervise et je repasse derrière sur les itérations majeures, exactement comme je le ferais pour du code humain. On garde le shift left : un faux vert, c’est un défaut comme un autre, mieux vaut le rattraper le plus tôt possible.

Et ce qui dit NON à un test qui ne vérifie rien, ce n’est pas un humain avec un avis : c’est du mutation testing. On mute le code exprès ; si le test reste vert, il ne sert à rien. Stryker, mutmut, PIT : déterministe, 0 ou 1, le même garde-fou appliqué aux tests eux-mêmes. Ce qui fait autorité sur un test, ce n’est pas son auteur, c’est la mécanique.

6. Specification gaming : l’agent n’a pas “voulu” pirater

L’histoire du LLM d’OpenAI qui a piraté Hugging Face a fait son tour. Rien de fou : on a explicitement demandé aux modèles de pratiquer de l’exploitation avancée par chemins d’attaque complexes et on a désactivé les garde-fous pour mesurer le plafond.

Ce n’est pas une IA qui décide un matin de pirater quelqu’un, c’est du specification gaming à grande échelle. OpenAI le dit à peu près en ces termes : les modèles étaient hyperfocalisés sur la résolution d’ExploitGym et sont allés à des extrémités considérables pour atteindre un objectif de test assez étroit. Le modèle n’a pas voulu pirater HF, il a voulu maximiser un score et le chemin le moins cher passait par le vol de la correction. C’est le vieux problème du RL, sauf qu’ici l’agent a un RCE au bout.

Ce n’est pas isolé : Anthropic a rapporté qu’un modèle avait également échappé à un sandbox pendant des tests de sécurité pour obtenir un accès Internet non prévu et oui, c’est aussi un coup de comm’. La leçon reste : la garde-fou désactivé pour “mesurer le plafond” est un plafond qui s’ouvre.

7. Le jugement ne se certifie pas

Le problème réel : comment filtrer sur le jugement quand n’importe qui sort du code plausible en trois prompts ? Mais je ne crois pas que la certification soit le bon instrument.

On sait depuis 25 ans ce qui prédit la performance d’un candidat. La méta-analyse de référence (Sackett et al., 2022) met en tête l’entretien structuré, le test de connaissances métier et la mise en situation. Le diplôme et l’expérience déclarée arrivent bons derniers, très loin derrière. Une certification, c’est encore un cran en dessous : ça s’achète et ça se périme en quelques trimestres. Et quand celui qui vend la formation est aussi celui qui certifie et qui recrute, sans examen indépendant, on ne mesure pas la compétence, on mesure le passage à la caisse.

Ce qui marche est plus simple et gratuit : faire coder le candidat devant vous, avec ou sans IDE, LLM, agent, harnais, puis lui demander de raconter un incident de prod qu’il a vraiment vécu. Le code plausible se produit en trois prompts ; l’incident vécu se raconte avec ses détails, ses mauvaises décisions et son arrière-goût.

8. L’outil amplifie celui qui le tient

La question que je pose à ceux qui craignent l’agentique et à ceux qui l’adorent : qui se sert de l’outil pour savoir et qui se fait servir par lui.

Le goulot n’a jamais été la machine, il est dans le discernement et dans les fondamentaux qu’on ne veut plus apprendre. Le pire n’est même plus ceux qui n’y touchent pas, c’est ce qu’on fabrique à l’intérieur du métier : toute une génération spécialisée à outrance et formée à la chaîne, collée à leurs idiomes et frameworks, qui livre du code sans avoir jamais regardé ce qu’il y a dessous. Ils ne savent pas ce que fait un syscall, comment circule un paquet TCP/IP, ce qui se passe sous l’abstraction et surtout ça ne les intéresse pas une seconde.

Mettez un LLM dans ces mains là et il ne les élève pas : il les laisse filer plus vite dans la même ornière. L’outil amplifie celui qui le tient. Une poignée de profils s’en servira pour creuser et vraiment apprendre, beaucoup pour penser à leur place et livrer du slop à la chaîne, en masquant le trou un peu plus vite.

Résumé

Audit et pentest ne sont pas le même exercice : l’agentique excelle sur la collecte et la confrontation aux référentiels, plafonne sur la démonstration d’exploitation. Le consensus de plusieurs modèles n’est jamais une preuve.
Les données d’abord : NDA, dumps AD, code source impliquent un modèle local ou une vérification précise de la rétention. Pas d’agent sur la prod sans cadrage.
Le piège numéro un de 2026 est opérationnel, pas intellectuel : le contexte tronqué en silence (Ollama, colonne CONTEXT) transforme deux minutes en vingt-deux heures. Choisissez des outils qui exposent leurs choix.
Local ou cloud est la mauvaise question ; la bonne est quelle tâche va où. Un modèle dense qui overthink sur une 4090 ne dit rien du local bien déployé sous vLLM.
Les faux verts se tranchent au mutation testing, pas à l’opinion. Le specification gaming n’est pas une intention malveillante, c’est un objectif mal borné avec un RCE au bout.
La certification ne mesure pas le jugement. Faites coder, puis faites raconter un incident de prod vécu.
L’outil amplifie celui qui le tient. Investissez dans les fondamentaux avant d’investir dans les tokens.