Au début des années 2010, le secteur de la Banque-Finance a du changer de cap suite à plusieurs événements. Suite à la crise des subprimes, des institutions autrefois perçu comme insubmersibles ont bel et bien coulées, tandis que la confiance des consommateurs se dégradait. Parallèlement, les habitudes des consommateurs évoluent avec l'accélération de l'accès à internet et l'arrivée des premiers smartphone sur le marché.

Pour répondre à ces attentes, les banques traditionnelles ont massivement investi dans les services bancaires en ligne et les services numériques. La montée en puissance de la banque en ligne a entraîné une augmentation significative des volumes de transactions et a intensifié la pression sur les systèmes sous-jacents.  Pour accompagner cette évolution, les établissements ont entrepris de moderniser leurs infrastructures afin de remédier à des problèmes persistants.

Il s'agissait notamment d'améliorer la qualité du service, de réduire les inefficacités et la dette technique, et de favoriser une plus grande collaboration et une appropriation accrue au sein des équipes. Dans le même temps, la scalabilité est devenue une exigence essentielle. Les banques devaient gérer un nombre croissant de clients numériques dont les habitudes d'utilisation étaient non seulement plus intenses, mais aussi de plus en plus fluctuants.

La Promesse de l'Innovation

APIs: les rouages de la machine

En surface, le système bancaire semble stable, fiable, immuable. Dans les faits, ils ont subi de profondes transformations ces vingt dernières années.

À mesure que l'adoption du numérique s'accélérait, les volumes de transactions ont explosé. Les clients ont multiplié leurs intéractions avec leurs banques, effectuant des paiements, consultant leurs comptes et gérant leurs produits financiers en ligne. L'argent circulait plus vite, plus souvent, et dans des canaux plus variés

Les systèmes existants, initialement conçus pour privilégier la stabilité plutôt que la rapidité, ont rapidement eu du mal à suivre. Afin de maintenir la qualité de leurs services, les banques ont développé de nouvelles applications dédiées pour gérer des utilisations spécifiques tels que les paiements, la gestion d'actifs, les prêts ou les assurances.

Parallèlement, l'émergence de l'Open Banking et de l'Open Finance a redéfini le paysage concurrentiel. En ouvrant leurs systèmes via des API, les institutions financières ont permis à des prestataires tiers et aux fintechs de développer de nouveaux services en s'appuyant sur l'infrastructure existante.

Dans ce contexte, le développement logiciel est devenu un élément central des services financiers. Il ne s'agit plus seulement d'une fonction de soutien, mais du principal moteur de l'innovation, permettant aux institutions de proposer de nouveaux services, d'améliorer leur efficacité et de répondre aux attentes des utilisateurs, en constante évolution.

Quand les écosystèmes deviennent plus complexes

Pour soutenir ce rythme d’innovation, les banques ont cherché à moderniser leurs processus de développement et de mise en production. Leur objectif était d’améliorer l’efficacité, de réduire les efforts redondants en matière de tests et de déploiement, et d’élever la qualité globale des logiciels produits.

Cependant, cette évolution s’est accompagnée de conséquences inattendues.
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 également considérablement accru la complexité. Désormais, même des modifications mineures nécessitent de naviguer entre de multiples dépendances, de gérer différentes couches de configuration et d’assurer la compatibilité entre systèmes.

Avec le temps, cette complexité s'est considérablement accrue.

Une manière pertinente de comprendre cette évolution consiste à 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, provoquant des effets en cascade à l’échelle de tout le réseau.

Les systèmes bancaires ont évolué de manière similaire. 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 performant, mais aussi nettement plus difficile à comprendre, à modifier et à sécuriser.

De la même façon, les architectures bancaires sont devenues des écosystèmes denses et interconnectés où chaque nouveau composant améliore les capacités, tout en ajoutant 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 à maîtriser.

Le coût opérationnel de l'ouverture

Plus de pression, moins de visibilité

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

Poussées par des stratégies centrées sur le client et des dynamiques concurrentielles, les équipes de développement sont attendues pour livrer de nouveaux services à un rythme accéléré. Cette pression constante pour innover peut parfois mener à des compromis. Les pratiques de sécurité peuvent être reléguées au second plan, et la dette technique peut augmenter lorsque les équipes privilégient la rapidité par rapport à 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. Bien que cela améliore l'efficacité à court terme, cela augmente également le risque de compromission. D'autres organisations préfèrent plutôt fournir à leurs développeurs deux ordinateurs portables pour isoler les outils et limiter la propagation potentielle des attaques. Bien que cette option semble concilier l'air-gapping et permette aux développeurs d'avoir un environnement spécifique avec leur Linux, elle ajoute de la complexité dans leurs 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 les deux.

Les accès par delà les bureaux

Les changements dans les modes de travail ont transformé la façon dont les développeurs accèdent aux systèmes critiques. Selon un rapport de 2025, 32,8% des développeurs en France travaillent partiellement en télétravail, tandis que 18,1% sont entièrement en télétravail. Ce changement reflète une attente croissante de flexibilité et d'autonomie.

Alors que les développeurs attendent de plus en plus de flexibilité et d'autonomie, de nombreuses organisations ont eu du mal à adapter leurs environnements à ces nouvelles attentes. Une part importante des développeurs travaille désormais au moins partiellement en télétravail, ce qui a conduit à une multiplication des points d'accès aux systèmes critiques.

Pour accompagner ce changement, les entreprises ont déployé des solutions d'accès à distance telles que les protocoles de bureau à distance (RDS). Cependant, ces outils n'ont pas toujours délivré les niveaux de performance et de flexibilité attendus. Des solutions comme la VDI ou les RDS, souvent dépendantes de la qualité du réseau ou limitées par des contraintes d'utilisabilité, ont parfois conduit à de la frustration chez les utilisateurs.

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

Finalement, cela crée une double frustration pour les développeurs. On attend d'eux qu'ils livrent plus rapidement, mais ils manquent souvent de l'autonomie et des outils nécessaires pour travailler efficacement et en toute sécurité. Cet écart entre les attentes et la réalité devient en soi une source de risque.

Quand les systèmes ne répondent plus aux besoins

Un système en décalage avec les usages réels

Ce désalignement peut être comparé à un réseau de transport métropolitain conçu pour une époque révolue.

À Paris, par exemple, le système de métro a été historiquement construit pour relier les banlieues au centre-ville, et non pour permettre un déplacement direct entre banlieues. En conséquence, voyager d'une banlieue à une autre nécessite souvent de passer par des hubs centraux, augmentant à la fois 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'utilisation distribuée observé aujourd'hui. À mesure que les services numériques se sont développés et que les modes de travail ont évolué, 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 les changements dans les modes d'utilisation, les institutions financières doivent maintenant repenser leurs systèmes pour s'aligner sur la façon dont les gens travaillent et interagissent réellement avec eux.

Le chainon manquant : la séparation logique du matériel et virtualization next-gen

L'une des limites fondamentales des approches traditionnelles réside dans la façon dont les environnements sont structurés et isolés.

Historiquement, la sécurité a reposé lourdement sur la séparation physique entre les environnements. Bien que efficace, ce modèle est de plus en plus difficile à mettre à l'échelle dans des organisations modernes et dynamiques. De nouvelles approches, rendues possibles par la virtualisation de nouvelle génération, permettent de repenser ce modèle. Au lieu de s'appuyer uniquement sur l'isolation physique, les organisations peuvent créer plusieurs environnements logiquement séparés sur un seul poste de travail.

Par exemple, les développeurs peuvent opérer au sein d'environnements distincts sur le même appareil : un espace de travail d'entreprise et un environnement de développement entièrement isolé adapté à leurs besoins, avec les outils appropriés, tels qu'une configuration basée sur Linux, et des politiques de sécurité adaptées à leurs flux de travail. En gardant les ressources allouées localement, ces environnements peuvent maintenir des performances élevées tout en imposant une isolation stricte.

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

Finalement, ce changement permet aux organisations de résoudre une tension de longue date. Il fournit aux développeurs l'autonomie dont ils ont besoin pour travailler efficacement, sans compromettre la sécurité ni les performances.

Conclusion : La virtualisation revient 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. Pendant que les organisations financières transitions, la façon dont les gens travaillent a évolué plus rapidement que les systèmes qui les soutiennent. Dans la poursuite d'une innovation accélérée, elles n'ont pas réussi à penser aux besoins des équipes travaillant sur cette nouvelle architecture.

De la flexibilité pour les utilisateurs des applications, pas pour ceux qui les maintiennent en fonctionnement. Et lorsque le télétravail a explosé pendant les confinements, même un secteur généralement en avance dans l'innovation a vu ses développeurs compter sur des 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 comment les environnements sont construits, permettant à la sécurité, aux performances 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 offrons avec notre solution.

Cela semble trop beau pour être vrai ? Laissez nous vous montrer comment concilier visibilité pour les admins et liberté pour les devs.