Cette phrase, je l'entends plusieurs fois par mois, dans la bouche de dirigeants et de DSI qui découvrent six à dix-huit mois plus tard que tous les projets open source ne se valent pas.
Une mauvaise sélection OSS coûte plus cher qu'un outil propriétaire mal choisi — parce que les signaux de fragilité sont moins visibles. Voici la grille en 12 questions que j'applique avant chaque adoption, structurée en 4 dimensions, tenable en moins de deux heures par projet et accessible sans expertise technique avancée.Pourquoi une grille de décision existe pour ça
Le paysage open source en 2026 n'est pas uniforme. À une extrémité, PostgreSQL — trente ans d'existence, des milliers de contributeurs, gouvernance multi-vendor sans propriétaire unique.
À l'autre, un projet GitHub maintenu par trois personnes en soirée, sans modèle économique, exposé au risque d'abandon. Les deux portent l'étiquette « open source » et se présentent visuellement de la même façon sur leurs pages d'accueil. Sans grille de lecture, rien ne les distingue.
S'ajoute à cette dispersion structurelle un phénomène plus récent : les relicences sous pression commerciale. Entre 2021 et 2024, trois projets majeurs ont basculé de licences open source standard vers des licences dites source-available — Elasticsearch en janvier 2021, Terraform en août 2023, Redis en mars 2024.
À chaque fois, des entreprises qui s'étaient appuyées sur ces outils ont dû arbitrer en urgence : migrer vers un fork communautaire, payer une licence commerciale, ou changer de stack.
Aucune de ces décisions n'aurait été facile à anticiper sans poser, avant l'adoption, des questions sur la gouvernance et le modèle économique du mainteneur.
Six à dix-huit mois de retard sur un projet, un coût de migration imprévu, et une perte de confiance interne durable sur le sujet open source. La plupart de ces situations sont évitables avec une grille de lecture appliquée avant l'adoption — pas après le premier incident.
Les 4 dimensions de la grille
L'évaluation d'un projet open source se fait en quatre temps successifs. Chaque dimension durcit ou allège les exigences des suivantes — un besoin court rend les exigences de gouvernance plus tolérables, un besoin critique de longue durée les durcit.
L'ordre n'est pas négociable : qualifier le besoin avant de juger l'outil évite de tomber amoureux d'un projet inadapté.
Dimension Besoin : qualifier avant de juger
Avant de juger un outil, qualifier le besoin. Cette dimension élimine vite et se traite en moins d'une heure de réflexion interne. C'est aussi la plus souvent escamotée par les décideurs pressés — alors qu'elle conditionne la pondération de toute la suite.
Sans horizon clair, sans criticité documentée, sans cartographie de l'existant, l'audit technique d'un projet open source perd son sens.
Quel horizon temporel ?
Six mois, trois ans, dix ans ? Attention à la confusion fréquente entre durée du contrat et durée de vie de la donnée — un ERP signé pour trois ans, c'est dix ans de données comptables derrière
Critique ou périphérique ?
DSi l'outil disparaît demain matin, combien de temps tient votre activité avant impact métier visible ? Plus de 24 h = périphérique. Moins de 4 h = critique.
Équivalent libre mature ?
rois sources indépendantes citent le même projet OSS comme référence sur votre besoin ? L'équivalent mature existe. Aucune ? Vous êtes sur une niche — à assumer en durcissant le reste de la grille.
Q1 et Q3 sont éliminatoires, Q2 est sérieuse. Sans horizon défini, la pondération des autres questions devient arbitraire. Sans cartographie de l'existant, l'évaluation des projets de niche se fait à l'aveugle — la règle empirique des trois sources indépendantes suffit pour trancher en trente minutes.
Dimension Projet : la plus chargée
Le besoin est qualifié. Vient la dimension la plus dense de la grille : la solidité du projet open source lui-même. Quatre questions qui couvrent la gouvernance, l'activité du dépôt, la diversité contributrice et le modèle économique du mainteneur. C'est ici que la grille fait son travail le plus dur — distinguer un projet OSS solide d'un projet en apparence solide mais fragile, sur des signaux visibles sans expertise technique.
La Q4 porte sur la forme juridique qui possède et oriente le projet : fondation neutre (Apache, Linux Foundation, OSGeo…), association indépendante (Document Foundation, PostgreSQL Global Development Group…), entreprise unique avec gouvernance ouverte (Odoo SA, Nextcloud GmbH…), ou entreprise unique avec gouvernance fermée — la configuration la plus risquée, et c'est exactement celle qui a produit les trois relicences majeures de la décennie.
La Q5 mesure l'activité réelle du dépôt — quatre onglets GitHub suffisent en cinq minutes, sans lire une seule ligne de code : Code (date du dernier commit), Releases (cadence des versions), Issues (ratio open/closed et délai de réponse), Insights/Pulse (courbe d'activité sur 12 mois). Un projet abandonware est un projet mort, même si son code est techniquement excellent à l'instant T.
La Q6 quantifie la concentration contributrice — quel pourcentage des commits vient d'une seule entreprise ? Au-delà de 60 %, vous êtes face à un single-vendor déguisé dont la pérennité repose entièrement sur la santé d'une seule structure.
La Q7 identifie comment le mainteneur gagne sa vie — fondation + sponsors, open core, support et services, SaaS managé, dual-licensing, ou donations et bénévolat. Six modèles dominants, dont trois pérennes en pratique et un structurellement risqué (le SaaS managé en concurrence frontale avec les hyperscalers).
Le triplet Q4 + Q6 + Q7 dessine le profil structurel de risque du projet : single-vendor + concentration contributrice + modèle SaaS managé sous pression hyperscaler. Combiné à la dimension Licence ci-dessous, il devient un outil prédictif — pas seulement descriptif.
Dimension Licence : OSI ou pas, point final
Deux questions courtes mais décisives. La licence n'est pas un détail juridique — c'est ce qui détermine si vous pouvez réellement utiliser, modifier, redistribuer et survivre à un changement de gouvernance du projet.
La Q8 est éliminatoire : la licence est-elle reconnue par l'Open Source Initiative ? Le test prend cinq minutes — lire le fichier LICENSE à la racine du dépôt, identifier le nom exact, vérifier sa présence sur opensource.org/licenses. Si la licence n'y figure pas, vous adoptez une licence source-available, et il faut traiter le projet comme un produit propriétaire avec analyse juridique au cas par cas.
Depuis 2018, le marché s'est rempli de licences qui se présentent comme open source mais ne le sont pas : SSPL (MongoDB, Redis), BSL (HashiCorp, MariaDB), Elastic License v2, Redis Source Available License — toutes interdisent au moins un usage commercial standard, généralement le SaaS managé concurrent.
Beaucoup de pages marketing 2026 utilisent abondamment le vocabulaire « open », « community edition », « free tier » pour des licences que l'OSI a explicitement rejetées. Le terme officiel de l'OSI pour ces licences est « fauxpen » — contraction de « faux open source ». Pour le décideur, la règle est simple : si la licence n'est pas sur opensource.org/licenses, elle est source-available. Le mot « open » sur la page d'accueil ne suffit pas.
La Q9 est sérieuse : le projet a-t-il déjà changé de licence ? L'historique git, la page Wikipédia du projet et la presse spécialisée (LWN, The Register, Hacker News) répondent en quinze minutes.
Un précédent de relicence vers du source-available est un signal d'alerte fort, surtout combiné à Q4 (gouvernance single-vendor) et Q7 (modèle SaaS managé).
Ces trois signaux convergents forment le triangle prédictif des relicences — c'est exactement la configuration qui précédait les bascules d'Elastic, HashiCorp et Redis avant qu'elles ne surviennent.
Dimension Exécution : où le code échoue chez vous
Le besoin est qualifié, le projet est jugé sain, la licence est OSI. Reste la dernière dimension — la plus terrain : pouvez-vous réellement déployer et faire vivre cet outil ? Trois questions qui décident souvent du succès ou de l'échec de l'adoption.
La Q10 force la décision avant l'adoption : qui prend la responsabilité opérationnelle ? Le test : « Si la personne qui a installé l'outil quitte l'entreprise demain, qui prend le relais, dans quel délai, à quel coût ? » Sans réponse claire, vous tombez dans la configuration qui produit les abandons silencieux à dix-huit mois — l'outil tourne grâce à la personne qui l'a installé, puis cette personne change de poste et plus personne ne sait comment ça marche.
La Q11 distingue le support de la capacité de mise en œuvre. Q10 répond à « qui déploie au quotidien » ; Q11 répond à « qui intervient quand ça casse en production, hors heures ouvrées ». Pour un outil critique dans une PME sans équipe IT 24/7, sans réponse claire à « qui répond à deux heures du matin », l'outil ne peut pas être déployé en production critique sans risque inacceptable.
Cette question est informative au niveau de la grille parce qu'on peut toujours acheter du support — mais elle est de facto sérieuse pour la plupart des PME.
La Q12 démonte le mythe le plus tenace : « l'open source, c'est gratuit ». Le code l'est. Le déploiement, la formation, la maintenance, l'hébergement, le support et la sortie ne le sont pas. Le TCO d'un outil open source sur cinq ans est rarement nul et souvent du même ordre de grandeur qu'un outil propriétaire équivalent — parfois inférieur, parfois supérieur, jamais nul. Calculer le TCO honnêtement, c'est ce qui distingue une décision rationnelle d'une décision émotionnelle.
Un outil open source économise systématiquement la ligne licence et souvent une partie du support obligatoire. Il ne change rien au déploiement, à la formation, à l'hébergement et au coût de sortie. Le solde sur cinq ans est généralement favorable à l'open source pour les outils structurants — mais l'écart réel est de l'ordre de trente à cinquante pour cent, pas de quatre-vingt-dix pour cent comme un discours superficiel pourrait le laisser croire.
Comment utiliser la grille — l'arbre de décision
Le verdict final repose sur deux règles simples, applicables sans calcul complexe.
Arbre de décision — verdict global sur un projet open source
Règle 1 — Éliminatoire. Un seul échec sur une question éliminatoire (Q1, Q3, Q4, Q5, Q8) suffit à écarter le projet. Ces questions mesurent des ruptures non négociables — sans horizon, sans gouvernance saine, sans licence OSI, sans activité de code, l'évaluation ne peut pas continuer.
Règle 2 — Cumul sérieux. Trois échecs ou plus sur les questions sérieuses (Q2, Q6, Q7, Q9, Q10, Q12) déclenchent un rejet par effet d'amplification. Deux signaux sérieux convergents sur la même dimension (par exemple Q4 single-vendor + Q6 concentration + Q7 SaaS managé) sont un signal d'alerte plus fort que trois signaux dispersés.
En pratique, sur les projets rencontrés en mission, trois configurations reviennent. Odoo Community pour un ERP PME passe la grille avec deux sérieuses (Q2 critique, Q6 concentration Odoo SA) — verdict Recommandé sous condition de prestataire identifié.
Un outil SIG de niche sans gouvernance neutre échoue dès la Q4 — verdict Stop, redirection vers un équivalent sous OSGeo ou horizon raccourci.
Un outil source-available détecté en évaluation par un éditeur logiciel échoue dès la Q8 — verdict Stop, redirection vers le fork sous fondation neutre (OpenSearch, OpenTofu, Valkey selon le cas).
Ce qu'il faut retenir
| Question | Verdict | Définit | Exclut |
|---|---|---|---|
| Q1 — Horizon temporel | ❌ Éliminatoire | La tolérance au risque sur tout le reste de la grille | Les choix faits sans visibilité à 5 ou 10 ans |
| Q2 — Criticité opérationnelle | ⚠️ Sérieuse | Le niveau d'exigence support et SLA | Les outils périphériques traités comme critiques (et inversement) |
| Q3 — Équivalent libre mature | ❌ Éliminatoire | Si vous êtes sur du standard ou de la niche | Les choix aveugles sans cartographie de l'existant |
| Q4 — Gouvernance | ❌ Éliminatoire | La pérennité juridique du projet | Le risque de relicence unilatérale par un éditeur unique |
| Q5 — Activité du dépôt | ❌ Éliminatoire | La vitalité réelle du projet | Les abandonwares techniquement excellents mais sans avenir |
| Q6 — Diversité contributrice | ⚠️ Sérieuse | Le degré de dépendance à un seul acteur | Les single-vendors déguisés en projets communautaires |
| Q7 — Modèle économique du mainteneur | ⚠️ Sérieuse | La soutenabilité financière du projet | Les modèles fragiles (bénévolat pur, SaaS sous pression cloud) |
| Q8 — Type de licence | ❌ Éliminatoire | Vos droits réels d'usage et de redistribution | Les licences source-available qui se font passer pour de l'OSI |
| Q9 — Historique de relicence | ⚠️ Sérieuse | La probabilité d'une future bascule | Les projets dont la direction a déjà choisi la rupture une fois |
| Q10 — Capacité de mise en œuvre | ⚠️ Sérieuse | Qui porte la responsabilité opérationnelle | Les adoptions « on verra bien » qui produisent les abandons à 18 mois |
| Q11 — Support disponible | ✅ Informative | Qui répond à 2 h du matin sur un incident critique | Les outils critiques sans SLA contractualisable |
| Q12 — TCO sur 5 ans | ⚠️ Sérieuse | Le coût total honnête, licence évitée comprise | Le mythe du « c'est gratuit donc zéro euro » |
La grille en 12 questions ne remplace pas votre jugement — elle structure l'information pour que vous puissiez décider, en deux heures par projet, sur des signaux visibles sans expertise technique avancée.
Trois idées-leviers à emporter. L'open source n'est pas gratuit, il est libre — le TCO n'est jamais nul, et la confusion entre les deux a produit des milliers d'abandons silencieux.
La gouvernance prédit tout le reste — un projet sous fondation neutre avec DCO n'a pas relicencié en quarante ans, un projet single-vendor avec CLA l'a fait trois fois en deux ans.
Une licence est OSI ou ne l'est pas — trente secondes de vérification sur opensource.org/licenses évitent un risque juridique structurel.
Cette grille s'inscrit dans la posture détaillée dans mon manifeste Pourquoi je n'utilise (presque) que de l'open source, et elle complète l'analyse des mécanismes de fragilisation 2026 développée dans L'IA va-t-elle tuer l'open source ?.
Le livre blanc téléchargeable approfondit chaque question avec des fiches détaillées, décortique les trois relicences majeures (Elasticsearch, Terraform, Redis), traite l'arbitrage internalisation vs externalisation, et livre l'annexe Panorama des licences open source promise dans l'article #1.
Choisir un outil open source, c'est signer un contrat avec une communauté — pas avec un éditeur. La gouvernance, c'est la clause de résiliation.
La licence, c'est le périmètre des droits. Le TCO, c'est la réalité économique derrière la gratuité apparente.— Mattieu Pottier