L'intelligence se loge dans la boucle : le loop engineering ou l'art de sortir l'humain du circuit

Un chantier ouvert où l’Europe a ses chances

Deux équipes, le même modèle, la même tâche. La première obtient un agent qui tient la distance. La seconde obtient un prototype qui déraille au troisième enchaînement. Ce qui les sépare n’est pas le modèle, puisqu’il est identique. C’est ce qu’elles ont construit autour.

NVIDIA vient de publier un papier et un framework qui mettent un nom sur cette chose. Le nom compte, parce qu’il désigne un endroit précis où porter l’effort d’ingénierie. Il s’appelle loop engineering. Et une fois qu’on a compris où il déplace la performance, il déplace aussi la question de la souveraineté.

Une brève histoire de ce qui nous préoccupe

Il faut trois plans pour situer le sujet. Chacun a duré à peu près un an, et chacun a déplacé l’effort d’un cran.

2023, l’attention se porte sur le prompt. On cisèle le texte. On teste des formulations. On découvre que « tu es un expert en » change le résultat, sans très bien savoir pourquoi. C’est de l’artisanat. La transmission se fait par capture d’écran, les résultats ne sont pas reproductibles, et personne ne sait dire si une amélioration vient de la formule ou du hasard d’échantillonnage.

2024, l’attention se déplace sur le contexte. RAG, fenêtres longues, sélection et découpage des documents. On ne cisèle plus la formule, on décide ce qu’on met devant le modèle. C’est le premier vrai travail d’ingénierie du domaine : il y a des pipelines, des métriques de rappel, des choix d’architecture qu’on peut défendre en revue.

2026, l’effort se concentre sur la boucle. On ne décide plus seulement ce qu’on met devant le modèle à un instant donné. On conçoit le système qui produit les entrées successives, qui décide de relancer ou d’arrêter, qui délègue, qui mémorise, qui isole.

Le mouvement est net, et c’est lui qu’il faut retenir. À chaque étape, l’effort se déplace vers l’extérieur du modèle. Et à chaque étape, il devient un peu plus du logiciel ordinaire. Du texte, puis des données, puis du code.

Retenez ce dernier point. Nous y reviendrons à la fin, parce que c’est là que se joue l’enjeu européen.

Avant de parler d’ingénierie de la boucle, il faut être précis sur ce qu’est une boucle. Le mot circule beaucoup et désigne trois choses différentes.

Anatomie d’une boucle agentique

Les quatre temps

Un agent, c’est ce cycle :

1. le modèle reçoit un contexte
2. le modèle produit une action
3. l’action s’exécute
4. le résultat rejoint le contexte

Puis on recommence, jusqu’à ce qu’une condition de terminaison soit atteinte.

Tous les agents fonctionnent comme ça, du plus rudimentaire au plus sophistiqué. Ce n’est pas un choix d’architecture, c’est la définition. Un système qui n’a pas cette boucle n’est pas un agent, c’est un appel d’API.

Les trois niveaux

C’est ici que le vocabulaire se brouille, et qu’il faut être méthodique. Trois questions distinctes se cachent derrière le mot « boucle ».

Niveau	Question posée	Réponses possibles
Le squelette	Qu’est-ce qui se répète ?	Contexte, action, exécution, résultat
Le format de l’action	Sous quelle forme le modèle agit-il ?	Texte libre, appel d’outil JSON, code exécutable
L’ingénierie de la boucle	Comment la boucle est-elle conçue ?	Ordonnancement, mémoire, sous-agents, isolation

La confusion habituelle consiste à mélanger le deuxième et le troisième niveau. Ce sont deux décisions indépendantes. Vous pouvez faire du code as action dans une boucle naïve. Vous pouvez faire du tool calling dans une boucle très raffinée. Les deux se combinent, aucun n’implique l’autre.

Les cinq leviers du troisième niveau

Le loop engineering, c’est le travail sur ces cinq leviers.

1. L’ordonnancement. Quand appeler le modèle, combien de fois, avec quel budget, à quel moment abandonner.

2. Les sous-agents. Un agent qui en pilote d’autres, chacun avec son contexte propre, pour éviter qu’un contexte unique accumule tout et se dégrade.

3. Les espaces de travail isolés. Plusieurs agents qui travaillent en parallèle sans se marcher dessus, chacun dans son bac à sable, avec fusion des résultats à la fin.

4. Les compétences chargées à la demande. Plutôt que d’empiler toutes les capacités dans le contexte initial, on ne charge que ce dont la tâche courante a besoin.

5. La mémoire persistante. Ce qui survit entre deux exécutions, et sous quelle forme.

Ces cinq leviers ressemblent à des raffinements. Nous verrons plus loin qu’ils deviennent des nécessités dès qu’on change de régime.

Commençons par le deuxième niveau, le format de l’action.

Code as action

Ce qui cloche dans le tool calling

Dans l’approche classique, le modèle choisit un outil dans une liste et remplit ses paramètres en JSON. Une opération par tour. Le résultat revient dans le contexte, et le modèle choisit l’outil suivant.

Le premier défaut est visible : toute exploration devient linéaire. Impossible de parcourir, de croiser, de reboucler sans multiplier les allers-retours, et chaque résultat intermédiaire traverse le modèle pour être recopié dans l’appel suivant.

Deux autres défauts sont plus graves, et moins souvent nommés.

L’hallucination se démultiplie. À chaque tour, le modèle réémet les paramètres de l’appel suivant à partir de ce qu’il croit avoir lu au tour précédent. Un identifiant mal recopié au troisième tour se propage aux vingt suivants, et rien ne le rattrape puisque chaque appel est validé isolément. Plus la chaîne est longue, plus la probabilité qu’au moins un maillon dérive s’approche de la certitude.

Le contrôle des sorties devient impraticable. Il n’y a pas un contrat unique à vérifier, mais une suite de charges utiles JSON faiblement typées, produites à des instants différents et validées séparément. Vous pouvez contrôler chaque appel. Vous ne pouvez pas dire ce que la séquence garantit dans son ensemble. Avec du code, il y a un seul type de retour et un flot d’exécution que vous pouvez lire, tester et rejouer.

Un cas où le schéma n’existe pas

La plupart des démonstrations de code as action prennent un mauvais exemple. Elles montrent un agent qui parcourt des documents, croise des droits, filtre des dates. C’est spectaculaire, mais c’est réfutable en une phrase : une requête SQL fait ça mieux, plus vite, pour zéro token. Dès qu’il y a une table, il y a une requête, et l’agent devient un intermédiaire coûteux.

Le bon exemple est ailleurs. Il faut chercher là où la donnée existe mais le schéma non.

Ce qu’on appelle captation ambiante

Le terme mérite une définition précise, parce qu’il recouvre souvent un malentendu.

La captation ambiante, c’est le recueil continu et passif des interactions professionnelles : réunions, visioconférences, appels, parfois échanges écrits. Ces flux sont transcrits, puis traités pour en extraire des assertions. Une assertion est un énoncé atomique, daté, attribué, rattaché à des personnes et à des organisations, assorti d’un degré de confiance et d’un lien vers sa source. « Marc a travaillé avec Sophie chez cet éditeur entre 2016 et 2021 » est une assertion.

Deux malentendus à écarter.

Ce n’est pas de l’archivage. L’objet de valeur n’est pas l’enregistrement mais l’assertion extraite, et l’enregistrement peut être détruit une fois l’extraction faite. Ce n’est pas non plus de la prise de notes automatique : un compte rendu de réunion reste un document que seul un humain relit, alors qu’une assertion est un fait manipulable par un programme.

C’est ce qui rend le terrain intéressant, et c’est exactement ce qui le rend sensible. Une captation ambiante sans consentement explicite, sans périmètre défini, sans durée de conservation et sans droit de rectification n’est pas un produit, c’est un problème. La question de savoir qui détient ces assertions et qui a le droit de les traverser précède toute discussion technique. Nous y revenons plus loin.

La question qui n’a pas de réponse aujourd’hui

Ce qui se dit en réunion n’entre dans aucune table. La relation entre Marc et Sophie est réelle, exploitable, prononcée une fois, en passant, dans une transcription parmi trois années d’archives. Aucun champ ne la porte. Le graphe est là, il n’est simplement pas matérialisé.

D’où cette question, que tout commercial se pose et à laquelle aucun outil ne répond :

Qui, dans mon réseau, peut m’introduire auprès du DSI de ce grand compte ?

LinkedIn répond mal, parce qu’il ne voit que les liens déclarés. Votre CRM répond mal, parce qu’il ne stocke que les liens contractuels. Les vraies relations, celles qui permettent une introduction, ont été mentionnées à l’oral et n’ont jamais été saisies nulle part.

Trois façons de traiter la question

Le tool calling explose. Chaque saut du graphe est un appel. Trois sauts sur quelques centaines de personnes, et le nombre d’appels part en explosion combinatoire. Ce n’est même pas un problème de fenêtre de contexte, c’est un problème de branchement.

Le script préconstruit n’existe pas. Pas parce qu’il serait difficile à écrire, mais parce qu’il n’y a rien à requêter. Aucune table ne contient « a travaillé avec ». Et personne n’aurait préparé ce rapport, puisque la question naît d’une opportunité surgie ce matin.

Le code as action apporte une réponse. L’agent écrit la traversée dont il a besoin, à la demande :

cible = graphe.resoudre("DSI", compte)
chemins = []

for personne in assertions.mentionnant(cible):
    for lien in assertions.reliant(personne):
        if lien.source in mon_reseau:
            chemins.append(Chemin(lien.source, personne, cible, lien.extraits))

return classer(chemins)

Boucles imbriquées, accumulation, remontée de chemins. C’est du code, et rien d’autre ne fait ça.

Le bon partage du travail

Notez ce qui se passe au bout du programme. Trois chemins remontent, avec leurs extraits de transcription. Là, et seulement là, le modèle intervient.

Cette relation mentionnée il y a quatorze mois est-elle assez établie pour demander une introduction ? Il faut lire les extraits et juger. Puis rédiger l’approche. C’est de la création, pas de la détection, et aucun programme ne le fera.

Le code traverse, le modèle juge et rédige. Le partage est net, et il a une conséquence que personne ne met en avant : les milliers d’assertions parcourues ne sont jamais entrées dans le modèle. Seuls trois extraits en sont ressortis.

Le code as action est donc aussi un mécanisme de minimisation des données. Pour un déploiement en administration, ça change la nature de la conversation avec le responsable de la sécurité. Vous ne dites plus « l’agent accède à vos conversations ». Vous dites « un programme audité parcourt vos conversations, et seuls trois extraits atteignent le modèle ».

Ce n’est pas une lubie de NVIDIA

Cloudflare est arrivé au même résultat par un autre chemin, en TypeScript, avec une approche qu’ils appellent Code Mode. Leur démarche : convertir les outils MCP en une API TypeScript, puis demander au modèle d’écrire du code contre cette API.

Leur constat mérite d’être rapporté. Les agents gèrent davantage d’outils, et des outils plus complexes, quand ceux-ci sont présentés comme une API plutôt que comme des schémas d’appel. Leur hypothèse : les modèles ont vu une quantité considérable de code réel pendant l’entraînement, et très peu d’exemples d’appels d’outils, qui sont pour l’essentiel artificiels.

Écrire du code est le mode naturel du modèle. Le tool calling lui demande une traduction supplémentaire. Cette convergence entre deux acteurs qui n’ont ni les mêmes intérêts ni le même langage est le meilleur indice que l’idée est solide.

L’objection du graphe de connaissances

Un lecteur attentif objectera : construisez le graphe la nuit par un traitement de fond, puis interrogez-le en Cypher.

La réponse honnête est oui, et c’est la bonne architecture pour les questions connues. Mais deux choses. D’abord, la construction du graphe est elle-même du travail de modèle, puisqu’il faut extraire les assertions de la parole. Ensuite et surtout, chaque question intéressante a une forme de traversée différente. Qui peut m’introduire. Qu’avons-nous promis sans livrer. Où avons-nous perdu contre ce concurrent. On ne matérialise pas toutes les traversées possibles.

Les scripts servent les questions prévues. Les agents servent les questions imprévues.

Quand personne ne demande rien

Tout ce qui précède partage pourtant un défaut, et il est plus profond que le format de l’action. Un humain pose une question, le système répond. C’est encore de la consultation, juste avec une meilleure mécanique.

Retirez le déclencheur humain, et l’exemple change de nature.

Jeudi, vous voyez Marc. Il a mentionné il y a quatorze mois avoir travaillé avec l’actuel DSI de ce grand compte. Ce compte vient de publier un avis de marché. Voici une demande d’introduction, prête à envoyer.

Personne n’a rien demandé. Trois signaux hétérogènes se sont croisés : une assertion vieille de quatorze mois issue de la captation ambiante, un événement d’agenda, un signal externe. Aucun des trois n’a de sens seul. Et la sortie n’est pas une réponse, c’est une proposition d’action, rédigée.

Règle contre pertinence

Un script a besoin d’un déclencheur explicite. Vous pouvez écrire « alerte-moi si une affaire est silencieuse depuis trois semaines », et c’est une bonne règle. Vous ne pouvez pas écrire « signale-moi ce qui mérite mon attention ».

La différence est celle entre règle et pertinence. Les règles s’énumèrent, la pertinence non. Elle dépend de qui vous voyez cette semaine, de ce qui a bougé chez vos clients, de ce que vous avez déjà écarté le mois dernier. Le déclencheur pertinent n’est pas connu à l’avance, donc il n’y a rien à planifier.

Ce qui casse quand l’humain sort de la boucle

C’est ici que tout se referme.

Tant qu’un humain déclenche, la boucle est bornée et l’humain corrige. Une boucle médiocre reste utilisable, parce que quelqu’un relit, reformule et relance. L’ingénierie de la boucle est un confort.

Retirez l’humain du déclenchement, et les cinq leviers cessent d’être des raffinements :

• l’ordonnancement devient le produit, puisque plus rien ne dit à l’agent quand se réveiller ni quel budget dépenser
• la mémoire persistante devient obligatoire, sinon l’agent reproposera lundi ce que vous avez écarté vendredi
• l’isolation devient une condition d’exploitation, puisque du code s’exécute sans personne devant l’écran
• les sous-agents deviennent structurants, parce que balayer et rédiger sont deux métiers qui ne demandent ni le même contexte ni le même modèle
• les compétences chargées à la demande évitent qu’un agent permanent traîne en permanence tout son outillage

Le loop engineering est la discipline qui apparaît quand on retire l’humain de la boucle. C’est la définition la plus utile qu’on puisse en donner.

Le mode d’échec à nommer

La proactivité crée un risque que la consultation n’avait pas : le bruit.

Un agent qui propose trop est pire qu’un agent muet, parce qu’on cesse de le lire au bout de quinze jours. Et le jour où il a raison, plus personne ne regarde.

Le seuil de déclenchement, la mémoire des refus, la limitation du débit de propositions : tout cela est encore de l’ingénierie de la boucle, et c’est probablement la partie la plus difficile. Il faut le dire, sous peine de vendre une promesse.

NOOA, ou l’agent comme objet

Reste à savoir avec quoi construire ces boucles. C’est là que NVIDIA propose quelque chose de plus radical qu’un framework de plus.

Le pari

NVIDIA-labs OO Agents, abrégé NOOA, tient dans une phrase : un agent est un objet Python. Les champs sont l’état, les méthodes sont les capacités, les docstrings sont les prompts, les annotations de type sont les contrats.

Reprenons notre agent de réseau :

from nooa import Agent

class AgentReseau(Agent):
    """Tu veilles sur le réseau relationnel de ton utilisateur."""

    assertions: JournalAssertions
    agenda: Agenda
    ecartees: MemoireDesRefus

    def chemins(self, cible: Personne) -> list[Chemin]:
        return self.assertions.traverser(vers=cible, sauts=3)

    async def vaut_une_introduction(self, chemin: Chemin) -> Jugement:
        """Cette relation est-elle assez établie pour demander une introduction ?"""
        ...

    async def rediger(self, chemin: Chemin) -> Message:
        """Rédige la demande d'introduction."""
        ...

Le détail décisif est dans les trois points. Une méthode avec un vrai corps s’exécute normalement, en Python déterministe. Une méthode dont le corps est ... est complétée à l’exécution par une boucle agentique.

La frontière entre le déterministe et le probabiliste devient une propriété du code, visible à la lecture. Dans l’exemple ci-dessus, la traversée du graphe est mécanique et le jugement est confié au modèle. Vous le voyez en ouvrant le fichier. Aucun framework ne rendait cette frontière aussi lisible.

Pourquoi le nom d’une méthode compte

Un mécanisme mérite d’être explicité, parce qu’il surprend au premier abord.

Pour une méthode à corps vide, ce qui est transmis au modèle, c’est la signature complète : le nom de la méthode, ses paramètres typés, son type de retour et sa docstring. L’ensemble tient lieu d’instruction. Il n’y a pas de fichier de prompts à maintenir à côté du code, parce que le code est le prompt.

Conséquence directe : renommer rediger en rediger_bref modifie l’instruction transmise, donc la sortie. Le mot « bref » n’est pas décoratif, il est lu comme une consigne.

C’est élégant, parce que la nomenclature devient un acte de conception plutôt qu’une convention d’équipe. C’est aussi une fragilité qu’il faut connaître : un renommage de confort, du type de ceux qu’un outil de refactorisation propose automatiquement, change le comportement sans que rien ne le signale. Vos tests deviennent le seul garde-fou.

Les cinq leviers, revisités

Levier	En NOOA
Ordonnancement	Une boucle Python que vous écrivez
Sous-agents	Un attribut de l’objet, instancié normalement
Mémoire persistante	Un champ de l’objet, plus le paquet nooa-memory
Compétences	Un répertoire skills/, chargées à la demande
Espaces isolés	Le bac à sable d’exécution du code généré

La thèse de NVIDIA tient là : Python possède déjà ces primitives. Une boucle est un for. Un sous-agent est une instanciation. La mémoire des refus est un champ. Inutile d’empiler un langage d’orchestration par-dessus un langage qui sait déjà faire tout ça.

Le papier identifie six idées que NOOA revendique d’être le premier à réunir sur une même surface : entrées et sorties typées, passage par référence sur des objets vivants, code as action, ingénierie programmable de la boucle, état explicite de l’objet, et interfaces de contexte et d’événements appelables par le modèle. Les auteurs notent que la communauté converge déjà sur plusieurs de ces idées, souvent à l’état de fonctionnalité expérimentale ou partielle.

Combiner le déterministe et le probabiliste sans les confondre

C’est là que le pari me convainc, et c’est un point d’architecture avant d’être un gain de productivité.

La plupart des frameworks brouillent la frontière. Le modèle est partout, l’orchestration est une configuration, et vous ne savez plus dire quelle partie de votre système est reproductible et quelle partie ne l’est pas.

NOOA fait l’inverse. Il vous force à placer la frontière vous-même, méthode par méthode, et il la rend visible dans le fichier. La traversée du graphe est déterministe parce que vous l’avez écrite. Le jugement sur la qualité d’une relation est probabiliste parce que vous avez laissé trois points. Personne n’a décidé à votre place.

Le corollaire est agréable. Tout ce qui est déterministe redevient du logiciel ordinaire : on le teste avec pytest, on le trace, on le refactorise, on le versionne, on lit un diff et on comprend ce qui a changé. Et l’effort de validation, qui coûte cher, se concentre sur les rares endroits où le modèle intervient réellement.

Pour un agent permanent qui agit sans supervision directe, ce n’est pas un confort de développeur. C’est une condition d’admissibilité devant une autorité.

Deux réserves, à garder en tête sans qu’elles changent le tableau. NOOA est en version 0.0.7, estampillé « labs », donc sans engagement de support. Et ses auteurs écrivent noir sur blanc que leurs vérifications de code sont des garde-fous en profondeur et non une frontière de confinement : la vraie frontière est l’isolation au niveau du système. Cette honnêteté est à leur crédit, et elle pèse d’autant plus lourd pour un agent qui s’exécute sans personne devant l’écran.

Ce que ça change pour la souveraineté

Le raisonnement tient en trois pas.

Premier pas. Le billet technique qui accompagne le papier s’intitule Six Agent Harness Capabilities for Higher Model Performance. Lisez le titre attentivement. Pas de meilleurs modèles. Un meilleur harnais, pour de meilleures performances, à modèle constant.

Deuxième pas. Si le harnais améliore les performances à modèle constant, alors une part de la performance ne réside plus dans les poids. Elle réside dans le harnais.

Troisième pas. Or le harnais est du logiciel ordinaire. Il ne demande ni cluster d’entraînement, ni milliards d’investissement, ni accès privilégié à des GPU. Il demande des ingénieurs qui savent concevoir des systèmes.

La conséquence stratégique est directe. Nous ne rattraperons pas les modèles de frontière sur les poids à court terme, et il faut cesser de faire semblant. Nous pouvons parfaitement rattraper sur la boucle. Un bon loop engineering sur des SLM plus maîtrisés, comme les Nemotron de NVIDIA, les Qwen ou les Lucioles d’OpenLLM France en 1B, 8B et 23B, les rapproche des modèles américains sur des tâches réelles, parce qu’il compense par l’architecture ce qui manque en capacité brute. Un modèle plus petit est aussi un modèle qu’on peut auditer, faire tourner sur son propre matériel et spécialiser sans demander la permission à personne.

Il y a un second argument, moins évident et peut-être plus important. Ces frameworks sont agnostiques du modèle. NOOA s’appuie sur LiteLLM et accepte indifféremment un modèle hébergé, un serveur vLLM local ou une instance Ollama. Le harnais que vous construisez survit au modèle que vous y branchez. C’est un actif qui ne se déprécie pas au rythme des sorties de modèles. Dans ce domaine, c’est rare.

Il y a un troisième argument, et c’est celui qui devrait décider les acheteurs publics. Un agent permanent qui balaye en continu les conversations d’une organisation est un objet politiquement sensible. La question n’est pas seulement de savoir où tournent les poids. Elle est de savoir qui peut lire le journal de ce que l’agent a parcouru, et selon quelles règles il a décidé de remonter telle proposition plutôt qu’une autre. Cette redevabilité ne se négocie pas dans un contrat de licence. Elle se lit dans le code du harnais, ou elle n’existe pas.

La nuance obligatoire, pour ne pas raconter d’histoires : le harnais réduit l’écart, il ne l’annule pas. Un bon harnais sur un modèle médiocre reste un modèle médiocre. La question n’est pas de remplacer la course aux modèles, elle est de savoir où placer un effort d’ingénierie à budget contraint.

Pour finir

Le loop engineering est un chantier ouvert. Il n’est ni breveté, ni capitalistique, ni verrouillé par un acteur dominant. Il demande des gens qui savent concevoir des systèmes et raisonner sur des architectures, compétence que l’Europe n’a jamais perdue.

Et il porte une question qui n’est pas seulement technique. Un agent qui attend qu’on l’interroge est un outil. Un agent qui décide de vous interrompre est autre chose. La façon dont cette boucle est conçue, ce qu’elle mémorise, ce qu’elle exécute et ce qu’elle consent à taire, tout cela relève d’un choix politique déguisé en choix d’architecture.

Autant qu’il soit fait ici, par nous et de manière maîtrisée et auditable.

---

Sources

• Furgale, Klingler, Nolan et al., NVIDIA-labs OO Agents: Native Python Object-Oriented Agents, arXiv:2607.20709, 22 juillet 2026.
• Dépôt NVIDIA-NeMo/labs-OO-Agents, licence Apache 2.0.
• NVIDIA, Six Agent Harness Capabilities for Higher Model Performance.
• Cloudflare, Code Mode: the better way to use MCP.
• OpenLLM France sur Hugging Face : famille Luciole 1B, 8B et 23B, et Lucie 7B.

Sur ce carnet, la ligne éditoriale continue

• Kimi K3 : les poids sont libres, le compute ne l’est pas (encore) · pourquoi la classe 3T ouverte change la donne, et où se déplace la vraie frontière.
• La distillation, nouveau front de la guerre technologique sino-américaine · quand la bataille cesse de porter sur le hardware pour se déplacer vers les modèles.
• POSAIS 2026 : cap sur un modèle Frontier européen · la feuille de route en 4 points pour l’alternative européenne.
• Tout ce que vous avez toujours voulu savoir sur les World Models et JEPA · le débat de fond sur les limites structurelles des LLM autorégressifs.