Ivan Nikitin, PDG et cofondateur de Fortytwo – Série d’entretiens

Ivan Nikitin est PDG et cofondateur de Fortytwo, où il développe une technologie d’inférence en essaim qui réunit plusieurs modèles d’IA afin qu’ils raisonnent et évaluent mutuellement leur travail. Son parcours couvre les jeux vidéo, l’IA conversationnelle, l’IA générative et les systèmes interactifs, notamment chez Temporal et Sensorium. En 2011, il a cofondé Temporal avec Vlad Larin, aujourd’hui cofondateur et directeur technique de Fortytwo. Cette expérience lui a permis de travailler sur des populations d’agents en évolution et des systèmes combinant des modèles spécialisés.

Fortytwo développe une infrastructure d’IA qui permet aux modèles de collaborer pendant l’inférence. Son Fortytwo Engine utilise un Swarm Decoder pour orienter un processus de raisonnement partagé au fil de son déroulement, dans le but d’améliorer la précision et de réduire la génération inutile de jetons lors de tâches longues. L’entreprise propose une API aux développeurs par l’intermédiaire de Fortytwo Engine, ainsi qu’un déploiement sur site avec Fortytwo Harbor.

Avant de cofonder Fortytwo, vous avez passé des années à développer des produits dans les domaines de l’IA conversationnelle, de l’IA générative et des systèmes interactifs chez Sensorium et Temporal. Comment ces expériences ont-elles façonné votre vision des limites des grands modèles de langage pris individuellement et vous ont-elles finalement conduit à l’approche en essaim de Fortytwo ?

Une grande partie de notre équipe, moi y compris, est arrivée à l’IA par le jeu vidéo. Les jeux vidéo ont été le berceau de l’informatique personnelle et de l’IA moderne : ils sont à l’origine de l’existence du GPU, et les jeux ont constitué le premier véritable terrain d’expérimentation de l’apprentissage par renforcement. Les univers de jeu nous ont offert un environnement concret pour créer des agents capables d’apprendre, de s’adapter et de rivaliser. Chez Temporal, que j’ai cofondée en 2011 avec Vlad Larin, aujourd’hui cofondateur et directeur technique de Fortytwo, nous nous sommes d’abord intéressés à l’intelligence évolutive : des populations d’agents en compétition, soumises à une pression de sélection. Nous cherchions à comprendre comment une population pouvait accomplir davantage qu’un agent individuel, à condition de disposer d’un bon mécanisme pour repérer ses contributions les plus fortes et s’appuyer sur celles-ci. La sélection et l’évaluation sont devenues des éléments centraux de notre conception de l’intelligence.

Avec l’arrivée des modèles à transformeurs, nous avons élargi nos activités à l’IA conversationnelle et créé une plateforme de personnages pilotés par l’IA, capables de tenir des conversations libres et non scénarisées, avec une mémoire et une personnalité. C’était environ deux ans avant ChatGPT, et les modèles sur lesquels nous travaillions avaient des fenêtres de contexte de seulement 512 à 1 024 jetons. Il était hors de question de compter sur un seul des premiers modèles de langage pour répondre de manière fiable à toutes les exigences de cette expérience. Nous avons dû créer un pipeline sur mesure composé de modèles spécialisés, chacun ayant une responsabilité plus restreinte, ainsi que la logique nécessaire pour combiner leurs contributions. Le classement et la sélection des réponses sont devenus essentiels au bon fonctionnement de l’expérience dans son ensemble. Nous avons ainsi compris à quel point un système bien conçu pouvait tirer parti de modèles aux capacités limitées.

L’autre enseignement concernait l’efficacité. Nous avons constaté que des modèles spécialisés pouvaient être entraînés et déployés plus efficacement pour des tâches bien définies, ce qui nous permettait d’accomplir davantage avec des ressources de calcul limitées. Mais le passage à l’échelle de l’inférence restait difficile : d’un côté, les plafonds d’utilisation des API et, de l’autre, le coût de l’auto-hébergement à grande échelle. Sans accès à des capacités de calcul de pointe, nous devions réfléchir soigneusement aux moyens de mieux exploiter les ressources disponibles. Fortytwo a réuni ces enseignements dans le concept d’inférence en essaim : plusieurs modèles, ou plusieurs instances d’un même modèle, contribuent au raisonnement tout en évaluant le travail de leurs pairs. Le collectif obtient ainsi une plus grande précision que chacun de ses membres.

Fortytwo Engine utilise plusieurs modèles à poids ouverts pour orienter un processus de raisonnement unique et se vérifier mutuellement au fil de la génération de la réponse. En quoi cette approche diffère-t-elle des systèmes multi-agents classiques, des ensembles de modèles ou du simple fait d’exécuter plusieurs modèles puis de sélectionner la meilleure réponse ?

La principale différence est que l’inférence en essaim est intégrée directement au moteur d’inférence que nous avons développé. Nous l’appelons Swarm Decoder : plusieurs modèles participants façonnent continuellement une seule trajectoire de raisonnement au fur et à mesure de sa génération. L’évaluation et l’orientation ont lieu au sein de ce processus, ce qui permet aux modèles d’en influencer le cours avant que la réponse soit terminée.

Les autres approches fonctionnent différemment. Dans un ensemble de modèles produisant chacun une réponse, les modèles génèrent des réponses distinctes qui sont ensuite classées, sélectionnées ou combinées. La première architecture de Fortytwo, mise en œuvre en 2025, reposait sur le classement par les pairs de réponses achevées. Elle a considérablement amélioré la précision des réponses, mais au prix d’une latence accrue et d’une surcharge de calcul. De nombreux systèmes multi-agents classiques répartissent le travail entre plusieurs agents et s’appuient sur un orchestrateur et des messages en langage naturel pour coordonner leurs contributions. Ces transferts peuvent nécessiter des appels d’inférence supplémentaires, la répétition du contexte et des décisions sur les informations à transmettre d’un agent à l’autre. Avec le Swarm Decoder, il n’y a pas de transfert : les participants travaillent sur une seule trajectoire et échangent uniquement leur avis sur la meilleure direction à prendre.

Le Swarm Decoder est conçu pour repérer les hypothèses fragiles pendant la génération, avant qu’un effort considérable ne soit consacré à les développer. Il vise à réduire les erreurs, les retours en arrière et la génération inutile ; le gain d’efficacité apparaît lorsque les vérifications évitent davantage de travail qu’elles n’en ajoutent. C’est aussi pourquoi il n’y a pas de pénalité de latence : l’exécution suit un chemin plus direct, si bien que l’Engine accomplit les tâches plus rapidement que le même modèle utilisé seul et avec moins de jetons au total, en comptant ceux de tous les modèles participants.

Vous avez évoqué la dérive des modèles au cours des tâches de longue durée comme un problème majeur. Qu’est-ce qui provoque concrètement cette dérive, et comment se manifeste-t-elle dans des applications pratiques comme le génie logiciel, la recherche ou les agents d’IA autonomes ?

La dérive se produit lorsque le contexte d’un modèle s’éloigne peu à peu de la tâche. Au cours d’une longue exécution, le contexte se remplit des propres réponses du modèle, des résultats des outils, du contenu des fichiers et des tentatives répétées. L’instruction initiale occupe une part de plus en plus réduite de ce à quoi le modèle prête attention, et ses erreurs antérieures font désormais partie des éléments à partir desquels il raisonne : les erreurs s’accumulent donc au lieu de s’annuler. À cela s’ajoute le fait que les modèles de raisonnement actuels sont entraînés par apprentissage par renforcement à mener les tâches à bien, et qu’ils apprennent des raccourcis qui donnent l’impression d’y parvenir : ne pas appeler l’outil, déclarer la tâche terminée, résumer au lieu de vérifier. Nous appelons cela de la paresse, et les modèles de pointe en font autant que ceux à poids ouverts. La cause fondamentale est qu’un modèle seul ne dispose d’aucun contrôle externe. Il évalue son propre travail, alors que les modèles sont peu doués pour s’autoévaluer avec précision.

En génie logiciel, on le voit lorsque l’agent corrige le bogue que vous avez décrit, mais enfreint la contrainte que vous aviez énoncée dans le premier message, rédige un test qui réussit sans difficulté ou lit quatre fois le même fichier parce qu’il a perdu le fil de ce qu’il avait déjà appris. En recherche, c’est une longue exécution qui s’éloigne de la question posée pour se rabattre sur celle à laquelle il est le plus facile de répondre, puis fournit un résumé générique. Avec les agents autonomes, la dérive coûte cher : digressions, appels répétés aux outils, retours en arrière et consommation de tokens plusieurs fois supérieure à ce qu’exigeait la tâche.

On peut le quantifier. Nous avons fait exécuter à Qwen 3.8 27B 450 tâches DeepSWE, de véritables tâches de génie logiciel nécessitant l’utilisation d’outils sur de longs contextes, une fois seul et une fois avec Fortytwo Engine. Seul, le modèle utilisait en moyenne 16,3 millions de tokens par exécution, soit 7,4 milliards au total. Avec Engine, le même modèle utilisait en moyenne 12,3 millions de tokens par exécution, soit 5,6 milliards au total, 24,7 % de moins, et réussissait davantage de tâches : 47,8 % contre 42,2 %. Le modèle, lui, n’avait pas changé. Les quatre millions de tokens par exécution économisés correspondaient à la dérive : les relectures, les nouvelles tentatives et les retours en arrière auxquels un modèle seul doit se livrer parce que personne ne repère ses erreurs de parcours au moment où il les commet. L’essaim les repère ; il n’a donc jamais à en payer le prix.

Auparavant, Fortytwo faisait évaluer les réponses terminées des modèles les uns par les autres, tandis que l’architecture actuelle leur permet d’influer sur le processus de raisonnement pendant qu’il se déroule. Qu’avez-vous appris de l’approche précédente, et pourquoi le pilotage en temps réel est-il plus efficace ?

L’architecture de 2025 a démontré que l’on peut atteindre des capacités de niveau des modèles de pointe par une mise à l’échelle horizontale, en faisant participer davantage de modèles plutôt qu’en cherchant à en obtenir un seul toujours plus grand. Un essaim de modèles à poids ouverts qui classaient les réponses complètes les uns des autres a surpassé le meilleur modèle individuel de l’essaim de jusqu’à 17 points de pourcentage. Il s’est aussi montré robuste d’une manière qu’un modèle seul ne peut l’être : face à des requêtes bruitées, à des instructions injectées et à une majorité de réponses erronées.

Cette architecture ne pouvait toutefois pas intervenir. Le classement de réponses terminées fonctionne pour une question isolée, mais les exécutions d’agents comptent des centaines d’étapes, entrecoupées d’appels aux outils, et les erreurs décisives se produisent tôt, puis s’aggravent. Juger à la fin signifie que chaque modèle a déjà payé la totalité du coût en tokens, et que le juge ne peut choisir qu’entre des trajectoires qui ont déjà divergé. Cela signifiait également que le coût de l’essaim augmentait avec le nombre de modèles, ce qui convient pour une question difficile, mais pas pour un agent de programmation.

Le pilotage en temps réel résout ces deux problèmes. Le classement continu exerce une pression de sélection tout au long de l’exécution : un mauvais choix est corrigé là où il se produit, avant de se répercuter sur la suite. L’essaim ne se contente jamais d’une tentative bâclée, car celle-ci est moins bien classée qu’une tentative plus soigneuse. C’est pourquoi le même mécanisme nous permet désormais d’obtenir à la fois une meilleure précision et une consommation réduite de tokens.

Lors de vos tests avec Qwen 3.8 27B, Fortytwo indique avoir utilisé 24,7 % de tokens en moins sur 450 exécutions DeepSWE, tout en améliorant les résultats sur six bancs d’essai. Que se passe-t-il au sein de l’essaim pour qu’il améliore les performances tout en réduisant la consommation de tokens ?

Les vérifications de l’essaim ont un coût faible et fixe ; les opérations de correction qu’elles évitent coûtent d’autant plus cher que la tâche est longue, car chaque erreur de parcours non corrigée compromet tout ce qui se construit à partir d’elle. Plus la tâche est longue, plus les économies potentielles sont importantes. DeepSWE se situe à l’extrémité des tâches les plus longues, ce qui explique pourquoi les économies atteignent près d’un quart du total des tokens.

Pour ce qui est de la précision, tout tient à l’hétérogénéité de l’intelligence. Les progrès des modèles sont généralement inégaux : un modèle peut raisonner au niveau du doctorat dans un domaine et produire des absurdités dans un autre, car le réglage fin, l’apprentissage par renforcement et les autres étapes de post-entraînement améliorent un modèle sur les données qui ont servi à l’entraîner, tandis que les gains diminuent à mesure que les tâches réelles s’éloignent de ces données. Le Swarm Decoder ne modifie pas le modèle. Il améliore le raisonnement lui-même, de façon constante : les six bancs d’essai ne correspondent donc pas à six domaines pour lesquels nous avons optimisé le modèle, mais à six façons de mesurer la même chose. Au final, le modèle est plus intelligent et plus attentif et, avec des pairs qui vérifient chaque étape, on a l’impression qu’il consacre bien plus d’efforts à votre tâche. C’est aussi pourquoi nous pouvons facturer Engine au tarif par token du modèle de base : le client ne paie pas pour un budget plus élevé, mais pour un chemin plus court vers la bonne réponse.

Les développeurs en IA s’inquiètent de plus en plus des coûts d’inférence, car les modèles de raisonnement génèrent des chaînes de jetons toujours plus longues. Pensez-vous qu’améliorer l’efficacité du processus de raisonnement lui-même pourrait, à terme, être aussi important que de rendre les modèles individuels plus petits, plus rapides ou moins coûteux ?

Oui, et je dirais même que c’est déjà le levier le plus important. Rendre les modèles plus petits, plus rapides et moins coûteux réduit le prix d’un jeton. Mais personne n’achète des jetons. Les gens achètent une tâche accomplie, et à l’ère des agents, le nombre de jetons utilisés par tâche a explosé : pour une véritable tâche de programmation, un modèle de raisonnement consomme des millions de jetons, dont une grande partie sert à revenir sur ses pas. Réduire de 25 % le nombre de jetons par tâche a exactement la même valeur qu’une baisse de prix de 25 %, sauf que cette réduction se cumule avec chaque amélioration du matériel, de la quantification et des noyaux de calcul, et que nous pouvons l’appliquer à n’importe quel modèle à poids ouverts disponible sur le marché.

L’industrie dispose de trois leviers. De meilleurs modèles, ce qui relève de l’entraînement et coûte cher. Des jetons moins coûteux, ce qui dépend du matériel et de l’infrastructure d’inférence, et dont les coûts convergent puisque tout le monde utilise les mêmes GPU. Et moins de jetons par tâche, ce qui dépend de la manière dont l’inférence est exécutée et reste un domaine presque inexploré. Jusqu’à présent, la mise à l’échelle a consisté à augmenter la taille des modèles et à allonger les chaînes de pensée ; dans les deux cas, on demande à un seul modèle de tout faire au cours d’une même trajectoire. Nous pensons que le prochain axe sera collectif : plusieurs modèles qui raisonnent ensemble, avec un jugement réparti entre eux, afin que la trajectoire elle-même soit plus courte et plus fiable. Il s’agit d’une autre forme de mise à l’échelle, différente de celle fondée sur le nombre de paramètres ou sur le calcul au moment du test, et c’est celle sur laquelle nous misons. Nous résumons cette approche ainsi : privilégier les pairs plutôt que les paramètres.

Fortytwo Engine est compatible avec l’API OpenAI tout en exécutant des modèles à poids ouverts. Quelle importance a revêtu la compatibilité avec les piles de développement d’IA existantes, et dans quelle mesure les développeurs peuvent-ils facilement faire passer une application d’une API classique à modèle unique à une architecture en essaim ?

La compatibilité est essentielle. L’écosystème des agents — agents de programmation, environnements d’orchestration, frameworks et outils d’évaluation — repose sur le format de l’API OpenAI. Pour les développeurs qui utilisent Fortytwo Engine, le changement revient donc à passer d’un fournisseur d’inférence à un autre : pour une application, un agent, un environnement d’orchestration ou un service compatible, il suffit généralement de modifier un seul paramètre : le point de terminaison, la clé API et le modèle sélectionné.

Ce qui change, c’est le comportement, pas l’intégration. La différence se manifeste lors des longues séquences d’exécution d’agents, où la consommation de jetons et la précision dès la première tentative déterminent le coût : avec le même modèle utilisé par l’intermédiaire d’Engine, les tâches s’exécutent plus vite, avec moins de jetons, et davantage d’entre elles sont correctement accomplies. Je conseille de procéder comme pour tout changement de modèle : lancez l’évaluation que vous utilisez déjà pour votre agent, comparez le nombre de jetons par tâche et le taux de réussite, puis conservez la solution la plus performante.

Merci pour cette excellente interview. Les lecteurs qui souhaitent découvrir l’inférence en essaim et comprendre comment l’évaluation par les pairs peut améliorer l’efficacité du raisonnement peuvent consulter Fortytwo.