Concevoir des agents IA qui développent et déploient des logiciels : l'architecture de Jobbit

La plupart des « agents IA » s'arrêtent à la conversation. Ils répondent, puis c'est un humain qui fait le travail. Le problème d'ingénierie intéressant — et véritablement difficile — consiste à construire des agents qui font le travail : écrire une application full-stack, l'exécuter, corriger leurs propres erreurs et la déployer en production. C'est précisément le problème sur lequel l'équipe d'ingénierie de Jobbit et sa division R&D, Jobbit Labs (jobbitlabs.com), travaille chaque jour.

Cet article est une plongée technique dans les patterns qui sous-tendent les agents IA qui développent et déploient des logiciels : l'architecture, les modes de défaillance et les enseignements. Il se veut délibérément pratique et agnostique en matière de fournisseur : que vous construisiez avec des LLM, de l'orchestration multi-agents, du tool calling ou du RAG, ces principes restent valables.

Les chatbots répondent ; les agents agissent

Le passage d'un chatbot à un agent, c'est le passage de la génération de texte à la prise d'actions dans le monde réel. Un agent doit planifier une tâche en plusieurs étapes, appeler des outils, lire les résultats et décider de la suite — puis recommencer jusqu'à atteindre l'objectif. Cette boucle, souvent appelée boucle agentique (ou boucle raisonnement–action), est le cœur du système.

Le défi d'ingénierie, c'est que chaque étape peut échouer. Le modèle peut halluciner une fonction qui n'existe pas, écrire du code qui ne compile pas, mal interpréter la sortie d'un outil ou dériver silencieusement de sa tâche. Un chatbot qui se trompe produit une mauvaise phrase ; un agent qui se trompe produit un déploiement cassé. La fiabilité, et non la puissance brute, est le véritable travail d'ingénierie.

L'architecture : planificateur, exécuteur, outils

Une plateforme d'agents robuste sépare la planification de l'exécution. Une couche de planification décompose un objectif (« construire une application de réservation avec paiements ») en étapes concrètes ; une couche d'exécution réalise chaque étape à l'aide d'outils. En gardant ces préoccupations distinctes, le système devient débogable : on peut inspecter le plan indépendamment de la manière dont chaque étape s'est déroulée.

Le tool use (utilisation d'outils) est ce qui donne ses mains à un agent. Les outils sont des fonctions bien définies que le modèle peut appeler : lire un fichier, écrire du code, lancer un build, interroger une base de données, déployer. La discipline d'ingénierie tient ici à la conception des interfaces : chaque outil a besoin d'un schéma strict et sans ambiguïté, d'entrées validées et de sorties structurées que le modèle peut analyser de façon fiable. Les interfaces d'outils trop lâches sont l'une des principales sources d'échec des agents ; les interfaces strictes sont le gain de fiabilité le moins cher qui soit.

Pour les travaux complexes, un agent unique cède souvent la place à l'orchestration multi-agents : des agents spécialisés qui planifient, écrivent du code, relisent et vérifient, coordonnés par un orchestrateur. La décomposition vous offre de la concentration (chaque agent a une tâche restreinte et un contexte restreint) et du parallélisme (les sous-tâches indépendantes s'exécutent simultanément). En contrepartie, la coordination ajoute de la complexité, si bien que la couche d'orchestration doit être déterministe là où elle peut l'être, et résiliente là où elle ne le peut pas.

Exécuter et déployer du vrai code, en toute sécurité

Un agent qui écrit du logiciel doit exécuter ce logiciel — et exécuter du code généré par un modèle est avant tout un problème de sécurité. La réponse, c'est l'exécution de code en sandbox : le code non fiable s'exécute dans un environnement isolé, aux ressources limitées, sans accès aux secrets et avec des frontières réseau strictes. La sandbox est ce qui permet à un agent d'itérer — compiler, tester, lire l'erreur, corriger — sans mettre en danger la plateforme ou les autres utilisateurs.

Le déploiement est l'étape qui transforme une application générée en produit. Un véritable constructeur d'applications IA (AI app builder) maîtrise le chemin du code jusqu'à une URL en ligne : build, provisionnement de l'hébergement, rattachement d'un domaine, terminaison TLS. Bien concevoir cela, c'est rendre les déploiements reproductibles et réversibles : les mêmes entrées produisent le même résultat, et un mauvais déploiement peut être annulé. L'idempotence et un rollback propre n'ont rien de spectaculaire, mais ce sont eux qui rendent le déploiement autonome digne de confiance.

Contexte, mémoire et récupération

Les LLM ont un contexte fini, et les vrais projets n'y tiennent pas. Un système d'agents sérieux investit donc massivement dans le context engineering (ingénierie du contexte) : décider ce que le modèle voit à chaque étape. Tout entasser dans le prompt est à la fois coûteux et contre-productif — un excès de contexte non pertinent dégrade le raisonnement.

C'est là que le RAG (génération augmentée par récupération) et les bases de données vectorielles prennent toute leur valeur. Plutôt que de déverser un dépôt de code entier dans le contexte, le système récupère uniquement les quelques fichiers, symboles ou documents pertinents pour l'étape en cours. Combinée à une mémoire structurée — un historique des décisions, la spécification qui évolue et ce qui a déjà été tenté — la récupération maintient l'agent ancré sur une tâche longue sans faire exploser la fenêtre de contexte. Une bonne récupération est souvent un levier de qualité plus puissant qu'un modèle plus gros.

Fiabilité : évals, vérification et garde-fous

S'il y a une idée qui distingue l'ingénierie d'agents en production des démos, c'est celle-ci : on ne peut pas livrer ce que l'on ne peut pas mesurer. Les systèmes agentiques sont stochastiques ; la fiabilité s'obtient donc par des évals — des suites de tests automatisées qui notent l'agent sur des tâches représentatives et détectent les régressions avant les utilisateurs. Un changement qui « semble meilleur » mais fait chuter vos scores d'éval est un changement que vous ne livrez pas.

Au-dessus des évals viennent les garde-fous (guardrails) et la vérification à l'exécution. Le pattern le plus efficace est l'auto-vérification adverse : après qu'un agent a produit un résultat — un bout de code, un plan, une correction — une passe de vérification distincte tente de le réfuter. Le code compile-t-il ? Les tests passent-ils ? La sortie correspond-elle au schéma ? Traiter la vérification comme une étape distincte et sceptique permet d'attraper une large part des défaillances qu'une unique passe confiante laisserait passer. Les relances avec backoff, les disjoncteurs (circuit breakers) et l'escalade vers un humain gèrent le reste.

Une observabilité réellement débogable

Quand un système autonome prend des dizaines de décisions par tâche, il faut pouvoir les voir. L'observabilité — le traçage structuré de chaque prompt, appel d'outil et résultat — n'est pas négociable. Quand un agent dérape, la trace est ce qui vous permet de retrouver l'étape exacte où il a dévié, de la reproduire et d'en corriger la cause racine. Les équipes qui traitent les traces d'agents comme une télémétrie de premier ordre déboguent en quelques minutes ; les autres déboguent en quelques jours.

L'edge et l'élasticité

Les charges de travail des agents sont en rafales et sensibles à la latence, ce qui fait du edge computing un choix naturel. Exécuter au plus près des utilisateurs — sur des plateformes comme Cloudflare Workers et des stockages de données en périphérie — réduit la latence des allers-retours et permet une mise à l'échelle élastique selon la demande. Jobbit Labs s'appuie sur cette approche edge-first pour une partie de son infrastructure de données et de produit : distribuée mondialement, à autoscaling et facturée à l'usage, de sorte que la capacité suit la charge au lieu de rester inutilisée.

La couche human-in-the-loop

La dernière pièce de l'architecture est celle qui manque à la plupart des plateformes d'agents : un parcours human-in-the-loop (humain dans la boucle). L'IA gère le volume et la vitesse, mais certaines décisions — logique sensible en matière de sécurité, formulation juridique, jugement de design — reviennent à une personne. Concevoir cela, c'est construire des points de relais propres où un expert humain vérifié peut intervenir, avec un séquestre (escrow) qui protège la transaction. L'agent et le réseau humain ne sont pas des couches concurrentes ; ils forment un filet de sécurité pensé dès la conception, qui rend l'ensemble du système fiable.

Enseignements pour les ingénieurs qui construisent des agents

Si vous construisez des systèmes agentiques, quelques principes rapportent leur mise initiale de nombreuses fois.

Concevez des interfaces d'outils strictes. La plupart des échecs d'agents remontent à des outils ambigus. Des schémas stricts et des entrées/sorties validées sont la fiabilité la moins chère que vous achèterez jamais.

Vérifiez de manière adverse. Ne faites pas confiance à une première passe confiante. Ajoutez une étape distincte dont le rôle est de réfuter le résultat.

Mesurez avec des évals. Construisez le harnais d'évaluation avant de passer l'agent à l'échelle. On ne peut pas améliorer ce que l'on ne peut pas noter.

Travaillez le contexte, ne le déversez pas. Récupérez ce qui est pertinent ; mémorisez ce qui compte. Des prompts plus gros ne sont pas de meilleurs prompts.

Mettez tout ce qui n'est pas fiable en sandbox. Si un agent exécute du code, l'isolation est un prérequis, pas une option.

Gardez un parcours humain. Le système autonome le plus sûr est celui qui sait quand demander à une personne.

Foire aux questions

Qu'est-ce qui différencie un agent IA d'un chatbot ?

Un chatbot génère du texte ; un agent IA planifie et prend des actions — il appelle des outils, exécute du code et itère vers un objectif. La difficulté d'ingénierie est la fiabilité sur de nombreuses étapes, où une seule erreur peut compromettre le résultat.

Comment exécuter du code généré par IA en toute sécurité ?

Avec l'exécution de code en sandbox : le code non fiable s'exécute dans un environnement isolé, aux ressources limitées, sans accès aux secrets et avec un réseau restreint, de sorte que l'agent peut compiler, tester et corriger sans risque pour la plateforme.

Pourquoi les évals sont-elles si importantes pour les systèmes d'agents ?

Parce que les agents sont stochastiques, il faut des évals automatisées pour mesurer la qualité sur des tâches représentatives et détecter les régressions avant la mise en production. Sans elles, les « améliorations » ne sont que des suppositions.

Que fait Jobbit Labs ?

Jobbit Labs (jobbitlabs.com) est la division R&D et données derrière Jobbit, axée sur l'ingénierie la plus lourde, intensive en données et à l'échelle entreprise — recherche, plateformes de données et les fondations agentiques sur lesquelles le produit est bâti.

Curieux de l'ingénierie qui se cache derrière les agents qui déploient des logiciels ? Explorez jobbit.uk et jobbitlabs.com.