Résumé exécutif
- L’open source est désormais perçu comme un pilier stratégique dans les services financiers, plus seulement comme un levier de réduction des coûts : 93 % des organisations interrogées considèrent qu’il améliore la qualité des logiciels et 87 % qu’il crée de la valeur métier tangible.
- La gouvernance de l’open source s’institutionnalise : environ la moitié des institutions financières ont défini une stratégie open source claire et presque autant ont mis en place un OSPO (Open Source Program Office) afin de coordonner l’usage, la contribution et la gestion des risques liés aux logiciels open source.
- Les politiques internes encadrant l’utilisation et la contribution aux projets open source deviennent plus permissives (seules ~2 % des entreprises interdisent formellement les contributions), mais leur application reste inégale. Des incohérences de processus – souvent dues à l’incertitude sur le ROI ou à des préoccupations juridiques – conduisent à une participation hétérogène et peuvent engendrer des forks internes coûteux à maintenir.
- La sécurité de la chaîne d’approvisionnement logicielle est un enjeu majeur : 52 % des acteurs citent les vulnérabilités dans les composants open source parmi leurs principales inquiétudes et 37 % redoutent les attaques visant la supply chain logicielle. Pour y remédier, des pratiques comme l’utilisation de SBOM (Software Bill of Materials) se développent, même si moins de la moitié des organisations produisent aujourd’hui des SBOM pour leurs applications.
- De fortes disparités de maturité subsistent entre les établissements : certains leaders ont déjà intégré l’open source à leur culture (OSPO dédié, politiques formalisées, contributions actives), tandis qu’une part non négligeable du secteur n’en est qu’aux premiers pas et n’a pas encore mis en place de programme open source structuré.
- Le rôle du top management est déterminant dans la stratégie open source : les responsables technologiques (CTO, CIO) et les OSPO figurent parmi les acteurs les plus influents pour impulser la dynamique open source, leur engagement permettant de lever les obstacles culturels et organisationnels.
- Les principaux obstacles identifiés à l’adoption de l’open source restent l’absence de ROI clairement établi et la complexité juridique (gestion des licences, propriété intellectuelle). Ces freins, associés à des processus internes parfois lourds, entretiennent la prudence de certaines institutions malgré la reconnaissance des bénéfices de l’open source.
Une adoption devenue stratégique
L’adoption de l’open source dans le secteur financier est entrée dans une phase de maturité où elle n’est plus marginale mais bien au cœur de la stratégie technologique. La très grande majorité des organisations financières utilisent des logiciels open source au quotidien, et la tendance s’est accélérée ces dernières années. Ce qui n’était initialement perçu que comme un moyen de réduire les coûts informatiques est désormais considéré comme un véritable levier de création de valeur. Près de 9 institutions financières sur 10 reconnaissent aujourd’hui que l’open source apporte des bénéfices concrets – en améliorant la qualité logicielle, en accélérant l’innovation, et en contribuant à la valeur métier. Dans un secteur guidé par la précision, la réglementation et le ROI (retour sur investissement), le fait que banques et assurances embrassent massivement l’open source est révélateur : si elles le font, c’est que la proposition de valeur est avérée.
Les chiffres confirment cette évolution de perception. Non seulement la quasi-totalité des établissements utilisent des composants open source, mais 84 % estiment que ces technologies ouvertes sont désormais essentielles pour l’ensemble du secteur financier. L’open source est ainsi passé du statut d’outil opportuniste à celui d’atout stratégique de long terme. Par exemple, certaines solutions communautaires issues de collaborations sectorielles – telles que des standards comme FDC3 (interopérabilité des postes de travail financiers) ou des outils spécifiques comme GitProxy – font désormais partie intégrante de l’infrastructure de grandes banques, signe que l’open source alimente le cœur des systèmes critiques. Les avantages recherchés vont au-delà de la simple économie de coûts de licences : les établissements constatent aussi un accélération du time-to-market, une meilleure conformité réglementaire partagée (via des standards communs), ainsi qu’un atout en matière d’attraction et rétention des talents technologiques.
Les politiques d’utilisation et de contribution open source
Avec la généralisation de l’open source, les institutions financières ont dû structurer des politiques internes pour encadrer à la fois l’utilisation des logiciels libres et la contribution de leur propre code aux projets externes. Sur le volet de l’usage (“consommation” de code open source), l’approche s’est nettement ouverte : l’industrie reconnaît que l’open source est omniprésent et incontournable. Aujourd’hui, 97 % des organisations autorisent explicitement l’utilisation de composants open source dans leurs systèmes, et seulement une infime minorité (environ 1 à 2 %) continue d’en interdire l’emploi. En pratique, cela signifie que les développeurs financiers ont désormais le feu vert pour intégrer des bibliothèques, frameworks ou outils open source, là où il y a une décennie certaines directions informatiques bannissaient par précaution tout code “non propriétaire”. Cette évolution traduit une meilleure compréhension : même les établissements jadis réticents ont constaté qu’ils utilisaient de l’open source sans le savoir, tant ces composants sont devenus indissociables de l’ingénierie logicielle moderne.
Côté contributions (“amont” vers les communautés open source), la mutation est en cours elle aussi. De plus en plus d’institutions encouragent leurs équipes à contribuer à des projets externes, ne serait-ce que pour corriger un bug ou ajouter une fonctionnalité utile. D’après les enquêtes récentes, seules 2 % des entreprises financières déclarent encore interdire formellement à leurs développeurs de contribuer à des projets open source. Autrement dit, 98 % des acteurs autorisent la contribution d’une manière ou d’une autre – un changement notable par rapport au passé. Cependant, la façon dont ces contributions sont encadrées varie fortement. Dans certains groupes, la politique peut être très restrictive (exigeant par exemple une validation au cas par cas par l’équipe juridique ou conformité pour chaque contribution), tandis que d’autres ont mis en place des processus plus fluides ou des guides de contribution clairs.
Cette hétérogénéité fait que, malgré des politiques officiellement permissives, l’application concrète reste parfois inégale. Il n’est pas rare, par exemple, que des développeurs choisissent de contribuer sur leur temps libre ou via des comptes personnels GitHub, faute d’une procédure bien définie pour le faire au nom de leur employeur. Les lacunes de cadrage et la complexité perçue (peur de “mal faire”) brident donc encore la participation en amont dans certains établissements. Les causes principales identifiées sont le manque de visibilité sur le ROI des contributions (difficile à quantifier en bénéfices financiers directs) et les craintes liées aux aspects juridiques (licences, propriété intellectuelle, conformité réglementaire). Il en résulte, d’une part, une adoption inégale de l’open source selon les entités ou équipes au sein d’une même entreprise, et d’autre part l’apparition de contournements coûteux tels que les forks internes (voir plus loin). L’un des défis de gouvernance pour les DSI est donc d’harmoniser et simplifier ces politiques afin de lever l’incertitude, ce qui permettra une contribution plus sereine et généralisée de l’ensemble des collaborateurs.
Mise en place des OSPO (Open Source Program Offices)
La création d’un Open Source Program Office (OSPO) dédié est devenue une pratique phare pour structurer la gouvernance open source dans les grandes organisations. Un OSPO est une entité interne – une équipe ou cellule transverse – chargée de centraliser tout ce qui a trait à l’open source : définition des politiques, accompagnement des développeurs, gestion des risques de conformité, contribution aux projets communautaires, relations avec les fondations, etc. En 2025, près de la moitié des entreprises du secteur financier disposent d’un OSPO ou d’une fonction équivalente, alors qu’il y a quatre ans cette notion restait émergente. Le mouvement est encore plus prononcé parmi les grands groupes bancaires : on estime que presque deux tiers des grandes banques internationales ont désormais instauré un OSPO pour piloter leur stratégie open source.
Le rôle de l’OSPO est à la fois opérationnel et stratégique. Opérationnel, car il établit des processus internes clairs autour de l’open source (par exemple : comment valider l’utilisation d’une nouvelle librairie open source, quelles étapes suivre pour contribuer à un projet externe, comment publier en open source un outil développé en interne, etc.) et fournit l’outillage et la formation nécessaires aux équipes. Stratégique, car il veille à ce que l’adoption de l’open source soit alignée sur les objectifs de l’entreprise : l’OSPO connecte les départements technologie, juridique/conformité, sécurité et même RH, pour que l’usage de logiciels libres et la participation aux communautés soient cohérents avec les exigences réglementaires et les intérêts business. En pratique, un OSPO agit comme centre de compétence interne sur l’open source. Il conseille les projets sur le choix des composants (pour éviter, par exemple, des licences incompatibles ou des dépendances non maintenues), il coordonne les contributions de code en amont (en s’assurant que les développeurs respectent les règles et bonnes pratiques de la communauté), et il gère la relation avec les écosystèmes externes (participation aux fondations comme FINOS, Linux Foundation, etc.).
Le fait qu’un nombre croissant d’institutions financières aient formalisé un OSPO témoigne d’une montée en maturité. Cela institutionnalise l’open source en interne, là où auparavant les efforts étaient souvent ad hoc ou dispersés. On est passé d’une approche opportuniste (quelques passionnés contribuant de leur côté) à une approche gouvernée : l’open source devient “géré comme un actif”, avec des indicateurs de suivi, des budgets alloués, et une intégration dans la gouvernance globale IT. Cette évolution est si marquante que d’autres industries commencent à s’y intéresser en prenant pour modèle la finance, un secteur qui montre qu’on peut concilier rigueur (sécurité, conformité, gestion de risque) et ouverture (collaboration et transparence du code).
Gestion des risques liés à la chaîne d’approvisionnement logicielle
L’exposition aux risques de sécurité est l’une des contreparties de l’usage massif d’open source – et les institutions financières en sont bien conscientes. La « chaîne d’approvisionnement logicielle » désigne l’ensemble des composants, outils et processus qui entrent dans la fabrication et le déploiement d’une application. Or, dans cette chaîne, les briques open source occupent souvent une place importante (systèmes d’exploitation, serveurs d’applications, bibliothèques tierces, etc.). Gérer les risques de la supply chain logicielle consiste donc à maîtriser tout ce qui pourrait compromettre l’environnement applicatif via ces briques : failles de sécurité connues dans une bibliothèque, dépendances cachées, attaques visant un fournisseur ou un dépôt de code, problèmes de licence ou de qualité du code importé, etc.
D’après les enquêtes sectorielles récentes, la sécurité de l’open source est une préoccupation prioritaire pour les DSI de la finance. En effet, 52 % des organisations citent les vulnérabilités dans les composants open source comme l’un de leurs problèmes majeurs, ce qui en fait l’inquiétude numéro un en matière d’open source. De plus, 37 % des répondants soulignent spécifiquement le risque d’attaques ciblant la chaîne d’approvisionnement (supply chain attacks), c’est-à-dire la compromission malveillante d’une dépendance logicielle (comme on a pu le voir avec des incidents publics impliquant des bibliothèques corrompues ou des attaques de type SolarWinds). Ces chiffres montrent que la sensibilisation aux risques est élevée.
En réponse, les établissements financiers renforcent progressivement leurs pratiques de gestion du risque open source. Près de la moitié déclarent avoir mis en place des processus formalisés d’évaluation des composants open source avant leur adoption (par exemple, une analyse de sécurité, une validation de la licence, une vérification de la pérennité du projet communautaire). De même, environ 42 % indiquent utiliser des outils dédiés pour appliquer leurs politiques open source – cela peut inclure des scanners de code pour détecter les vulnérabilités ou les licences indésirables, des solutions de suivi des dépendances, etc. Autrement dit, de plus en plus d’acteurs outillent et automatisent la gouvernance de leurs dépendances logicielles.
Cependant, il reste un écart entre la prise de conscience du risque et la mise en œuvre effective des mesures de contrôle dans toute l’industrie. Certains établissements en sont encore à un stade initial où l’inventaire des composants utilisés n’est pas exhaustif ou où les procédures de mise à jour de sécurité ne sont pas systématiques. Par exemple, lorsqu’une faille critique (“zero-day”) est révélée dans une librairie open source répandue, toutes les entreprises n’ont pas la même capacité de réaction pour identifier rapidement si elles l’utilisent et pour déployer un correctif. La gestion de la vulnérabilité open source nécessite une coordination entre les équipes de développement, de sécurité et d’exploitation, ainsi qu’une bonne visibilité sur l’ensemble des logiciels libres déployés. C’est précisément pour améliorer cette visibilité et cette réactivité qu’émergent des pratiques comme l’établissement d’une SBOM pour chaque application (voir section suivante). En résumé, la gestion du risque open source progresse à travers des politiques et outils dédiés, mais elle n’est pas encore uniformément mature dans tous les établissements financiers, ce qui laisse place à des efforts accrus dans les années à venir.
Usage des SBOM (Software Bill of Materials)
Face à la complexité de la supply chain logicielle moderne, le SBOM est en train de s’imposer comme un outil crucial de transparence. Un Software Bill of Materials (littéralement “liste de matériaux logiciels”) est un document ou fichier qui dresse l’inventaire détaillé de tous les composants (dépendances, bibliothèques, modules) qui entrent dans la composition d’un logiciel. On peut l’assimiler à la nomenclature utilisée dans l’industrie manufacturière pour connaître chaque pièce d’un produit fini. Dans le contexte logiciel, un SBOM permet à une organisation de savoir exactement quelles versions de quelles bibliothèques open source (et de quels éditeurs tiers) sont intégrées dans ses applications, ce qui facilite grandement la gestion des failles de sécurité ou des obligations de licence.
Dans les services financiers, l’adoption des SBOM est encore en phase de généralisation, mais on observe une montée en puissance. En 2025, environ 43 % des institutions financières déclarent produire activement des SBOM pour les logiciels qu’elles développent en interne. Cela signifie qu’à peine moins de la moitié ont institutionnalisé cette pratique – ce qui est à la fois significatif (compte tenu du caractère récent de l’initiative) et encore insuffisant pour couvrir tout le secteur. En outre, une proportion comparable d’organisations commence à consommer des SBOM fournies par des tiers ou par les communautés open source elles-mêmes : par exemple, analyser les SBOM publiés par un fournisseur pour vérifier que ses produits ne contiennent pas de dépendances vulnérables, ou exiger des SBOM de la part d’un prestataire logiciel dans le cadre d’un achat. D’autres pratiques émergentes incluent l’intégration des SBOM dans les pipelines CI/CD (afin de générer automatiquement l’inventaire lors de chaque build applicatif) ou l’utilisation de SBOM dans les rapports de conformité réglementaire.
Le fait que moins de la moitié des acteurs produisent aujourd’hui des SBOM illustre un décalage entre la sensibilisation et l’action. Beaucoup d’institutions reconnaissent l’utilité du SBOM en théorie, mais n’ont pas encore déployé les processus outillés pour le faire à grande échelle. Par ailleurs, un nombre non négligeable de répondants à l’enquête sectorielle admettent ne pas savoir si leur organisation a adopté de telles pratiques, ce qui suggère un déficit de communication interne sur ces sujets techniques. Néanmoins, la tendance est clairement à l’augmentation de l’adoption des SBOM, poussée par plusieurs facteurs : la multiplication des normes de sécurité et des guides de bonnes pratiques qui recommandent fortement les SBOM, l’intérêt croissant des régulateurs pour la sécurité de la supply chain (certaines réglementations à l’étude pourraient exiger la fourniture de SBOM pour les logiciels critiques), et surtout les retours d’expérience démontrant l’efficacité des SBOM lors de crises de sécurité (par exemple pour évaluer l’impact d’une faille comme Log4Shell en 2021, les entreprises disposant de SBOM ont pu plus vite identifier les applications à risque). On peut donc s’attendre à ce que la majorité des institutions financières adoptent les SBOM dans un futur proche, les SBOM devenant un standard de facto de la gouvernance logicielle au même titre que les processus de gestion des vulnérabilités ou des correctifs.
Écarts de maturité entre les institutions
Si l’orientation globale est à la progression de l’open source dans les services financiers, tous les acteurs ne marchent pas du même pas. On observe d’importants écarts de maturité d’une institution à l’autre. Certaines grandes banques pionnières affichent aujourd’hui une intégration poussée de l’open source : elles ont une stratégie formalisée, un OSPO actif, des politiques bien établies et participent à de multiples projets communautaires. À l’inverse, d’autres établissements sont encore au tout début du chemin, limités à une utilisation passive de quelques outils open source sans cadre clair, voire avec une méfiance persistante.
Les données de l’étude 2025 illustrent ce fossé. Par exemple, environ 14 % des institutions financières traditionnelles sondées indiquent n’avoir encore entrepris aucune des actions type proposées pour maturer leur approche open source (que ce soit définir une politique, lancer un programme interne, rejoindre une fondation ou encourager les contributions). Ce pourcentage non négligeable suggère qu’un groupe d’établissements reste en retrait total – souvent en raison de freins culturels ou d’un manque de priorité stratégique sur le sujet. À l’opposé, 97 % des fintechs interrogées affirment avoir initié au moins une démarche structurante en matière d’open source (politiques, contributions, etc.), seules 3 % d’entre elles déclarant n’avoir rien lancé. Ce contraste indique que les jeunes entreprises financières technologiques (fintech/insurtech) sont en général plus enclines à embrasser spontanément l’open source, possiblement grâce à une culture d’entreprise plus “native numérique” et une moindre inertie organisationnelle. Toutefois, les fintechs ayant moins de ressources, elles peuvent être en avance culturellement tout en étant moins formalisées en matière de gouvernance que les grandes banques.
Une autre dimension des écarts de maturité tient à la taille et aux ressources disponibles. Les très grandes banques et compagnies d’assurance disposent d’équipes importantes, de budgets IT conséquents, et sont souvent présentes dans les instances de gouvernance de l’open source (adhésion à FINOS, sièges dans des comités techniques, etc.). Cela leur permet d’être mieux équipées pour avancer rapidement : par exemple, le taux d’adoption d’un OSPO ou équivalent dépasse les 55 % chez les établissements financiers de premier plan, contre environ 38 % seulement chez les fintechs plus petites. À l’inverse, dans les banques de taille moyenne ou les acteurs plus locaux, il est fréquent que l’open source soit utilisé de manière opportuniste sans programme dédié, faute de moyens alloués ou d’expertise interne suffisante pour le structurer.
Enfin, il convient de souligner que même au sein d’une institution donnée, il peut y avoir des décalages de maturité internes. Souvent, l’initiative open source est portée par une division ou quelques leaders éclairés, tandis que d’autres départements restent en retrait. Par exemple, l’étude révèle des différences marquées dans la connaissance des politiques open source selon les personnes interrogées : ceux qui sont très familiers du sujet rapportent bien plus souvent l’existence d’outils et processus que ceux qui ne le sont que vaguement, signe que l’information ne circule pas toujours à tous les étages. Pour combler ces écarts, un travail d’évangelisation interne et de formation est nécessaire, afin d’embarquer l’ensemble des équipes dans une culture commune de l’open source.
Impact des forks internes
Le terme fork désigne en open source le fait de copier le code d’un projet pour en créer une version distincte. Un fork interne, dans le contexte d’une institution financière, se produit lorsque l’entreprise maintient en interne une version modifiée d’un logiciel open source sans fusionner régulièrement ces modifications avec le projet open source d’origine. Dit autrement, l’entreprise se retrouve avec sa branche parallèle du code, distincte de la branche communautaire.
Ces forks internes résultent généralement de contraintes organisationnelles. Par exemple, une équipe de développement peut avoir besoin d’ajouter rapidement une fonctionnalité à un outil open source pour répondre à une exigence métier locale. Si le processus pour contribuer cette modification au projet open source est trop long ou incertain (du fait de politiques internes restrictives ou de craintes juridiques), l’équipe va implémenter la modification de son côté et déployer une version customisée en production. Ainsi naît un fork interne, souvent non planifié au départ (“unintentional fork”). D’autres fois, le fork provient du fait qu’un projet open source utilisé n’évolue plus assez vite ou ne prend pas en compte certains besoins critiques de l’entreprise, poussant celle-ci à diverger pour aller plus loin en interne.
Le coût de ces forks internes est bien documenté. D’une part, maintenir un fork signifie que l’entreprise doit elle-même intégrer les correctifs de sécurité et mises à jour publiés en amont, au lieu de simplement bénéficier des améliorations de la communauté – cela mobilise donc des ressources supplémentaires en veille et en développement. D’autre part, plus le fork perdure, plus il s’éloigne du tronc commun : la réintégration éventuelle devient complexe, et le fork peut devenir un cul-de-sac technologique si le projet open source originel continue à évoluer différemment. On estime que les forks internes entraînent une duplication de l’effort, une augmentation de la dette technique (car le code divergé doit être refactoré manuellement pour suivre les évolutions), ainsi qu’un risque accru de vulnérabilités (si le fork ne reçoit pas en temps réel les patches de sécurité du projet d’origine). En outre, ils privent la communauté open source des contributions de l’entreprise, ce qui est un manque à gagner mutuel : la communauté ne profite pas des améliorations et l’entreprise ne bénéficie pas des retours ni de l’évolution collective sur cette partie du code.
Limiter les forks internes inutiles fait donc partie des enjeux de gouvernance open source. Idéalement, lorsqu’un besoin de modification apparaît, l’entreprise devrait contribuer en amont au projet open source, pour faire intégrer sa solution dans la version officielle. Cela requiert un cadre interne permettant aux développeurs de proposer des changements à la communauté dans un délai compatible avec les impératifs métier. L’étude souligne que la prolifération de forks internes est souvent le symptôme de politiques de contribution trop restrictives ou floues : lorsque les procédures seront clarifiées et uniformisées, et que les développeurs auront le réflexe de travailler main dans la main avec les mainteneurs externes, on verra diminuer ces duplications d’efforts. En attendant, un conseil pratique émerge des retours d’expérience : prioriser les contributions sur les composants open source les plus critiques pour l’entreprise. En concentrant l’investissement de contribution là où l’impact est majeur (sur les outils stratégiques, au cœur des systèmes), on évite que les différences locales ne s’accumulent et ne forcent la création d’un fork. En somme, le fork interne doit être considéré comme un dernier recours temporaire, et non comme un mode de fonctionnement normal – c’est un point d’attention que les dirigeants IT surveillent de près, car il touche à l’efficacité et à la durabilité des solutions open source déployées.
Rôle des dirigeants dans la stratégie open source
L’engagement des dirigeants – en particulier des dirigeants technologiques – s’avère crucial pour faire aboutir la démarche open source au sein d’une institution financière. Les retours du secteur montrent que sans sponsorship au plus haut niveau, les initiatives open source ont tendance à stagner ou à rester confinées à des petits périmètres. À l’inverse, lorsque le COMEX et la direction IT affichent clairement leur soutien à l’open source, cela envoie un signal fort à toute l’organisation et accélère les progrès.
Selon les données de l’étude, les acteurs jugés les plus influents dans l’élaboration de la stratégie open source d’une entreprise financière sont le CTO (Chief Technology Officer), les responsables d’OSPO ou rôles similaires dédiés, ainsi que la communauté des développeurs internes eux-mêmes. Chacun de ces groupes est cité par plus de 60 % des répondants comme moteur de la dynamique open source (le CTO arrivant en tête avec près de 69 % de citations). Viennent ensuite les fonctions de sécurité (CISO) et de direction des systèmes d’information (CIO). En revanche, les parties prenantes externes comme les régulateurs ou internes comme l’audit et les ressources humaines sont perçues comme bien moins influentes sur ces questions – ce qui signifie que l’initiative doit d’abord venir de la volonté interne plutôt que d’une contrainte imposée de l’extérieur.
Le leadership joue sur plusieurs tableaux. D’une part, un dirigeant convaincu de l’intérêt de l’open source pourra allouer les ressources nécessaires (budget, temps des équipes, investissements dans des outils ou des partenariats externes). D’autre part, il pourra adapter les processus internes pour les rendre compatibles avec l’agilité de l’open source – par exemple, en simplifiant certaines procédures de validation ou en ajustant les objectifs RH pour valoriser la contribution communautaire. Aussi, le discours des dirigeants influe sur la culture : s’ils valorisent publiquement les réussites open source de leurs équipes, cela incite d’autres employés à s’impliquer.
À l’inverse, le manque de leadership identifié est un frein tangible. Près d’un tiers des organisations pointent l’absence de portage clair par un responsable ou un sponsor exécutif comme un obstacle à l’expansion de l’open source chez eux. Ce vide de leadership peut se manifester par de la dilution de responsabilité (personne n’ayant la mission explicite de développer l’open source, chacun restant dans son silo), ou par une hésitation à prendre des décisions engageantes (par exemple libérer en open source un logiciel interne innovant, ce qui nécessite un arbitrage stratégique que seul un dirigeant peut trancher). Sans pilote dans l’avion, la gouvernance open source risque d’être fragmentée et de manquer de cohérence.
Il ressort clairement que pour intégrer l’open source à la stratégie d’entreprise, le soutien visible des dirigeants de haut niveau est indispensable. Dans plusieurs grandes banques, on constate que c’est l’impulsion d’un CTO visionnaire ou d’un directeur innovation sensibilisé à l’open source qui a déclenché la mise en place d’un OSPO et l’acculturation progressive des équipes. Le rôle du top management est également de communiquer en externe sur l’engagement open source de l’entreprise (via des annonces, des participations à des forums sectoriels), ce qui a pour effet de légitimer ces efforts et de renforcer la marque employeur tech de l’organisation. En somme, les dirigeants fixent le cap et débloquent les ressources, tandis que l’OSPO et les développeurs opèrent la transformation au quotidien. C’est cette combinaison qui semble la plus efficace pour surmonter les obstacles et ancrer durablement les pratiques open source.
Obstacles persistants : ROI et aspects juridiques
Malgré l’enthousiasme croissant et les progrès réalisés, il subsiste des obstacles structurels qui freinent l’adoption pleine et entière de l’open source dans la finance. Les deux freins les plus fréquemment cités par les acteurs du secteur sont la difficulté à mesurer le ROI et la complexité juridique liée à l’open source.
Le ROI (Return on Investment), obsession légitime dans l’industrie financière, est un concept parfois difficile à appliquer à l’open source. 48 % des organisations reconnaissent qu’un manque de visibilité sur le retour sur investissement concret des contributions open source limite leur engagement. En effet, si l’usage de logiciels libres peut se traduire par des économies immédiates (moins de coûts de licence, mutualisation de développements), la contribution active – elle – est souvent perçue comme un investissement à long terme dont les retombées sont diffuses : amélioration de réputation, influence sur la feuille de route d’un projet, gains d’efficacité partagés, etc. Il n’est pas aisé d’attribuer une valeur monétaire à ces bénéfices intangibles. Par exemple, comment chiffrer précisément l’avantage d’avoir des développeurs plus expérimentés grâce à leur participation communautaire, ou le temps gagné sur un futur projet grâce à un standard ouvert qu’on a contribué à élaborer ? Les directeurs financiers et même les directeurs informatiques peuvent donc se montrer prudents s’ils ne peuvent pas justifier en chiffres l’effort consacré à l’open source. Cela conduit certaines entreprises à limiter les contributions ou les initiatives open source faute de business case clair à présenter en interne. Toutefois, on observe que la situation évolue : de plus en plus d’institutions commencent à quantifier certains effets (par exemple, des millions d’euros économisés en évitant le développement redondant grâce à un projet open source commun, ou un gain de productivité des développeurs évalué en pourcentage) et à reconnaître que l’open source apporte aussi des retours non financiers importants, comme l’innovation plus rapide ou l’accès facilité à des talents.
Le deuxième grand obstacle est d’ordre juridique et réglementaire. L’open source s’accompagne d’un cadre légal particulier, principalement via les licences open source qui régissent les conditions d’utilisation, de modification et de redistribution du code. Dans un environnement aussi régulé et sensible que la banque, beaucoup de services juridiques internes ont longtemps considéré ces licences avec prudence, voire méfiance. 48 % des organisations citent encore les préoccupations légales/licences comme un frein à leur contribution open source. Les craintes portent sur plusieurs points : le respect des obligations de licence (par ex, crainte de devoir ouvrir le code source de certaines applications si on utilise du logiciel libre sous licence copyleft), la protection de la propriété intellectuelle de l’entreprise (peur que du code interne confidentiel ne “fuite” par le biais d’une contribution open source mal maîtrisée), ou encore la conformité aux exigences réglementaires sectorielles (les régulateurs bancaires n’imposent pas de restrictions explicites sur l’open source, mais les établissements veulent s’assurer que l’usage de logiciels tiers libres ne crée pas de faille de compliance ou de risque opérationnel imprévu). S’ajoutent à cela les enjeux de support et de responsabilité : utiliser un composant open source sans garantie de support contractuel peut sembler risqué à un manager, de même que contribuer à un projet externe piloté en dehors du contrôle de l’entreprise.
Ces obstacles juridiques sont souvent surmontables via des politiques claires et de l’acculturation, mais ils requièrent du temps et l’implication conjointe des équipes légales, conformité et techniques. De nombreuses institutions ont mis en place des processus de validation des licences (création d’une liste blanche de licences acceptables, clause d’approbation préalable avant d’ouvrir un code, etc.) pour se rassurer sur ces points. Cependant, ces processus peuvent ralentir voire décourager l’open source en interne s’ils sont trop lourds.
Outre le ROI et le juridique, d’autres freins secondaires ont été mentionnés par les acteurs : la résistance au changement ou la culture du secret encore présente dans certaines organisations, la surcharge des équipes (l’open source pouvant être perçu comme une tâche supplémentaire par rapport aux projets classiques), ou le manque de compétences internes pour naviguer dans l’écosystème open source (identifier les bons projets, interagir avec les communautés). Néanmoins, ces points sont généralement adressés progressivement à mesure que la maturité open source augmente.
En conclusion sur les obstacles, il apparaît que la clarification de la proposition de valeur et la simplification du cadre juridique sont deux leviers majeurs pour lever les réticences. Les experts recommandent de développer des indicateurs de performance adaptés pour suivre les bénéfices de l’open source (par exemple nombre de projets accélérés grâce à l’utilisation de composants libres, économies réalisées, impacts en termes de réduction de risques ou de recrutements facilités). Parallèlement, l’adoption de standards et de frameworks internes (modèles de licence approuvés, guides de contribution, clauses contractuelles pour les fournisseurs open source, etc.) peut apporter la sécurité juridique nécessaire pour que les équipes agissent en confiance. Avec des leaderships éclairés, des règles du jeu claires et des succès tangibles mis en avant, les obstacles tendent à s’estomper, permettant à l’open source de déployer tout son potentiel dans un secteur financier qui en a saisi l’importance.
Si je devais conclure
L’open source dans les services financiers est passé en quelques années d’une expérimentation marginale à un élément central de la stratégie IT. Les bénéfices attendus – innovation partagée, efficience opérationnelle, mutualisation des coûts et des efforts – se concrétisent suffisamment pour convaincre des établissements réputés conservateurs d’y investir temps et ressources. Cette évolution s’accompagne inévitablement de nouveaux enjeux de gouvernance : il s’agit pour les dirigeants de s’assurer que l’adoption de l’open source se fait de manière maîtrisée, sécurisée et alignée avec les objectifs de l’entreprise.
Le panorama actuel montre que les fondations de cette gouvernance sont posées. Des politiques d’usage et de contribution sont en place dans la plupart des grandes institutions, des OSPO coordonnent désormais les initiatives open source en interne, et la gestion des risques liés aux logiciels libres est mieux outillée que par le passé. Les résultats n’en sont que plus visibles : l’open source apporte du meilleur code, des coûts réduits, plus de rapidité et de collaboration, au point que le secteur financier tout entier y voit un atout compétitif pour l’avenir.
Pour autant, le travail n’est pas terminé. Transformer l’essai demandera de poursuivre les efforts afin d’homogénéiser les pratiques (au sein et entre les organisations), combler les retards de maturité, et intégrer pleinement l’open source à la culture d’entreprise. Cela implique de mesurer et communiquer régulièrement sur la valeur générée (pour dissiper les doutes sur le ROI), de renforcer la sécurité de la chaîne logicielle (pour que la confiance s’installe à tous les niveaux), et de maintenir un engagement fort du leadership (pour guider et encourager les équipes).
En fin de compte, l’expérience des services financiers démontre qu’il est possible d’allier rigueur réglementaire et ouverture technologique. Les banques et assurances qui gouvernent efficacement leur utilisation de l’open source en retirent un avantage tangible, tout en contribuant à l’écosystème commun. L’open source n’est plus vu comme un risque à contenir, mais comme une capacité à amplifier – un moyen de faire mieux, plus vite et ensemble. À mesure que ces pratiques gagnent en maturité, le secteur financier s’affirme comme un modèle de référence pour d’autres industries en quête d’un équilibre entre innovation collaborative et exigences de gouvernance.
Enjoy !
Sources
- https://www.finos.org/state-of-open-source-in-financial-services
- https://www.linuxfoundation.org/blog/banking-on-collaboration-the-2025-state-of-open-source-in-financial-services
