Code généré par IA : vérifier les licences et les dépendances avant la production

Pour vérifier les licences d’un code généré par IA avant la production, ne vous fiez pas à une simple déclaration de l’assistant : inventoriez les dépendances, retrouvez la provenance des composants repris et faites valider les cas ambigus. Cette revue complète les tests techniques; elle ne prouve pas à elle seule que chaque ligne est libre de droits.

Le risque apparaît souvent quand une équipe transforme un prototype de vibe coding en application utilisée par des clients. Un extrait proposé par un copilote IA peut être copié, modifié puis mélangé à du code interne, tandis que les paquets installés ajoutent leurs propres licences. La bonne méthode consiste à conserver des éléments de preuve et à traiter les zones inconnues avant la mise en ligne.

Que faut-il vérifier dans un code généré par IA ?

Il faut séparer trois questions : d’où vient le code, quelles licences s’appliquent aux composants du projet, et quelles obligations votre produit doit respecter. Une réponse générée par un LLM n’est pas une preuve de provenance ni un avis juridique.

Pour chaque partie importante, notez si elle a été écrite par l’équipe, produite avec un outil d’IA générative, adaptée d’un exemple public ou importée d’une dépendance. L’objectif n’est pas de reconstituer chaque frappe, mais de rendre visibles les blocs à risque : extraits de code repris d’un dépôt, extraits de documentation, polices, icônes, modèles, bibliothèques et code ajouté par l’agent.

La licence d’une dépendance ne se confond pas avec la licence de votre application. Un paquet peut avoir une licence différente de celle du code propriétaire qui l’utilise; certaines conditions nécessitent une revue particulière selon le mode de distribution et l’usage. Ne déduisez pas l’autorisation de réutiliser un extrait du seul fait qu’il apparaît dans une réponse de Claude Code, Cursor, GitHub Copilot ou Windsurf. Ces outils accélèrent l’écriture et la navigation dans le code, mais la revue et la décision de livraison doivent rester sous le contrôle de l’équipe projet.

Comment retrouver la provenance d’un extrait ?

Commencez par les changements significatifs, pas par une lecture ligne à ligne de tout le dépôt. Reliez chaque fonctionnalité sensible à une demande, une revue ou un ticket, puis consignez la source connue du code et le nom des outils utilisés pour le produire ou le modifier.

Une procédure légère peut suivre ces étapes :

1. Repérez les fichiers ou blocs introduits par une génération, un copier-coller ou une migration.
2. Demandez à l’outil d’expliquer l’approche et de nommer les bibliothèques ou références publiques utilisées, sans considérer cette réponse comme une preuve.
3. Comparez les extraits inhabituels avec les sources que l’équipe connaît déjà; si l’origine reste incertaine, remplacez le code ou demandez une revue spécialisée.
4. Ajoutez au dépôt une note de décision pour les composants conservés : origine, licence identifiée, usage et personne ayant validé.
5. Gardez les changements sous contrôle de version afin de pouvoir relier la décision au commit qui les introduit.

Claude Code et Cursor peuvent aider un développeur à explorer un dépôt et à proposer des modifications; GitHub Copilot peut suggérer du code dans le flux de développement; Windsurf propose un environnement de développement assisté. Aucun de ces outils ne dispense de vérifier les dépendances réellement installées ni les conditions applicables à un composant repris. Une revue humaine doit aussi vérifier que les références suggérées existent et qu’elles correspondent bien au code livré.

Comment inventorier les dépendances et leurs licences ?

L’inventaire commence par les fichiers de manifeste et de verrouillage. Ils indiquent les paquets directs et, selon l’écosystème, permettent de remonter les dépendances transitives. Notez le nom et la version de chaque paquet, l’origine du registre, la licence déclarée lorsqu’elle est disponible et le rôle du composant.

Un manifeste n’est pas toujours une preuve juridique suffisante. Les métadonnées peuvent être absentes, incomplètes ou différentes des conditions publiées par le projet. Pour les éléments qui comptent, consultez le dépôt amont et le texte de licence associé à la version utilisée. Consignez la licence et sa version, les notices ou attributions à conserver, les éventuelles obligations de redistribution et la manière dont le produit est livré; faites examiner les cas ambigus selon votre contexte. Si une bibliothèque est vendue, embarquée ou distribuée à des clients, demandez une analyse adaptée au contexte de diffusion plutôt que d’appliquer une règle générale.

GitHub fournit une vue du graphe de dépendances et documente la conformité des licences open source; sa documentation décrit également l’export d’un inventaire SBOM depuis le graphe de dépendances. Une SBOM aide à rendre les composants identifiables, mais ne certifie ni leur provenance complète ni la conformité du produit. GitHub Actions peut automatiser la génération de rapports ou signaler un changement à examiner dans la chaîne d’intégration continue; Docker, lui, sert à construire et exécuter une application dans un environnement conteneurisé, pas à vérifier les licences par lui-même.

Quelle revue intégrer au passage en production ?

Ajoutez la vérification des licences au même jalon que la revue de sécurité et la préparation de la livraison. Une personne responsable doit examiner les paquets nouveaux ou mis à jour, les notices requises, les dépendances abandonnées et les composants dont la licence n’est pas claire. Pour les modifications générées par IA, demandez aussi si le changement introduit une bibliothèque inutile ou recopie un exemple sans attribution.

La revue peut être organisée en trois niveaux :

• Accepté : licence identifiée, usage compatible avec la distribution envisagée, notices conservées selon les besoins.
• À confirmer : métadonnées manquantes ou source ambiguë; le changement ne part pas en production avant clarification.
• Refusé ou remplacé : conditions incompatibles avec le produit, ou provenance trop incertaine pour être défendue.

Cette règle évite qu’une suggestion plausible devienne une dépendance permanente sans décision explicite. L’article sécuriser les pipelines de données traite d’un autre volet de la maîtrise du cycle de vie, tandis que la reprise d’une application générée par IA détaille les contrôles à prévoir lors de la stabilisation d’un prototype.

Avant de livrer, gardez une trace exploitable

Pour chaque version, conservez le manifeste, le fichier de verrouillage, l’inventaire des dépendances et les décisions prises sur les licences ou les extraits dont la source était incertaine. Une chaîne d’intégration continue avec GitHub Actions peut signaler les changements à faire examiner; elle ne remplace pas une personne qui comprend le contexte de distribution.

Si vous reprenez un produit construit avec du code généré, commencez par un échantillon représentatif : inventaire des paquets, identification des composants copiés, puis revue des notices et des cas ambigus. La page reprise et stabilisation d’une application construite avec l’IA présente les étapes de remise à niveau d’un existant. Quand l’origine d’un composant ou ses conditions d’usage restent incertaines, mettez-le en attente et faites vérifier le point avant de livrer.