Une image classique d’un développeur signant une ligne de code peut sembler désuète à une époque où des agents d’Intelligence Artificielle génèrent des correctifs, des tests et de la documentation en quelques secondes. Pourtant, cette signature conserve toute sa valeur, non pas parce que le logiciel doit revenir à une artisanat lent et manuel, mais parce que les systèmes critiques nécessitent quelque chose qu’aucun modèle ne peut apporter seul : une responsabilité humaine vérifiable.

Les progrès des assistants de programmation ont modifié le rythme du développement. Des outils comme Copilot, Claude Code, Cursor ou Codex aident à écrire des fonctions, repérer des erreurs, proposer des refactorisations ou automatiser des tâches qui prenaient auparavant des heures. Dans certains équipes, la question n’est plus de savoir s’il faut utiliser l’IA, mais comment l’intégrer sans perdre le contrôle de la qualité, de la sécurité et de l’attribution du code.

Le problème survient lorsque la rapidité est confondue avec la fiabilité. Un correctif généré par IA peut compiler, respecter le style du projet et passer des tests simples, mais échouer dans un cas limite, introduire une dépendance non sécurisée ou reproduire un motif vulnérable appris à partir de code public. L’apparence de correction ne suffit pas. Dans le logiciel — et encore plus dans des infrastructures critiques — le coût d’une erreur apparaît souvent lorsque le système est en production.

Linux trace une frontière : l’IA aide, mais ne signe pas

Le noyau Linux a formalisé une règle qui résume bien ce moment. Les assistants d’IA peuvent aider au développement, mais ne peuvent pas ajouter la balise Signed-off-by. Cette signature est liée au Developer Certificate of Origin, un mécanisme par lequel un contributeur certifie qu’il a le droit d’envoyer ce code et assume la responsabilité de la contribution.

Le guide du noyau est clair : seule une personne peut réviser le code généré par l’IA, vérifier sa conformité à la licence, y apposer sa propre signature et répondre du résultat. Lorsqu’un outil d’IA a été utilisé, cela doit être indiqué par une balise Assisted-by, mentionnant l’agent, la version du modèle et, si pertinent, d’autres outils d’analyse employés.

Il ne s’agit pas d’un rejet de l’Intelligence Artificielle, mais d’une manière de l’intégrer dans un processus de confiance déjà en place. Le message pour les autres projets est simple : l’IA peut écrire, suggérer ou accélérer, mais ne peut assumer des responsabilités légales ou techniques. Si un correctif cause une vulnérabilité, rompt une compatibilité ou viole une licence, la responsabilité ne peut revenir à un modèle, une API ou une entreprise fournisseur située à plusieurs niveaux de distance.

Cette distinction deviendra de plus en plus cruciale. Dans les environnements de développement autonomes, la tentation de déléguer des décisions complètes croîtra. Mais plus un outil possède d’autonomie, plus il sera essentiel d’enregistrer précisément ce qu’il a fait, avec quels permissions, sur quel dépôt, selon quelles instructions, et qui a validé le résultat final.

Code généré rapidement, dette technique aussi rapide

La sécurité de l’IA appliquée au développement ne peut se limiter à une vérification par linter ou à l’exécution d’une batterie de tests basiques. Un rapport de Veracode sur du code généré par IA a conclu que 45 % des échantillons analysés comportaient des vulnérabilités de sécurité connues. Ce chiffre ne signifie pas que tout code AI soit dangereux, ni que le code humain soit parfait. Il indique simplement qu’une productivité sans révision accumule à la fois une dette technique et de sécurité à un rythme accéléré.

Une règle fondamentale à suivre : traiter tout code généré par IA comme non fiable jusqu’à preuve du contraire. Cela implique une revue humaine, des tests automatisés, une analyse statique, une vérification des dépendances, un contrôle des secrets, des tests de sécurité et une revue d’architecture lorsque la modification touche des zones sensibles.

Il est également crucial de surveiller les dépendances. Les modèles peuvent proposer des librairies inexistantes, désuètes ou peu maintenues. Dans un flux de travail traditionnel, un développeur connaît souvent l’écosystème dans lequel il travaille. Dans un flux automatique orchestré par des agents, un outil peut intégrer des paquets par convenance syntaxique sans comprendre la politique de sécurité de l’organisation. La confiance seule ne suffit pas, il faut des contrôles.

Le principe classique de moindre privilège doit être étendu à celui de moindre autonomie. Un agent ne devrait pouvoir faire que ce qui est nécessaire pour une tâche précise, et pas tout ce qu’il sait faire. Il ne faut pas lui donner la permission de créer des branches, ouvrir des pull requests, modifier des pipelines, installer des dépendances ou déployer en production, à moins que cela ne soit explicitement requis.

La chaîne d’approvisionnement montre que la confiance implicite échoue

Les incidents récents en dehors du développement assisté par IA renforcent cette leçon. En avril 2026, le site CPUID, connu pour CPU-Z ou HWMonitor, a été compromis en moins de 24 heures. Selon Kaspersky, des attaquants ont remplacé des liens de téléchargement légitimes par des installateurs infectés par un cheval de Troie, intégrant un exécutable signé et une DLL malveillante nommée CRYPTBASE.dll, chargée via du DLL sideloading.

Ce détail est crucial : il n’est pas toujours nécessaire de modifier le binaire signé pour compromettre l’utilisateur. Il suffit de manipuler la chaîne de distribution, placer une bibliothèque à l’endroit stratégique et profiter des règles de chargement héritées. La signature de l’exécutable continue à donner une impression de confiance, mais le paquet livré à l’utilisateur est déjà contaminé.

De même, Apple a corrigé en avril 2026 la vulnérabilité CVE-2026-28950 dans Notification Services, qui pouvait faire rester indéfiniment en mémoire des notifications marquées pour suppression. Des médias de sécurité ont relié cette faille à la récupération de contenu provenant de notifications Signal, montrant que le chiffrement de bout en bout ne garantit pas totalement la vie privée. La sécurité finale dépend aussi du système d’exploitation, des notifications, des stockages locaux, des logs et des outils d’extraction.

Ces exemples ont une lecture commune : la sécurité ne repose pas sur une seule couche ou promesse. Un code peut apparaître correct et signé, une application peut chiffrer ses messages, mais si la chaîne d’approvisionnement, le système d’exploitation, le chargement des bibliothèques ou la gestion des logs sont vulnérables, la confiance est rompue ailleurs.

Vérification continue, pas simple audit cérémonial

La gouvernance de l’IA ne doit pas devenir une simple politique revue annuellement. Si des agents génèrent du code, modifient de la documentation, ouvrent des tickets, relisent des pull requests ou proposent des déploiements, la vérification doit faire partie du flux quotidien de travail.

Cela implique d’enregistrer quelles parties d’un changement ont été assistées par IA, de conserver la traçabilité des prompts et actions, d’exiger une revue humaine pour les étapes critiques, d’appliquer des contrôles automatisés avant la fusion, et de limiter les permissions des agents selon le dépôt, l’environnement et la tâche. Il faut aussi mesurer le nombre de faux positifs, d’erreurs récurrentes, et identifier où la machine se trompe le plus.

L’objectif n’est pas de freiner l’adoption de l’IA, mais de la rendre durable. Une innovation sans trace ne peut pas être auditée, une automatisation sans limites est ingérable, et un code non signé aujourd’hui pourrait causer des problèmes demain. La responsabilité revient à l’humain, pas à l’outil.

Le rôle du développeur ne disparaît pas avec l’arrivée des agents. Il évolue. Il devient moins technicien répétant des fonctions, plus responsable du contexte, de l’architecture, de la sécurité et de la validation. L’IA peut écrire beaucoup, mais quelqu’un doit savoir ce qu’il ne faut pas faire, ce que l’on ne doit pas déployer, et ce qui mérite un regard plus approfondi.

En 2026, la question n’est plus de savoir si une organisation utilise l’IA pour développer, mais qui signe ce que cette IA produit, quels contrôles le vérifient, et ce qu’il advient si le résultat échoue. L’humain reste en contrôle, non par nostalgie, mais parce qu’il est encore le seul capable d’assumer cette responsabilité.

Questions fréquemment posées

Une IA peut-elle signer du code dans le noyau Linux ?
Non. La gouvernance du noyau indique que les agents d’IA ne peuvent pas ajouter les balises Signed-off-by. Seule une personne peut certifier le Developer Certificate of Origin et en assumer la responsabilité.

Que signifie la balise Assisted-by ?
Elle indique qu’un outil d’IA a assisté à la contribution. Elle apporte de la transparence sans faire reposer la responsabilité légale ou technique sur l’IA.

Tout code généré par AI est-il dangereux ?
Pas nécessairement. Mais il doit être considéré comme non fiable jusqu’à preuve du contraire. Des études de sécurité ont montré que ces échantillons comportent fréquemment des vulnérabilités connues, d’où la nécessité de revue humaine et de tests approfondis.

Quels contrôles doit appliquer une entreprise utilisant des agents d’IA pour coder ?
Elle doit limiter les permissions, enregistrer les actions, exiger une revue humaine pour les changements sensibles, réaliser une analyse de sécurité, contrôler les dépendances, et maintenir une vérification continue intégrée au processus de développement.