Impacts de l'utilisation à outrance des assistants IA dans le développement logiciel

Ces dernières années, l'industrie du développement logiciel n'a cessé de subir des transformations structurelles profondes. L'intégration de nouveaux outils LLM (modèles de langage massifs) pour la production massive de code (GitHub Copilot, OpenAI, Claude, etc.), qui était une pratique marginale, est aujourd'hui devenue la norme de l'industrie. Les entreprises de développement logiciel se sont lancées dans une course effrénée à la productivité et à la réduction des coûts ; pour cela, elles incitent et souvent même contraignent les développeurs à déléguer le plus possible la rédaction du code aux agents IA et à se contenter d'être des superviseurs de ces agents.

En effet, la vitesse d'adoption de ces nouvelles technologies est telle que les développeurs n'arrivent plus à suivre et sont de plus en plus relégués au rang d'éditeurs de textes/codes dont ils ne peuvent garantir la logique ou la sécurité. Fort de ce constat, une question émerge : Est-il acceptable, d'un point de vue moral, qu'un développeur puisse mettre en production du code généré par un assistant IA et qu'il ne maîtrise pas entièrement ?

Dans ce rapport, nous prouverons que cette pratique est dangereuse et irresponsable en recourant à des notions conjointes d'éthique, de morale et de droit. Nous démontrerons que le fait de normaliser le déploiement aveugle du code par les développeurs est une fuite en avant, un abandon de notre agence et de notre devoir moral en tant qu'êtres humains. Bien que l'argument classique mette en avant le gain de productivité pour justifier l'usage aveugle des assistants IA, cette vision s'effondre dès que l'on mesure la perte de contrôle de l'humain sur la machine. En réalité, cette efficacité immédiate cache des conséquences graves à moyen et long terme : elle engendre une paresse intellectuelle, une stagnation, voire une régression des compétences techniques chez les développeurs.

1. Le cadre technique et l'illusion de la neutralité

Dans un premier temps, il est nécessaire de définir avec rigueur de quoi il s'agit quand on parle d'assistant de code IA. Ces outils ne sont pas des agents dotés de raison ou encore des experts en cybersécurité ou cybercriminalité. Il ne s'agit que d'un engin statistique qui a été entraîné sur des milliards et milliards de lignes de code dont la plupart sont publiques et donc non contrôlées. Cet outil d'apparence complexe n'a en fait qu'une seule fonction principale, qui est de prédire le prochain jeton (token) en fonction du contexte fourni par le développeur.

Par conséquent, quand il s'agit de valider la logique ou encore de s'assurer des normes de sécurité des lignes de code que ce dernier produit, cet outil est totalement inadapté et aveugle sur ces sujets. Ainsi, ce code généré, qui a l'air d'être parfait au premier abord, contient quelquefois des failles de sécurité ou ne tient pas compte du contexte global de l'application ou de la logique d'affaires de l'entreprise. On peut y voir une sorte de sophisme naturel identifié par David Hume dans ce sens où : Puisque l'IA produit massivement du code syntaxiquement fonctionnel et que l'industrie adopte cet outil, alors il est légitime et obligatoire de déployer ce code pour rester compétitif. Ce qui est faux, car la syntaxe peut être correcte, mais le code inadapté et faillible.

Dans le développement de logiciels, ce sophisme occulte plusieurs risques techniques majeurs :

La sécurité des bases de données : L'IA, cherchant la solution la plus fréquente dans ses données d'entraînement, génère régulièrement des requêtes brutes hautement vulnérables aux injections SQL, mettant en péril l'intégrité des données personnelles des utilisateurs.
Le contrôle d'accès : Les modèles omettent fréquemment les validations de sessions complexes, introduisant des failles logiques permettant à un attaquant de consulter ou modifier les données privées d'autrui par simple manipulation d'identifiants dans l'URL.
La gestion financière : Lors de l'intégration d'API de paiement sensibles (PayPal, Stripe, etc.), les assistants omettent souvent les vérifications cryptographiques des signatures de webhooks, ouvrant la voie à des falsifications de transactions où un acteur malveillant peut simuler un achat réussi.

2. Devoir de responsabilité et prudence du développeur

Le déploiement de scripts opaques dont on ne maîtrise ni les tenants ni les aboutissants viole de manière flagrante les principes sur lesquels reposent la pratique de l'ingénierie et ceux de la Déclaration de Montréal pour un développement responsable de l'IA.

2.1 Le principe de la responsabilité sur le plan moral

Si nous nous basons sur les écrits de Fischer et Ravizza dans Responsibility and Control: A Theory of Moral Responsibility, la responsabilité morale d'un agent est engagée à partir du moment où il remplit ces trois conditions : il initie l'action, il le fait intentionnellement et il en a le contrôle (il comprend les tenants et les aboutissants et a le choix d'agir autrement).

Ainsi, quand un programmeur copie et colle un bloc de code qui a été généré par un assistant IA et qu'il ne maîtrise pas entièrement, il brise de ce fait la chaîne de responsabilité. Dès lors, en cas de faille du code en production, le programmeur dira que la compagnie encourage l'utilisation des assistants IA et que c'est en les utilisant que l'erreur est survenue. De son côté, n'ayant aucune mauvaise intention, lui non plus ne sera pas imputable et pourra s'extraire de sa responsabilité morale en blâmant l'opacité du fonctionnement des assistants IA. Le fait de déléguer intentionnellement la rédaction d'un code critique à une IA n'est pas éthiquement défendable, car il s'agit d'une tentative délibérée de déployer du code sans en assumer la responsabilité en cas de défaillance. Ces assistants ne pouvant être tenus responsables, car n'étant pas des agents moraux, l'humain est le dernier rempart moral au moment de déployer le code.

2.2 Le principe de prudence et de vigilance

Dans la Déclaration de Montréal, l'un des principes est qu'il faut faire preuve de prudence et de vigilance permanente quand on développe ou utilise les outils liés à l'IA pour éviter tout risque systémique. Dans une société informatisée comme la nôtre, le développement logiciel impacte tous les segments de la société, des plus banals aux plus critiques (banques, hôpitaux, etc.). Normaliser l'utilisation des assistants IA pour le déploiement du code est une tentative de remplacer l'examen rationnel du développeur et son analyse minutieuse par un gain apparent de productivité d'un algorithme prédictif, et cela viole le devoir de prudence prôné par la Déclaration de Montréal.

Nous parlons de gain apparent, car les dégâts que peuvent causer ces agents IA peuvent réduire à néant le temps qui aura été sauvé au départ par une erreur qui prendra plus de temps à réparer. Les compagnies qui ont adopté ces IA trop rapidement et trop aveuglément commencent à s'en rendre compte et essaient tant bien que mal de rectifier le tir progressivement. Le développeur n'est pas dédouané de ses responsabilités pour autant : il a pour devoir et obligation d'anticiper le pire scénario à chaque fois et ne peut abdiquer cette vérification sous prétexte qu'il veut produire plus de code. Il s'agit d'une faute éthique grave s'il ne le fait pas, et cela doit lui être imputé.

2.3 Atrophie des compétences et décalage prométhéen entre le développeur et le logiciel

Aristote a défini le terme habitus comme étant le fait de répéter des actions vertueuses tellement souvent que cela devient une seconde nature. Ainsi, un développeur ne peut pas se contenter de faire du copier-coller à longueur de journée et espérer développer son jugement ou ses compétences. L'effort cognitif quotidien que doit fournir le développeur pour résoudre les problèmes techniques qu'il rencontre est annulé par l'usage des LLM. Cela engendre une paresse intellectuelle qui sera dommageable à moyen et long terme pour lui-même, l'entreprise et finalement la société dans son ensemble. Plus le temps passe, plus ils ne seront plus que des prompteurs incapables de résoudre les problèmes du quotidien sans recourir à l'aide des assistants IA.

Günther Anders, dans son livre L'obsolescence de l'homme, a théorisé le concept de décalage prométhéen comme le niveau où la machine devient tellement complexe qu'elle échappe au contrôle de son concepteur. En effet, la même asymétrie s'observe dans le développement logiciel avec des développeurs qui créent des systèmes de plus en plus complexes, mais qui en ont de moins en moins le contrôle et, par conséquent, ne peuvent plus anticiper entièrement les conséquences morales dévastatrices du code qu'ils déploient (fuites massives de données, détournements de fonds, piratage des serveurs, etc.).

3. L'objection utilitariste : L'impératif de l'efficience économique

Notre critique étant à la fois déontologique et aristotélicienne, les défenseurs de l'utilitarisme opposent quelques arguments assez cohérents qui méritent tout au moins qu'on s'y attarde. Avant d'aller plus loin, rappelons que l'utilitarisme, connu encore sous le nom de conséquentialisme, est une vision éthique selon laquelle une action est morale ou non selon que les bienfaits dépassent les inconvénients pour la majorité de la société.

Ces derniers évoquent trois arguments principaux pour défendre leur position :

Des gains massifs sur le plan économique : L'usage des assistants IA permet une accélération de la livraison logicielle et la chute drastique des coûts de production. Ces gains permettent aux PME d'avoir une marge bénéficiaire qui peut leur permettre d'investir ailleurs et de faire croître leur entreprise plus rapidement, tout en offrant des prix abordables pour leurs utilisateurs. Elles ont aussi accès à des technologies de pointe à des frais modiques. Ainsi, le bien-être collectif s'en trouve accru.
La minimisation des erreurs triviales : Bien que le code qu'ils génèrent puisse souvent être hors contexte, ces assistants sont très efficaces pour produire du code passe-partout et rigoureux sur le plan syntaxique. Ainsi, les bogues mineurs causés par les erreurs de frappe et autres erreurs syntaxiques qui minent le quotidien des développeurs sont presque réduits à zéro. La fiabilité du code s'en trouve augmentée automatiquement de manière générale.
La libération de l'esprit humain : Le fait de laisser le travail ingrat aux machines permet aux développeurs de se concentrer sur les décisions architecturales, qui sont les plus importantes. Ainsi, l'effort cognitif n'est pas annulé, mais il est plutôt déplacé sur d'autres types de problèmes dits de haut niveau.

Ainsi, selon les défenseurs de l'utilitarisme de l'IA, nous avons plusieurs tâches au quotidien que nous avons déléguées aux machines (ex: pilotage automatique dans les avions, etc.) et cela ne nous a pas rendus obsolètes pour autant ; il en est de même pour l'intelligence artificielle. Refuser de déléguer les tâches aux assistants IA sous prétexte qu'ils ont une certaine opacité dans leur fonctionnement est une décision purement fondée sur une peur irréaliste qui cause un tort à la société en voulant l'empêcher de continuer sa croissance sur le plan technologique.

4. Réfutation : Illusion de contrôle et impératif d'un capitalisme algorithmique

Le souci dans l'argumentaire des utilitaristes est qu'il est basé sur des prémisses erronées.

4.1 Illusion du contrôle humain et biais d'automatisation

Dans un premier temps, l'argument selon lequel le développeur est capable de superviser les assistants IA en tout temps est faux. La réalité du travail de nos jours est telle que le volume de code et les délais de déploiement ne permettent pas à celui-ci de relire et de corriger convenablement ce code. Il faut savoir que le code d'un logiciel est distribué et souvent dispersé dans différents dossiers inter-reliés. Il ne suffit pas qu'un bout de code soit syntaxiquement correct, mais encore faut-il qu'il s'intègre correctement à la logique globale de l'application. Avec les délais de plus en plus réduits, un développeur ne peut pas convenablement réviser le code et se concentrer en plus sur l'architecture du logiciel.

Ce phénomène a déjà été observé avec le système Lavender utilisé par l'armée israélienne à Gaza, où justement un être humain avait un rôle de superviseur pour approuver ou réfuter une frappe aérienne de drone. En situation réelle, ce qui était faisable en théorie est devenu un fiasco total, car l'agent, sous l'effet de la pression et des délais irréalistes, était obligé de valider la majorité des décisions de la machine et était relégué à un rôle de tampon d'approbation. Le souci est donc que, dans un contexte de pression intense (ce qui est très souvent le cas), le programmeur, de par son incapacité à valider dans un temps prescrit le code produit par la machine, subit un biais d'automatisation, car il est obligé de faire confiance aveuglément à la machine.

4.2 Saisie semi-automatique ou Nudging permanent

Pour finir, une fonctionnalité commune à tous ces assistants, et qui devient de plus en plus pernicieuse, est la saisie semi-automatique. En effet, à chaque touche de clavier, l'outil fait des propositions et essaie en permanence d'orienter le développeur vers une certaine voie. Quand l'on sait que de plus en plus de compagnies récompensent subtilement les employés qui ont le plus recours à l'intelligence artificielle, il est presque impossible de désactiver cette fonctionnalité au risque de voir sa productivité chuter et de se faire remarquer négativement ou de voir son poste menacé.

À la longue, le développeur finit par se retrouver dans un environnement où sa délibération rationnelle est mise à l'épreuve en permanence et il doit se battre contre l'assistant pour ne pas être court-circuité par lui. La plupart des développeurs pensent prendre des décisions par eux-mêmes, et pourtant, à force d'être bombardés à longueur de journée par les suggestions, en approuvant certaines et en rejetant d'autres, au final, c'est l'IA qui finit par influencer le développeur au lieu que ce soit le contraire. Contrairement à ce que les utilitaristes prétendent, le but de ces assistants n'est pas de libérer les développeurs des tâches de bas niveau pour leur permettre de se concentrer sur les décisions de plus haut niveau dites architecturales. Non, leur rôle est plutôt de rapidement faire disparaître la dépendance aux développeurs et de rendre ces derniers complètement obsolètes pour optimiser la rentabilité et faire chuter les coûts de production : c'est l'essence même du capitalisme algorithmique.

Conclusion

En conclusion, l'omniprésence actuelle des assistants IA dans le développement des logiciels modernes n'est pas une simple question d'arbitrage technique de productivité contre robustesse. Nous avons démontré par notre argumentaire rigoureux que le fait de déployer du code sans maîtrise complète de la logique entière est une pratique indéfendable éthiquement parlant.

Cette pratique est une tentative de violer le principe de responsabilité morale en cherchant à faire disparaître la responsabilité du développeur dans l'opacité des statistiques prédictives de la machine. Le principe de prudence est aussi bafoué car cette pratique expose le code à des risques sécuritaires majeurs tels que les injections SQL et autres failles logiques de contrôle d'accès. Enfin, le développeur finit par perdre son impartialité car il est en permanence soumis à une pratique de nudging ; il doit se battre au quotidien contre les suggestions faites par la machine et, par fatigue, est tenté de se soumettre à la machine s'il ne veut pas perdre en productivité.

On ne peut pas faire reposer uniquement le fardeau de la responsabilité sur ces développeurs qui ne peuvent rien contre le Capital Algorithmique. Il est important que l'État légifère à ce sujet et impose un cadre juridique contraignant pour les entreprises logicielles, notamment :

L'obligation légale de révision par des pairs humains pour tout code critique.
La responsabilité civile et pénale stricte des entreprises pour les failles générées par leurs IA.
L'interdiction de la délégation automatisée dans les secteurs touchant à la sécurité publique, à la santé, à la finance ou à la gestion des données citoyennes.

Ce n'est qu'à ce prix que l'IA pourra redevenir un outil au service des développeurs et qu'ils ne seront plus de simples tampons d'approbation comme c'est le cas actuellement.