Construire un agent IA en 2026, c'est généralement jongler avec quatre artefacts séparés : des templates de prompts dans un dossier, des schémas d'outils JSON dans un autre, du code de callback quelque part entre les deux, et un graphe de workflow pour relier le tout. Modifiez l'un, et vous cassez silencieusement les trois autres.
Le 22 juillet 2026, NVIDIA Labs a publié un article proposant quelque chose de presque agressivement simple. Sa thèse tient en une phrase : un agent est un objet Python.
Le framework s'appelle NOOA — NVIDIA Object-Oriented Agents — et il est agnostique quant au modèle. Son argument n'est pas qu'il nous faut un meilleur framework d'agents. C'est qu'il nous faut surtout moins d'abstractions spécifiques aux agents, parce que Python en possède déjà de bonnes.
L'idée centrale
Dans NOOA, la correspondance entre programmation orientée objet et conception d'agents est directe :
| Concept Python | Concept agent |
|---|---|
| Méthodes | Actions disponibles pour le modèle |
| Attributs | État de l'agent |
| Docstrings | Prompts |
| Annotations de type | Contrats |
La partie astucieuse tient à la façon dont une méthode devient pilotée par le modèle. Une méthode dont le corps est littéralement ... est complétée à l'exécution par une boucle d'agent pilotée par un LLM. Une méthode avec un corps normal reste du Python ordinaire et déterministe.
from dataclasses import dataclass
@dataclass
class AuditeurFactures:
"""Vous auditez les factures fournisseurs d'une PME tunisienne.
Signalez tout ce qui viole les règles de facturation électronique TTN."""
company_id: str
signalees: list[str]
def charger_factures(self, mois: str) -> list[dict]:
# Python normal. S'exécute de façon déterministe, à chaque fois.
return db.query(self.company_id, mois)
def evaluer(self, facture: dict) -> tuple[bool, str]:
"""Déterminez si cette facture est conforme.
Renvoyez le verdict et une justification en une phrase."""
...charger_factures est du code que vous avez écrit. evaluer est du code que le modèle exécute. Les deux vivent dans la même classe, partagent le même état, et se lisent de la même manière pour un relecteur humain.
Cette seule décision de conception rend tout le reste intéressant. Puisque l'agent est un objet, vous pouvez le tester, le tracer, le refactoriser, en hériter et le versionner exactement comme n'importe quel autre module de votre base de code. Il n'y a pas de registre de prompts séparé à maintenir synchronisé. La docstring est le prompt, elle est donc relue dans la même merge request que le code qu'elle décrit.
Six idées sur une seule surface
La deuxième contribution de l'article est une thèse sur la consolidation. NVIDIA identifie six capacités orientées modèle et affirme que NOOA est le premier framework à les combiner toutes au même endroit :
- Entrées/sorties typées — les retours du modèle sont validés contre de vraies annotations de type Python, pas contre un schéma JSON maintenu à la main.
- Passage par référence sur objets vivants — le modèle reçoit des poignées vers de vrais objets en mémoire, pas des instantanés sérialisés.
- Le code comme action — le modèle agit en écrivant et exécutant du Python, plutôt qu'en émettant du JSON d'appel d'outil.
- Boucle d'agent programmable — la boucle elle-même est du code que vous façonnez, pas un runtime opaque.
- État d'objet explicite — l'état vit dans des attributs inspectables, pas enfoui dans l'historique de conversation.
- API de harness appelables par le modèle — le modèle peut interroger son propre contexte et son flux d'événements par de simples appels de méthode.
Fait notable, les auteurs ne revendiquent pas l'invention de ces idées. Ils observent explicitement que la communauté converge déjà vers plusieurs d'entre elles, souvent sous forme de fonctionnalités expérimentales ou partielles, et présentent la comparaison pour encourager leur adoption. Ce cadrage est rafraîchissant d'honnêteté, et c'est probablement le signal le plus important pour les praticiens : ces six propriétés deviennent l'attente de base pour tout runtime d'agents sérieux.
Pourquoi le passage par référence compte plus qu'il n'y paraît
Parmi les six, celle qui mérite qu'on s'y attarde est le passage par référence sur objets vivants.
La plupart des frameworks d'agents sérialisent tout. Votre agent a besoin d'une fiche client : le framework la convertit en JSON, la dépose dans la fenêtre de contexte, le modèle raisonne sur la copie, et renvoie une autre copie que vous devez réconcilier avec la réalité. Chaque aller-retour coûte des tokens et crée une occasion de dérive entre la représentation mentale du modèle et votre base de données.
Passer une référence vivante change l'économie du système. Le modèle peut appeler une méthode sur l'objet pour récupérer uniquement le champ dont il a besoin, au moment où il en a besoin, sans jamais détenir la fiche complète en contexte. Pour un agent travaillant sur un grand jeu de données — un catalogue produits, une base de code, une année de transactions — c'est la différence entre un système qui tient dans une fenêtre de contexte et un qui n'y tient pas.
Cela règle aussi un problème de correction. Si le modèle modifie un objet vivant, la modification est réelle. Il n'y a plus d'étape de réconciliation susceptible d'échouer.
Le code comme action surpasse le JSON d'appel d'outil
L'idée du « code comme action » gagne discrètement du terrain depuis un moment. Quand un agent exprime une action en Python exécutable plutôt qu'en payload d'appel d'outil, il obtient gratuitement les boucles, les conditions, la composition et la gestion d'erreurs. Trois appels d'outils enchaînés deviennent une ligne de code. Filtrer 500 résultats pour n'en garder que 3 se fait dans l'interpréteur, pas en faisant transiter 500 résultats par la fenêtre de contexte.
NOOA formalise cela en en faisant le comportement par défaut plutôt qu'un mode d'exécution spécial. Le modèle écrit déjà des méthodes sur un objet ; la façon naturelle d'en invoquer cinq à la suite est d'écrire cinq lignes.
Le compromis est réel et doit être nommé : exécuter du code écrit par le modèle exige un bac à sable. Toute équipe adoptant ce motif a besoin d'isolation de processus, de restrictions du système de fichiers et de contrôle du trafic sortant avant la mise en production. La commodité au niveau de l'écriture ne supprime pas le besoin de confinement au niveau de l'exécution.
Ce que NVIDIA a réellement démontré
La troisième contribution de l'article est empirique : les modèles actuels utilisent efficacement cette interface. NVIDIA rapporte des résultats sur des tests de capacité ciblés ainsi que sur des benchmarks agentiques et de raisonnement, dont SWE-bench Verified, Terminal-Bench 2.0 et ARC-AGI-3.
Le propos n'est pas une revendication de classement. C'est une affirmation d'ergonomie portant sur l'interface : les modèles entraînés sur du Python ordinaire savent déjà manipuler des classes, des annotations de type et des docstrings, parce que ces motifs saturent leurs données d'entraînement. Un framework d'agents qui ressemble à du Python idiomatique est, en un sens réel, pré-entraîné dans le modèle. Un DSL sur mesure ne l'est pas.
C'est un argument solide, et il explique pourquoi l'ergonomie converge sans cesse vers « écrivez simplement du code normal ».
Ce que cela implique si vous livrez des agents
Vous n'avez pas besoin d'adopter NOOA pour tirer profit de cet article. Les leçons architecturales se transposent à la stack que vous exploitez déjà :
Gardez le prompt à côté du code qu'il gouverne. Si vos prompts vivent dans un fichier YAML séparé, un magasin de templates ou un SaaS de gestion de prompts, vous avez créé un problème de synchronisation qui vous rattrapera lors d'un refactoring. Les docstrings ne sont pas la seule réponse, mais la co-localisation, si.
Rendez l'état explicite. Un état d'agent caché dans un historique de conversation accumulé est un état que vous ne pouvez ni inspecter, ni tester, ni réinitialiser. Des attributs nommés sur un objet sont débogables à 2 h du matin ; une transcription de 40 tours ne l'est pas.
Typez vos frontières. Des retours validés attrapent toute une classe de défaillances silencieuses que le parsing JSON manuel laisse passer. Si vous êtes en TypeScript, c'est le même argument que développe notre guide des sorties structurées, pris par l'autre bout.
Possédez votre boucle. Un framework qui masque la boucle d'agent masque précisément ce que vous devrez régler : politique de reprise, validation, escalade, budget. Nous avons traité le sujet en profondeur dans l'ingénierie de boucle pour agents IA.
Testez vos agents comme du logiciel. Toute la promesse de l'agent-comme-objet est que votre outillage existant s'applique. Si vous ne pouvez pas écrire un test unitaire contre votre agent aujourd'hui, l'abstraction que vous avez choisie joue contre vous.
Le mouvement de fond
Un motif se dégage de l'évolution de l'outillage d'agents ces deux dernières années. Les frameworks ont commencé élaborés — graphes, nœuds, arêtes, orchestrateurs, machines à états — et n'ont cessé depuis de se délester d'abstractions. LangGraph a simplifié. Le SDK Agents d'OpenAI est sorti délibérément mince. smolagents a parié sur le code-comme-action. Les recommandations d'Anthropic ont constamment poussé vers des boucles plus simples avec de meilleurs outils.
NOOA est l'expression la plus directe de cette tendance à ce jour : non pas un framework plus léger, mais l'argument que le bon framework est surtout le langage dans lequel vous écrivez déjà. Là où Python a une abstraction, utilisez celle de Python. N'ajoutez quelque chose de spécifique aux agents que lorsque Python n'a véritablement pas de réponse — contexte, événements, mémoire, boucles validées.
C'est une discipline, pas une liste de fonctionnalités. Et elle mérite d'être appliquée quel que soit le nom de framework qui finira dans votre pyproject.toml.
Pour commencer
L'article est disponible sur arXiv sous la référence 2607.20709, sous licence CC-BY-4.0. À l'heure où nous écrivons, aucun dépôt public n'est largement indexé : la démarche pratique consiste donc à lire les principes de conception et à les appliquer à votre stack actuelle plutôt qu'à attendre un paquet à installer.
Si vous évaluez une architecture d'agents pour un système de production — et surtout si vous pesez le verrouillage par framework contre le fait de bâtir sur les primitives du langage — les six idées orientées modèle constituent une excellente grille d'audit. Confrontez-y votre stack actuelle. Les manques vous diront d'où viendra votre prochain incident de production.
Chez Noqta, nous construisons des systèmes d'agents IA pour des entreprises en Tunisie et dans le Golfe, et c'est exactement la conversation architecturale que nous avons au démarrage de chaque mission : de combien de framework avez-vous réellement besoin ? De plus en plus, la réponse est : moins que vous ne le pensez.
À lire également :