Sécuriser une application métier développée avec l’IA : le risque s’est déplacé du réseau vers le code

Une part croissante du code qui fait tourner les applications métier n’est plus écrite ligne à ligne par un développeur. Elle est produite avec un agent, un assistant, un modèle qui complète, propose, génère. Le gain de vitesse est réel et il ne se discute plus. Ce qui se discute, c’est la répartition du risque : les hypothèses de sécurité héritées d’une époque où un prestataire écrivait le code et où le service informatique protégeait le réseau ne tiennent plus. Le responsable qui valide ce qui part en production hérite d’un risque dont le centre de gravité a bougé, sans que personne ne l’ait décidé.

Le réflexe serait d’ajouter une couche : un pare-feu de plus, un audit réseau, une revue des accès. Ce réflexe protège un périmètre qui n’est plus celui par lequel le risque entre. Quand une équipe développe avec l’IA, la surface exposée n’est pas le réseau, c’est ce qui entre dans la base de code : le code généré, les dépendances tirées pour aller vite, le pipeline qui transforme ce code en logiciel exécutable. Le risque a quitté la frontière extérieure pour s’installer dans la chaîne d’approvisionnement logicielle. Le sécuriser suppose de le gouverner là.

Cet article situe où le risque se loge réellement dans un développement assisté par l’IA, et ce que le gouverner exige sur trois fronts : le code que produit l’IA, les dépendances qu’elle mobilise, le pipeline qui la met en production. Chacun de ces fronts appelle une décision de gouvernance, pas un outil miracle. Et l’enjeu, pour qui pilote cette production, est de rendre ce risque mesurable sans devenir le frein d’une équipe qui, elle, a gagné en vitesse.

Le risque a changé de camp : pourquoi le modèle réseau ne protège plus

Pendant vingt ans, sécuriser une application métier a d’abord voulu dire sécuriser son environnement : pare-feu, réseau privé virtuel (VPN), gestion des accès, cloisonnement des systèmes. Ce modèle reste nécessaire, il ne devient pas faux. Mais il répond à une question, comment empêcher un intrus d’atteindre le système, qui n’est plus ni la seule ni la principale.

Le déplacement est documenté. L’agence de l’Union européenne pour la cybersécurité (ENISA) le formule sans détour dans son analyse des attaques de la chaîne d’approvisionnement : une protection périmétrique solide ne suffit plus dès lors que l’attaquant s’intéresse aux fournisseurs, et une organisation peut être vulnérable même quand ses propres défenses sont bonnes. La faille n’entre plus par la porte que l’on garde, elle entre par ce que l’on assemble.

Le développement assisté par l’IA amplifie ce déplacement. Un agent produit du code et mobilise des composants à un rythme et dans un volume qui dépassent la relecture manuelle. La chaîne d’approvisionnement logicielle, c’est-à-dire l’ensemble de ce qui entre dans un logiciel avant qu’il ne s’exécute (le code écrit, les bibliothèques tierces, les outils qui construisent l’application), devient la surface à surveiller. Elle couvre tout le cycle de vie d’une application conçue avec une IA agentic, de la première ligne suggérée jusqu’à la mise en service.

Pour un directeur des systèmes d’information (DSI) comme pour une direction qui pilote cette production, la conséquence est concrète. Le tableau de bord sécurité ne peut plus se limiter aux accès et au réseau. Il doit intégrer ce qui se passe en amont, dans la fabrique du logiciel, là où le code prend forme et où les composants s’agrègent.

Le code généré : plausible n’est pas sûr

Un agent génère du code qui compile, passe les tests visibles et ressemble à s’y méprendre à du bon code. Cette plausibilité est précisément ce qui endort la vigilance : rien, dans l’apparence d’un extrait, ne signale qu’il porte une faille.

Le fait est mesuré. Les modèles de génération apprennent sur d’immenses volumes de code public, qui contient aussi du code vulnérable. Une étude présentée à l’IEEE Symposium on Security and Privacy (Pearce et al., 2022) a soumis un assistant de génération à quatre-vingt-neuf scénarios construits autour des faiblesses les plus dangereuses répertoriées par le référentiel CWE (Common Weakness Enumeration, la nomenclature de référence des types de failles logicielles). Sur les 1 689 programmes produits, près de 40 % contenaient une vulnérabilité. Le chiffre porte sur un protocole précis, pas sur une vérité universelle, mais l’ordre de grandeur suffit à poser le problème : la sortie d’un agent n’est pas sûre par défaut.

Un travail complémentaire pointe un effet plus insidieux encore. Une étude de Stanford (Perry et al., 2023) a montré que les développeurs disposant d’un assistant IA écrivaient un code moins sûr que ceux qui s’en passaient, tout en étant plus convaincus d’avoir produit du code sûr. Cette fausse confiance est le vrai danger pour une direction : elle rend le risque invisible à ceux-là mêmes qui le produisent, et fait tomber la vigilance au moment où elle serait le plus utile.

La réponse tient dans un principe de gouvernance simple. La revue de code n’est plus une option de confort, elle redevient un maillon de sécurité. Non pas une relecture ligne à ligne de tout, impraticable au volume de l’IA, mais une revue ciblée sur les surfaces sensibles : traitement des entrées, gestion des secrets, authentification, appels vers l’extérieur. La compétence n’est pas de savoir écrire le code, elle est de savoir lire et interroger ce qu’une machine a écrit, en gardant à l’esprit que la solidité structurelle du code est indissociable de sa sécurité. Pratiquer les mêmes outils côté production, chaque jour, est ce qui permet de savoir où regarder.

Les dépendances : l’angle mort de la chaîne logicielle

Pour aller vite, un développeur, ou l’agent qui l’assiste, tire un paquet tiers plutôt que de réécrire une fonction. C’est légitime et c’est massif. Mais la provenance et l’état de sécurité de ce paquet sont rarement vérifiés au moment où il entre dans le projet.

Le référentiel OWASP classe les composants vulnérables et obsolètes parmi les dix principaux risques applicatifs. Le point qu’il souligne est simple et souvent ignoré : vous héritez du risque d’un code que vous n’avez pas écrit, et une seule dépendance non corrigée peut exposer toute l’application, d’autant que ces composants s’exécutent en général avec les mêmes privilèges qu’elle. S’y ajoute une réalité peu regardée : une bibliothèque en tire d’autres, ses dépendances transitives, si bien que la surface réelle est bien plus large que la liste des paquets choisis explicitement.

Le contexte IA-augmenté ouvre en outre une porte inédite. Dans son panorama des menaces 2025, l’ENISA documente le ciblage de la chaîne d’approvisionnement par des paquets piégés et signale des vecteurs directement liés aux assistants de développement, jusqu’à l’injection d’instructions malveillantes dans leurs fichiers de configuration. Quand un modèle suggère un nom de composant, rien ne garantit que ce composant est légitime, ni même qu’il existait avant qu’un attaquant ne l’enregistre pour capter une suggestion attendue.

Gouverner les dépendances, c’est instaurer trois disciplines. Connaître ce qui entre, par un inventaire des composants et de leurs versions, jusqu’aux dépendances transitives. Vérifier leur état, par une analyse de composition logicielle (en anglais software composition analysis, SCA), qui confronte l’arbre des dépendances aux bases de vulnérabilités connues. Réduire la surface, en privilégiant les sources officielles et les paquets signés, et en retirant ce qui ne sert pas. Rien de paralysant ici : de l’hygiène outillée, intégrée au flux de travail plutôt que reléguée à un contrôle de fin de parcours.

Le pipeline de build : gouverner ce qui s’exécute

Le pipeline d’intégration continue (en anglais continuous integration, CI, la chaîne automatisée qui compile, teste et assemble le logiciel) est le moment où le code devient un artefact exécutable. C’est aussi le front le moins surveillé des trois.

Un pipeline s’exécute souvent avec des droits étendus, manipule des secrets comme des clés et des jetons d’accès, et exécute des étapes tierces téléchargées depuis l’extérieur. En contexte IA-augmenté, l’agent touche parfois lui-même à la configuration de cette chaîne. Chacune de ces caractéristiques est une prise pour un attaquant : compromettre une seule étape de build peut suffire à insérer du code dans tout ce qui sort du pipeline, sans jamais toucher au code source qui a été relu. C’est le point où faire tenir en production un prototype produit avec l’IA devient un métier distinct de sa mise au point.

Le terrain est cadré. Le référentiel de développement logiciel sécurisé publié par le NIST (l’institut de normalisation américain), le SSDF (Secure Software Development Framework, publication SP 800-218), recommande d’intégrer la sécurité tout au long du cycle de développement plutôt que de la reléguer à un contrôle final. Il insiste sur l’intégrité des composants et de leur provenance, et fait de l’environnement de build lui-même un objet à sécuriser. Sa logique est celle d’une direction, pas d’un poste technique : définir des pratiques, les rendre vérifiables, les tenir dans la durée.

En pratique, gouverner le pipeline revient à appliquer le principe du moindre privilège, en n’accordant à chaque étape que les droits strictement nécessaires, à isoler les secrets, à contrôler ce qui s’exécute et depuis quelles sources, et à tracer la provenance des artefacts produits. C’est le front à plus fort effet de levier : peu visible, il conditionne la confiance dans tout le reste, car un code relu avec soin ne vaut plus rien s’il transite par une fabrique ouverte.

La sécurité, condition de la vitesse

Le périmètre de la sécurité applicative a bougé. Tant qu’une application était écrite à la main par un prestataire et exploitée derrière un réseau gardé, protéger la frontière avait du sens. Dès lors que le code est produit avec l’IA, à un rythme qui dépasse la relecture, le risque s’installe là où le logiciel se fabrique : dans le code généré, dans les dépendances mobilisées, dans le pipeline qui met le tout en production. Ajouter une couche réseau ne protège pas cette surface.

Sécuriser une application métier développée avec l’IA tient alors moins à l’outillage qu’à une décision : traiter la fabrique du logiciel comme une surface à gouverner, avec le sérieux qu’on réservait autrefois au réseau. Une posture à la portée de toute organisation qui choisit d’objectiver le risque en amont, plutôt que de le découvrir en production.

Pour la direction qui pilote un développement IA-augmenté, l’enjeu final tient en une phrase : rendre ce risque mesurable sans reprendre à l’équipe la vitesse qu’elle a gagnée. La sécurité, ici, ne s’oppose pas à la productivité de l’IA. Elle est la condition pour que cette productivité tienne en production.