Deux simulateurs, un monde absent — sur les promesses et les lacunes de CarlaAir
Voici un fait qui mérite qu’on s’y arrête : deux des environnements de simulation les plus utilisés en robotique autonome reposent sur le même moteur graphique — Unreal Engine —, ont été publiés à quelques années d’intervalle, et n’ont pourtant jamais été conçus pour fonctionner ensemble. CARLA (Car Learning to Act) simule des véhicules au sol dans des environnements urbains ; AirSim, développé par Microsoft et abandonné par son créateur depuis 2022, permettait de faire voler des drones et de faire rouler des robots terrestres dans des paysages variés. Les deux outils partagent donc déjà, au niveau du code graphique, une infrastructure commune. Et pourtant, si l’on souhaite entraîner simultanément une voiture autonome et un drone dans la même scène simulée — pour modéliser une intersection surveillée par un aéronef, par exemple —, aucun des deux ne suffit. Il faut construire quelque chose de nouveau.
C’est le problème qu’un projet baptisé CarlaAir prétend résoudre. Problème légitime, réponse encore très incomplète.
Avant d’examiner ce que CarlaAir apporte réellement, il faut prendre le temps de comprendre pourquoi la question est difficile. Un simulateur de robotique n’est pas une maquette numérique passive. C’est un environnement actif qui doit générer, à chaque instant, des données sensorielles cohérentes pour un agent en mouvement : images, nuages de points LiDAR (système de mesure par impulsions laser construisant une représentation tridimensionnelle de l’espace), informations inertielles, collisions. Lorsqu’un seul agent évolue dans cet environnement, la tâche est déjà complexe. Lorsqu’il faut synchroniser deux agents appartenant à des dynamiques physiques très différentes — une voiture soumise aux contraintes de la route, un drone soumis à la gravité et aux forces aérodynamiques — la difficulté augmente d’un cran : il faut garantir la cohérence temporelle des perceptions, la gestion des interactions physiques mutuelles, et l’interopérabilité des interfaces logicielles. CarlaAir s’appuie sur ROS2 (Robot Operating System 2) comme couche de communication — le standard de facto en robotique professionnelle —, ce qui facilite en théorie l’intégration dans des pipelines de recherche existants.
C’est précisément là que réside le premier point délicat concernant la thèse de CarlaAir. Les présentations du projet insistent sur une séparation supposément fondamentale entre CARLA (le monde du sol) et AirSim (le monde de l’air). Mais cette dichotomie est une simplification qui ne résiste pas à l’examen. AirSim ne se limitait pas aux drones : il supportait aussi des véhicules terrestres, des robots à roues, et même des configurations hybrides. La frontière entre les deux simulateurs était davantage une question de tradition d’usage et de communauté de pratique que d’incompatibilité technique irréductible. Présenter CarlaAir comme la réponse à une séparation « fondamentale » entre deux mondes hermétiquement cloisonnés, c’est construire une démonstration sur une prémisse plus fragile qu’il n’y paraît.
Ce n’est pas dire que la question posée est sans intérêt — elle l’est assurément. La coordination multi-agents entre systèmes aériens et terrestres est un problème ouvert et actif dans la communauté robotique. Les scénarios pertinents ne manquent pas : cartographie conjointe lors d’opérations de secours, surveillance multi-niveaux d’un environnement, gestion de flotte dans des entrepôts à plusieurs étages. Mais pour évaluer sérieusement ce que CarlaAir apporte à ces problèmes, il faudrait disposer de résultats expérimentaux — des métriques de performance, des benchmarks comparatifs, une évaluation quantifiée du « sim-to-real gap » (l’écart entre les comportements appris en simulation et les comportements observés dans le monde réel) — et, idéalement, d’un article soumis à évaluation par les pairs.
Or CarlaAir n’a, à ce jour, fait l’objet d’aucune publication académique. La seule source publique disponible est au moins un dépôt sur GitHub (louiszengCN/CarlaAir) qui comptait, au moment de la rédaction de cet article, de l’ordre d’une cinquantaine d’étoiles — signal d’une adoption encore très confidentielle dans la communauté. La documentation d’un projet GitHub n’est pas une preuve expérimentale. Elle décrit une intention, une architecture, parfois un exemple de prise en main. Elle ne dit rien des performances réelles du système, de sa robustesse face à des scénarios variés, ni de la façon dont il se comporte lorsque le nombre d’agents augmente. Ce point n’est pas un reproche fait aux auteurs — qui semblent parfaitement conscients du stade précoce de leur projet —, mais il impose une règle méthodologique élémentaire : on ne peut pas traiter les cas d’usage évoqués dans une documentation GitHub (surveillance urbaine, coordination en milieu sinistré) comme des applications documentées. Ce sont des aspirations.
La comparaison avec l’état de l’art réel de la simulation multi-robots est ici éclairante. Des travaux académiques sur la coordination aérienne et terrestre existent sur arXiv et dans les actes des grandes conférences de robotique — ICRA, IROS, CoRL —, certains combinant des approches par apprentissage par renforcement multi-agents avec des environnements de simulation personnalisés. Ces travaux publient systématiquement des courbes d’apprentissage, des taux de convergence, des matrices de performance selon le nombre d’agents. L’absence de tout élément comparable dans la communication autour de CarlaAir n’invalide pas le projet, mais interdit qu’on le situe dans un état de l’art dont il n’a pas encore cherché à se mesurer.
Il faut aussi s’interroger sur une tension inhérente à l’approche retenue. CarlaAir hérite des forces de CARLA — dont la richesse des environnements urbains et la qualité des capteurs simulés sont bien documentées depuis l’article fondateur de Dosovitskiy et al. (2017) — mais aussi de ses contraintes. CARLA est un simulateur lourd, exigeant en ressources graphiques, dont les scènes les plus détaillées nécessitent plusieurs gigaoctets de mémoire vidéo. Y intégrer une couche de simulation aérienne ne fait qu’accroître cette exigence. La question du passage à l’échelle — que se passe-t-il avec dix drones, vingt véhicules, une interaction dense entre les deux populations d’agents ? — n’est pas traitée. Ce n’est pas une question rhétorique : c’est précisément là que les simulateurs multi-agents rencontrent généralement leurs limites les plus sévères, sous la forme d’explosions du temps de calcul ou d’incohérences physiques difficiles à détecter.
Ce tableau ne doit pas conduire à une conclusion définitive dans un sens ou dans l’autre. Un projet logiciel de ce type peut tout à fait mûrir, faire l’objet d’un article soumis à évaluation, et produire des résultats solides. Ce qui est décrit ici reste — pour le moment — une infrastructure prometteuse dont les propriétés réelles ne sont pas encore mesurées. Le problème qu’il aborde, lui, est réel et peu résolu. L’absence de simulateur unifié air-sol est une lacune authentique de l’outillage disponible pour la communauté robotique. Mais l’existence d’un besoin ne suffit pas à valider une solution.
La vraie question, celle qui restera sans réponse jusqu’à ce qu’un papier évalué la tranche, est plus précise : est-ce que des agents entraînés conjointement dans CarlaAir transfèrent mieux vers le monde réel que des agents entraînés séparément dans leurs environnements respectifs ? C’est-à-dire : la couche de réalité partagée qu’apporte ce simulateur réduit-elle effectivement le « sim-to-real gap » pour les tâches de coordination, ou bien l’écart subsiste-t-il, simplement habillé d’une nouvelle interface ? La réponse à cette question exige des expériences, des métriques, et une confrontation au monde physique. Elle n’est, à ce jour, pas disponible.
À lire aussi sur Émergence :
- AGILE : la méthode tout-en-un pour apprendre à un robot humanoïde à bouger dans le monde réel
- Des robots qui gardent le cap même quand tout bouge autour d’eux
- Médaille d’or à l’Olympiade de maths : l’IA dépasse les meilleurs lycéens du monde
Sources
Aucune publication académique évaluée par les pairs n’est disponible pour CarlaAir à la date de rédaction de cet article (mars 2026). Les informations techniques évoquées sont tirées du dépôt public du projet sur GitHub (louiszengCN/CarlaAir). L’article ne cite donc pas de source à DOI ou arXiv pour CarlaAir lui-même, conformément à la règle éditoriale d’Émergence interdisant l’invention de références. Le lecteur souhaitant explorer l’état de l’art de la simulation multi-agents en robotique autonome est invité à consulter les actes des conférences ICRA, IROS et CoRL, ainsi que les dépôts arXiv des catégories cs.RO (robotique) et cs.MA (systèmes multi-agents).