Il y a encore quelques années, répondre à la question « qui a écrit ce code ? » était relativement simple. On pouvait désigner le développeur, l’équipe ou la société de développement qui était responsable d’un module précis.
Aujourd’hui, la situation est tout à fait différente.
Une partie du code peut être écrite manuellement. Une autre peut être générée par Copilot. Un autre fragment peut être créé par un agent de programmation. Un autre encore peut être récupéré depuis une bibliothèque open source. Un autre sera une dépendance d’un paquet externe. À cela s’ajoutent les API, les services cloud, les composants prêts à l’emploi, les frameworks et les outils fournis par d’autres entreprises.
Le système fonctionne. Mais savez-vous vraiment de quoi il a été construit ?
Le code généré par l’IA n’apparaît pas dans le vide
Le développement des outils d’IA pour la programmation ne change pas seulement la manière d’écrire des logiciels. Il modifie aussi la structure de la responsabilité du code.
Aujourd’hui, un développeur peut décrire une tâche à un agent, puis recevoir une fonction prête à l’emploi, un module, des tests, une configuration ou même une proposition de changements architecturaux. C’est un énorme gain de productivité.
Le problème commence lorsque nous traitons le code généré comme un « code venu de nulle part ».
En effet, l’IA ne crée pas du code en dehors de tout l’écosystème de développement. Les modèles sont entraînés sur d’immenses ensembles de données, et le fragment généré peut ressembler à des solutions existantes, à des modèles ou à du code publiquement disponible. C’est précisément pourquoi la question de l’origine du code, des licences et de la responsabilité devient de plus en plus importante.
Cela ne signifie pas automatiquement que chaque fragment de code généré par l’IA enfreint une licence quelconque. Cela signifie en revanche qu’une organisation qui utilise l’IA dans le processus de développement logiciel devrait traiter l’origine et la vérification du code comme un élément du processus d’ingénierie, et non comme une curiosité juridique.
Ce n’est déjà plus seulement une théorie
Le 16 septembre 2026, la Cour d’appel du 9e circuit a statué sur une partie de l’affaire Doe v. GitHub, dans laquelle des développeurs reprochaient à GitHub, Microsoft et aux entités OpenAI, entre autres, d’avoir utilisé du code publiquement disponible sur GitHub lors de la création et de l’entraînement d’outils tels que Copilot et Codex.
L’une des demandes concernait le DMCA et les informations relatives au droit d’auteur. Le tribunal a confirmé le rejet de cette accusation spécifique. En même temps, l’affaire couvre également d’autres questions liées au droit d’auteur et aux licences open source.
C’est important non pas parce qu’un seul jugement apporte une réponse simple à la question « peut-on utiliser du code issu de l’IA ? »
Il n’en apporte pas.
Ce qui est plus important, c’est que le litige montre un problème plus large : dans le monde de l’IA, la frontière entre le code écrit par un humain, le code généré par un modèle et le code provenant de l’écosystème logiciel existant devient de plus en plus difficile à retracer.
Et pour les entreprises qui développent des logiciels, cela signifie la nécessité de mieux gérer ce processus.
La chaîne d’approvisionnement logicielle, c’est-à-dire que votre système a bien plus « d’auteurs »
Dans la sécurité logicielle, le concept de software supply chain - la chaîne d’approvisionnement logicielle - est utilisé depuis des années.
Ce sont l’ensemble des composants, outils, bibliothèques, dépendances et processus qui participent à la création du produit final.
Le NIST souligne dans ce contexte notamment la nécessité de gérer l’origine des composants, de contrôler les dépendances open source, de surveiller les vulnérabilités et d’utiliser un SBOM, c’est-à-dire un Software Bill of Materials.
On peut, en très grande simplification, comparer le SBOM à une liste des ingrédients d’un produit.
Il ne dit pas seulement « nous avons une application ». Il montre quels composants se trouvent à l’intérieur.
Par exemple :
- framework de l’application,
- bibliothèques externes,
- versions des différents paquets,
- composants open source,
- dépendances indirectes,
- éléments fournis par des prestataires externes.
Ainsi, lorsqu’une vulnérabilité apparaît dans une bibliothèque précise, il est possible de vérifier plus rapidement quels systèmes l’utilisent.
Le NIST attire également l’attention sur la provenance, c’est-à-dire la possibilité de retracer l’origine des éléments logiciels.
Et c’est précisément ici que l’IA ajoute un nouveau niveau de complexité.
Parce qu’au sein de la chaîne existante s’ajoute une autre manière de produire du code.
Imaginez un système métier typique
40 % du code a été écrit par l’équipe.
20 % a été créé avec l’aide de l’IA.
D’autres fragments ont été générés par un agent.
Plusieurs bibliothèques proviennent de l’open source.
Une partie des dépendances a été ajoutée par le framework.
Le système utilise l’API d’un fournisseur externe.
Un composant provient d’un paquet que personne n’a mis à jour depuis deux ans.
Et la documentation des dépendances ?
Elle se trouve quelque part dans le dépôt.
Ou bien elle n’existe pas.
Le système fonctionne...
Et c’est précisément pour cela que le problème est invisible. Jusqu’à ce que quelque chose se produise.
Puis une vulnérabilité apparaît
Imaginons que l’on découvre une faille de sécurité grave dans l’une des bibliothèques.
La question est : Savez-vous si votre système l’utilise ?
Si vous disposez d’un registre structuré des dépendances, la réponse peut prendre quelques minutes.
Sinon, il faut commencer à fouiller manuellement les dépôts, contacter les développeurs, vérifier les environnements, les versions des paquets et les dépendances indirectes.
Ajoutons maintenant à cela le code généré par l’IA.
Sait-on quel fragment a été créé avec quel outil ?
Le code a-t-il fait l’objet d’une revue ?
Le code a-t-il été couvert par des tests ?
Les dépendances ont-elles été vérifiées ?
Quelqu’un a-t-il contrôlé la licence du composant ?
Peut-on reproduire le processus qui a conduit à la création d’un fragment précis ?
Ce ne sont plus seulement des questions pour le développeur.
Ce sont des questions liées à la gestion du risque technologique de l’entreprise.
Le plus grand problème n’est pas l’IA. C’est l’absence de processus
Il serait facile de faire de cet article un avertissement contre l’intelligence artificielle.
Ce serait toutefois une conclusion trop simple.
L’IA peut fortement améliorer la productivité d’une équipe de développement logiciel.
Le problème apparaît lorsque l’entreprise augmente le rythme de production du code sans augmenter simultanément le contrôle sur ce code.
C’est un peu comme si une usine produisait soudain dix fois plus de pièces, mais sans augmenter le contrôle qualité, l’inventaire des matériaux ni le contrôle des fournisseurs.
Dans une société de développement logiciel, les équivalents d’un tel système de contrôle sont notamment :
- revue de code
- tests automatiques
- analyse des dépendances
- SBOM
- surveillance des vulnérabilités
- contrôle des licences open source
- CI/CD avec contrôles de sécurité
- gestion des dépôts
- documentation de l’architecture
- traçabilité de l’origine des composants
- des règles claires pour l'utilisation de l'IA dans le développement
Le NIST indique également la possibilité d'intégrer des mécanismes de sécurité de la chaîne d'approvisionnement directement dans les pipelines CI/CD.
C'est un changement important de manière de penser.
La sécurité ne devrait pas être un contrôle effectué seulement avant le déploiement.
Elle devrait faire partie du processus de création du logiciel.
"Qui a écrit ce code ?" cesse d'être la bonne question
Dans le monde du développement traditionnel, on pouvait demander qui était l'auteur.
Dans le monde du développement assisté par l'IA, des questions bien plus importantes deviennent :
- D'où vient ce composant ?
- Quelle est sa licence ?
- Qui l'a vérifié ?
- Quelle version utilisons-nous ?
- Quelles sont ses dépendances ?
- Est-il toujours maintenu ?
- Connaissons-nous ses vulnérabilités ?
- Pouvons-nous reconstituer l'historique des changements ?
- Savons-nous où l'IA a participé à sa création ?
Et surtout :
- L'entreprise est-elle capable de prouver qu'elle maîtrise tout cela ?
Car le client n'achète pas un "code d'IA". Il achète un système qui fonctionne. Et la responsabilité de ce système incombe toujours à l'organisation qui le fournit et le maintient.
Le code peut être automatisé. Pas la responsabilité
C'est probablement l'un des changements les plus importants que l'IA apporte aux sociétés de développement logiciel.
Le programmeur ne disparaît pas. Son rôle change.
De plus en plus, il ne s'agit pas uniquement d'écrire un certain nombre de lignes de code. Il s'agit de concevoir la solution, de contrôler les éléments générés, d'évaluer les risques, de tester, d'intégrer, d'assurer la sécurité et de maintenir l'ensemble du système.
De même, l'entreprise ne peut pas se limiter à demander si ses programmeurs utilisent l'IA.
Elle devrait savoir comment ils l'utilisent, dans quel processus, avec quels contrôles et comment cela affecte l'ensemble du cycle de vie du logiciel.
Car dans quelques années, la question pourrait ne plus être : "Qui a écrit ce système ?"
mais : "Pouvez-vous reconstituer à partir de quoi et de quelle manière il a été construit ?"
Si la réponse est "pas tout à fait", le problème n'est pas l'absence d'un nouvel outil d'IA.
Le problème est l'absence de contrôle sur la chaîne d'approvisionnement logicielle.
