Comment JONI orchestre la couche agent IA ?

JONI orchestre la couche agent IA en reliant modèles, runtime persistant, actions réelles et contrôles d’exécution. Le vrai sujet n’est pas de générer une bonne réponse. C’est d’aller au bout d’une tâche, sans perdre le contexte, sans bloquer, sans faire n’importe quoi.

Pourquoi la génération ne suffit plus ?

Générer une sortie correcte ne suffit plus quand l’objectif est d’exécuter une tâche complète.

Un modèle peut produire un texte propre, un bout de code qui compile, une recommandation qui a l’air intelligente. C’est utile. Mais ce n’est pas la même chose que prendre une demande, comprendre le contexte, appeler les bons outils, vérifier les résultats, gérer les erreurs, reprendre si ça bloque, puis livrer quelque chose d’exploitable.

C’est là que beaucoup de projets IA coincent. On confond encore “réponse générée” et “travail terminé”. Dans un contexte business, ce qui compte, ce n’est pas que la réponse soit élégante. Ce qui compte, c’est que la facture soit classée, que le CRM soit mis à jour, que le ticket soit résolu, que le rapport soit envoyé à la bonne personne.

Les systèmes IA multi-étapes ont encore des limites très concrètes :

• Ils perdent le contexte quand la tâche dure trop longtemps.
• Ils s’arrêtent au milieu si une API répond mal ou si une donnée manque.
• Ils n’ont pas toujours de mémoire fiable entre deux exécutions.
• Ils peuvent donner une réponse plausible sans avoir vraiment vérifié.
• Ils reprennent mal un travail après un échec, surtout si plusieurs étapes ont déjà été faites.

J’ai vu ça chez un client sur un cas assez simple en apparence : analyser des demandes entrantes, créer un dossier, enrichir les infos, puis notifier l’équipe. Le modèle savait très bien résumer les demandes. Mais dès qu’il fallait enchaîner les actions, garder l’état, éviter les doublons et prouver ce qui avait été fait, il fallait autre chose qu’un prompt plus long.

JONI se place précisément à cet endroit. Pas comme un modèle de fondation de plus, mais comme une couche agent au-dessus des modèles. Le modèle raisonne et génère. JONI orchestre, garde le fil, déclenche les outils, suit l’état d’avancement et sécurise l’exécution.

La vraie question devient donc simple : Est-ce que l’IA a juste répondu, ou est-ce qu’elle a réellement fait le travail ?

Critère	Génération simple	Exécution agentique
Objectif	Produire une réponse	Terminer une tâche opérationnelle
Contexte	Limité à l’échange en cours	Conservé et réutilisé pendant l’exécution
Durée	Courte, souvent instantanée	Plus longue, parfois en plusieurs étapes
Risque	Réponse fausse ou incomplète	Erreur d’outil, interruption, reprise à gérer
Preuve d’exécution	Texte généré	Actions tracées, état suivi, résultat vérifiable

Comment fonctionne le runtime persistant ?

Le runtime persistant donne à chaque utilisateur un environnement cloud qui garde mémoire, fichiers, intégrations et tâches planifiées. C’est la pièce qui évite à l’agent IA de repartir de zéro à chaque échange, comme si toute votre activité devait tenir dans une simple conversation avec un LLM.

Dans JONI, je vois ça comme une architecture hybride. D’un côté, chaque utilisateur a son runtime cloud dédié. C’est son espace stable. Il contient le contexte utile, les fichiers de travail, les connexions aux outils, les automatisations, les préférences, les tâches qui doivent tourner plus tard. Quand il n’y a plus d’activité, ce runtime peut hiberner. Il ne disparaît pas, il se met en pause pour éviter de consommer inutilement.

De l’autre côté, JONI peut lancer des instances éphémères isolées pour les calculs lourds. Une grosse analyse de données, un traitement de fichiers massif, une génération coûteuse, un job technique qui doit être cloisonné… On le lance dans un environnement temporaire, puis on le détruit quand c’est terminé. C’est beaucoup plus propre que de tout faire tourner dans l’espace principal.

Cette séparation change beaucoup de choses en pratique.

• La continuité reste dans le runtime persistant, donc l’agent garde un vrai fil de travail.
• La puissance de calcul arrive à la demande, sans alourdir l’environnement permanent.
• L’isolation limite les dégâts si une tâche plante, consomme trop, ou manipule des données sensibles.
• L’architecture suit des pratiques cloud classiques : séparer l’état durable du compute temporaire.

Côté développeur, c’est une différence énorme. On ne demande pas au LLM de se souvenir de tout dans son contexte, ce qui est fragile, coûteux et parfois imprévisible. On donne à l’agent un vrai environnement d’exécution, avec un état persistant, des fichiers, des accès contrôlés, et des workers temporaires pour les gros traitements. C’est plus proche d’un système logiciel sérieux que d’un chatbot amélioré.

Élément	Rôle
Runtime persistant	Garde la mémoire, les fichiers, les intégrations et le contexte utilisateur.
Instance éphémère	Exécute les calculs lourds ou risqués dans un environnement temporaire.
Hibernation	Met le runtime en pause après inactivité, sans perdre l’état utile.
Isolation	Sépare les environnements pour limiter les risques et les effets de bord.
Tâches planifiées	Permettent à l’agent d’agir plus tard, sans dépendre d’une conversation ouverte.

Qui choisit le bon modèle IA ?

C’est la plateforme qui classe la requête et route la tâche vers le modèle connecté le plus adapté. Dit simplement, JONI ne part pas du principe qu’un seul modèle doit tout faire. Et franchement, c’est plutôt sain.

Chaque demande n’a pas le même besoin. Une question juridique ou financière demande souvent du raisonnement, donc une capacité à suivre une logique, comparer des éléments, éviter les raccourcis. Une demande d’image ou de vidéo demande plutôt de la génération média. Une action dans un outil, comme créer une fiche CRM ou envoyer un mail, demande de l’exécution outillée. Et parfois, on veut juste une réponse rapide, pas une réflexion de trois minutes.

Le routing, c’est cette décision-là. Qui est le mieux placé pour traiter la tâche maintenant ? Le modèle le plus précis ? Le plus rapide ? Le moins coûteux ? Celui qui sait utiliser un outil ? Celui qui gère bien le format demandé ?

Type de requête	Besoin principal	Logique de routage	Risque si mauvais modèle
Analyse complexe	Raisonnement fiable	Envoyer vers un modèle fort en logique et contexte long	Réponse superficielle ou erreur de raisonnement
Génération média	Image, audio ou vidéo	Router vers un modèle spécialisé dans le média demandé	Résultat inutilisable ou hors format
Action dans un outil	Exécution contrôlée	Choisir un modèle capable d’appeler des outils proprement	Mauvaise action, donnée modifiée au mauvais endroit
Question simple	Rapidité et coût maîtrisé	Utiliser un modèle léger si la qualité reste suffisante	Temps perdu et coût inutile

Le point intéressant avec JONI, c’est la neutralité possible. Comme la plateforme n’a pas son propre modèle propriétaire à pousser, elle peut théoriquement arbitrer plus librement entre les modèles connectés. Je dis bien théoriquement, parce que la neutralité ne se décrète pas. Elle se prouve.

Pour que ça tienne, il faut des comparatifs réguliers, transparents et reproductibles. Même jeu de tests, mêmes critères, mêmes conditions. JONI prévoit justement de publier des comparatifs de performance des modèles, sans inventer un gagnant magique valable pour tous les cas. C’est important, parce que le “meilleur modèle” n’existe pas dans l’absolu. Il existe surtout le bon modèle pour la bonne tâche.

Et ça rejoint le chapitre précédent. Le routing décide qui réfléchit. Le runtime garde où et comment la tâche avance. L’un choisit le bon cerveau, l’autre tient le cadre d’exécution.

Comment JONI exécute des actions réelles ?

JONI ne s’arrête pas à la réponse, il déclenche et suit des actions concrètes avec validation, audit et reprise en cas de blocage. C’est ça la vraie différence entre un assistant qui parle et un agent qui travaille. Il ne se contente pas de dire “voici ce qu’il faudrait faire”, il peut exécuter, contrôler, attendre une validation, reprendre plus tard, et laisser une trace propre.

Concrètement, JONI peut lancer des actions assez sensibles. Enregistrer un nom de domaine. Provisionner un hébergement. Déployer un site. Gérer des campagnes publicitaires. Publier sur les réseaux sociaux via les API officielles, donc les interfaces autorisées par les plateformes. Générer des médias, images, vidéos, audio. Utiliser des fonctions d’email et de téléphonie, par exemple envoyer une séquence, appeler un contact, ou notifier une équipe.

Mais dès qu’un agent peut agir, il faut des garde-fous. Sinon on crée juste une machine à faire des bêtises plus vite que nous. Une action à conséquence doit demander une approbation explicite de l’utilisateur. Acheter un domaine, dépenser un budget pub, publier un post public, envoyer un email à une base client, ce n’est pas pareil que résumer un document.

JONI garde donc une piste d’audit. Qui a demandé quoi. Quel outil a été appelé. Avec quels paramètres. À quel moment. Quel résultat est revenu. C’est indispensable quand on doit comprendre, corriger, ou prouver qu’une action a bien été validée.

La fiabilité compte autant que l’intelligence. J’ai souvent vu des automatisations très belles échouer sur la reprise après incident, c’est rarement le scénario nominal qui coûte cher. Le vrai sujet, c’est ce qui se passe quand une API ne répond plus, qu’un paiement reste en attente, qu’un job tourne trop longtemps, ou qu’un utilisateur ferme son navigateur au mauvais moment.

• Détection de blocage. JONI identifie qu’une action n’avance plus ou qu’un état attendu n’arrive pas.
• Redémarrage automatique. Il peut relancer une étape sans refaire toute la chaîne.
• Récupération de travaux orphelins. Un job perdu est repris par un autre processus.
• Checkpointing. Les longues exécutions enregistrent des points de reprise, comme une sauvegarde dans un jeu.
• Réversion et terminaison. On peut annuler, compenser, stopper proprement, ou isoler une action à risque.

Action	Risque	Contrôle attendu	Preuve
Enregistrer un domaine	Achat non souhaité ou mauvais nom	Validation explicite avant paiement	Journal de demande, validation, facture
Déployer un site	Mise en ligne cassée	Prévisualisation, rollback, validation	Version déployée, logs, statut santé
Lancer une campagne pub	Dépense incontrôlée	Plafond budget, approbation, arrêt automatique	Budget validé, ID campagne, métriques
Publier sur les réseaux	Message public incorrect	Aperçu, validation humaine, API officielle	Contenu validé, horodatage, lien public
Envoyer email ou appel	Contact non conforme ou abus	Consentement, quotas, liste d’exclusion	Destinataires, statut, historique d’envoi

Pourquoi ouvrir un marketplace ?

Un marketplace permet d’étendre la couche agent avec des extensions tierces, sans attendre que la plateforme développe tout elle-même. C’est assez simple : si JONI doit tout couvrir en interne, le périmètre avance au rythme de son équipe produit. Si des développeurs peuvent ajouter des briques propres, documentées et maintenues, la couche agent respire beaucoup mieux.

Pour les développeurs, ça change plusieurs choses. Ils peuvent publier des extensions, connecter de nouveaux outils, exposer des actions vers des logiciels métier, ou couvrir des cas très spécifiques qu’une plateforme généraliste ne priorisera jamais assez vite. Je pense à des intégrations CRM locales, des connecteurs ERP un peu exotiques, des workflows de conformité propres à un secteur, ou des outils internes déjà bien installés dans une entreprise.

Dans une architecture agent, chaque pièce a son rôle. Le runtime assure la continuité de l’exécution, il garde le contexte et fait tenir le scénario dans la durée. Le routing choisit le bon modèle IA selon le besoin, le coût, la latence ou le niveau de raisonnement attendu. Les actions exécutent concrètement des tâches dans les outils. Le marketplace, lui, élargit le terrain de jeu.

Mais je reste prudent avec le mot “écosystème”. Un écosystème ouvert n’a de valeur que si les extensions sont sérieuses. Sinon, on crée juste une collection de connecteurs fragiles qui cassent au premier changement d’API.

Les points importants sont assez concrets :

• Les extensions doivent être documentées, avec des entrées, des sorties et des limites claires.
• Les permissions doivent être explicites, surtout quand l’agent accède à des données sensibles.
• La maintenance doit être visible, parce qu’une extension abandonnée devient vite un risque.
• L’intégration doit rester cohérente avec le runtime, le routing et les actions existantes.

La confiance vient de là. Pas d’une promesse vague. D’un contrôle propre, de logs exploitables, de permissions lisibles, et d’une façon claire de savoir ce qu’une extension peut faire ou non.

Pour une entreprise, l’intérêt est net : construire une couche agent extensible, plutôt qu’une pile d’automatisations isolées. C’est ça qui change vraiment l’échelle.

Alors, on construit quoi avec une vraie couche agent IA ?

Je retiens surtout ça : la couche agent IA devient intéressante quand elle dépasse la conversation. JONI pose une approche assez nette avec un runtime persistant, du compute éphémère isolé, du routing vers le bon modèle, des actions concrètes et des garde-fous sérieux. Ce n’est pas juste une interface plus jolie au-dessus d’un LLM. C’est une tentative de rendre l’exécution fiable, traçable et extensible. Pour vous, le bénéfice est simple : moins d’automatisations bricolées, plus de continuité, plus de contrôle, et des agents capables d’avancer vraiment sur des tâches business.

FAQ

• Qu’est-ce qu’une couche agent IA ?
  Une couche agent IA sert à transformer une demande en exécution suivie. Elle ne se limite pas à demander une réponse à un modèle. Elle garde le contexte, choisit les bons outils, déclenche des actions, vérifie l’état d’avancement et garde une trace de ce qui a été fait.
• Pourquoi un runtime persistant est important ?
  Un runtime persistant évite de repartir de zéro à chaque interaction. Il conserve la mémoire, les fichiers, les intégrations et les tâches planifiées. Pour un agent IA, c’est essentiel si on veut gérer des tâches longues ou reprendre proprement après une interruption.
• Le routing entre modèles IA sert à quoi ?
  Le routing sert à envoyer chaque tâche vers le modèle le plus adapté. Toutes les demandes ne nécessitent pas les mêmes capacités. Certaines demandent du raisonnement, d’autres de la vitesse, de la génération média ou une bonne capacité à utiliser des outils.
• Comment limiter les risques quand un agent agit vraiment ?
  Il faut des validations explicites pour les actions sensibles, une piste d’audit, des options de réversion, des mécanismes d’arrêt et une surveillance des blocages. Dès qu’un agent peut acheter, publier, déployer ou contacter quelqu’un, le contrôle humain devient indispensable.
• Pourquoi un marketplace d’extensions change la donne ?
  Un marketplace permet d’étendre plus vite les capacités de la plateforme. Des développeurs tiers peuvent connecter de nouveaux outils ou couvrir des usages métier précis. La valeur dépend quand même de la qualité des extensions, de leur maintenance et de leur intégration dans l’exécution agentique.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA et les sujets SEO/GEO. J’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer des agents IA fiables, des workflows propres ou une architecture data plus solide, contactez-moi, je peux vous aider.