Transcription

• Timothé

  On s'est rendu compte assez rapidement au début de la révolution de l'IA. C'était comme onboarder une nouvelle personne dans ton entreprise quand tu fais venir un agent ou même juste une IA et qu'en fait cette personne, on ne peut pas lui faire confiance par défaut. La source d'erreur... ou de vulnérabilité, elle vient de comment est-ce qu'on interagit avec la technologie plutôt que la technologie. Et l'IA en fait, ça rajoute une troisième personne dans cette boucle, qui a un potentiel qui est énorme. Ça s'arrête jamais, c'est 24h sur 24, 7 jours sur 7. Un humain, avant de faire une action, on a quand même un contexte d'entreprise qui nous a été instruit depuis notre plus jeune âge, on est allé à l'école, on a grandi. Il y a une certaine confiance d'humain en humain. T'as peur de la faute d'orthographe, t'as peur... L'agent, il a pas peur. Il a pas du tout cette notion-là. On parle d'attaque, et il y a... Tout ce département qui est vraiment le côté malicieux et l'attaque, mais il y a aussi le comportement qui est juste une erreur. Et en fait, l'IA, par son côté non déterministe, elle va faire des actions qui sont non voulues et qui vont avoir le même effet qu'une attaque, entre guillemets. La plupart de ces catastrophes, elles se passent sur les 150, 250 premiers runs d'un agent. Souvent, on ne prend pas le temps de réfléchir l'IA pourquoi. Maintenant que c'est tellement commodisé d'écrire du code et de créer des agents, c'est la partie réflexion, la partie d'architecture au début sur laquelle il faudrait continuer à se pencher.

• Noham

  On parle d'agents d'IA partout, dans les pitches, dans les démos, dans les conférences, dans les roadmaps. Mais une question revient systématiquement. Qui contrôle ce que font les agents ? Alors aujourd'hui, j'accueille Timothée Husson. Bonjour Timothée.

• Timothé

  Bonjour.

• Noham

  Qui est CTO de Hodor. Et justement, Hodor s'attaque à ce problème de gouvernance, une couche d'identité et de politique pour les agents IA. Hodor a été fondée en 2025, c'est une startup parisienne et qui a décroché d'ailleurs le prix de l'innovation de l'année à Vivatech la semaine dernière en 2026. Le marché n'a pas encore de leader et Hodor pourrait peut-être devenir ce leader. En tout cas, mon invité pour ce podcast aujourd'hui... Timothée, CTO et co-fondateur de Hodor, un parcours atypique que tu vas nous décrire. On va parler d'identité, on va parler d'agents, on va parler de MCP, enfin bref, tout ce qui tourne autour des agents. Timothée, bienvenue dans ce podcast MVP, Most Valuable People. Je suis ravi de t'accueillir. Merci à Dell Technologies qui est notre partenaire et Hodor qui est d'ailleurs... Dans les dernières activités, beaucoup d'activités finalement chez Hodor, vous êtes officiellement partenaire de Dell Technologies. Écoute, Timothée, présente-toi, qui tu es, d'où tu viens, comment tu as cofondé justement Hodor et pourquoi avoir justement créé cette startup autour de la sécurisation des agents ?

• Timothé

  Déjà, merci beaucoup. Du coup, je me présente, Timothée, cofondateur d'Hodor et CTO. Donc comme tu l'as décrit, Hodor c'est vraiment une couche de sécurité entre tout ce qui va être instance IA, un agent, un chat ou tout ce que tu veux et tout ce qui va être applicatif, donc tes emails, ta base de données, ton API interne ou autre. La raison pour laquelle on a confondé Hodor avec Karim, c'est qu'on s'est rendu compte assez rapidement au début de la révolution de l'IA que c'était comme onboarder une nouvelle personne dans ton entreprise quand tu fais venir un agent ou même juste une IA et qu'en fait cette personne, on ne peut pas lui faire confiance par défaut. Et donc dès nos premiers tests de vibe coding, d'essayer de one-shotter des applications ou autres, on s'est rendu compte que tous les outils que tu donnes à une IA, ils vont être appelés. C'est qu'une question de probabilité et quand on voit le volume de ces actions, ça arrive beaucoup plus vite qu'on le croit. Et donc on s'est rendu compte que pour faire confiance à cet outil, il fallait déjà être capable d'observer ce qu'il faisait et de le contrôler. Donc c'est venu assez naturellement dans tous nos tests de... de prototypage d'autres idées, d'autres solutions qu'on avait en tête, de se dire en fait c'est ce player-là qu'il faut être capable d'observer et capable de gouverner. Il faut lui laisser l'autonomie sur la partie thinking, et en fait commencer vraiment à mettre ses guardrails sur la partie acting. D'où l'idée vraiment de se positionner au niveau des interactions avec les applications métiers, qui elles n'ont jamais été conçues pour l'IA, elles ont été conçues pour des utilisateurs humains. pour des API mais qui étaient appelés par du code qui était généré par l'humain donc qui avait vraiment un côté très déterministique et qui en fait, on fait de la plomberie pour les connecter à ces nouveaux outils d'IA et la plomberie elle n'est pas propre aujourd'hui.

• Noham

  Mais à l'origine de votre projet avec KM, je voulais savoir est-ce que tu avais déjà une appétence sur la sécurité ? Tu étais déjà dans cet univers-là où c'est justement en faisant des tests, en cherchant, en bricolant si j'ai envie de dire comme ça ? Tu as découvert qu'il y avait vraiment une opportunité et qu'il y avait un manque finalement aussi d'outils pour sécuriser tout ça ?

• Timothé

  Donc moi j'ai un background en sécurité, j'ai commencé en start-up à New York où je bossais sur des algorithmes d'authentification et d'encryption avant de faire du conseil et de la réponse en cas d'incident. Et ce qui m'a toujours fasciné... Le fascinant dans la sécurité, c'est qu'on parle beaucoup de vulnérabilité, de hack ou quoi que ce soit, mais ce qu'on voit, c'est que dans la majorité des cas, l'erreur, elle est humaine. C'est un email de phishing, un not pass qualiqué ou autre. Et donc, en fait, c'est vraiment la source d'erreur ou de vulnérabilité, elle vient de comment est-ce qu'on interagit avec la technologie plutôt que la technologie. Et l'IA, en fait, ça rajoute une troisième personne dans cette boucle qui a un potentiel qui est énorme. Mais qui, par son volume d'activité, ça ne s'arrête jamais. C'est 24 heures sur 24, 16 jours sur 7.

• Noham

  Et ça se démultiplie.

• Timothé

  Complètement.

• Noham

  Tu vois, on a parlé un petit peu de la partie agent qui va exploser en termes de coûts, notamment sur la partie token. Ça explose, on a dit, 2027 fois 30 des coûts liés justement à l'introduction de l'agent Sikya. Donc en effet, ça rejoint... comment ce que tu évoquais, c'est-à-dire l'exposition de failles potentiellement de sécurité. Moi, j'avais un chiffre, c'était en termes de cyberattaques, on va dire la plus forte probabilité d'être attaqué vient des insiders. Donc, de l'intérieur, je crois que c'est à peu près une trentaine de pourcentage d'attaques liées aux gens internes. Et donc, ce que tu dis, c'est que l'Alia va rajouter encore une personne supplémentaire dans... Dans cette organisation qui va encore multiplier le nombre d'attaques, c'est à peu près combien de pourcentages ? Tu sais à peu près ?

• Timothé

  Ce qu'on voit, c'est que la plupart, enfin, on parle d'attaques, et il y a tout ce département qui est vraiment le côté malicieux et l'attaque, mais il y a aussi le comportement qui est juste une erreur. Et en fait, l'IA, par son côté non déterministe, elle va faire des actions qui sont non voulues et qui vont avoir en fait le même effet qu'une attaque, entre guillemets. Ça peut te compromettre une base de données, mettre des fausses données dans ton CRM. Liquer de l'information par email vraiment de manière accidentelle. Et nous ce qu'on a vraiment observé, c'est que la plupart de ces catastrophes, elles se passent sur les 150-250 premiers runs d'un agent. Et en fait c'est sur les premiers tests, quand les prompts ne sont pas 100% bien faits, quand tout n'a pas encore été réfléchi que ça part en cap.

• Noham

  Et comment vous intervenez aussi ? On voit beaucoup de plus en plus les phénomènes de prompt adjunction. ou comment tu vas pouvoir inclure quelque chose de malveillant. Vous faites quelque chose là-dessus ? Vous avez des mécanismes pour essayer de garantir ou de cloisonner cette partie-là ?

• Timothé

  Une fois de plus, nous, on va rester complètement agnostique de la partie thinking. S'il y a une injection de prompte, mais qui ne parle pas de tools, nous, on considère que c'est comme un humain avec une pensée malveillante. Tant que c'est une pensée, ce n'est pas très grave. Nous, on veut vraiment protéger les applications métiers à lesquelles c'est lié. Et donc ce qu'on fait, c'est qu'on va toujours inspecter les actions et on va faire des checks de détection d'anomalies dans le comportement agentique ou de comportements qu'on considère dangereux. Et à ce moment-là, le but, c'est de bloquer l'action plutôt que de le bloquer au niveau du prompt.

• Noham

  D'accord. Et j'ai une question, c'est quand les entreprises se lancent avec des agents IA, de ton retour, quelles sont les erreurs classiques que tu as ? que tu vois revenir, assez récurrente entre guillemets, tu dis à chaque fois c'est toujours un petit peu la même chose, donc quel est ton retour d'expérience là-dessus ?

• Timothé

  Je pense qu'il y a beaucoup d'implémentations de l'IA qui est liée un peu à une faux mot. Tout le monde parle d'IA, tout le monde veut faire l'IA, il y a la pressure bottom-down d'implémenter l'IA dans des processus, il y a une pressure bottom-up qui est de dire moi je veux utiliser de l'IA pour aller plus vite. Et souvent on ne prend pas le temps de réfléchir l'IA pourquoi, et on essaye de viser trop gros trop vite. Et donc plutôt que... Maintenant que c'est tellement commodisé d'écrire du code et de créer des agents, c'est la partie réflexion, la partie d'architecture au début sur laquelle il faudrait continuer à se pencher et à essayer de vraiment prendre le temps de bien faire et de commencer dans un processus itératif de faire petit à petit. Et en fait, je pense que les gens font confiance trop rapidement. On dit souvent « assume breach » et se dire que c'est problématique depuis le début, qu'à chaque fois que tu donnes une autorisation ou un consentement, il y a potentiellement un blast reduce derrière qui est assez énorme. Et du coup, dès le début, se dire, OK, on va commencer petit, on va faire des tests, on va faire des réductions. Et dès le début du projet, avoir une notion de traçabilité, d'observabilité et de contrôle de ce qui se passe. Pas se dire que c'est quelque chose qu'on rajoutera avant la mise en production, parce qu'en réalité, l'erreur, elle va arriver très vite sur les premiers tests. Et en fait, si tu le rajoutes plus tard, c'est problématique.

• Noham

  D'accord. stem Tu as plus ou moins répondu à mon autre question qui était quand on a commencé, une entreprise commence quelques pilotes, qui tournent bien, souvent c'est ça, donc que ce soit, je n'ai pas envie de parler de POC parce que pour moi un POC c'est jetable, mais plutôt quand on a commencé sur une... plateforme MVP, donc tout se passe plutôt sereinement. Quels seraient tes conseils pour passer à l'échelle justement ?

• Timothé

  Si tu ne l'as pas fait dès le début de l'itération, mettre de l'observabilité, mettre vraiment de la détection d'anomalies, faire des vrais tests à balles réelles, faire des evals, le faire tourner beaucoup de fois. Et après, implémenter un peu toutes les bonnes pratiques. L'OASP donne beaucoup de conseils là-dessus. Il y a le processus de l'ease agency qui dit en fait, il faut vraiment limiter le quand, le comment, le pourquoi de ce que peut faire chaque agent. Nous, c'est vraiment sur ça qu'on a fondé Hodor.

• Noham

  D'accord.

• Timothé

  Et de se dire qu'en fait, le comportement attendu d'un agent, il faut que ça soit son comportement permis. Plus le comportement permis est plus grand que le comportement attendu, plus il y aura d'erreurs.

• Noham

  D'accord. Juste pour finir un petit peu sur cette compréhension-là, concrètement, en quoi un agent IA est-il plus compliqué à sécuriser qu'un simple utilisateur ou un simple service ou plusieurs services ?

• Timothé

  Je pense que c'est la question la plus intéressante, dans le sens où il y a les réponses obvieuses qui vont être le volume d'action, le fait que ça peut travailler 24 heures sur 24, le fait que ça travaille très rapidement. Mais je pense que les deux choses, c'est un peu une... La peur et l'éthique. En fait, un humain, avant de faire une action, on a quand même un contexte d'entreprise qui nous a été instruit depuis notre plus jeune âge. On est allé à l'école, on a grandi. Et donc, il y a une certaine confiance d'humain à l'humain. Tu sais, quand tu es dev, que tu ne vas pas dropper une base de données en production. C'est quelque chose que tu fais hyper attention. Tes premiers mails, tu les relis. Tu as peur de la faute d'orthographe, tu as peur. L'agent, il n'a pas peur. Il n'a pas du tout cette notion-là. Et donc, il fait. et Et en fait, on lui fait trop confiance dès le départ.

• Noham

  Oui. Écoute, merci Timothée pour cette interview. Merci de nous avoir permis de découvrir qui est Hodor. Et encore une fois, on est très fiers de vous accueillir comme partenaire technologique pour Dell Technologies. Et félicitations encore pour votre award en tant que startup innovante que vous avez reçue à VivaTech. Donc chapeau et je vous souhaite plein de succès à Audor.

• Timothé

  Merci, c'est un honneur pour nous de travailler avec Dell.

• Noham

  Super. Merci Tim.

• Timothé

  Merci.