AGPL expliquée : obligations pour les déploiements internes

Vous avez trouvé du code sous AGPL qui semble utile, mais vous ne savez pas ce que cela implique pour une exécution au sein de votre entreprise. L'inquiétude pratique : devrez-vous publier du code privé, exposer des systèmes internes ou ouvrir un champ juridique risqué si vous modifiez le logiciel et l'utilisez derrière votre pare-feu ? Ce guide clarifie le jargon juridique et montre, en termes techniques, ce que la GNU Affero General Public License (AGPL) oblige effectivement pour une entreprise qui déploie le code en interne.

Vue rapide : ce qu'est l'AGPL et en quoi elle diffère de la GPL

L'AGPL est la GNU GPL avec une clause réseau. GPLv3 couvre la distribution de binaires : si vous distribuez un programme modifié, vous devez proposer le code source correspondant. AGPLv3 ajoute la section 13 : si vous exécutez un programme AGPL modifié et que vous permettez à des tiers d'interagir avec lui via un réseau, ces utilisateurs distants doivent également avoir accès au code source de cette version modifiée. En bref : l'utilisation via le réseau déclenche des obligations de mise à disposition du code similaires à celles de la distribution sous la GPL.

Quand l'AGPL s'applique en interne dans une entreprise

La question clé est de savoir qui compte comme « utilisateur » au sens de l'AGPL. La licence ne distingue pas les clients publics des employés : toute personne qui interagit avec le programme couvert par l'AGPL via un réseau est un utilisateur ayant droit au code source. Il y a donc trois scénarios internes typiques à garder distincts :

• Déploiements internes accessibles uniquement aux employés derrière un pare-feu d'entreprise : les obligations AGPL s'appliquent à ces utilisateurs-employés — vous devez leur fournir le code source correspondant de la version en cours d'exécution et de toute modification.
• Déploiements de type SaaS ou services exposés aux clients : si des clients externes interagissent avec votre service, vous devez rendre le code source disponible pour ces clients (la mise en ligne publique est la méthode courante pour satisfaire cette obligation).
• Utilisation strictement hors ligne (aucune interface réseau) : si le programme est exécuté uniquement localement sur des machines sans interaction réseau, la clause réseau de l'AGPL n'est pas déclenchée au-delà des obligations normales de la GPL en matière de distribution.

De façon cruciale, « utilisation interne » ne signifie pas automatiquement « aucune obligation ». Si des employés ou des contractuels utilisent le service, ce sont des utilisateurs au sens de l'AGPL et ils ont droit au code source. En revanche, une obligation AGPL de publier le code sur Internet survient uniquement si ces utilisateurs sont externes (clients, tiers) ou si vous choisissez de satisfaire l'offre en rendant le code publiquement accessible.

Ce que vous devez effectivement fournir aux utilisateurs

Lorsque l'AGPL est applicable, les obligations pratiques sont concrètes. Vous devez fournir le « Complete Corresponding Source » pour la version exacte du programme que vous exécutez. Cela inclut typiquement :

• L'arbre complet des sources du programme, y compris toutes les modifications que vous avez apportées.
• Scripts de compilation, fichiers de configuration, scripts de packaging et toutes instructions d'installation et de déploiement nécessaires pour reproduire le binaire en cours d'exécution.
• Tous scripts ou sources nécessaires pour générer ou récupérer des composants non-sources qui font partie du système déployé (par exemple, le code utilisé dans une construction de conteneur).
• Conservation des avis de licence, en-têtes de copyright et fichiers AUTHORS/NOTICE tels qu'ils figurent dans le projet upstream.

L'offre peut être faite directement aux utilisateurs qui interagissent avec le programme. En pratique, les organisations satisfont cette exigence en plaçant un lien clairement étiqueté dans l'interface de l'application ou dans une page À propos pointant vers une archive tarball ou un instantané de dépôt git et un README lisible expliquant les étapes de compilation et de déploiement. L'AGPL ne prescrit pas un format d'URL unique ni un hébergeur, mais le code source doit être accessible aux utilisateurs concernés sous une forme réutilisable.

Ce que « fournir le code source » ne signifie pas (et idées reçues)

Certaines choses ne sont pas automatiquement imposées par l'AGPL :

• Elle ne vous oblige pas à publier des services propriétaires ou des configurations non liées au programme AGPL. Seul le programme et son code source correspondant sont requis.
• Elle n'exige pas la publication continue de l'historique de développement ; fournir le code exact utilisé pour exécuter le service est ce qui compte (même si de nombreuses équipes publient un tag VCS ou un hash de commit pour clarifier).
• Elle ne force pas la publication de credentials, clés privées ou secrets. Ceux-ci ne sont pas du « code source » : vous devez supprimer ou ne pas inclure les secrets dans tout archive publiée. (Si des secrets sont nécessaires pour produire une distribution fonctionnelle, documentez des espaces réservés et les sources attendues des secrets au lieu d'incorporer des secrets.)

Comment se mettre en conformité — liste pratique pour les équipes d'ingénierie

Quand vous déployez du code AGPL (modifié ou non), suivez ces étapes pour rester en conformité et éviter les surprises :

• Inventaire : enregistrez où des composants AGPL sont utilisés, s'ils ont été modifiés, et qui utilise chaque service (employés, contractuels, clients).
• Version et hash de commit : taggez le commit exact ou l'ID de build que vous exécutez. Rendez cet identifiant visible dans l'interface (par exemple une page À propos) afin que le code publié puisse être identifié avec l'instance en cours.
• Publiez le code source correspondant : fournissez une archive téléchargeable ou un instantané git en lecture seule qui inclut les scripts de build, Dockerfiles et manifests de déploiement nécessaires pour reproduire le programme en cours d'exécution.
• Rendez le code accessible aux utilisateurs habilités : pour les services exposés aux clients, utilisez une URL publique liée depuis l'interface. Pour les services internes, un dépôt git interne ou un dépôt d'artefacts accessible par les employés est typique et suffisant.
• Conservez les mentions légales : gardez les en-têtes de copyright et de licence upstream et ajoutez vos propres notes de contributeur pour les modifications.
• Évitez d'inclure des secrets : nettoyez les clés privées, tokens, mots de passe et adresses réseau internes des archives publiées.
• Formez les équipes support et juridique : assurez-vous que les ingénieurs support savent répondre aux demandes de source et ont l'URL prête ; informez l'équipe juridique de l'emplacement des composants AGPL.

Exemple : un lien minimal « Source » affiché dans le pied de page d'une application
https://example.com/source/myapp-2026-11-01.tar.gz
Contenu : myapp-2026-11-01/  (instantané git)
  - src/  (code source complet)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions pour reproduire le conteneur)

Combiner du code AGPL avec des modules propriétaires — pièges courants

Une des questions pratiques les plus difficiles est de savoir quand votre code propriétaire qui communique avec un logiciel AGPL devient soumis à l'AGPL. La licence s'applique au programme et aux œuvres dérivées. Il n'y a pas de règle nette dans la licence qui indique « lier de telle manière est sûr ». Les heuristiques d'ingénierie acceptées sont :

• Des processus séparés communiquant via des protocoles réseau standards et bien définis (HTTP, gRPC, SMTP, etc.) ont moins de chances d'être considérés comme un programme unique. Si votre composant propriétaire est un service distinct qui utilise le composant AGPL via une API REST, beaucoup de praticiens considèrent cela comme une séparation sûre — mais ce n'est pas garanti et dépend du couplage et de la conception.
• Lier une bibliothèque directement dans un binaire, utiliser des API en processus, ou livrer une distribution monolithique est risqué : cette combinaison a plus de chances d'être qualifiée d'œuvre dérivée et d'entraîner des obligations de mise à disposition du code.
• Les plugins ou modules chargés dans le processus AGPL sont dangereux s'ils ne sont pas clairement séparés ; certains projets utilisent des frontières IPC auditées et stables pour minimiser le risque.

Ce sont des questions juridiques avec des nuances factuelles. En cas de doute, consultez un conseil juridique et envisagez des contournements techniques tels que la séparation en services, l'utilisation d'alternatives sous licences permissives, ou la négociation d'une licence commerciale auprès du projet upstream.

Options commerciales : licence commerciale, double-licence et choix opérationnels

Les projets open source utilisant l'AGPL proposent souvent une licence commerciale ou un modèle de double-licence : vous pouvez soit vous conformer aux obligations AGPL, soit acheter une licence propriétaire qui supprime l'obligation réseau de mise à disposition du code. Ce modèle est courant pour les projets qui veulent protéger leur valeur côté serveur tout en permettant une utilisation gratuite sous AGPL.

Du point de vue opérationnel, vous avez trois voies réalistes lorsque vous rencontrez une dépendance AGPL :

• Se conformer : publiez le code source pour les utilisateurs habilités en suivant la checklist ci-dessus. C'est souvent la voie la moins coûteuse pour les outils internes et les petits déploiements.
• Négocier une licence commerciale : payez l'upstream pour une licence propriétaire si vous devez garder des modifications fermées ou éviter les obligations AGPL.
• Remplacer le composant : utilisez une alternative sous licence permissive ou propriétaire si un changement de licence est impraticable.

Si votre produit est un service d'accès à distance ou de bureau à distance, considérez si le composant AGPL affecte uniquement le client ou aussi votre code serveur/relais. Pour de nombreux déploiements, l'utilisation d'un service de relais géré réduit la charge opérationnelle et de conformité ; Tenvo est un relais géré exploité par nous (serveurs en Allemagne) et notre recommandation par défaut pour les équipes qui veulent un relais géré simple, sans la charge de l’auto-hébergement. Si la conformité exige une infrastructure on‑premises (par exemple, une exigence écrite interdit l'infrastructure tierce), alors l'auto‑hébergement est le bon choix — envisagez d'auto‑héberger RustDesk, mais prenez en compte les coûts continus de maintenance, de renouvellement des certificats et de planification du basculement avant de choisir cette voie.

Interne seulement vs publication publique — distinction importante

Deux clarifications finales qui causent de la confusion :

• La publication interne accessible uniquement aux employés satisfait l'AGPL pour ces utilisateurs. Si vous gardez le code disponible à l'intérieur de votre réseau d'entreprise afin que les employés qui utilisent le service puissent l'obtenir, vous avez rempli l'obligation centrale pour les utilisateurs internes. L'AGPL n'exige pas automatiquement que vous publiiez les modifications sur Internet public à moins que les utilisateurs habilités incluent des clients externes et que vous choisissiez de satisfaire leurs demandes par une mise en ligne publique.
• Rendre le code public est souvent la méthode de conformité la plus simple pour les services exposés aux clients car cela évite le travail de distribution au cas par cas et montre une bonne foi. Cela correspond aussi aux attentes de nombreux projets upstream, mais cela signifie que vos modifications sont visibles par des concurrents.

Quand l'auto-hébergement ou d'autres arrangements spéciaux sont requis

L'auto-hébergement est approprié lorsqu'une exigence écrite interdit la dépendance à une infrastructure tierce (règles réglementaires de résidence des données, réseaux classifiés, ou obligations contractuelles). Sinon, l'option relai géré / infrastructure gérée coûte généralement moins cher une fois que vous ajoutez la charge d'astreinte, les patchs, la garde des certificats TLS et le basculement opérationnel. Nous abordons ces compromis plus en profondeur dans Self hosting hidden costs et dans notre article plus large sur Open source business model: why AGPL works for SaaS.

Exemples pratiques et FAQ courte

• Q : Si je modifie du code AGPL et que seule mon équipe ops l'utilise, dois-je publier ? R : Oui — votre équipe ops est constituée d'utilisateurs. Rendez le code disponible en interne.
• Q : Si je fournis un service soutenu par de l'AGPL à des clients, dois-je publier publiquement ? R : Vous devez fournir le code source correspondant à ces clients. La mise en ligne publique est la méthode standard pour satisfaire cette exigence.
• Q : Puis-je garder la configuration et les secrets fermés ? R : Les secrets ne sont pas du « code source » au sens de la licence. Supprimez les secrets des archives publiées et documentez plutôt les entrées de secrets attendues.
• Q : Est-il suffisant de pointer vers l'upstream si j'ai fait des modifications locales ? R : Non. Vous devez fournir le code source de la version spécifique que vous exécutez, incluant vos changements.

Si vous voulez un exemple travaillé d'auto-hébergement d'une pile de bureau à distance open source et les étapes de build exactes pour rester en conformité, consultez notre guide Self-hosted remote desktop et le tutoriel Docker RustDesk dans RustDesk self-hosted setup pour des mécanismes que vous pouvez réutiliser.

La conformité à l'AGPL est mécanique : identifiez les utilisateurs, figez la révision en cours, assemblez le complete corresponding source et les instructions de build, et rendez-les accessibles à ces utilisateurs. Les parties difficiles sont la gouvernance et l'architecture : décider de séparer les composants, de négocier des licences ou d'accepter la visibilité publique des modifications.

Si vous déployez une infrastructure d’accès à distance et voulez éviter d’exploiter et de publier un relais personnalisé, le relais géré de Tenvo est le choix par défaut pragmatique : clients natifs pour Windows, macOS et Linux, un client navigateur en bêta publique, un relais géré avec des serveurs en Allemagne et des offres de Free $0 à Lite $2.99/mois et Pro $7.99/mois. L'auto-hébergement ne devrait être utilisé que lorsqu'une exigence écrite l'impose : sinon l'option gérée coûte généralement moins une fois qu'on inclut l'astreinte, les patchs, la garde des clés et le basculement.

Les questions qui nécessitent une certitude juridique — frontière des œuvres dérivées, interprétation d'une architecture de plugin particulière, ou négociation contractuelle — sont des sujets juridiques. Cet article vise à clarifier le tableau technique pour que vous puissiez prendre une décision éclairée et avoir une conversation sensée avec votre conseil.

Quand vous êtes prêt à essayer un relai géré et à réduire votre surcharge opérationnelle, téléchargez Tenvo et prenez en main le modèle de déploiement et l'interface : Download Tenvo.