Chaque enregistrement s’explique : le sérialiseur ai_context

Le côté excitant du logiciel natif IA, c'est l'agent qui fait quelque chose d'utile. Ce qui le fait réellement fonctionner est bien plus terne : la façon dont un enregistrement se décrit à un modèle.

Ratez cela et toutes les démonstrations qui suivent reposent sur du sable. Réussissez-le et l'agent cesse de deviner.

Une ligne de table brute est le mauvais point d'entrée

Une ligne de base de données est conçue pour la base de données. Elle contient des clés étrangères, des énumérations de statut, des colonnes nullables, des drapeaux internes et des horodatages en UTC. Transmettez cela à un modèle et vous lui demandez deux métiers à la fois : reconstituer ce que l'enregistrement signifie, puis raisonner dessus.

Il fera mal le premier. status: 3 ne veut rien dire sans la table de correspondance. Un null dans closed_at peut vouloir dire « toujours ouvert » comme « jamais suivi ». Une clé étrangère est un nombre que le modèle ne peut pas suivre. Alors le modèle invente le sens dont il a besoin — avec assurance — et l'erreur se propage à chacune des étapes suivantes.

La solution n'est pas un modèle plus gros. C'est de donner au modèle la bonne entrée.

Ce qu'est un sérialiseur ai_context

Chez Cyril, chaque entité — un compte, une affaire, un projet, un ticket, une facture — expose un sérialiseur ai_context. C'est une méthode unique qui renvoie une vue déterministe et consciente du schéma de l'enregistrement, construite spécifiquement pour l'ancrage de l'IA.

Cette vue fait le travail d'interprétation que le modèle ne devrait pas avoir à faire :

• Les énumérations sont résolues en leur sens humain — status: 3 devient "stage: negotiation".
• Les compteurs liés sont intégrés — un compte porte son nombre de tickets ouverts, l'état de ses projets actifs et celui de ses factures impayées, parce que c'est ce dont une question sur ce compte aura besoin.
• Les champs purement internes sont retirés — le modèle ne voit jamais les identifiants de ligne, les drapeaux de suppression logique ni la plomberie multi-tenant.
• La forme est stable — le même enregistrement produit le même contexte à chaque fois, donc les invites peuvent être mises en cache et le comportement est reproductible.

Ce n'est, délibérément, ni la réponse de l'API ni la ligne de base de données. C'est une troisième représentation dont le seul public est un modèle.

Pourquoi « obligatoire sur chaque entité » est tout l'enjeu

Il serait facile d'écrire un sérialiseur ai_context pour les trois entités que touche une démonstration de lancement. C'est le piège. L'intérêt d'un graphe de données unique, c'est qu'une question peut franchir n'importe quelle frontière — « quels clients à risque ont aussi un projet en retard et une facture impayée ? » ne marche que si les comptes, les projets et les factures s'expliquent tous de la même façon.

Chez Cyril, le sérialiseur est donc une exigence, pas une fonctionnalité. Une nouvelle entité n'est pas terminée tant qu'elle n'en a pas un. Les patrons de test le vérifient. Cette discipline est ingrate, et c'est exactement ce qui permet à un agent de parcourir la plateforme sans jamais tomber sur un enregistrement qu'il ne sait pas lire.

Le déterminisme est aussi une propriété de sécurité

Parce que le sérialiseur est la seule vue exposée à l'IA, c'est aussi là que nous contrôlons l'exposition. Les décisions champ par champ sur ce qu'un agent a le droit de voir tiennent en un seul endroit auditable par entité, cadré par org_id comme n'importe quelle autre requête. Il n'existe pas de chemin « export IA » séparé qui élargirait discrètement la surface d'exposition — le sérialiseur qui ancre le modèle est exactement celui qui le limite.

Ce que cela vous apporte

• Posez une question qui traverse plusieurs modules et obtenez une réponse ancrée dans des données résolues, reliées et à jour — pas dans des lignes brutes que le modèle a dû décoder.
• Faites assez confiance à la réponse pour agir dessus, puisque le même enregistrement produit toujours le même contexte.
• Sachez que ce que l'IA a le droit de voir se définit en un seul endroit par entité, et non éparpillé dans des intégrations.

Le sérialiseur ne sera jamais la fonctionnalité qu'on met en avant. C'est la couche qui décide si celles qu'on met en avant sont vraies.

Questions fréquentes

En quoi est-ce différent de la réponse de l'API ?

La réponse de l'API est taillée pour un développeur qui assemble un écran : elle est complète, normalisée, et suppose que l'appelant connaît le domaine. Le sérialiseur, lui, est taillé pour un lecteur sans connaissance du schéma et incapable de suivre une clé étrangère ; il résout au lieu de référencer.

Pourquoi ne pas simplement faire de la recherche documentaire sur la base ?

La recherche documentaire trouve du texte qui ressemble à la question. Elle répond à ce qui a été écrit à un moment donné, pas à ce qui est vrai d'un enregistrement aujourd'hui — et pour « quels clients sont à risque ce trimestre », c'est justement toute la question.

Construire cette vue ralentit-elle les requêtes ?

L'état lié qu'elle agrège est de toute façon celui qu'une vraie réponse aurait exigé ; le rassembler une fois, de façon déterministe, coûte moins cher que de laisser le modèle le réclamer sur plusieurs tours. Le déterminisme permet en plus de mettre le résultat en cache, ce que le chemin par lignes brutes ne permet pas.

Que se passe-t-il quand une nouvelle entité est ajoutée ?

Elle n'est pas terminée tant qu'elle n'en a pas un. C'est imposé par les patrons de test plutôt que laissé à la mémoire, parce que tout l'intérêt du graphe est qu'une question puisse franchir n'importe quelle frontière — une seule entité sans sérialiseur est un trou dans lequel un agent tombe.

---

Si vous voulez être parmi les premiers à utiliser Cyril, inscrivez-vous sur la liste d'attente.