Europe Alternatives

Criteres d'inclusion

Europe Alternatives repertorie a la fois des entreprises commerciales europeennes et des projets open-source. Chaque type a ses propres criteres d'inclusion decrits ci-dessous.

Entreprises commerciales

1. Siege europeen

L'entreprise doit avoir son siege dans un pays europeen. Cela ne se limite pas aux Etats membres de l'UE -- les entreprises de tout pays europeen sont eligibles, y compris ceux de l'EEE, de l'AELE et d'autres nations europeennes.

2. Actionnariat majoritairement europeen

La majorite des actionnaires de l'entreprise doit etre europeenne. Si une entreprise europeenne a une societe mere ou un actionnaire majoritaire non europeen, elle n'est pas eligible. Cela garantit que les entreprises listees sont veritablement controlees par des Europeens.

3. Service SaaS ou cloud

L'entreprise doit proposer un produit ou service de type logiciel en tant que service (SaaS) ou base dans le cloud. Cela inclut les logiciels heberges, l'infrastructure cloud, les services de plateforme et autres solutions delivrees par le web.

Pays europeens et accords commerciaux

Pour reference, voici les principaux blocs economiques et accords europeens. Les entreprises siegeant dans l'un de ces pays sont eligibles.

Union europeenne (UE) -- 27 Etats membres

Autriche, Belgique, Bulgarie, Croatie, Chypre, Republique tcheque, Danemark, Estonie, Finlande, France, Allemagne, Grece, Hongrie, Irlande, Italie, Lettonie, Lituanie, Luxembourg, Malte, Pays-Bas, Pologne, Portugal, Roumanie, Slovaquie, Slovenie, Espagne, Suede

Espace economique europeen (EEE) -- 30 pays

Les 27 Etats membres de l'UE plus l'Islande, le Liechtenstein et la Norvege. L'EEE etend le marche interieur de l'UE a ces trois pays de l'AELE, assurant la libre circulation des biens, services, capitaux et personnes.

Association europeenne de libre-echange (AELE) -- 4 pays

Islande, Liechtenstein, Norvege et Suisse. Alors que l'Islande, le Liechtenstein et la Norvege participent a l'EEE, la Suisse maintient sa relation avec l'UE par des accords bilateraux.

Autres pays europeens

Royaume-Uni, Ukraine, Moldavie, Albanie, Serbie, Montenegro, Macedoine du Nord, Bosnie-Herzegovine, Kosovo, Georgie, Armenie, Turquie (partie europeenne), Monaco, Andorre, Saint-Marin et Cite du Vatican. Les entreprises de ces pays sont egalement eligibles.

Projets Open-Source

Les projets open-source sont listes dans un tableau separe. Contrairement aux entreprises commerciales, ils n'ont pas besoin d'un siege ou d'un actionnariat europeen. Pour etre liste, un projet doit repondre aux criteres suivants.

1. Licence open-source reconnue

Le projet doit etre publie 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 eligibles.

2. Auto-hebergeable avec documentation officielle

Le projet doit etre realiste a auto-heberger, avec une documentation d'installation officielle et au moins un chemin de deploiement standard, comme :

  • Docker et Docker Compose
  • Helm charts ou manifestes Kubernetes
  • Paquets systeme (deb, rpm, etc.)

"Compiler depuis les sources" sans guide de deploiement clair n'est pas suffisant.

3. Activement maintenu

Le projet doit montrer une maintenance continue : une release ou une activite de commit significative au cours des 12 derniers mois. Une exception peut etre faite pour les projets explicitement en "mode maintenance" si leur documentation operationnelle et de securite est solide.

4. Pret 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-dela de l'installation initiale :

  • Mises a jour et migrations -- comment mettre a jour en toute securite entre les versions
  • Sauvegarde et restauration ou export/import -- comment proteger et deplacer les donnees

5. Contact securite / voie de divulgation

Le projet doit fournir un moyen clair de signaler les vulnerabilites de securite de maniere responsable. Les methodes acceptables incluent :

  • Un fichier SECURITY.md dans le depot
  • Une adresse e-mail de securite dediee
  • Un processus de divulgation documente ou un programme de bug bounty

6. Pas de "piege SaaS"

La version auto-hebergee doit etre utilisable de maniere significative sans necessiter un backend cloud proprietaire du fournisseur pour les fonctionnalites principales. Les fonctionnalites peuvent differer entre les offres auto-hebergees et hebergees par le fournisseur, mais le produit principal doit fonctionner de maniere independante.