Unite AI : Nikunj Bajaj, cofondateur et PDG de TrueFoundry – Série d'entretiens

Nikunj Bajaj est cofondateur et PDG de TrueFoundry, où il définit la vision et la stratégie de l'entreprise pour concevoir des plateformes d'IA fiables et de qualité professionnelle. Fort de son expérience dans le développement de produits technologiques et la gestion d'équipes, il aide les organisations à déployer et à exploiter leurs systèmes d'IA de manière sécurisée et efficace. Il publie régulièrement des analyses sur l'adoption de l'IA en entreprise, les stratégies de plateformes d'IA et les tendances émergentes de l'IA en production.

TrueFoundry est une plateforme d'infrastructure d'IA pour les entreprises qui aide les organisations à concevoir, déployer, gouverner et mettre à l'échelle des applications de machine learning et d'IA générative dans des environnements Kubernetes, qu'ils soient dans le cloud, sur site ou hybrides, tout en garantissant une gouvernance, une sécurité et un contrôle des coûts rigoureux. Elle combine une passerelle d'IA (AI Gateway) pour centraliser l'accès aux modèles, aux LLM et aux flux de travail des agents, avec des outils de réglage fin, de déploiement, de surveillance et de mise à l'échelle automatique, visant à simplifier le MLOps et à accélérer le retour sur investissement pour les équipes de science des données et d'ingénierie. L'approche de TrueFoundry, axée sur les développeurs et indépendante du cloud, met l'accent sur la conformité et la flexibilité, permettant aux équipes de gérer des charges de travail d'IA complexes sans dépendance vis-à-vis d'un fournisseur, tout en respectant des normes telles que SOC 2, HIPAA et ITAR.

Avant de fonder TrueFoundry, vous avez travaillé dans la recherche en machine learning, sur l'IA en production chez Facebook et sur des systèmes de recommandation à grande échelle. Quelles expériences vous ont le plus poussé à créer une entreprise d'infrastructure d'IA pour les entreprises, et quel problème majeur n'était pas résolu à l'époque selon vous ?

Chez Meta, nous considérions le machine learning comme un cas particulier du logiciel, et l'IA générative comme un cas particulier du machine learning. Cela aboutissait à une pile verticale avec le logiciel à la base, le machine learning au milieu et l'IA générative au sommet. Dans cette configuration, si je suis un développeur en machine learning, les modèles que je construis suivent le même schéma de déploiement que le reste du logiciel, ce qui rend la mise à l'échelle des systèmes très simple.

La plupart des entreprises, cependant, déployaient des piles parallèles, ce qui signifie qu'elles avaient des piles distinctes pour le logiciel, le machine learning et l'IA générative. Dès lors que vous avez ces piles parallèles, la mise à l'échelle devient plus complexe en raison des transferts nécessaires entre le machine learning et le monde du logiciel.

Notre équipe a toujours travaillé à l'intersection de la conception de modèles de machine learning et de l'infrastructure associée. Nous avions donc un point de vue unique : nous pouvions apporter des piles verticales similaires aux entreprises et les adapter à leurs besoins spécifiques. Fin 2021, nous avions également l'hypothèse que le machine learning approchait d'un point d'inflexion et que, le moment venu, davantage d'entreprises auraient besoin d'une pile intégrée verticalement pour déployer et mettre à l'échelle ces systèmes efficacement. C'est ce qui nous a finalement conduits à fonder TrueFoundry, et notre hypothèse s'est révélée exacte. L'adoption de l'IA s'est accélérée après le lancement de ChatGPT fin 2022.

À mesure que les systèmes d'IA passent de l'expérimentation aux opérations quotidiennes, qu'est-ce qui a changé dans la manière dont les organisations devraient envisager la fiabilité et les pannes ?

Les enjeux liés à l'IA générative sont nettement plus élevés que ceux des systèmes de machine learning traditionnels. À mesure que ces systèmes passent en production, les organisations sont confrontées à un niveau d'ambiguïté et de non-déterminisme beaucoup plus élevé, car les LLM sont stochastiques par nature. Les systèmes d'agents construits par-dessus ajoutent encore plus d'incertitude.

De plus, les pannes ne sont plus binaires. Au lieu que les systèmes fonctionnent ou tombent simplement en panne, de nombreux problèmes se manifestent sous forme de défaillances partielles ou de dégradations silencieuses. Les systèmes peuvent répondre avec une latence plus élevée, une qualité dégradée ou un comportement incorrect au fil du temps. Dans bien des cas, ces dégradations peuvent être plus difficiles à détecter et parfois plus dommageables qu'une panne totale.

Les organisations doivent penser la fiabilité non seulement en termes de disponibilité, mais aussi en termes de dégradation des performances au fil du temps.

TrueFailover a été lancé dans un contexte marqué par une vague de perturbations majeures des services cloud et d'IA. Quels événements récents ont clairement montré que la fiabilité de l'IA n'était plus une option, mais une exigence architecturale fondamentale ?

L'un de nos clients dans le secteur de la santé, qui traite des demandes de patients urgentes et sensibles liées à des ordonnances, a été touché par une panne causée par une défaillance de modèle. Leurs flux de travail génèrent des milliers de dollars de revenus par seconde, et la panne a perturbé certains de ces processus critiques. En tant que client précoce de TrueFailover, nous avons pu aider à une récupération rapide, limitant ainsi l'impact.

Des incidents comme celui-ci soulèvent une question importante. Alors que les enjeux des systèmes d'IA générative continuent de croître, pourquoi les processus de récupération sont-ils encore largement manuels ? Cela a renforcé l'idée que les systèmes doivent être conçus en partant du principe que des pannes surviendront, et qu'ils doivent être capables de se corriger automatiquement. La fiabilité doit également être intégrée à la pile d'IA elle-même grâce à l'utilisation de passerelles d'IA (AI Gateways), qui peuvent assurer un routage centralisé, une observabilité, des garde-fous et une commutation intelligente entre les modèles des différents fournisseurs.

De nombreuses pannes d'IA sont encore considérées comme de simples incidents techniques. Où voyez-vous apparaître les véritables coûts économiques et humains lorsque les systèmes d'IA tombent en panne ?

L'IA en entreprise a évolué au point que ces incidents ne touchent plus seulement les flux de travail internes. Aujourd'hui, les pannes et les dégradations affectent directement et immédiatement l'image publique et les profits, car les cas d'usage en production sont désormais tournés vers les clients. Ce passage des tests internes aux applications critiques exposées au public explique pourquoi nous constatons une demande accrue d'attention et de supervision de la part des dirigeants.

À mesure que les systèmes d'IA s'intègrent plus profondément dans les flux opérationnels, les pannes ne sont plus seulement des problèmes techniques. Elles ont de plus en plus de conséquences directes sur l'activité, les clients et la réputation.

Dans des environnements critiques comme les pharmacies, les opérations de santé ou le service client, à quelle vitesse une interruption de l'IA peut-elle se transformer en risque opérationnel ou de réputation ?

Dans les environnements critiques, l'escalade est quasi immédiate car ces systèmes soutiennent des flux de travail en temps réel et sensibles au facteur temps. Même une courte interruption peut paralyser des processus essentiels, retarder la prestation de services ou interrompre des systèmes en aval qui dépendent de ces résultats, créant des effets opérationnels en cascade dans toute l'organisation.

Dans des secteurs comme la santé, l'impact dépasse la simple perturbation opérationnelle pour toucher l'expérience client et les résultats des services. Si un patient ne peut pas obtenir son ordonnance à temps, les conséquences peuvent être réelles. Non seulement cela pose problème pour le patient, mais cela peut également nuire à la réputation d'une pharmacie ou d'un prestataire de soins. Dans les environnements où la confiance est primordiale, il est essentiel que les systèmes restent opérationnels. C'est pourquoi les organisations reconnaissent de plus en plus que les systèmes d'IA doivent être conçus en supposant que des pannes se produiront et que des mécanismes de récupération doivent s'activer automatiquement pour minimiser les risques.

Vous avez déclaré que de nombreuses équipes conçoivent leurs systèmes pour la performance plutôt que pour la continuité. Pourquoi pensez-vous que la résilience a été historiquement reléguée au second plan dans la conception des systèmes d'IA ?

Cela tient en grande partie aux mécanismes d'incitation au sein des organisations. Les nouvelles fonctionnalités sont visibles et enthousiasmantes. Elles permettent de créer des démonstrations, des fonctions et des possibilités de produits que la direction peut immédiatement visualiser.

Par définition, la continuité est invisible lorsque tout fonctionne bien. Pour cette raison, les systèmes de récompense ont tendance à privilégier le déploiement de nouvelles fonctionnalités plutôt que la prévention des pannes. En conséquence, les organisations investissent souvent de manière disproportionnée dans le développement de capacités au détriment de l'ingénierie de résilience.

Alors que les entreprises dépendent de plus en plus de modèles et d'API externes, quelles nouvelles fragilités sont introduites dans la pile technologique IA, que les dirigeants n'ont peut-être pas encore pleinement identifiées ?

Les LLM sont fondamentalement des ressources partagées, et les entreprises ne les possèdent pas comme elles le feraient pour une infrastructure traditionnelle. De plus, des systèmes critiques pour l'entreprise reposent sur des systèmes externes qui n'ont pas encore fait leurs preuves sur le long terme. Les LLM eux-mêmes évoluent rapidement, ce qui signifie qu'un fournisseur de modèles ne peut être tenu responsable d'une légère baisse de latence ou de performance, car il itère très rapidement sur ses recherches.

Comme les LLM sont des ressources partagées, la latence peut augmenter si un autre utilisateur effectue une action spécifique. La nature même des LLM introduit de nombreux points de défaillance, et dans ce nouveau monde, les entreprises n'ont tout simplement pas un contrôle total. Sans contrôle total, la meilleure chose à faire est de créer suffisamment de redondances pour concevoir un système résilient.

Sans se concentrer sur des produits spécifiques, comment les organisations devraient-elles repenser l'architecture de l'IA pour anticiper les pannes plutôt que de traiter les interruptions comme des cas isolés rares ?

Les organisations devraient revenir aux principes fondamentaux de la conception des systèmes distribués. Les systèmes logiciels ont été construits en partant du principe que les composants réseau et les machines finiraient par tomber en panne, et qu'une région entière pourrait devenir indisponible.

Les systèmes d'IA ne devraient pas faire exception. Nous devons partir du principe que les fournisseurs de modèles connaîtront des problèmes de latence, des dégradations ou des pannes, et intégrer une redondance afin que les applications restent résilientes face aux différents scénarios de défaillance.

Pensez-vous que la résilience de l'IA deviendra un facteur décisif dans le choix des plateformes et des fournisseurs, tout comme le temps de disponibilité et la redondance ont façonné les décisions en matière d'infrastructure cloud ?

À mesure que davantage de systèmes d'IA passeront en production, la résilience deviendra une condition sine qua non. Si un fournisseur ne peut pas présenter ses graphiques et ses mesures sur le temps de disponibilité et la résilience globale, il ne sera même pas pris en considération. Une fois que la résilience sera devenue une attente de base, les facteurs décisifs se déplaceront vers l'expérience utilisateur, l'optimisation des performances, l'observabilité et les capacités produit de haut niveau. Avec le temps, des composants tels qu'une passerelle IA (AI Gateway) et des capacités de basculement automatique deviendront des éléments fondamentaux de l'infrastructure IA en entreprise.

En nous tournant vers l'avenir, que signifie réellement une IA « prête pour la production » dans un monde où l'on attend de l'IA qu'elle soit disponible en permanence, et pas seulement utile occasionnellement ?

Les systèmes d'IA prêts pour la production doivent être observables, contrôlables et récupérables. Ces trois conditions doivent impérativement être remplies.

Pour qu'une IA de production soit observable, les équipes ont besoin d'une visibilité approfondie sur le comportement du modèle, la latence, les taux d'erreur, l'utilisation des jetons, la dérive et les schémas de défaillance. Sans une forte observabilité, il devient très difficile de détecter les dégradations avant que les utilisateurs ne commencent à les remarquer.

Pour que les systèmes soient contrôlables, cela inclut la gestion du trafic, la limitation du débit, les garde-fous, l'application des politiques et le routage intelligent entre les modèles et les fournisseurs. C'est là qu'une passerelle IA devient fondamentale, agissant comme un plan de contrôle centralisé qui applique des garde-fous, assure une gouvernance cohérente et permet un basculement dynamique de modèle en cas de baisse de performance ou de fiabilité.

Enfin, en ce qui concerne la récupérabilité, les systèmes doivent être conçus en partant du principe que les composants peuvent être partiellement ou totalement défaillants, que ce soit en raison de pannes du fournisseur, d'une dégradation de la qualité du modèle, de limites de débit ou d'entrées inattendues provenant d'acteurs malveillants. Le basculement automatique et les mécanismes d'auto-guérison doivent être natifs à l'architecture, et non des procédures manuelles déclenchées après coup.

C'est la direction que nous prenons chez TrueFoundry. Les fournisseurs qui définissent la préparation à la production de cette manière, en combinant observabilité, contrôle centralisé et récupération automatique, gagneront la confiance des clients sur le long terme et seront capables de résoudre les nouveaux problèmes à mesure qu'ils émergent.

À propos de TrueFoundry :

TrueFoundry fournit une passerelle IA de qualité entreprise qui englobe une passerelle LLM, une passerelle MCP et une passerelle d'agents, permettant aux entreprises de connecter, d'observer et de gouverner en toute sécurité l'accès aux modèles, outils, garde-fous et agents depuis un plan de contrôle unique. La passerelle IA permet des charges de travail agentiques sécurisées, efficaces et pérennes grâce à des connexions unifiées et composables entre les fournisseurs.

Au-delà de la couche de passerelle, TrueFoundry permet aux organisations de déployer et d'entraîner des LLM personnalisés sur des GPU, d'héberger des serveurs MCP et d'exécuter des agents personnalisés, le tout via une interface native Kubernetes. Elle prend en charge les installations sur site et VPC pour la passerelle IA et les environnements de déploiement. TrueFoundry garantit une conformité de niveau entreprise avec les normes SOC 2, HIPAA et ITAR. Grâce à l'autoscaling, à la mise en cache et à l'optimisation des ressources intégrés, TrueFoundry permet aux organisations de construire, déployer et gouverner des systèmes d'IA de manière sécurisée, efficace et sur une pile technologique pérenne. Pour en savoir plus, visitez truefoundry.com