Quand l'innovation dépasse la réalité : repenser les environnements de développement dans les services financiers

Dans les années 2010, le secteur bancaire et financier a dû opérer un virage radical. Des géants autrefois considérés comme « trop gros pour faire faillite » se sont effondrés, la confiance des clients s'est érodée et les attentes ont radicalement changé, portées par l'accélération de l'accès à Internet et l'émergence des premiers smartphones.

Pour répondre à ces attentes, les banques traditionnelles ont massivement investi dans la banque en ligne et les services numériques. L'essor de la banque en ligne a considérablement augmenté les volumes de transactions et intensifié la pression sur les systèmes sous-jacents.

Pour accompagner cette mutation, les institutions ont commencé à moderniser leurs infrastructures afin de résoudre des problèmes persistants. Il s'agissait notamment d'améliorer la qualité de service, de réduire les inefficacités et la dette technique, et de favoriser une meilleure collaboration et une plus grande responsabilisation des équipes. Parallèlement, l'évolutivité est devenue une exigence critique. Les banques devaient gérer un nombre croissant de clients numériques dont les habitudes d'utilisation étaient non seulement plus fréquentes, mais aussi de plus en plus volatiles.

‍

La promesse de l'innovation

Les API : le moteur sous le capot

En apparence, les systèmes bancaires semblent stables, presque immuables. En réalité, ils ont subi de profondes transformations au cours des deux dernières décennies.

Avec l'accélération de l'adoption du numérique, les volumes de transactions ont bondi. Les clients ont commencé à interagir plus fréquemment avec leur banque, effectuant des paiements, consultant leurs comptes et gérant leurs produits financiers en ligne. L'argent a commencé à circuler plus vite, plus souvent et via davantage de canaux que jamais auparavant.

Les systèmes hérités, conçus à l'origine pour la stabilité plutôt que pour la vitesse, ont rapidement eu du mal à suivre ce rythme. Pour maintenir la qualité de service, les banques ont introduit de nouvelles applications dédiées pour gérer des cas d'usage spécifiques tels que les paiements, la gestion d'actifs, les prêts ou l'assurance.

Parallèlement, l'émergence de l'Open Banking et de l'Open Finance a remodelé le paysage concurrentiel. En ouvrant leurs systèmes via des API, les institutions financières ont permis à des prestataires tiers et à des fintechs de construire de nouveaux services sur une infrastructure existante. Cela a accru l'interopérabilité, mais a également intensifié la concurrence, poussant l'ensemble du secteur dans une course permanente à l'innovation.

Dans ce contexte, le développement logiciel est devenu central pour les services financiers. Il ne s'agit plus seulement d'une fonction de support, mais du principal moteur d'innovation, permettant aux institutions de proposer de nouveaux services, d'améliorer leur efficacité et de répondre aux attentes sans cesse changeantes des utilisateurs.

‍

Quand l'écosystème devient de plus en plus complexe

Pour soutenir ce rythme d'innovation, les banques ont cherché à moderniser leurs processus de développement et de livraison. Leur objectif était d'améliorer l'efficacité, de réduire les efforts redondants lors des tests et du déploiement, et d'améliorer la qualité globale des logiciels produits.

Cependant, ce changement a eu des conséquences imprévues.

Au lieu de simplifier leurs systèmes, les banques ont progressivement introduit des centaines d'applications et de services interconnectés. Si ces architectures ont permis une plus grande flexibilité et des cycles de développement plus rapides, elles ont aussi considérablement accru la complexité. Apporter la moindre modification nécessite désormais de naviguer entre de multiples dépendances, de gérer des couches de configuration et d'assurer la compatibilité entre les systèmes.

Au fil du temps, cette complexité a crû de manière exponentielle.

Une façon utile de comprendre cette évolution est de comparer les systèmes bancaires à un réseau de métro. À mesure que le réseau s'étend, de nouvelles lignes améliorent la couverture et la connectivité, mais elles augmentent aussi les interdépendances. Une perturbation sur une ligne apparemment mineure, comme la ligne 10 à Paris, peut contribuer à la saturation de lignes majeures comme la ligne 13, créant des effets en cascade sur l'ensemble du système.

Les systèmes bancaires ont évolué de la même manière. Chaque nouvelle application ou API améliore les fonctionnalités mais accroît également les dépendances. Avec le temps, le système devient plus efficace, mais nettement plus difficile à comprendre, à modifier et à sécuriser.

De la même manière, les architectures bancaires sont devenues des écosystèmes denses et interconnectés où chaque nouveau composant améliore les fonctionnalités mais ajoute également des frictions et des risques. Ce qui a initialement permis l'innovation a progressivement rendu les systèmes plus difficiles à faire évoluer et, en fin de compte, plus difficiles à contrôler.

‍

Le coût opérationnel de l'ouverture

Plus de pression, moins de contrôle

Derrière ces architectures, les équipes opérationnelles font face à une pression croissante.

Sous l'impulsion de stratégies centrées sur le client et d'une dynamique concurrentielle, les équipes de développement doivent livrer de nouveaux services à un rythme soutenu. Cette pression constante pour innover peut parfois mener à des compromis. La sécurité peut être reléguée au second plan et la dette technique s'accumuler, les équipes privilégiant la rapidité à la résilience.

Dans certains cas, les développeurs se voient accorder des droits d'administration complets ou partiels pour accélérer leur travail. Si cela améliore l'efficacité à court terme, cela accroît également le risque de compromission. D'autres organisations préfèrent fournir deux ordinateurs portables à leurs développeurs afin d'isoler les outils et de limiter la propagation potentielle des attaques. Bien que cette option semble concilier cloisonnement et utilisation d'un environnement Linux spécifique, elle complexifie les flux de travail.

Cela crée un paradoxe : les organisations exigent à la fois rapidité et sécurité, mais échouent souvent à fournir les conditions nécessaires pour atteindre ces deux objectifs.

‍

Quand l'accès sort du bureau

L'évolution des modes de travail a transformé la manière dont les développeurs accèdent aux systèmes critiques. Selon un rapport de 2025, 32,8 % des développeurs en France travaillent partiellement à distance, tandis que 18,1 % sont en télétravail complet. Ce changement reflète une attente croissante en matière de flexibilité et d'autonomie.

Alors que les développeurs aspirent à plus de flexibilité et d'autonomie, de nombreuses organisations peinent à adapter leurs environnements à ces nouvelles attentes. Une part importante des développeurs travaille désormais au moins partiellement à distance, ce qui a entraîné une multiplication des points d'accès aux systèmes critiques.

Pour accompagner cette transition, les entreprises ont déployé des solutions d'accès à distance telles que les protocoles de bureau à distance. Cependant, ces outils n'ont pas toujours offert les niveaux de performance et de flexibilité attendus. Les solutions de type VDI ou RDS, souvent dépendantes de la qualité du réseau ou limitées par des contraintes d'ergonomie, ont parfois généré de la frustration chez les utilisateurs.

En conséquence, des solutions de contournement apparaissent. Ces pratiques officieuses peuvent améliorer la productivité à court terme, mais elles introduisent de nouvelles vulnérabilités et réduisent le contrôle global sur l'environnement.

En fin de compte, cela crée une double frustration pour les développeurs. On attend d'eux qu'ils livrent plus rapidement, tout en les privant souvent de l'autonomie et des outils nécessaires pour travailler efficacement et en toute sécurité. Ce décalage entre les attentes et la réalité devient une source de risque en soi.

‍

Quand les systèmes ne sont plus adaptés aux besoins

Un système non conçu pour les usages actuels

Ce manque d'alignement peut être comparé à un réseau de transport métropolitain conçu pour une autre époque.

À Paris, par exemple, le métro a été historiquement construit pour relier la banlieue au centre-ville, et non pour permettre des déplacements directs entre les banlieues. Par conséquent, voyager d'une zone périphérique à une autre nécessite souvent de passer par des hubs centraux, ce qui augmente le temps de trajet et la congestion.

Les systèmes bancaires font face à un défi similaire. Ils n'ont pas été conçus pour le niveau d'interconnectivité, de flexibilité et d'usage distribué que nous connaissons aujourd'hui. Avec l'expansion des services numériques et l'évolution des modes de travail, l'architecture a eu du mal à s'adapter, créant des inefficacités, des frictions et de nouveaux points de risque.

Tout comme l'urbanisme a dû évoluer pour mieux refléter l'évolution des usages, les institutions financières doivent désormais repenser leurs systèmes pour les aligner sur la manière dont les collaborateurs travaillent et interagissent réellement avec eux.

‍

Le chaînon manquant : la séparation logique du matériel et la virtualisation de nouvelle génération

L'une des principales limites des approches traditionnelles réside dans la manière dont les environnements sont structurés et isolés.

Historiquement, la sécurité reposait largement sur la séparation physique des environnements. Bien qu'efficace, ce modèle est de plus en plus difficile à mettre à l'échelle dans les organisations modernes et agiles. De nouvelles approches, rendues possibles par la virtualisation de nouvelle génération, permettent de repenser ce modèle. Au lieu de dépendre uniquement de l'isolation physique, les organisations peuvent créer plusieurs environnements logiquement séparés sur une seule station de travail.

Par exemple, les développeurs peuvent travailler dans des environnements distincts sur le même appareil : un espace de travail d'entreprise et un environnement de développement totalement isolé, adapté à leurs besoins, avec les outils appropriés, comme une configuration basée sur Linux, et des politiques de sécurité conformes à leurs flux de travail. En maintenant les ressources allouées localement, ces environnements conservent des performances élevées tout en garantissant une isolation stricte.

Cette approche s'inscrit dans le droit fil des recommandations telles que celles promues par l'ANSSI, qui explore le modèle des postes de travail multi-environnements, tout en reconnaissant que la séparation physique n'est plus la seule option viable.

En fin de compte, ce changement permet aux organisations de résoudre une tension persistante. Il offre aux développeurs l'autonomie dont ils ont besoin pour travailler efficacement, sans compromettre la sécurité ni les performances.

‍

Conclusion : La virtualisation est de retour sur le marché

En ouvrant leurs infrastructures via des API et en multipliant les applications, les institutions financières ont permis des services plus rapides, plus flexibles et plus interconnectés. Alors que les organisations financières opéraient cette transition, les méthodes de travail ont évolué plus rapidement que les systèmes qui les soutiennent. Dans leur quête d'innovation accélérée, elles ont omis de prendre en compte les besoins des équipes travaillant sur cette nouvelle architecture.

La flexibilité pour les utilisateurs d'applications, mais pas pour ceux qui assurent leur fonctionnement. Et lorsque le télétravail a explosé pendant le confinement, même un secteur généralement en pointe en matière d'innovation a vu ses développeurs dépendre de solutions VDI instables et coûteuses, qu'ils utilisent encore aujourd'hui malgré leurs inconvénients bien connus.

Il est clair que le défi n'est plus d'innover plus vite, mais de repenser la manière dont les environnements sont construits, permettant à la sécurité, à la performance et à l'autonomie des développeurs de coexister, tout en restaurant la visibilité et le contrôle que les organisations ont progressivement perdus.

C'est ce que nous proposons avec notre solution.

Cela semble trop beau pour être vrai ? Laissez-nous vous montrer comment nous procédons.