Critères d'inclusion
Europe Alternatives répertorie à la fois des entreprises commerciales européennes et des projets open-source. Chaque type a ses propres critères d'inclusion décrits ci-dessous.
Entreprises commerciales
1. Siège européen
L'entreprise doit avoir son siège dans un pays européen. Cela ne se limite pas aux États membres de l'UE -- les entreprises de tout pays européen sont éligibles, y compris ceux de l'EEE, de l'AELE et d'autres nations européennes.
2. Actionnariat majoritairement européen
La majorité des actionnaires de l'entreprise doit être européenne. Si une entreprise européenne a une société mère ou un actionnaire majoritaire non européen, elle n'est pas éligible. Cela garantit que les entreprises listées sont véritablement contrôlées par des Européens.
3. Service SaaS ou cloud
L'entreprise doit proposer un produit ou service de type logiciel en tant que service (SaaS) ou basé dans le cloud. Cela inclut les logiciels hébergés, l'infrastructure cloud, les services de plateforme et autres solutions délivrées par le web.
Pays européens et accords commerciaux
Pour référence, voici les principaux blocs économiques et accords européens. Les entreprises siégeant dans l'un de ces pays sont éligibles.
Union européenne (UE) -- 27 États membres
Autriche, Belgique, Bulgarie, Croatie, Chypre, République tchèque, Danemark, Estonie, Finlande, France, Allemagne, Grèce, Hongrie, Irlande, Italie, Lettonie, Lituanie, Luxembourg, Malte, Pays-Bas, Pologne, Portugal, Roumanie, Slovaquie, Slovénie, Espagne, Suède
Espace économique européen (EEE) -- 30 pays
Les 27 États membres de l'UE plus l'Islande, le Liechtenstein et la Norvège. L'EEE étend le marché intérieur de l'UE à ces trois pays de l'AELE, assurant la libre circulation des biens, services, capitaux et personnes.
Association européenne de libre-échange (AELE) -- 4 pays
Islande, Liechtenstein, Norvège et Suisse. Alors que l'Islande, le Liechtenstein et la Norvège participent à l'EEE, la Suisse maintient sa relation avec l'UE par des accords bilatéraux.
Autres pays européens
Royaume-Uni, Ukraine, Moldavie, Albanie, Serbie, Monténégro, Macédoine du Nord, Bosnie-Herzégovine, Kosovo, Géorgie, Arménie, Turquie (partie européenne), Monaco, Andorre, Saint-Marin et Cité du Vatican. Les entreprises de ces pays sont également éligibles.
Projets Open-Source
Les projets open-source sont listés dans un tableau séparé. Contrairement aux entreprises commerciales, ils n'ont pas besoin d'un siège ou d'un actionnariat européen. Pour être listé, un projet doit répondre aux critères suivants.
1. Licence open-source reconnue
Le projet doit être publié sous une licence open-source reconnue par l'OSI (par exemple MIT, Apache 2.0, GPL-3.0, AGPL-3.0, MPL-2.0). Les projets utilisant des licences "source available", "non commercial", "Commons Clause" ou similairement restrictives ne sont pas éligibles.
2. Auto-hébergeable avec documentation officielle
Le projet doit être réaliste à auto-héberger, avec une documentation d'installation officielle et au moins un chemin de déploiement standard, comme :
- Docker et Docker Compose
- Helm charts ou manifestes Kubernetes
- Paquets système (deb, rpm, etc.)
"Compiler depuis les sources" sans guide de déploiement clair n'est pas suffisant.
3. Activement maintenu
Le projet doit montrer une maintenance continue : une release ou une activité de commit significative au cours des 12 derniers mois. Une exception peut être faite pour les projets explicitement en "mode maintenance" si leur documentation opérationnelle et de sécurité est solide.
4. Prêt pour la production (Day-2 Readiness)
La documentation doit couvrir au minimum les domaines suivants pour garantir que le projet est viable pour une utilisation en production au-delà de l'installation initiale :
- Mises à jour et migrations -- comment mettre à jour en toute sécurité entre les versions
- Sauvegarde et restauration ou export/import -- comment protéger et déplacer les données
5. Contact sécurité / voie de divulgation
Le projet doit fournir un moyen clair de signaler les vulnérabilités de sécurité de manière responsable. Les méthodes acceptables incluent :
- Un fichier SECURITY.md dans le dépôt
- Une adresse e-mail de sécurité dédiée
- Un processus de divulgation documenté ou un programme de bug bounty
6. Pas de "piège SaaS"
La version auto-hébergée doit être utilisable de manière significative sans nécessiter un backend cloud propriétaire du fournisseur pour les fonctionnalités principales. Les fonctionnalités peuvent différer entre les offres auto-hébergées et hébergées par le fournisseur, mais le produit principal doit fonctionner de manière indépendante.