10.12 Code source ouvert contre code source fermé

Vue d’ensemble et motivation

Presque chaque système moderne est un mélange de logiciel que vous avez écrit, de logiciel que vous avez acheté, et de logiciel que vous avez pris gratuitement. Deux de ces trois viennent avec un choix fondamental : le logiciel est-il code source ouvert ou code source fermé ? Le logiciel à code source ouvert (OSS) est distribué sous une licence qui accorde à tous le droit d’utiliser, étudier, modifier, et redistribuer le code source, les instructions lisibles par un humain qui définissent le programme. Le logiciel à code source fermé, aussi appelé logiciel propriétaire, est distribué comme un produit fini dont le fournisseur garde le code source privé. Vous obtenez le droit de l’exécuter sous une licence, mais pas d’inspecter ou changer comment il fonctionne. Une catégorie intermédiaire, le logiciel à source disponible, publie la source pour la lecture mais restreint l’usage, la modification, ou la redistribution. Il est visible mais pas ouvert selon la définition standard.

Deux clarifications comptent avant de les comparer. Premièrement, « libre » est ambigu. La communauté distingue libre au sens de liberté (la liberté de modifier et partager, parfois écrit « libre ») du libre au sens de prix (coût zéro, « gratuit »). Le code source ouvert concerne la liberté, pas nécessairement le prix. Deuxièmement, les licences de code source ouvert se divisent en deux familles. Les licences permissives (comme MIT, BSD, et Apache 2.0) vous laissent faire presque tout, y compris intégrer le code dans un produit fermé. Les licences copyleft (comme la GNU General Public License, GPL) exigent que les œuvres dérivées que vous distribuez soient aussi publiées sous les mêmes termes ouverts, une règle de réciprocité parfois appelée « virale » par les critiques et « partage à l’identique » par les partisans.

Ce chapitre regarde le choix depuis deux côtés. En tant que consommateur, vous décidez d’adopter un composant à code source ouvert ou propriétaire. En tant que producteur, vous décidez si vous ouvrez en code source le logiciel que vous avez construit. Pour les grandes entreprises et spécialement le gouvernement, les deux décisions portent un poids bien au-delà du fichier de licence. Elles touchent aux marchés publics (chapitre 10.3), à la souveraineté numérique (chapitre 10.11), à la sécurité de chaîne d’approvisionnement (chapitre 4.2), à l’interopérabilité (chapitre 3.8), et au calcul construire-ou-acheter (chapitre 6.1).

Principes clés

La licence, pas le prix, définit « ouvert ». Lisez la licence ; gratuit et code source ouvert sont des affirmations différentes.
Aucun modèle n’est intrinsèquement plus sécurisé. Les deux peuvent être excellents ou négligents ; les pratiques autour du code comptent plus que son ouverture.
L’ouverture est un levier de réduction de dépendance. L’accès à la source est la protection ultime contre la dépendance au fournisseur.
Vous possédez toujours le fardeau opérationnel. Gratuit à acquérir n’est jamais gratuit à exploiter ; le coût total de possession raconte la vraie histoire.
Les différenciateurs restent fermés ; les commodités peuvent s’ouvrir. Ouvrez en code source ce qui ne vous distingue pas ; gardez ce qui le fait.
Le copyleft a des conséquences. Comprenez les obligations de réciprocité avant d’intégrer du code copyleft dans un produit que vous distribuez.
Une communauté vivante est un atout ; un dépôt abandonné est un passif. Jugez le projet, pas seulement la licence.

Recommandations

Évaluer un composant sur le projet, pas seulement la licence

Avant d’adopter toute dépendance, à code source ouvert ou propriétaire, évaluez sa santé : cadence de publication, nombre et diversité de mainteneurs, réactivité aux rapports de sécurité, et étendue d’adoption. Une bibliothèque à code source ouvert à mainteneur unique et un petit fournisseur propriétaire portent le même risque de facteur bus (le danger qu’un projet s’effondre si une ou quelques personnes clés partent). Favorisez les composants avec une large base de contributeurs ou un fournisseur financièrement solide, et enregistrez l’évaluation comme partie de la diligence raisonnable (chapitres 10.2, 4.2).

Lire et suivre les licences comme obligation de premier ordre

Maintenez un inventaire de chaque composant et sa licence, et appliquez une politique sur quelles familles de licence sont acceptables pour quels usages. La distinction critique est le copyleft. Le code permissif (MIT, Apache 2.0) peut généralement être intégré dans des produits fermés librement. Le copyleft fort (GPL) peut vous obliger à publier votre propre dérivé distribué sous les mêmes termes. Utilisez l’analyse de composition logicielle (SCA) automatisée, des outils qui scannent vos dépendances pour identifier les composants, licences, et vulnérabilités connues, et générez une nomenclature logicielle (SBOM), une liste formelle de chaque composant dans un produit (chapitres 10.3, 4.2).

Juger la sécurité par la pratique, pas par l’ouverture

Ne supposez pas que le code source ouvert est sûr à cause de l’argument des « nombreux yeux » (loi de Linus : « donné assez d’yeux, tous les bugs sont superficiels »). Et ne supposez pas que le code propriétaire est sûr à travers la sécurité par l’obscurité (la croyance erronée que cacher la source cache les défauts). Les nombreux yeux n’aident que si des gens qualifiés regardent réellement, et de nombreux projets largement utilisés sont maigrement maintenus. Les deux modèles portent un risque de chaîne d’approvisionnement : le code source ouvert à travers des dépendances compromises ou abandonnées, le propriétaire à travers du code opaque et des canaux de mise à jour que vous ne pouvez pas inspecter. Épinglez les versions, vérifiez la provenance, scannez continuellement, et surveillez les avis indépendamment du modèle (chapitre 4.2).

Concevoir pour la sortie et l’interopérabilité

Préférez les composants qui parlent des normes ouvertes et formats de données portables, pour pouvoir les remplacer plus tard (chapitres 3.8, 10.11). Avec le code source ouvert, vous gagnez la sortie ultime : si un projet cale, vous pouvez le bifurquer (créer et maintenir votre propre copie). Avec le logiciel propriétaire, négociez des protections à l’avance : export de données dans des formats ouverts, API documentées, et dépôt fiduciaire de code source (un arrangement légal où le fournisseur dépose la source auprès d’un tiers, libérée à vous si le fournisseur échoue). Concevez pour qu’aucun composant unique, de l’un ou l’autre type, ne puisse tenir votre système en otage.

Peser le coût total de possession, pas le prix affiché

Comparez les options sur le coût total de possession (TCO), le coût de vie complète incluant l’acquisition, l’intégration, l’exploitation, le support, la formation, les mises à niveau, et le remplacement éventuel, plutôt que les frais de licence seuls. Le code source ouvert échange souvent le coût de licence contre un coût opérationnel et de personnel plus élevé. Le logiciel propriétaire échange souvent des frais d’abonnement prévisibles contre la dépendance et moins de contrôle. Incluez le coût du modèle lui-même : le code source ouvert auto-soutenu a besoin de compétence interne, tandis que le logiciel propriétaire a besoin de capacité de gestion de fournisseur.

En tant que producteur, ouvrir en code source ce qui ne vous différencie pas

Classifiez votre propre logiciel en ce qui vous donne un avantage concurrentiel ou de mission et ce qui est de la plomberie non différenciée. Gardez les différenciateurs propriétaires. Considérez ouvrir en code source l’infrastructure de commodité, où une communauté peut partager la maintenance et l’amélioration. Pour le gouvernement, pesez « argent public, code public » (le principe selon lequel le logiciel financé par les contribuables devrait être publiquement disponible par défaut) comme moteur de transparence, réutilisation, et souveraineté (chapitres 10.5, 10.11). Choisissez la licence délibérément : permissive pour maximiser l’adoption, copyleft pour garder l’écosystème ouvert.

Compromis : avantages et inconvénients

Dimension	Code source ouvert	Fermé / propriétaire
Coût d’acquisition	Habituellement zéro à acquérir	Frais de licence ou d’abonnement
Coût total de possession	Le coût se déplace vers les opérations et le personnel	Plus prévisible, mais prime de dépendance
Contrôle et personnalisation	Complet : vous pouvez lire et changer la source	Limité à ce que le fournisseur expose
Support et responsabilité	Communauté, ou tiers payant ; pas de gorge unique à étrangler	Support contractuel et une partie responsable claire
Posture de sécurité	Auditable ; « nombreux yeux » si vraiment maintenu	Géré par le fournisseur ; opaque ; l’obscurité n’est pas une protection
Longévité / abandon	Peut être bifurqué si maintenu ; peut quand même dépérir	Dépend de la viabilité et feuille de route du fournisseur
Dépendance au fournisseur	Faible : la source et les formats ouverts permettent la sortie	Élevée sauf atténuée par les normes et le dépôt fiduciaire
Écosystème	Communauté ouverte et interopérabilité	Sélectionné, intégré, parfois cloisonné

La tension récurrente est contrôle contre commodité et responsabilité. Le code source ouvert maximise le contrôle, l’auditabilité, et la liberté de la dépendance, mais il vous demande de fournir la capacité, l’intégration, et le support vous-même. Le logiciel propriétaire livre un produit supporté, intégré, et responsable avec un contrat à faire respecter, mais il concède le contrôle et invite la dépendance. La résolution est rarement tout-ou-rien. La plupart des parcs matures mélangent des fondations à code source ouvert avec des systèmes propriétaires là où le support, la responsabilité, ou une capacité spécialisée justifient l’échange.

Questions à discuter avec votre équipe

Appliquons-nous une politique de licence avec SCA et SBOM automatisés dans le pipeline, spécialement pour attraper le copyleft fort avant qu’il ne soit livré ? Intégrer une bibliothèque GPL dans un produit propriétaire distribué peut vous obliger à publier votre propre source, et cette surprise fait surface habituellement tard, quand elle est coûteuse à défaire. Maintenez un inventaire de chaque composant et sa licence, appliquez quelles familles de licence sont acceptables pour quels usages, et exécutez l’analyse de composition logicielle automatiquement pour que le pipeline bloque les violations plutôt qu’un avocat ne les attrape au moment de la livraison. Générez une SBOM comme une question de routine. Pour un parc grand ou gouvernemental, c’est aussi de l’hygiène de chaîne d’approvisionnement et souvent une exigence de marché public. Apportez votre inventaire de licence actuel, ou le fait que vous n’en avez pas un, et décidez qui possède la politique.
Quand nous adoptons une dépendance, évaluons-nous la santé du projet et le facteur bus comme diligence raisonnable ? Une bibliothèque à code source ouvert à mainteneur unique et un petit fournisseur propriétaire portent le même risque : le projet s’effondre si une ou quelques personnes clés partent. Avant d’adopter quoi que ce soit, évaluez la cadence de publication, le nombre et la diversité de mainteneurs, la réactivité aux rapports de sécurité, et l’étendue d’adoption, et enregistrez l’évaluation. Aucun modèle n’est plus sûr par défaut ; « nombreux yeux » n’aide que si des gens qualifiés regardent réellement, et de nombreux projets largement utilisés sont maigrement maintenus. Apportez les trois ou quatre dépendances dont votre produit dépend le plus et demandez, pour chacune, combien de personnes devraient partir avant que cela ne devienne votre problème. Si vous ne pouvez pas répondre, c’est l’évaluation que vous vous devez.
Quand nous achetons du propriétaire, sécurisons-nous les protections de sortie à l’avance ? Le logiciel propriétaire offre la responsabilité et la commodité en échange du contrôle, et le coût caché est la dépendance : des coûts de changement qui laissent un fournisseur élever les prix ou dégrader le service avec peu de recours. Négociez les protections avant de signer, quand vous avez encore du levier : export de données dans des formats ouverts, API documentées, et dépôt fiduciaire de code source qui libère la source si le fournisseur échoue. Avec le code source ouvert, votre sortie est la capacité de bifurquer ; avec le propriétaire, vous devez écrire la sortie dans le contrat. Apportez vos systèmes propriétaires les plus critiques et demandez ce qui se passe réellement si le fournisseur double le prix ou fait faillite. Si la réponse est « nous sommes coincés », corrigez le contrat au renouvellement.
Pour le logiciel que nous construisons nous-mêmes, comment décidons-nous quoi ouvrir en code source et quoi garder fermé, et qui détient l’autorité de faire cet appel ? Trompez-vous dans une direction et vous donnez le code même qui vous différencie ; trompez-vous dans l’autre et vous accumulez de la plomberie de commodité dont une communauté partagerait volontiers la maintenance. Les pressions concurrentes sont réelles : les ingénieurs veulent l’avantage de recrutement et de réputation d’un dépôt public, tandis que le produit et le juridique s’inquiètent de donner aux rivaux un avantage ou d’exposer une heuristique sensible à la sécurité. Apportez une classification honnête de vos systèmes en différenciant la mission contre infrastructure non différenciée, et nommez la personne ou le conseil qui approuve une publication, parce qu’une décision ad hoc prise par quiconque a poussé le dépôt est comment les joyaux de la couronne fuient. Pour une grande entreprise, la question est une stratégie de portefeuille, et pour le gouvernement, elle entre en collision avec « argent public, code public », le principe selon lequel le logiciel financé par les contribuables devrait être public par défaut, donc décidez à l’avance quelles exemptions (sécurité nationale, détection de fraude, données personnelles) justifient de garder le code fermé.
Nos comparaisons construire-ou-acheter capturent-elles le coût total de possession complet, ou traitons-nous toujours un frais de licence zéro comme un coût zéro ? L’erreur financière la plus commune avec le code source ouvert est de lire « gratuit à acquérir » comme « gratuit à exploiter », puis de découvrir que l’intégration, les opérations, la réponse de sécurité, et le support payé éclipsent toute licence évitée. La tension est qu’un abonnement propriétaire semble coûteux sur la facture tout en cachant une prime de dépendance, et un composant ouvert semble gratuit sur la facture tout en déplaçant le coût vers votre propre personnel. Apportez un modèle TCO à même échelle pour deux ou trois vraies décisions : acquisition, intégration, exploitation, support, formation, mises à niveau, réponse de sécurité, et remplacement éventuel, tarifés sur la vie complète plutôt que la première année. Dans un parc d’entreprise ou gouvernemental, ajoutez le coût du modèle opérationnel lui-même, puisque le code source ouvert auto-soutenu exige une compétence interne que vous devez recruter et retenir, et traitez une comparaison qui omet ces lignes comme une preuve, pas une analyse.
Jugeons-nous la sécurité d’un composant par ses pratiques, ou nous appuyons-nous sur l’étiquette d’ouverture, que ce soit « nombreux yeux » ou le secret du code fermé ? Les deux défauts sont des pièges : « nombreux yeux » ne vous protège que quand des gens qualifiés revoient réellement le code, et de nombreux projets ouverts largement utilisés fonctionnent sur un mainteneur épuisé, tandis que le code source fermé qui compte sur le fait que les attaquants ne le voient pas est de la sécurité par l’obscurité, pas un contrôle. Le débat compte parce qu’il change où vous dépensez un effort de sécurité rare, et la réponse honnête est que les deux modèles portent un risque de chaîne d’approvisionnement, le code source ouvert à travers des dépendances compromises ou abandonnées et le propriétaire à travers des canaux de mise à jour opaques que vous ne pouvez pas inspecter. Apportez des preuves pour vos composants les plus critiques : qui les révise réellement, à quelle vitesse les avis sont corrigés, si les versions sont épinglées et la provenance vérifiée, et si vous générez une SBOM. Pour un parc grand ou gouvernemental, liez cela aux obligations de marchés publics et de scan continu, parce qu’un régulateur demandera ce que vous avez inspecté, pas si la source était publique.

Regard sectoriel

Jeune pousse. Avec peu de marge de manœuvre, vous construisez sur des fondations à code source ouvert parce que vous ne pouvez pas vous permettre les frais de licence et voulez la liberté de bifurquer si un projet cale. Exécutez un scan d’analyse de composition avant de livrer pour qu’une bibliothèque à copyleft fort ne vous oblige pas silencieusement à publier votre propre source, et gardez votre unique vrai différenciateur strictement fermé. Ouvrez en code source un petit outil non critique si cela aide le recrutement, mais ne dotez pas un fardeau de maintenance que vous ne pouvez pas porter.

Petite entreprise. Sans spécialiste juridique ou de plateforme interne, traitez la licence comme un risque que vous ne devez pas mal lire plutôt qu’un sujet que vous pouvez maîtriser. Préférez les outils propriétaires supportés ou les distributions commerciales de code source ouvert où un fournisseur possède les correctifs et la responsabilité, parce qu’auto-soutenir une pile que vous ne pouvez pas exploiter est une fausse économie. Quand vous adoptez un composant gratuit, vérifiez que sa licence permet votre usage et que le projet est réellement maintenu, pas abandonné.

Grande entreprise. À l’échelle, le problème est la cohérence à travers de nombreuses équipes : une politique de licence écrite, une analyse de composition logicielle automatisée et une génération de SBOM dans chaque pipeline, et des décisions construire-ou-acheter basées sur le TCO plutôt que l’habitude par équipe. Gérez le logiciel ouvert et propriétaire comme un seul portefeuille, standardisez les protections de sortie comme les formats ouverts et le dépôt fiduciaire de code source dans les marchés publics, et suivez la santé des dépendances critiques pour qu’un seul projet abandonné ne devienne pas un incident. Gouvernez aussi le côté producteur, avec une règle claire sur ce que l’organisation ouvre en code source contre garde fermé.

Gouvernement. Les règles de marchés publics, les devoirs de transparence, et la responsabilité publique façonnent chaque choix. Pesez « argent public, code public », le principe selon lequel le logiciel financé par les contribuables devrait être public par défaut, pour faire avancer la réutilisation à travers les agences et la souveraineté numérique, tout en découpant des exemptions étroites pour le code sensible à la sécurité ou aux données personnelles. Exigez que tout fournisseur propriétaire fournisse un export de données dans des formats ouverts et un dépôt fiduciaire de code source pour qu’un échec de fournisseur ne puisse pas échouer un service public, et publiez la source non sensible pour que les citoyens puissent auditer les règles qui les gouvernent.

Exemples

Jeune pousse. Une jeune pousse à trois fondateurs construit tout son produit sur des fondations à code source ouvert (Linux, une base de données à code source ouvert, un cadriciel web) parce qu’elle ne peut pas se permettre des frais de licence et veut la liberté de bifurquer si un projet cale. Avant de livrer, un fondateur exécute un scan d’analyse de composition et attrape une bibliothèque à copyleft fort qui les aurait forcés à publier leur algorithme de correspondance propriétaire, donc ils l’échangent pour un équivalent sous licence permissive. Ils gardent cet algorithme, leur seul différenciateur, strictement fermé, et n’ouvrent en code source qu’un petit outil de journalisation interne pour construire de la bonne volonté et attirer des ingénieurs.

Grande entreprise. Un grand assureur exploite sa plateforme centrale sur des fondations à code source ouvert : Linux, une base de données à code source ouvert largement utilisée, et un orchestrateur de conteneurs. Mais il achète une suite de modélisation actuarielle propriétaire, parce que l’expertise de domaine du fournisseur, les certifications réglementaires, et le contrat de support valent le prix et il n’y a pas d’alternative ouverte comparable. Il paie un abonnement pour du code source ouvert commercial (des distributions des composants ouverts supportées par fournisseur) pour obtenir la responsabilité et les correctifs sur la plomberie, tout en gardant l’algorithme de tarification qui le différencie strictement propriétaire et interne. L’analyse TCO (chapitre 10.10) pilote chaque choix plutôt que l’idéologie.

Gouvernement. Une agence fiscale nationale, sous une politique « argent public, code public », construit un nouveau service d’éligibilité aux prestations sur des composants à code source ouvert et des normes ouvertes (chapitre 3.8), pour que d’autres agences puissent le réutiliser et que les citoyens puissent auditer les règles. Elle publie le code non sensible dans un dépôt public, ne retenant que les heuristiques de détection de fraude comme fermées pour des raisons de sécurité. Cela réduit la dépendance au fournisseur et fait avancer la souveraineté numérique (chapitre 10.11). Les règles de marchés publics (chapitre 10.3) exigent que tout composant propriétaire fournisse un export de données dans des formats ouverts et un dépôt fiduciaire de code source, pour garantir la continuité si le fournisseur échoue.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

L’attrait financier du code source ouvert, son absence de frais de licence, est la partie la moins fiable du dossier, parce que l’acquisition est une petite fraction du TCO. Les retours durables sont stratégiques : liberté de la dépendance (la capacité de changer ou abandonner un fournisseur sans réarchitecturer), auditabilité pour la sécurité et la conformité, adoption plus rapide parce que les ingénieurs peuvent essayer avant de s’engager, et maintenance partagée du code de commodité à travers toute une industrie. Les coûts compensatoires sont réels. Vous devez fournir l’intégration, les opérations, la réponse de sécurité, et souvent le support payé, et un projet mal choisi et non maintenu peut coûter plus en incidents que n’importe quelle licence ne l’aurait fait.

Le dossier d’affaires du logiciel propriétaire est la responsabilité et la commodité : un seul fournisseur responsable du produit, un contrat de support que vous pouvez faire respecter, des fonctionnalités intégrées, et une budgétisation prévisible. Son coût caché est la dépendance, les coûts de changement qui laissent un fournisseur élever les prix ou dégrader le service avec peu de recours, plus la dépendance envers la solvabilité et feuille de route du fournisseur. Des modèles d’affaires courants brouillent la ligne : le noyau ouvert (une base ouverte avec des extensions propriétaires payantes), le double licenciement (le même code offert sous une licence copyleft et une licence commerciale payante), le logiciel en tant que service (SaaS) (le logiciel fonctionne comme un service hébergé que vous louez, où la source peut être hors de propos parce que vous ne possédez jamais le binaire), et les modèles support/abonnement qui vendent du service autour de code par ailleurs gratuit.

Pour un producteur, le ROI d’ouvrir en code source votre propre logiciel non différenciant peut être substantiel. Les contributeurs externes réduisent votre charge de maintenance. Le projet devient un atout de recrutement et de réputation. L’adoption externe fait de votre norme la norme de facto. Pour le gouvernement, cela livre transparence et réutilisation à travers le secteur public. La règle stratégique est simple : ouvrez en code source la commodité pour partager son coût et cultiver un écosystème, et gardez le différenciateur fermé pour protéger l’avantage qui finance tout le reste.

Anti-patterns et pièges

« Gratuit signifie gratuit » : traiter le coût d’acquisition zéro comme un TCO zéro, puis sous-financer l’exploitation et le support.
L’aveuglement de licence : intégrer du code à copyleft fort dans un produit propriétaire distribué et déclencher des obligations que vous n’avez jamais planifiées.
La foi dans « nombreux yeux » : supposer qu’un projet ouvert est audité quand il a un mainteneur surchargé et aucune revue de sécurité.
La sécurité par l’obscurité : croire que le code source fermé est sûr simplement parce que les attaquants ne peuvent pas le lire.
L’absolutisme idéologique : mandater « tout ouvert » ou « tout propriétaire » au lieu de choisir par composant sur le mérite et le TCO.
Ignorer la provenance : tirer des dépendances sans SBOM, épinglage de version, ou vérification de chaîne d’approvisionnement (chapitre 4.2).
Ouvrir en code source les joyaux de la couronne : publier le code même qui vous différencie, donnant votre avantage.
Bifurquer-et-oublier : bifurquer un projet abandonné sans la capacité de réellement maintenir la bifurcation.

Modèle de maturité

Niveau 1 (Initier). Les composants à code source ouvert et propriétaire entrent dans le parc ad hoc. Les licences ne sont pas lues, il n’y a pas d’inventaire ou de SBOM, et le choix entre modèles est fait par habitude ou prix seul. L’abandon et le risque de licence font surface seulement quand quelque chose casse, et chaque équipe réagit seule.

Niveau 2 (Développer). Certaines équipes commencent des pratiques de base : un inventaire de composant et de licence, une vue approximative des licences acceptables, et une analyse de composition logicielle occasionnelle. Les décisions construire-ou-acheter et ouvert-ou-fermé sont écrites, mais la discipline est inégale et incohérente d’une équipe à l’autre, donc une surprise de copyleft ou de facteur bus peut encore passer là où l’habitude ne s’est pas installée.

Niveau 3 (Standardiser). Un cadre documenté gouverne à la fois la consommation et la production à l’échelle de l’organisation. Les composants sont choisis sur le TCO et la santé du projet, les licences sont appliquées automatiquement dans le pipeline pour que les violations bloquent une construction, les SBOM sont générées comme une question de routine, et une politique explicite énonce ce que l’organisation ouvre en code source contre garde fermé. Les protections de sortie comme les formats ouverts et le dépôt fiduciaire de code source sont standard dans les marchés publics, et chaque équipe suit les mêmes règles plutôt que les siennes.

Niveau 4 (Gérer). Le programme est mesuré et contrôlé contre des référentiels. L’organisation suit des métriques comme la couverture de SBOM à travers les produits, la part de dépendances qui violent la politique, le temps moyen pour corriger une vulnérabilité de dépendance divulguée, les scores de facteur bus et de santé pour les projets critiques, et le TCO réalisé contre l’estimation qui justifiait chaque choix. Les seuils déclenchent une action : un composant dont la maintenance cale ou dont la latence de correctif dérive au-delà de la cible est signalé pour remplacement sur des preuves, et les décisions ouvert-ou-fermé et construire-ou-acheter sont révisées contre les chiffres plutôt que défendues par habitude.

Niveau 5 (Orchestrer). La stratégie de code source ouvert est une capacité d’affaires délibérée, intégrée à travers l’organisation et continuellement améliorée. L’organisation contribue à et parfois gère les projets dont elle dépend, ouvre en code source son logiciel non différenciant comme une question de routine, et réinjecte les données de santé de dépendance et de TCO dans les marchés publics, la sécurité, et la planification produit. Elle rééquilibre routinièrement son portefeuille de logiciel ouvert et propriétaire, s’adaptant aux changements de coût, risque, souveraineté, et avantage stratégique avant qu’ils ne forcent une crise.

Pistes de réflexion

Où dans votre parc perdre un seul fournisseur ou mainteneur serait-il existentiel, et quel est votre plan de sortie ?
Lesquels de vos propres systèmes sont des commodités que vous pourriez ouvrir en code source, et lesquels sont de vrais différenciateurs à protéger ?
Votre organisation traite-t-elle « nombreux yeux » comme un vrai contrôle de sécurité ou une hypothèse non examinée ?
Pour les lecteurs du secteur public : qu’est-ce qu’un défaut « argent public, code public » changerait dans votre prochain marché public ?
À quel point vos comparaisons TCO capturent-elles bien les coûts opérationnels et de support que le code source ouvert vous déplace ?

Points clés à retenir

Ouvert contre fermé est défini par la licence, pas par le prix ; connaissez la différence entre libre au sens de liberté et libre au sens de prix, et entre permissif et copyleft.
Aucun modèle n’est intrinsèquement plus sécurisé ou moins cher. Jugez les pratiques du projet et son TCO complet, pas l’étiquette d’ouverture.
L’ouverture est le plus fort antidote à la dépendance, livrant l’auditabilité, la portabilité, et la capacité de bifurquer ; le logiciel propriétaire offre la responsabilité et la commodité en échange du contrôle.
Décidez par composant sur le mérite, et mélangez les modèles délibérément plutôt que par idéologie.
En tant que producteur, ouvrez en code source la commodité et gardez le différenciateur fermé, et dans le gouvernement, pesez « argent public, code public » pour la transparence, la réutilisation, et la souveraineté.

Références et lectures complémentaires

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft et autres, divers titres O’Reilly sur la stratégie et les opérations de code source ouvert
Free Software Foundation, The Free Software Definition (et les textes de la GNU General Public License)
Open Source Initiative, The Open Source Definition et liste de licences approuvées
Free Software Foundation Europe, matériaux de campagne Public Money, Public Code
Yochai Benkler, The Wealth of Networks