>> Cet article est extrait de notre carnet d’expériences Une DSI « broker de services » ? Recettes de scale-ups à l’usage des entreprises

La fintech française Lydia, créée en 2013 et spécialisée dans le paiement mobile, a beaucoup changé en quelques années. Devenue une véritable scale-up, elle fait face à des enjeux de relation IT-métiers que ne renieraient pas des entreprises plus traditionnelles. Alexandre Heimburger, son Chief Technology Officer, détaille ce que sont pour lui les impératifs, technologiques et organisationnels, qui permettent de mettre en œuvre une IT « broker de services ».

Que représente l’IT chez Lydia ?

Nous sommes 200 collaborateurs au total chez Lydia, avec un objectif de 300 d’ici la fin de l’année. En 2020, nous n’étions que 70 dont seulement quinze à s’occuper de la tech ! La transformation de start-up en scale-up se voit bien à ce niveau.

Depuis janvier 2020, je gère en tant que CTO à la fois l’ingénierie – software factory et development delivery –, la partie data et la partie infrastructure. J’ai également la responsabilité de notre IT interne, qui est extrêmement importante car notre entreprise a des obligations de sécurité et de conformité très fortes. Celles-ci sont d’autant plus critiques que nous évoluons dans un contexte de forte mobilité, au sein d’équipes distribuées. Nous devons donc pouvoir fournir des services IT sécurisés à des personnes qui travaillent de n’importe où.

Quand on devient une scale-up et qu’on « onboard » vingt personnes tous les quinze jours, la pression sur l’IT interne, que ce soit pour fournir les machines, les configurer ou mettre en place les VPN, est énorme. En parallèle, du côté de nos clients, nous avons atteint les 6 millions d’utilisateurs, soit deux fois plus qu’il y a deux ans, ce qui est assez colossal pour un organisme financier de notre taille en France. Cela signifie que notre système d’information doit gérer des dizaines de transactions chaque seconde. Et ce sont des dizaines de millions d’euros qui transitent dessus chaque mois, dans une logique 24 / 7, avec tout ce que cela implique en termes de résilience et de sécurité.

C’est aussi représentatif de l’élargissement de l’activité de votre entreprise…

Effectivement, Lydia était connue avant tout sur le remboursement entre proches, mais aujourd’hui nous proposons un compte courant et aussi de l’épargne, ou encore du trading, y compris sur des crypto-monnaies. Ce sont des flux financiers beaucoup plus complexes, qui doivent s’exécuter dans des conditions optimales en permanence. Au-delà de la construction d’une infrastructure similaire à un éditeur de logiciel SaaS, nous devons aussi assumer l’impossibilité que l’infrastructure tombe. Tous nos arbitrages prennent cela en compte.

Vous reconnaissez-vous dans l’expression « broker de services » pour votre DSI ?

Oui, mais il faut noter qu’une DSI a toujours eu pour objectif de fournir des services aux métiers dans l’entreprise. Ce qui a changé, c’est que maintenant, ce n’est plus la DSI qui dit « voilà comment faire ». La demande des métiers est différente, notamment sur l’accès à la data. Cet accès doit se faire de partout et dans une logique de temps réel de plus en plus importante. Or, par le passé, il était impossible d’accéder facilement à la donnée, notamment en dehors des murs de l’entreprise.

La DSI avait les pleins pouvoirs pour produire un simple reporting, quitte à attendre plusieurs mois. Mais aujourd’hui, la réalité d’une entreprise comme Lydia, c’est au contraire de permettre une communication directe permanente sur les sujets métiers. Tout doit être fait de façon très véloce, en quelques jours. Donc je dirais que c’est avant tout la façon de fournir les services, et leur nature, qui a changé.

Quels sont les aspects les plus importants de ces changements pour vous ?

Avant, la DSI jouait avec un grand système d’information monolithique. Et le coût d’ajout de nouvelles briques à ce système devenait de plus en plus important dans le temps, si bien que plus personne n’osait toucher aux empilements du SI. On le voit très bien dans notre secteur, avec des banques traditionnelles qui ont beaucoup de mal à fournir des services mobiles en temps réel, du fait d’une dette technique qui dépasse leurs moyens pourtant considérables. La logique « broker de services » est le fruit d’une exigence de changement dans la conception des services eux-mêmes d’un point de vue technique. Autour de trois aspects en particulier : les microservices, le déploiement dans le cloud, et la sécurité by design.

« Nous avons au premier plan un enjeu fort de maîtrise de la mise en production. » Cliquez pour tweeter

Ces changements sont-ils assez clairs dans la vision des possibles que peut avoir un Comex et, partant de là, dans sa vision du rôle de la DSI ?

D’une entreprise à une autre, les différences sont notables. Les entreprises qui ont été montées depuis quinze ans ont une conception de leur système d’information, et donc de leur DSI, complètement différente, à la fois sur les technologies utilisées et sur ce qui est attendu des équipes. Il y a clairement un lien entre la vision stratégique de l’entreprise et le rôle donné à la DSI au quotidien. De plus en plus, les collaborateurs ne peuvent de toute façon plus comprendre l’incapacité d’une DSI à fournir des services équivalents à ce qu’ils expérimentent à titre personnel dans leur vie de tous les jours. Mais quand il est obligatoire pour une entreprise de suivre un workflow complexe afin de déployer deux serveurs pour mettre en œuvre un nouveau service, tout en respectant une validation budgétaire trimestrielle… cela ne va pas de soi !

A lire aussi : Chez Doctolib, la transformation de l’IT est au coeur de l’hyper‑croissance

Aujourd’hui, le cloud permet de faire cela en quelques clics et la différence commence à être claire pour les collaborateurs. Chez les scale-ups, ce conflit est évidemment moins présent, mais la demande est tellement forte en termes d’autonomie de la part des métiers, que nous avons au premier plan un enjeu fort de maîtrise de la mise en production. D’un côté, on ne peut pas faire passer toutes les mises en production sous les fourches caudines d’une seule équipe IT, mais on ne peut pas non plus tout laisser filer. Nous estimons que notre stratégie pour aller vers du 100 % cloud assumé permettra de trouver le bon équilibre.

Quelles sont pour vous les grandes caractéristiques des nouveaux services que doit apporter l’IT vis-à-vis du métier ?

Dans la fourniture de services modernes, je vois trois enjeux clés. D’abord, la gestion de la data : la principale mission de l’IT va être de répondre au besoin de vélocité des analystes métiers, en fiabilisant la donnée et en l’exposant, dans des délais extrêmement courts, de l’ordre de 30 minutes. Pour y parvenir, il faut que l’IT soit dans le bon état d’esprit, mais aussi qu’il ait les technologies adéquates : sans avoir des stockages spécifiques big data, type BigQuery, c’est impossible… Le prérequis technique est donc important. Ensuite, l’IT doit permettre aux développeurs d’être agiles, en leur laissant la possibilité de livrer de manière sécurisée, avec des processus de qualité automatiques qui s’exécutent pour avoir la certitude que les systèmes mobiles ou serveurs ne casseront pas.

C’est la logique d’une chaîne d’intégration continue qui permet à un utilisateur d’avoir accès au service dix minutes seulement après que le code a été finalisé. Les implications de cette agilité du software delivery sont très importantes, notamment en termes de sécurité : single sign-on, gestion des identités, VPN, chiffrement des disques…

Enfin, le troisième point, qui est dans la continuité des deux précédents, est la gestion de la mobilité. Celle-ci vient percuter à la fois l’aspect data, le software delivery et la sécurité de plein fouet.

Quels sont les principaux impacts sur le système d’information ?

Il faut garder en tête que même une scale-up crée en permanence ce qui sera demain sa dette technique. On ne peut rien y faire. Pour faire face au mieux à cette gestion du système d’information sur le long terme, je pense que l’enjeu est celui de la modularisation maximum du SI. On ne doit plus se retrouver à devoir changer le monolithe avec des migrations qui prennent un temps considérable. À l’inverse, quand on conçoit les services que l’on fournit de manière isolée, on peut les remplacer beaucoup plus vite. Cela préside à tous nos choix.

Quand on parle aux équipes data et infrastructure lors de la mise en place d’un data warehouse par exemple, on s’interroge : que se passe-t-il si on le perd ou si on doit le reconstruire ? Si la réponse est que ce sera difficile… alors on arrête là. Car il est évident que demain il faudra le reconstruire d’une façon ou d’une autre : pour des raisons de sécurité, mais aussi parce que les modèles de data de demain seront très différents de ceux d’aujourd’hui. Or, si à la conception tout est encore possible, quand on manipule des téraoctets de données, tout devient évidemment beaucoup plus compliqué. 

Dans cette logique, avant tout développement, nous rédigeons un document de design technique, qui se base sur un modèle commun. Il permet de détailler comment le système va être conçu ; comment il va pouvoir passer à l’échelle en restant performant ; la place que prendra la sécurité dès le design ; ou encore comment il permettra l’exposition de la data et son évolution. Le CTO et les architectes doivent valider cette logique de design autour de quatre points clés : performance, sécurité, modularité, scalabilité. Ces quatre éléments permettent de débloquer à l’avance de nombreuses situations problématiques. Cela peut paraître paradoxal par rapport à l’approche « agile », qui semble dire « faisons vite et on avisera ensuite ». Mais pour être en mesure de conserver cette agilité, il faut se structurer intelligemment dès le départ.

Vous mentionniez également le rôle fondamental du cloud ?

Si je reprends mon exemple : quand on veut déployer un data warehouse avec un pétaoctet de données, l’entreprise a au final deux choix. Soit gérer elle-même le hardware, et prévoir deux pétaoctets de disponibles au cas où…

Ou aller dans le cloud. Le cloud est perçu comme plus cher, certes. Sauf quand on regarde les coûts dans leur globalité, en intégrant l’impact organisationnel, les salaires, la réalité des data centers, etc. Créer son propre « private cloud » coûte également cher, à la fois à concevoir, à opérer, à maintenir. Côté cloud public, les opérateurs commencent à avoir une maturité et une granularité d’offres suffisamment importantes, avec une vision sécurité très aboutie. C’est d’ailleurs bien ce qui permet d’avoir finalement une équipe de taille optimale quand on les ramène au nombre d’utilisateurs sur nos systèmes par exemple. C’est un point d’autant plus important de l’équation, car recruter ces experts devient un challenge de plus en plus complexe.