IA et cybersécurité : peut-on vraiment automatiser l’audit de code source ?

Pendant longtemps, auditer le code source d’une application nécessitait de mobiliser des spécialistes capables de parcourir des milliers de lignes de code, de comprendre les mécanismes de sécurité et d’identifier les faiblesses susceptibles d’être exploitées. Des outils automatisés existaient déjà, mais leurs résultats demandaient souvent un important travail de vérification.
L’arrivée de l’intelligence artificielle change progressivement la donne. Certains outils ne se contentent plus de signaler une anomalie : ils tentent de comprendre le fonctionnement du code, d’expliquer pourquoi une portion de programme présente un risque et de proposer une correction.
Pour les entreprises, la perspective est intéressante. Une application métier peut comporter plusieurs centaines de milliers de lignes de code, accumulées au fil des évolutions. Pouvoir en analyser plus rapidement les parties sensibles représente un gain de temps potentiel considérable.
Mais une question demeure : peut-on réellement automatiser l’audit de sécurité d’une application sans passer à côté de vulnérabilités importantes ?

À retenir

L’intelligence artificielle peut accélérer l’analyse de sécurité du code source en aidant à repérer des vulnérabilités, à comprendre leurs causes et à préparer des correctifs. Elle est particulièrement intéressante pour les applications volumineuses ou anciennes, dont l’architecture est parfois difficile à appréhender.
Un audit automatisé ne garantit toutefois pas qu’une application est sécurisée. Les résultats doivent être vérifiés et confrontés à l’architecture réelle, aux règles métier et aux conditions d’exploitation. L’approche la plus fiable reste celle qui associe outils d’analyse, IA et expertise humaine.

L’audit de code source, un travail devenu plus complexe

Une application métier ne se résume plus à quelques fichiers développés par une seule équipe. Elle repose souvent sur plusieurs technologies, des bibliothèques externes, des API et des services qui communiquent entre eux. Prenons le cas d’un ERP développé sur mesure. Une fonctionnalité de facturation peut solliciter plusieurs composants : gestion des utilisateurs, calcul des montants, accès à la base de données, génération de documents et transmission à un service externe. Une faiblesse dans l’un de ces mécanismes peut avoir des conséquences sur l’ensemble du processus. Le problème est qu’une vulnérabilité n’apparaît pas toujours sous la forme d’une erreur évidente. Une application peut fonctionner parfaitement pour ses utilisateurs tout en autorisant, dans certaines conditions, l’accès à des informations qui devraient rester confidentielles.
C’est notamment le cas des défauts de contrôle d’accès. Une API peut vérifier qu’un utilisateur est authentifié, mais oublier de contrôler s’il est autorisé à consulter le document demandé. Le code ne provoque aucune erreur. Pourtant, un utilisateur pourrait potentiellement récupérer un document appartenant à un autre compte en modifiant simplement un identifiant dans sa requête. Identifier ce type de faiblesse suppose de comprendre comment les différentes parties de l’application interagissent. Sur un projet important, ce travail peut rapidement devenir complexe.

Les outils d’analyse automatique existaient bien avant l’IA

L’intelligence artificielle n’a pas inventé l’audit automatisé du code source. Les outils d’analyse statique, généralement désignés par l’acronyme SAST (Static Application Security Testing), sont utilisés depuis longtemps pour examiner le code sans exécuter l’application. Ils recherchent notamment des constructions dangereuses, des traitements insuffisamment sécurisés ou des erreurs de programmation susceptibles d’introduire des vulnérabilités. D’autres outils, spécialisés dans l’analyse des dépendances logicielles, vérifient si les bibliothèques utilisées par une application comportent des vulnérabilités connues.

Ces mécanismes restent indispensables. Leur principale limite tient au fait qu’une alerte ne correspond pas nécessairement à une faille réellement exploitable. Un scanner peut signaler une requête SQL potentiellement dangereuse alors que les paramètres sont correctement protégés par un mécanisme situé ailleurs dans le code. À l’inverse, une erreur de logique métier peut passer inaperçue parce qu’elle ne correspond à aucune règle de détection classique. Les développeurs doivent alors examiner les résultats, comprendre leur contexte et distinguer les problèmes réels des alertes sans conséquence. C’est sur cette phase d’interprétation que l’IA peut apporter une valeur supplémentaire.

Ce que l’IA apporte réellement à l’audit de sécurité

La différence ne réside pas uniquement dans la vitesse d’analyse. Elle concerne surtout la capacité des nouveaux outils à rapprocher plusieurs éléments du code pour tenter d’en comprendre le fonctionnement. Un modèle spécialisé peut examiner une fonction, rechercher comment elle est appelée et analyser les contrôles appliqués aux données avant leur traitement. Il peut également expliquer une alerte dans un langage compréhensible, suggérer des pistes de correction ou aider un développeur à identifier les parties du programme concernées.

Imaginons une application dans laquelle un utilisateur peut modifier les informations d’un client. La fonction vérifie correctement l’identité de la personne connectée, mais ne contrôle pas systématiquement si cette personne dispose des droits nécessaires sur le dossier concerné. Une analyse assistée par IA peut contribuer à repérer cette incohérence en étudiant le chemin parcouru par la requête et les mécanismes d’autorisation utilisés dans d’autres parties de l’application.

Ce type d’analyse est intéressant parce que les vulnérabilités ne se trouvent pas toujours dans une seule ligne de code. Elles peuvent résulter de plusieurs décisions techniques qui, prises séparément, semblent parfaitement normales. Il faut néanmoins rester prudent. Les modèles d’IA peuvent mal interpréter certaines fonctions, ignorer des protections existantes ou inventer des relations entre composants. Leurs conclusions doivent donc être considérées comme des hypothèses à vérifier, et non comme des preuves.

Des agents IA capables de rechercher des vulnérabilités

L’évolution la plus marquante concerne probablement l’arrivée des agents IA spécialisés dans la sécurité du code. Contrairement à un outil qui se contente de produire un rapport, un agent peut enchaîner plusieurs opérations. Il explore une partie du projet, identifie un comportement suspect, examine les fonctions associées et cherche à vérifier si le problème peut réellement être exploité. Certains systèmes peuvent également préparer un correctif et lancer des tests dans un environnement isolé.

Cette approche intéresse particulièrement les équipes qui maintiennent des applications complexes. Lorsqu’une vulnérabilité est découverte dans une fonction utilisée à plusieurs endroits, retrouver toutes les parties concernées peut demander un travail considérable. Un agent peut faciliter cette investigation en parcourant les dépendances internes et en proposant une première analyse de l’impact.

Les travaux menés par Google autour de la recherche automatisée de vulnérabilités illustrent cette évolution. L’objectif n’est plus seulement de détecter des erreurs déjà répertoriées, mais d’utiliser des systèmes capables d’examiner des comportements logiciels et d’aider à découvrir des faiblesses jusque-là inconnues.

Pour autant, un agent qui propose une correction n’est pas nécessairement capable d’en mesurer toutes les conséquences. Modifier une fonction d’authentification, un mécanisme de gestion des droits ou une règle de validation métier peut résoudre une vulnérabilité tout en provoquant des régressions ailleurs dans l’application. L’automatisation doit donc s’accompagner de tests, d’une revue du code et d’un processus de validation avant toute mise en production.

L’IA peut-elle découvrir des failles que les scanners classiques ne détectent pas ?

C’est possible, et c’est précisément l’un des domaines dans lesquels les recherches progressent. Les outils traditionnels sont particulièrement efficaces lorsqu’ils recherchent des problèmes correspondant à des règles connues. Les modèles d’IA peuvent adopter une approche différente en analysant des comportements et en formulant des hypothèses sur les risques potentiels. Ils peuvent ainsi contribuer à identifier certaines incohérences dans les contrôles d’accès, dans la manipulation des données ou dans l’enchaînement des opérations.

Mais découvrir une anomalie ne signifie pas avoir démontré une vulnérabilité. Une portion de code peut sembler dangereuse lorsqu’elle est examinée isolément, alors qu’un contrôle effectué en amont empêche toute exploitation. Inversement, une faille peut dépendre d’une règle métier très particulière que le modèle ne connaît pas. La valeur de l’IA dépend donc largement du contexte auquel elle a accès et de la qualité des vérifications réalisées après son analyse. Une vulnérabilité doit être confirmée, pas simplement annoncée par un outil.

Pourquoi l’audit de sécurité ne peut pas être entièrement confié à l’IA

Un audit de code source n’est qu’une partie de l’évaluation de la sécurité d’une application. Une plateforme peut disposer d’un code correctement développé et présenter malgré tout des risques importants à cause de son environnement d’hébergement. Un serveur mal configuré, une interface d’administration exposée sur Internet ou des permissions excessives peuvent créer des possibilités d’attaque qui ne seront pas nécessairement visibles dans le dépôt de code.

Les règles métier constituent une autre limite. Prenons une application de gestion financière. Une opération peut être parfaitement sécurisée sur le plan technique, mais autoriser un collaborateur à valider une transaction qu’il a lui-même créée, alors que la procédure interne exige une double validation. Pour identifier cette faiblesse, il faut connaître l’organisation de l’entreprise et comprendre le processus métier attendu.

Une IA peut assister l’analyse si ces informations lui sont fournies. Elle ne peut cependant pas deviner de manière fiable toutes les règles internes qui ne sont ni documentées ni représentées dans le code. C’est pourquoi un audit sérieux doit conserver une approche globale. Il doit tenir compte du code source, de l’architecture, des configurations, des droits d’accès et des conditions réelles d’utilisation.

Les faux positifs : un problème que l’IA ne fait pas disparaître

Les équipes de développement connaissent bien cette situation : un outil d’analyse signale des dizaines de problèmes, mais une partie des alertes ne correspond pas à des vulnérabilités exploitables. On parle alors de faux positifs. À l’inverse, lorsqu’un outil ne détecte pas une vulnérabilité existante, il s’agit d’un faux négatif. Ces deux limites concernent également les systèmes d’intelligence artificielle.

Un modèle peut produire une explication techniquement convaincante à propos d’une vulnérabilité qui n’existe pas. Il peut aussi passer à côté d’un problème réel parce qu’il ne dispose pas de suffisamment d’informations sur le fonctionnement de l’application. La qualité d’un audit ne devrait donc pas être évaluée uniquement à partir du nombre d’alertes générées. Pour une entreprise, l’essentiel est de savoir quelles faiblesses sont réellement présentes, quel risque elles représentent et quelles corrections doivent être réalisées en priorité.

L’IA peut aider à réduire le temps consacré au tri des résultats. Mais cette amélioration doit être mesurée sur des cas concrets, avec des vulnérabilités confirmées et des tests reproductibles.

Auditer son code avec une IA : attention à la confidentialité

Les équipes de développement connaissent bien cette situation : un outil d’analyse signale des dizaines de problèmes, mais une partie des alertes ne correspond pas à des vulnérabilités exploitables. On parle alors de faux positifs. À l’inverse, lorsqu’un outil ne détecte pas une vulnérabilité existante, il s’agit d’un faux négatif. Ces deux limites concernent également les systèmes d’intelligence artificielle.

Un modèle peut produire une explication techniquement convaincante à propos d’une vulnérabilité qui n’existe pas. Il peut aussi passer à côté d’un problème réel parce qu’il ne dispose pas de suffisamment d’informations sur le fonctionnement de l’application. La qualité d’un audit ne devrait donc pas être évaluée uniquement à partir du nombre d’alertes générées. Pour une entreprise, l’essentiel est de savoir quelles faiblesses sont réellement présentes, quel risque elles représentent et quelles corrections doivent être réalisées en priorité.

L’IA peut aider à réduire le temps consacré au tri des résultats. Mais cette amélioration doit être mesurée sur des cas concrets, avec des vulnérabilités confirmées et des tests reproductibles.

Auditer son code avec une IA : attention à la confidentialité

L’utilisation d’une intelligence artificielle externe pour analyser du code source soulève également des questions de confidentialité. Le code d’une application métier représente souvent une partie importante du savoir-faire de l’entreprise. Il peut révéler son architecture, ses processus internes, ses intégrations avec d’autres systèmes ou certaines règles commerciales sensibles.

Avant de transmettre un dépôt à un outil d’IA, il est donc nécessaire de vérifier comment les données sont traitées, où elles sont hébergées et quelles garanties contractuelles encadrent leur utilisation. La question des permissions est tout aussi importante. Un outil chargé de réaliser une analyse n’a pas nécessairement besoin d’un accès en écriture au dépôt. De la même manière, un agent autorisé à exécuter des commandes doit fonctionner dans un environnement contrôlé.

L’intégration de l’IA dans les processus de sécurité doit respecter les mêmes principes que les autres outils informatiques : limitation des accès, traçabilité des opérations et protection des informations sensibles.

Comment intégrer l’IA dans un processus DevSecOps ?

Pour les entreprises qui disposent déjà d’une chaîne d’intégration continue, l’approche la plus intéressante consiste souvent à enrichir les contrôles existants plutôt qu’à les remplacer. Lorsqu’un développeur propose une modification, le pipeline CI/CD peut lancer automatiquement des tests et des analyses de sécurité. Les outils SAST examinent le code, tandis que les outils SCA vérifient les dépendances.

L’IA peut ensuite intervenir pour faciliter l’interprétation de certaines alertes, examiner des changements complexes ou proposer des corrections. Les problèmes les plus sensibles sont transmis à un développeur ou à un spécialiste de la sécurité pour validation.

Cette organisation permet d’identifier les vulnérabilités plus tôt dans le cycle de développement, lorsqu’elles sont généralement moins coûteuses à corriger. Elle évite également de concentrer tous les contrôles de sécurité à la fin du projet, quelques jours avant la mise en production. L’objectif n’est pas d’ajouter systématiquement davantage d’outils, mais de rendre les contrôles existants plus efficaces et plus faciles à exploiter par les équipes.

Et pour les applications anciennes ?

Les applications legacy représentent un terrain particulièrement intéressant pour l’analyse assistée par IA. Certaines ont été développées pendant plus de dix ans, parfois par plusieurs équipes successives. La documentation est incomplète, les dépendances ont évolué et certaines règles métier ne sont connues que par les collaborateurs historiques. Avant même de rechercher des vulnérabilités, il faut parfois comprendre l’organisation du code.

L’IA peut aider à explorer ces projets, à expliquer certaines fonctions et à reconstituer une partie des relations entre les composants. Elle peut également assister les équipes dans l’identification des zones les plus sensibles, notamment celles qui manipulent des données personnelles, des fichiers ou des mécanismes d’authentification.

Mais elle ne résout pas automatiquement les contraintes liées aux technologies obsolètes. Lorsqu’une vulnérabilité concerne un framework qui n’est plus maintenu, la correction peut nécessiter une mise à niveau importante, voire une migration partielle de l’application. L’audit de sécurité devient alors un point de départ pour une réflexion plus large sur la modernisation du logiciel.

Vers des audits de sécurité plus rapides et plus continus

L’intelligence artificielle devrait progressivement modifier la manière dont les entreprises organisent leurs audits applicatifs. Aujourd’hui encore, certaines organisations réalisent une analyse de sécurité principalement avant une mise en production importante ou à l’occasion d’un audit ponctuel. Or, une application évolue en permanence. Chaque nouvelle fonctionnalité, chaque dépendance ajoutée et chaque modification de configuration peuvent introduire de nouveaux risques.

L’automatisation permet de rapprocher les contrôles de sécurité du développement quotidien. L’IA peut contribuer à cette évolution en aidant les équipes à comprendre les alertes, à prioriser les investigations et à préparer certaines corrections.

Cela ne signifie pas que les audits approfondis ou les tests d’intrusion deviennent inutiles. Ils restent nécessaires pour examiner des scénarios complexes et évaluer des risques qui dépassent la simple analyse du code. L’enjeu est plutôt de combiner une surveillance technique régulière avec des évaluations plus approfondies lorsque le niveau de risque le justifie.

Conclusion : l’IA transforme l’audit de code, mais ne remplace pas l’expertise

L’intelligence artificielle apporte de nouvelles possibilités à la cybersécurité applicative. Elle peut faciliter l’analyse de projets volumineux, aider à détecter certaines faiblesses et réduire le temps nécessaire à la compréhension et à la correction de problèmes techniques. Pour les entreprises, cette évolution représente une opportunité d’intégrer davantage de contrôles de sécurité dans leurs processus de développement.

Mais la fiabilité d’un audit ne repose pas uniquement sur la puissance de l’outil utilisé. Comprendre les règles métier, évaluer l’exposition réelle d’une vulnérabilité, vérifier les correctifs et anticiper les conséquences d’une modification nécessitent toujours une expertise technique. L’avenir de l’audit de code source repose donc moins sur une automatisation totale que sur une collaboration efficace entre intelligence artificielle, développeurs et spécialistes de la cybersécurité.

Votre application métier présente-t-elle des risques de sécurité ?

Euro Tech Conseil accompagne les entreprises dans l’audit de code source, l’analyse des vulnérabilités, la sécurisation des applications et la modernisation de logiciels existants. Qu’il s’agisse d’une application web développée sur mesure ou d’un environnement historique, l’objectif est d’identifier les faiblesses techniques, d’évaluer leur impact et de définir les corrections prioritaires.

Vous souhaitez faire analyser votre application ?