« GPL, MIT, licence propriétaire avec palier gratuit » : ces trois régimes cohabitaient sans qu’aucun n’ait jamais fait l’objet d’une vérification formelle, sur un projet où l’équipe technique avait ajouté ses outils de test au fil des besoins, sans validation préalable. Aucun problème ne s’était encore posé, mais la situation aurait pu mal tourner : l’un des outils, gratuit pour un usage individuel, imposait une licence payante dès qu’il tournait dans un pipeline d’intégration continue partagé par plusieurs développeurs.
Ce genre de situation ne relève pas d’une négligence isolée : la plupart des développeurs ajoutent un outil de test parce qu’il résout un problème immédiat, rarement en vérifiant d’abord les conditions d’usage commercial de sa licence. Pour une agence qui facture ses prestations à des clients, cette vérification devient pourtant une étape à part entière avant toute adoption d’outil dans un pipeline.
Les questions à poser avant d’ajouter un outil
- La licence autorise-t-elle explicitement un usage commercial, ou se limite-t-elle à un usage personnel ou éducatif ?
- Le modèle de licence dépend-il du nombre de postes, du nombre d’exécutions, ou du nombre de dépôts couverts ?
- L’exécution dans un environnement de CI hébergé compte-t-elle comme un usage distinct de l’exécution en local, selon les conditions de l’éditeur ?
- Une clause de la licence impose-t-elle une attribution visible, une redistribution du code sous la même licence, ou une restriction de modification ?
- L’outil dépend-il lui-même d’une bibliothèque tierce dont la licence diffère de la sienne ?
Le cas rencontré sur ce projet
L’outil en question proposait une offre gratuite limitée à un usage individuel non commercial, avec une clause explicite exigeant une licence payante dès qu’il s’exécutait dans un contexte d’équipe ou d’entreprise, quel que soit le nombre de postes. La CI du projet, hébergée et partagée par cinq développeurs facturant leur temps au client, tombait sans ambiguïté dans ce second cas.
Extrait relevé dans le fichier LICENSE de l'outil concerné :
"Free for individual, non-commercial use only.
Any use within a team, company, or commercial CI pipeline
requires a paid Team or Enterprise license."
La régularisation a consisté à souscrire la licence payante appropriée, dont le coût a été intégré au budget d’outillage du projet, plutôt que de continuer à utiliser l’outil dans une zone grise juridique.
Documenter la décision, pas seulement la corriger
Au-delà de la régularisation ponctuelle, l’équipe a ajouté une check-list courte au processus d’ajout de tout nouvel outil de test ou de qualité, consultée avant chaque proposition d’ajout à la CI d’un projet client, avec une case dédiée à la vérification de licence, au même titre que la vérification de maintenance active du projet.
Ce que cette vérification ne couvre pas
- Elle ne remplace pas un avis juridique formel pour les cas ambigus ou les contrats client particulièrement stricts sur les dépendances tierces.
- Elle ne dispense pas de revérifier la licence lors d’une montée de version majeure de l’outil : certains éditeurs changent leur modèle de licence entre deux versions.
- Elle ne concerne pas seulement les outils de test : la même discipline s’applique à toute dépendance ajoutée au projet, mais les outils de test échappent souvent à cette vigilance car perçus comme secondaires par rapport au code applicatif.
Un outil gratuit pour soi seul ne l’est pas nécessairement pour une équipe qui facture son temps à un client.
En résumé
Vérifier la licence d’un outil de test avant de l’ajouter à un pipeline commercial prend quelques minutes et évite un risque contractuel qui peut coûter bien davantage, une fois l’outil ancré dans les habitudes de toute une équipe. Sur ce projet, trois régimes de licence différents cohabitaient déjà sans vérification préalable : la revue a permis d’en régulariser un avant qu’il ne devienne un problème pour le client.
