DC : Peux-tu te présenter en quelques mots ?
Eric Moura : Je suis Eric, CTO de DealCockpit. Ingénieur de formation, aujourd’hui architecte : un rôle auquel je suis arrivé naturellement après des années en tant que développeur puis DevOps. Multi-certifié, je porte l’ensemble de la plateforme, de l’architecture cloud à la dernière ligne de code. Je fais en sorte de rester très à jour : la technologie évolue vite, et je n’hésite pas à adopter de nouvelles évolutions dès qu’elles me semblent pertinentes. En dehors du travail, je suis un joueur invétéré – jeux vidéo, jeux de plateau, impression 3D… j’adore les défis et la compétition, et de manière générale, construire des choses, que ce soit du logiciel ou du physique.
DC : Tu es ingénieur de formation. Est-ce que tu te souviens du moment où tu as su que tu voulais construire des systèmes, plutôt que simplement les utiliser ?
Eric M. : Honnêtement, ça a toujours été là. En tant qu’enfant, je ne me contentais pas de jouer aux jeux vidéo, je voulais comprendre comment ils marchaient, les modifier, créer les miens. J’ai toujours été fasciné par le fait de partir d’une idée abstraite et d’en faire un projet concret. C’est ce même réflexe que j’ai encore aujourd’hui : quand j’utilise un outil, je pense immédiatement à comment je l’aurais conçu, ce que j’aurais fait différemment. Le passage à l’ingénierie, c’était juste mettre un cadre professionnel sur quelque chose qui était déjà naturel. Et aujourd’hui avec DealCockpit, c’est l’aboutissement de cela : je ne suis pas juste un utilisateur de technos, je construis un produit de bout en bout.
DC : Ton histoire avec DealCockpit remonte à loin, d’abord comme prestataire externe, puis en freelance et maintenant en tant que CTO. D’où vient cette passion pour l’outil ?
Eric M. : Ce qui m’a accroché dès le départ, c’est le domaine. Le M&A, c’est un environnement où chaque détail compte : la confidentialité, la fiabilité, la rigueur. En tant que prestataire externe, j’ai d’abord découvert la plateforme de l’extérieur, et je voyais déjà son potentiel. Ensuite en freelance, j’ai pu mettre les mains dedans vraiment, comprendre ses fondations, ses forces, ses axes d’amélioration. Et c’est là que la passion s’est installée : c’est un produit techniquement exigeant, dans un secteur où on n’a pas le droit à l’erreur. Pour quelqu’un qui aime les défis, c’est le terrain de jeu idéal. Le passage au rôle de CTO, c’était la suite logique, j’avais envie de porter cette vision sur le long terme, pas juste de contribuer ponctuellement.
DC : Qu’est-ce que ça change, de connaître une plateforme de l’extérieur avant de la porter de l’intérieur ? C’est un avantage, un biais, les deux ?
Eric M. : Les deux, clairement. L’avantage, c’est que j’ai eu le regard utilisateur et intégrateur avant d’avoir le regard architecte. Je sais ce qui frustre, ce qui manque, ce qui fait perdre du temps, parce que je l’ai vécu. Quand je prends une décision technique aujourd’hui, j’ai ce filtre terrain que l’on n’a pas forcément lorsqu’on construit un produit en partant de zéro dans une bulle. Le biais, c’est qu’il faut savoir s’en détacher. Quand on connait un système par cœur, on peut avoir tendance à le faire évoluer dans la continuité plutôt qu’à le remettre en question. J’en suis conscient, et c’est pour ça que je reste en veille permanente : je challenge mes propres choix autant que le code existant. Au final, je pense que c’est surtout un avantage. Connaître l’historique d’une plateforme, ses cicatrices, ses compromis permet de prendre des décisions éclairées plutôt que de réinventer la roue.
DC : Concrètement, qu’est-ce que ça signifie d’être CTO d’une data room ? Qu’est-ce qui dans ton quotidien ne ressemble à aucun autre poste de CTO SaaS ?
Eric M. : La différence fondamentale, c’est le niveau d’exigence sur la sécurité. Sur un SaaS classique, une faille c’est embêtant. Sur une data room M&A, une faille peut faire capoter un deal à plusieurs millions, exposer des informations stratégiques, ruiner la confiance d’un client. Ça change tout dans la façon de penser l’architecture, chaque décision technique est pesée à travers ce prisme. Concrètement, mon quotidien c’est un mélange d’architecture, de développement, de DevOps, de veille sécurité et de dialogue avec les équipes commerciales pour traduire des besoins métier très pointus en fonctionnalités robustes. Je ne suis pas un CTO qui fait du PowerPoint ; je suis dans le code tous les jours, je déploie, je monitore, je patche. C’est ce qui me plaît d’ailleurs : la chaîne est courte entre une décision et son impact en production.
DC : La plateforme repose sur une technologie 100% propriétaire. C’est un choix fort, presque contre-courant. Qui l’a posé, et pourquoi tu y crois ?
Eric M. : C’est un choix qui a été posé dès les origines de DealCockpit, et que je porte pleinement aujourd’hui. Pourquoi j’y crois ? Parce que dans notre domaine, la maîtrise totale de la stack n’est pas un luxe, c’est une nécessité. Quand on gère des données aussi sensibles que des documents de due diligence, on ne veut pas dépendre d’une brique tierce dont on ne contrôle ni le code, ni les mises à jour, ni les failles potentielles. Le propriétaire, ça veut dire qu’on sait exactement ce qui tourne, pourquoi, et comment. Chaque ligne de code est la nôtre, chaque choix d’architecture est assumé. Cela demande plus d’efforts, c’est sûr – pas de raccourci, pas de plugin magique. Mais en contrepartie, on a une agilité et une réactivité que les plateformes construites sur des assemblages de briques open source n’auront jamais. Si demain un client a un besoin spécifique ou qu’une menace apparaît, je peux intervenir directement, sans attendre le bon vouloir d’un éditeur tiers.
DC : Les professionnels M&A confient des données parmi les plus sensibles qui soient. Comment tu portes cette responsabilité techniquement : pas dans le discours, dans les choix réels d’architecture ?
Eric M. : C’est la question que je me pose tous les jours, et c’est tant mieux. Concrètement, ça se traduit par des choix très concrets. L’hébergement avec une infrastructure que je maîtrise de bout en bout ; mes multiples certifications ne sont pas pour décorer un CV, mais parce que lorsqu’on porte ce niveau de responsabilité, on doit comprendre chaque couche de son infrastructure. Le chiffrement est en place à tous les niveaux : au repos et en transit, avec une gestion stricte des clés. Les accès sont contrôlés par des permissions granulaires, chaque utilisateur ne voit que ce qu’il doit voir, pas un document de plus. Et au-delà de l’architecture, c’est une discipline quotidienne : les mises à jour de sécurité ne traînent jamais, les audits sont réguliers, et chaque nouvelle fonctionnalité passe par le filtre «est-ce que ça peut créer une brèche ?». Ce n’est pas du marketing, c’est de l’ingénierie. La confiance de nos clients se mérite dans le code, pas dans les slides.
DC : Face aux grands acteurs américains du VDR, quel est l’argument technique / d’architecte que tu mets sur la table en premier ?
Eric M. : La maîtrise. Les grands acteurs américains, ce sont souvent des mastodontes qui ont grandi par acquisition. Le résultat, c’est des plateformes lourdes, pas toujours cohérentes, où l’utilisateur final le ressent. Nous, c’est l’inverse : une stack propriétaire, pensée comme un tout, par quelqu’un qui connaît chaque ligne de code. Et ça se traduit par un time-to-market imbattable. Entre le moment où un besoin arrive et son déploiement en production, il se passe parfois moins d’une journée. Ça, aucun grand acteur ne peut le faire. Au-delà de la vitesse, il y a la proximité : nos données sont hébergées en Europe (à Paris et à Dublin), et on met en place tous les mécanismes de chiffrement nécessaires pour garantir la confidentialité de bout en bout. Pour des opérations M&A, c’est un argument qui n’est pas juste technique, mais stratégique.
DC : Comment restes-tu à jour sur les menaces et les évolutions réglementaires ? C’est quoi ta veille, ta discipline personnelle ?
Eric M. : La veille, c’est pas un créneau dans mon agenda, c’est un réflexe permanent. Je suis très actif sur les communautés tech, je lis beaucoup, je teste beaucoup. Quand une nouvelle technologie ou un nouveau framework sort, je ne me contente pas de lire l’article de blog, je mets les mains dedans pour comprendre ce que ça change vraiment. Côté sécurité, je suis les bulletins d’infrastructure, les CVE, les advisories des dépendances qu’on utilise. Les mises à jour de sécurité ne traînent jamais, c’est une règle non négociable. Pour le réglementaire, je m’appuie sur les publications de la CNIL, de l’ANSSI, et sur les évolutions du cadre européen : RGPD, DORA, NIS2. C’est moins sexy que du code, mais lorsqu’on gère une data room M&A, on ne peut pas se permettre d’être en retard sur ces sujets. Et puis, il y a les certifications que j’entretiens ce qui m’oblige à rester à jour sur les bonnes pratiques cloud ; c’est une discipline en soi.
DC : Comment les retours clients font-ils évoluer la plateforme ? Tu peux donner un exemple d’une demande terrain qui a conduit à un vrai changement technique ?
Eric M. : Les retours clients, c’est le carburant de la roadmap. On n’est pas dans une tour d’ivoire à imaginer des fonctionnalités, on écoute le terrain. Un exemple concret : le caviardage. En due diligence, les clients ont régulièrement besoin de partager des documents tout en masquant certaines informations sensibles (des noms, des montants, des clauses confidentielles). C’est un besoin qui revient tout le temps du terrain. Techniquement, c’est loin d’être trivial : il faut garantir que l’information masquée est réellement supprimée du document, pas juste cachée visuellement, sinon c’est une fausse sécurité. Ce retour terrain a déclenché un vrai travail d’architecture pour intégrer un caviardage fiable, directement dans la plateforme. C’est ça la force d’écouter le terrain : ça pousse à résoudre des vrais problèmes, pas des problèmes imaginaires.
DC : Est-ce qu’il t’arrive de refuser un développement demandé par un client parce qu’il contredit tes convictions en matière de sécurité ou d’architecture ? Comment gères-tu cela ?
Eric M. : Oui, et je ne m’en cache pas. Mon rôle est aussi de dire non quand il faut. Si un client demande quelque chose qui compromet la sécurité de la plateforme ou qui introduit de la dette technique ingérable, je refuse ; mais je ne m’arrête jamais au non. J’explique pourquoi, et surtout je propose une alternative qui répond au besoin sans sacrifier l’intégrité de l’ensemble. C’est une question de responsabilité : je gère un outil de data room qui contient des documents qui valent parfois des centaines de millions d’euros. Si je dis oui à tout pour faire plaisir, c’est l’ensemble des clients que je mets en danger. Les équipes commerciales le comprennent très bien d’ailleurs : avec le temps, cette rigueur est devenue un argument de vente, pas un frein. Quand on dit à un client « on a refusé tel raccourci pour protéger vos données », ça inspire confiance.
DC : L’IA s’invite dans tous les outils professionnels. Comment abordes-tu ce sujet quand la confidentialité des données est non négociable ? C’est quoi ta ligne rouge ? Et est-ce qu’il y a des cas d’usage IA sur lesquels vous travaillez qui pourraient vraiment changer l’expérience d’une due diligence ?
Eric M. : L’IA, c’est un sujet qui me passionne : je l’utilise au quotidien dans mon travail de développement, donc je connais la puissance de ces outils. Mais quand on parle de données M&A, la ligne rouge est claire : aucune donnée client ne sort de notre périmètre pour alimenter un modèle tiers. Jamais. C’est non négociable. Ça veut dire qu’on n’intègre pas de l’IA pour cocher une case marketing. On évalue chaque cas d’usage avec une question simple : est-ce que la donnée reste sous notre contrôle, de bout en bout ? Si la réponse est non, on ne le fait pas. Et surtout, ma vision c’est que l’IA est un outil au service de l’utilisateur, pas un service qui le remplace. C’est un assistant à qui on délègue des tâches simples mais longues et souvent rébarbatives (résumer un document de 200 pages, chercher sémantiquement dans une data room entière). Mais certainement pas de la prise de décision, et même pas donner un avis. Au final, c’est le nom du professionnel et sa responsabilité qui seront sur le dossier, pas celle d’une IA. On regarde cela de très près, avec une approche pragmatique : la technologie doit servir le métier, pas l’inverse, et surtout sans jamais compromettre la confidentialité.
DC : Dans cinq ans, à quoi ressemble une data room selon toi ? Et quel conseil donnerais-tu aujourd’hui à un professionnel M&A qui choisit sa plateforme sans être expert technique ?
Eric M. : Dans cinq ans, je pense que la data room deviendra un véritable espace de travail intelligent, où l’information est indexée, résumée, accessible en quelques secondes. Les tâches chronophages de la due diligence (fouiller, classer, croiser des centaines de documents) seront largement assistées. Mais le cœur restera le même : la sécurité et la confidentialité. Les outils qui ne mettront pas ça au centre disparaîtront. Et pour le conseil à un professionnel M&A qui n’est pas expert technique ? C’est simple : posez trois questions. Où sont mes données ? Qui y a accès ? Et quand j’ai un problème, en combien de temps on me répond ? Si votre interlocuteur ne peut pas répondre clairement à ces trois questions, passez votre chemin. Ne vous laissez pas impressionner par les belles interfaces ou les buzzwords : ce qui compte, c’est ce qui se passe sous le capot. Et si possible, choisissez un acteur qui maîtrise sa technologie de bout en bout. Ça fait toute la différence le jour où ça compte vraiment.