Outil interne
Outillage de développement, tableaux de bord, scripts d’exploitation, applications métier utilisées uniquement par les salariés.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Non |
| Un tiers interagit-il avec lui par un réseau ? | Non — les salariés ne sont pas des tiers |
| Le produit est-il un bien de consommation ? | Non |
Aucun mécanisme de copyleft ne se déclenche. C’est le scénario le plus libre.
Le verdict par famille
| Famille | Verdict | Raison |
|---|---|---|
| Permissive | ● | Attribution non due faute de distribution, mais bonne pratique de créditer |
| Copyleft faible (MPL, EPL, LGPL) | ● | Pas de distribution, pas de réciprocité |
| Copyleft fort (GPL) | ● | La GPL ne se déclenche qu’à la distribution |
| Copyleft réseau (AGPL) | ◐ | Voir ci-dessous |
| Source-available (BSL, SSPL, ELv2) | ◐ | Lire les restrictions : certaines visent l’usage, pas seulement la revente |
Le cas de l’AGPL
L’article 13 vise « tous les utilisateurs qui interagissent à distance par un réseau ». Rien n’exclut les salariés. Une lecture stricte impose donc, pour un outil interne AGPL modifié, d’offrir le code source aux utilisateurs internes.
En pratique c’est indolore : publier le source sur le dépôt interne suffit. Mais l’obligation existe, et elle mérite d’être connue plutôt que découverte.
Les licences source-available
Contrairement au copyleft, elles restreignent parfois l’usage lui-même, sans qu’il y ait distribution :
- une BSL-1.1 interdit typiquement l’usage en production au-delà de la concession additionnelle accordée par l’éditeur ;
- une Elastic License 2.0 interdit de fournir le produit en service managé, ce qui peut couvrir une plateforme interne mutualisée entre filiales ;
- Commons Clause retire le droit de vendre, mais pas celui d’utiliser.
Il faut donc les lire, alors même que le scénario est le plus permissif de tous.
Le seul vrai risque : la frontière bouge
C’est la totalité du risque de ce scénario, et il est réel.
| Événement | Effet |
|---|---|
| L’outil interne devient un produit | Tous les mécanismes se réveillent d’un coup |
| L’outil est déployé chez un client ou un partenaire | Distribution |
| L’outil est transmis à une filiale, personne morale distincte | Distribution — une filiale est un tiers |
| Un prestataire externe reçoit le binaire | Distribution |
| L’image de conteneur est publiée sur un registre public | Distribution |
| L’outil est ouvert à des utilisateurs externes, même gratuitement | L’AGPL se déclenche |
Le point sur la filiale surprend souvent : la distribution intra-groupe entre deux personnes morales distinctes est une distribution au sens des licences libres. La consolidation comptable n’a aucun effet ici.
La recommandation. Appliquer malgré tout la politique de licences aux outils internes, au moins en mode avertissement. Non pas parce que l’obligation existe aujourd’hui, mais pour que la promotion en produit ne se heurte pas, deux ans plus tard, à un composant impossible à retirer.
Ce que le CRA ajoute
Un outil interne n’est pas un produit comportant des éléments numériques : il n’est pas mis sur le marché. Il sort du champ du règlement — voir Le périmètre.
Cela ne signifie pas qu’il échappe à toute exigence : les outils de la chaîne de construction participent à la sécurité des produits que vous mettez sur le marché, et relèvent à ce titre de la maîtrise de la chaîne d’approvisionnement.