Mantis : des agents IA pour détecter et corriger des failles de code

L’intelligence artificielle s’est rapidement installée dans les outils des développeurs. Génération de code, documentation, tests, refactoring ou recherche dans une base de code : les usages sont déjà nombreux. Avec Mantis, Google pousse cette logique dans une autre direction en utilisant plusieurs agents IA spécialisés pour participer à la recherche de vulnérabilités, à leur vérification et à la préparation de correctifs.

Publié en open source, Mantis est présenté comme un framework destiné à automatiser plusieurs étapes de l’analyse de sécurité d’un dépôt : découverte, triage, reproduction et correction de vulnérabilités. L’approche ne consiste donc pas seulement à demander à un modèle de lire quelques fichiers et de signaler ce qui lui paraît suspect. Elle cherche à construire un véritable processus autour de l’IA.

Cette évolution est particulièrement intéressante pour les équipes qui développent des SaaS, des applications web et des logiciels métier. Elle montre comment l’IA pourrait progressivement participer non seulement à la création du code, mais aussi à son contrôle et à sa maintenance.

1. Qu’est-ce que Mantis ?

Mantis est un ensemble d’outils open source conçu pour fonctionner avec des agents de développement capables de travailler directement sur une base de code. Google résume son objectif autour de quatre grandes étapes : découvrir, trier, reproduire et corriger des vulnérabilités logicielles.

Le projet s’inscrit dans une approche plus large utilisée par Google Cloud pour intégrer des agents spécialisés à différentes étapes du cycle de développement logiciel. Google indique disposer en interne d’une version plus complète du système, tandis que les éléments publiés permettent d’en expérimenter les principaux concepts.

L’objectif n’est donc pas simplement de créer un nouveau scanner de sécurité. L’idée consiste plutôt à orchestrer plusieurs agents capables de se répartir le travail et de transmettre leurs conclusions aux étapes suivantes. Un agent peut explorer le dépôt, un autre rechercher un comportement potentiellement dangereux, un troisième remettre en question le résultat, puis un autre tenter de reproduire le problème. Enfin, une proposition de correction peut être générée et soumise à validation.

Cette organisation rapproche davantage Mantis d’un processus automatisé de revue de sécurité que d’un simple assistant conversationnel. La valeur ne vient pas uniquement du modèle utilisé, mais de la façon dont les tâches, les contrôles et les preuves sont enchaînés.

2. Pourquoi un simple LLM ne suffit pas pour analyser la sécurité d’un projet

Les modèles de langage modernes comprennent relativement bien le code. Ils peuvent expliquer une fonction, identifier des erreurs évidentes ou proposer des améliorations. Mais cette capacité possède une limite importante : un modèle peut produire une réponse très convaincante tout en ayant tort.

Dans une utilisation classique, une erreur peut être gênante. Dans une analyse de sécurité, elle peut devenir problématique. Un modèle peut annoncer qu’une vulnérabilité existe alors que le problème est déjà neutralisé ailleurs dans l’application. Il peut au contraire passer à côté d’un contrôle important situé dans un autre fichier. Il peut également proposer une correction qui semble logique isolément, mais qui ne respecte pas le fonctionnement global de l’application.

Google explique que certaines approches trop simples de scan de code par IA peuvent aboutir à des taux de vrais positifs inférieurs à 7 %. C’est précisément l’un des problèmes auxquels Mantis cherche à répondre. Un grand nombre d’alertes ne signifie pas nécessairement une meilleure sécurité : une équipe peut rapidement perdre du temps à vérifier des dizaines de résultats qui ne présentent finalement aucun risque réel.

La question importante n’est donc pas seulement « l’IA peut-elle trouver quelque chose de suspect ? », mais plutôt « peut-elle expliquer pourquoi ce problème est important et apporter suffisamment d’éléments pour qu’il soit vérifié ? ». En sécurité, une alerte utile doit être contextualisée, reproductible et compréhensible.

3. Plusieurs agents IA plutôt qu’un seul

Mantis repose notamment sur une approche multi-agents. Au lieu de confier toute l’analyse à un seul modèle avec une instruction très générale, plusieurs tâches spécialisées sont enchaînées. Dans l’architecture décrite par Google, un agent de stratégie peut commencer par examiner la structure globale du projet, les dépendances et les zones potentiellement sensibles.

Des agents de recherche explorent ensuite plus précisément le code source. D’autres étapes servent à consolider les découvertes, éliminer les doublons, vérifier les résultats et filtrer les problèmes peu crédibles. Cette séparation possède un intérêt important : un agent auquel on demande simultanément de comprendre plusieurs milliers de fichiers, de rechercher des vulnérabilités, de vérifier ses propres conclusions et de proposer des corrections doit résoudre trop de problèmes à la fois.

Une architecture spécialisée permet au contraire de découper le travail. Elle autorise aussi certains agents à contester les conclusions produites par d’autres. Ce principe est courant dans le développement logiciel humain : une personne écrit du code, une autre le relit et les tests vérifient ensuite son comportement. Mantis applique une logique comparable à des agents IA.

4. Comprendre le contexte d’un dépôt de code

Une vulnérabilité n’existe presque jamais uniquement parce qu’une ligne de code paraît étrange. Le contexte compte énormément. Une fonction peut sembler vulnérable lorsqu’elle est analysée seule alors qu’un contrôle est effectué plus tôt dans l’application. À l’inverse, plusieurs composants parfaitement légitimes pris séparément peuvent devenir dangereux lorsqu’ils sont combinés.

Pour cette raison, Mantis cherche à construire une représentation plus générale du projet. Google indique notamment que le framework analyse l’historique du dépôt afin d’apprendre de précédentes corrections de sécurité et de construire progressivement une documentation sur l’architecture et le modèle de menace.

Pour limiter la quantité d’informations envoyées simultanément aux modèles, Mantis utilise également une organisation hiérarchique du contexte. Les fichiers peuvent être résumés au niveau de leurs dossiers, puis ces informations sont elles-mêmes condensées pour obtenir une vision globale du dépôt. Google affirme que cette technique a permis de réduire de plus de 85 % la quantité de contexte nécessaire tout en conservant les informations structurelles utiles.

Cette idée dépasse la cybersécurité. Dans beaucoup de projets utilisant l’IA, le problème n’est pas simplement d’envoyer davantage d’informations au modèle. Il faut surtout lui fournir le bon contexte au bon moment. Une documentation claire, un historique compréhensible et une architecture lisible deviennent donc utiles aux développeurs comme aux agents.

5. Reproduire les vulnérabilités dans un environnement isolé

Une vulnérabilité détectée par l’IA n’est pas automatiquement considérée comme vraie. Le framework prévoit des étapes permettant d’essayer de reproduire le comportement dans un environnement isolé. L’objectif est de passer d’une hypothèse — « ce code semble vulnérable » — à un résultat beaucoup plus exploitable : « nous avons réussi à reproduire le comportement dans ces conditions ».

Google présente justement les environnements sandboxés comme l’un des moyens utilisés pour améliorer la qualité des résultats et limiter les faux positifs. Pour vérifier certaines vulnérabilités, l’agent peut être amené à générer puis exécuter du code. Cette opération ne doit évidemment pas être réalisée directement sur un environnement contenant des données réelles ou donnant accès aux services de production.

La documentation officielle de Mantis est particulièrement claire sur ce point. Google recommande des environnements isolés et restreints, et déconseille explicitement de lancer ce type de code sur une machine possédant un accès aux systèmes de production, à des données sensibles ou au réseau interne.

Cette étape illustre une règle importante de l’utilisation professionnelle de l’IA : plus un agent devient autonome, plus son environnement d’exécution doit être contrôlé. L’automatisation ne supprime pas les règles de sécurité. Elle rend au contraire leur application encore plus importante.

6. De la détection à la proposition de correctif

Détecter une vulnérabilité n’est que le début du travail. Dans une application réelle, il faut ensuite déterminer pourquoi elle existe, mesurer ses conséquences et préparer une correction qui ne casse pas d’autres fonctionnalités. Mantis prévoit justement une étape dédiée à la préparation des correctifs.

La documentation décrit un agent capable d’appliquer une modification minimale puis de vérifier dans la sandbox que le problème reproduit précédemment n’est plus présent. C’est une évolution importante par rapport aux scanners de sécurité traditionnels. Un rapport indiquant «risque d’injection détecté dans ce fichier» reste utile, mais une analyse qui présente le problème, explique pourquoi il semble réel, montre comment il a été reproduit et propose une modification apporte beaucoup plus de contexte au développeur.

L’IA commence donc à intervenir non seulement dans la détection, mais également dans la remédiation. Cela ne signifie cependant pas que la modification doit être appliquée automatiquement en production. La correction peut affecter une règle métier, modifier des performances, introduire une incompatibilité ou déplacer le risque vers une autre partie du système.

7. Pourquoi la validation humaine reste indispensable

La documentation de Mantis insiste explicitement sur cette question. Les modèles d’IA sont non déterministes. Ils peuvent halluciner une vulnérabilité, interpréter incorrectement le fonctionnement d’une application ou générer un correctif erroné.

Pour cette raison, Google recommande notamment aux nouveaux utilisateurs de commencer avec un mode interactif. Lorsqu’une action sensible doit être effectuée — comme écrire dans des fichiers ou exécuter un code de reproduction — l’agent doit pouvoir s’arrêter et demander une validation humaine.

L’IA devient donc un outil d’assistance à la décision. Elle peut accélérer considérablement certaines analyses, mais elle ne doit pas devenir une source de confiance automatique.

8. Ce que cela change pour un SaaS ou un logiciel métier

Pour une entreprise qui développe une application, l’intérêt principal de Mantis n’est pas nécessairement d’installer immédiatement le framework. Le plus intéressant est probablement de regarder la direction prise par les outils de développement.

Prenons un SaaS maintenu pendant plusieurs années. De nouvelles fonctionnalités sont ajoutées, des développeurs interviennent successivement, les dépendances évoluent et certaines parties du code deviennent progressivement plus difficiles à comprendre. Dans ce contexte, des agents capables d’analyser l’historique du projet, de reconstruire une partie de son architecture et de rechercher continuellement certains comportements suspects peuvent apporter une aide importante.

Ils pourraient intervenir lors d’une revue de code, d’une évolution importante, d’une mise à jour de dépendance ou d’un contrôle avant déploiement. Ils peuvent aussi aider à prioriser les zones qui méritent une inspection humaine plus approfondie, documenter les chemins d’exécution et rapprocher un signalement d’une correction antérieure.

Mais cette évolution ne change pas une règle fondamentale : une IA ne peut pas compenser une architecture mal conçue. Une application sans séparation claire des permissions, sans tests suffisants ou sans maîtrise de ses dépendances restera difficile à sécuriser, quel que soit le nombre d’agents utilisés.

9. L’IA peut-elle remplacer un audit de sécurité ?

Non, du moins Mantis ne doit pas être présenté ainsi. La sécurité d’un produit logiciel ne se limite pas à rechercher certaines formes de code vulnérable. Une analyse complète peut nécessiter de comprendre l’architecture, les rôles et permissions, les données manipulées, les règles métier, l’infrastructure, les dépendances et les conditions réelles d’utilisation.

Certaines vulnérabilités n’existent qu’à cause d’une logique métier incorrecte. Le code peut être parfaitement valide du point de vue technique tout en permettant une action qui ne devrait jamais être autorisée. Un outil automatisé peut avoir beaucoup plus de difficultés à reconnaître ce type de problème s’il ne connaît pas précisément les règles de l’application.

Google recommande justement d’enrichir les analyses avec des informations humaines : documentation, exigences internes et connaissances spécifiques au projet. L’IA peut donc devenir un outil supplémentaire très performant, mais elle reste une couche parmi d’autres dans une stratégie de sécurité.

10. Les bonnes pratiques à retenir

Même sans utiliser Mantis directement, plusieurs enseignements peuvent déjà être appliqués à un projet professionnel. Une équipe humaine comme une IA comprend mieux un système lorsque les responsabilités de ses composants sont clairement définies. Une documentation maintenue évite aussi que des décisions importantes disparaissent avec le temps.

• Conserver un historique utile : Mantis s’appuie sur les corrections précédentes ; des changements lisibles et expliqués facilitent donc l’analyse future.
• Tester chaque correction : tests unitaires, intégration et non-régression restent essentiels pour vérifier qu’un correctif n’introduit pas un nouveau problème.
• Isoler tout code généré : une exécution automatique ne doit jamais disposer des mêmes accès que l’application de production.
• Limiter les permissions : réseau, fichiers, secrets, durée, mémoire et processeur doivent être réduits au strict nécessaire.
• Commencer petit : la documentation recommande des analyses limitées afin d’ajuster les filtres avant de scanner un dépôt entier.
• Exiger des éléments vérifiables : une alerte ne doit pas être considérée comme vraie uniquement parce qu’elle est formulée avec assurance.

Un historique Git correctement organisé possède une valeur qui dépasse la simple possibilité de revenir en arrière. Il documente les intentions, les compromis et les anciennes zones de risque. De la même manière, des tests reproductibles fournissent une base concrète pour évaluer un correctif proposé par un humain ou par une IA.

11. Mantis est-il prêt pour la production ?

La réponse demande une nuance importante. Mantis est bien disponible en open source et Google fournit des instructions permettant de commencer à l’utiliser avec différents agents de développement. Mais sa documentation ne recommande pas de lui donner librement accès à un système critique.

Google indique que Mantis doit être considéré comme un point de départ à adapter aux besoins et à l’environnement de chaque organisation. Pour des utilisations autonomes, la documentation décrit des mesures renforcées : environnement isolé, permissions limitées, réseau contrôlé et infrastructure dédiée.

Pour une TPE ou une PME, le principal enseignement n’est donc probablement pas «installez Mantis demain sur votre serveur». Il est plutôt que les outils de développement vont progressivement intégrer des capacités d’analyse et de vérification beaucoup plus avancées. Avant une adoption réelle, il faut définir le périmètre analysé, les données accessibles, les actions autorisées, les validations requises et la manière de contrôler les résultats.

12. Vers une sécurité davantage intégrée au développement

Pendant longtemps, la sécurité était parfois considérée comme une étape séparée. Une application était développée, puis contrôlée avant sa livraison. Les approches comme celle présentée par Google cherchent au contraire à intégrer davantage la sécurité directement dans le cycle de développement.

Google Cloud décrit une architecture où différents agents interviennent à plusieurs étapes du cycle logiciel, depuis la conception jusqu’à l’analyse du code. Une vulnérabilité pourrait être détectée lors d’une modification, analysée automatiquement, puis reproduite dans un environnement isolé. Une correction pourrait être proposée, les tests vérifier son comportement et un développeur examiner l’ensemble avant de valider la modification.

Le principe n’est plus uniquement «vérifier la sécurité de l’application une fois terminée». Il devient «intégrer progressivement les contrôles de sécurité au développement lui-même». Cette approche peut raccourcir le délai entre l’introduction d’un défaut et sa détection, tout en fournissant davantage de contexte à la personne qui doit prendre la décision finale.

13. Conclusion : automatiser l’analyse sans automatiser la confiance

Mantis illustre une évolution importante de l’intelligence artificielle appliquée au développement. Après la génération de code, la documentation ou les tests, les agents commencent à intervenir dans des tâches plus complexes : analyser une architecture, rechercher des vulnérabilités, confronter leurs propres résultats, reproduire des problèmes et préparer des correctifs.

Pour les développeurs, cette évolution peut devenir extrêmement utile. Une IA peut parcourir rapidement une base de code importante, apporter du contexte et attirer l’attention sur une modification ou un comportement qui mérite d’être examiné. Mais cette automatisation ne supprime pas les fondamentaux. Une application professionnelle reste dépendante de la qualité de son architecture, de ses tests, de la maîtrise de ses dépendances et du suivi effectué après sa mise en production.

Le futur de la sécurité assistée par IA ne repose probablement pas sur un modèle capable de tout faire seul. Il repose plutôt sur une succession de contrôles : analyser, confronter, reproduire, corriger, tester et valider. L’IA peut automatiser une grande partie de ce processus. La confiance, elle, doit continuer à être construite par la vérification.