Il existe une hypothèse rarement remise en question derrière l’enthousiasme actuel autour des agents d’IA : l’idée que, si l’IA peut écrire du code, il suffit de la connecter à l’environnement de développement pour en récolter les gains de productivité.
Mais je constate que nous sous-estimons un détail important. Plus on accorde d’autonomie à ces systèmes, plus leur surface d’influence devient vaste.
Un développeur sait distinguer, au moins en théorie, entre instructions, commentaires, journaux, documentation, messages de commit, tickets et code exécutable. Un agent d’IA ne perçoit pas nécessairement ces frontières de la même façon. Tout peut devenir contexte. Tout peut influencer une décision.
Cela change la nature du problème. Pendant des décennies, la sécurité logiciel s’est concentrée sur la protection des systèmes contre des entrées malveillantes capables de compromettre les applications. Désormais, nous entrons dans un scénario différent : l’interprétation du contexte elle-même peut devenir l’objet d’une manipulation.
Il existe même un nom pour une partie de ce phénomène : l’injection de prompt. Des instructions cachées dans des documents, des tickets, des pages web, des bases de données de type RAG ou des commentaires de code peuvent influencer le comportement des agents de manière difficile à prévoir.
Il n’est pas difficile d’imaginer ce qui se produit lorsque des agents commencent à consommer automatiquement de la documentation, des dépôts, des journaux, des wikis d’entreprise et des dizaines d’autres sources d’information.
Le défi n’est plus seulement « le code est-il correct ? », mais « pouvons-nous faire confiance à tout ce qui a influencé la génération de ce code ? ». Et c’est une question bien plus difficile.
Ce qui retient mon attention, c’est que la majeure partie du récit actuel sur la productivité suppose des environnements presque parfaits, avec des données fiables, une documentation à jour, des processus organisés et des utilisateurs bien intentionnés.
Mais les entreprises réelles opèrent rarement dans ces conditions. Les dépôts accumulent des années de dette technique. La documentation devient désuète. Les processus changent. Des personnes commettent des erreurs. Et, dans certains cas, il existe des agents malveillants qui cherchent précisément à exploiter ces fragilités.
Le risque ne provient pas nécessairement d’une attaque sophistiquée. Souvent, il vient simplement d’informations incorrectes qui passent à être traitées comme vraies par l’agent.
Plus nous dépendons de l’IA pour prendre des décisions dans cet environnement, plus nous devons investir dans la gouvernance, l’observabilité, la validation et des mécanismes capables de différencier les sources plus fiables des sources moins fiables.
Cela ne signifie pas que la programmation assistée par IA cessera de fonctionner. Cela signifie simplement que le débat mûrit.
L’avenir de l’ingénierie logicielle ne consiste pas seulement à ajouter davantage d’agents. Il s’agit de construire des agents qui savent en qui avoir confiance. Car générer du code devient de plus en plus facile. Ce qui demeure difficile, c’est de décider quelles informations doivent influencer ce code.
