L’analyse statique de code promet de trouver les failles avant la mise en production. En pratique, elle noie les développeurs sous les faux positifs, et ceux-ci finissent par l’ignorer. Présenté à SecSea 2026 par un ingénieur en sécurité applicative, ce retour de terrain explore la sortie de l’impasse : non pas remplacer l’analyse statique par un modèle de langage, mais combiner règles déterministes et agents IA pour obtenir ce que ni l’une ni l’autre ne donne seule.
Sixième volet de notre couverture de SecSea 2026. Un sujet au cœur du DevSecOps, et de l’usage sérieux de l’IA.
Le problème : trop de bruit, pas assez de contexte
L’analyse statique (SAST) examine le code sans l’exécuter, dès l’éditeur ou dans la chaîne d’intégration. Son principe est sain : repérer qu’une entrée non fiable (une source) atteint une fonction sensible (un puits) sans avoir été assainie en chemin. Son défaut est structurel : faute de contexte d’exécution et de compréhension métier, elle signale beaucoup trop. Et un outil qui crie au loup cent fois pour une vraie alerte est un outil que les équipes désactivent.
Les représentations du code, du plus simple au plus riche
Pour tracer un flux de données, on modélise le code sous plusieurs formes, de plus en plus complètes : l’arbre syntaxique, le graphe de flot de contrôle, le graphe de dépendances, et enfin le graphe de propriétés de code qui combine les trois. Ce dernier permet d’interroger précisément un chemin « de la source au puits », même si sa maturité varie selon les langages. C’est l’outillage déterministe, précis et explicable.
Le modèle de langage : puissant, mais pas tout seul
Les LLM excellent là où l’analyse statique est aveugle : la logique métier, les défauts de contrôle d’accès, les autorisations. Mais les lâcher naïvement sur une base de code entière, c’est garantir un résultat coûteux, lent, à la couverture incertaine, et sujet aux hallucinations comme aux manipulations par du contexte piégé.
Ni l’un ni l’autre ne suffit. L’analyse statique voit tout et ne comprend rien ; le modèle comprend et ne voit pas tout. La réponse n’est pas de choisir, c’est de les faire travailler dans le bon ordre.
L’architecture hybride, et le rôle décisif du slicing
La clé tient dans une idée simple : le slicing, c’est-à-dire l’extraction déterministe des seules portions de code reliant une source à un puits. Au lieu d’envoyer toute la base au modèle, on ne lui soumet que le fragment pertinent. L’effet est spectaculaire sur les coûts, un des exemples cités réduisant la consommation d’un facteur proche de dix, tout en garantissant la couverture. L’architecture recommandée enchaîne alors trois étages :
- Déterministe : des règles et du slicing isolent le code critique, souvent sur les seules différences d’une demande de fusion plutôt que sur tout le dépôt.
- Raisonnement : un modèle juge l’exploitabilité et écarte les faux positifs.
- Contradiction : un agent contradicteur valide ou conteste chaque constat avant la revue humaine.
Un second intervenant a présenté un pipeline voisin : vectorisation du code, pré-tri par de petits modèles ciblés, puis investigation approfondie par un modèle plus large orchestré en agents, avec une interface pour vérifier les constats. Même philosophie : filtrer beaucoup, raisonner peu, mais bien.
Ce qu’on en retient chez Humanix
- Un outil de sécurité que les développeurs désactivent ne sert à rien. La bataille du SAST se gagne sur le taux de faux positifs, pas sur le nombre d’alertes. Tout ce qui réduit le bruit sans perdre en couverture est prioritaire.
- L’IA utile est encadrée, pas lâchée. Le bon usage d’un LLM en audit, c’est de le nourrir d’un fragment précis isolé par des règles déterministes, pas de lui confier une base entière. C’est la même leçon que celle de notre article sur les serveurs MCP : la discipline de l’outillage prime sur la puissance brute.
- Un agent contradicteur avant l’humain est une idée à retenir : faire challenger chaque constat par un second agent filtre le bruit avant qu’il n’atteigne une personne. On industrialise le doute.
- Commencer simple, puis monter en gamme. Un SAST basique pour amorcer la démarche, des agents ciblés pour les audits ponctuels, un pipeline hybride à grande échelle. C’est exactement le phasage que nous recommandons. La preuve avant le verdict.
À retenir
- L’analyse statique souffre d’un excès de faux positifs faute de contexte ; les développeurs finissent par l’ignorer.
- Le graphe de propriétés de code permet de tracer précisément un flux de la source au puits ; les LLM comprennent la logique métier mais coûtent cher et hallucinent seuls.
- Le slicing déterministe isole le fragment vulnérable et réduit drastiquement les coûts d’analyse par IA, à couverture maîtrisée.
- L’architecture gagnante enchaîne règles déterministes, raisonnement par LLM et agent contradicteur avant la revue humaine.
Note. Compte-rendu, à visée pédagogique, d’un entretien de SecSea 2026 sur l’analyse statique hybride et les agents LLM pour l’audit de sécurité applicative. Les approches et projets cités sont publics. Sixième volet de notre couverture de l’événement. Une chaîne de développement à sécuriser sans noyer vos équipes ? Contactez-nous.