Un agent qui agit n'est pas un chatbot avec un accès en écriture

Il y a une différence de nature entre « une IA qui répond à des questions sur vos données » et « une IA qui agit sur vos données ». La première se juge sur la pertinence de ses réponses. La seconde se juge sur ce qu’elle casse.

Voici les trois mécanismes qui, chez nous, séparent les deux.

Agent, automatisation, ou à la main ?

Avant les mécanismes internes, une question plus simple : quand a-t-on seulement besoin d’un agent ?

Trois cas, trois réponses différentes :

• La règle est connue et ne change pas — « quand un statut passe à Gagné, envoyer un email de bienvenue ». Une automatisation suffit : même entrée, même chemin, même résultat, et c’est plus prévisible qu’un agent pour ce cas précis.
• La décision dépend du contenu, au cas par cas — trier des demandes entrantes hétérogènes, qualifier un prospect selon ce qu’il a écrit, résumer une semaine d’activité. Personne n’écrira une règle qui couvre tous les cas à l’avance : c’est exactement le travail d’un agent.
• C’est ponctuel, ou ça arrive une fois — pas besoin d’agent ni d’automatisation, faites-le à la main. Un mécanisme qui surveille en permanence pour une action qui n’arrivera qu’une fois est une dépense inutile.

Le signal le plus fiable : si vous savez déjà décrire la règle en une phrase du type « quand X, fais Y », c’est une automatisation. Si la phrase se termine par « … et ça dépend », c’est un agent.

1. Rien n’est écrit sans proposition

Quand un agent TblFlow décide de créer une table, d’ajouter un champ ou de modifier des enregistrements, il ne le fait pas. Il émet une proposition : un aperçu de ce qui changerait, avec un identifiant. Vous l’acceptez, et alors seulement l’écriture a lieu.

Ça paraît lourd. En pratique, c’est ce qui rend l’outil utilisable, parce que ça déplace la question. On ne vous demande plus « faites-vous confiance à ce modèle ? » mais « ce changement précis est-il celui que vous voulez ? ». La deuxième question a une réponse.

2. La cible est explicite, et contrainte techniquement

Dans le panneau de chat, des boutons précisent l’intention avant même que le modèle ne lise votre texte : Table, Interface, Automation, Agent, Application complète, Données fictives.

Ce n’est pas une aide à la rédaction du prompt. Quand vous choisissez « Table », les outils hors périmètre ne sont pas passés au modèle — ils n’existent pas dans son schéma d’outils, il ne peut donc pas les appeler. Et chaque outil revérifie sa propre autorisation au début de son exécution, au cas où le filtrage dériverait un jour.

La leçon générale : une contrainte appliquée dans le prompt est une suggestion, une contrainte appliquée à l’enregistrement des outils est une garantie. Les deux ont leur place, mais il ne faut pas les confondre.

3. La mémoire est un graphe, pas un historique

Un agent qui ne se souvient que de la conversation en cours redemande les mêmes choses indéfiniment. Un agent qui garde tout l’historique en contexte devient coûteux et confus.

Les agents TblFlow maintiennent un graphe entité/relation persistant : les entités mentionnées sont extraites au fil de l’eau, reliées, et dédupliquées quotidiennement. Ce qui remonte dans le contexte, c’est le sous-graphe pertinent, pas les mille derniers messages.

Ce qui reste difficile

Rien de tout ça ne résout le problème de fond : un modèle peut se tromper avec assurance. Le cycle de proposition transforme une erreur silencieuse en erreur visible, ce qui est un vrai progrès — mais si vous acceptez les propositions sans les lire, vous avez reconstruit le problème que le mécanisme évitait.

C’est aussi pour ça qu’un garde-fou d’approbation humaine existe sur les étapes sensibles des automatisations. Un agent qui envoie des emails à des clients réels n’est pas un endroit pour l’optimisme.