Des rêves d’agent RAG aux prototypes VBA : séparer les données brutes et les données dérivées

Le projet était modeste : créer une petite version de Merge, un agent IA personnel. Des expériences avec RAG, LangChain, LangGraph, les embeddings et les bases de données vectorielles étaient déjà en cours, et l’idée initiale était de doter l’agent d’une mémoire à long terme et d’un accès aux documents internes. Puis un autre problème est apparu. La gestion de projets en tant que freelance était devenue chaotique, ce qui a conduit à envisager d’abord d’écrire un petit outil VBA. Cela semblait simple, mais ce n’était pas le cas. Au fil du temps, le prototype VBA s’est transformé en quelque chose d’autre, un moyen d’étudier la logique métier que pourrait un jour hériter un agent IA.

Projets qui refusent un cycle de vie propre

Le travail indépendant ne suit pas de trajectoire bien définie. Une page d’accueil est livrée, puis le client souhaite une refonte. La direction de l’entreprise change, l’intégration de paiements apparaît, suivie de l’automatisation via LINE, puis d’un projet connexe. Sur le plan financier, une tâche peut déjà être terminée et facturée tandis que l’engagement global se poursuit. Les contrats de maintenance sont encore plus étranges, car beaucoup se poursuivent simplement jusqu’à ce que le client indique qu’il n’en a plus besoin.

Un seul champ de statut ne suffit pas à le décrire. Plusieurs dimensions d’état indépendantes le peuvent :

billing_status = closed
task_status = active
invoice_status = pending

Lors de la lecture conjointe, il apparaît que le montant est définitif, la tâche reste active et la facture n’a pas encore été émise. Sinon, vingt états combinés définis manuellement auraient été nécessaires. Les champs indépendants permettent de garder le modèle compact.

Séparation des responsabilités

Après quelques jours de réflexion, une règle de hiérarchisation est apparue :

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Les données primaires contiennent des faits. Les données secondaires contiennent des informations calculées ou transformées destinées à l’œil humain. Une règle fondamentale s’applique : pas de données tertiaires. Une feuille de données secondaires ne doit jamais servir de base à un autre calcul. Lorsqu’un nouveau résultat est nécessaire, on retourne aux données brutes pour générer un nouveau ensemble de données secondaires. Cela peut entraîner la création de nombreuses feuilles de données secondaires, ce qui est acceptable. Vingt vues indépendantes valent mieux qu’une telle chaîne de calculs :

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

car une seule erreur au milieu se propage partout. Le principe de fonctionnement est que plus il y a de feuilles, c’est mieux, mais des dépendances trop profondes ne le sont pas.

Un layout strict pour le livre de travail

Les feuilles sont organisées par domaine de responsabilité, en utilisant une convention de préfixe :

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

Les fiches de données brutes ont l'aspect suivant :

D_Task
D_Point
D_Pharmacy

et les feuilles de calcul principales comme ceci :

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

Les feuilles D_ constituent la source de vérité. Les feuilles M_ sont des dictionnaires commerciaux qui couvrent les entreprises, les produits, les projets et les contacts. S_System stocke la configuration spécifique à VBA : le taux d’imposition, la signification de chaque statut, le tarif horaire et les objectifs de revenus. Les feuilles ayant le préfixe V_ sont des résultats temporaires. Elles peuvent être reconstruites sur demande, et elles existent pour être lues par les utilisateurs, et non pour servir de référence à d’autres formules.

Aucune modification directe

Une deuxième règle est respectée : le fonctionnement normal ne doit jamais nécessiter que quiconque modifie manuellement les données brutes ou les feuilles maîtresses. Les UserForms gèrent la création, la mise à jour et la suppression logique des enregistrements. La suppression n’est pas physique ; un enregistrement est plutôt marqué comme à supprimer :

record_status = deleted

La ligne reste dans le système, ce qui devrait faciliter le suivi de l’historique et réduire les pertes de données accidentelles.

VBA en tant qu’outil d’observation

C’est à ce moment-là que tout le projet a changé de direction. À l’origine, VBA devait automatiser le flux de travail. Son rôle potentiellement plus utile pourrait être de l’observer. Le système peut calculer les revenus attendus du projet et ceux attendus du pharmacien, déterminer combien de revenus supplémentaires sont encore nécessaires, ce qui reste à faire pour chaque projet, quels factures n’ont pas encore été envoyées, où en est chaque projet et combien de points ont été dépensés.

En examinant ces chiffres, on en arrive à des décisions, comme celle de conclure qu’aucun service supplémentaire de pharmaciens n’est nécessaire le mois prochain. Si l’on demande à Merge comment cette décision a été prise, la réponse honnête aujourd’hui est quelque chose comme « l’expérience ». C’est précisément pour cette raison que la décision n’est pas encore automatisée. Le système devrait afficher de manière cohérente les mêmes informations, et après un usage suffisant, des schémas dans les décisions pourraient devenir visibles. Ces schémas pourraient ensuite être intégrés dans Python et finalement dans l’agent. La progression possible :

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

La version VBA n’est donc pas nécessairement l’application finale. Elle sert de laboratoire pour déterminer ce que l’application finale doit savoir.

Outils différents, tâches différentes

Forcer tout le monde dans un seul système serait une erreur. Excel gère les chiffres, la facturation, les statuts, les enregistrements et les tableaux financiers. Notion contient des tâches détaillées, des notes et des informations sur les projets. Un tableau blanc physique permet d’y noter ce qu’il faut se rappeler ou remarquer.

Le tableau à plus long terme combine deux présentations : l’une ressemblant à un rapport et l’autre à une chronologie, avec Merge fonctionnant dans Slack en tant qu’endroit principal de discussion. Un appareil physique Merge pourrait par la suite lire à haute voix les messages importants de Slack grâce à la reconnaissance vocale. Au début, il ne produirait que du texte, les réponses étant tapées dans Slack, car la reconnaissance vocale est difficile à l’extérieur et les expériences précédentes ont entraîné des paroles excessivement fortes émises depuis un ordinateur. C’est pour les conversations vocales directes avec l’appareil physique que le Raspberry Pi reviendrait en jeu.

L’interface devient un tableau noir

Après des jours de discussions sur l’architecture, les travaux ont commencé sur le premier UserForm, qui gère les groupes, les entreprises, les projets, les contacts et les produits. Au début, on pensait qu’il servirait uniquement à des fins personnelles et que l’apparence n’avait pas d’importance. Puis on a choisi une police de caractères amusante, le fond a été modifié, des lignes de séparation blanches sont apparues, et le formulaire sérieux destiné aux données maîtresses est devenu une interface de type tableau noir. Selon Merge, cela ressemblait à MergeLab, et la réaction honnête était qu’il était plutôt agréable à regarder.

En interne, tout est strict : les dépendances, la propriété des données brutes, la suppression logique, ainsi que l’interdiction des données tertiaires. Visuellement, c’est comme si quelqu’un enseignait la normalisation des bases de données au tableau noir à minuit. Le VBA ne fonctionne toujours pas, mais au moins l’interface de tableau noir est cohérente.

Leçons apprises

La leçon la plus importante est que l’automatisation ne devrait pas commencer par l’automatisation elle-même. Il faut d’abord déterminer quelles informations sont factuelles, lesquelles sont dérivées et quelles décisions relèvent encore du jugement humain.

Un nombre réduit de feuilles ne signifie pas automatiquement une moindre complexité. De nombreuses vues secondaires indépendantes peuvent être plus faciles à comprendre qu’une configuration compacte avec de longues chaînes de données dérivées.

Les différents types d’états doivent être placés dans des champs distincts. Plutôt que de disposer de nombreux états combinés, des champs indépendants permettent de décrire des situations réelles bien plus complexes :

task_status
billing_status
invoice_status
record_status

La logique métier doit rester à l’écart de l’interface utilisateur. Un UserForm collecte les entrées et appelle des logiques réutilisables, la feuille de calcul déclenche les mises à jour et affiche les résultats, tandis que les calculs se trouvent dans de petits modules réutilisables. Cela facilite la migration ultérieure du prototype.

Surtout, le prototype peut révéler des règles de décision cachées. Il n’est pas obligé de prendre toutes les décisions dès aujourd’hui ; il suffit que ces décisions soient visibles.

Prochaines étapes

La tâche immédiate est de faire en sorte que le VBA effectue des actions, en commençant par MasterManagementForm, qui enregistre et gère les groupes, les entreprises, les projets, les contacts et les produits. Son flux de base est le suivant :

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

Lorsque les données maîtresses fonctionnent correctement, des formulaires d’entrée distincts sont utilisés pour les feuilles brutes :

D_Task
D_Point
D_Pharmacy

Après cela, les premières vues secondaires peuvent être générées. Les plus importantes pour l’instant :

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Lorsque ces outils seront utilisables dans un contexte professionnel réel, il deviendra évident quels vues sont réellement ouvertes et lesquelles n’étaient que des idées. Ce n’est qu’une fois ce flux de travail stabilisé que une reconstruction adéquate avec Python, une intégration Slack et un agent IA deviendra une option sérieuse.

Ainsi, la séquence jusqu’à présent : une tentative de créer un agent alimenté par RAG, puis Excel, suivie de plusieurs jours passés à définir les limites des données, puis l’utilisation d’une ardoise numérique. Le développement logiciel progresse bien.