Comment structurer un data office capable d’allier proximité métier, passage à l’échelle et cohérence globale ? Dans cet épisode du podcast LES ENFANTS DE LA DATA, Paul Marcombes — ex-Head of Engineering & Data chez Nickel — revient sur la transformation en profondeur du data office de Nickel. Il y décrypte la mise en place d’un modèle hybride, mêlant équipe centrale forte et data analysts intégrés aux métiers, soutenu par une vision plateforme pensée comme un levier d’autonomie.
Dans une fintech au modèle singulier — ouverture de compte chez les buralistes, forte inclusion bancaire, présence européenne — la donnée est au cœur de la performance mais aussi de la sécurité des utilisateurs, notamment sur les enjeux de lutte contre le blanchiment et de détection de fraude. Entre cas d’usage concrets, impacts mesurables et retours d’expérience, cet échange révèle les secrets d’une organisation data réellement au service des métiers.
ENTRETIEN
Julien Merali :
Paul Marcombes, vous étiez jusqu’à très récemment Head of Data chez Nickel. Nous allons revenir sur tout ce que tu as mis en place. Comment était organisé le Data Office à ton arrivée ? Mais d’abord, même si la marque Nickel est bien ancrée dans l’inconscient collectif, peux-tu nous présenter Nickel en quelques chiffres et expliquer les différents métiers exercés ?
Paul Marcombes :
Nickel est une fintech qui permet d’ouvrir un compte courant pour les particuliers, directement chez un buraliste. Nous comptons plus de 8 000 bureaux de tabac partenaires en France. L’activité est principalement en France, mais aussi en Europe : en Espagne, en Belgique, au Portugal et en Allemagne. En tout, près de 5 millions de clients ont rejoint Nickel en une douzaine d’années.
Julien Merali :
Tu es arrivé il y a combien de temps chez Nickel ?
Paul Marcombes :
Je suis arrivé il y a environ sept ans.
Julien Merali :
À ton arrivée, l’entreprise comptait combien de collaborateurs ?
Paul Marcombes :
Environ 300 collaborateurs.
Julien Merali :
Et lorsque tu es parti ?
Paul Marcombes :
Nous étions 900.
Julien Merali :
Une très forte croissance donc. Comment était organisé le Data Office ? Existait-il déjà une structure bien établie ?
Paul Marcombes :
À 300 personnes, nous avions une équipe data de quatre personnes qui répondait à l’ensemble des demandes data de l’entreprise. C’était une équipe totalement centralisée qui était au service de tout le monde.
Elle répondait à toutes les sollicitations : fourniture de chiffres, analyses plus poussées, développement d’algorithmes.
Julien Merali :
Et la gestion des données en tant que telle, comment était-elle organisée ?
Paul Marcombes :
La gestion des données sur la data plateforme était partagée avec la DSI. Elle permettait d’alimenter la plateforme, que l’équipe data exploitait ensuite pour réaliser ses analyses.
Julien Merali :
Quelles étaient les grandes typologies de données à gérer ?
Paul Marcombes :
Les données clients, les transactions bancaires, les données personnelles.
Mais aussi toutes les activités réalisées sur l’application. Comme pour un compte courant classique : application mobile, site web… Nous suivions l’ensemble des interactions et opérations effectuées sur le compte.
Julien Merali :
La thématique de cette interview est : les secrets de la data chez Nickel, ou comment faire fonctionner un modèle hybride au service des métiers. D’abord, qu’appelles-tu un modèle hybride ?
Paul Marcombes :
À mon arrivée, l’équipe centrale répondait à toutes les demandes. Progressivement, le modèle s’est essoufflé : nous étions trop éloignés des métiers, l’entreprise était en forte croissance et nous connaissions moins bien les nouveaux besoins. Les équipes passaient par du ticketing, nous répondions au fil de l’eau, mais cela manquait de proximité et d’efficacité.
Nous avons donc voulu évoluer vers un modèle hybride : rattacher des profils data directement aux métiers, tout en conservant une équipe centrale forte. L’idée n’était pas une décentralisation totale, mais un équilibre :
- une partie décentralisée, proche des métiers ;
- une équipe centrale chargée d’animer la communauté et de fournir les outils communs.
Julien Merali :
Concrètement, que signifie “décentraliser” ? Un data analyst par direction ? Quels ont été les premiers métiers concernés ?
Paul Marcombes :
Lorsqu’on mène un changement, il faut commencer là où les chances de succès sont les plus élevées. Chez nous, c’était la conformité. Nous travaillions étroitement avec eux sur les algorithmes de lutte contre le blanchiment et la fraude.
Nous avons donc recruté un data analyst directement rattaché à cette direction.
Le test a dépassé nos attentes. La direction est devenue autonome :
- sur son activité quotidienne,
- sur l’amélioration de son efficacité opérationnelle,
- sur la création de ses propres algorithmes.
Les performances des modèles de lutte contre la fraude ont été drastiquement améliorées.
Face à ce succès, d’autres directions ont voulu adopter le même modèle : marketing, équipes commerciales, puis progressivement l’ensemble des départements.
Julien Merali :
Comment êtes-vous passés de quelques équipes à l’ensemble de l’entreprise ?
Paul Marcombes :
Cela s’est fait progressivement, ce qui a facilité la gestion du changement. Notre principale crainte était le risque de divergence : des équipes non rattachées hiérarchiquement au central, avec des méthodes ou des définitions différentes, créant du chaos dans les données.
Nous avons donc renforcé le rôle de l’équipe centrale :
- animation active de la communauté (réunions hebdomadaires),
- accompagnement méthodologique des métiers avec les analystes pour les aider à matérialiser leurs connaissances.
- forte exigence de partage.
Les analystes rattachés aux métiers répondaient à leurs managers opérationnels. Mais pour nous, communauté data, il était essentiel que les enseignements issus de leurs analyses alimentent une base de connaissances commune.
Nous avons donc dédié des ressources centrales pour les accompagner dans cette formalisation, jusqu’à ce que le partage devienne naturel.
Julien Merali :
Quel était le périmètre de ces analystes métiers ?
Paul Marcombes :
Nous leur avons donné un maximum d’autonomie. Nous les appelions data analysts, mais ils étaient en réalité “full stack” :
Ils intervenaient sur toute la chaîne de la data:
- collecte des données dans le data warehouse,
- mise en qualité et documentation,
- création des dashboards de référence,
- analyse des parcours clients et identification des points de friction,
- mise en place d’algorithmes (fraude, communication ciblée, reporting réglementaire),
- modèles simples ou de machine learning.
En pratique, ils combinaient les rôles de Data Engineer, Analytics Engineer, BI engineer, ML Engineer, Data Scientist…
Julien Merali :
À la fin, combien d’analystes autonomes comptiez-vous ?
Paul Marcombes :
Nous en avions 25.
Julien Merali :
Comment maintenir la cohérence entre équipe centrale et analystes métiers ? Parce que les data analysts, quelque part, c’est un mini CDO dans sa trame métier.
Paul Marcombes :
C’était vraiment le but. Chaque département pouvait compter deux ou trois analystes, dont un plus senior rattaché au responsable métier. Nous le considérions comme le “Head of Data” de son département, presque comme si chaque direction était une startup de 50 à 60 personnes.
La cohérence reposait sur deux piliers :
- L’animation de la communauté (réunions régulières, hebdo et annuelles).
- Les outils communs.
L’équipe centrale fournissait des outils uniques pour :
- charger et transformer les données,
- créer des dashboards,
- envoyer des communications,
- déployer des modèles.
Grâce à cette standardisation, nous avions une visibilité globale sur tout ce qui était produit.
Qui dit outils communs dit standardisation, et donc cohérence à l’échelle de l’entreprise.
Julien Merali :
Très concrètement, quel est le résultat de cette transformation ? Nous parlerons ensuite des avantages et des inconvénients — car chaque modèle en a — mais d’abord : à quoi aboutit réellement ce type d’organisation ?
Paul Marcombes :
On arrive à mettre en place des choses qui nous dépassent complètement, nous, équipe centrale. Même avec la meilleure expertise possible, nous n’aurions jamais pu imaginer certaines solutions conçues au plus près du métier.
Un bon exemple est celui de la conformité. Nous avions des algorithmes générant des alertes de suspicion de blanchiment. Ensuite, des opérationnels analysaient ces alertes : investigation sur le compte client, échanges avec le client, vérification de l’origine des fonds, etc.
Lorsque nous étions en central, la conformité nous demandait simplement d’ajouter tel ou tel indicateur via un ticket. Nous restions dans une logique réactive.
Quand nous avons rattaché un data analyst à l’équipe conformité, il s’est rapidement rendu compte que les outils existants n’étaient pas suffisants. Nous avions un back-office interne donnant une certaine visibilité sur les comptes, mais cela restait limité.
Dès son premier mois, il a conçu un dashboard 360° offrant une vision globale du client, répondant à des questions que la conformité se posait depuis longtemps sans que l’IT puisse les prioriser jusque-là.
Ce que l’on gagne avant tout, c’est de la proactivité et d’être embarqué dans l’équipe, en observant les pratiques quotidiennes, en identifiant les besoins implicites et en apportant des solutions avant même qu’un ticket ne soit formulé.
Julien Merali :
Avez-vous mis en place des KPI pour mesurer le succès de cette démarche ou un ROI ?
Paul Marcombes :
Nous avons commencé petit, avec une vision long terme. Le meilleur indicateur de succès a été organique : le modèle fonctionnait tellement bien que les directions ont demandé à recruter leurs propres data analysts.
Julien Merali :
Les métiers ont donc demandé leur propre budget pour recruter davantage de data analysts ?
Paul Marcombes :
Exactement. Un autre indicateur très concret concerne la performance des algorithmes. Au départ, certains modèles de détection sur le blanchiment affichaient environ 5 % à 10 % de vrais positifs.
Les analystes intégrés aux équipes, en observant les opérationnels et leurs méthodes d’investigation, ont fait évoluer les modèles et sont passés à 70–80 % de précision.
C’était à des années-lumière de ce qu’on était capable de faire.
Julien Merali :
As-tu d’autres cas d’usage très concrets rendus possibles par cette organisation ?
Paul Marcombes :
Oui, notamment la communication ciblée pour les clients. Les data analysts répartis dans les équipes pouvaient configurer des communications batch ou temps réel.
Par exemple :
- Lors d’un paiement à l’étranger, ils peuvent proposer une offre premium adaptée.
- En cas de suspicion de fraude faible, envoyer un message d’avertissement.
- Lorsque le solde devient bas, notifier le client et envoyer un warning.
Plusieurs métiers pouvaient ainsi exploiter un même événement client pour envoyer des communications personnalisées. Cela a profondément renforcé la proximité entre le métier et le client.
Ils pouvaient même configurer dynamiquement certains contenus dans l’application mobile selon le comportement utilisateur.
Julien Merali :
On a déjà évoqué plusieurs avantages. Peux-tu compléter, mais aussi nous parler des inconvénients ? À t’écouter, on a envie d’adopter ce modèle immédiatement.
Paul Marcombes :
Un des grands avantages est l’absence de guerre de priorisation.
Dans un modèle centralisé, tous les métiers viennent défendre leurs sujets. Dans un modèle hybride, chaque direction dispose de ses propres ressources et priorise en interne.
Les équipes deviennent autonomes. Si un analyste génère de la valeur, elles trouvent le budget pour en recruter un second.
Cela rend le système scalable.
Nous sommes passés de 300 à 900 collaborateurs sans que l’équipe centrale devienne un goulet d’étranglement. On pourrait continuer à croître sans changer fondamentalement le modèle.
Autre avantage : des analystes “full stack”, capables d’utiliser la data pour servir le métier, quel que soit l’outil.
Si demain les modèles évoluent, si l’IA générative prend plus de place, leur rôle restera pertinent :
- mieux documenter les données. Mais finalement, il fait même boulot parce qu’il a permis aux métiers d’aller explorer eux-mêmes des données très spécialisées ou adapter les usages aux nouvelles technologies.
À l’inverse, un rôle trop spécialisé (par exemple uniquement la production de dashboards) peut devenir fragile si l’IA et l’automatisation progresse.
Côté inconvénients : Malgré la standardisation des outils et l’animation communautaire, il existe toujours un risque de divergence. Les conventions sont moins strictement appliquées qu’en équipe centralisée.
Cela peut générer du “chaos”. Mais c’est parfois positif, car il fait émerger de nouvelles pratiques. Mais maintenir la cohérence devient plus complexe.
Deuxième inconvénient : le modèle nécessite des profils capables de tout faire. Cela ne correspond pas à tous les analystes notamment sur le SQL. Certains préfèrent se concentrer uniquement sur l’analyse, sans transformation de données avancée. Ce qui n’était pas le cas chez nous.
Mais dans certaines organisations, comme les profils sont moins spécialisés, ils sont mécaniquement moins experts dans chaque domaine.
Des Data Analysts qui ne déploient pas des algos de machine learning ne sont pas des cadors du ML et ne feront pas de R&D avancée pour inventer de nouveaux modèles.
Julien Merali :
Après avoir parlé de l’organisation, il y a aussi cette notion de plateforme, qui est centrale. Peux-tu nous expliquer cette vision plateforme ? En préparant cette interview, tu évoquais d’ailleurs la différence entre une vision “plateforme” et une vision “cas d’usage”.
Paul Marcombes :
Effectivement. Nous avons conçu notre data platform comme une plateforme de capacités, capable de répondre à plusieurs cas d’usage.
Au départ, nous avions une plateforme permettant d’exécuter des algorithmes batch et d’envoyer leurs résultats vers une destination donnée. Et après on a fait évoluer ça avec du temps réel.
Prenons le cas des alertes de suspicion de blanchiment.
Nous avions une règle métier — souvent une requête SQL — qui analysait l’ensemble des comportements utilisateurs et produisait une table avec :
- une ligne par alerte,
- des colonnes par alerte contenant les paramètres (montant dépensé, habitudes de versement que le client à l’habitude de recevoir, variations, etc.).
À partir de cette table, nous générons un message à trous complété automatiquement avec ces paramètres, puis envoyé au back-office pour investigation.
Une fois ce système en place, nous avons réalisé que le même mécanisme pouvait servir à tout autre chose.
Par exemple, envoyer des emails marketing automation :
- une règle de ciblage,
- une ligne par email à envoyer,
- des paramètres (nom, prénom, et les différents paramètres qu’on va mettre dans l’e-mail.)
- un e-mail à trous qu’on va remplir avec ces paramètres.
La seule chose qui change, c’est le connecteur de sortie.
- d’un côté, vers le back-office ;
- de l’autre, vers l’outil d’envoi d’emails.
Même logique pour les exports réglementaires.
Nous avons donc appris à penser plateforme avant de penser cas d’usage. Mais chaque nouveau besoin devient l’occasion d’enrichir une capacité réutilisable par d’autres équipes.
Julien Merali :
Dans ce type de modèle, qui décide des évolutions de la plateforme ? L’équipe centrale ? Les métiers ?
Paul Marcombes :
Il y a plusieurs niveaux.
L’équipe centrale construit les outils destinés aux data analysts et, plus largement, à l’entreprise. Pour chaque outil, nous animons une communauté d’utilisateurs.
Nous gérons ces outils comme des produits, avec un fonctionnement proche d’un Product Owner :
- identification des besoins,
- animation de la communauté,
- priorisation des évolutions.
L’équipe centrale reste responsable du développement et de la cohérence globale.
Dans l’équipe centrale, notre objectif a toujours été de créer des outils hautement configurables.
Nous cherchons à construire le minimum viable qui permette aux analystes — ou aux métiers — d’être totalement autonomes, sans intervention permanente du central.
Par exemple, une fois l’outil de marketing automation en place, nous n’intervenons plus dans la création ou le suivi des campagnes. Nous améliorons l’outil, mais nous ne pilotons pas les usages. On ne va plus intervenir pour mettre en place une campagne, faire le suivi de la campagne ou améliorer les campagnes.
Autre exemple : une application web de vision 360° client, avec une vue graphe des relations (flux d’argent, emails partagés, connexions entre comptes, etc.).
Nous avons conçu le squelette :
- une zone graphe,
- une zone d’informations détaillées,
- une zone d’événements liés au nœud sélectionné.
Ensuite, les analystes configurent le contenu affiché selon leurs besoins métier.
Julien Merali :
Si je me mets à la place d’un Chief Data Officer qui nous écoute et souhaite mettre en place ce modèle : Est-ce universel ? Y a-t-il des prérequis ? Certaines organisations sont-elles plus adaptées que d’autres ?
Paul Marcombes :
Il n’existe pas une organisation meilleure qu’une autre. Tout dépend du contexte :
- taille de l’entreprise,
- maturité data,
- culture interne,
- profils présents dans les équipes.
Je suis aujourd’hui dans une organisation beaucoup plus centralisée, avec des experts très motivés, très pointus, qui maîtrisent parfaitement leurs chiffres et répondent efficacement à l’ensemble des métiers. Et cela fonctionne très bien.
Pour ceux qui souhaitent évoluer vers un modèle hybride, je recommande :
- Démarrer petit, là où les chances de succès sont les plus élevées.
- Tester, mesurer, ajuster.
- S’assurer que l’équipe centrale dispose de temps dédié pour accompagner les analystes métiers.
L’équipe centrale doit être au service des équipes métiers.
Si elle impose uniquement des règles et des contraintes, sans aider à les appliquer, elle perdra l’adhésion.
Les conventions, les standards, les cadres sont nécessaires pour garantir la cohérence. Mais ils doivent être accompagnés :
- aide à la mise en œuvre,
- outils qui améliorent la productivité,
- support actif.
Si les outils rendent réellement les équipes plus efficaces, l’adhésion vient naturellement.
L’objectif n’est pas de gouverner par la contrainte, mais de créer les conditions pour que chacun réussisse.
Interview réalisée par Julien Merali, Directeur du Pôle IT – Agora Managers Groupe.
Le Podcast Les Enfants de la Data est un rendez-vous de l’Agora des CDO.
