Rétro-ingénierie logicielle : ce que le droit autorise, ce qu’un agent IA change

La rétro-ingénierie d’un logiciel consiste à comprendre comment il fonctionne sans disposer de ses sources : l’observer, le tester, parfois le décompiler. En Europe, elle n’est ni interdite par principe ni libre par principe. La directive 2009/24/CE et sa transposition française à l’article L122-6-1 du Code de la propriété intellectuelle dessinent un périmètre précis, que la Cour de justice de l’Union européenne a interprété à plusieurs reprises.

Je ne suis pas juriste. Je suis ingénieur et docteur en intelligence artificielle, et je conduis des missions où il faut comprendre des logiciels sans documentation. Ce qui suit est une lecture d’ingénieur des textes officiels, cités avec leurs liens : ce n’est pas un avis juridique, et tout projet réel doit être validé par un juriste au regard de la licence et du contexte. La seconde moitié porte sur ce qu’un agent IA change : surtout la question de la preuve.

Le droit d’auteur protège l’expression d’un programme, c’est-à-dire son code, et non les idées et principes qui sont à sa base, y compris ceux de ses interfaces.

C’est l’article 1er, paragraphe 2, de la directive 2009/24/CE qui le pose. Le programme est protégé s’il est original, c’est-à-dire création intellectuelle propre à son auteur.

Dans l’arrêt SAS Institute (C-406/10, 2 mai 2012, grande chambre), la Cour a jugé que ni la fonctionnalité d’un programme, ni le langage de programmation, ni le format de fichiers de données qu’il utilise ne constituent une forme d’expression protégée par le droit d’auteur sur les programmes. L’arrêt interprète la directive 91/250/CEE, codifiée depuis par la directive 2009/24/CE avec la même numérotation. Réserve : reprendre des éléments originaux du manuel d’utilisation d’un autre programme peut porter atteinte au droit d’auteur sur ce manuel.

Pour l’ingénieur, la distinction est opératoire : reproduire un comportement n’est pas reproduire un code. C’est le fondement de la méthode dite de salle blanche, que je décris dans PhotoCraft, un Photoshop open source construit en salle blanche.

La personne habilitée à utiliser un programme peut l’observer, l’étudier et le tester pour en déterminer les idées et principes, à condition de le faire pendant les opérations qu’elle a le droit d’effectuer.

L’article 5, paragraphe 3, de la directive vise les opérations de chargement, d’affichage, d’exécution, de transmission ou de stockage. Aucune autorisation du titulaire n’est requise, et l’article 8 frappe de nullité toute clause contractuelle contraire. En droit français, le III de l’article L122-6-1 reprend la règle et vise le fonctionnement « ou la sécurité » du logiciel ; le dernier alinéa déclare nulle toute stipulation contraire aux II, III et IV.

L’arrêt SAS Institute précise le périmètre : le titulaire d’une copie sous licence peut observer, étudier et tester lorsqu’il effectue des opérations couvertes par la licence et les opérations de chargement et de déroulement nécessaires à l’utilisation, à condition de ne pas porter atteinte aux droits exclusifs du titulaire.

Ma lecture d’ingénieur : l’analyse en boîte noire d’un logiciel qu’on a le droit d’exécuter est le terrain le plus solide. Mais « qu’elle est en droit d’effectuer » renvoie à la licence : observer hors des conditions qu’elle ouvre sort de ce cadre.

La décompilation est permise sans autorisation seulement si elle est indispensable pour obtenir les informations nécessaires à l’interopérabilité d’un programme créé de façon indépendante, et si trois conditions cumulatives sont réunies.

L’article 6, paragraphe 1, de la directive exige que :

1. les actes soient accomplis par le licencié ou une autre personne ayant le droit d’utiliser une copie, ou pour leur compte par une personne habilitée ;
2. les informations nécessaires à l’interopérabilité ne leur soient pas déjà facilement et rapidement accessibles ;
3. les actes soient limités aux parties du programme d’origine nécessaires à l’interopérabilité.

Le paragraphe 2 encadre l’usage de ce qu’on obtient : pas d’autres fins que l’interopérabilité, pas de communication à des tiers sauf nécessité pour cette interopérabilité, pas d’utilisation pour mettre au point un programme d’expression fondamentalement similaire. Le paragraphe 3 interdit toute application qui causerait un préjudice injustifié au titulaire ou porterait atteinte à l’exploitation normale du programme. Le IV de l’article L122-6-1 transpose ces conditions en droit français.

Traduit en méthode : avant de décompiler, on vérifie la documentation, l’API publique, et on interroge l’éditeur. On garde la trace de ces démarches, car « pas déjà facilement et rapidement accessibles » se démontre.

Selon la CJUE, l’acquéreur légitime peut décompiler un programme pour corriger des erreurs qui affectent son fonctionnement, dans la mesure nécessaire et dans le respect des conditions prévues par contrat.

Dans l’arrêt Top System (C-13/20, 6 octobre 2021), la Cour juge que la décompilation de tout ou partie du programme est possible pour corriger des erreurs, y compris lorsque la correction consiste à désactiver une fonction qui perturbe l’application. Ce fondement est l’article 5, paragraphe 1, et non l’article 6 : les conditions de l’interopérabilité ne s’appliquent pas.

La limite est contractuelle. L’article 5, paragraphe 1, s’applique « sauf dispositions contractuelles spécifiques », et l’arrêt réserve le respect des conditions convenues avec le titulaire. En droit français, le I de l’article L122-6-1 permet à l’auteur de se réserver par contrat le droit de corriger les erreurs, et ce I ne figure pas dans la clause de nullité.

Conséquence pratique : avant de corriger un logiciel tiers par décompilation, on lit le contrat de licence et de maintenance.

La directive (UE) 2016/943 range l’observation, l’étude, le démontage ou le test d’un produit acquis licitement parmi les moyens licites d’obtenir un secret d’affaires, sauf obligation juridiquement valide de limiter cette obtention.

C’est l’article 3, paragraphe 1, point b). Le considérant 16 le dit en clair : l’ingénierie inverse d’un produit obtenu de façon licite doit être considérée comme un moyen licite d’obtenir des informations, sauf dispositions contractuelles contraires. En France, l’article L151-3 du Code de commerce reprend la règle, « sauf stipulation contractuelle interdisant ou limitant l’obtention du secret ».

Les deux régimes se cumulent : l’article 8 de la directive 2009/24/CE précise qu’elle n’affecte ni le secret des affaires ni le droit des contrats. Ma lecture, à faire confirmer : le contrat pèse davantage côté secret des affaires que côté droit d’auteur, où certaines exceptions ne peuvent pas être écartées.

La licence ne peut pas supprimer les exceptions impératives d’observation et de décompilation pour l’interopérabilité, mais elle encadre tout le reste, et c’est elle qu’on lit en premier.

La nullité des clauses contraires est ciblée : article 5, paragraphes 2 et 3, et article 6 dans la directive ; II, III et IV dans le Code de la propriété intellectuelle. Elle ne couvre ni la correction d’erreurs, ni le secret des affaires. Pour un service en ligne dont on ne détient pas de copie, les CGU prennent une place plus grande : point à faire valider. Sur le poids d’une licence dans un choix technique, voir aussi Llama 2 : la licence compte autant que le modèle.

Le tableau résume ma lecture : il sert à savoir quand appeler le juriste, pas à trancher.

Un agent IA ne change pas les règles : il change l’échelle, la vitesse et la circulation du code, ce qui rend la question du périmètre et de la preuve centrale.

Un agent décompile et résume un binaire en quelques minutes. La tentation est de tout décompiler, alors que l’article 6 limite l’acte aux parties nécessaires. Le périmètre doit donc être imposé à l’outil, pas laissé à son initiative : c’est le principe que je défends dans agents IA, le périmètre avant l’autonomie.

Le deuxième changement est la circulation. Un agent adossé à un modèle hébergé envoie le code analysé à un fournisseur. L’article 6, paragraphe 2, limite la communication à des tiers des informations issues de la décompilation, et la licence contient souvent des clauses de confidentialité. Savoir si un fournisseur de modèle est un tiers au sens du texte relève du juriste ; la réponse d’ingénieur est un modèle local ou un fournisseur sans conservation, vérifiée par contrat. Voir ce qu’on a le droit de mettre dans un prompt.

Le troisième est la sortie. Un agent qui a lu du code décompilé puis écrit le nouveau programme peut en reproduire des fragments, ce que l’article 6, paragraphe 2, point c), interdit. D’où la séparation entre analyse et écriture, et la vérification décrite dans le code écrit par un modèle et ce qu’on a le droit de livrer.

En tenant un journal d’investigation reproductible : ce qui a été analysé, pourquoi, avec quel outil, où sont allées les données et ce qui en est sorti.

Le journal consigne l’empreinte du binaire, le titre d’utilisation, l’objectif, chaque action avec sa justification, les échanges avec l’agent et la destination de chaque donnée. Reproductible signifie qu’un tiers peut rejouer l’enquête et retrouver les mêmes constats.

Des outils comme REA, un agent de rétro-ingénierie logicielle, proposent ce type de journal. En cas de contestation, on montre la nécessité et la limitation au lieu de les reconstituer après coup. C’est la même logique que le dossier de preuve d’une réponse IA.

On cadre avant de toucher au binaire : finalité, titre d’utilisation, licence, périmètre, flux de données, séparation des équipes, validation juridique.

1. Écrire la finalité en une phrase : interopérer avec quoi, corriger quelle erreur, comprendre quel comportement.
2. Établir le titre d’utilisation : licence, version, contrat de maintenance, personne habilitée.
3. Épuiser les sources ouvertes : documentation, API, demande écrite à l’éditeur, réponses archivées.
4. Fixer le périmètre : modules concernés, techniques autorisées, de l’observation à la décompilation.
5. Choisir l’outillage et les flux : modèle local ou hébergé, conservation, journal activé dès le départ.
6. Séparer analyse et écriture : l’équipe qui écrit ne voit que la spécification fonctionnelle.
7. Faire valider ce cadrage par un juriste avant le premier acte de décompilation.

C’est la démarche que j’applique pour moderniser un logiciel legacy sans documentation avec un agent IA. Pour situer ce type de projet dans l’ensemble de vos usages, un audit IA en fixe les priorités et les garde-fous.

Lecture d’ingénieur proposée par Anand Candassamy au 13 octobre 2026. Elle ne constitue pas un avis juridique.